桌面端 Windows：点击网页通知无法把窗口带到前台；dsh://open 第二实例 133 ms 后以退出码 1 结束，focusPrimaryWindow 也不恢复最小化窗口

[chromoany]

环境

• Windows 11 家庭版 中文版，10.0.26200
• 桌面端 @deepseek-ai/dsh-desktop 0.2.1-rc.2（app.asar 内 package.json）
• 触发方：网页层（dsh-app://app/ 主框架）里的系统通知，来自第三方插件 dsh-notify-me

现象

桌面端窗口被其他窗口盖住或最小化时，点击 Windows 通知横幅，窗口不会回到前台。通知的 onclick 确实执行了，navigator.userActivation.isActive === true、document.visibilityState === "hidden"，属于真实的用户激活；但页面里 window.focus() 对 Electron 原生窗口无效，也没有其他可用通道。

复现 A：系统协议

1. 启动桌面端、进入工作区。
2. 把主窗口最小化（ShowWindow/WM_SYSCOMMAND SC_MINIMIZE 均可）。
3. 在终端执行："<install-dir>\DeepSeek Harness.exe" dsh://open
4. 结果：第二进程约 133 ms 后退出，退出码 1；主窗口 IsIconic 仍为 True。

对照：不带任何参数重复第 3 步，第二进程约 258 ms 后以退出码 0 退出（正常的单实例让位），但最小化的主窗口依然没有恢复。

复现 B：页面内深链导航

页面里用隐藏 iframe 导航 dsh://open（放在通知点击的激活窗口内）没有任何效果；lib/main.js:12032 的 will-navigate 只放行 dsh-app: 和同源 http，dsh: 一律 preventDefault()，并且只有 http(s) 才转 shell.openExternal——从网页层这条路也走不通。

相关代码位置（0.2.1-rc.2）

• lib/main.js:12032 主窗口 will-navigate 守卫：非 dsh-app: 且非同源 http 的方案一律拦截。
• lib/main.js:13056 app.on("open-url") 处理 dsh://open → focusPrimaryWindow()，仅 macOS。
• lib/main.js:7658 claimDesktopSingleInstance()：requestSingleInstanceLock() 失败即 application.quit()，否则 application.on("second-instance", focusOwner)。
• lib/main.js:13184 调用点传入 () => focusPrimaryWindow()。
• lib/main.js:13031 focusPrimaryWindow()：if (window === mainWindow && !enteredWorkspace) return; 之后才 restore()/show()/focus()。
• lib/preload-app.cjs 暴露面只有 dshOnboarding、__DSH_DIRECTORY_PICKER__、__DSH_HOST_PATHS__、dshDesktopBoot、dshPlatform、dshDesktop、__DSH_LOCALE__；DESKTOP_IPC 里没有 focus/raise 类通道（windowFullscreen 只用于接收状态）。

推断：Windows 上带 dsh://open 的第二进程在进入单实例判定之前就以退出码 1 结束，主进程收不到 second-instance，focusPrimaryWindow() 不会执行；而无参重启虽然正常让位、second-instance 应已到达，但最小化窗口实测仍未恢复，说明 focusPrimaryWindow() 内部早退（enteredWorkspace 门控或 welcomeWindow 分支）。

期望行为

点击系统通知（或任何用户主动触发的深链）后，应用窗口应当像其他 Windows 程序一样被带到前台；最小化时先恢复。

建议

1. 给网页层一个最小化的、只允许 dsh-app://app 主框架调用的 IPC（例如 DESKTOP_IPC.focusWindow），实现 if (win.isMinimized()) win.restore(); win.show(); win.focus()。这样网页里的通知点击就有正规通道，不必依赖协议导航。
2. 修 Windows 下 dsh://open 的第二实例路径：确认带协议参数时为什么会以退出码 1 提前退出；并在 second-instance 回调里显式处理 argv 中的深链而不是一律「聚焦主窗口」。
3. focusPrimaryWindow() 对「用户主动唤醒」场景不要早退：至少在没有可见窗口时执行 show()/restore()，或按需 createMainWindow()。

备注

macOS 走 open-url，Windows 只能走 second-instance，所以这更像是 Windows 分支的问题，不是配置问题。

[chromoany]

补充：现象是间歇的

有反馈说这里其实「有时候能上前台」。补测后确认：点通知后窗口是否上前台不稳定，有时会，有时只切换会话。把 dsh://open 深链隔离出来测（带参启动 exe / 系统协议激活 / 真实最小化后再发，各 3 次）全部无效：带参第二实例每次约 130 ms 后退出码 1，不带参数约 260 ms 退出码 0，最小化后 IsIconic 保持 true。所以能抬起来的那些次，大概率是系统或 Chromium 在通知点击时激活了应用，不是深链。ForegroundLockTimeout 为 0，可以排除前台锁。原帖的复现与代码位置结论不变，只是预期改为「应稳定抬窗」，而不是「从未抬过」。

[xinming-chenniang]

补充一组实测（同版本：DSH Desktop 0.2.1-rc.2 / Windows 11 26100），有两点想修正和补上。

1. 「ForegroundLockTimeout = 0 可以排除前台锁」可能偏乐观

我直接拿 Win32 在同一个后台 PowerShell 里试了五种抬窗手法（窗口状态分两种；ForegroundLockTimeout 未改）：

手法	窗口最小化 + 别的应用在前台	窗口未最小化、被别的应用盖住
ShowWindow(SW_RESTORE)	有效	无效
SetForegroundWindow	有效	被拒（仍停在原前台窗口）
合成 ALT 键 + SetForegroundWindow	有效	有效
SwitchToThisWindow	—	无效
最小化 → 恢复	有效	有效

结论：只要窗口没最小化、而前台是别的应用，SetForegroundWindow 单独调用就是会被拒——这是调用级的前台锁规则，跟「锁超时」不是一回事（ForegroundLockTimeout 我这边也没动）。这和 #10446 里「有时能上前台」的间歇现象也吻合：能上的那些次，多半是系统/Chromium 在通知点击时把应用激活了。

对修复的直接影响：就算官方补上 IPC，实现里也别只写一句 win.focus()。建议至少 restore() → show() → focus()，并把「没最小化但仍被盖住」当成独立场景测一遍；如果实测被前台锁拒，再考虑补一次原生 SetForegroundWindow 或 setAlwaysOnTop(true→false) 之类的唤醒手法（这条我只在 Win32 侧验证过，Electron 主进程里没测，仅作提示）。

2. 官方 IPC 落地前，网页层已经有可用绕法

我在本机跑通了一条不需要改官方代码的路子，供其他通知插件作者参考：

• 宿主侧：ctx.inject(['webServer'], ctx => ctx.webServer.register({ kind: 'exact', path: '/__dsh-notification/focus-window', handler }))，handler 做 loopback + 同源校验，然后 spawn 一次 PowerShell 调上表里的兜底链（SW_RESTORE → SetForegroundWindow → ALT 抖动 → 最小化/恢复），脚本最后打印 FOCUSED=1|0，路由据此回 200/202，不假装成功。
• 页面侧：通知的 onclick 里 fetch('/__dsh-notification/focus-window', { method: 'POST', body: '{}' }).catch(() => {})。

实测结果（走真实 HTTP 路由，非直调）：

最小化 + 别的应用在前台 → 200 {"ok":true,"focused":true,"platform":"win32"} → IsIconic false，GetForegroundWindow = DSH 主窗口
未最小化、被盖住       → 200 {"ok":true,"focused":true,"platform":"win32"} → 同上

页面的 onclick 里 navigator.userActivation.isActive === true（和 #10446 主贴一致），所以页面侧确实有激活窗口的资格，缺的只是通往原生窗口的通道。代价是每个通知插件各写一套 PowerShell 和一个路由——这正是希望官方开 IPC 的理由。

3. 建议的 API 形状（贴合现有 preload 约定）

dshDesktop 现在有 browser / deviceInfo / keyboard / shortcuts / updates 几组，加一组最省事：

// preload-app
window.dshDesktop.window = {
  focus: () => ipcRenderer.invoke(DESKTOP_IPC.windowFocus),          // restore → show → focus
  isMinimized: () => ipcRenderer.invoke(DESKTOP_IPC.windowIsMinimized),
}

