[Bug] 输入法上屏后粘贴多行文本只剩第一行：insertText 走 CONTROLLED_TEXT_INSERTION_COMMAND 被 Lexical 吞段（附复现脚本与零改动修复）

[chenhongdeGitHub]

[Bug] 中文输入法上屏后粘贴多行文本只保留第一行：beforeinput insertText 走 CONTROLLED_TEXT_INSERTION_COMMAND，Lexical 只写入首段（附复现脚本与零改动修复）

环境

项	值
dsh	@deepseek-ai/dsh 0.2.1-alpha.1（cordis 4.0.5-alpha.1）
浏览器	Chromium 1243（arm64，playwright-core 驱动，移动 UA / 412×915 / isMobile / hasTouch）
真机	DSHA 内置 Android WebView（用户实测复现）
组件	@deepseek-ai/dsh-client-ui-conversation 的 composer（Lexical 编辑器）
文件	…/dsh-client-ui-conversation/lib/client.js（877842 B / 23304 行）

---

一、症状

在输入框里先用中文输入法打字上屏几个字，然后粘贴一段多行长文本，粘贴内容只剩第一行，其余全部丢失。

反过来：直接粘贴（没有先打字上屏）同样一段长文本，完全正常，一字不少。

用户原话（DSHA App 内 Web 界面）：粘贴长内容被截断；先打几个字再粘贴才出问题。

---

二、复现（最小步骤）

1. 打开 dsh Web，光标落进 composer；
2. 用输入法打字上屏 3 个字符（abc）—— 这一步必须走 IME composition（中文/日文/韩文输入法、或移动端软键盘候选词上屏）；
3. 粘贴一段含换行的文本（两行就够，例如 <<HEAD>>\n第二行）；
4. 结果：输入框只剩 abc<<HEAD>>，第二行 及其后所有行消失。

对照（均不触发）：不先打字直接粘贴；先打字后粘贴单行文本；用 Ctrl+V / 右键粘贴菜单（走 paste 事件）。

---

三、边界矩阵（实测，6 用例）

E 系列全部在同一个 composer 会话内、按序执行。payload 为多行等长行，L(n) = n*60 + 17。

用例	序列	期望长度	实测长度	尾标记在	判定
E1	上屏3字 → insertText 单行 20k	20019	20019	是	✅ 正常
E2	上屏3字 → insertText 2 行	75	11	否	❌ 丢失
E3	上屏3字 → insertText 10 行	515	11	否	❌ 丢失
E4	上屏3字 → 等 3 秒 → insertText 10 行	515	11	否	❌ 丢失
E5	上屏3字 → 重新点输入框 → insertText 10 行	515	11	否	❌ 丢失
E6	无 composition → insertText 10 行（对照）	512	512	是	✅ 正常

失败用例终态完全一致：DOM len=11、paras=1、文本 "abc<<HEAD>>" —— 即「composition 上屏的 3 字 + 粘贴内容的第一行」，第一行之后全部丢失。

时间维度排除：粘贴后按 250ms 步长采样 8 秒，长度全程稳定在 11，不是延迟补全，是同步截断。等待 3 秒、重新聚焦均不能解除 ⇒ 状态残留，非时序问题。

原生对照（关键）：同样序列打在原生 <div contenteditable> 上 → len=29519 且尾标记在，原生不受影响；Lexical 上「无 composition 前置」的纯 insertText 20k → len=30017 无损 ⇒ 与浏览器 / WebView 无关，锅在 composer 自身。

---

四、机制（事件序列取证）

探针监听 beforeinput / input / compositionstart / compositionend / paste，F1 为「上屏3字 → insertText 200 字符（4 行）」：

compositionstart              data=0
beforeinput:insertCompositionText  data=3   comp=true  dom=2
input:insertCompositionText        data=3   comp=true  dom=4
beforeinput:insertCompositionText  data=3   comp=true  dom=4
input:insertCompositionText        data=3   comp=true  dom=4
compositionend                data=3   dom=4
beforeinput:insertText        data=200 comp=false prevented=false dom=3   ← 完整数据、未被 preventDefault
input:insertText              data=8   dom=11
input:insertText              data=0   dom=11
input:insertText              data=60  dom=11
input:insertText              data=0   dom=11
input:insertText              data=60  dom=11
input:insertText              data=0   dom=11
input:insertText              data=60  dom=11
input:insertText              data=0   dom=11
input:insertText              data=8   dom=11
DOM: len=11 paras=1 txt="abc<<HEAD>>"

