mirror of
https://github.com/stablyai/orca.git
synced 2026-10-21 08:03:33 +00:00
Neil
a3c96136db
CompositionHelper.keydown exempted keyCodes 16/17/18 from tearing a composition down, which covers Shift/Ctrl/Alt but not macOS Meta — 91/93 in Chromium, 224 in Firefox. A lone Cmd press mid-composition therefore reached _finalizeComposition(false), which dropped the preedit overlay's `active` class and committed the live syllable early. macOS keeps the marked text alive across that press, so no later compositionstart re-arms the overlay and the rest of the word composes invisibly. Measured on hardware (m4air, macOS 26.5.2, Apple M4, 2-Set Korean) with the Cmd posted as a CGEventType.flagsChanged, which is what a physical modifier emits. AppleScript `key code 55` posts nothing a browser can see — a bare `key code 56` for Shift is equally silent — which is why no capture in the corpus ever reached this branch. Three arms, same build otherwise: overlay live throughout with the exemption, dark and prematurely committed without it, live again with it restored. Evidence under .tmp/ime-handoff/swarm-scratch/wave31-cmd-preedit/evidence/. The fix cannot widen past a lone modifier: only a standalone press reports these keyCodes, and a Cmd chord during composition is reported by Chromium as 229, which was already exempt. Cmd+A still ends the composition, via the IME's own compositionend. Ghostty draws the same line, returning early from flagsChanged under hasMarkedText() for every modifier including Super. Orca's terminal pane was never affected — shouldSuppressTerminalModifierKeyboardEvent drops a standalone Meta keydown before xterm sees it, and deleting only 'Meta' from that set is what flipped the hardware arm to broken. The popout preview terminal and mobile's webview install no such guard and did reach the teardown. terminal-ime-xterm-composition-commit-overlap.test.ts asked its fixer to update the two Cmd arms to the values it named as correct; both now emit a single ['한'].