fix(desktop): let Windows users enable notifications after a false denial

[BradGroux]

Addresses #2445.

What Windows users saw

Buzz could report desktop notification permission as denied before Windows had registered the installed app as a notification sender. The settings toggle then treated that value as final, so users could not turn notifications on even though requesting permission would repair the state.

What changed

• default still requests access on every platform.
• A false denied state gets one recovery request only in the Windows Tauri app.
• Genuine denial remains terminal on macOS, Linux, and ordinary Windows web pages.
• Unit coverage exercises the platform/runtime policy.
• The settings-flow Playwright regression explicitly identifies itself as Windows Tauri and verifies one recovery request.

There is no retry loop, Tauri plugin fork, new dependency, or change to notification delivery.

Verification

• just desktop-check desktop-test desktop-typecheck desktop-build: passed, including 3,889 JavaScript tests.
• pnpm --dir desktop build:e2e: passed.
• pnpm exec playwright test profile.spec.ts --project=integration --grep "Windows retries a false denied notification permission from settings": 1 passed.

What still needs a real Windows test

The automated regression uses a Windows platform identity and the real settings hook against the notification shim. It does not run inside Windows WebView2 or a packaged Tauri application.

Keep #2445 open until an affected Windows 11 installation confirms the request returns granted, Buzz appears under System > Notifications, and a real toast arrives.

[BradGroux]

I rebased this branch onto current main and tightened the workaround after rechecking the actual trust boundary.

The reported Windows Tauri behavior is still relevant, but the old condition retried denied permission on any Windows browser. That would turn a genuine web denial into another prompt attempt and exceeded the issue's installed-app scope.

Head acda0d989a3d91eef16b3278a9afea43db3d732c now permits the one-time recovery request only when both Windows and Tauri are true. The Playwright regression also declares a Windows Tauri identity explicitly; this caught the overly broad condition during verification.

All 3,725 Desktop JavaScript tests, Desktop typecheck, the E2E build, the focused Playwright settings flow, and targeted Biome checks passed. A real Windows 11/WebView2 smoke test is still required, so #2445 should remain open and the PR should not claim packaged-shell proof.

[BradGroux]

Rebased this branch onto current block/buzz main at c55e421a0.

Head moved from 071c0b63a to 9a0f18df9. git range-diff shows the Windows notification recovery patch is unchanged. The branch also cleanly incorporates the current profile E2E changes from main; no branch behavior was dropped during the rebase.

Verification:

• Desktop Biome, file-size, text-size, and pubkey-truncation checks passed.
• The full Desktop test suite passed.
• TypeScript typecheck and the production Vite build passed on the final rebased branch.
• git diff --check, DCO trailer checks, and the direct merge-base audit passed.

GitHub checks are rerunning on the new head.

[BradGroux]

Rebased onto current block/buzz main at b1b283cd4. #2483 remains the only Buzz pull request addressing the Windows Tauri false-denial path, and no review feedback or superseding implementation surfaced.

Published head: f87a89336e3eb74db56710c1f7ec1029178bdf96.

Desktop check, typecheck, build, and all 3,889 JavaScript tests pass. The focused settings-flow Playwright regression also passes in Chromium.

The remaining boundary is unchanged: the automated regression exercises a Windows Tauri identity and the real settings hook against the notification shim, but it is not packaged Windows 11 or WebView2 proof. #2445 should remain open until an affected installation confirms registration and toast delivery.

[BradGroux]

Rebased onto block/buzz main at ce3cf3cd2591f132f286fbc0a42a9e6699d0b08d and rechecked the Windows permission path, current notification settings code, open issue #2445, and competing pull requests.

The PR remains valid. Current main still requests notification access only from the default state and treats a Windows Tauri denied result as terminal. No other open or merged pull request implements the one-time installed-app recovery path. The branch remains narrowly guarded by both Windows and Tauri, so ordinary Windows web pages and genuine denial on other platforms do not receive another prompt attempt.

The rebase was clean and preserves the current profile E2E bridge changes. No production-path correction beyond the existing single recovery request was needed.

Exact-head verification on aebe3f29db29cbf5fad962447abb481773e568e0:

• Desktop policy/static checks passed, including formatting and file-size, text-size, and pubkey-truncation gates.
• The full Desktop JavaScript suite passed with 0 failures.
• Desktop typecheck and production build passed.
• The E2E build passed.
• Focused Playwright coverage passed for “Windows retries a false denied notification permission from settings,” including the assertion that exactly one recovery request occurs.
• git diff --check, conflict-marker scan, merge-base audit, and required DCO trailers passed.

The acceptance boundary is unchanged and should stay explicit: this automated regression uses a Windows Tauri identity and the real settings hook against the notification shim, but it is not packaged Windows 11 or WebView2 proof. #2445 should remain open until an affected installation confirms app registration, granted permission, and real toast delivery.

