dsh-notify-me 1.9.4 → 1.9.5

package/CHANGELOG.md

@@ -2,6 +2,18 @@
 
 All notable changes to **dsh-notify-me** are documented here.
 
+## [1.9.5] — 2026-10-20
+
+### 说明
+
+- **修正 1.9.4 的口径过重**：实测补充了「有时能上前台」的反馈后重测——1.9.4 说的「0.2.1-rc.2 上失效」不准确，实际是**不稳定**：有时窗口会上前，有时只切对话。
+- 复测方法：把 `dsh://open` 深链单独拿出来，三种走法（直接带参启动 exe、走系统协议激活、`WM_SYSCOMMAND` 真实最小化后再发）各 3 次，**全部失败**——带参第二实例每次约 130 ms 后退出码 1（不带参数约 260 ms 退出码 0，正常单实例让位），最小化窗口的 `IsIconic` 每次保持 `true`。⇒ 能抬起来的那些次大概率是系统/Chromium 在通知点击时自己激活了窗口，不是深链。
+- README（中英）与设置页提示改为「不稳定」，并写明隔离复测结论；上游 [discussions #10446](https://github.com/deepseek-ai/deepseek-harness/discussions/10446) 待补充这条「间歇」信息。
+
+### 测试
+
+- `npm test` 两套件通过（`ALL SMOKE TESTS PASSED ✔` / `cordis-host-test passed`）。
+
 ## [1.9.4] — 2026-10-20
 
 ### 说明

package/README.en.md

@@ -146,7 +146,7 @@ The overlay only knows which screen the window is on, not which screen you are l
 - **Stay quiet for the conversation on screen** (on): a wait belonging to the conversation you are looking at keeps only the tab marker so the approval card stays readable; backgrounding restores alerts;
 - **Also alert "reply finished" while the page is open** (off): by default only background finishes alert;
 - **Ignore subagent sessions** (on): skip background sessions spawned by a subagent — the parent conversation covers them; the one you have open still alerts;
-- **Click a toast to open that conversation** (on): the click switches to the conversation that raised it; in a browser it also brings the window forward, while on the Desktop shell whether the native window comes forward depends on the shell version (see [How the Desktop window gets raised](#how-the-desktop-window-gets-raised)); with several tabs open only one is raised, and off means a click does nothing.
+- **Click a toast to open that conversation** (on): the click switches to the conversation that raised it; in a browser it also brings the window forward, while on the Desktop shell it is flaky — sometimes the window comes forward, sometimes only the conversation switches (see [How the Desktop window gets raised](#how-the-desktop-window-gets-raised)); with several tabs open only one is raised, and off means a click does nothing.
 
 ### Try it
 
@@ -182,7 +182,7 @@ Off by default. Supports Discord Webhook / Bark / Gotify / custom webhooks. Aler
 
 ### Runtime & diagnostics
 
-The last block inside Advanced. The page protocol is detected automatically to tell Web from Desktop (`dsh-app://`); override it by hand if detection is wrong — Desktop clicks fire the `dsh://` deep link (whether that actually raises the window depends on the shell version — see [How the Desktop window gets raised](#how-the-desktop-window-gets-raised)) and carry no quick-decision buttons, while Web uses `window.focus()` plus the Service Worker bridge. When the override disagrees with detection the page says so.
+The last block inside Advanced. The page protocol is detected automatically to tell Web from Desktop (`dsh-app://`); override it by hand if detection is wrong — Desktop clicks fire the `dsh://` deep link (the effect is unreliable — see [How the Desktop window gets raised](#how-the-desktop-window-gets-raised)) and carry no quick-decision buttons, while Web uses `window.focus()` plus the Service Worker bridge. When the override disagrees with detection the page says so.
 
 <details>
 <summary>Alert language, Desktop window raising, reset</summary>
@@ -305,7 +305,11 @@ DSH Desktop is a thin Electron shell and its page lives under `dsh-app://app`: D
 
 Verified on the real shell (DSH Desktop 0.2.0-rc.2, three rounds of retesting in issue #9): a toast click raises the window and switches the conversation in one step, stable across sessions and with the window in the background. Timing of the fire is what makes the chain work: the deep link must be launched from a **user-gesture handler** — the notification's `onclick` carries one, which is why the product path works — while gesture-less scripted injection (an iframe appended from a CDP evaluate, say) is silently dropped by Chromium and the external protocol never launches, which looks exactly like the channel being blocked.
 
-**Regression on 0.2.1-rc.2 / Windows** (measured 2026-10-20): the toast click handler still runs (`navigator.userActivation.isActive === true`, `visibilityState` is `hidden`), but the window no longer comes forward. Shell-side evidence: launching a second instance with the `dsh://open` argument exits with code 1 after 133 ms, while launching it without arguments exits with code 0 after 258 ms (the normal single-instance yield), so the URL branch is what breaks. Minimizing the window for real via `WM_SYSCOMMAND` and then firing the deep link — or relaunching with no arguments — leaves `IsIconic` at `true`, so `focusPrimaryWindow()`'s `restore()` never takes effect. There is no page-side fallback either: the shell preload only exposes `dshDesktop`, the directory picker and locale, and `DESKTOP_IPC` has no focus/raise channel. The repro and code locations are filed upstream in [deepseek-harness discussions #10446](https://github.com/deepseek-ai/deepseek-harness/discussions/10446). The plugin's part ends there: it still fires the deep link; raising the native window is the shell's call.
+**Flaky on 0.2.1-rc.2 / Windows** (measured 2026-10-20): the toast click handler still runs (`navigator.userActivation.isActive === true`, `visibilityState` is `hidden`), but whether the window actually comes forward is inconsistent — sometimes it does, sometimes only the conversation switches while the window stays put.
+
+Do not count on the plugin's own path: isolating the `dsh://open` deep link (three ways, three runs each — launching the exe with the argument, OS protocol activation, and a real `WM_SYSCOMMAND` minimize followed by the deep link) failed **every time**. The second instance with the argument exits with code 1 after ~130 ms (without arguments it exits with code 0 after ~260 ms, the normal single-instance yield), and after a real minimize `IsIconic` stays `true`. So the times it does come forward are most likely the OS/Chromium activating the app on the notification click itself, not the deep link.
+
+There is no page-side fallback either: the shell preload only exposes `dshDesktop`, the directory picker and locale, `DESKTOP_IPC` has no focus/raise channel, and the main window's `will-navigate` rejects `dsh:` URLs outright. The repro and code locations are filed upstream in [deepseek-harness discussions #10446](https://github.com/deepseek-ai/deepseek-harness/discussions/10446).
 
 </details>
 
@@ -315,7 +319,7 @@ Verified on the real shell (DSH Desktop 0.2.0-rc.2, three rounds of retesting in
 - Notifications appear through the browser, so the browser needs "show notifications" permission in the OS notification settings, and notification-center "Do Not Disturb" must not suppress them.
 - The first sound/toast of each page load needs one user click on the page first (browser autoplay + permission policy).
 - Toasts are only produced once the notification permission is granted; declining means sound + title marker only.
-- On the Desktop shell (DSH Desktop 0.2.1-rc.2 / Windows) a toast click no longer brings the window forward by itself: the plugin fires the `dsh://open` deep link, but the shell does not raise the window ([discussions #10446](https://github.com/deepseek-ai/deepseek-harness/discussions/10446)). Switching to the conversation still works.
+- On the Desktop shell (DSH Desktop 0.2.1-rc.2 / Windows) a toast click does not reliably bring the window forward: sometimes it does, sometimes only the conversation switches. The plugin's `dsh://open` deep link on its own failed 3/3 in isolation (see [How the Desktop window gets raised](#how-the-desktop-window-gets-raised)), so when it does come forward it is most likely the OS/Chromium activating the app on the notification click itself ([discussions #10446](https://github.com/deepseek-ai/deepseek-harness/discussions/10446)).
 - System notification banners are drawn on the primary display only: Windows has no setting and Chromium no API to aim one at another monitor, so on a multi-monitor setup the second screen never receives them. Use the in-page overlay for that — it follows the DSH window to its display.
 - Quick-decision buttons need a Service Worker: they work on `http://127.0.0.1` and `https`, not on plain `http://192.168.x.x`-style LAN addresses, and some browsers or desktop hosts never render notification buttons. **The Desktop (`dsh-app://`) is tested and cannot register a Service Worker**, so buttons never render there and approval toasts fall back to their buttonless form. The `bridge` field of `window.__dshNotifyMe.debug()` says why; everything else keeps working.
 - macOS: in the browser, alerts, sounds, the title marker and toast-click navigation carry no OS assumptions and work as on Windows. Two caveats: DSH Desktop (Electron) notifications require the app to be code-signed — unsigned builds simply emit no notification — and whether the official macOS build satisfies that is untested; and notification buttons on the macOS desktop host are likewise untested (the Windows desktop host is tested and renders none, see the line above), falling back to the buttonless form above.

package/README.md

@@ -142,7 +142,7 @@ Windows 的系统通知横幅固定画在主屏上，系统没有设置项、浏
 - **当前对话不弹通知**（默认开）：等待就发生在你正看着的对话里时只留标签页标记，免得挡住审批卡片；切到后台后照常提醒，若你已处理掉就作废；
 - **页面打开时也提醒「回复完成」**（默认关）：默认只在切到后台时提醒，避免打扰；
 - **子代理会话不提醒**（默认开）：跳过后台子代理（subagent）会话——它们是主对话那一轮的步骤，完成由主对话自己的提醒覆盖；你当前打开的那个子代理会话照常提醒；
-- **点击通知回到对应对话**（默认开）：点通知切到提醒所属的对话；浏览器里同时把窗口带到前台，桌面端能不能上前台看壳的版本（见[桌面端怎么抬窗的](#桌面端怎么抬窗的)）；多个标签页同时开着时只调起一个（优先当前可见的那个）；关掉后点通知不做任何事。
+- **点击通知回到对应对话**（默认开）：点通知切到提醒所属的对话；浏览器里同时把窗口带到前台；桌面端不稳定——有时窗口会上前，有时只切对话（见[桌面端怎么抬窗的](#桌面端怎么抬窗的)）；多个标签页同时开着时只调起一个（优先当前可见的那个）；关掉后点通知不做任何事。
 
 ### 试一试
 
@@ -178,13 +178,13 @@ Windows 的系统通知横幅固定画在主屏上，系统没有设置项、浏
 
 ### 运行环境与诊断
 
-在「高级设置」最后一块。默认自动识别当前是 Web 端还是桌面端（DSH Desktop，`dsh-app://`）；识别不准时可手动指定——桌面端点通知走 `dsh://` 深链调窗（能否真的上前台看壳的版本，见[桌面端怎么抬窗的](#桌面端怎么抬窗的)）、通知上不带快捷裁决按钮；Web 端走 `window.focus()` 与 Service Worker 桥。手动覆盖与自动识别不一致时，设置页会明示检测结果。
+在「高级设置」最后一块。默认自动识别当前是 Web 端还是桌面端（DSH Desktop，`dsh-app://`）；识别不准时可手动指定——桌面端点通知走 `dsh://` 深链调窗（效果不稳定，见[桌面端怎么抬窗的](#桌面端怎么抬窗的)）、通知上不带快捷裁决按钮；Web 端走 `window.focus()` 与 Service Worker 桥。手动覆盖与自动识别不一致时，设置页会明示检测结果。
 
 <details>
 <summary>通知语言、桌面端抬窗与恢复默认</summary>
 
 - **通知语言**：跟随界面 / 简体中文 / English——决定通知文字与 `🔔 …` 标题标记使用的语言；
-- **桌面端怎么抬窗**：页面侧的 `window.focus()` 在 Electron 里抬不动原生窗口，1.5.2 起改走应用自己的 `dsh://open` 深链调窗——在 DSH Desktop 0.2.0-rc.2 上实测有效，0.2.1-rc.2 在 Windows 上失效（详见下一节）；
+- **桌面端怎么抬窗**：页面侧的 `window.focus()` 在 Electron 里抬不动原生窗口，1.5.2 起改走应用自己的 `dsh://open` 深链调窗——在 DSH Desktop 0.2.0-rc.2 上实测有效，0.2.1-rc.2 在 Windows 上不稳定（详见下一节）；
 - **恢复默认设置**：把所有开关与音效设置还原成出厂值（不动外部推送目标和已选的自定义音频文件）。
 
 </details>
@@ -301,7 +301,11 @@ DSH Desktop 是一层 Electron 壳，页面跑在 `dsh-app://app` 下：DOM 的
 
 真实壳已实测（DSH Desktop 0.2.0-rc.2，issue #9 三轮复测）：点通知 = 抬窗 + 切会话一步到位，跨会话、窗口在后台时同样稳定。触发时机是这条链路的关键：深链必须在**带用户手势的处理器**里发——通知的 `onclick` 自带手势，所以产品路径通；而无手势的脚本化注入（如 CDP evaluate 手工塞 iframe）会被 Chromium 静默丢弃、外部协议根本不回流，复现时看起来就像「通道被拦死」。
 
-**0.2.1-rc.2 在 Windows 上失效**（2026-10-20 实测）：点通知的回调照常执行（`navigator.userActivation.isActive === true`、`visibilityState` 为 `hidden`），但窗口不再上前台。壳侧可复现的证据：带 `dsh://open` 参数启动第二实例，133 ms 后以退出码 1 结束；不带参数时 258 ms 退出码 0（正常的单实例让位），说明问题出在 URL 参数那条分支。把窗口用 `WM_SYSCOMMAND` 真实最小化后，无论发深链还是无参重启，`IsIconic` 都保持 `true`，`focusPrimaryWindow()` 的 `restore()` 没有实际生效。页面侧也没有替代通道：壳的 preload 只暴露 `dshDesktop`、目录选择、本地化这些，`DESKTOP_IPC` 里没有 focus/raise 类通道。已把复现步骤与代码位置提交到 [deepseek-harness discussions #10446](https://github.com/deepseek-ai/deepseek-harness/discussions/10446)。插件侧能做的到此为止：深链照发，原生窗口抬不抬由壳决定。
+**0.2.1-rc.2 在 Windows 上不稳定**（2026-10-20）：点通知的回调照常执行（`navigator.userActivation.isActive === true`、`visibilityState` 为 `hidden`），但窗口是否上前台时灵时不灵——有时会，有时只切对话、窗口不动。
+
+插件这一侧为什么不能指望：把 `dsh://open` 深链单独拿出来复测（三种走法各 3 次：直接带参启动 exe、走系统协议激活、`WM_SYSCOMMAND` 真实最小化后再发），**全部失败**——带参第二实例每次都在约 130 ms 后以退出码 1 结束（不带参数则约 260 ms 退出码 0，属正常单实例让位），最小化窗口的 `IsIconic` 每次都保持 `true`。也就是说，能抬起来的那些次，多半是系统/Chromium 在通知被点击时自己激活了应用窗口，不是插件发的深链起了作用。
+
+页面侧也没有替代通道：壳的 preload 只暴露 `dshDesktop`、目录选择、本地化这些，`DESKTOP_IPC` 里没有 focus/raise 类通道；主窗口的 `will-navigate` 对 `dsh:` 一律 `preventDefault()`。复现步骤与代码位置已提交到 [deepseek-harness discussions #10446](https://github.com/deepseek-ai/deepseek-harness/discussions/10446)。
 
 </details>
 
@@ -309,7 +313,7 @@ DSH Desktop 是一层 Electron 壳，页面跑在 `dsh-app://app` 下：DOM 的
 
 - 页面必须开着才会提醒（后台标签/最小化可以；关标签页即失效——浏览器层方案固有限制）。
 - 通知经由浏览器弹出，需允许浏览器通知权限，且勿扰模式不能屏蔽它。
-- 桌面端（DSH Desktop 0.2.1-rc.2 / Windows）点通知不再自动把窗口带到前台：插件能发 `dsh://open` 深链，壳侧却没把窗口抬起来（[discussions #10446](https://github.com/deepseek-ai/deepseek-harness/discussions/10446)）；切到对应对话不受影响。
+- 桌面端（DSH Desktop 0.2.1-rc.2 / Windows）点通知后窗口不一定上前台：有时会，有时只切对话。插件发的 `dsh://open` 深链单独复测 3/3 无效（详见[桌面端怎么抬窗的](#桌面端怎么抬窗的)），能抬的时候多半是系统/Chromium 在通知激活时自己把窗口带起来了（[discussions #10446](https://github.com/deepseek-ai/deepseek-harness/discussions/10446)）。
 - 系统通知横幅只画在主屏：Windows 没有设置项、Chromium 没有 API 能把它指到别的显示器（多屏时副屏收不到系统通知）。要用副屏提醒，开「页面浮层提醒」，它会跟着 DSH 窗口走。
 - 每次页面加载后第一次出声/弹通知前，需在页面上点击过一次（浏览器自动播放与权限策略）。
 - 未授权通知权限时只有提示音与标题标记。

package/lib/client.js

@@ -1937,7 +1937,7 @@
       });
     } catch (e) {}
     // keep in sync with package.json "version" on every release
-    api.version = "1.9.4";
+    api.version = "1.9.5";
     api.setConfig = function (patch) { return setConfigLocal(patch); };
     api.resetConfig = function () {
       try {
@@ -2073,7 +2073,7 @@
       enable: "启用提醒",
       enableHint: "关闭后不弹通知、不响提示音，也不改标签页标题。",
       hostEnv: "运行环境",
-      hostEnvHint: "默认自动识别：页面协议是 dsh-app:// 即桌面端（DSH Desktop），其余为 Web 端。识别不准时手动指定：桌面端走 dsh:// 深链调窗（能否真的上前台看壳的版本）、快捷裁决按钮不可用；Web 端走 window.focus() 与 Service Worker 桥。",
+      hostEnvHint: "默认自动识别：页面协议是 dsh-app:// 即桌面端（DSH Desktop），其余为 Web 端。识别不准时手动指定：桌面端走 dsh:// 深链调窗（效果不稳定）、快捷裁决按钮不可用；Web 端走 window.focus() 与 Service Worker 桥。",
       hostEnvAuto: "自动识别（推荐）",
       hostEnvDesktop: "桌面端（DSH Desktop）",
       hostEnvWeb: "Web 端（浏览器）",
@@ -2200,7 +2200,7 @@
       enable: "Enable reminders",
       enableHint: "When off: no toasts, no sounds, and the tab title is left alone.",
       hostEnv: "Environment",
-      hostEnvHint: "Auto-detect by default: a dsh-app:// page is the Desktop (DSH Desktop) shell, anything else is the Web. Override it if detection comes out wrong: on the Desktop a toast click fires the dsh:// deep link (whether the window actually comes forward depends on the shell version) and quick-decision buttons are unavailable; on the Web it is window.focus() plus the Service Worker bridge.",
+      hostEnvHint: "Auto-detect by default: a dsh-app:// page is the Desktop (DSH Desktop) shell, anything else is the Web. Override it if detection comes out wrong: on the Desktop a toast click fires the dsh:// deep link (the effect is unreliable) and quick-decision buttons are unavailable; on the Web it is window.focus() plus the Service Worker bridge.",
       hostEnvAuto: "Auto-detect (recommended)",
       hostEnvDesktop: "Desktop (DSH Desktop)",
       hostEnvWeb: "Web (browser)",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dsh-notify-me",
-  "version": "1.9.4",
+  "version": "1.9.5",
   "description": "离开 DSH 页面也能收到提醒：需要你操作 / 后台回复完成时发系统通知、标题标记与可选页面浮层（副屏也能看见），支持审批快捷裁决与外部推送。Brand icon and a reworked settings page in 1.9.0.",
   "license": "MIT",
   "type": "module",