Bug 452208

Summary:	Moving windows with super+lclick is allowed when a context menu is open on Wayland
Product:	[Plasma] kwin	Reporter:	Oliver Beard <olib141>
Component:	general	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED INTENTIONAL
Severity:	normal	CC:	nate
Priority:	NOR	Keywords:	wayland-only
Version First Reported In:	5.24.4
Target Milestone:	---
Platform:	unspecified
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	Unfocused system settings moved with a menu open. The menu has decorations as it was opened with the window unfocused. Focused system settings moved with a menu open, the application has been painted unfocused though it is focused. KWrite moved underneath an open context menu, showing the displacement of click targets Broken painting in kwrite from experimenting with the bug

Description Oliver Beard 2022-04-03 04:55:18 UTC

SUMMARY
When a context menu is open in an application, using super + leftclick to grab and move the window is blocked on X11. In Wayland, this is allowed. This leads to a significant amount of breakage with window focus and painting:

- The menu remains open, and does not move relative the application, however, its click targets do move relative to the application (though when moving the cursor over the context menu itself, does have correctly lined up targets).

- This results in some strange issues when painting the application as focused/unfocused. If the cursor is moved such to move from one selected menu to open another, the window's application area is painted unfocused, but the titlebar is painted focused. The application is treated as unfocused (I've noticed that when a context menu is opened for an unfocused window in Wayland, the context menu gets window decorations and opens in the center). Sometimes, when refocusing the window, it is not repainted as focused, though buttons are when hovered over. These buttons are also not repainted as unfocused when the window is unfocused.

- The broken painting behaviour cannot be replicated on X11 because when a window has a context menu open, super+leftclick to drag the window is not allowed.

- This is also broken in KDE's System Settings application, which uses a button to create a menu rather than a menubar.

- I have also noticed that opening the menu in System Settings on X11 paints the application area of the window unfocused. This is not replicable in Dolphin, which has a similar burger menu, though its created menu seems to suffer from Korners (the corner rendering seems to differ from other menus). This issue in Dolphin seems to be a distinct bug, present using Wayland and X11 so I will report a separate issue for it.

I am not sure exactly how many bugs exist here, or how to categorise them. **I suspect that most/all of the breakage here is caused by super+leftclick to grab being allowed when a menu is opened on Wayland.** This likely breaks some state resulting in focus and painting issues.

A lot of this was hard to describe and likely not explained well, so I'd encourage some experimentation to see the broken behaviour. I will submit another post with images showing the broken behaviours.

I am not sure where this bug should be filed so I have placed it in kwin/general. Please move if this is not appropriate.

SOFTWARE/OS VERSIONS
Linux: Arch Linux
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.92.0
Qt Version: 5.15.3

Comment 1 Oliver Beard 2022-04-03 04:57:01 UTC

Created attachment 147914 [details]
Unfocused system settings moved with a menu open. The menu has decorations as it was opened with the window unfocused.

Comment 2 Oliver Beard 2022-04-03 04:58:17 UTC

Created attachment 147915 [details]
Focused system settings moved with a menu open, the application has been painted unfocused though it is focused.

Comment 3 Oliver Beard 2022-04-03 04:59:14 UTC

Created attachment 147916 [details]
KWrite moved underneath an open context menu, showing the displacement of click targets

Comment 4 Oliver Beard 2022-04-03 05:00:52 UTC

Created attachment 147917 [details]
Broken painting in kwrite from experimenting with the bug

Comment 5 Oliver Beard 2022-04-03 05:02:06 UTC

Because adding attachments is done one at a time, and each one sends an email, here's an imgur album with various screenshots: https://imgur.com/a/TFWRPK3

Comment 6 Nate Graham 2022-04-04 21:36:01 UTC

lol. I think this not working on X11 was a bug, but now that it works on Wayland, it exposes a bunch more bugs that nobody thought to consider because moving a window with Meta+click while a window is open is a pretty uncommon thing to do.

Might be a Qt issue.

Comment 7 Oliver Beard 2022-04-04 21:45:12 UTC

(In reply to Nate Graham from comment #6)

Blocking moving the window is a reasonable solution to prevent things breaking in this manner, and probably the best thing to do for Wayland. Attempting to move a window whilst it has an open menu is not really a common action, and I'd guess that trying to fix the underlying logic to allow for this could be a very large can of worms.

Comment 8 Vlad Zahorodnii 2024-06-12 10:25:27 UTC

Popups detaching from the parent window was a bug and it was fixed. Some popups having decorations is also a bug, it has been partially fixed upstream in Qt.

Regarding allowing moving windows with popups, this is rather intentional behavior, at least the xdg-shell spec doesn't dictate that the popups must be dismissed.

On X11, things works differently because the popups usually grab input and the window manager needs to grab input in order to start interactive move resize session too. So that's why you can't move windows while there's a popup.

Comment 9 Oliver Beard 2024-06-12 10:30:24 UTC

(In reply to Vlad Zahorodnii from comment #8)
> Popups detaching from the parent window was a bug and it was fixed. Some
> popups having decorations is also a bug, it has been partially fixed
> upstream in Qt.

Yep, I'm happy to see this resolved! Only a few odd behaviours remain - such as popups not being moved to account for window resizing (we'll probably have to be cleverer in apps such as Dolphin), and popups not moving with their parent when fading out (closing). The last one is probably not possible to fix?

Comment 10 Vlad Zahorodnii 2024-06-12 10:34:45 UTC

That one is tricky because that is a closed window by that time.

"such as popups not being moved to account for window resizing" kwin supports popup repositioning, Qt just needs to support that as well

Comment 11 Oliver Beard 2024-06-12 10:38:03 UTC

(In reply to Vlad Zahorodnii from comment #10)
> That one is tricky because that is a closed window by that time.

Indeed, perhaps it's possible to remember the parent and position accordingly? It's a very minor visual flaw though, and one that a user would rarely see or even realise.

As for popups, I know in some apps (e.g. System Settings) we position the QMenu only at creation - though this *is* fine in System Settings as the left pane with the tool button can't be resized.