[BradGroux]

Review and rebase summary

Reviewed the PR for accuracy against current block/buzz main at d42d60d64 and rebased the branch onto that commit.

What this PR does

Adds a Windows-specific retry path for desktop notification permissions. On Windows Tauri, the WebView2 notification shim can report denied even when the OS permission is actually default (a known false-denial). The new ensureDesktopNotificationPermission function retries requestAccess() when the current permission is denied and the environment is Windows Tauri. On non-Windows or non-Tauri environments, denied is terminal and no retry is attempted. The default state still requests access on every platform.

Accuracy review

• The isWindowsPlatform() helper uses navigator.platform matching /^win/i, which correctly identifies Win32 and Win64 without false-positive on Darwin or Linux x86_64.
• The ensureDesktopNotificationPermission function is cleanly extracted and testable — it takes currentPermission, isWindowsTauri, and requestAccess as parameters, making it pure and deterministic.
• Three Node.js tests cover: Windows Tauri retries denied and accepts granted; non-Windows-Tauri environments keep denied without retrying; default permission still requests on every platform.
• The E2E test seeds a denied permission with a granted request result on a Win32 platform, toggles desktop notifications off then on, and asserts the request count is 1.
• The isTauri() import from @tauri-apps/api/core is correct for Tauri 2.
• No unwrap() or expect() in production paths. No new dependencies.

Rebase result

Head moved from aebe3f29d to d33c71c8c. No conflicts. git range-diff shows the patch is unchanged.

CI

DCO passes. Semgrep OSS and zizmor were pending at the time of this comment.

[BradGroux]

Rebase and accuracy review (2026-08-07)

Rebased onto current main (2b873cf20). Clean fast-forward through the intermediate d42d60d64 base — 52 commits applied, no conflicts.

Branch state: acda0d989 (was d33c71c8c at the intermediate base) Mergeable: ✅ MERGEABLE · BLOCKED (branch protection — awaiting maintainer review)

Accuracy review

The PR adds a ensureDesktopNotificationPermission helper that retries the Windows Tauri notification shim's known false-denied state. When currentPermission is "denied" and the platform is Windows Tauri, it re-requests access instead of accepting the denial. The isWindowsPlatform() helper in platform.ts is tested in platform.test.mjs.

The permission.test.mjs covers both the normal "default" path (request access) and the Windows false-denied path (retry when isWindowsTauri is true). The e2e test in profile.spec.ts exercises the full notification permission flow.

No unwrap()/expect() equivalent in the TypeScript paths. No new dependencies — uses existing Tauri notification plugin APIs. Scope is tight: 7 files, 208 insertions.

⚠️ Note: main has since added PR #5143 (fix(desktop): drop unhandled rejection from throwing window.Notification) which wraps new window.Notification(...) in a try/catch in desktop.ts. This PR's changes to hooks.ts are in a different code path (permission request, not notification delivery) so they do not conflict, but a future merge of both changes should verify the notification flow works end-to-end on Windows after a false denial.

[BradGroux]

This is the third recurring review + rebase pass for the open BradGroux PRs on block/buzz.

What this PR does

Lets Windows users re-enable desktop notifications after a false denial. On Windows Tauri, the notification permission shim can report "denied" even when the user hasn't actually denied it. The fix introduces an ensureDesktopNotificationPermission function that retries the permission request when the current state is "denied" and the environment is Windows Tauri (but not on other platforms, where "denied" is respected as final).

The PR also adds:

• isWindowsPlatform() in platform.ts — checks navigator.platform against /^win/i.
• Test coverage for the permission retry logic (Windows Tauri retries denied, non-Windows-Tauri keeps denied, default always requests).
• Platform detection tests (Win32 → true, Darwin → false).

Correctness

• The retry condition currentPermission === "default" || (currentPermission === "denied" && isWindowsTauri) correctly distinguishes the Windows false-denial case from a genuine denial on other platforms.
• The isWindowsTauri flag combines isWindowsPlatform() && isTauri(), so web browsers on Windows are not affected.
• The function is pure and testable — requestAccess is injected, making it deterministic in tests.
• The navigator.platform regex /^win/i matches Win32, Win64, and Windows variants.
• No new dependencies. No unwrap/expect (TypeScript, no Rust).

Rebase result

Rebased from 2b873cf20 to current main 02f640bc4 (7 commits). Clean rebase, no conflicts.

• Old head SHA: 6fd06c2a6405e20535cd57cb43f68d31205e522b
• New head SHA: 4533228ddbadcb4064d818258e86fba93e73a037
• Mergeable: ✅ MERGEABLE
• CI: DCO ✅

No code changes were made — this was a review + rebase pass only.