[Bug] Web 界面中文输入法（IME）失效：拼音字母直接上屏，无候选词

[thomasinalonnie-ship-it]

环境

• 系统：macOS（Intel/M 系列均可复现）
• 版本：DeepSeek Harness Web 界面（预览版，v0.1.0-rc.8，本地运行 dsh web --host 127.0.0.1 --port 8700）
• 输入法：macOS 系统「简体拼音」（菜单栏输入法图标显示正常）

问题描述

在 Web 界面新建会话后，使用系统中文拼音输入法在消息输入框内输入文字时，拼音字母直接上屏（如输入 ffffccc），候选词不出现，无法输入中文。该现象在输入框聚焦后立即出现；切换输入法（拼音 ↔ ABC）或重新聚焦输入框后仍可复现。其他应用（浏览器、文本编辑器）输入中文完全正常。

复现步骤

1. 启动 dsh web，打开会话界面（截图所示输入框，PTC 模式）
2. 切换至系统拼音输入法
3. 在消息输入框输入任意拼音，观察字母直接上屏、无候选词

期望行为

输入法组合正常：拼音候选词出现，中文正常上屏。

附加信息

• 疑似原因：输入框未正确处理 IME composition 事件（compositionstart / compositionend / isComposing），按键在组合完成前被直接写入输入框（或 keydown 被 preventDefault 吞掉）
• 截图说明：红框 1 = 菜单栏输入法图标（拼音模式，正常）；红框 2 = 输入框内字母直落现象
• 补充：dsh tui 模式输入中文正常，无此问题；问题在新建会话后必然出现
• 如有需要，我可以在评论区补充界面截图（菜单栏输入法图标正常 + 输入框字母直落现象）

[ylwl1997]

macOS Web IME 这条很影响中文输入体验。方便的话补充一下：

• 浏览器是 Chrome / Safari / Arc / 内置 WebView？
• 是否只在 textarea 组合输入失败，地址栏/系统其他应用正常？
• 关闭拼写检查 / 切换「简体拼音」↔「ABC」是否有变化？

我这边也会留意 Web 输入框相关的社区插件有没有误拦 composition* 事件；有可复现的最小页面片段的话更好定位。

[denial123789]

I traced this against the rc.8 source (141eb6f). One important distinction may help narrow the report: “no candidate window; raw pinyin is inserted” is not the same failure as “the candidate appears, but Enter submits early.”

The rc.8 InputBar already attaches onCompositionStart / onCompositionEnd, retains a render-stable composition ref, delays the Safari clear, and also checks nativeEvent.isComposing plus keyCode 229. Its regression test covers composition Enter through those three guard paths. That makes a completely missing candidate window worth investigating first at the actual browser artifact / focused DOM element / extension boundary, rather than assuming the Enter guard is absent.

The most useful next evidence would be:

1. exact dsh --version, listening PID, browser + version, and a cache-bypassed reload;
2. guest/private profile result with extensions disabled;
3. whether compositionstart, compositionupdate, beforeinput, input, and compositionend fire on the focused textarea;
4. for each key event: key, isComposing, keyCode, and defaultPrevented;
5. Chromium vs Safari on the same Mac, if available.

If no composition event fires, I would inspect DOM remount/focus, injected scripts, stale Web assets, and the actual running build before changing keyboard arbitration. If the interval exists, the first event incorrectly prevented inside it should identify the narrower fix.

I wrote up the isolation matrix, rc.8 evidence, safe recovery order, and a real-browser regression contract here: https://sandbaseai.github.io/deepseek-harness-handbook/web-ime-composition.html

Source runbook: https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/troubleshooting/web-ime-composition.md

[ylwl1997]

感谢 @denial123789 把 rc.8 InputBar 的 composition* 路径和两种失败模式拆开了——这对复现很关键。

原帖描述更像你说的第一种：候选窗不出现、拼音字母直接进 textarea，而不是「候选出现但 Enter 抢提交」。

@thomasinalonnie-ship-it 如果方便，再确认两点就能把报告钉死：

1. 是否 100%「无候选窗」？（若有时有候选、有时没有，也请写上比例）
2. 用的是系统浏览器开 dsh web，还是桌面端内置 WebView？

我这边会继续留意社区 Web 输入相关插件有没有在捕获阶段误 preventDefault composition 事件。