[Bug][Windows][Desktop 0.2.0-rc.2] 点击系统通知无法聚焦/拉回主窗口

[keke309]

Bug 描述

在 Windows 桌面版 0.2.0-rc.2 中，点击系统通知或托盘图标，无法将 DeepSeek Harness 窗口聚焦到前台。

复现步骤

1. 打开 DeepSeek Harness 桌面版，将其最小化或置于后台。
2. 触发一个需要用户注意的通知（例如，Agent 发送一条新消息）。
3. 点击弹出的 Windows 系统通知。
4. 观察：DSH 窗口没有回到前台。

预期行为

点击通知后，DSH 窗口应恢复到前台并聚焦。

实际行为

点击通知无反应，窗口没有回到前台。但手动点击任务栏上的 DSH 图标可以正常恢复窗口。

环境信息

• DSH 版本：0.2.0-rc.2
• 操作系统：Windows 11

根因分析（已排查）

经过详细排查，问题的根本原因在于 DSH 的架构设计：

1. 通知创建位置：通知由渲染进程（Web 端）创建。
2. 事件处理：点击通知后，Electron 只能将事件回传至渲染进程（页面），而页面没有权限调用原生窗口 API（如 win.focus()）来激活主进程窗口。
3. 主进程功能：DSH 主进程内部其实有完好的 focusPrimaryWindow() 函数（包含 restore, show, focus 逻辑），但渲染进程没有 IPC 通道可以调用它。
4. 对比参考：类似 Hermes 的桌面应用，其通知在主进程创建，点击回调直接调用 focusWindow()，因此可以正常激活窗口。

建议修复方案

• 方案 A：在渲染进程和主进程之间增加一个 IPC 通道，允许页面请求主进程执行窗口聚焦操作。
• 方案 B：将通知的创建逻辑从渲染进程移至主进程，由主进程直接处理点击事件并调用 focusPrimaryWindow()。

PS：这个问题折腾了我很久，换了几个插件都没用，最后用本地模型和API跑了几百万token才排查出根因（钱包在滴血😭）。希望官方大大能早日修复，或者给页面开个IPC权限，非常感谢！

[PerryLink]

你的排查方向对：通知在渲染进程创建，而"把窗口拉回前台"只有主进程能做

1. 机制层面的关键分工

• 谁能操作窗口：show() / restore() / focus() 都是主进程（Electron main）的 BrowserWindow 能力；
• 谁创建了通知：你写"通知由渲染进程（Web 端）创建" ⇒ 点击事件落在渲染侧，它本身没有把窗口拉回前台的能力。

⇒ 所以链路必须是 渲染侧点击 ⇒ IPC 回主进程 ⇒ 主进程 restore + show + focus。这条链路缺一环，就是你看到的"点了没反应"；而"手动点任务栏图标能恢复"恰好说明窗口对象本身没坏，只是没人叫它到前台。

2. Windows 上还有第二个坑：前台锁定（foreground lock）

即使主进程调用了 focus()，Windows 也可能拒绝一个后台进程抢占前台（防焦点窃取）。⇒ 常见且有效的做法是"先置顶、再取消置顶"：

win.setAlwaysOnTop(true)
if (win.isMinimized()) win.restore()
win.show()
win.focus()
win.setAlwaysOnTop(false)

建议把这两层分开写在报告里（缺 IPC 路由 / 被前台锁定拦下），因为它们是两个不同的修法，维护者需要知道你说的是哪一个。

3. 请补三样（能立刻定性）

1. 通知是哪一个进程创建的（渲染侧用的是什么 API：Notification / 主进程的 new Notification？）；
2. 点击处理里有没有任何 IPC 到主进程（有的话，主进程收到后做了什么）；
3. 主进程窗口在该时刻的状态（isMinimized() / isVisible()）——你已在报告里写了根因分析，把这一段的关键结论贴出来即可。

4. 版本口径

你在 桌面 0.2.0-rc.2；⚠️ 当前最新是 0.2.1-alpha.1（0.1.7-rc.2 → 0.2.1-alpha.1 共 714 个提交，apps/desktop 94 个）。⇒ 桌面窗口与通知逻辑在这区间很可能被动过，请在新版复核后再定稿。

