Created attachment 184217 [details] SELinux spams notifications SUMMARY When an application or service creates a lot of notifications in short succession, the UI of the notifications widget becomes somewhat unusable. STEPS TO REPRODUCE Well, in my case, install current Waydroid (and maybe install an app). Then, SELinux started spamming security alerts. For developers, it would be reproducible by creating a program that will just spam notifications. OBSERVED RESULT Notifications are opened-closed-opened-closed... etc. in short succession, no chance to click on either [Dismiss] or [Show]. EXPECTED RESULT Notifications are not made unusable if the same app spams a lot of notifications. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 42 KDE Plasma Version: 6.4.4 KDE Frameworks Version: 6.17.0 Qt Version: 6.9.1 Kernel Version: 6.15.9-201.fc42.x86_64 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5700X 8-Core Processor Memory: 32 GiB of RAM (31.3 GiB usable) Graphics Processor: NVIDIA GeForce GTX 1660 SUPER ADDITIONAL INFORMATION See attached video for a demo.
It actually looks like the app is creating and then immediately revoking its notifications. Do you have any ideas for what the Plasma notification should do instead, in the face of this kind of abuse from an app?
> It actually looks like the app is creating and then immediately revoking its notifications. Ah, good to know, I wasn't sure what was happening. To your question, I guess, a quota of how many notifications per minute an app is allowed to post/update would be a mitigation that however comes with a rat tail of other potential issues attached (e.g. what if user presses pause/play/pause/play on some audio or video playback very often). But maybe, if an app removes a notification and in the same breath posts a new notification, don't fade out the old and fade in the new, but directly replace it in-place. I gather what might be happening is that SELinux *doesn't* want to spam notifications when a barrage of security alerts occur, so it makes sure to always only show a notification for one, i.e. the latest security alert, thus clearing any previous when a new one arrives. (In that case, though, it might be worth opening an issue at whatever component creates these SELinux notifications to not create new notifications but update the old one, if that's possible)
The thing is there are no good options here. As you suspect, a quota would cause innumerable issues. Disabling the animation if an app revokes and then immediately re-creates a new notification would work for the case that the app is literally doing this so fast that we have both notifications already in the queue at the moment we would remove the old notification. But in cases where we don't, this would require predicting the future; we can't know that we should disable the fade-out animation for a notification just because later, in the future, there's going to be a new notification from the same app. Another option is to batch up notifications so that they appear in a little group, rather than all visually appearing and disappearing. That's tracked with Bug 491181. If you think that would help, we can consider this bug report a duplicate of that one, Let me know your thoughts.
Well, what I meant was that if the removal and the new addition happened in the same frame, i.e. that would mean that any new notification would only be posted with a delay of a millisecond or so. 491181 would solve it in a better way, I think, so let's close this as duplicate.
Sound good! *** This bug has been marked as a duplicate of bug 491181 ***