[Bug] 安卓语音输入：输入法组字里带换行时，输入框只落地一部分文本（首段整段丢失）

[chenshi723]

环境

项	值
DSH	0.1.5-rc.2（Web GUI）
设备	vivo iPA2475 / Android 16
承载	App 内置 Android WebView
输入法	微信输入法 3.5.0，语音输入 + 「AI 整理」

现象

用语音说一段话，等输入法「AI 整理」完成后，输入框里的文本会比整理版少一整段：

• 整理版是两行（例如「1. …」换行「2. …」）时，第一行整行消失，只剩第二行；
• 主观感受就是"整理完刚进框，立马又被删了一截"。

说明：输入法把口述重写、压缩是它自己的功能，不算 bug。这里只针对整理后的文本没有完整落地。

复现步骤

1. 安卓 + 微信输入法，开着语音输入的「AI 整理」；
2. 在 Web 输入框里用语音说一段有并列条理、能被整理成"带编号/换行"的长句（比如提两条要求）；
3. 说完停顿，等它整理；
4. 观察输入框：整理版的第一行可能整体消失。

关键证据（客户端埋点：composition / beforeinput / input + DOM 变更）

一次典型现场（t 是页面内相对毫秒）：

t=223457  comp-update   d=58  "1. 把那个长文按钮去掉吧，太别扭了。\n2. 把哨兵挂在后台监督着我。万一有这种…"
t=223457  beforeinput   insertCompositionText  d=58
t=223484  charData      -66   文本节点 105 → 39        ← 首段「1. …」整行没有落地
t=223486  node-/node+   SPAN、P、BR 增删（编辑器重建该处 DOM）
t=223498  input         insertCompositionText  d=58  ×3
t=223498  comp-end      d=41  "2. 把哨兵挂在后台监督着我。…\n"   ← 输入法最终声明的也只剩第二行

同一次口述里，输入法先后声明的组字文本是：d=105（未整理原文）→ d=58（整理版，两行）→ d=41（只剩第二行）。
输入法声明的组字文本里有换行，而落进编辑器的只剩换行之后那一段。

对照组：

• 组字不含换行时，编辑器里的文本和输入法声明的文本差值 ≤2 字（通常只是尾部空白），一切正常；
• 同一录制窗口里 9 次"输入框被清空"，逐条和会话记录比对，9 次全部对应用户按下发送——所以不是编辑器在乱清空。

定位

• 触发条件是"一次组字里带换行"（contenteditable 里换行 = 新 block 元素）：此时实际落地文本比输入法声明的少一整个首段，同时编辑器重建了该处 DOM；
• 推测是 Android WebView/Chromium 对 insertCompositionText 组字区跨段落的边界处理，与编辑器的 DOM 重建叠加导致的；
• 对比 npm 上 0.1.2-rc.1 / 0.1.3-alpha.2 / 0.1.5-alpha.1 / 0.1.5-rc.2 四个版本的输入框实现，都是同一个富文本编辑器。所以这不是新版回归，是一个一直存在的老问题，只是被输入法的新功能（会把口述整理成多行/带编号）第一次踩出来。

期望行为

compositionend 之后，这一段的实际文本不应该少于输入法在 compositionupdate / compositionend 里声明的文本。

建议的修复方向

1. compositionend 后做一次完整性校验：拿输入法声明过的文本与该段实际文本比对；如果声明文本更长、且实际文本是它的连续子串，就按声明文本用受控插入补全（不要重新进入组字）；
2. 或者在 beforeinput（insertCompositionText）检测到 data 含 \n 时，别让组字区跨段落推进（例如先把整段落进单个 block，再由编辑器自行拆段）；
3. 回归用例建议：Android WebView + 中文输入法语音输入，构造"一次组字带换行/编号"的输入，断言最终文本包含组字声明文本的首段。

附：我这边做的临时缓解（没有改宿主代码）