另：latest 现在 = 0.2.0-rc.2（我 09 月说的"latest 停在 0.1.5-rc.3"已废止，见登记表 §0.170）。桌面端有独立安装通道，请把你那份桌面构建版本号一并写上。

一条边界

我给出的是 Electron 的职责分工与 Windows 前台锁定这一通用机制（足以解释你的现象与那两个候选修法）。你这份构建里通知由谁创建、点击后走了什么以你的排查为准——我没有该构建的源码可读（桌面壳在打包产物内）。

[EliteOtaku]

补充实测：根因不在"缺 IPC 通道"，而在 focusPrimaryWindow() 抢前台的那一步

我也是这个问题的报告人（同一台机器、同一版本），做了一轮受控实验。结论：帖子里的根因分析（渲染进程没有 IPC 通道调用 focusPrimaryWindow()，建议新增 IPC 通道）不成立，真正卡住的是 focusPrimaryWindow() 内部。

1. 深链链路是通的，focusPrimaryWindow() 确实被执行

插件侧（dsh-notify-me 1.5.3）走的是页面隐藏 iframe 导航 dsh://open → 单实例锁 second-instance → focusPrimaryWindow()。我在真实点击时同步录制了进程与前台窗口变化，每次点击都触发了深链（出现一个短命的二次实例，随即被单实例锁转交）：

>>> DEEPLINK FIRED  throwaway pid=44152
      at fire: DSHforeground=False  minimized=False  visible=True  fg=微信
      outcome: NOT RAISED within 6s  <== FAILURE

所以"点了没反应"不是通道缺失——通道通了，失败发生在壳抢前台的最后一步。换 IPC 通道解决不了：即使换成 IPC，focusPrimaryWindow() 里的 show() + focus() 同样会被 Windows 前台锁拒绝。

2. 现象其实有明确分界：取决于窗口是否已最小化

点击通知时窗口状态	结果
已最小化	窗口正常回到前台 ✅
可见，但被别的程序压在后面	窗口纹丝不动 ❌

两种状态外观差别很小（都表现为"不在前台"），所以体感像随机失败。

3. 根因：apps/desktop/src/main.ts:1212

focusPrimaryWindow = () => {
  if (quitting) return
  if (isMandatory()) { mandatoryUI?.focus(); return }
  const window = welcomeWindow ?? mainWindow
  if (window === undefined || window.isDestroyed()) { /* ... */ return }
  if (window === mainWindow && !enteredWorkspace) return
  if (window.isMinimized()) window.restore()   // ← 只有"已最小化"时才走
  window.show()
  window.focus()                               // ← 遮挡场景只剩这个，被前台锁拒绝
}

窗口未被最小化时只会执行 show() + focus()，而后台进程仅凭 SetForegroundWindow（Electron 的 window.focus()）会被 Windows 前台锁（HKCU\Control Panel\Desktop\ForegroundLockTimeout，本机 200000 ms）拒绝。

4. 受控实验（真实 dsh://open 深链，非合成输入）

每次试验前用真实遮挡窗口建立前置条件并校验，每次同时确认深链是否触发：

场景	对应代码路径	深链触发	抬窗成功
(A) 窗口可见、其他程序占前台	show() + focus()	6/6	0/6 ❌
(B) 窗口已最小化、其他程序占前台	restore() + show() + focus()	6/6	5/6 ✅

纯 Win32 原语对照（窗口做成"可见但非前台"，不掺任何深链），确认这是 OS 层规则而非协议问题：

策略	成功
SetForegroundWindow（= 壳的 window.focus()）	0/6
minimize → restore	8/8
SetWindowPos(TOPMOST) → focus → 摘除置顶	0/3
SetWindowPos(TOPMOST) → focus（保持置顶）	0/4

另测：WS_EX_TOPMOST 能把窗口抬到遮挡窗口之上（Z 序 idx 0 vs 2），但拿不到键盘焦点；moveTop + focus 同样 0/1。

方法论提醒：合成输入（CDP evaluate / Input.dispatchMouseEvent）测不出这条链路——早期我用 Start-Process dsh://open 做遮挡测试，先后得到"失败"和"成功"两个矛盾结果，正是因为合成输入的前台授权状态不稳定。上表已全部改为可校验前置条件的对照设计。（这一点在 #8800 里也和 chromoany 讨论过。）

