https://bugs.kde.org/show_bug.cgi?id=508433
--- Comment #2 from Tobias Zwick <new...@westnordost.de> --- > 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) -- You are receiving this mail because: You are watching all bug changes.
