fix(web): right panel launcher letters work on non-Latin keyboard layouts#21508

_{P2 Badge} Treat accented Latin letters as layout output

On a Latin layout with an accented letter at a US launcher position—for example, Bépo emits è with code === "KeyT"—the ASCII-only test classifies the character as non-Latin and sets physical to t. When Terminal is available and the empty launcher handles the event before type-to-focus, pressing è opens Terminal instead of preserving the typed character (the actual Bépo t already matches through event.key). Test for the Latin Unicode script, not just [a-z], before enabling this fallback.

Useful? React with 👍 / 👎.

The fallback to the physical key now applies only when the typed key is a single letter or combining mark from a non-Latin script, so Bépo è on KeyT stays text while Bépo t still matches through event.key. Punctuation such as the French AZERTY comma on KeyM and Dead keys no longer fall back either, and unit cases cover all three.

_{P2 Badge} Guard AltGraph text before using the physical key

On Linux/X11 layouts where AltGr is exposed through getModifierState("AltGraph") without setting ctrlKey or altKey, German AltGr+M can produce key === "µ" with code === "KeyM". When Device is available, the panel is in its empty-launcher state, and focus is outside an editable element, this branch classifies that character as non-Latin, opens Device, and prevents type-to-focus from inserting it. The normal keybinding matcher already rejects non-ASCII AltGraph text in packages/shared/src/keybindings.ts:105-110; add getModifierState to this event shape and apply the same guard before the physical fallback.

Useful? React with 👍 / 👎.

The matcher now returns early when AltGraph is held and event.key is not an ASCII letter or digit, the same test matchesKeybindingShortcut uses outside macOS, so German AltGr+M typing µ leaves Device shut while Finnish AltGr+B typing b still opens Browser, with a unit case for each. From my reading of the Chromium and Firefox sources, Windows layouts with an AltGr key report AltGraph without ctrlKey or altKey like Linux does, so this covers Windows too, and on macOS Option sets altKey, which the existing early return already handles.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Register the launcher listener in the persistent ChatView lifecycle.

After the panel closes and its presence timeout completes, usePanelPresence unmounts RightPanelTabs. Reopening the panel mounts it after ChatView has already registered useChatShortcuts on window, so the composer capture listener runs first.

For a non-Latin event such as key: "е" and code: "KeyT, the composer can insert event.key and call preventDefault(). The later launcher listener then rejects the event because surfaceShortcutActionForKey checks event.defaultPrevented, so the physical-key surface shortcut fails.

Register launcher dispatch from the persistent ChatView lifecycle before useChatShortcuts, or add an equivalent pre-dispatch coordination point. Do not rely on the conditional RightPanelTabs mount order.

@MarMarLabs Thanks for clarifying. The listener-order bug is pre-existing and tracked in #21541, with a separate fix in #21556. I withdraw this finding from the layout-matcher PR. No listener relocation is needed here.

✅ Review thread resolved.

You are interacting with an AI system.

This is the listener-order bug tracked as #21541, which a maintainer confirmed on main and accepted, and #21556 is the open fix PR for it. This PR stays on the layout matcher and leaves the launcher's listener where it is.

_{P2 Badge} Accept multi-code-point non-Latin key values

On the Windows Arabic (101) layout, the physical B key reports لا (lam plus alef) as a multi-code-point printable value. The single-code-point anchors make this test fail even though code is KeyB, so neither the empty launcher nor the add-surface menu opens Browser from that layout. Treat strings composed entirely of non-Latin letters/marks as eligible for the physical-key fallback rather than requiring exactly one code point.

Useful? React with 👍 / 👎.

The fallback now accepts a run of non-Latin letters and combining marks, so lam alef on the B key opens Browser wherever event.key carries both letters, and the non-Latin unit case checks it. From my reading of the engine sources, that is Firefox and Safari, while Chromium reports at most one typed character, so Chrome and the desktop app on Windows still get Unidentified for that key and behave as on main.