You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Safari: CJK IME composition is aborted mid-input in web app prompt input #38674
In the web app prompt input (packages/app/src/components/prompt-input.tsx), typing with a CJK IME in Safari gets cut off mid-composition: after a few keystrokes the half-composed text (raw pinyin / kana) is committed as plain text and the composition ends.
Root cause: the prompt input is a contenteditable that round-trips DOM -> state -> DOM on every input event (handleInput -> prompt.set(...) -> effect -> renderEditorWithCursor()). Safari aborts an active IME composition whenever the DOM or selection is mutated programmatically, and the existing guards don't hold there:
The effect guard if (composing()) return fails because Safari fires the first input event beforecompositionstart, so composing() is still false at that point (Chrome fires them in the opposite order).
The mirror.input flag only skips one write-back round; when isNormalizedEditor() is false (common mid-composition) renderEditorWithCursor() still rewrites the DOM.
Japanese IMEs that confirm bunsetsu-by-bunsetsu also fire compositionend + a new compositionstart mid-sentence; a rewrite landing in that gap cuts off the remaining segments the same way.
Related: #35746 covers the confirm-Enter mis-submit side. The same Safari event order breaks the isImeComposing guard in this input too: Safari fires compositionendbefore the confirming Enter keydown, so that event has isComposing === false and keyCode === 13 and none of the guard conditions match.
The standard approach (ProseMirror / CodeMirror / Lexical) is to freeze DOM->state->DOM syncing entirely during composition and do a single sync on compositionend. I have a patch for both problems and would like to submit a PR.
Plugins
No response
OpenCode version
v1.18.4 (code paths verified on main @ c9db6e9)
Steps to reproduce
Open the opencode web app in Safari on macOS.
Focus the prompt input and enable a Chinese pinyin or Japanese IME.
Type a long phrase continuously, e.g. zhongwenshurufaceshi or きょうはいいてんきですね.
The composition is aborted partway and half-composed text is committed. Pressing Enter to confirm a candidate also submits the message.
Not reproducible in Chrome (there compositionstart precedes the first input, and the confirming Enter keydown arrives with isComposing=true / keyCode=229 before compositionend).
Open a new browser tab pointing to the OpenCode web app.
Focus the v2 prompt input and enable the Chinese IME.
Start typing continuously.
Expected: Pinyin composes normally and can be confirmed.
Actual: All letters except the last one are committed as plain English characters immediately; only the final keystroke remains in the composition. Chrome on the same machine does not exhibit this.
Activity
anyingiit commentedon Aug 25, 2026
Environment
Reproduction
Expected: Pinyin composes normally and can be confirmed.
Actual: All letters except the last one are committed as plain English characters immediately; only the final keystroke remains in the composition. Chrome on the same machine does not exhibit this.
Tarquinen commentedon Oct 20, 2026
Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (
opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
fix(app): keep the composer editor inert during IME composition