Repository navigation
[windows] Desktop notifications never reach Windows; in-app banner misattributes to system settings. #4660
Description
[windows] Desktop notifications never reach Windows; in-app banner misattributes to system settings. On Windows 11, the app shows "Desktop notifications are blocked. Enable them in your system settings" — but Buzz never appears in Settings → Notifications' app list, and HKCU...\Notifications\Settings contains no xyz.block.buzz.app entry, i.e. no toast was ever registered. The WebView2 profile's notification permission map is empty (not denied); even with an explicit "setting":1 grant for http://tauri.localhost:80,* in the profile Preferences, no toast is raised. Start Menu shortcut exists with correct AUMID (xyz.block.buzz.app); toast master switch enabled. Looks like the WebView2 NotificationReceived → Windows toast bridge is unimplemented on Windows, and the banner should say "not supported yet" rather than pointing users at system settings.
Activity
MrGrasss commentedon Aug 9, 2026
Still reproduces on Windows 11 with Buzz Desktop 0.5.8 (latest), same signature:
NoToastApplicationNotificationpolicy in HKCU or HKLM.xyz.block.buzz.appentry underHKCU\Software\Microsoft\Windows\CurrentVersion\Notifications\Settings(never registered).So nothing is actually denied at the OS or WebView2 layer. The app reports "blocked" for a state that is really "never requested/registered", and the disabled in-app toggle leaves no way to trigger the request. Confirming this is not fixed as of 0.5.8.
ranjank2alpha commentedon Aug 31, 2026
#6876 implements this. Buzz had no Windows arm in
show_native_notificationat all, so the toast never reached the OS, which is why nothing appeared under Settings > Notifications and noxyz.block.buzz.appkey was ever written.The PR adds the native WinRT toast path via
tauri-winrt-notification, brings up a process-wide COM MTA that those WinRT calls need (without it every call fails withCO_E_NOTINITIALIZED, silently, in a release build), and registers the AUMID plus the Start Menu shortcut'sPKEY_AppUserModel_IDso Windows recognises Buzz and routes toasts to the Action Center.It also fixes the misleading "blocked" banner this issue calls out. The permission state is now read from the backend rather than the webview shim's cached
"denied", so the in-app toggle actually works instead of reporting a denial that was never real. Clicking a toast focuses the window and opens the conversation.Happy to walk through any of it if it helps review.
wpfleger96 commentedon Oct 9, 2026
🤖 fixed by #5600, which ships in the next desktop release. the plugin does deliver Windows toasts, but on Windows it reported permission as
deniedat startup without asking the backend, so Buzz never sent one. that is also why Buzz never showed up in Windows notification settings. #5600 repairs that reading, so Desktop alerts turn on and stay on across restarts. if toasts still do not arrive on the release with the fix, comment here and we will reopen. thanks for the report