SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. Put an Analog Clock widget on your Plasma desktop 2. run `notify-send --urgency=critical "I'm sticky"` to get a notification on the screen that won't time out 3. Move the widget, either by clicking-and-holding it and then dragging it, or by entering edit mode and then dragging it OBSERVED RESULT The persistent notification moves up to the top-left corner of the screen and stays there. All notifications that arrive after that also go there. This happens until plasmashell is restarted. EXPECTED RESULT Notifications don't move
This is on Wayland with a single screen at 200% scale FWIW.
I can't reproduce this on current builds with 100% scale on multiple screens, is it still happening for you?
Yes, it's still 100% reproducible for me on one or two screens. One of those screens always has a 200% scale factor, though, so maybe that's relevant.
This is still reproducible although I couldn't do it using the OP's steps. Issue 1-1 and Issue 1-2 have the same behavior as OP, but I was adding and removing panels to reproduce it Issue 2-1 has different behavior, caused by moving widget and changing the scaling (I think notif doesn't need to be displayed, just move the widget and then change the scaling, widget needs to be moved, otherwise notif is correctly displayed using both scaling options), not sure if it would be better to report new bug or if it could be fixed here Operating System: Arch Linux KDE Plasma Version: 6.2.3 KDE Frameworks Version: 6.7.0 Qt Version: 6.8.0 Kernel Version: 6.11.6-arch1-1 (64-bit) Graphics Platform: Wayland
Created attachment 175839 [details] Issue 1-1
Created attachment 175840 [details] Issue 1-2
Created attachment 175841 [details] Issue 2-1
so happens on wayland. do we know if on x11 exibits pretty much the same behavior or if seems wayland-only?
Git commit 404352dc0688e62b344b1c0399f2e74caa4a5dc8 by Marco Martin. Committed on 25/11/2024 at 15:30. Pushed by mart into branch 'wor/mart/notificationPosition'. Notification positioning fixes Better tracking of obstructingDialog size, visibility and position, making notifications reposition correctly when going out of edit mode Behavior is still a bit weird sometimes, but should never be breaking anymore, for a full fix the obstructingDialog should be rewritten considering that there might be more than one, but this would lead to a considerable increase in code complexity, so doesn't belong in this mr. More robust tracking of who is the parent plasmoid: the hack used before alsways removed the first item from plasmoidItems which is not guaranteed to actually be the one that was removed, now plasmoids unsubscribe themselves before actually being destroyed, which is much more reliable M +26 -10 applets/notifications/package/contents/ui/global/Globals.qml M +3 -0 applets/notifications/package/contents/ui/main.qml https://invent.kde.org/plasma/plasma-workspace/-/commit/404352dc0688e62b344b1c0399f2e74caa4a5dc8
In progress with https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4941
I can reproduce it on X11 as well, although on X11, the notification isn't moved to the top left corner, but to the middle of screen vertically and 40% from the bottom.
There are multiple issues here: there are some actual positioning issues of the notifications applet (first two videos) which are fixed by https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4941 and a bigger issue of the systray itself which indirectly causes the issue of the 3rd video
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4944
A possibly relevant merge request was started @ https://invent.kde.org/plasma/libplasma/-/merge_requests/1227
Git commit ff624952851e83bc78c4d796821ada2b630da4ce by Marco Martin. Committed on 29/11/2024 at 13:27. Pushed by mart into branch 'master'. Always ensure setDestroyed propagates to all children applets Some applets (systemtray, groupingplasmoids) can be parent of a Containment, in order to have nested containments (since the actual systray applet is a containment that instantiates other applets) But also in that case we need to make sure that the destroyed property properly propagates to the children in order to not leak inner containments when they are deleted M +10 -0 src/plasma/private/applet_p.cpp https://invent.kde.org/plasma/libplasma/-/commit/ff624952851e83bc78c4d796821ada2b630da4ce
A possibly relevant merge request was started @ https://invent.kde.org/plasma/libplasma/-/merge_requests/1228
Git commit fb588e8cdb96a6feba11512ca2ca0dff3a800e40 by Marco Martin. Committed on 29/11/2024 at 13:27. Pushed by mart into branch 'Plasma/6.2'. Always ensure setDestroyed propagates to all children applets Some applets (systemtray, groupingplasmoids) can be parent of a Containment, in order to have nested containments (since the actual systray applet is a containment that instantiates other applets) But also in that case we need to make sure that the destroyed property properly propagates to the children in order to not leak inner containments when they are deleted (cherry picked from commit ff624952851e83bc78c4d796821ada2b630da4ce) 2f97b1de Always ensure setDestroyed propagates to all children applets Co-authored-by: Marco Martin <notmart@gmail.com> M +10 -0 src/plasma/private/applet_p.cpp https://invent.kde.org/plasma/libplasma/-/commit/fb588e8cdb96a6feba11512ca2ca0dff3a800e40
Git commit f75b13d545c9c6d69c3ad357818adf2b0344a13d by Marco Martin. Committed on 29/11/2024 at 13:59. Pushed by mart into branch 'master'. Systray: Clean up leaking systrays Since removing a systray container didn't use to remove the internal systray containment and all its applets, after a while especially if default panels are added and removed often, the applet config file becomes full of orphaned systray containments that just take up resources and cause misbehaviors This destroys on startup all org.kde.plasma.private.systray that are not associated with a particular org.kde.plasma.systray here went from an appletsrc config file of almost 7000 lines to under 1000 Related: bug 404641 M +47 -0 applets/systemtray/container/systemtraycontainer.cpp M +1 -0 applets/systemtray/container/systemtraycontainer.h https://invent.kde.org/plasma/plasma-workspace/-/commit/f75b13d545c9c6d69c3ad357818adf2b0344a13d
Git commit 4c82b4255836c43cc46c6eac7b26bbb8ba3d3bf9 by Marco Martin. Committed on 29/11/2024 at 13:59. Pushed by mart into branch 'master'. systray: destroy the inner systray when the container is destroyed When SystemTrayContainer is destroyed and removed form the config, the inner (actual) systray was left lingering there, ending up polluting the configuration file and instroducing slowdowns and misbehaviors as all the systray applets got instantiated and are "working" this gets rid of the inner systray on delete M +6 -0 applets/systemtray/container/systemtraycontainer.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/4c82b4255836c43cc46c6eac7b26bbb8ba3d3bf9
Git commit 7357e228ba88a6a16acc9f97628ce6fd4f40e2ab by Marco Martin. Committed on 29/11/2024 at 14:24. Pushed by mart into branch 'Plasma/6.2'. systray: Clean up leaking systrays backport of https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4944 Since removing a systray container didn't use to remove the internal systray containment and all its applets, after a while especially if default panels are added and removed often, the applet config file becomes full of orphaned systray containments that just take up resources and cause misbehaviors This destroys on startup all org.kde.plasma.private.systray that are not associated with a particular org.kde.plasma.systray Related: bug 404641 M +45 -0 applets/systemtray/container/systemtraycontainer.cpp M +1 -0 applets/systemtray/container/systemtraycontainer.h https://invent.kde.org/plasma/plasma-workspace/-/commit/7357e228ba88a6a16acc9f97628ce6fd4f40e2ab