F2（无 composition 对照）只有一条 beforeinput:insertText data=200 comp=false prevented=false dom=0 → DOM len=200 paras=1，全文正常。

F3（同会话连做两次）：第二次仍重复同样的碎片序列、终态仍 len=11 ⇒ 同一会话内永久性状态污染，无法自愈。

三例 localStorage 中均无草稿 key（draft keys: []）⇒ 与草稿持久化无关。

---

五、根因（源码定位）

@deepseek-ai/dsh-client-ui-conversation/lib/client.js，dsh 0.2.1-alpha.1：

1）beforeinput 主分发（:10306）

if ("insertText" === n || "insertTranspose" === n) {
    if ("\n" === c) e.preventDefault(), Nl(r, Ue$2, !1);          // 恰好一个换行 → INSERT_LINE_BREAK
    else if (c === D$1) e.preventDefault(), Nl(r, He$2);          // 恰好一个段分隔 → INSERT_PARAGRAPH
    else if (null == c && e.dataTransfer) { … }
    else null != c && Bn(s, o, c, e.timeStamp, !0)
        ? (e.preventDefault(), Nl(r, je$2, c), jn(c))             // ← 多行文本走这里
        : i.unprocessedBeforeInputData = c;
    return i.lastBeforeInputInsertTextTimeStamp = e.timeStamp, !0;
}

je$2 = CONTROLLED_TEXT_INSERTION_COMMAND（:10049）。注意判断是精确相等 "\n" === c，所以含换行的整段文本不命中前两个分支，整段（含 \n）被交给 je$2。

对比：真正的粘贴事件走另一条路（:10335）

case "insertFromPaste":
case "insertFromPasteAsQuotation":
    Nl(r, Je$2, e);        // Je$2 = PASTE_COMMAND —— 这条通道不吞段
    break;

⇒ insertText 通道（CONTROLLED_TEXT_INSERTION_COMMAND）会吞段，paste 通道（PASTE_COMMAND）不会。 这正是「直接粘贴正常、输入法上屏后粘贴异常」的分叉点：Android WebView 的粘贴菜单与输入法 commitText 都走 InputConnection.commitText → 等价 insertText，而不是 paste 事件。

2）不一致判定器 Bn(t, e, n, o, r, i)（:10155）

返回 true 表示「DOM 与 model 不一致、需要走 Lexical 自己的命令」。返回表达式中与 composition 强相关的两个子句（:10164）：

… || a.isDirty() && _ > 1 || (r || !s) && null !== g && !a.isComposing() && d !== wc(a, g, u) || …

• a.isDirty() —— composition 上屏必然把节点标脏；
• _ = n.length —— 多行文本长度远大于 1。

两者同时为真 ⇒ Bn 返回 true ⇒ 走 je$2，随后 Lexical 的 insertText 实现按 \n 拆段时只把第一段写进 model，其余段被吞。DOM 侧随后出现的那串 data=60 / data=0 交替的 input 事件都发生在 dom=11 不变的状态下，是 model 已被截断之后的空转。

3）为什么「无 composition 前置」不触发：节点未 isDirty()，Bn 走不到那条子句，insertText 正常按段写入。

---

六、修复方案

方案 A（零宿主改动，插件侧兜底，已验证）

在 composer 的 beforeinput 上装一个 capture 期守卫：命中「insertText + data 含换行 + 落在 Lexical 编辑器中」时，preventDefault() + stopPropagation()，再用 DataTransfer 造一个 ClipboardEvent('paste') 派发回去，把同一段文本改投 paste 通道（即上文 Je$2 那条不吞段的路径）。

核心逻辑（约 30 行，可直接放进任意客户端插件）：

function installPasteGuard() {
  let alive = true, fired = 0;
  const onBeforeInput = (event) => {
    if (!alive) return;
    if (event.inputType !== 'insertText') return;
    const text = event.data;
    if (typeof text !== 'string' || text.indexOf('\n') === -1) return;
    const target = event.target;
    if (!target || !target.closest || !target.closest('[data-lexical-editor="true"]')) return;
    const host = target.closest('[contenteditable="true"]') || target;
    if (typeof DataTransfer !== 'function' || typeof ClipboardEvent !== 'function') return;
    let clipboardData;
    try { clipboardData = new DataTransfer(); clipboardData.setData('text/plain', text); }
    catch { return; }
    event.preventDefault();
    event.stopPropagation();
    try {
      host.dispatchEvent(new ClipboardEvent('paste',
        { clipboardData, bubbles: true, cancelable: true }));
    } catch { return; }
    fired++;
  };
  document.addEventListener('beforeinput', onBeforeInput, true);
  return () => { alive = false; document.removeEventListener('beforeinput', onBeforeInput, true); };
}