5. 修复建议

在 focusPrimaryWindow() 中，当窗口未被最小化但前台权被拒时，把"强制最小化再还原"作为兜底：

if (window.isMinimized()) window.restore()
window.show()
if (!window.isFocused()) {   // 前台权被前台锁拒绝时的兜底
  window.minimize()
  window.restore()
}
window.focus()

依据：minimize → restore 在遮挡场景 8/8 成功，而现有路径 0/6；同类问题 #8043（Windows 前台锁 + 窗口不弹前台）的修复方向也是"最小化 → 还原 → SetForegroundWindow"，手法一致。该兜底路径实测在 0.1s 内完成。

6. 版本口径

• 本机桌面端 0.2.0-rc.2（Electron 44.0.0），Windows 11 build 26300
• dsh-v0.2.1-alpha.1 的 apps/desktop/src/main.ts 与 0.2.0-rc.2 逐字节一致（SHA256 0FA49B658B970E19ED1C0F7D1E3EC55DD39F7E8236D282431484BA9C501B3EE8），所以本结论对当前最新版同样成立

7. 一条如实说明

"前台锁"是本现象最合理的解释，但我没有通过直接改写 ForegroundLockTimeout 做因果验证——本机 SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT) 始终返回 ERROR_INVALID_PARAMETER，无法生效。上表结论的因果依据是"同一窗口状态下，仅 focus() 失败而 minimize → restore 成功"这一对照，而非来自开关前台锁。另外"restore() 属于前台锁豁免路径"是推测，未单独验证。

---

复现脚本（真实深链 A/B + Win32 原语对照）我保留了完整版本，需要的话我贴出来或直接开 PR。

[PerryLink]

你的受控实验正好落在我们此前分开的那一层——而且它把另一半排除了

1. 你的实验否掉的是哪一半

我在这个问题的早期回复里给出过两层：

1. 缺 IPC 路由（渲染侧点击 → 需要 IPC 回主进程才能 show()/focus()）；
2. Windows 前台锁定（即便主进程调了 focus()，后台进程也可能被拒绝抢前台）。

⇒ 你这条实测把第 1 层排除了、把第 2 层坐实了：

• 深链链路是通的（dsh://open → 单实例锁 second-instance → focusPrimaryWindow()），且每次点击都触发（出现短命的二次实例、随即被单实例锁转交）⇒ 不是通道缺失；
• 失败在最后一步：DSHforeground=False minimized=False visible=True fg=微信 ⇒ NOT RAISED within 6s ⇒ 窗口存在、未最小化、可见，但没能被抬到前台。

⇒ 所以你写"换 IPC 通道解决不了"是对的：换通道后仍会走 show()+focus()，而它同样会被前台锁拒绝。⇒ 这一点很值得写进摘要——它阻止了维护者去做一个无效的改动。

2. ⇒ 可执行的修法（Windows 前台锁的常规处置）

对"后台进程抢前台被拒"这一类，Windows 上没有纯 API 的正解（前台权限归属于当前前台窗口的线程），但有一条被广泛使用的确定性绕法：

win.setAlwaysOnTop(true)
if (win.isMinimized()) win.restore()
win.show()
win.focus()
win.setAlwaysOnTop(false)

⇒ 原理是先改变窗口的 Z 序状态，使系统把它当作"用户可见的置顶窗口"来激活，再撤掉置顶。

建议诉求写成：

focusPrimaryWindow() 应当实现针对 Windows 前台锁的处置（例如上述"先置顶、再取消置顶"序列），而不是仅调用 show()+focus()；不要把这个缺陷当作"缺 IPC 通道"处理。

3. 你给的判据很干净（建议保留）

DSHforeground / minimized / visible / fg=<当前前台窗口> / NOT RAISED within Ns⇒ 这五个值就能判定"锁拒绝"而不是"窗口不存在"。⇒ 建议把它作为验收条件写出来：点击通知后，DSHforeground 应在 N 秒内变为 True。

4. 请补两样

1. focusPrimaryWindow() 的实现位置（哪个文件/函数）⇒ 有了它，修法就落到一行一行上；
2. 是否在任何前台窗口下都失败（你测到 fg=微信 ⇒ 换一个前台窗口再测一次即可）⇒ 若一致失败 ⇒ 确证是系统性前台锁，而非某个应用的干扰。

