docs: 收口阶段 0B 输入消费结论
This commit is contained in:
Codex
@@ -0,0 +1,57 @@
|
||||
# BUG-20261006-0002
|
||||
|
||||
> 适用场景：记录问题本身，不展开完整修复方案。修复内容写入对应的 Fix 文档。
|
||||
|
||||
## 基本信息
|
||||
|
||||
- ID: BUG-20261006-0002
|
||||
- 标题: 阶段 0B 夹具缺少 IME 锚点、组合态 Escape 规则无法命中且采集存在锁竞争丢失
|
||||
- 状态：已修复并完成微软拼音与搜狗人工验证
|
||||
- 严重性：S2
|
||||
- 优先级：P0
|
||||
- 模块: 阶段 0B / InputProbe / UiFixture / IMM32
|
||||
- 版本 / 分支: `master`，0B 开发中未提交改动
|
||||
- 环境: Windows 11、EasyX 25.9.10、ANSI HWND、CP936、DPI-unaware 96 DPI、微软拼音与搜狗人工探测
|
||||
- 发现人: 用户真实 IME 人工探测 + 日志复核
|
||||
- 关联 Fix ID: Fix-BUG-20261006-0002
|
||||
|
||||
## 问题描述
|
||||
|
||||
- 现象 1: `input-consume-probe` 窗口中开始中文组合后，微软拼音和搜狗候选 UI 都出现在桌面左下角，而不是探测窗口内。
|
||||
- 现象 2: 人工按一次 Escape 后，配置为 `WM_KEYDOWN + VK_ESCAPE + ComposingOnly` 的规则命中数为 0。
|
||||
- 现象 3: 本轮日志出现 3 条 `wndproc_lock_contention`，`recordsLost=3`，分析结果为 `inconclusive_capture_loss`。
|
||||
- 影响范围: 0B-3 的真实 IME A/B 无法形成有效证据；如果误把该运行当成消费行为结果，可能把夹具缺陷错误归因于 IME 或 WndProc 消费策略。
|
||||
- 期望结果: 夹具使用与 0C 同源的客户区 anchor 定位候选 UI；规则匹配 WndProc 实际可观察的原生键三元组；探测器自身不因 flush 锁竞争丢记录。
|
||||
|
||||
## 复现信息
|
||||
|
||||
- 前置条件: 运行 0B Composition 人工探针，选择微软拼音或搜狗。
|
||||
- 复现步骤:
|
||||
|
||||
1. 点击 `StellarX.UI.input-consume-probe`，输入固定非敏感串 `ceshi`。
|
||||
2. 观察候选 UI 位于桌面左下角。
|
||||
3. 在组合态按一次 Escape 并关闭窗口。
|
||||
4. 分析 JSONL 中的原生键和 `records_lost`。
|
||||
|
||||
- 复现概率：旧夹具在本轮稳定复现
|
||||
- 证据目录: `TestResults/InputProbe/0B/20261006-140720-218-96b7392e-548a-44cf-9343-5d1449bf73fa`
|
||||
- 人工截图: `manual-evidence/composition-candidate-position-wrong.png`
|
||||
- 截图 SHA-256: `61E4A04CEE329B13BB22C919DC233A07ABF3EF6C298E64FB7B6E70F6D60DE0A3`
|
||||
|
||||
## 初步分析
|
||||
|
||||
- 候选位置根因: 0B 夹具没有调用 `ImmSetCompositionWindow` 或 `ImmSetCandidateWindow`，却要求操作者按 0C 基线判断位置；两套环境实际上不可比。
|
||||
- 规则根因: 组合态按 Escape 时，WndProc 记录为 `WM_KEYDOWN + VK_PROCESSKEY(229) + scanCode 1`；IME 结束后才出现 `WM_KEYUP + VK_ESCAPE(27)`。旧规则错误假设 KeyDown 仍保留逻辑 VK。
|
||||
- API 时机边界: 微软文档说明 `ImmGetVirtualKey` 只能在应用调用 `TranslateMessage` 前恢复原 VK。当前钩子已经在 EasyX WndProc，不能可靠恢复该键，只能记录真实原生值。
|
||||
- 采集丢失根因: 宿主 safe-point 在状态锁内复制整个记录环，WndProc 使用 `try-lock`，争用时直接记丢失；探测器自身制造了实验失效条件。
|
||||
- 证据边界: 失败运行混有多次组合，且存在采集丢失，只能证明夹具缺陷，不能区分输入法差异，也不能判断 Consume 是否安全。
|
||||
|
||||
## 跟踪信息
|
||||
|
||||
- 首次发现时间: 2026-10-06 14:07
|
||||
- 最后更新时间: 2026-10-07
|
||||
- 修复版本: 待提交
|
||||
- 验证版本: Debug x64 探测构建、默认单元测试 15/15、UI fixture 1 轮、F24 自动 A/B、微软拼音 Forward/Consume 与搜狗运行时 fail-open 人工验证通过
|
||||
- 参考: <https://learn.microsoft.com/windows/win32/api/immdev/nf-immdev-immgetvirtualkey>
|
||||
- 后续关联: 固定锚点实现最初在状态锁内调用 IMM32 setter，引发 WndProc 重入自锁；详见 `BUG-20261006-0003`。
|
||||
- 关闭边界: 搜狗候选态不暴露标准 Composition 生命周期，Consume 请求必须以 `ime_condition_not_met` fail-open；这是 `MustForward` 的输入法兼容结论，不是本 BUG 的残留夹具缺陷。
|
||||
@@ -0,0 +1,60 @@
|
||||
# BUG-20261006-0003
|
||||
|
||||
> 适用场景：记录问题本身，不展开完整修复方案。修复内容写入对应的 Fix 文档。
|
||||
|
||||
## 基本信息
|
||||
|
||||
- ID: BUG-20261006-0003
|
||||
- 标题: 阶段 0B 持锁调用 IMM32 定位导致 WndProc 重入死锁
|
||||
- 状态：已修复（微软拼音 Forward/Consume 与搜狗 fail-open 人工运行均保持响应）
|
||||
- 严重性：S1
|
||||
- 优先级：P0
|
||||
- 模块: 阶段 0B / InputProbe / WndProc / IMM32
|
||||
- 版本 / 分支: `master`，0B 开发中未提交改动
|
||||
- 环境: Windows 11、EasyX 25.9.10、ANSI HWND、CP936、DPI-unaware 96 DPI、微软拼音与搜狗人工探测
|
||||
- 发现人: 用户真实 IME 人工探测
|
||||
- 关联 Fix ID: Fix-BUG-20261006-0003
|
||||
|
||||
## 问题描述
|
||||
|
||||
- 现象: 启动微软拼音 `ObserveAndForward` 人工探测后，EasyX 窗口卡顿并进入“未响应”，无法继续输入。
|
||||
- 影响范围: 0B-3 人工 IME A/B 无法执行；该现象由诊断夹具自身造成，不能作为微软拼音或 Forward 行为异常的证据。
|
||||
- 期望结果: IMM32 定位不得持有探测状态锁；同步重入的 WndProc 消息仍应被严格有序记录，窗口保持可交互。
|
||||
|
||||
## 复现信息
|
||||
|
||||
- 前置条件: 启用 0B 人工 Composition 规则和固定 IME caret/line rect。
|
||||
- 复现步骤:
|
||||
|
||||
1. 启动微软拼音 `ObserveAndForward` 人工探针。
|
||||
2. 激活 EasyX 窗口并尝试中文输入。
|
||||
3. 窗口出现卡顿，随后无法输入并显示“未响应”。
|
||||
|
||||
- 复现概率：本轮稳定复现
|
||||
- 证据目录: `TestResults/InputProbe/0B/20261006-231604-636-4bc775a1-a3f8-41b9-b466-1cce740bc195/forward`
|
||||
- 日志边界: 已耐久写入 268 条记录，`sequenceStrict=true`、`recordsLost=0`，但没有 `WM_CLOSE/session_end`；最后一批记录完整结束于普通 Space KeyUp。死锁发生点很可能位于下一次定位调用且早于新记录入队，因此日志不能直接给出阻塞栈。
|
||||
|
||||
## 根因分析
|
||||
|
||||
- `inputProbeWndProcEnter` 持有不可重入的 `ProbeState::lock` 时调用 `ImmGetContext`、`ImmSetCompositionWindow` 和 `ImmSetCandidateWindow`。
|
||||
- IMM32 定位 setter 可以同步重入同一窗口过程；重入后的探测入口再次请求同一把 SRW 独占锁，当前线程因此自锁。
|
||||
- 直接把 setter 移到锁外仍不充分：重入消息如果再次满足定位触发条件，会递归发起新的定位调用，需要独立的线程内重入抑制。
|
||||
- 本问题由 `BUG-20261006-0002` 的固定锚点修复实现引入，不是 EasyX、微软拼音或消息消费策略本身的缺陷。
|
||||
|
||||
## 跟踪信息
|
||||
|
||||
- 首次发现时间: 2026-10-06 23:16
|
||||
- 最后更新时间: 2026-10-07
|
||||
- 修复版本: 待提交
|
||||
- 验证版本: Debug x64 探测构建、默认单元测试 15/15、UI fixture 1 轮、微软拼音 Forward/Consume 与搜狗 fail-open 真实复验通过
|
||||
- 关联记录: `BUG-20261006-0002`、`Fix-BUG-20261006-0002`
|
||||
|
||||
## 关闭证据
|
||||
|
||||
- 有效运行: `TestResults/InputProbe/0B/20261006-234544-007-603391f8-3a14-4c90-ab41-4d891ceb8f46/forward`
|
||||
- 结构结果: `experimentValidity=valid`、`sequenceStrict=true`、`recordsLost=0`、规则唯一命中并 Forward、`imePosition=18/18`、`imePositionOrphanCount=0`、`WM_CLOSE/session_end` 完整。
|
||||
- 人工结果: 窗口保持响应并可正常输入；组合串和候选 UI 位于固定锚点附近，Escape 流程完成后窗口正常关闭。
|
||||
- 截图: `manual-evidence/microsoft-pinyin-forward-composition-position-pass.png`
|
||||
- 截图 SHA-256: `1447E9F1AAD2C90A787AADC2594C78AE596336FC6D569EA1A22C69B2FCA5C3D5`
|
||||
- 补充证据: 搜狗最终 fail-open 运行中窗口保持响应，定位 3/3、无孤立结果、零丢失且关闭完整；见 `TestResults/InputProbe/0B/20261007-033454-763-56a2630b-bf2a-4431-b501-38f6ff977dfe/consume`。
|
||||
- 关闭边界: 本 BUG 只关闭“持锁定位导致重入死锁”；搜狗未暴露 Composition 生命周期所形成的 `MustForward` 结论归 0B 规格，不属于死锁残留。
|
||||
Reference in New Issue
Block a user