| Summary: | Reconnecting to internet after downtime triggers flood of notifications from apps that remained open during that time | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Marten <w-m> |
| Component: | Notifications | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | agurenko, fanzhuyifan, kde, kdelibs-bugs-null, nate, nicolas.fella, olib141, plasma-bugs-null, postix, qydwhotmail, raphael.kde, w-m |
| Priority: | NOR | Keywords: | usability |
| Version First Reported In: | master | ||
| Target Milestone: | 1.0 | ||
| Platform: | Manjaro | ||
| OS: | Linux | ||
| See Also: |
https://bugs.kde.org/show_bug.cgi?id=440837 https://bugs.kde.org/show_bug.cgi?id=486070 https://bugs.kde.org/show_bug.cgi?id=508394 https://bugs.kde.org/show_bug.cgi?id=483481 |
||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Marten
2021-09-02 11:46:12 UTC
I am able to reproduce the frustrating flood of notifications in this case, but not any crashes or memory spikes because of it. Are you using an NVIDIA GPU? If so, you are probably experiencing Bug 414785 in addition to just the notification flood issue. Regardless, probably what we should do us suppress any notifications that are not sent in real-time; e.g. queued-up notifications from apps that *would have sent* while the network was down or Do Not Disturb mode was active. See Bug 440837. What about grouping notifications? If an application issues more than N notifications in a short time, display a (meta) notification saying "X notifications from this application", with the application and its icon in the notification title. A button "Show details" could open the notification drawer at the right place. It is still useful to be notified that something happened when reconnecting, leaving suspend or DND I think. In Plasma 6 I can now reproduce the performance issues resulting from the notification flood. Grouping them into one might make sense. We should also do some profiling to see why creating so many notifications causes performmance issues. The data flow can be like:
(When flood prevention is enabled)
NotificationSortProxyModel -> QSortFilterProxyModel to filter out floods -> QConcatenateTablesProxyModel
-> QAbstractListModel to track floods and create summary notifications ->
Just need someone to implement the 3 models.
Did https://invent.kde.org/plasma/plasma-workspace/-/commit/5145d877d82dd5111118c93d0da7c988cf0640e5 fix this? It appears to have, yes! Unfortunately I was mistaken; this is still an issue even with that commit. What would a solution to this look like?
Perhaps we watch for connectivity — if connectivity goes from offline to online (and was offline for a period of say 1 hour), we start inhibiting notifications for a short period (say 5 seconds) and display the summary notification ("While you were offline…"). It'd need implementation of an inhibition reason (do not disturb and connectivity).
I imagine it would take notifications a moment to come in from different applications when connectivity is restored, and from different apps at different times.
Yes, and we'd also need to handle the cases of the system going to sleep and hibernating, in case those don't officially signal a connectivity change. I used to be able to reproduce this with NeoChat, but now it's not happening anymore, maybe because NeoChat now revokes old notifications. The other chat apps I use (DIscord, Telegram) do, too. Marten, are you able to put together a test case for this that we can use to test changes against? 🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone! Nah, I can confirm it's still happening in the general case for less-well-behaved apps. |