[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]

这条和 #6552 是同一位同学、同一份内容——完整分析我写在那边了

你和 #6552 是同一个问题（同一份复现、同一份埋点）。我在那边给了完整回复，把要点搬过来，省得你在两条之间跳：

1. 决定性的证据在你自己的埋点里

t=223457  beforeinput   insertCompositionText  d=58
t=223484  charData      -66   文本节点 105 → 39        ← 首段整行没有落地
t=223498  comp-end      d=41

charData -66（105 → 39）说明第一次 beforeinput 声明 58 字之后，DOM 里的文本就已经只剩第二行；而 comp-end d=41 说明输入法最后自己声明的也只剩第二行。

⇒ 首段从来没有进入编辑器的 DOM。 所以 compositionend 上无论怎么补写都补不回一段从未送达的文本——这不是"编辑器丢了一段"，而是"这一段没送到"。

2. 可以排除"是 DSH 的文本管线丢的"

我在你那个版本（0.1.5-rc.2）与当前 HEAD 上都全树检索过：发布出去的客户端里没有任何 beforeinput / insertCompositionText 处理（0 命中，只有测试文件里一句注释）。唯一的 IME 相关代码是按键守卫（收尾组字的 Enter/Space 不提交）。也就是说 DSH 不拦截、不重写组字文本，组字期间的 DOM 由浏览器原生写入。

3. 机制

一次组字里带换行时，组字区跨了 block 边界；你埋点里的 SPAN/P/BR 增删正是引擎为此重建 DOM 块。重建会把 WebView 记录的 composing region 作废，输入法随后只认最后那一块——于是 compositionend 自己就只剩第二行了。这也解释了你的对照组：不含换行时组字区不跨块、DOM 不重建、落地差值 ≤2 字。

4. 现在能用的规避

• 关掉输入法语音的「AI 整理」——它会反复重声明组字文本（你记录到的 105 → 58 → 41），正是触发条件；
• 需要多段时，先落第一段、再起第二次组字；
• 或者直接用剪贴板粘贴。

5. 真修的方向

不是"取消区"逻辑，而是别在组字进行中重建块 DOM——把换行导致的段落拆分推迟到 compositionend 之后落地。

两条按一条跟就行，不必分别处理；细节与逐条证据都在 #6552 那条回复里。