[Bug] Web composer: IME composition leaks un-typed characters (0.1.5-rc.3, Windows + Microsoft Pinyin)

[mingyu-qiaoqiao]

dsh-composer-ime-bug-report.docx
dsh-composer-ime-probe.docx

[PerryLink]

这是第三个输入法组字报告了——所以我先把共性与已核实的事实给你，再说怎么让这条被处理

1. 已核实的事实（对三个报告都成立）

客户端里与输入法有关的代码只有一处：packages/client/ui-conversation/src/client/input/editor/keymap.ts 的按键守卫，它的职责是——"a composition-closing Enter/Space must not submit or adjudicate"：监听根元素的 compositionstart / compositionend，在 compositionend 之后再多保持 10ms 守卫（对付 Safari 迟到的那次 keydown），并把 keyCode 229 当作引擎在没有 isComposing 时发出的传统组字信号。

同时：发布出去的客户端里没有 beforeinput / insertCompositionText 的处理（0 命中，只有测试里的一句注释）。⇒ 组字期间的文本插入由浏览器原生完成，DSH 既不拦截也不重写。

所以"未上屏的字符泄漏到了输入框里"这种表现，最可能是引擎/编辑器在组字未结束时就把内容提交或同步进了文档，而不是 DSH 主动写入了什么。

2. 一个必须指出的对比（也是这条报告的难点）

:6552 那位同学用埋点把问题钉死在了"跨段落组字导致 DOM 重建、作废 composing region"上；而你这台的输入法是微软拼音 + Windows（他那台是 Android WebView + 微信输入法）。同一症状、不同引擎，说明这可能不是单一场景，而是"组字期间编辑器仍然在同步文档"这一类问题的不同表现。你的报告如果能量化"泄漏的字符是什么"（是拼音串？还是候选词？还是重复的已上屏文本？），就能立刻区分：

• 泄漏的是拼音串（如 nihao）⇒ 组字区被当成普通文本提交了；
• 泄漏的是候选词但顺序错乱/重复 ⇒ 是提交时机与文档同步打架；
• 泄漏的是重复的已上屏文本 ⇒ 更像 DOM 重建后的回填。

3. ⚠️ 一个真实的可读性障碍：附件是 .docx

你附了 dsh-composer-ime-bug-report.docx 和 dsh-composer-ime-probe.docx。维护者通常不会去下载并打开 docx：正文无法被搜索、无法被引用、也无法在 issue 里被逐行讨论。

建议把关键内容直接贴进正文（或贴到一个 gist/仓库再链接），至少包含：

1. 复现步骤（哪几个键、什么顺序）；
2. 那份 probe 的原始事件序列（compositionstart / beforeinput / input / compositionend 的 data 与顺序）——这才是决定性的证据；
3. dsh --version。

这不是格式挑剔：#6552 之所以能被定位，就是因为它把埋点数据贴在了正文里。

4. 版本提醒（这条对你特别重要）

你写的是 0.1.5-rc.3——请注意，0.1.5-rc.3 正是 npm 上 latest 的版本，而真正最新的是 next = 0.1.7-rc.2：

dsh --version                       # 先确认你现在到底在哪一版
npm i -g @deepseek-ai/dsh@next      # 当前最新 = 0.1.7-rc.2

如果你当初是不带 tag 安装的，那就正好落在 latest（旧版）上。0.1.5-rc.3 → 0.1.7-rc.2 之间输入框所在的包改动很多（alpha.1 → alpha.2 就有 162 个提交），所以先升级再复现能省掉一整轮排查——如果升级后不再出现，这条就可以结掉。

5. 建议的报告结构

"引擎 + 输入法版本 → 最小按键序列 → probe 事件序列（正文）→ 期望/实际 → 版本"。这样它与 #6552 就能被并列比较，维护者一次就能看出是不是同一族。