macOS accent popup inserts both the base letter and the selected accented character

[ilya-sarantsev]

Pre-submit Checks

• I have searched Warp bugs and there are no duplicates
• I have searched Warp known issues page and my issue is not there
• I have an issue with AI and have included the debugging ID (Optional, but helps expedite the AI quality fix). Debugging ID instructions
• I have technical issue and have included the logs (optional, but helps expedite the bug fix). Log instructions

Describe the bug

When holding a key that has accented variants (e.g. u, o, a), Warp correctly
shows the macOS press-and-hold accent popup. However, after selecting an accented
character from the popup, Warp inserts BOTH the base character and the selected
accented character, instead of just the accented one.

Example: holding o and selecting ö from the popup results in oö being typed,
not just ö

To reproduce

1. In a Warp prompt, press and hold a letter key that has accent variants (e.g. o)
2. Wait for the macOS accent popup to appear
3. Select an accented variant from the popup (click it or press its number key)
4. Observe the text that gets inserted

Expected behavior

Only the selected accented character should be inserted (e.g. ö), overriding the
base character, matching the behavior in Terminal.app

Screenshots, videos, and logs

Screen.Recording.2026-07-13.at.07.53.27.mov

Operating system (OS)

macOS

Operating system and version

26.6 Beta (25G5057c)

Shell Version

zsh 5.9 (arm64-apple-darwin25.0)

Current Warp version

v0.2026.07.08.17.54.stable_02

Regression

No, this bug or issue has existed throughout my experience using Warp

Recent working Warp date

No response

Additional context

Might be related to #3191

macOS built-in Terminal.app is fine. Ghostty has another issue (ghostty-org/ghostty#10669)

Does this block you from using Warp daily?

Yes, this issue prevents me from using Warp daily.

Is this an issue only in Warp?

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

Warp Internal (ignore): linear-label:b9d78064-c89e-4973-b153-5178a31ee54e

None

[oz-for-oss]

@ilya-sarantsev

Here's what I found while triaging this issue:

Thanks for the detailed repro steps and video. This looks like a macOS-specific Warp text-input issue where the native accent selector commits the selected accented character after Warp has already accepted the held base letter; related accent/key-repeat issues exist in #3191 and #2453, but this double-insertion symptom appears distinct.

Maintainer details

I concluded that macOS press-and-hold accent selection inserts both the held base letter and the selected accented character in Warp terminal input..

Triage summary

This is a macOS-specific terminal input bug: selecting a character from the native press-and-hold accent popup inserts both the held base letter and the selected accented character. The reporter supplied direct repro steps, Warp stable version v0.2026.07.08.17.54.stable_02, macOS 26.6 Beta, zsh version, and video evidence; Terminal.app reportedly behaves correctly.

Duplicate check

I found related historical issues #3191 and #2453 around macOS accent/key-repeat behavior, but they do not describe this specific double-insertion-after-selection symptom. Because the dedupe workflow requires at least two likely duplicate matches, this should not be marked duplicate from the current evidence.

Likely implementation area

The most relevant path is the macOS text input bridge. crates/warpui/src/platform/mac/objc/host_view.m implements NSTextInputClient: keyDownImpl: calls interpretKeyEvents:, batches insertText:replacementRange: output into textToInsert, dispatches the raw key through warp_handle_view_event, and then forwards the batched text as TypedCharacters if the raw key was not handled. crates/warpui/src/platform/mac/window.rs forwards that text to Warp events, and app/src/terminal/view.rs / app/src/terminal/input.rs insert it into the command input.

A plausible failure mode is that the initial held key (for example o) is accepted as ordinary typed input before the native accent popup commits the selected replacement character (ö), so both commits reach terminal input as oö. The next implementation step should be to reproduce on macOS with press-and-hold enabled and inspect the sequence of keyDown:, insertText:replacementRange:, marked-text callbacks, and terminal TypedCharacters dispatches when the accent picker selection occurs.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz