http://bugs.winehq.org/show_bug.cgi?id=59345 --- Comment #7 from Rémi Bernon <rbernon@codeweavers.com> --- Created attachment 80365 --> http://bugs.winehq.org/attachment.cgi?id=80365 Test showing broken behavior Although the behavior may seem regressive, there's been various issues with message processing around the blamed commits, and it seems to be timing dependent. The issue comes from window focus not matching Windows, and what the application expects. The application creates five windows each time it opens a menu. Four of the windows are transparent layered windows (WS_EX_TRANSPARENT | WS_EX_LAYERED), which are used for some unknown app-specific purpose. The fifth window is a classic WS_EX_TOOLWINDOW / WS_POPUP window. They are all created / shown / stacked in a specific order by the application. The windows are shown with SW_SHOWNA which is supposed to show the windows on screen but not activate them. We implement this through the EWMH X11 protocol, by setting _NET_WM_USER_TIME = 0 property before mapping the window (https://specifications.freedesktop.org/wm/latest/ar01s05.html#id-1.6.16). This is meant to tell the window manager not to activate it upon mapping, neither through XSetInputFocus, nor WM_TAKE_FOCUS. Yet, we still seem to sometimes receive WM_TAKE_FOCUS events, which we need to respond to by activating the window, as it may come from a user action without any way for us to tell. The application then gets confused as it receives focus change messages when it does not expect so. This then varies a bit depending on which window gets activated and it seems like it only decides to close the menu if the non-layered window is, possibly assuming that the window got activated by a mouse click on a menu item.
This happens in a KWin Wayland session but not in an X11 session nor did it happen using IceWM. That does mean it could be an issue with XWayland and not Wine.
This seems to be the reason for the WM_TAKE_FOCUS we receive, and it looks like that it also depends on where the window is being opened. I can reproduce this on XWayland with GNOME, with the attached test, which passes on windows or with a X11 session. It looks like that if a window is created above, or moved above right after mapping, the currently active window, it gets the WM_TAKE_FOCUS every time, regardless of _NET_WM_USER_TIME value. If the window is mapped elsewhere, it doesn't. This is IMO a broken EWMH implementation, either from XWayland or from the X11 window manager under XWayland, and it should be fixed there. -- 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.