[Bug][Desktop 0.2.0-rc.2][Windows] dsh-app:// 协议未注册 ServiceWorker 特权：通知类插件「点击跳回对话」「审批快捷裁决」整体失效

[EliteOtaku]

环境

• DeepSeek Harness 官方桌面端 0.2.0-rc.2（Electron 44.0.0，Windows 11 26200 x64）
• 场景：第三方客户端插件 dsh-notify-me（系统通知 + 点击通知跳回对应对话 + 审批通知快捷裁决）

问题

dsh-app://app 这个自定义协议源没有注册 Service Worker 特权，navigator.serviceWorker.register() 直接被拒：

Failed to register a ServiceWorker: The URL protocol of the current origin ('dsh-app://app') is not supported.

（可通过页面内 navigator.serviceWorker.register(...) 或任意依赖 SW 的插件复现；window.__dshNotifyMe.debug() 的 bridge 字段也直接打印了这条错误。）

实际影响（已实测）

1. 通知点击后无法把窗口带到前台：没有 SW 就没有 notificationclick，也就没有带用户激活的 clients.focus()；降级路径里页面侧的 window.focus() 没有用户激活，被 Chromium 无视。实测向插件的 BroadcastChannel 发 navigate: true 消息，dsh.sessions.current 正确切换（切会话逻辑完好），但窗口不被抬到前台——用户感知就是「点了通知没反应」。
2. 审批通知快捷裁决不可用：Notification action buttons 只存在于 SW 的 showNotification，页面 new Notification() 无法携带「同意 / 拒绝」按钮，相关开关自动退化。
3. 依赖 SW 的所有其他第三方插件能力在桌面端同样静默失效。

建议

给 dsh-app scheme 注册 serviceWorker 特权，即 webContents/protocol 层对自定义协议声明 registerServiceWorker: true（Chromium 要求自定义协议以 registerServiceSchemes/privilege 方式登记，Electron 下为 protocol.registerSchemesAsPrivileged([{ scheme: 'dsh-app', privileges: { /* standard, secure, ... */ serviceWorker: true } }]) 一类的声明级改动）。加特权后 SW 作用域、notificationclick、clients.focus() 均按标准语义生效，插件生态（通知类、离线缓存类、推送类）都能直接受益。

相关讨论：#8044（插件独立窗口 seam）解决的是「插件自己开窗口」，本帖是「插件把主窗口带到前台 + 使用标准通知通道」，两者互补。

复现

桌面端 0.2.0-rc.2 任意页面控制台：

navigator.serviceWorker.register('/sw.js', { type: 'module' }).then(r => console.log('ok', r)).catch(e => console.log('denied:', e.message))

[EliteOtaku]

收尾更新（报告人）

主要痛点已解决：「点击通知无法回到对话」已在插件侧修复——chromoany/dsh-notify-me 1.5.2 用 dsh://open 深链抬窗（页面隐藏 iframe → 协议回流 → 壳的 single-instance focusPrimaryWindow），本人在真实桌面端 0.2.0-rc.2 上端到端手测通过：通知点击后 DSH 上前台且切到对应对话。

顺带更正我此前的一条判断：我曾用 CDP 合成注入测得「沙箱 renderer 静默拦截外部协议」并推断该通道在真实壳不可用——这个结论被真实手测推翻。合成输入没有复现真实通知点击的激活/前台权利链条，合成观察不能外推。以真实手测为准。

SW 特权请求的剩余价值（供官方排期参考，本帖作为报告人先关闭，接手时可重开）：

• 审批通知快捷裁决（Notification action buttons 仅 registration.showNotification 可用，页面构造器不支持）——目前桌面端审批只能在页面内点；
• 未来依赖 Service Worker 的插件生态（离线、推送等标准 Web 能力）。

修法建议不变：protocol.registerSchemesAsPrivileged 给 dsh-app 增加 serviceWorker: true。感谢社区插件生态的快速迭代。

[PerryLink]

我找到了确切原因，而且是一行：特权块里没有 serviceWorkers

1. 现状（HEAD = dsh-v0.2.1-alpha.1）

apps/desktop/src/main.ts:132-142：

protocol.registerSchemesAsPrivileged([{
  scheme: SCHEME,
  privileges: {
    standard: true,
    secure: true,
    supportFetchAPI: true,
    corsEnabled: true,
    stream: true,
    codeCache: true,
    // ← 这里没有 serviceWorkers
  },
}])

⇒ serviceWorkers 这一项不在列。而 Electron 的自定义协议要让其源被当作可注册 Service Worker 的安全源，必须在应用 ready 之前的 registerSchemesAsPrivileged 里显式声明 serviceWorkers: true。

这与你报的错完全对应：

Failed to register a ServiceWorker: The URL protocol of the current origin ('dsh-a…') is not supported

⇒ 不是插件写错了，是协议特权没给。

2. 修法（一行）

privileges: {
  standard: true,
  secure: true,
  supportFetchAPI: true,
  corsEnabled: true,
  stream: true,
  codeCache: true,
  serviceWorkers: true,      // ← 新增
},

建议把诉求写成这样（可直接采纳）：

apps/desktop/src/main.ts:134-141 的特权对象应加入 serviceWorkers: true，使 dsh-app:// 源可注册 Service Worker；否则所有依赖 SW 的客户端插件（通知跳回、审批快捷裁决等）在该源下整体失效。

注意必须加在 registerSchemesAsPrivileged 里（即在 ready 之前）——运行期补注册是无效的。

3. 你这条的影响面写得很好（建议保留）

你指出不是某一个插件坏了，而是"通知类插件的一整类能力"失效（点击跳回对话、审批快捷裁决）。⇒ 这一点让优先级完全不同，因为 SW 是这些能力的共同前置。

建议补一句：这类失效是静默的（插件加载成功、只是 SW 注册被拒），所以插件作者很难自查——这也是为什么值得在框架侧修。

4. 请补两样

1. 是否还有其它插件/场景依赖 SW（例如离线缓存、后台同步）——影响面越大越值得优先；
2. 版本：你写桌面 0.2.0-rc.2；我核到的最新 0.2.1-alpha.1 仍缺该项 ⇒ 这条是当前存活项，已在最新版复核。

一条边界

我确认的是特权对象里确实没有 serviceWorkers（足以解释该报错）。Electron 版本对 serviceWorkers 特权项的支持与否以你们的实测为准——我没有在 Electron 44 上改这一项验证过。