Bug：Web UI 原生文件夹选择器不置前；服务孤儿化时选择器崩溃（附已验证修复）

[Zhangbo-cn]

一句话

Windows 下 Web UI 触发的原生文件夹选择器有两个问题：① 对话框出现在浏览器窗口后面、不置前，需要手动点任务栏；② 当 dsh web 服务进程孤儿化（所属终端/后台任务被关闭）后，选择器直接失败，报 win32 folder dialog worker exited before reporting a result。

复现

1. 启动 pnpm dsh web，打开 Web UI http://127.0.0.1:3080。
2. 点"打开文件夹"（触发 host.pickDirectory → 原生 IFileOpenDialog 目录选择器）。
3. 孤儿化场景：以"会孤儿化"的方式启动服务（后台任务启动后 kill 其宿主任务，node 服务存活但 console/stdio 管道被切断），再点"打开文件夹"。

实际结果

• ① 对话框弹出但在浏览器窗口后面（不置前），需到任务栏（固定栏）点击才能操作。
• ② 孤儿化服务下 pick 约 20ms 内失败：directory picker failed: win32 folder dialog worker exited before reporting a result。给 worker 加生命周期日志发现：子进程在 JS 顶层代码执行前（CRT 启动阶段）即退出，stdout/stderr 无任何输出。同一代码在正常启动的服务上，选择器工作正常。

预期结果

• ① 点"打开文件夹"后，对话框自动出现在浏览器前面，无需任务栏点击。
• ② 无论服务进程是否孤儿化，选择器都正常工作。

环境

• Windows 11 Pro 10.0.26200 x64 · Node v24.14.1 · pnpm 11.7.0 · deepseek-harness 0.1.0-rc.5（master）

根因

1. 弹窗不置前：packages/host/directory-picker-native 以 IFileOpenDialog::Show(NULL)（无 owner 窗口）打开对话框。对话框子进程由服务端 spawn，并非用户直接输入来源，Windows 前台锁（foreground lock）限制其无法主动抢到前台，于是落在浏览器后面。代码注释假设"子进程的第一个窗口 Windows 会自动激活"，但由浏览器触发的场景下不可靠。
2. 孤儿化崩溃：spawnDialogWorker 用 stdio: ['ignore','inherit','inherit','ipc'] spawn 对话框子进程。当父进程（dsh web 服务）孤儿化后，其 console/stdio 句柄在 Windows 上已失效；子进程继承这些句柄后，CRT 启动校验失败、任何 JS 未执行即终止，父进程只收到 exit 事件 → 报 "worker exited before reporting a result"。

修复（已验证）

// packages/host/directory-picker-native/src/win32-dialog-host.ts —— 孤儿化健壮性
-  const stdio: StdioOptions = ['ignore', 'inherit', 'inherit', 'ipc']
+  const stdio: StdioOptions = ['ignore', 'ignore', 'ignore', 'ipc']

// packages/host/directory-picker-native/src/win32-dialog-logic.ts —— 弹窗置前
-      const shown = dialog.show()
+      const shown = dialog.show(bindings.foregroundWindow())

// packages/host/directory-picker-native/src/win32-dialog-bindings.ts
   const getCurrentThreadId = kernel32.func('__stdcall', 'GetCurrentThreadId', 'uint32', [])
+  const getForegroundWindow = user32.func('__stdcall', 'GetForegroundWindow', 'void *', [])
   ...
-        show: () => method(dialog, SLOT_SHOW, protoShow)(null),
+        show: owner => method(dialog, SLOT_SHOW, protoShow)(owner),
   ...
+    foregroundWindow: () => getForegroundWindow() as number,

修复 ① 的原理：把当前前台窗口（用户刚点击的浏览器）作为 owner 传给 Show，带 owner 的模态对话框会被 Windows 显示在 owner 之上并自动激活。对话框结果本就通过 IPC 回报，不依赖父进程 stdio，故 ② 直接固定子进程 stdio 为 NUL 即可。

关联问题：中文路径截断（readUtf16）

感谢维护者的反馈——本组件还涉及中文路径截断问题（官方讨论区 dsh-handbook 第 12 章 汇总，根因帖 discussion #107，家族 17+ 帖）：readUtf16 以单字节判 0 作为终止符，遇到 UTF-16 单元低字节为 0x00 的字符（如 开=U+5F00 → UTF-16LE 00 5F）会误判终止、截断路径。已一并修复并加回归测试：

// packages/host/directory-picker-native/src/win32-dialog-bindings.ts —— readUtf16 中文路径截断
-  while (end + 1 < bytes.length && bytes[end] !== 0) end += 2
+  while (end + 1 < bytes.length && (bytes[end] !== 0 || bytes[end + 1] !== 0)) end += 2

验证

• 包单测：pnpm exec vitest run packages/host/directory-picker-native/tests → 47 passed / 1 skipped（5 个文件）。
• 实机验证（Windows 11）：
  • ① 修复后，在 Web UI 点"打开文件夹"，对话框直接出现在浏览器前面（已确认）。
  • ② 复现孤儿化服务：修复前 pick 失败（~20ms），修复后对话框正常弹出。

补丁分支

完整补丁（前台置前 + 孤儿化健壮性 + readUtf16 中文路径）已提交到 fork 的 fix/win32-directory-picker 分支：https://github.com/Zhangbo-cn/deepseek-harness/tree/fix/win32-directory-picker（若官方后续开放 PR，可直接从该分支创建）。

[Electricitysheep]

Windows 文件夹选择器不置前 + 孤儿化崩溃——选择器是 #800（中文路径截断）那个组件的另一个问题面。

带已验证修复很好，建议连同 #800 的 readUtf16 修复一起提给官方。Windows 路径/选择器坑位第 12 章有汇总：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/12-limitations.md

[Zhangbo-cn]

感谢维护者的反馈与关联问题提示（选择器是中文路径截断那个组件的另一面）。已按建议一并补充：

1. 修复了同组件的 中文路径截断 问题——readUtf16 以单字节判 0 作为终止符，遇到 UTF-16 单元低字节为 0x00 的字符（如 开=U+5F00）会误判终止、截断路径。已修复为校验完整 0x0000 终止符并加回归测试。
2. 补丁分支 fix/win32-directory-picker 现含 3 个修复：前台置前 / 孤儿化健壮性 / readUtf16 中文路径。
3. 修正了本帖正文的 Markdown 格式（去掉有问题的加粗写法、规范化链接），避免在提供修复的同时引入格式问题。

Windows 路径/选择器坑位已参考 dsh-handbook 第 12 章（#107 根因帖）。若官方开放 PR，随时可合并。