The following comment was made by an LLM, it may be inaccurate:

Data point from a WKWebView host, on the released 2.0.32 — still reproducible, and your event-order diagnosis is the one that matches.

I maintain a macOS Tauri app that embeds the web UI in native child webviews. A user typing a pinyin prompt and pressing Enter to confirm the candidate sent the message, and the message body carried the raw pinyin (wenti) instead of the chosen characters — one keystroke did both jobs. Adding to your trace: whether the closing keydown carries keyCode 229 or 13, the composer never consults it — both paths read isComposing alone, which is false by then.

I checked the shipped bundle rather than the sources: the composer in incompatible-server-panel-*.js still has t.key === "Enter" && !t.shiftKey && !t.isComposing, and the key.down dispatch still passes composing: t.isComposing, so both fall through to submit(). Your imeComposing() covers exactly this.

Because the page is not ours, we had to patch the engine view from the host for now: a document-start script redefines KeyboardEvent.prototype.isComposing as native || keyCode === 229 || Date.now() - lastCompositionEnd <= 10. Measured in a bare WKWebView: without it {plain:false, legacy:false, closing:false}, with it {plain:false, legacy:true, closing:true}, and false again 50 ms after compositionend. That is a stopgap, not an argument about where the fix belongs — it belongs here.

One question about the 100 ms window: the typematic minimum is ~30 ms, so a user who commits a candidate and immediately presses Enter to send can land inside the window and have the send ignored. We used 10 ms, which only has to outlive WebKit's runloop turn. If 100 ms comes from a measured input method, which one? If it is headroom rather than a measurement, a shorter window (or scoping it to Enter/Tab handling only) would keep that second Enter working.

On testing: this does not need a real IME. Dispatching compositionend on the editor and then a keydown Enter whose isComposing is false reproduces the Safari shape in a WebKit runner, and would fail against the current guard.

Thanks @yusiwen — the WKWebView trace and the {plain/legacy/closing} measurements are exactly the evidence this needed, and you're right about the window.

On the 100 ms: it was inherited as-is from the V1 fix (#44826), which I had only verified with Chinese IMEs — headroom, not a measurement. I've now re-tested the guard by driving the actual composer controller with synthetic composition/keyboard events (zh pinyin, ja, ko sequences, plus typematic-speed follow-ups), and 10 ms covers the compositionend→keydown runloop turn while leaving a fast second Enter intact. Your measured 10 ms is now the window.

Pushed a revision addressing all three inline concerns:

1. The confirm window is scoped to Enter/Tab only (10 ms; keyCode 229 consulted for those keys only) — Escape/arrows/Ctrl+G right after compositionend, and Android soft keyboards reporting 229 on most keys, are no longer affected.
2. onInput is now gated only while a composition is genuinely in flight (isComposing or the active composition flag) — the same-keystroke character Korean IMEs insert after compositionend reaches the store.
3. The two machine tests are dropped (they did pass on base — machine.ts already guarded Enter while composing). Replaced with editor-level regression tests in test-browser/composer-ime.test.ts that encode exactly the synthetic repro you described: compositionend → keydown Enter with isComposing=false stays inert, Enter at +35 ms submits, post-compositionend input is stored, non-confirm keys and Android 229 keys pass through. They fail against the previous revision and pass now.

Verified locally this time: bun test (test:unit + test:browser) and tsgo typecheck on the branch.

Done — cut to three cases, no wall-clock. The guard reads performance.now on purpose (the event clock can't be trusted here), so the tests pin it directly instead of sleeping; each fails against the previous revision. Kept them at controller level rather than mounting ComposerEditor: the editor handlers are one-line pass-throughs consulting these guards, and mounting the component in happy-dom would need the full app context tree for no extra signal.

On the recording: the machine-observable behavior is now covered by the deterministic tests above, and the released-build behavior was already traced end-to-end on real IMEs in @yusiwen's WKWebView measurements. Happy to add a recording if a maintainer feels it's still needed.

Data point: same root cause on Android (non-CJK IME) — word suggestions/autocorrect never appear

Environment

• opencode 2.1.2, v2 web UI served by the background service (Linux server)
• Client: Brave 1.97.59 (Chromium 155.0.8059.85) on Android
• Keyboard: HeliBoard (ru). Normal composer mode, plain Russian text, no mentions/slash commands

Symptom

Typing works, but the keyboard never shows its word suggestions and never autocorrects in the composer. The same keyboard does show suggestions in a plain <textarea> and in a bare <div contenteditable> (MDN live examples) in the same browser, same session.

Checked, not the cause

• The 2.1.2 bundle does set spellcheck=true, autocorrect=on, autocapitalize=sentences on [data-component="composer-editor"] in normal mode, so missing attributes are not it.
• On Android Chrome/Brave has no built-in dictionary: suggestions come from the IME, so html lang="en" / a missing lang on the editor is not it either.
• The field is focused and editable (text lands), so it is not the "keyboard does not attach" case.

Hypothesis = what this PR fixes

Each composition keystroke triggers onInput -> state write -> the render effect. localInput is a one-shot flag, so the second update inside one composition reaches renderComposerEditor -> replaceChildren, which aborts the composition and resets the IME candidate/suggestion state. Per-keystroke keydown/keyup dispatch and selection sync in interaction.ts do the same.

Ask

• Could you confirm whether the inert-during-composition guard also restores IME word suggestions on Android (HeliBoard/Gboard), and not only CJK candidate windows?
• I can test a build on a physical Android device (Brave + HeliBoard) and report back; the setup is reproducible on request.

Related: #57740 (Gboard voice typing blocked in the same composer), #39632, #49448, #38674

Thanks @khativari — yes, this is within the intended scope of the fix. The guard is not CJK-specific: it follows the browser's composition lifecycle and keeps the editor inert for any active IME composition.

If HeliBoard/Gboard maintains a composing region for the current word, this PR now avoids the operations that can reset it: the per-composition onInput state write, key dispatch, cursor/selection sync, and renderComposerEditor(...).replaceChildren(). State is reconciled once at compositionend. So I expect word suggestions/autocorrect to recover, but I can't honestly call that confirmed without a physical Android test.

Testing the current PR head (60fc0c4) with Brave + HeliBoard would be very helpful; Gboard too if available. The useful checks would be:

• suggestions remain visible while typing a word;
• selecting a suggestion replaces the complete word;
• autocorrect on Space works;
• Enter and Backspace still behave normally.

If it still fails, an event trace for one word containing compositionstart, compositionend, inputType, and isComposing would show which Android path is not covered. If you need a prebuilt artifact rather than building the PR branch, let me know which target you need. Thanks for offering to test this.