SUMMARY When receiving notifications from applications such as Discord, sometimes, the notifications will not expire and will stay hanging on the side. Additionally, this may cause a momentary freeze on the application if another notification is received while the hanging notification is still hanging. It seems to happen more reliably with notifications with long titles. STEPS TO REPRODUCE 1. Open Konsole 2. run the following command : sleep 5; notify-send --expire-time 20000 "this is a test message i am making it long on purpose :)" 3. re-run a few times if the issue did not appear, also try with a video playing on Firefox. OBSERVED RESULT The notification is hanging longer than it's expiry time and the expiry timer freezes or outright does not appear. EXPECTED RESULT The expiry timer on the notification should go down as usual and the notification should be closed automatically. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 Kernel Version: 6.1.1-zen1-1-zen (64-bit) Graphics Platform: Wayland Processors: 16 × Intel® Core™ i7-10700K CPU @ 3.80GHz Memory: 31.3 GiB of RAM Graphics Processor: AMD Radeon RX 6700 XT Manufacturer: Micro-Star International Co., Ltd. Product Name: MS-7C79 System Version: 1.0 ADDITIONAL INFORMATION I have tried reverting to prior versions of knotifications, kwin and plasma-desktop, it did not have an impact on the issue. I have also tried to reset my user configurations, this also did not fix the issue.
Experiencing this as well.
Trying to dig into the logs... this is what appears on every notification, pretty much regardless of if they fail to expire or not : 5 Jan 2023 14:49:58 plasmashell org.kde.plasma.notifications: Trying to replace notification with id 1735 which doesn't exist, creating a new one. This is an application bug! 5 Jan 2023 14:49:58 plasmashell Could not find the Plasmoid for Plasma::FrameSvgItem(0x559ada1a3af0) QQmlContext(0x559ad8d820e0) QUrl("file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml") 5 Jan 2023 14:49:58 plasmashell Could not find the Plasmoid for Plasma::FrameSvgItem(0x559ada1a3af0) QQmlContext(0x559ad8d820e0) QUrl("file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml") 5 Jan 2023 14:49:58 plasmashell file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/NotificationItem.qml:222:21: QML SelectableLabel: Binding loop detected for property "implicitWidth" 5 Jan 2023 14:49:58 plasmashell file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/NotificationItem.qml:222:21: QML SelectableLabel: Binding loop detected for property "implicitWidth" 5 Jan 2023 14:49:58 plasmashell file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/NotificationItem.qml:222:21: QML SelectableLabel: Binding loop detected for property "implicitHeight"
Looks like Plasma is "frozen" somehow: the notification timer gets stuck until I move the mouse around the desktop or the panel,. If I stop moving the pointer, the timer freezes again. Also affects the clock widget sometimes (it stays 1 or 2 minutes behind until I interact with Plasma). Wayland as well. Fedora 37/open-source AMD drivers
Forgot to add that starting plasmashell from the terminal with QSG_RENDER_LOOP=basic makes the problem far, far worse, if it helps debugging.
New find: starting plasmashell with mesa_glthread=false fixes the issue for me. Mesa 22.3 enables GL threads by default.
(In reply to Real Name from comment #5) > New find: starting plasmashell with mesa_glthread=false fixes the issue for > me. Mesa 22.3 enables GL threads by default. Can you indicate how you've done that? Is there a way to start plasmashell like this automatically/at login?
(In reply to Jeremi Campagna from comment #6) > (In reply to Real Name from comment #5) > > New find: starting plasmashell with mesa_glthread=false fixes the issue for > > me. Mesa 22.3 enables GL threads by default. > > Can you indicate how you've done that? Is there a way to start plasmashell > like this automatically/at login? You can test it from the terminal with the following command-line kquitapp5 plasmashell && sleep 10 && mesa_glthread=false kstart5 plasmashell As for starting only Plasma with that environment variable set, I'm not sure it's possible, and it would pass it on to the applications you launched with it anyway. You can set it globally in /etc/enviroment or a snippet in $HOME/.config/environment.d if you use systemd.
Did you enable "Send notifications" plugin in KDE Connect?
(In reply to Fushan Wen from comment #8) > Did you enable "Send notifications" plugin in KDE Connect? I use KDE Connect, but no, "Send notifications" is disabled in my case. "Receive notifications" is active however.
Created attachment 155098 [details] attachment-18148-0.html I do not use KDE Connect, this issue is not related to KDE Connect specifically but with general notifications. On Sat, Jan 7, 2023, 21:41 Fushan Wen <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=463377 > > Fushan Wen <qydwhotmail@gmail.com> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > Resolution|WAITINGFORINFO |--- > Status|NEEDSINFO |REPORTED > > -- > You are receiving this mail because: > You reported the bug. > You voted for the bug.
(In reply to Jeremi Campagna from comment #10) > > I do not use KDE Connect, this issue is not related to KDE Connect > specifically but with general notifications. It could be related to KDE Connect because KDE Connect will also handle notifications if "Send notifications" plugin is enabled.
Created attachment 155112 [details] drirc to test Plasma with mesa_glthread disabled I just recalled that Mesa allows you to work around application bugs, so no need for environment variables. Attaching a drirc that you can place either in /etc or in your home directory as ~/.drirc. Logging out and in again is enough.
(In reply to Fushan Wen from comment #11) > (In reply to Jeremi Campagna from comment #10) > > > > I do not use KDE Connect, this issue is not related to KDE Connect > > specifically but with general notifications. > > It could be related to KDE Connect because KDE Connect will also handle > notifications if "Send notifications" plugin is enabled. how can it be related to KDE Connect if I don't use, don't have it installed, and that behaviour still happens?
(In reply to Real Name from comment #12) > Created attachment 155112 [details] > drirc to test Plasma with mesa_glthread disabled > > I just recalled that Mesa allows you to work around application bugs, so no > need for environment variables. Attaching a drirc that you can place either > in /etc or in your home directory as ~/.drirc. Logging out and in again is > enough. Thanks for that workaround! I guess now it could be a mesa issue.
I can intermittently reproduce this, where the timer doesn't start until I move the cursor. Then it starts and runs normally, even if I stop moving the cursor. I haven't managed to detect a pattern yet. Wayland, Intel iGPU, Mesa 22.3.2, and git master everything KDE on top of Fedora 37. It does seem like it could be a GPU driver issue and Mesa has had a lot of those recently.
I can confirm that the workaround of disabling mesa_glthread globally or on plasmashell only seems to be working. I have applied this workaround for the last day or two and did not notice issues with notification timeout.
Hmm, that sounds like the issue described and fixed in https://gitlab.freedesktop.org/mesa/mesa/-/issues/7624. Is anyone who's experiencing this issue NOT using an AMD GPU?
New mesa 23.3.3 seems to have fixed the issue (checked it out by undoing the workaround.)
Mesa version 23.3.3 fixed the issue for me. I have been going without the workaround since updating and I still see no freeze in plasmashell.
Great!