实测（装上守卫后，10 用例全过）

用例	场景	期望	实测	判定
G1	上屏3 + 10 行	620	620	✅
G2	上屏3 + 单行 20k	20003	20003	✅
G3	上屏3 + 中文多行	617	617	✅
G4	上屏3 + 10 行（重复）	620	620	✅
G5	上屏3 + 280 行（16820 字符）	16820	16820	✅
G6	连续两次触发	1237	1237	✅
G7	普通打字	5	5	✅
G8	Shift+Enter 软换行	4	4	✅ 无回归
G9	上屏3 + 中文多行（守卫前/后对照）	—	守卫前 len=7 只剩首行；守卫后 len=32 全文保留	✅
G10	最小两行触发	80	80	✅

G9 是本 bug 的对照实证：同一页面、同一序列，装守卫前 {"len":7,"txt":"abc你好世界"}（只剩第一行），装守卫后 {"len":32,"txt":"abc你好世界\n第二行\n第三行\n第四行\n第五行\n<<TAIL>>"}。

不回归：普通打字、Shift+Enter 软换行、真 Ctrl+V（paste 事件路径）、无 composition 的纯 insertText 路径全部行为不变。

方案 B（改宿主，一行级）

在 :10306 的 insertText 分支里，把「含换行的多行文本」也送进 paste 通道，而不是 CONTROLLED_TEXT_INSERTION_COMMAND：

if ("insertText" === n || "insertTranspose" === n) {
    if ("\n" === c) e.preventDefault(), Nl(r, Ue$2, !1);
    else if (c === D$1) e.preventDefault(), Nl(r, He$2);
    else if (null == c && e.dataTransfer) { … }
    else if (null != c && c.indexOf("\n") !== -1) {      // ← 新增：多行 insertText 改走 paste
        e.preventDefault();
        const t = e.dataTransfer ?? (() => {
            const d = new DataTransfer(); d.setData("text/plain", c); return d;
        })();
        Nl(r, Je$2, { …e, dataTransfer: t });
        jn(c);
    }
    else null != c && Bn(s, o, c, e.timeStamp, !0) ? (e.preventDefault(), Nl(r, je$2, c), jn(c)) : i.unprocessedBeforeInputData = c;
    return i.lastBeforeInputInsertTextTimeStamp = e.timeStamp, !0;
}

更保守的等价修法：在 Bn（:10164）里把 a.isDirty() && _ > 1 收窄成 a.isDirty() && _ > 1 && !a.isComposing() 之外再补「且文本不含换行」，让多行文本不走 Lexical 自己的 insertText 命令。

---

七、验证方法

复现脚本（playwright-core，Chromium，移动 UA；需一个带 token 的 dsh 实例）：

# 起一个可驱动的实例
cd /root && dsh --profile web --port 41537 --no-open > /tmp/repro/inst.log 2>&1 &
# 从日志里取 URL（形如 http://127.0.0.1:41537/?token=XXXX），带 cookie 访问
curl -c /tmp/repro/jar -o /dev/null "http://127.0.0.1:41537/?token=XXXX"
curl -b /tmp/repro/jar http://127.0.0.1:41537/api/dsha-boot      # 应回 200 + JSON

// 关键片段：造 composition 上屏，再投多行 insertText，读回长度与尾标记
const cdp = await page.context().newCDPSession(page);
await page.click('[data-lexical-editor="true"]');
await cdp.send('Input.imeSetComposition', { text: 'abc', selectionStart: 3, selectionEnd: 3 });
await cdp.send('Input.insertText', { text: 'abc' });          // 上屏 → compositionend
await cdp.send('Input.insertText', { text: payload });        // 多行粘贴等价路径
const got = await page.$eval('[data-lexical-editor="true"]', el => ({
  len: el.textContent.length, paras: el.children.length,
  tail: el.textContent.includes('<<TAIL>>')
}));
// 期望：len === payload.length && tail === true

