Hey I’ve noticed when trying to adjust to gnome, that clicking on a notification seems to have a sort of inconsistent behavior and was trying to understand the rationale/trace if this is a limitation of gtk/gnome, flatpak, or the application developers.
System Details Report
Report details
Date generated: 2026-09-26 17:41:11
Hardware Information:
Hardware Model: Framework Laptop 12th Gen Intel Core
Memory: 16.0 GiB
Processor: 12th Gen Intel® Core™ i5-1240P × 16
Graphics: Intel® Graphics (ADL GT2)
Disk Capacity: 2.0 TB
Software Information:
Firmware Version: 03.20
OS Name: openSUSE Tumbleweed
OS Build: (null)
OS Type: 64-bit
GNOME Version: 50
Windowing System: Wayland
Kernel Version: Linux 7.2.6-1-default
Other Relevant Software Information
Discord stable 617136 (d950ed2) Host 1.0.158 x64 Build Override: N/A Linux 64-bit (7.2.6-1-default) installed through Flatpak 1.18.2
Expected Behavior
When I receive a notfication from discord and click on it I expect discord to become focused so that I can read the relevant notification.
Current Behavior
When I receive a notification from discord and click on it one of two things happen:
If the discord window is closed, discord opens to the page where the notification is. I would consider this a success.
If the discord window was open in the background or in another workspace, the notication just disappears and a second notification spawns in a few seconds. Discord seems to correctly react and change the content in its window to display the notification but it does not pull focus until I find the second notification and click on it.
This experience means that I effectively need to always be aware of if I closed the existing window after to know whether I need 1 click or two to actually read the content of my notification. And if I was in the calendar view because I was trying to catch up on notifications it makes it more confusing as I have to scroll through notifications I was addressing to find the “notification is ready” notification and click on it. Was wondering if there was a rationale around pulling focus being used to justify the behavior, or if this is a known mistake on the developer/electron’s side that creates this sort of awkward UI experience?
Additional Info from discovery
I pulled the busctl traffic from the interaction and as I see it I can’t see this secondary notification on the session bus which is also confusing to me, is this not being spawned by discord but instead by the gnome-shell and just using the discord logo? I have a pcap saved from bustle but can’t upload directly to here can share upon request, but what I see effectively for all three situations mentioned above:
Discord registers a notification through libnotify that is shown properly and has a default action on click for them to respond to.
(On User Click): An ActionInvoked notification is sent
Discord is sent an activate action at /com/discordapp/Discord
But beyond that no further dbus communications are shown and no notification is sent back that looks like a notification is ready notification which makes me confused on the flow happening here, would appreciate any insight and depending may have to read the gnome handbook and roll up my sleeves. Just wanted to know whose tree I’m supposed to be barking up/helping at haha. Thanks for any help
To follow up, I see this same behavior with most third party applications, I just wanted to give a concrete example and centered around Discord as I figured it was more helpful that way. In no way exclusive to discord alone.
This happens when applications don’t use the supplied activation token to activate their window. So to the shell it looks like some application trying to randomly raise its window, which it prevents, because windows should only be raised in response to user actions (and the token is the way to indicate that).
There is one workaround in place, because of many applications not implementing this properly (in particular on launch): New windows can still raise themselves without triggering this. This is why it is working in the first case. This can be disabled via gsettings set org.gnome.desktop.wm.preferences focus-new-windows strict if you prefer the consistent behavior of not raising the window in either case.
There is also an extension that allows any windows to steal focus at any time, which would work around this problem, but also might allow other, less desirable behavior: Steal my focus window - GNOME Shell Extensions
including the full pcap at the bottom, but looking at the signals being emitted, I do not see a org.freedesktop.Notifications.ActivationToken signal being emitted at all through the entire interaction, but I do note that the org.gtk.Notifications.ActionInvoked Signal seems to include an activationtoken while the org.freedesktop.portal.notifications.ActionInvoked does not I assume because it is not listed in the spec you just sent me and I assume gtk seems to be using a spec modified from that.
So it looks like discord is attempting to properly implement this activation token and including it in the program data being sent out but it is being ignored or otherwise prevented from pulling focus using the activation token it pulled from the gtk signal. Is gtk/gnome expected to be emitting the signal you linked to me above that was not emitted? Is that also a cause for investigation or does gtk not implement that signal and instead use the activation-token from the org.gtk.Notifications.ActionInvoked signal instead? and was the signal being sent out by discord malformed or is there some other reason why gnome would ignore that activation even when given the activation-token?
discord-notification-action-debug-2026-09-26 17-28-32.pcap
Including a onedrive link for the full pcap where I recorded three separate notification interactions with the three separate scenarios, although I can also pull individual signals myself out to look at if needed.
And thank you for the guidance on temporary fixes and information to help dive in a little more that definitely helps
If Discord is installed via Flatpak, portals are involved and it’s a bit more complicated. From the gnome-shell perspective the portal is a gtk notification client, which uses a different protocol that includes the token in the action invocation itself rather than as a separate signal. The signal is only necessary for the libnotify protocol, because that’s only a later addition and could not be included in the existing signals in that protocol.
The portal is also what is calling org.freedesktop.Application.Activate in this case and forwards the token. That’s not Discord trying to activate itself. Discord would then need to use that token when calling xdg_activation_v1::activate on Wayland in response to that call.
I’ve noticed when trying to adjust to gnome, that clicking on a notification seems to have a sort of inconsistent behavior and was trying to understand the rationale/trace if this is a limitation of gtk/gnome, flatpak, or the application developers.
