Summary
There are two ShowToast implementations in the tray with divergent behaviour. App.ShowToast honours the user's sound preference (None/Subtle/Default) and a 30-second deduplication window. NodeService.ShowToast does neither — it just fires ToastContentBuilder().Show(). Capture/record paths route through NodeService.ShowToast, so screen-record / camera-clip / camera-blocked / capture-complete toasts ignore the user's sound setting.
Where
- Divergent:
src/OpenClaw.Tray.WinUI/App.xaml.cs:3823 (App.ShowToast) vs src/OpenClaw.Tray.WinUI/Services/NodeService.cs:1786 (NodeService.ShowToast)
- Callers using the wrong path:
Toast_ScreenCaptured — NodeService.OnScreenCapture (~line 1367)
Toast_ScreenRecordingComplete — NodeService.OnScreenRecord (~line 1402)
Toast_CameraBlocked — NodeService.OnCameraSnap/OnCameraClip (~lines 1430, 1465)
Why it matters
These toasts fire on privacy-sensitive operations (screen capture, camera). A user who silenced toasts because they're in a meeting or recording video gets unexpected sound. Worse: the toasts fire on attacker-controllable triggers (any screen.snapshot succeeds throttled-once-per-10s).
Proposed fix
Delete NodeService.ShowToast. Route capture/record toasts through App.ShowToast (or equivalent helper that honours preferences and dedup).
Add a regression test: set sound preference to None, fire a capture, assert no PlaySound invocation (or use a mockable toast service and assert the routing).
Note on root cause
This is one of several findings where copy/paste in NodeService diverged from the original in App. Filing a structural duplication issue separately to catalog the broader pattern.
Severity
Bug — privacy/UX regression visible on every screen-capture invocation.
Summary
There are two
ShowToastimplementations in the tray with divergent behaviour.App.ShowToasthonours the user's sound preference (None/Subtle/Default) and a 30-second deduplication window.NodeService.ShowToastdoes neither — it just firesToastContentBuilder().Show(). Capture/record paths route throughNodeService.ShowToast, so screen-record / camera-clip / camera-blocked / capture-complete toasts ignore the user's sound setting.Where
src/OpenClaw.Tray.WinUI/App.xaml.cs:3823(App.ShowToast) vssrc/OpenClaw.Tray.WinUI/Services/NodeService.cs:1786(NodeService.ShowToast)Toast_ScreenCaptured—NodeService.OnScreenCapture(~line 1367)Toast_ScreenRecordingComplete—NodeService.OnScreenRecord(~line 1402)Toast_CameraBlocked—NodeService.OnCameraSnap/OnCameraClip(~lines 1430, 1465)Why it matters
These toasts fire on privacy-sensitive operations (screen capture, camera). A user who silenced toasts because they're in a meeting or recording video gets unexpected sound. Worse: the toasts fire on attacker-controllable triggers (any
screen.snapshotsucceeds throttled-once-per-10s).Proposed fix
Delete
NodeService.ShowToast. Route capture/record toasts throughApp.ShowToast(or equivalent helper that honours preferences and dedup).Add a regression test: set sound preference to None, fire a capture, assert no
PlaySoundinvocation (or use a mockable toast service and assert the routing).Note on root cause
This is one of several findings where copy/paste in
NodeServicediverged from the original inApp. Filing a structural duplication issue separately to catalog the broader pattern.Severity
Bug — privacy/UX regression visible on every screen-capture invocation.