[Bug] Web composer stuck in IME composition — Enter stops submitting, keystrokes duplicate (Windows + Microsoft Pinyin / 微软拼音)

[Af-080612]

Web composer can get permanently stuck in IME composition: Enter stops submitting and keystrokes produce duplicate/incorrect text

中文摘要（TL;DR）

Web 输入框的输入法（IME）组合状态会永久卡死。卡死后：

1. 回车无法发送消息，被直接吞掉；
2. 按一个键会产生多个效果（文字重复 / 插错位置）；
3. 拼音不能整词上屏，被拆成单个音节各自变成错字，还会残留英文字母
   （实测出现 你好t尼哈奥尼哈尼赫尼，同时输入法候选框仍开着）。

只有刷新页面或退出会话重进才能恢复。

疑似原因：dsh-client-ui-conversation 的 registerComposerKeymap 用一个闭包变量
composing 记录是否在组词，它只能由 compositionend 清除，没有任何兜底
（不超时、失焦也不清）。一旦该事件丢失，composing 永久为 true，回车处理里的
第一句 isComposingEvent(event, recentlyComposing) 就会把回车吞掉，其他按键也会
走组词分支。

环境：Windows 11 + 微软拼音 + @deepseek-ai/dsh@0.1.5-rc.1（Web 界面）。
录屏证据见本贴附件。

Summary

In the DSH Web UI, the message composer can enter a state where its IME
composition handling is permanently stuck in the "composing" state. While stuck:

• Enter no longer submits the message — it is silently swallowed.
• Ordinary keystrokes produce multiple / incorrect effects (duplicated text,
  text inserted at the wrong place).
• Pinyin is committed as isolated syllables mapped to wrong characters, and stray
  Latin letters are left in the draft (observed: 你好t尼哈奥尼哈尼赫尼).
• The state does not clear by itself. It only clears when the composer is
  rebuilt — reload the page, or leave the session and come back.

Environment

• DSH: @deepseek-ai/dsh@0.1.5-rc.1 (latest on npm at the time of writing),
  launched as npx @deepseek-ai/dsh@latest web
• OS: Windows 11
• Input method: Microsoft Pinyin (微软拼音) — the candidate list included the
  built-in kaomoji candidate \(@^0^@)/
• UI: DSH Web GUI at http://127.0.0.1:3080
• Affected package: @deepseek-ai/dsh-client-ui-conversation@0.1.5-rc.1
  (line numbers below are from the published lib/client.js bundle)

Steps to reproduce

1. Open the DSH Web UI and focus the message composer.
2. Type Chinese text with the IME.
3. Intermittently — during ordinary typing, with no session switch and no reload —
   the composer enters the stuck state.

So far the failure has been observed several times but is not yet deterministic.
It may be timing-dependent.

Actual behaviour

While stuck, the IME candidate window stays open, pinyin is not converted as a
whole word, and the committed text contains both wrong single characters and raw
Latin letters. Pressing Enter does nothing at all.

Evidence

A 9.7 s screen recording was captured by the reporter. 19 frames (2 fps) were
extracted and OCR'd with the Windows OCR engine (zh-Hans-CN).

The draft content was stable across many consecutive frames, i.e. it is
committed text, not a transient composition rendering:

你好t尼哈奥尼哈尼赫尼

A bare Latin t sits between Chinese characters, and hao appears split into
哈 (ha) + 奥 (ao) — the signature of a composition that was aborted
mid-word and then committed in fragments.

At the same time the IME candidate window held candidates for nihao:

1 你好   2 你号   3 似好   4 倪浩   5 \(@^0^@)/   6 你

The reporter's description of the failure:

• "回车发不出去" — Enter cannot send the message.
• "其他按键按下有多个效果" — other keys produce multiple effects.
• "退出重进又好了" — leaving the session and re-entering restores normal behaviour.

Suspected cause

There are two independent pieces of "is composing" state. Both are cleared only by
a compositionend event, and neither has any fallback.

1. DSH's own keymap flag

registerComposerKeymap in @deepseek-ai/dsh-client-ui-conversation/lib/client.js:

let composing = false;
let composingUntil = 0;
const onCompositionStart = () => {
  composing = true;
};
const onCompositionEnd = () => {
  composing = false;
  composingUntil = Date.now() + 10;
};
const recentlyComposing = () => composing || Date.now() < composingUntil;

