[Bug 51526] The Longest Five Minutes crashes without virtual desktop

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=51526

--- Comment #6 from Gabriel Ivăncescu <gabrielopcode at gmail.com> ---
Created attachment 70674
  --> https://bugs.winehq.org/attachment.cgi?id=70674
Test hack

So the game creates a (hidden) window that's slightly larger than the screen,
to offset the non-client area, but places it at (0,0) instead of something
negative. In my case (1920x1080 screen), it creates a 1928x1107 window.

After it creates the window, it shows it. The problem is that the window
manager gets involved at that point, and doesn't like such windows because
they're off-screen. So it resizes it to 1920x1051 so it fits the work area (and
for some reason, moves it to (0,2) as well, but that's probably not important),
and then generates a ConfigureNotify event.

When wine's X11 driver sees this event, it attempts to sync the X11 window
(that was resized/moved by the WM) with what the "windows side" sees it (which
right now still believes the window to be in the old size). It does this by
using a SetWindowPos if needed in X11DRV_ConfigureNotify (see
winex11.drv/event.c), which among other things, ends up sending messages to the
window.

For most apps this works fine, as they handle such alien SetWindowPos requests.
There are exceptions though, and this game seems like one of them, but not the
only one I know of. Note that theoretically, other apps could send SetWindowPos
to any other app's window (at least if they have the required privilege), so
it's not out of the ordinary what wine does here, it's just that the app
doesn't expect it (but if you used e.g. AutoHotkey on Windows to send it at
this specific time, it would probably crash as well).

Another bug that comes to mind is the old bug 15346, which suffers from similar
issues due to that SetWindowPos and the WM moving/changing the window (in that
case, WM refuses to move it off-screen), and seems unfixable without nasty
hacks (the attached patch in it only band-aids the problem and breaks some
older apps, as Alexandre mentioned on the mailing list, that expected the
window to disappear if off-screen). In that bug, Winamp doesn't expect the
SetWindowPos call either, it's not even processing a message loop at that
point, and it keeps "track" of its movements manually, and that call breaks
this assumption.

Strangely, for this particular game, it works fine if you put a Sleep for like
1000ms just before that call, which means it's something the game doesn't
expect *at the time* it's generated, likely it uses something uninitialized
yet. Sleeping for 100ms was not enough in my case though, but 1000ms is.

The attached hack (which obviously is *not* a solution) can be used to test if
it works as well (you can try increase the Sleep if you want).

Other things that you can use that makes it work for me, and worth testing to
replicate: Clear the "Allow the window manager to control the windows" in
winecfg's Graphics tab. In this case the WM won't reconfigure the window if it
doesn't like it. In Virtual Desktop it doesn't either, which is why it also
works.

Ultimately I don't think this is fixable without some sort of nasty hack,
unless someone comes up with a very clever idea, unfortunately. (and even then,
getting Alexandre's approval for such fragile code will be very difficult)

-- 
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.