Bug 478923 - 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
Summary: On Wayland, floating panel becomes non-responsive after moving it to a screen...
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Panel (show other bugs)
Version: 5.91.0
Platform: Other Linux
: NOR major
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords: qt6, wayland-only
Depends on:
Blocks:
 
Reported: 2023-12-23 09:16 UTC by Jan Rathmann
Modified: 2024-01-23 17:10 UTC (History)
2 users (show)

See Also:
Latest Commit: https://invent.kde.org/plasma/plasma-workspace/-/commit/4cffda35da942b9a07ff0af03ba15ad889f128a9
Version Fixed In: 6.0
Sentry Crash Report:

Attachments
Screen recording of the reproduction steps (1.74 MB, video/webm)
2024-01-11 21:35 UTC, Jan Rathmann 		Details
View All Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Rathmann 2023-12-23 09:16:05 UTC 
SUMMARY
A floating panel will become completely unresponsive if it is moved to the top (or bottom) in the Wayland session.

STEPS TO REPRODUCE
1. Start Wayland session.
2. Have a floating panel (like the default one).
3. Right-click, "Enter edit mode..."
4. Set position to top.
5. Exit edit mode.

OBSERVED RESULT
The panel doesn't respond to clicks or mouse hover anymore. The only reliable way to make it usable again seems to be 'plasmashell --replace'.

EXPECTED RESULT
The panel stays a friendly thing that you can interact with :)

SOFTWARE/OS VERSIONS
KDE Plasma Version: 5.91
KDE Frameworks Version: 5.248 
Qt Version: 6.6.1

ADDITIONAL INFORMATION
* X11 session seems not affected.
* Moving the panel from top to bottom has the same effect (becoming unresponsive).
* Moving the panel to left or right seems _not_ to be affected.
* If the panel is solid (non-floating), the unresponsiveness doesn't seem to happen.
* Reproduced on Neon Unstable and in a VM with openSuse Krypton live image.
Comment 1 Nate Graham 2024-01-11 17:42:14 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.
Comment 2 Jan Rathmann 2024-01-11 21:35:30 UTC 
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'.
Comment 3 Nate Graham 2024-01-18 22:51:23 UTC 
Thanks. Unfortunately I remain unable to reproduce the issue after following those steps. :(
Comment 4 Jan Rathmann 2024-01-19 12:08:53 UTC 
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 :-)
Comment 5 Nate Graham 2024-01-19 15:30:05 UTC 
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.
Comment 6 Jan Rathmann 2024-01-19 21:10:18 UTC 
(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)...
Comment 7 Jan Rathmann 2024-01-20 14:53:26 UTC 
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.
Comment 8 Nate Graham 2024-01-22 21:40:30 UTC 
Correction: my step 2 should read:

"2. Have no windows touching it, so it *floats*"
Comment 9 Bug Janitor Service 2024-01-22 22:09:07 UTC 
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3809
Comment 10 Nate Graham 2024-01-23 16:58:15 UTC 
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
Comment 11 Nate Graham 2024-01-23 17:10:48 UTC 
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