判据：len === payload.length 且 tail === true。修复前 len=11 tail=false；修复后（方案 A）len=620 tail=true。

---

八、已知不确定项

1. 触发条件在桌面浏览器上用 CDP 合成 Input.insertText 可稳定复现；真机上由 Android WebView InputConnection.commitText 触发，两条路径在本 bug 上等价（均为 insertText 而非 paste），但真机软键盘厂商差异（搜狗 / Gboard / 系统输入法）未逐一覆盖。
2. Bn 返回 true 只是必要条件，insertText 命令内部「按 \n 拆段只写首段」的确切代码路径未逐行读出（je$2 的 handler 在压缩后的 bundle 内，未展开定位）；本文的机制结论以事件序列 + 分支命中为证据。
3. 方案 B 的 e.dataTransfer 构造在不同浏览器下 DataTransfer 可用性不同，故方案 A（页面内守卫）作为主推。
4. 未验证在 dsh 更早版本（0.1.x / 0.2.0-rc.*）上是否同样存在 —— 本报告基于 0.2.1-alpha.1 实测。

[PerryLink]

你指的路径与我们代码里的粘贴路径不是同一条——这个区分对你有利

1. 我们的粘贴路径是可核的

packages/client/ui-conversation/src/client/input/editor/keymap.ts：

editor.registerCommand(PASTE_COMMAND, (event) => { … handlers.pasteText(text) … })   // :183

以及 view-binding.ts:140：pasteText: (text) => { … }。⇒ 粘贴命令走的是我们自己的 pasteText，不是 Lexical 的默认 insertText 路径。

而你现在报的是 beforeinput insertText（即输入法上屏产生的那条插入路径）⇒ 这是另一条路：它不经过 PASTE_COMMAND，而由 Lexical 的 insertText 处理，进到 CONTROLLED_TEXT_INSERTION_COMMAND。

这个区分很重要：它说明你遇到的不是"我们的粘贴处理写错了"，而是"上屏插入这条路径我们没有接管"。建议在正文里明确写出这一点——否则容易被读成"粘贴功能坏了"，从而找错方向。

2. 一条我此前已核实的相关事实（对你有用）

在多个版本上我都检索过：发布出去的客户端里没有 beforeinput / insertCompositionText 的处理（0 命中）。⇒ 与你的定位自洽：上屏/组字期间的插入由浏览器与 Lexical 原生处理，我们没有介入。

因此修法只有两个方向（建议在报告里写明你主张哪一个）：

1. 我们接管 beforeinput/insertText（在 composer 层把多段插入补齐，而不是只落首段）；
2. 上游 Lexical（CONTROLLED_TEXT_INSERTION_COMMAND 对多段文本的处置）。

你写的是"零改动修复"——如果它是配置/开关层面的（例如改用另一条 insertion 命令、或给编辑器加一个 option），请把那个开关具名写出；若它其实是"补一小段 beforeinput 处理"，那严格说不是零改动。这一处措辞会影响维护者的判断，建议改准。

3. 这是第四个中文输入法/composer 报告了

帖	承载 / 输入法	症状
#6552	Android WebView + 微信输入法	跨段落组字 ⇒ 首段整段丢失
#7825	Windows + 微软拼音	未上屏字符泄漏
#7803	Windows + 微软拼音	拼音落框、候选错乱
你这条	Android WebView / Chromium	上屏后多行粘贴只落首行

⇒ 建议在正文里点出这个群（你这台是"真机 Android WebView + 用户实测复现"，价值很高）。四条合起来足以说明"组字/上屏期间的多段文本插入"是一类系统性问题，而不是四个孤例——这比单独立案更容易被排期。

4. 版本口径

你写的是 0.2.1-alpha.1——就是当前 HEAD（5badb15009），所以无需再升级，你的现场就是最新代码。只是别把核换成 latest（0.2.0-rc.2，比 alpha 线旧）：

npm i -g @deepseek-ai/dsh@alpha    # 0.2.1-alpha.1

一条边界

我确认的是我们的粘贴路径是 PASTE_COMMAND → pasteText，以及客户端没有 beforeinput 处理（因此你描述的路径确实未被接管）。CONTROLLED_TEXT_INSERTION_COMMAND 只写首段这一行为属于 Lexical 内部，以你的复现脚本为准。