[Bug 60208] New: BonziBuddy: Microsoft Agent context menu is never dismissed on a Wayland session (Xwayland)
http://bugs.winehq.org/show_bug.cgi?id=60208 Bug ID: 60208 Summary: BonziBuddy: Microsoft Agent context menu is never dismissed on a Wayland session (Xwayland) Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs@list.winehq.org Reporter: wehrwolfmann@gmail.com Target Milestone: --- Distribution: --- Created attachment 81897 --> http://bugs.winehq.org/attachment.cgi?id=81897 test program: ownerless WS_POPUP window with TrackPopupMenu BonziBuddy is a desktop assistant from 2002 that draws a cartoon character on top of everything else and opens a Microsoft Agent context menu when you right click it. Under Wine the character works fine, but the menu never goes away: it opens where I expect it, and then clicking anywhere outside it does nothing at all, and Escape does not close it either. The only things that dismiss it are picking one of its own items or clicking back on the character. About versions, so nobody wastes time: I could only watch BonziBuddy itself on Wine 10.0, because on anything newer the Microsoft Agent character does not load at all, which is bug 60177. The attached test program needs no Microsoft Agent and behaves exactly the same way on 11.15, which is the version I put on this report. Both were a 64 bit prefix running a 32 bit application on KDE Plasma 6.7.4 with KWin 6.7.4 as a Wayland session, so it goes through winex11.drv on Xwayland. On a plain X server (I used Xvfb) the same binaries close their menus normally, so it is the Xwayland side that makes the difference. The test program opens an ordinary window and an ownerless WS_POPUP tool window with WS_EX_NOACTIVATE, the way Microsoft Agent creates the window its character lives in, shows a plain TrackPopupMenu context menu on right click in either of them and prints to stderr when a menu opens and when the menu loop ends. On a plain X server both menus close on a click elsewhere and print WM_EXITMENULOOP and the TrackPopupMenu return value. In the Wayland session the ordinary window still behaves, and so does the File menu of builtin notepad, but the popup window's menu never closes and never prints anything. While such a menu is stuck, xdotool getwindowfocus reports a window that does not belong to Wine at all, which would explain the dead Escape key. I can build and test any proposed fix. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=60208 Ken Sharp <imwellcushtymelike@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |testcase -- 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.
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.
participants (1)
-
WineHQ Bugzilla