http://bugs.winehq.org/show_bug.cgi?id=60208 --- Comment #1 from Wehrwolfmann <wehrwolfmann@gmail.com> --- I measured what the stuck menu does to the rest of the session, and two things in my report were imprecise. The menu holds an active X pointer grab, so while it hangs the mouse is dead in every X11 client on that Xwayland at once - any other client asking for the pointer gets AlreadyGrabbed. That is how I ran into it in the first place: I spent an evening unable to click anything in Steam and looked for the fault there, when it was a menu I had left open off to the side. Wayland-native clients are unaffected, and there is no keyboard grab. Saying that clicking outside does nothing was too broad. Clicking any X11 client, including another window of the same Wine process, does close the menu correctly, with WM_EXITMENULOOP and TrackPopupMenu returning 0, although the click itself is swallowed and never reaches whatever I clicked on. Clicking a Wayland surface - the Plasma desktop, any Wayland application - leaves the menu untouched, and on a Plasma session that is most of the screen, which is why it feels undismissable. That looks like the root of it to me: an active pointer grab does not reach across the Wayland boundary, so the grab owner is only told about clicks Xwayland itself receives. The foreign window I mentioned from xdotool getwindowfocus is not part of this, and I should not have brought it up. 0x200000 is KWin's 1x1 InputOnly focus holder and it owns the X focus whenever no X11 client is focused, stuck menu or not. If an X11 client had the focus before the menu opened it keeps it and its keyboard still works. Escape does nothing because the popup is WS_EX_NOACTIVATE and the Wine window never takes the X focus at all; setting the input focus to it by hand and then pressing Escape closes the menu properly. One more failure mode, in case someone tries to work around this: if the menu window is forcibly unmapped, the grab is released on its own, but Wine stays inside the menu tracking loop forever. No WM_EXITMENULOOP, TrackPopupMenu never returns, and every later right click is swallowed, so that application never shows a menu again. It looks like a hang, but the process is healthy, and sending a synthetic Escape to any of its windows gets it out cleanly. Worth knowing too that a Wine menu window and a Wine tooltip cannot be told apart by their X properties - both override-redirect, both _NET_WM_WINDOW_TYPE_DIALOG, both with WM_TRANSIENT_FOR and input=False. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.