GNOME Bugzilla – Bug 767809
suggestion: rate-limit the number of notifications an app can make bubble up
Last modified: 2021-07-05 14:23:38 UTC
Some Apps out there are just buggy - of course it's also worthy approaching those upstreams to get them fixed, but that's often not so easy (abandoned projects, unresponsive, [...]). The problem at hand: an application fires out a notification several times a second (e.g: it tries in a loop to ask PK to install a codec - every single query fires up a notification). This is quite annoying to the user and it would be great if this could be: * limited to how many notifications an app can send per time frame * or at least: limit the number of bubble produced for a single app - especially if the bubble does not really change content to a previous notification from the same app.
We have already been doing this since 3.16 - a source can only have up to three notifications queued up at any time[0]. What I suspect you are seeing is an application that shells out to notify-send for notification handling. I'm not sure there's much we can do in that case, as we cannot pin-point the notifications to a single source in that case - after all, each of them is created by a separate process ... https://git.gnome.org/browse/gnome-shell/tree/js/ui/messageTray.js#n784
I am the user who triggered Dominique's report (thank you!), and the trigger was Kopete, so I assume indeed we are looking at the notify-send case here? Would it be an option to block repetitive notifications that are exactly the same coming from notify-send? (Or, at least block those unless at least five(?) seconds have passed.)
(In reply to Gerald Pfeifer from comment #2) > Would it be an option to block repetitive notifications that are exactly > the same coming from notify-send? Not really - we don't generally know that a notification was sent via notify-send. However we could revisit tying notification sources to PIDs - that behavior was added way back in bug 629090 mostly in preparation for combining status icons and notification. We no longer do that, so it should be possible to adapt the source matching to deal better with broken apps. Another concern for the PID matching was that unrelated notifications ended up being grouped together when notify-send was used, however sources (and thus grouping) are no longer represented in the UI, so I don't think that's much of an issue nowadays either. If two applications use notify-send without a proper ID, they wouldn't be limited to 3 notifications each, but 3 in total - but that's a better drawback than not applying any limit at all in that case, so I'd say the apps get what they deserve for not using the actual API (via GIO, libnotify or raw DBus).
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.