fix(macos/ime): skip key-equivalent priority path while IME is composing (#9709)

[maxmilian]

Description

Fixes #9709 — on macOS, third-party IMEs that listen on the input context (e.g. 超注音 / Yahoo Bopomofo) observed every arrow keystroke twice during candidate selection, advancing the highlight by 2 instead of 1.

Root cause

Arrow keys carry the function-key flag (modifierFlags=0xa00100), so they qualify as key equivalents and AppKit dispatches them through performKeyEquivalent: before keyDown:. In crates/warpui/src/platform/mac/objc/window.m::performKeyEquivalent:, the previous implementation:

1. Called [self.contentView keyDownImpl:event] — which invokes interpretKeyEvents: and forwards to Rust
2. Rust suppresses keystrokes during composition (is_composing=true), so keyDownImpl returned NO
3. Fell through to [super performKeyEquivalent:event]
4. AppKit then dispatched keyDown: on the host view → keyDownImpl again → interpretKeyEvents ran a second time

Apple's built-in IME uses IMKCandidates (a separate NSPanel) for candidate selection, so the second delivery doesn't reach its candidate index. 超注音 draws its candidate panel itself and listens on the input context directly — it observes both deliveries and advances by 2.

Fix

Skip the priority path in performKeyEquivalent: while hasMarkedText is YES. AppKit then routes the event through the standard keyDown: chain exactly once.

Testing

NSLog instrumentation (before/after)

I added per-call instrumentation around keyDownImpl, interpretKeyEvents, setMarkedText:, insertText:, unmarkText, doCommandBySelector:, and performKeyEquivalent: and reproduced with 超注音 (Yahoo Bopomofo) on macOS 26.4.1.

Before the fix — single right-arrow press during candidate selection:

performKeyEquivalent: keyCode=124 modifiers=0xa00100
performKeyEquivalent: keystrokeIsAssigned=1
keyDownImpl#8 ENTER keyCode=124 wasComposing=1
  interpretKeyEvents BEGIN                    ← IME +1
  setMarkedText: '...' (interpretingKeyEvents=1)
  setMarkedText: '...' (interpretingKeyEvents=1)
  interpretKeyEvents END (hasMarkedText=1)
warp_handle_view_event(composing=1) handled=0
performKeyEquivalent: keyDownImpl returned NO, falling through to super
keyDown: keyCode=124                          ← AppKit fires again
keyDownImpl#9 ENTER keyCode=124 wasComposing=1
  interpretKeyEvents BEGIN                    ← IME +1 again → total +2
  ...

After the fix:

performKeyEquivalent: keyCode=124 modifiers=0xa00100
performKeyEquivalent: IME composing, skipping priority path
keyDown: keyCode=124
keyDownImpl#22 ENTER keyCode=124 wasComposing=1
  interpretKeyEvents BEGIN                    ← single delivery
  interpretKeyEvents END (hasMarkedText=1)

Manual verification (macOS)

• 超注音 (Yahoo Bopomofo): right/left arrow now advances candidate by exactly 1 per press (was 2). ✅
• Apple built-in 注音 (Bopomofo): no regression — candidate window behaves identically. ✅
• Apple Pinyin: no regression. ✅
• Cmd-shortcut keys without IME composition (e.g. Cmd-T new tab): no regression — the hasMarkedText guard only triggers during active composition, so the priority path still executes for ordinary key equivalents. ✅
• Plain typing without an IME: no regression. ✅

No automated tests were added: the bug requires running an IME on macOS and observing AppKit's two-stage event delivery (performKeyEquivalent: → keyDown:), which is impractical to simulate in the existing unit/integration test harnesses. The change is small, well-scoped (performKeyEquivalent: only), and the guard short-circuits to [super performKeyEquivalent:] on the same path AppKit would fall back to anyway.

Server API dependencies

• Is this change necessary to make the client compatible with a desired server API breaking change?
• Does this change rely on a new server API?
• Is this change enabling the use of a server API on client channels that rely on the production server?

None — this is a pure native-input-handling change.

Agent Mode

• Warp Agent Mode - This PR was created via Warp's AI Agent Mode

Changelog Entries for Stable

CHANGELOG-BUG-FIX: macOS: fix third-party IMEs (e.g. 超注音 / Yahoo Bopomofo) advancing candidate selection by 2 per arrow press during composition.

[cla-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have the users @maxmilian on file. In order for us to review and merge your code, each contributor must visit https://cla.warp.dev to read and agree to our CLA. Once you have done so, please comment @cla-bot check to trigger another check.

[oz-for-oss]

@maxmilian

I'm starting a first review of this pull request.

You can view the conversation on Warp.

I reviewed this pull request and requested human review from: @vorporeal.

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[oz-for-oss]

Overview

This PR skips Warp's key-equivalent priority path while macOS marked text is active, allowing AppKit to deliver IME composition keys through the normal keyDown: path exactly once.

Concerns

• No blocking correctness or security concerns found in the changed lines.

Verdict

Found: 0 critical, 0 important, 0 suggestions

Approve

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[maxmilian]

@cla-bot check

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!