Skip to content

Fix desktop notifications on GNOME 46+ Linux#1246

Open
benthecarman wants to merge 1 commit into
block:mainfrom
benthecarman:ubuntu-notifs
Open

Fix desktop notifications on GNOME 46+ Linux#1246
benthecarman wants to merge 1 commit into
block:mainfrom
benthecarman:ubuntu-notifs

Conversation

@benthecarman

@benthecarman benthecarman commented Jun 24, 2026

Copy link
Copy Markdown
Contributor

Desktop notifications didn't work for me. Claude's vibe coded fix. This fixes the problem for me

The app posts every desktop notification through the Web Notification constructor, which tauri-plugin-notification routes to its notify command. That command calls notify-rust's show() and then drops the returned handle immediately. The handle owns the D-Bus connection used to post the notification, and on GNOME 46+ (Ubuntu 24.04, Fedora 41+) tearing that connection down dismisses the notification the instant it appears, so nothing is ever seen. macOS uses a different backend and is unaffected.

Add a Linux-only show_native_notification command that posts from a dedicated thread and holds the connection open via wait_for_action until the notification is closed. The same wait surfaces the default click action, which is forwarded to the frontend so clicking focuses the window and routes to the notification target. The web client now sends through this command on Linux and keeps the plugin path on macOS and Windows.

@wesbillman

Copy link
Copy Markdown
Collaborator

Blocking: desktop/src-tauri/Cargo.toml now declares the Linux target dependency table twice:

[target.'cfg(target_os = "linux")'.dependencies]

Cargo rejects duplicate TOML tables before it can compile, so the desktop crate fails immediately with:

error: duplicate key
  --> desktop/src-tauri/Cargo.toml:50:2

This is from adding the notify-rust Linux table above the existing Linux keyring table. Please merge notify-rust = "4" into the existing [target.'cfg(target_os = "linux")'.dependencies] block instead of creating a second one.

The app posts every desktop notification through the Web Notification
constructor, which tauri-plugin-notification routes to its `notify`
command. That command calls notify-rust's `show()` and then drops the
returned handle immediately. The handle owns the D-Bus connection used
to post the notification, and on GNOME 46+ (Ubuntu 24.04, Fedora 41+)
tearing that connection down dismisses the notification the instant it
appears, so nothing is ever seen. macOS uses a different backend and is
unaffected.

Add a Linux-only `show_native_notification` command that posts from a
dedicated thread and holds the connection open via `wait_for_action`
until the notification is closed. The same wait surfaces the default
click action, which is forwarded to the frontend so clicking focuses
the window and routes to the notification target. The web client now
sends through this command on Linux and keeps the plugin path on macOS
and Windows.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: benthecarman <benthecarman@live.com>
@benthecarman

Copy link
Copy Markdown
Contributor Author

@wesbillman sorry, was not on latest master. Fixed!

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.

2 participants