主进程侧复用现成约束：assertProductSender(event)（= assertDesktopSender(event, ["app"]) + 主 frame 校验，directoryPick 用的就是这套），落点 focusPrimaryWindow()——顺带把它里面 if (window === mainWindow && !enteredWorkspace) return; 这个早退在「用户主动唤醒」路径上放宽一点。

4. 一个现成的正例，说明能力已经有了

壳自己已经在主进程里弹带点击回调通知：DesktopUpdateAttention 用 new Notification({...}) + notification.once("click", …)，点击直接走聚焦，不需要经过渲染进程。#8711 里说的「通知由渲染进程创建，所以只能回传给页面」是第三方插件的处境，不是壳的；壳这边能力是现成的，缺的只是给 dsh-app://app 主框架开一个最小入口。

备注

• 我先给相关第三方插件（nishit130/dsh-notification）提了 issue（#3），因为它那边 Windows 桌面通道用未注册 AUMID、toast 根本不显示，会让人误以为是「点了没反应」，实际根本没弹出来——这会污染这个问题的复现数据。
• 上面第 2 条的绕法我也验证过跨源会被 403 拒掉，所以开这条路由不会给页面之外的来源留口子。

[chromoany]

@xinming-chenniang 这组表我拿真窗口复测了一遍，结论对得上，而且第 1 条正好是修复的关键。

复测条件同版本 0.2.1-rc.2 / Windows 11，powershell.exe 5.1 从后台进程发起，ForegroundLockTimeout 未改：

场景	结果	实际停在哪一步
窗口已在前台	成功	无需操作
最小化 + 别的应用在前台	成功	恢复后 ALT 抖动 + SetForegroundWindow
未最小化、被别的应用盖住	成功	ALT 抖动 + SetForegroundWindow

三场景各跑 3 次全成功，wall 618–782 ms（含 PowerShell 启动与 Add-Type 编译的 200–240 ms）。第二场景每次都是合成 ALT 之后那一步过的，SW_MINIMIZE→SW_RESTORE 兜底链一次没触发。所以对「未最小化被盖住」，ALT 抖动是必要的那一步，恢复只是最小化场景的前提。

顺带补三条对官方修复的直接影响：

1. focusPrimaryWindow 里的 if (window.isMinimized()) window.restore(); window.show(); window.focus(); 在「未最小化被盖住」这条路径上三步都不解决问题：从外面看窗口没最小化，restore() 直接跳过，show() / focus() 在 Electron 里也过不了前台锁。补 IPC 时这条路径上得再加一次原生 SetForegroundWindow，而且要先合成一次 ALT 抖动（keybd_event(VK_MENU) 15 ms down/up）给当前线程拿前台权限，否则调用级前台锁会稳定拒掉。这件事只能主进程做。
2. 判状态别信 window.isMinimized()。Chromium 的 window_state 只反映内部状态：从外面 ShowWindow(hwnd, SW_MINIMIZE) 之后它仍是 false，而 IsIconic(hwnd) 是 true。所以真实最小化只能取原生 IsIconic。
3. 如果最终不走 IPC 而走 HTTP 路由，注意 forwardWebRequest 会把 origin / cookie / sec-fetch-site 剥掉再注入宿主 cookie，路由侧拿不到可靠的 Origin 做同源校验，得换个闸门，比如要求一个跨源发不出的自定义头（预检没人应答）。

两个边界也一并算进去了：目标窗口属于提权进程时 SetForegroundWindow 仍会被拒；窗口在另一个虚拟桌面时不会切过去。这两种情况应当如实报失败，而不是假装成功；因此 focus() 返回 Promise<boolean> 比返回 void 有用。

第 4 条那个形状我赞同：dshDesktop.window.focus() / isMinimized()，复用 assertProductSender + 主 frame 校验，落点就是 focusPrimaryWindow，顺带把它里面 if (window === mainWindow && !enteredWorkspace) return; 在「用户主动唤醒」路径上放宽。

[xinming-chenniang]

@chromoany 谢谢复测，三处都对上了，第 2 条顺着你的提醒改了一版。

