Pre-submit Checks

• I have searched Warp bugs and there are no exact duplicates (related issues linked below)
• I have searched Warp known issues page and my issue is not there

Describe the bug

On macOS, when using 超注音 (Yahoo Bopomofo / 極限注音) — a widely used third-party Traditional Chinese input method in Taiwan — pressing the right or left arrow key during candidate selection advances the highlighted candidate by 2 positions instead of 1. This makes it impossible to land on even-indexed candidates (#2, #4, #6, …) via arrow keys.

The bug does not occur with macOS built-in 注音 (Apple Bopomofo) or Apple Pinyin. It does not reproduce in Terminal.app, iTerm2, Ghostty, or VS Code's integrated terminal — only in Warp.

To reproduce

1. macOS, install 超注音 (Yahoo Bopomofo) — free third-party IM, https://tw.yahoo.com/超注音
2. In Warp, switch input source to 超注音
3. Type a Bopomofo combination with many candidates, e.g. ㄅㄨˋ (yields 不 / 把 / 被 / 補 / 版 / 堡 / …)
4. Candidate window appears with 1不 highlighted
5. Press right arrow once
6. Observed: highlight jumps from 1不 to 3被 (skips 2把)
7. Continue pressing right: 3被 → 5版 → 7表 → … (always advances by 2)

Number-key selection (1–9) works correctly as a workaround, but arrow-key navigation is broken.

Expected behavior

Right arrow advances candidate selection by 1 position, matching behavior in Terminal.app, iTerm2, Ghostty, and every other macOS app.

Screenshots, videos, and logs

Screen recording showing the candidate index jumping by 2 on each right-arrow press. Sequence: 1不 → 3被 (skipped 2把) → 5版 (skipped 4補).

Candidate row layout: 1不 2把 3被 4補 5版 6堡 7表 8ㄅ 9並 …

Operating system (OS)

macOS

Operating system and version

macOS 26.4.1 (25E253)

Shell Version

zsh 5.9

Current Warp version

0.2026.04.27.15.32.03

Regression

No, this bug has existed throughout my experience using Warp.

Recent working Warp date

N/A

Additional context

Suspected root cause

The bug appears to originate in keyDownImpl in crates/warpui/src/platform/mac/objc/host_view.m, where every keyDown event is dispatched through two parallel paths:

- (BOOL)keyDownImpl:(NSEvent *)event {
    BOOL wasComposing = [self hasMarkedText];
    [textToInsert setString:@""];

    interpretingKeyEvents = YES;
    [self interpretKeyEvents:[NSArray arrayWithObject:event]];   // path 1: AppKit IME (NSTextInputClient)
    interpretingKeyEvents = NO;

    BOOL handled = NO;
    if (self.readyForWarp) {
        handled = warp_handle_view_event(self, event,
                                         wasComposing || [self hasMarkedText]);  // path 2: Rust / winit
    }
    ...
}

Most macOS IMEs render their candidate UI through the standard IMKCandidates panel (a separate NSPanel owned by the input method server), so they only consume events arriving through path 1. 超注音 hooks deeper into the input context and observes key events through path 2 as well — so the right-arrow event reaches its internal candidate index twice, advancing it by 2.

This may also explain the long-standing #2335 (macOS Chinese candidate window misbehavior, open since 2022) and #9145 (Japanese IME popup misalignment in TUI apps): different surface symptoms (popup positioning vs. event double-counting) but plausibly the same root — inadequate isolation between the two key-event paths during IME composition on macOS.

Suggested fix

When wasComposing || [self hasMarkedText] is YES and the keycode corresponds to an arrow / page-navigation key, skip warp_handle_view_event (or have the Rust side early-return when the composing flag is set). This matches the contract Terminal.app and iTerm2 follow via standard NSTextInputClient delegation: while the IME is composing, the host should not act on navigation keys independently.

Related issues

• The problem of not being able to follow when inputting Chinese #2335 — macOS: candidate window doesn't follow cursor (open since 2022)
• Japanese IME conversion candidates popup is misaligned from cursor/input line #9145 — macOS: Japanese IME conversion candidates popup misaligned (TUI-specific)
• Warp's Windows input layer does not implement the capture and rendering of IME pre-edited strings, making the "intermediate state" of Pinyin input invisible to the user. #9012 — Windows: pre-edit string not visible (Windows-specific, but same family of IME-path bugs)
• Instructions on warp's support for Chinese #9357 — Tracking issue for Chinese support layers

Willing to PR

I'm willing to send a PR for this. Would appreciate maintainer confirmation of the suggested fix direction (early-return on path 2 during composition for navigation keys) before opening one.

Does this block you from using Warp daily?

No (number-key selection works as a workaround, but arrow-key navigation flow is broken)

Is this an issue only in Warp?

Yes, I confirmed that this only happens in Warp, not other terminals.