在客户端注入一段只读监听 + 静默修补脚本：组字期间记录输入法声明过的每一版文本；compositionend 之后如果框里该段文本是其中某一版的连续子串、而且更短，就按那一版补全（只补不删，措辞变化一律尊重输入法的整理结果）。这能消除现象，但它属于事后修补，根治还是要在编辑器层做。

[PerryLink]

你的埋点已经把根因指出来了：首段是在输入法/WebView 那一层就没送出来

先说你这份 trace 里最关键、但可能被忽略的一处：comp-end d=41。输入法在 compositionend 里自己声明的组字文本就已经只剩第二行（41 字），而同一次口述它前面声明过 d=105 → d=58（两行）。再加上 t=223484 charData -66（文本节点 105 → 39），也就是第一次 beforeinput insertCompositionText d=58 之后，DOM 里的文本长度就已经只有 39，正好对应"只剩第二行"。

结论：首段从来没有进入编辑器的 DOM。compositionend 携带的数据本身就是截断的——编辑器这边无论怎么在 compositionend 上做补写，都补不回一段从未送达的文本。

为什么可以排除"是 DSH 的文本管线丢的"

我在 0.1.5-rc.2（你的版本）和当前 HEAD 上分别全树检索过，发布出去的客户端里根本没有任何 beforeinput / insertCompositionText 处理：

git grep -n -E "insertCompositionText|onBeforeInput|beforeinput" dsh-v0.1.5-rc.2 -- packages
→ 仅 1 处命中：packages/client/ui-conversation/tests/input-bar.client.spec.tsx:9 的注释

（该注释原文：draft writes drive the shell (jsdom's beforeinput lacks the ranges Lexical needs).）

也就是说 DSH 不拦截、不重写、不自行插入组字文本——组字期间的 DOM 由浏览器原生写入。DSH 这边唯一的 IME 相关代码是按键守卫，在 packages/client/ui-conversation/src/client/input/editor/keymap.ts:9-15：

IME guard: a composition-closing Enter/Space must not submit or adjudicate. … Safari delivers the closing keydown AFTER compositionend, so a root-element composition watch holds the guard for 10ms more … keyCode 229 is the legacy signal engines emit without isComposing.

那管的是 Enter/Space 误提交，与文本落地无关。（输入框本身是 Lexical 0.49 + @lexical/plain-text 的 contenteditable，见该包 package.json。）

机制（和你推测的一致，但可以说得更准）

一次组字里带换行时，组字区跨了 block 边界。你 trace 里 t=223486 node-/node+ SPAN、P、BR 正是引擎为这个跨段落组字重建 DOM 块——重建会把 WebView 记录的 composing region 作废，输入法随后只认最后那个块，于是从"整理版两行"退化成"只剩第二行"，并且这个退化发生在 compositionend 之前、在 IME 侧。这也解释了你的对照组：不含换行时组字区不跨块，DOM 不重建，落地就差 ≤2 字。

触发它的是「AI 整理」这个会反复重声明组字文本（105 → 58 → 41）的输入法功能；普通的逐字组字不会一次塞进换行。

可以立刻用的规避

1. 关掉微信输入法语音的「AI 整理」，只保留普通语音转写（去掉"一次组字里带换行"这个前提）。
2. 需要多段时，先落第一段、再起第二次组字。
3. 或者用剪贴板粘贴进去（绕开组字路径）。
4. 桌面端 Web UI 不受影响。

想真修的话，方向在这里

要治的不是"取消区"逻辑，而是别在组字进行中重建块 DOM：即让换行导致的段落拆分推迟到 compositionend 之后落地（或在 beforeinput 的 insertCompositionText 上拦住跨块组字、由编辑器自己按整段写入）。这条路上游改起来是编辑器层的事。

说明一句：我这边无法起 Android WebView 复现，所以"WebView 作废组字区"这一步是基于你自己的埋点序列（DOM 已截断 + comp-end 数据已截断）推断的，不是我在设备上实测的；而"DSH 没有 beforeinput 处理"是我在源码里核实过的事实。

另外你另开的 #6550 是同一条（同标题同内容），修的时候按一条跟即可。