[Bug]: Right panel launcher hotkeys fail on non-Latin keyboard layouts & terminal close dialog UX issues #13427

Activity

1. juliusmarminge commented on Sep 24, 2026

   

   juliusmarminge

   on Sep 24, 2026

   Member

   More actions

   Confirmed on main at b2b43be. Desktop and web share this UI. Mobile does not use this launcher.

   Bare launcher letters compare event.key, so a non-Latin layout never hits them.

   surfaceShortcutActionForKey activates an available surface only when event.key equals the shortcut letter. Modified keys are ignored here.

   export function surfaceShortcutActionForKey<
     const Action extends { available: boolean; shortcut: string },
   >(actions: readonly Action[], event: SurfaceShortcutEvent): Action | null {
     if (event.defaultPrevented || event.isComposing) return null;
     if (event.metaKey || event.ctrlKey || event.altKey) return null;
     return (
       actions.find(
         (action) => action.available && action.shortcut.toLowerCase() === event.key.toLowerCase(),
       ) ?? null
     );
   }

   The empty state listens on window in the capture phase while it is mounted, and publishes the same Latin letters on data-surface-launcher-keys (B, T, F, D, P, L, A, M, whichever are available). shouldTypeToFocusComposer bails only when event.key is one of those letters:

     // The right-panel surface launcher claims its shortcut letters while it is
     // visible (data attribute set in RightPanelTabs); those keys open surfaces
     // instead of typing into the composer.
     const launcherKeys = document
       .querySelector("[data-surface-launcher-keys]")
       ?.getAttribute("data-surface-launcher-keys");
     if (launcherKeys && launcherKeys.toLowerCase().includes(event.key.toLowerCase())) return false;

   Modified shortcuts already fall back to the physical key when the layout character is not a Latin letter. That is why Cmd+Opt+B still opens the panel on a Ukrainian layout:

   function resolveEventKeys(event: ShortcutEventLike): Set<string> {
     const layoutKey = normalizeEventKey(event.key);
     const keys = new Set([layoutKey]);
     // The physical-position fallback exists for layouts that type non-Latin
     // letters (Cyrillic, Greek) and for Option-modified symbols on macOS.
     // When the layout already produces a Latin letter, match on it alone;
     // otherwise a remapped physical key triggers shortcuts for two different
     // letters at once and shadows system shortcuts on non-QWERTY layouts.
     const letterCode = event.code?.match(/^Key([A-Z])$/)?.[1];
     if (letterCode && !/^[a-z]$/.test(layoutKey)) {
       keys.add(letterCode.toLowerCase());
     }
     keys.add(shortcutKeyFromEvent(event));
     return keys;
   }

   The bare T does not use that fallback. On a Ukrainian layout that key reports е with code KeyT. е is not in the launcher list, so the capture handler returns and type-to-focus inserts it into the composer. The same matcher is used for letter shortcuts inside the add-surface menu.

   The empty state does call focus() when its node mounts (focusOnMount in RightPanelTabs). Those letters also do not require the launcher to be the focused element. They do stop when focus is in an input, textarea, select, or contenteditable, which includes the composer. usePanelPresence turns the panel present in an effect after open becomes true, so a letter pressed in that gap still belongs to the composer. After the empty state has mounted, the failure that remains on a non-Latin layout is the event.key comparison.

   The fix for this half is the same guard as resolveEventKeys: use code KeyA–KeyZ only when event.key is not already a Latin letter, in both surfaceShortcutActionForKey and shouldTypeToFocusComposer. A Dvorak or Colemak layout that types a different Latin letter must keep matching event.key alone.

   The close dialog matches the other confirmations.

   confirmTerminalClose always asks, through the shared host, with variant: "destructive". ConfirmDialogOptions is only that variant. Cancel is the first button, and the host passes no initialFocus, so the dialog opens on Cancel and Enter activates it. Nothing handles arrow keys; Tab moves between the buttons. There is no “Don’t ask again” control. Thread unpin, archive, and delete are switches under Settings → General → Confirmations, with no checkbox in the dialog.

   A remembered skip, and arrow-key movement inside this dialog, would be new behavior. Defaulting this host’s initial focus to Confirm would also make Enter confirm delete and the other destructive prompts.

   This issue should stay the shortcut bug. The dialog requests belong on their own.

   #13428 is the reporter’s PR for both halves. The shortcut half follows the Latin-letter guard above. The new empty-state effect lists shortcutActionsRef in its dependency array before that ref is declared, so rendering the launcher throws. The dialog half also points every confirmation’s initial focus at Confirm.

   Same event.key gap, different call sites: #13409 (Mod+B bold) and #13411 (paste-as-text).
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Sep 24, 2026
3. juliusmarminge commented on Oct 22, 2026

   

   juliusmarminge

   on Oct 22, 2026 – with GitCafe Production

   Member

   More actions

   Existing work covers the shortcut repair: #21508 is open specifically for non-Latin launcher letters. The composer-interception repair landed in 86fa9e0a0c. The optional terminal-confirmation setting also has an open PR, #16615. No competing implementation is needed.

   The remaining requests to change destructive-dialog default focus, add arrow navigation and remember the choice are product changes. The maintainer closing comment on #13428 explicitly directs that confirmation behavior to Ideas. Routing that discussion for maintainer conversion; the non-Latin bug remains covered by the focused open PR.
4. pingdotgg

   locked and limited conversation to collaborators on Oct 22, 2026
5. juliusmarminge

   converted this issue into a discussion #23320 on Oct 22, 2026