SUMMARY *** When I open an application in fullscreen on my tablet with the panel in dodge window mode, it nicely dodges the window. But when I then rotate the screen, the panel reappears in front of the window. *** STEPS TO REPRODUCE 1. Set panel to dodge window mode 2. open e.g. Dolphin in fullscreen 3. detach keyboard 4. switch to empty workspace (via three finger swipe) 5. come back to previous workspace (via three finger swipe) 6. rotate vertically 7. rotate horizontally OBSERVED RESULT 3. panel appears in front of dolphin 4. panel stays as it is 5. panel disappears/dodges window 6. panel appears but disappears after a second or so 7. panel appears in front of window and remains there EXPECTED RESULT 3. nothing happens 4. panel appears as it was not visible before 5. panel disappears/dodges window 6. screen gets rotated, panel is not shown 7. screen gets rotated, panel is not shown SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.90.0 KDE Frameworks Version: 5.246.0 Qt Version: 6.6.1 Kernel Version: 6.6.3-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Pentium® CPU 4425Y @ 1.70GHz Memory: 7.6 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 615 Manufacturer: Microsoft Corporation Product Name: Surface Go 2 System Version: 1
The same thing happens in auto hide mode, except now it does not ever require a full screen window.
The observed result 6. varies. I now have enabled automatic rotaion even if not in tablet mode and now the panel (mostly) first disappears and then appears after a second or so.
Can reproduce. When in Tablet Mode, when I rotate the screen, a Dodge Windows panel becomes visible even if there are windows touching its screen edge.
*** Bug 477810 has been marked as a duplicate of this bug. ***
Can also be reproduced if the display resolution / scaling is changed.
I can see similar behavior, but with unlocking screen. Is that also considered to be the same bug, or should I make a new report.
(In reply to Trần Nam Tuấn (Bill) from comment #6) > I can see similar behavior, but with unlocking screen. Is that also > considered to be the same bug, or should I make a new report. Can't reproduce after either locking or suspending -- dodge windows still work. Could you provide more detailed steps to reproduce it? Also is it consistently reproducible for you?
(In reply to fanzhuyifan from comment #5) > Can also be reproduced if the display resolution / scaling is changed. For some reason I can't reproduce it now. I don't remember changing anything in between, aside from rebooting the machine....
I also cannot seem to reproduce it with unlocking screen under normal timeout or force locking from a fresh boot. Must have been under very specific conditions, that I haven't noticed. Will keep a closer look on that. :/ However, I can reproduce this with changing resolution and scaling. So, that's something...
Another very interesting discovery. This bug only seems to be triggered if the panel is set to not floating when the computer starts. And yes, for some reason, it needs to be at the time the computer starts -- simply logging in and logging out doesn't change things.
(In reply to fanzhuyifan from comment #10) > Another very interesting discovery. This bug only seems to be triggered if > the panel is set to not floating when the computer starts. > > And yes, for some reason, it needs to be at the time the computer starts -- > simply logging in and logging out doesn't change things. On another set of experiments, this can no longer be reproduced. So I guess this could have been a coincidence..
This bug seems to be caused by `d->screenGeometry` having an incorrect value at `plasma-workspace/src/libtaskmanager/taskfilterproxymodel.cpp#L358` [1]. To verify this claim, one could add a debug print of `d->screenGeometry`, and note that when the bug triggers, its value is different from any valid screen geometry as reported by `kscreen-doctor -o`. I suspect that this is because when the display configuration changes, the screenGeometry changes value multiple times very quickly (for the snapping and repositioning stuff), causing some sort of race condition and the final change to be missed some how. [1] https://invent.kde.org/plasma/plasma-workspace/-/blob/01e67537f1e19ff71edbf2aeb5b50c70125fc8e1/libtaskmanager/taskfilterproxymodel.cpp#L358
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1913
Git commit ef34561f7c93e122cf14d802917e966f3de98e69 by Yifan Zhu. Committed on 11/12/2023 at 00:04. Pushed by davidedmundson into branch 'master'. Don't filter by screen for touching windows Windows centered on one screen may extend to other screens. Panels in dodge windows mode should dodge these windows if touching (BUG 478376). This is also a work around for BUG 478256, which seems to be caused by incorrectly updated screen geometries. Removing the screen filter bypasses the problem. Related: bug 478376 M +1 -1 desktoppackage/contents/views/Panel.qml https://invent.kde.org/plasma/plasma-desktop/-/commit/ef34561f7c93e122cf14d802917e966f3de98e69
It would be great if other people could verify if they still have this issue after the commit ef34561f. Thanks!
The patch was reverted; re-opening.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1917
A possibly relevant merge request was started @ https://invent.kde.org/plasma/libplasma/-/merge_requests/1013
Git commit edb091855547fa768f4a733504a48816e3434b08 by Aleix Pol Gonzalez, on behalf of Yifan Zhu. Committed on 13/12/2023 at 23:58. Pushed by apol into branch 'master'. Reconnects signals after screen change When the screen of ContainmentView changes, reconnect its screen related signal, screenGeometryChanged. M +27 -1 src/plasmaquick/containmentview.cpp https://invent.kde.org/plasma/libplasma/-/commit/edb091855547fa768f4a733504a48816e3434b08
Does anyone still have this issue on wayland after https://invent.kde.org/plasma/libplasma/-/commit/edb091855547fa768f4a733504a48816e3434b08? It fixes the issue for me on wayland. However, for me dodge windows still doesn't work on X11 (multiple monitors, fractional scaling)
This is partially fixed for me on Wayland with multiple monitors now. Rotating a monitor now does the right thing, and a Dodge Windows panel no longer inappropriately un-hides. However I can still reproduce the issue happening when the resolution or scale factor changes. Steps to reproduce: 0. Be on Wayland 1. Have a panel on a screen in Dodge Windows mode 2. Maximize a window so that it hides 3. Go to System Settings > Display & Monitor 4. Increase or decrease the screen's resolution or scale factor *Sometimes* the panel un-hides. Clicking on it and then clicking elsewhere will make it hide again. Other times the panel stays hidden as expected. So overall the behavior feels a bit buggy and glitchy.
(In reply to Nate Graham from comment #21) > *Sometimes* the panel un-hides. Clicking on it and then clicking elsewhere > will make it hide again. This sounds like 470760, an existing issue with autohide. Just to clarify, do you still get cases where the panel does not hide even if you click on it and click elsewhere? Previously I was having a lot of cases where the panel does not correctly hide even after I click on it and click elsewhere.
I was seeing some of those cases too, yeah. I gather you are as well? Let's use this to track that issue, and Bug 448420 will track the pre-existing issue of panels being un-hidden but hiding again when clicked.
(In reply to Nate Graham from comment #23) > I was seeing some of those cases too, yeah. I gather you are as well? Let's > use this to track that issue, and Bug 448420 will track the pre-existing > issue of panels being un-hidden but hiding again when clicked. Humm at least on wayland I haven't seen any cases where the panel shows up and I cannot hide them, even after mouse over/clicks, after edb09185. Do you have more detailed steps to reproduce? X11 seems to be a completely different story though. Last time I checked, on fractional scaling dodge windows doesn't seem to work at all. But since I don't use X11 for my daily drive, I haven't gotten around to taking a closer look yet.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1986
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1987
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1988
Git commit ba3995f0859e2fdfe7adb2464867df3b7a1835ec by Fushan Wen, on behalf of Yifan Zhu. Committed on 21/01/2024 at 11:30. Pushed by fusionfuture into branch 'master'. Don't filter by screen for touching windows Windows centered on one screen may extend to other screens. Panels in dodge windows mode should dodge these windows if touching (BUG 478376). This is also a work around for BUG 478256, which seems to be caused by incorrectly updated screen geometries. Removing the screen filter bypasses the problem. Related: bug 478376 (cherry picked from commit ef34561f7c93e122cf14d802917e966f3de98e69) M +1 -1 desktoppackage/contents/views/Panel.qml https://invent.kde.org/plasma/plasma-desktop/-/commit/ba3995f0859e2fdfe7adb2464867df3b7a1835ec
Git commit 4cdefe5d52b8facb996462f691f2c695288e48d2 by Fushan Wen, on behalf of Yifan Zhu. Committed on 21/01/2024 at 11:31. Pushed by fusionfuture into branch 'Plasma/6.0'. Don't filter by screen for touching windows Windows centered on one screen may extend to other screens. Panels in dodge windows mode should dodge these windows if touching (BUG 478376). This is also a work around for BUG 478256, which seems to be caused by incorrectly updated screen geometries. Removing the screen filter bypasses the problem. Related: bug 478376 (cherry picked from commit ef34561f7c93e122cf14d802917e966f3de98e69) M +1 -1 desktoppackage/contents/views/Panel.qml https://invent.kde.org/plasma/plasma-desktop/-/commit/4cdefe5d52b8facb996462f691f2c695288e48d2