关于第 2 条（Origin 拿不到）：你说得对，forwardWebRequest 会剥掉 origin / cookie / sec-fetch-site。但自定义头挡不住 rebinding —— rebinding 出来的恶意页对目标来说是同源的，能发任意自定义头，也不会触发预检。真正有效的闸门是 Host：壳转发时 host 也一起被删、由 fetch 按目标 URL 重设成 127.0.0.1:<port>，而 rebinding 的页面 Host 仍是自己的域名。所以我把守卫改成三层：remoteAddress loopback → Host 必须是 loopback 名（127.0.0.1 / localhost / [::1]，可带端口）→ 有 Origin 时必须与 Host 同源，OPTIONS 回 405 不应答预检。

实测（Windows 11 / 0.2.1-rc.2，走真实路由）：

POST  Host: 127.0.0.1:<port>  → 200 {"ok":true,"focused":true,"platform":"win32"}
POST  Host: localhost:<port>  → 200（同上）
POST  Host: evil.example      → 403 {"ok":false,"code":"bad-host"}
POST  Origin: http://evil.example → 403 {"code":"cross-origin"}
OPTIONS                       → 405 {"code":"method-not-allowed"}

注意 Host 那条要用原始 HTTP 测，fetch 会用自己的 URL 覆写 Host，测不出区别（我第一次就被它骗了一次「200」）。

关于第 1 条：我实现里的顺序和你测出来的一致——IsIconic 为真就先 SW_RESTORE，然后 SetForegroundWindow，被拒就合成 ALT（down/up 背靠背，等 150 ms）重试，再失败才 SW_MINIMIZE→SW_RESTORE。最小化场景 restore 之后就过了，未最小化被盖住必须靠 ALT，兜底链同样一次没触发过。

关于第 3 条：赞同 focus(): Promise<boolean>。我这边失败（找不到窗口 / 前台锁没拿下来 / 提权窗口 / 其他虚拟桌面）统一回 focused:false + HTTP 202，不假装成功——日志里能看到是"找到了 HWND 但没抢到前台"还是"根本没找到窗口"。

一个提醒：dsh web 的端口每次启动都变（我这边从 58865 变成 59824），所以路由和验收脚本里别写死端口，从运行时 URL 取。

[chromoany]

@xinming-chenniang rebinding 这条是我说错了，已经在自己的路由上复现并改掉。

原先只有一道自定义头。拿真 socket 打：POST + Host: evil.example + Origin: http://evil.example + 那个头 → 200 {"focused":true}，确实进了 OS 激活路径；GET 带外域 Host 也 200。你说得对，rebinding 在浏览器眼里就是同源，头挡不住。现在按你的三层来：loopback 对端 → Host 必须是 loopback 名 → 有 Origin 就必须和 Host 同源，不符回 403（bad-remote / bad-host / cross-origin），OPTIONS 一律 405。同一条请求现在回 403 bad-host。Host 那条确实得用原始 HTTP 测，fetch 会自己覆写，我第一次也被它骗出一个 200。

三点补充，可能有用于官方实现：

• 桌面转发链上 origin 和 sec-fetch-site 都会被删掉，所以 Origin 这一层在桌面路径上永远不触发，真正扛事的只有 Host。Sec-Fetch-Site 也别指望：rebinding 页面发出来的是 same-origin。
• 顺手量到：宿主对插件注册的路由没有统一鉴权，不带 cookie 的裸 POST 也能直接进 handler。也就是说闸门必须插件自己写，官方如果统一加一层，这个 Host 校验就可以退成纵深防御。
• GET 探测我也一起收进闸门了（同一条规则），装完用浏览器打开确认路由在不在仍然可用——浏览器地址栏发的就是 loopback Host。

激活顺序跟你一致（IsIconic → SW_RESTORE → SetForegroundWindow → ALT 抖动重试 → 最小化/恢复兜底），9 次真机里兜底那步同样一次没触发。focus(): Promise<boolean>、失败统一 focused:false + 202 不假装成功，这个口径我也照做了。端口没写死：页面侧是相对路径 fetch('/__dsh-notify-me/focus-window')，宿主侧不拼 host。