Web UI: typing Chinese with IME garbles text, but pasting works

[3418638729]

Environment

dsh: 0.1.2-rc.1 (latest on npm) - Windows 11 - Edge/Chrome - Microsoft Pinyin IME

Problem

Typing Chinese in the web UI garbles the text - e.g. typing 你好 produces fragmented/garbled characters. But Ctrl+V pasting the same Chinese displays correctly.

Root cause (from DOM inspection)

The input is a single controlled contenteditable (no input/textarea/iframe/canvas on page). Typed CJK appears to be committed character-by-character: during IME composition each key resets the content via the controlled state, so composition never completes cleanly. Pasting bypasses composition, hence it works.

Suggested fix

Handle IME composition events (onCompositionStart/Update/End) in the input component - do not rewrite content mid-composition and commit the full text on compositionend.

Workaround for affected users

A bookmarklet that types into a native textarea and injects the result (equivalent to a paste) into the contenteditable works reliably. Happy to share it.

[3418638729]

For anyone hitting this on Windows with Microsoft Pinyin, a reliable workaround while the IME handling gets fixed:

1. Create a bookmark (Ctrl+D), name it e.g. CN.
2. Paste the following into the bookmark's URL field (must start with javascript:):

javascript:(function(){var b=document.getElementById('dshCni');if(b){b.remove();return}var x=document.createElement('textarea');x.id='dshCni';x.style.cssText='position:fixed;left:8px;bottom:8px;z-index:2147483647;width:320px;height:100px;font:15px/1.4 sans-serif;background:#111;color:#0f0;border:1px solid #2a2;border-radius:6px;padding:6px;resize:both';x.placeholder='[CN] type Chinese, then press Enter';x.addEventListener('keydown',function(e){if(e.key==='Enter'&&!e.shiftKey){e.preventDefault();var v=(x.value||'').trim();if(!v){return}var ed=document.querySelector('[contenteditable="true"]');if(ed){ed.focus();try{document.execCommand('insertText',false,v)}catch(err){ed.textContent=v}}x.value='';x.focus()}});document.body.appendChild(x);x.focus()})();

3. Open the DSH web UI, click the bookmark, type Chinese in the small box, press Enter (text is inserted into the main input), then click Send. Click the bookmark again to close it; re-click after any page refresh.

The bookmarklet types in a native textarea and injects the text via execCommand insertText, which is equivalent to pasting - and pasting is confirmed to work. So it cleanly avoids the broken IME composition path.

[argszero]

Thanks for the detailed report + reproduction, and for the bookmarklet workaround. One architecture note that changes the diagnosis slightly, then the discriminating question.

The composer is not a naive controlled contenteditable — it's a Lexical rich-text editor. The editable surface (ComposerContentEditable.tsx) just binds a Lexical editor to the div; text mutation and composition are owned by @lexical/plain-text (via registerPlainText) wired through packages/client/ui-conversation/src/client/input/facade.ts. The "each key resets content via controlled state" pattern isn't what I see in the source: the draft persistence mirror (bindMirror) is one-directional (editor → store), and setDraft (store → editor) is only invoked on mount seed, not on every keystroke. So a composition-in-progress shouldn't be blown away by a store writeback.

IME handling is explicitly guarded and has dedicated tests. In input/editor/keymap.ts the composition watch (compositionstart/compositionend via a root listener, plus the keyCode === 229 legacy signal) prevents the composition-closing Enter/Space from submitting or adjudicating. input-bar.client.spec.tsx covers exactly these paths:

• "composition Enter never sends: ref guard, isComposing, and keyCode 229 paths"
• "Shift+Enter newline wins even inside IME composition"

So if the symptom is real on 0.1.2-rc.1, the more likely culprit than "controlled reset" is an interaction between a specific Lexical version and the IME's composition events (e.g. an update tag / $addUpdateTag during composition, or an update() landing mid-composition). That's a real bug class and worth fixing at the editor layer, but it isn't the controlled-contenteditable reset described.

Discriminating question that would localize it fast: does the garbling reproduce on current master / 0.1.3-alpha.1, or only on 0.1.2-rc.1? The textarea → Lexical composer refactor landed 2026-08-20 (b519cb87b0, three weeks before rc.1 was published). If it's gone on alpha, it's a shipped-rc.1 regression in that window; if it's still there, it's a live Lexical+IME interaction we can repro in-tree and fix. A quick npm view @deepseek-ai/dsh dist-tags check or running the alpha would tell us in a minute.

The bookmarklet is a solid stopgap — and pasting working while typing garbles is itself a strong signal: paste bypasses composition, so the fault is almost certainly in the composition event path (Lexical/beforeinput handling) rather than the projection/serialization layer.

[3418638729]

@argszero

Thanks for the detailed reply and the architecture correction — my "controlled contenteditable" framing was off.

I tried running the discriminating check you suggested, but the alpha channel is broken on the publishing side, so the test can't be reached the way you intended:

• dsh@0.1.3-alpha.2 (the current alpha tag) fails to install with ETARGET — it depends on @deepseek-ai/dsh-agent-tool-presentation@^0.1.3-alpha.2, which was never published. Same result via npx.
• Even if that dependency were fixed, the composer frontend @deepseek-ai/dsh-client-ui-conversation only has 0.1.2-alpha.5 on the alpha tag — older than the 0.1.2-rc.1 I'm currently on. So no published alpha build would carry a composer newer than mine.

For what it's worth, the published rc.1 and 0.1.3-alpha.2 bundles show a byte-identical Lexical vendor chunk and unchanged composition tokens (compositionend/compositionstart) — consistent with the composer not being re-released.

So across every installable version the garbling reproduces, which points to the live Lexical+IME interaction bug rather than an rc.1 regression. That said, I can only conclude this from published artifacts — I haven't actually typed on a newer composer.

If you can ship the newer composer to an installable channel (or point me to a master build), I'll run the real typing test and report back. Until then, the bookmarklet remains my workaround.