Replies: 2 comments
|
这个复现已经把 Firefox 与 Brave 的差异隔离出来了,但“对话框在后台”不一定等同于目录选择 worker 崩溃:建议先分别记录 picker 请求是否返回、目录是否成功选择,以及窗口激活/焦点事件。 建议补充一组最小证据:Firefox/Brave 版本、 修复边界可以这样划分:
回归应覆盖首次启动、已有窗口、最小化/多显示器、取消 picker、路径含非 ASCII 字符、Firefox/Brave 以及 alpha/rc 两个已声明版本;成功证据要同时包含“选择结果正确”和“对话框在前台”,二者不能互相替代。手册中的 Windows picker 排查清单可参考:Windows folder picker worker crash。 |
|
这个报告把环境隔离得很干净,正好可以从代码这边把原因补上:不管用哪个浏览器,最后走的都是同一条 host 侧路径(dsh web 本地部署固定用 native 后端,daemon 里没有按浏览器分支的逻辑),所以 Brave 和 Firefox 的差异不是浏览器 API 的问题,而是 Windows 在对话框创建那一刻的"前台切换许可"判定结果不同。 代码上是这样:
Win32 的前台锁是文档化行为:进程不满足前台切换条件时,系统不会把新窗口带到最前,而是让它留在当前前台窗口后面、任务栏按钮闪烁——和报告里的症状一模一样。所以 Brave 那次能正常前置,只是那一次的判定放行了,代码本身没有做任何保证。 修复方向建议:pick 请求到达 host 时,daemon 先 GetForegroundWindow() 抓一下当前前台窗口(用户刚点完按钮,那个窗口几乎必然就是发起点击的浏览器窗口),把句柄传给子进程,Show(hwndOwner) 把对话框挂成它的 owned 窗口。有 owner 的模态对话框跟着 owner 的前台状态走,就不再依赖那个启发式了。绑定层现在 show() 是无参的,需要把 hwnd 传进去;abort 那条 WM_CLOSE 通路不受影响。备选是 worker 里做 AttachThreadInput 的前台交接,但比 owner 方案脏。 一点边界说明:我手头没有 Windows 环境,上面是从代码和 Win32 前台锁的文档行为推的。想钉死的话,同一台机器、同一会话里先 Brave 后 Firefox 各点一次,记录点击瞬间哪个窗口在前台,基本就能确认差异来自系统判定而不是代码分支。 |
Uh oh!
There was an error while loading. Please reload this page.
环境
@deepseek-ai/dsh,npm 安装),通过dsh web启动 Web UI复现步骤
dsh web,用 Firefox 打开 Web UI同一环境用 Brave 浏览器测试,对话框正常前置弹出,无此问题。
All reactions