Skip to content

fix(desktop): enable Windows-native winrt/toast notifications and make them reliable - #7614

Open
bernhardkaindl wants to merge 4 commits into
block:mainfrom
youkeep-code:fix/windows-desktop-notifications-fixes-gen2
Open

fix(desktop): enable Windows-native winrt/toast notifications and make them reliable#7614
bernhardkaindl wants to merge 4 commits into
block:mainfrom
youkeep-code:fix/windows-desktop-notifications-fixes-gen2

Conversation

@bernhardkaindl

@bernhardkaindl bernhardkaindl commented Sep 12, 2026

Copy link
Copy Markdown

fix(desktop): enable Windows-native winrt notifications and make them reliable

This PR combines @fatima-n09's PR

Tested on Windows 11: When clicking the notification, the correct message, and if in a thread/branch, the message in the thread opens, and is highlighted as having just arrived.

Fixes

Obsoletes

Related to

Problems

  1. On the current main branch, Windows notifications are impossible to enable.
  2. Even with fix(desktop): enable native Windows toast notifications #6689 applied, Windows notification delivery and activation had three related gaps:
    • permission repair could still be in flight when the first notification was sent,
    • clicking a normal message notification could open an empty reply branch,
    • broad live channel subscriptions updated only the projected message cache, so an active channel could miss the message until reload.

Solution

  • Await and confirm desktop notification permission before feed, DM, and dedicated thread-reply delivery.
  • Carry explicit timeline-versus-thread intent in notification targets and channel routes.
  • Merge visible live channel messages into the authoritative channel window store before projection.
  • Add focused regression coverage for permission sequencing, activation routing, notify-while-viewing, and live window projection.

Fatima Nur and others added 2 commits September 13, 2026 00:56
The show_native_notification command only handled Linux and macOS.
On Windows it returned an error, forcing the frontend to fall through
to window.Notification (WebKit API). WebView2's Notification.permission
reports 'denied' even when the WinRT toast API is available, so the
app never appeared in Windows Settings > System > Notifications and
the settings toggle was stuck showing 'Desktop notifications are blocked.'

- Add tauri-winrt-notification as a Windows-specific dependency
- Add a windows module in notifications.rs that posts WinRT toasts
  using the app's Tauri identifier as AppUserModelID (this is what
  registers the app with Windows notification settings)
- Handle click actions through WinRT Activated handler, forwarding
  to the same native-notification-activated event that Linux uses
- Add isWindowsPlatform() helper to platform.ts
- Skip WebView2 Notification.permission check on Windows in
  getDesktopNotificationPermissionState() — use the Tauri plugin's
  isPermissionGranted() which queries native WinRT status
- Route Windows through the native show_native_notification path
  in sendDesktopNotification()
- Skip the Tauri plugin's onAction listener on Windows (click
  actions come through the native WinRT event instead)

Fixes block#6377

Signed-off-by: Fatima Nur <fatimanur424@example.com>
Problem
-------
Windows notification delivery and activation had three related gaps:

- permission repair could still be in flight when the first notification was sent,
- clicking a normal message notification could open an empty reply branch,
- broad live channel subscriptions updated only the projected message cache, so an active channel could miss the message until reload.

Solution
--------
- Await and confirm desktop notification permission before feed, DM, and dedicated thread-reply delivery.
- Carry explicit timeline-versus-thread intent in notification targets and channel routes.
- Merge visible live channel messages into the authoritative channel window store before projection.
- Add focused regression coverage for permission sequencing, activation routing, notify-while-viewing, and live window projection.

Signed-off-by: Bernhard Kaindl <bernhardkaindl7@gmail.com>
@bernhardkaindl
bernhardkaindl requested a review from a team as a code owner September 12, 2026 23:24
@github-actions

github-actions Bot commented Sep 12, 2026

Copy link
Copy Markdown

🔐 Codex Security Review

Status: review required for the current range.

The current range is 4cd82f513214aad11c2b742ce7cc7c681e8e32a0...0f891143100fbdde5330672dff8d1307771c59da.
A new review must complete for this exact range. When manual authorization
is required, a Block organization member must comment exactly
@buzz-security-review 0f891143100fbdde5330672dff8d1307771c59da to authorize a new review.
Any previous review applies only to its recorded range.

Signed-off-by: Bernhard Kaindl <bernhardkaindl7@gmail.com>
Signed-off-by: Bernhard Kaindl <bernhardkaindl7@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant