| Summary: | On Wayland, floating panel becomes non-responsive after moving it to a screen edge that causes it to de-float after Edit Mode is exited, until it is touched by a window to make it de-float again | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Jan Rathmann <jan.rathmann> |
| Component: | Panel | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | nate, niccolo.venerandi |
| Priority: | NOR | Keywords: | qt6, wayland-only |
| Version First Reported In: | 5.91.0 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/plasma-workspace/-/commit/4cffda35da942b9a07ff0af03ba15ad889f128a9 | Version Fixed/Implemented In: | 6.0 |
| Sentry Crash Report: | |||
| Attachments: | Screen recording of the reproduction steps | ||
|
Description
Jan Rathmann
2023-12-23 09:16:05 UTC
Cannot reproduce myself with those steps. Reminds me of Bug 469016, though. I have an Intel GPU; what GPU are you using? And could you attach a screen recording of it happening so I know I'm testing properly? Also would be good to check if it still happens in Plasma 6 RC1. Created attachment 164827 [details] Screen recording of the reproduction steps (In reply to Nate Graham from comment #1) > Cannot reproduce myself with those steps. Reminds me of Bug 469016, though. > I have an Intel GPU; what GPU are you using? > > And could you attach a screen recording of it happening so I know I'm > testing properly? > > Also would be good to check if it still happens in Plasma 6 RC1. My GPU vendor is AMD (AMD Ryzen 5700G APU). But I can also reproduce on a Gnome Boxes VM with no HW acceleration. I have just updated my Neon Unstable VM to see if anything has changed - it unfortunately hasn't. Here is a screen recording of the reproduction steps. Notice how the panel doesn't react neither to hovering nor clicking before running 'plasmashell --replace'. Thanks. Unfortunately I remain unable to reproduce the issue after following those steps. :( With latest updates on Neon/openSuse and with an updated build of Plasma 6.0, I can't reproduce the panel freezing anymore, too – it seems it has been getting fixed silently :-) I just found a 100% reliable way to reproduce this issue: STEPS TO REPRODUCE 1. Have a left screen edge maximized floating panel 2. Have no windows touching it, so it de-floats 3. Make sure at least one window is touching the right screen edge 4. Enter Panel Edit Mode and move the panel to the right screen edge 5. Exit Exit Mode 4. Enter Panel Edit Mode and move the panel to the left screen edge OBSERVED RESULTS The panel has de-floated and become non-interactive. If you move a window so that it touches the panel, the panel de-floats and becomes interactive again EXPECTED RESULTS The panel remains interactive. So it looks like it's not fixed, just hard to reproduce. (In reply to Nate Graham from comment #5) > I just found a 100% reliable way to reproduce this issue: > Weird, I can't reproduce it anywhere when replicating your steps (with updates/build from today)... With todays build (and also in my Neon VM with todays updates) I now can reproduce it again – both Nate's steps from #5 and mine from the bug description lead to a non-responsive panel. I can also confirm that the panel becomes responsive again when it is touched with a window. Correction: my step 2 should read: "2. Have no windows touching it, so it *floats*" A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3809 Git commit 1e6a908f4b2f0c3dee5513f45a90fdfc0115194b by Nate Graham, on behalf of Niccolò Venerandi. Committed on 23/01/2024 at 17:58. Pushed by ngraham into branch 'master'. PanelView: Use geometry() instead of geometryByDistance() for computing mask GeometryByDistance() returns the place where the panel should be at a given moment; however it might not have moved there yet, thus it's better to use the actual screen geometry. If there's a mismatch between the two, e.g. when moving the panel around, then the mapFromGlobal() function would place the mask outside the screen area. FIXED-IN: 6.0 M +1 -1 shell/panelview.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/1e6a908f4b2f0c3dee5513f45a90fdfc0115194b Git commit 4cffda35da942b9a07ff0af03ba15ad889f128a9 by Nate Graham, on behalf of Niccolò Venerandi. Committed on 23/01/2024 at 17:58. Pushed by ngraham into branch 'Plasma/6.0'. PanelView: Use geometry() instead of geometryByDistance() for computing mask GeometryByDistance() returns the place where the panel should be at a given moment; however it might not have moved there yet, thus it's better to use the actual screen geometry. If there's a mismatch between the two, e.g. when moving the panel around, then the mapFromGlobal() function would place the mask outside the screen area. FIXED-IN: 6.0 (cherry picked from commit 1e6a908f4b2f0c3dee5513f45a90fdfc0115194b) M +1 -1 shell/panelview.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/4cffda35da942b9a07ff0af03ba15ad889f128a9 |