5. 一条边界

我确认的是**"两层假设"的框架以及你提供的实验数据与第 2 层吻合**。focusPrimaryWindow() 的具体实现我没有核（推荐你补第 4 节第 1 样；我没有该构建的源码可读）。

[EliteOtaku]

感谢回复。逐条回，但先更正我自己上一帖里的两组数据——它们不可信，我收回。

0. 更正：我上一帖的「纯 Win32 原语对照」表是装置污染的产物

我上一帖给了一张表（SetForegroundWindow 0/6、minimize→restore 8/8、置顶方案 0/3、0/4）。那张表测的不是策略，是我的 PowerShell 装置自己有没有前台权——因为那些实验里是我的脚本进程去调 SetForegroundWindow，它和被测策略争同一个前台权。

同一个策略在不同轮次的结果：

轮次	置顶→focus→取消置顶
第 1 轮	0/3
第 2 轮	0/14
第 3 轮	10/10
第 4 轮	12/12
第 5 轮	0/10

minimize→restore 同样：一会儿 8/8，一会儿 0/6。诊断跑直接显示了原因——装置自己在抢前台，SetForegroundWindow(cover) 返回 True 的那几轮，所有策略都"成功"；返回 False 的那几轮，所有策略都"失败"（连"什么都不做"的对照组都被算成失败）。

所以那张表作废。 抱歉，这是我的方法错误。

1. 可信的实验设计：让壳自己当执行者

排除装置污染的唯一办法是我的脚本绝不调用 SetForegroundWindow（也不调用会激活窗口的 ShowWindow(cover, SW_RESTORE)），只负责摆窗口状态、发真实 dsh://open 深链，让壳自己的 focusPrimaryWindow() 去抢前台。

四次独立实验（含一次随机交错顺序），每次校验前置条件与深链触发：

臂	各次结果	合计
A 窗口可见、未最小化（壳走 show()+focus()）	0/6、0/8、1/7、0/16	1/37 ≈ 3%
B 窗口已最小化（壳走 restore()+show()+focus()）	5/6、6/6、4/10	15/22 ≈ 68%

深链每次都触发（fired 6/6、8/8、7/7、16/16），所以失败在壳抢前台那一步，不在协议通道。

要点：minimize→restore 显著改善但不是确定性修复——仍有约 1/3 失败。我上一帖说它「8/8」是装置污染的产物，已更正。

另外：重试深链无效（A 臂改为连发两次，仍是 0/8），所以插件侧"多点几次"解决不了。

2. 回答你的问题 1：focusPrimaryWindow() 的实现位置

apps/desktop/src/main.ts（桌面壳在 resources/app.asar 内，我从打包产物里读的）：

// L63
let focusPrimaryWindow = (): void => {}

// L1212 — 定义
focusPrimaryWindow = () => {
  if (quitting) return
  if (isMandatory()) { mandatoryUI?.focus(); return }
  const window = welcomeWindow ?? mainWindow
  if (window === undefined || window.isDestroyed()) {
    try { createMainWindow() } catch (error) { reportFatal(error, 'main'); return }
    void (backend.state.phase === 'ready' ? openInitialWindow() : navigateMain(applicationUrl)).catch(...)
    return
  }
  if (window === mainWindow && !enteredWorkspace) return
  if (window.isMinimized()) window.restore()   // ← 只有已最小化时才走
  window.show()
  window.focus()                               // ← 其余情况只有这一条
}

调用点共 4 处（都在同一文件）：

行	触发场景
L470	登录态回跳（attempt.phase 为 failed/expired）
L989	托盘菜单「打开」
L1231	app.on('open-url') — macOS 的 dsh://open 通道
L1336	claimDesktopSingleInstance(app, () => focusPrimaryWindow()) — Windows 走的就是这条（second-instance 事件）

单实例封装在 apps/desktop/src/single-instance.ts：

export function claimDesktopSingleInstance(application, focusOwner) {
  if (!application.requestSingleInstanceLock()) { application.quit(); return false }
  application.on('second-instance', focusOwner)
  return true
}

