Installed kwin from the arch linux packages to use in an LXQt session. When right clicking a title bar, I cannot cancel out of the menu or make it go away without actually choosing one of the options in the menu. Reproducible: Always
You mean not even pressing escape works? Please attach the output of "qdbus org.kde.KWin /KWin supportInformation" In case you're using some aurorae theme (this includes "plastik!"), please try the breeze decoration.
Actually, it randomly fails to grab input on right mouse button invocation. (Happens on breeze deco as well. Not always, but more than "rarely") Alt+F3 invocation seems "safe"
that sounds like a problem in Qt - after all Qt should do the grab for the popup. Maybe we need to update user time before showing the menu (assuming that Qt didn't get the timestamp from the mouse event as that is on our own window and not a Qt managed window).
*** Bug 352672 has been marked as a duplicate of this bug. ***
New observation: the menu does work as expected (here) after you unfold a submenu and let that close (by hovering another action and wait briefly)
clicking on a different window (e.g. desktop) also works. Maybe we filter out the events from Qt when it's on our window?
*clicking* a different window does not, but activating it does ;-P (Try clicking xeyes, doesn't work) That's "normal" and afair handled specially. While it does not work, the keyboard focus remains on the active window (and it receives mouse signals) "Making" it work by showing/hiding (latter is important) a submenu takes the input focus from the active window to the menu and also "blocks" mouse input from the active window. For some reason the input grab fails on initial invocation - but that's related to clicking the decoration, though. I could assume we (the deco) are grabbing input on button downs, so the popup cannot get it.
Has anyone consulted Qt developers in case this is an upstream issue?
They'll ask for a self-contained test case - which we cannot provide (so far) There's something interesting happening: a) we receive *two* XCB_MAP_NOTIFY events for the Alt+F3 menu in a row... b) the popup then gets the focus and looses it immediately - I could assume this is related to the doubled events?
> There's something interesting happening: > a) we receive *two* XCB_MAP_NOTIFY events for the Alt+F3 menu in a row... that might be the widget style destroying the window again in polish() in case the window is not ARGB?
(In reply to Martin Gräßlin from comment #10) > that might be the widget style destroying the window again in polish() in > case the window is not ARGB? Maybe, however I had tried ensurePolished() before exec() and that didn't help. Also I don't get this from other popups.
multiple maps seem a red herring - they also occur for the shortcut invocation. one is from the window and one from the root window and it's the same event. QMenu "needs" the button to be released before exec(), simply leaving the event cycle doesn't help - that's (delaying the menu by "something" > 100ms) however not a viable solution at all. It's not 100% related to the nested eventloop of the popup, calling ::popup instead of ::exec doesn't change a thing.
Created attachment 94675 [details] Workaround patch The grab fails while the button is down - Qt then also seems to release the keyboard. I avoided sending it to the deco, but that didn't help either - nevertheless it seems (from the Qt code) as if the button is currently grabbed (the code is a dumb forward to xcb_grab_pointer) As a workaround, the patch simply ensures a grab on releasing a button when the popup is visible. So far this works w/o side effects. Review request later.
Patch works for me in kwin plasma/5.4 branch. Context menu no longer gets stuck.
Meh, that's a nasty bug in Qt. Anyway: ShipIt(TM)
*** Bug 353954 has been marked as a duplicate of this bug. ***
@Thomas: did you push the patch?
Ehehh... errrmmm... no. Thanks for the reminder. Coming. (No problem, pointed 5.5 only anyway)
Git commit 801e60b2907690bf6de659a313131b85d3a1e1ac by Thomas Lübking. Committed on 16/10/2015 at 13:45. Pushed by luebking into branch 'master'. force grab on useractions menu Workaround, this *seems* a Qt problem. The grab fails while the button is down - Qt then also seems to release the keyboard. Not sending it to the deco didn't help either - nevertheless it seems (from the Qt code) as if the button is currently grabbed (the code is a dumb forward to xcb_grab_pointer) As a workaround, the patch simply ensures a grab on releasing a button when the popup is visible. FIXED-IN: 5.5 M +3 -0 events.cpp M +8 -5 useractions.cpp M +6 -0 useractions.h http://commits.kde.org/kwin/801e60b2907690bf6de659a313131b85d3a1e1ac
*** Bug 354390 has been marked as a duplicate of this bug. ***
*** Bug 356028 has been marked as a duplicate of this bug. ***
This bug is present again on 5.8.5. The submenu disappears either after selecting an option or driving the mouse pointer back on main menu and waiting for a moment.
Created attachment 104400 [details] Menus not disappearing on 5.8.5