https://bugs.winehq.org/show_bug.cgi?id=57650
Bug ID: 57650 Summary: osu! stable: Insert key to minimize to tray does not hide game window (regression) Product: Wine Version: 10.0-rc4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs@winehq.org Reporter: wine@horvath.blog Distribution: ---
Created attachment 77786 --> https://bugs.winehq.org/attachment.cgi?id=77786 broken "x11drv,systray,event" log
Regression commit: 0cda91856138e1d49fcfd9b6c2c9328146616baa
From: Rémi Bernon rbernon@codeweavers.com Date: Thu, 14 Nov 2024 11:53:52 +0100 Subject: [PATCH] winex11: Request window state updates asynchronously.
--- dlls/user32/tests/win.c | 7 +-- dlls/winex11.drv/event.c | 101 +++----------------------------------- dlls/winex11.drv/window.c | 41 +++++++++++----- dlls/winex11.drv/x11drv.h | 3 +- 4 files changed, 37 insertions(+), 115 deletions(-)
Before this commit, pressing the insert key properly unmapped/minimized the window to the system tray. After, it still adds an icon to the tray, but the game window remains open. The tray icon can still be clicked to remove the icon as before.
This problem still occurs on current Wine master (5942da6c) with minor differences, but the issue of not minimizing started with this change.
I mainly use i3wm, but I get the same behavior on swaywm (with the floating dock instead).
https://bugs.winehq.org/show_bug.cgi?id=57650
William Horvath wine@horvath.blog changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |0cda91856138e1d49fcfd9b6c2c | |9328146616baa CC| |rbernon@codeweavers.com, | |wine@horvath.blog
https://bugs.winehq.org/show_bug.cgi?id=57650
--- Comment #1 from William Horvath wine@horvath.blog --- Created attachment 77787 --> https://bugs.winehq.org/attachment.cgi?id=77787 working "x11drv,systray,event" log
https://bugs.winehq.org/show_bug.cgi?id=57650
William Horvath wine@horvath.blog changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
https://bugs.winehq.org/show_bug.cgi?id=57650
William Horvath wine@horvath.blog changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |https://m1.ppy.sh/r/osu!ins | |tall.exe Distribution|--- |ArchLinux
https://bugs.winehq.org/show_bug.cgi?id=57650
--- Comment #2 from William Horvath wine@horvath.blog --- Forgot to mention: to test, the game needs at least native dotnet45 installed in the prefix. Any .NET version between 4.5 and 4.8 is fine.
https://bugs.winehq.org/show_bug.cgi?id=57650
mrdeathjr28@yahoo.es changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mrdeathjr28@yahoo.es
https://bugs.winehq.org/show_bug.cgi?id=57650
--- Comment #3 from Rémi Bernon rbernon@codeweavers.com --- From the log, after the key is pressed there is:
``` 0024:trace:event:call_event_handler 3252 KeyPress for hwnd/window 0x10076/5c00003
0024:trace:x11drv:X11DRV_WindowPosChanged win 0x10076/5c00003 new_rects { window (-32000,-32000)-(-31840,-31969), client (-32000,-32000)-(-32000,-32000), visible (-32000,-32000)-(-31840,-31969) } style 36010000 flags 00008134 0024:trace:x11drv:set_mwm_hints 0x10076 setting mwm hints to 0,3c (style 36010000 exstyle 50008) /* window minimization (WM_STATE == 3) is being requested here: */ 0024:trace:x11drv:window_set_wm_state window 0x10076/5c00003, requesting WM_STATE 0x1 -> 0x3 serial 3288, foreground 0x10076
0024:trace:x11drv:X11DRV_WindowPosChanged win 0x10076/5c00003 new_rects { window (-32000,-32000)-(-31840,-31969), client (-32000,-32000)-(-32000,-32000), visible (-32000,-32000)-(-31840,-31969) } style 26010000 flags 000018ab /* window unmapping request is being delayed, as a minimize is still pending: */ 0024:trace:x11drv:unmap_window win 0x10076/5c00003
0024:trace:x11drv:X11DRV_WindowPosChanged win 0x10076/5c00003 new_rects { window (-32000,-32000)-(-31840,-31969), client (-32000,-32000)-(-32000,-32000), visible (-32000,-32000)-(-31840,-31969) } style 26010000 flags 0000180b 0024:trace:event:call_event_handler 3283 PropertyNotify for hwnd/window 0x10076/5c00003 0024:trace:event:call_event_handler 3284 PropertyNotify for hwnd/window 0x10076/5c00003 0024:trace:event:call_event_handler 3285 PropertyNotify for hwnd/window 0x10076/5c00003 0024:trace:event:call_event_handler 3286 PropertyNotify for hwnd/window 0x10076/5c00003 0024:trace:event:call_event_handler 3287 PropertyNotify for hwnd/window 0x10076/5c00003 0024:trace:event:call_event_handler 3289 PropertyNotify for hwnd/window 0x10076/5c00003
/* the minimization reply is received, window didn't get minimized and we then discard the delayed unmap */ 0024:warn:x11drv:window_wm_state_notify window 0x10076/5c00003, mismatch WM_STATE 0x1/3289, expected 0x3/3288 ```
This looks like a WM bug, we request a minimization and the WM does not minimize the window but instead updates WM_STATE with NormalState. There is no way for us to know that this is not a user action, and we cannot ignore it or override it safely.
We could, perhaps, decide that if the window has an unmap pending we should prefer it over user actions, but I'm not sure it is a good idea to add such logic and it feels brittle.
https://bugs.winehq.org/show_bug.cgi?id=57650
--- Comment #4 from Rémi Bernon rbernon@codeweavers.com --- Created attachment 77795 --> https://bugs.winehq.org/attachment.cgi?id=77795 Possible fix
Still, I think this patch should help, by allowing WithdrawnState requests to override any pending IconicState requests. I'm not completely sure it's a good idea to do this late in the code freeze but I will consider sending it upstream.
https://bugs.winehq.org/show_bug.cgi?id=57650
--- Comment #5 from William Horvath wine@horvath.blog --- (In reply to Rémi Bernon from comment #4)
Created attachment 77795 [details] Possible fix
Thanks, this patch fixes the regression, but I just noticed this: https://github.com/i3/i3/blob/853b0d9161a5f99c8491751590229a449e4076b6/src/h... which seems very relevant.
Changing the XCB_ICCCM_WM_STATE_NORMAL to XCB_ICCCM_WM_STATE_ICONIC there also makes it work again, but it seems to cause other side effects with toggling fullscreen. Removing that block entirely results in slightly different but still broken behavior.
So, you were right in this probably being a WM bug, but it's surprising that the behavior broke in a similar way on swaywm when it doesn't share this code with i3 (I think...).
https://bugs.winehq.org/show_bug.cgi?id=57650
--- Comment #6 from Rafał Mużyło galtgendo@o2.pl --- It would likely help if we could trace that comment to its origin, that is what wine behaviour it refers to and why did the wms decided to fix it in this way.
I mean wine did handle some state changes incorrectly, for example certain aspects of desktop switching (as of 9.22 that was improved, but I haven't check if some of more recent changes haven't regressed that), but that code/comment isn't really clear what is it working around...
https://bugs.winehq.org/show_bug.cgi?id=57650
William Horvath wine@horvath.blog changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Fixed by SHA1| |ea44fc340574c94a18520eb8d66 | |fbd3d83a86686
--- Comment #7 from William Horvath wine@horvath.blog --- Fixed by ea44fc340574c94a18520eb8d66fbd3d83a86686.
Thanks, Rémi.
https://bugs.winehq.org/show_bug.cgi?id=57650
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #8 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 10.1.