registered on the editor root:

return Eu(editor.registerRootListener((root, prevRoot) => {
  prevRoot?.removeEventListener("compositionstart", onCompositionStart);
  prevRoot?.removeEventListener("compositionend", onCompositionEnd);
  root?.addEventListener("compositionstart", onCompositionStart);
  root?.addEventListener("compositionend", onCompositionEnd);
}), ...);

and the Enter command:

editor.registerCommand(cn$1, (event) => {
  if (event?.shiftKey === true) return false;
  if (event !== null && isComposingEvent(event, recentlyComposing)) return true;
  if (handlers.arbitrate("enter", false) !== "pass") { ... }
  ...
  handlers.submit(event?.ctrlKey === true || event?.metaKey === true);

https://github.com/user-attachments/assets/510422ce-fdbd-40b0-bb78-b3d2dd8ec954


  return true;
}, 4),

with:

function isComposingEvent(event, recentlyComposing) {
  return event.isComposing || event.keyCode === 229 || recentlyComposing();
}

composing is a closure variable cleared only by a compositionend delivered
on the current root element. If that event is never delivered, composing stays
true forever, and isComposingEvent(...) then returns true for every
key event (a plain Enter has isComposing === false and keyCode === 13, but the
recentlyComposing() term is stuck true). The Enter handler therefore returns
true — "handled" — without ever calling handlers.submit(). This matches
"Enter cannot send" exactly.

A compositionend can plausibly be lost when:

• the editor root is detached / re-attached mid-composition —
  ComposerContentEditable calls editor.setRootElement(null) in its effect
  cleanup, and the shell calls it in dispose();
• Lexical reconciles and replaces the composed text node while the composition is
  in flight;
• the composition otherwise ends without a finalize event on that root.

2. Lexical's internal composition state

The bundled Lexical core under the same file tracks composition itself
(compositionPhase, isComposing(), the insertCompositionText branch of the
beforeinput handler). A missed compositionend leaves that state stuck in the
same way, which routes subsequent beforeinput events through the composition
branch and explains the duplicated / mis-positioned insertions
("other keys produce multiple effects").

Suggested fix

• Clear composing on blur / focusout of the root, and whenever
  registerRootListener swaps the root element.
• Add a bounded fallback: clear composing if no composition-related event has
  been observed for N ms.
• Do not swallow Enter solely because recentlyComposing() is true. Prefer the
  per-event signals (event.isComposing, event.keyCode === 229) and use the
  sticky flag only for the documented Safari case it was added for.
• Review whether the editor root can ever be detached while a composition is in
  flight, and re-establish composition state if it can.

Workaround

Reload the page (F5) or leave the session and re-enter. Rebuilding the composer
clears the stuck state.

[Mide69]

Checked this against the current TypeScript source rather than the built lib/client.js bundle, and there is a real update to report: one of your two suspected causes has already been independently fixed on upstream master.

Commit eff482c (2026-09-09, "fix(web): stabilize composer command editing and scrolling") added almost exactly your suggested fix to packages/client/ui-conversation/src/client/input/editor/keymap.ts's registerRootListener callback:

prevRoot?.removeAttribute('data-composer-composing')
composing = false
composingUntil = 0
rootElement = root

So a root swap while composing is in flight, which you flagged as one plausible trigger (editor.setRootElement(null) during detach/reattach), now resets the closure flag instead of leaving it stuck forever. This landed after 0.1.5-rc.1, the version you tested, so it is worth re-testing against a later build once one is available, since this half of your diagnosis may already be gone.

Your second suspected cause is still open though. The same commit added editor.isComposing() into a new syncComposition() helper, but only to drive a CSS attribute (data-composer-composing, for placeholder suppression per the updated doc comment). recentlyComposing() and isComposingEvent() still only read the local composing and composingUntil closure variables, never editor.isComposing(). So if Lexical's own internal composition state gets stuck without a matching compositionend on the tracked root, for example your cause 2, or any compositionend loss that is not a root swap, composing still has no fallback. There is no blur or focusout listener and no bounded timeout beyond the existing 10ms post-compositionend window. Your suggested fixes 2 and 3, a bounded timeout fallback and not swallowing Enter solely on the sticky flag, are both still fully applicable.

Good root causing from an OCR'd screen recording. That is a hard bug to pin down from a report alone.