When a non-Latin input source like Korean 두벌식 is active,
event.charactersIgnoringModifiers returns Hangul characters (e.g. ㅅ
for T key) instead of Latin letters. This caused all character-based
shortcut matching to fail — Cmd+T, Cmd+D, Cmd+1-9, Ctrl+N/P, etc.
Root cause: KeyboardLayout.character(forKeyCode:modifierFlags:) assumed
CJK input sources lack kTISPropertyUnicodeKeyLayoutData, but Korean
두벌식 has it. UCKeyTranslate returned Korean characters and the ASCII
fallback was never reached.
Fix:
- KeyboardLayout.character(): check result is ASCII before accepting;
fall through to TISCopyCurrentASCIICapableKeyboardInputSource() when
the current source returns non-ASCII characters
- Add KeyboardLayout.normalizedCharacters(for:) helper that normalizes
event.charactersIgnoringModifiers for shortcut comparison
- Apply normalization in handleCustomShortcut (AppDelegate),
BrowserPanelView omnibar key handler, and BrowserPopupWindowController
Cmd+W handler
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
When a non-Latin input source is active, event.charactersIgnoringModifiers
returns CJK characters that cannot match Latin shortcut keys. This adds
ASCII-capable input source fallback in KeyboardLayout and updates the
matchShortcut guard to skip early-return when event chars are non-ASCII.
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The ctrl fast path unconditionally returned after calling ghostty_surface_key,
even when it returned false (e.g. ignore keybindings), preventing IMEs from
receiving Ctrl-modified key events. Now falls through to interpretKeyEvents
when the key is not handled.
Also adds keyboard layout change detection around interpretKeyEvents (matching
Ghostty upstream) so that IME-triggered layout switches cause an early return
instead of sending the key to Ghostty.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