所以插件侧那条链路是：隐藏 iframe → dsh://open → 系统启动二次实例 → 单实例锁把请求转交主实例 → second-instance → focusPrimaryWindow()。这条链是通的——下面 A 臂累计 37 次试验里，深链每次都触发了。

3. 回答你的问题 2：是否换任何前台窗口都失败

是——但我要如实标注样本分布。

用干净设计（壳为执行者、脚本不激活任何窗口），A 臂累计 37 次试验、深链全部触发、抬窗成功 1 次（2.7%）：

实验	结果
第 1 次	0/6
第 2 次	0/8
第 3 次（随机交错）	1/7
第 4 次（专项 16 连测）	0/16

遮挡方涵盖 Exness MT5（terminal64）、Edge、微信、Windows Terminal，没有出现"某个特定应用下就成功"的反例。

但我要标注一点：专项 16 连测那次遮挡方稳定落在 MT5，所以按应用分层的样本并不均衡；"与遮挡方无关"这个结论的强度，受限于我只能在外部观测、无法控制前台归属。若要这一条定论，建议壳侧直接在 focusPrimaryWindow() 里打点记录 isFocused() 结果，比我外部观测可靠得多。

（顺带更正我上一帖：我曾在受污染的装置下报过"微信 0/3、MT5 0/3、Edge 1/3"，那组数字不可用，已作废。）

4. 关于你建议的「先置顶、再取消置顶」：我测不出可信结论

这条我不判断对错，说明理由——这正是方法边界所在。

setAlwaysOnTop(true) 是主进程的 Electron API，只能由壳调用。我的脚本用 SetWindowPos(HWND_TOPMOST) 模拟时，就回到了"脚本进程自己抢前台"的污染状态（也正是让我上一帖那张表出错的原因）。所以在"壳自己当执行者"的可信设计里，我无法测这个策略。

我能确定的只有两点：

1. 置顶确实改变 Z 序：WS_EX_TOPMOST 让 DSH 从遮挡窗口之下（Z 序 idx 2）变到之上（idx 0），且摘除置顶后仍在上面。
2. 但它没拿到键盘焦点：在能给出可信数据的轮次里，置顶序列后 GetForegroundWindow() 仍不是 DSH。

⇒ 若目标是"用户能立刻打字"，置顶序列可能不够；若目标是"用户至少能看见窗口"，它可能有用。这需要壳侧实测。建议把它作为候选交给维护者验证，而不是当作已证结论。

5. 修正后的诉求

综合以上，我建议诉求这样写：

focusPrimaryWindow() 在窗口未最小化时只调用 show()+focus()，而后台进程的 SetForegroundWindow 会被 Windows 前台锁拒绝（本机 ForegroundLockTimeout=200000）。用「壳自己当执行者、脚本不参与抢前台」的干净设计实测（四次独立实验、每次校验深链触发）：

• 窗口已最小化（走 restore()+show()+focus()）→ 15/22 ≈ 68% 抬到前台；
• 窗口可见但被遮挡（走 show()+focus()）→ 1/37 ≈ 3%；
• 深链每次都触发（fired 6/6、8/8、7/7、16/16）⇒ 通道没问题，失败在抢前台那一步；
• 重试深链无效（连发两次仍 0/8）。

⇒ 建议 focusPrimaryWindow() 针对"窗口未最小化但抢前台失败"补兜底。minimize()+restore() 是已实测有效但非确定性的候选（68% vs 3%），可作为第一层；「先置顶、再取消置顶」是另一条候选，但需要壳侧实测确认它能否真正拿到焦点（见第 4 节）。

6. 关于你提的验收判据

同意，而且我这次就是这么判定的——DSHforeground / minimized / visible / 当前前台窗口 / 是否在 N 秒内变 True 这五个值足以区分「锁拒绝」和「窗口不存在」。建议验收条件写成：点击通知后，GetForegroundWindow() 应在 N 秒内等于主窗口句柄（而不是仅 isVisible()）。

---

最后说明一句：我上一帖的结论里，"深链链路是通的、失败在 focusPrimaryWindow() 内部"这一条经受住了这次更严格的方法检验（37 次试验深链全部触发，且窗口几乎都不上前台）；但"具体哪个替代序列最有效"我上一帖给的表是错的，以本贴为准。