输入法组词提交带尾随空行时，消息在未按发送键的情况下被发出（安卓 + 微信输入法语音）

[notonlybutals]

EN (TL;DR): On Android + WeChat IME voice input (auto-formatting on), the IME commits its composition with a trailing \n\n. DSH then submits api/session/prompt in the same synchronous flow — no keydown, no click, no beforeinput, no submit — and the message is sent half-complete, without the user pressing send.

环境：DSH Desktop 0.2.2-rc.1（Windows x64，官方 Desktop）+ 安卓手机浏览器经局域网访问（dsh-mobile 插件提供的移动页）+ 微信输入法语音输入（自动整理开启）。

现象

微信输入法语音"整理"结束时，会用 compositionend.data 尾部的 \n\n 表示"这句话说完了"。DSH 在组词提交的同一个同步流程内就发出了 api/session/prompt：用户没按发送键，消息被发出且只发出前半句，剩下的部分留在输入框里变成下一条消息。

分点、加分号时最容易触发（输入法更爱在那里插空行）。结果是模型收到半句话。

实测事件序列（页面内 capture 监听采集）

04:28:18  INPUT len=18 tail="已经是不知道第多少次测试了：" it=insertCompositionText
04:28:18  COMP END "好，现在已经是不知道第多少次测试了：\n\n"        <- 组词数据尾部双换行
04:28:18  FETCH api/session/prompt body={"type":"client-request","rpcId":"0892f8ad-...","method"...
04:28:18  FETCH STACK at window.fetch (/plugins/...:73432:28)
               << at Object.call (/plugins/...:50051:29)
               << at Proxy.invoke (/mobile-access/mobile-boot/<hash>.js:1826:42)
04:28:19  CLEARED was=18                                             <- 草稿被清空

关键观察

1. 提交前后没有 keydown（含 Enter / keyCode 13 / 229）、没有 click、没有 beforeinput、没有 submit。链路只有 insertCompositionText -> compositionend -> 提交。
2. 输入框文本长度是 18，从来没包含那两个换行；\n\n 只存在于 compositionend 的 data 里。
3. 因此提交判断发生在组词提交的同步流程内，触发线索是提交数据尾部的空行。
4. 过程中 insertCompositionText 的 data 会反复出现整段历史文本（云端整理整体重写草稿），草稿长度曾出现 67 -> 6 的跳变。

影响

任何"用尾部空行表示句子结束"的输入法都会触发（中文语音输入是主流输入方式）。误发直接破坏消息完整性，且用户会以为是网络或模型问题。

临时规避

关闭输入法的"自动整理 / 智能标点 / 自动分段"。关闭后同样话术不再触发（已复现 15+ 次，关闭后 0 次）。

交叉引用

移动层的同类报告（含现有 Enter 守卫为何覆盖不到这个场景）：
saya-ch/dsh-mobile#414

那边已经在本仓之外加了组词路径的处理建议，但根因在 composer 的提交判断，仍需本体侧决定是否把 compositionend.data 的尾部空行当作提交信号。

[PerryLink]

内核的 composer 没有 compositionend 直接提交这条路。

提交只有两条：keydown Enter（有 IME 守卫：packages/client/ui-conversation/src/client/input/editor/keymap.ts:10-17 的 isComposing/229/10ms 窗口）和发送按钮。git grep -n "compositionend" e8f7b93a -- 'packages/client' 只命中 shortcuts/dom.ts、ui-approval、keymap 的守卫，没有提交逻辑。

你的事件序列里也没有 keydown/click，而 fetch 栈落在 mobile-boot/<hash>.js，所以提交来自 dsh-mobile 那条移动页链路，不在本仓。带去他们的 issue 是对的；如果他们说自己只是复用内核 composer，让他们贴出提交调用点。

我读的是 master 的 client 代码，没跑安卓 + 微信输入法。
这段可以直接给 AI，让它把内核与插件的提交路径分开。
如果这条对你有用，可以标成 answer，后面遇到输入法误发的人更容易找到。

[notonlybutals]

感谢核对。这里贴两处代码，可能正好是 grep 没覆盖到的那一环。

先对齐结论：提交确实不是从 compositionend 直接发生的，所以在 packages/client 里 grep 不到 submit 逻辑是对的。问题是 Lexical 会把"组词尾字符是换行"转成一条 Enter 命令，而 keymap 的 Enter 处理器把 event === null 当成了真实按键。

① 打包进来的 Lexical：to()（compositionend 的收尾函数）

if ("\n" === e[e.length - 1]) {
  const e = Kr();
  if (ur(e) || dr(e)) {
    ...
    return Nl(t, cn$1, null), ...   // 派发 ENTER_COMMAND，event 参数是 null
  }
}

② packages/client/ui-conversation/src/client/input/editor/keymap.ts 的 Enter 处理器

editor.registerCommand(cn$1, (event) => {
  if (event !== null && (event.altKey || event.getModifierState("AltGraph")
      || event.ctrlKey && event.metaKey
      || event.shiftKey && (event.ctrlKey || event.metaKey))) return true;
  if (event?.shiftKey === true) return false;
  if (event !== null && isComposingEvent(event, recentlyComposing)) return true;  // ← event === null 时整条跳过
  if (handlers.arbitrate("enter", false) !== "pass") { event?.preventDefault(); return true; }
  event?.preventDefault();
  if (event?.repeat === true) return true;
  if (!handlers.canSubmit()) return true;
  handlers.submit(event?.ctrlKey === true || event?.metaKey === true);            // ← 提交
}, 4)

event === null 时，组词守卫（isComposing / keyCode 229 / 10ms 窗口）全部被短路，直接走到 handlers.submit()。

行为侧完全吻合：现场日志里提交前后没有任何 keydown / click / beforeinput / submit，且提交发生在组词文本插入完成之前 —— 所以只发出前半句、后半句留在输入框。安卓 + 微信输入法语音"自动整理"（compositionend.data 尾部放 \n\n）稳定复现 15+ 次，关闭自动整理后 0 次。

最小修复建议（与插件作者一致）：cn$1 在 event === null 时不要 submit，退回普通换行；或者 to() 在该情形不派发 Enter 命令。回归测试：compositionend.data 以 \n\n 结尾时不发送、真实 keydown Enter 仍然发送。

所以这条还不是 answer，麻烦先别标 —— 标了以后遇到同样问题的人会顺着"插件侧提交"这个方向排查，反而绕远。插件作者那边已确认无法安全止血：saya-ch/dsh-mobile#414 (comment)

[PerryLink]

我上一条说错了：提交就在内核的 Enter 处理器里。

packages/client/ui-conversation/src/client/input/editor/keymap.ts:265 的守卫是 if (event !== null && isComposingEvent(...))——event === null 时整条跳过，随后 :279 直接 handlers.submit(...)。Lexical 在组词以换行结尾时正是用 event = null 派发 ENTER_COMMAND，所以你贴的 to() 那条路径成立。我上一条只 grep 了 compositionend，漏了 null event 这条路。

修法：把 event === null 也当作“不是真实按键”，在 recentlyComposing 窗口内直接 return true；或让那条 to() 不派发 Enter。第一处改动最小。影响不只安卓——任何在 compositionend 里以换行收尾的输入法都会中，且 null event 上 preventDefault 本来也无处可用。

我读的是 master 39163dd3 的 keymap，没有逐行核对打包的 Lexical；你贴的那段我接受。

这段可以直接给 AI，让它在 keymap 里补 null event 分支并加回归。
如果这条解决了你的问题，可以标成 answer，后面遇到输入法误发的人更容易找到。