http://bugs.winehq.org/show_bug.cgi?id=12196
Summary: Application window fails to be rendered after resize/minimize/restore cycle in managed mode Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: NEW Keywords: regression Severity: major Priority: P2 Component: winex11.drv AssignedTo: wine-bugs@winehq.org ReportedBy: a_villacis@palosanto.com
Somewhere between 0.9.56 and 0.9.57, a regression was introduced that causes an application window (in any app) to fail to be rendered properly. To reproduce (with Wine Notepad, but any application can be used):
1) Run: wine notepad 2) Drag app window border to make it bigger. This (apparently) works. 3) Minimize application window using the WM decorations (tested under GNOME/Metacity). 4) Immediately after minimize, try to restore the app window. Almost all of the tries result in the window failing to be restored properly. Only a tiny rectangle appears in the upper left corner.
I found this bug after doing that very same sequence as described above. I have tried to bisect this, but I didn't have time to complete it. I have narrowed it to:
git-bisect start # bad: [a32e36aee5684abca33001eea3a0768ab603c373] Release 0.9.57. git-bisect bad a32e36aee5684abca33001eea3a0768ab603c373 # good: [14991a42d1d28ae114f8f06f5e3ca209aefd87a7] Release 0.9.56. git-bisect good 14991a42d1d28ae114f8f06f5e3ca209aefd87a7 # bad: [e6cbde105f81990bb96c5b243e78ba77582f28ba] qmgr: Implement IBackgroundCopyFile_GetProgress. git-bisect bad e6cbde105f81990bb96c5b243e78ba77582f28ba # good: [62694157936baf64d20ab10e2c464bd1b1d6d34b] wined3d: Add GL_APPLE_float_pixels. git-bisect good 62694157936baf64d20ab10e2c464bd1b1d6d34b
This bug is confirmed at my home computer and my work computer. Both are running Fedora Core 8.
http://bugs.winehq.org/show_bug.cgi?id=12196
--- Comment #1 from Alex Villacís Lasso a_villacis@palosanto.com 2008-03-24 15:24:47 --- Bug confirmed in current 0.9.58 GIT
http://bugs.winehq.org/show_bug.cgi?id=12196
--- Comment #2 from Lei Zhang thestig@google.com 2008-03-24 16:55:29 --- Can you post a screenshot? I'm not seeing this problem with wine-git on KDE 3.5.
http://bugs.winehq.org/show_bug.cgi?id=12196
--- Comment #3 from Alex Villacís Lasso a_villacis@palosanto.com 2008-03-24 17:26:36 --- Created an attachment (id=11623) --> (http://bugs.winehq.org/attachment.cgi?id=11623) Raddecay application, before minimize/restore cycle
Run of application Raddecay (viewer of radioactive isotope properties), before the minimize/restore cycle, with current git.
http://bugs.winehq.org/show_bug.cgi?id=12196
--- Comment #4 from Alex Villacís Lasso a_villacis@palosanto.com 2008-03-24 17:28:22 --- Created an attachment (id=11624) --> (http://bugs.winehq.org/attachment.cgi?id=11624) Raddecay application, after minimize/restore cycle
Run of application Raddecay (viewer of radioactive isotope properties), after the minimize/restore cycle, with current git. Note that the underlying window is visible through the foreground window.
http://bugs.winehq.org/show_bug.cgi?id=12196
--- Comment #5 from Alex Villacís Lasso a_villacis@palosanto.com 2008-03-24 17:29:36 --- Created an attachment (id=11625) --> (http://bugs.winehq.org/attachment.cgi?id=11625) Wine regedit, before minimize/restore cycle
Wine regedit, before minimize/restore cycle, with current git.
http://bugs.winehq.org/show_bug.cgi?id=12196
--- Comment #6 from Alex Villacís Lasso a_villacis@palosanto.com 2008-03-24 17:31:07 --- Created an attachment (id=11626) --> (http://bugs.winehq.org/attachment.cgi?id=11626) Wine regedit, after minimize/restore cycle
Wine regedit, after minimize/restore cycle, with current git. In this case, it took a few retries of minimizing, restoring, and resizing before successfully triggering the bug.
http://bugs.winehq.org/show_bug.cgi?id=12196
--- Comment #7 from Lei Zhang thestig@google.com 2008-03-24 17:35:04 --- Are you using Beryl / Compiz? I don't see it with KDE, and I don't remember seeing this with Gnome (metacity) either.
Does anyone else see this?
http://bugs.winehq.org/show_bug.cgi?id=12196
--- Comment #8 from Alex Villacís Lasso a_villacis@palosanto.com 2008-03-24 17:38:29 --- (In reply to comment #7)
Are you using Beryl / Compiz? I don't see it with KDE, and I don't remember seeing this with Gnome (metacity) either.
Does anyone else see this?
No, in fact I am unable to run beryl/compiz at either my home or work computer. BTW, the work computer uses fglrx driver, the home computer uses savage driver.
http://bugs.winehq.org/show_bug.cgi?id=12196
--- Comment #9 from Alex Villacís Lasso a_villacis@palosanto.com 2008-03-24 17:49:55 --- (In reply to comment #7)
Are you using Beryl / Compiz? I don't see it with KDE, and I don't remember seeing this with Gnome (metacity) either.
Does anyone else see this?
In fact, I am unable to reproduce this with twm, mwm or wmaker. This might be a metacity-specific issue.
http://bugs.winehq.org/show_bug.cgi?id=12196
--- Comment #10 from Alex Villacís Lasso a_villacis@palosanto.com 2008-03-24 19:00:48 --- # good: [5ddcb2c1d36b676da2b9db714225ce3772dc6378] mscms/tests: The tests shouldn't fail if we have some ICM files. git-bisect good 5ddcb2c1d36b676da2b9db714225ce3772dc6378
http://bugs.winehq.org/show_bug.cgi?id=12196
--- Comment #11 from Alex Villacís Lasso a_villacis@palosanto.com 2008-03-24 19:38:42 --- Found the guilty commit:
eaea28e5d83b8d302eed62dbf574b5d6d2c14cdd is first bad commit commit eaea28e5d83b8d302eed62dbf574b5d6d2c14cdd Author: Alexandre Julliard julliard@winehq.org Date: Wed Feb 27 19:15:12 2008 +0100
winex11: Check the current window state on Map/UnmapNotify and ignore obsolete events.
:040000 040000 7e1445566b90d5698bf55518f394983085e88ad8 7f53d5ee2efbcca69979a10aec3338501e313674 M dlls
http://bugs.winehq.org/show_bug.cgi?id=12196
Lei Zhang thestig@google.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bgerst@didntduck.org
--- Comment #12 from Lei Zhang thestig@google.com 2008-03-24 20:58:14 --- *** Bug 12170 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=12196
Lei Zhang thestig@google.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kc8ldo@arrl.net
--- Comment #13 from Lei Zhang thestig@google.com 2008-03-24 22:37:49 --- *** Bug 12151 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=12196
--- Comment #14 from Dmitry Timoshkov dmitry@codeweavers.com 2008-03-25 04:36:40 --- What metacity version is that? I don't see any problem with 2.18.2.
http://bugs.winehq.org/show_bug.cgi?id=12196
--- Comment #15 from Alex Villacís Lasso a_villacis@palosanto.com 2008-03-25 10:26:14 --- Using metacity-2.20.2-1.fc8, from fc8 repository.
http://bugs.winehq.org/show_bug.cgi?id=12196
--- Comment #16 from Dmitry Timoshkov dmitry@codeweavers.com 2008-03-25 11:05:02 --- Alexandre is using the same version in Debian and apparently doesn't see that problem. Probably it's worth to report a bug to FC/Metacity developers.
http://bugs.winehq.org/show_bug.cgi?id=12196
--- Comment #17 from Alex Villacís Lasso a_villacis@palosanto.com 2008-03-25 11:08:05 --- (In reply to comment #16)
Alexandre is using the same version in Debian and apparently doesn't see that problem. Probably it's worth to report a bug to FC/Metacity developers.
Please note that, at least for some applications, it might take a few window manipulations, including all of resize/minimize/restore in order to trigger the bug. So Alexandre might not be trying hard enough.
http://bugs.winehq.org/show_bug.cgi?id=12196
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |julliard@winehq.org
--- Comment #18 from Dmitry Timoshkov dmitry@codeweavers.com 2008-03-25 11:22:35 --- Adding Alexandre to the cc: list.
http://bugs.winehq.org/show_bug.cgi?id=12196
--- Comment #19 from Leland C. Scott kc8ldo@arrl.net 2008-03-25 11:31:34 --- (In reply to comment #14)
What metacity version is that? I don't see any problem with 2.18.2.
I was having the same problem (bug 12151) on Fedora 8 using Metacity.i386 version 2.20.2-1.fc8
One more point I DID NOT see this bug under Fedora Core 5 using Metacity.i386 version 2.14.3-1.fc5.1
http://bugs.winehq.org/show_bug.cgi?id=12196
--- Comment #20 from Leland C. Scott kc8ldo@arrl.net 2008-03-25 11:35:14 --- (In reply to comment #19)
(In reply to comment #14)
What metacity version is that? I don't see any problem with 2.18.2.
I was having the same problem (bug 12151) on Fedora 8 using Metacity.i386 version 2.20.2-1.fc8
This is with wine 0.9.58
One more point I DID NOT see this bug under Fedora Core 5 using Metacity.i386 version 2.14.3-1.fc5.1
This is with wine 0.9.57
http://bugs.winehq.org/show_bug.cgi?id=12196
--- Comment #21 from Alexandre Julliard julliard@winehq.org 2008-03-25 13:42:26 --- (In reply to comment #17)
Please note that, at least for some applications, it might take a few window manipulations, including all of resize/minimize/restore in order to trigger the bug. So Alexandre might not be trying hard enough.
Actually I haven't tried at all with metacity, Dmitry was probably confusing this with another bug. I'll try it when I have a moment.
http://bugs.winehq.org/show_bug.cgi?id=12196
--- Comment #22 from Leland C. Scott kc8ldo@arrl.net 2008-03-26 11:58:03 --- (In reply to comment #20)
(In reply to comment #19)
(In reply to comment #14)
What metacity version is that? I don't see any problem with 2.18.2.
I was having the same problem (bug 12151) on Fedora 8 using Metacity.i386 version 2.20.2-1.fc8
This is with wine 0.9.58
One more point I DID NOT see this bug under Fedora Core 5 using Metacity.i386 version 2.14.3-1.fc5.1
This is with wine 0.9.57
A note to the group I tried wine 0.9.58, compiled and installed, on a Fedora Core 5 system using Metacity.i386 version 2.14.3-1.fc5.1 and there is no window paint problem with the current version of wine. Seem like the problem occurs with later version of the window manager - Metacity. This is the exact same system that I had wine 0.9.57 on above.
http://bugs.winehq.org/show_bug.cgi?id=12196
--- Comment #23 from Alex Villacís Lasso a_villacis@palosanto.com 2008-03-28 18:12:57 --- Created an attachment (id=11718) --> (http://bugs.winehq.org/attachment.cgi?id=11718) +event,+x11drv trace of app with blank window, restored correctly
The sequence used in this patch is: start app resize by dragging window border to a big size minimize wait until screen is static restore
http://bugs.winehq.org/show_bug.cgi?id=12196
--- Comment #24 from Alex Villacís Lasso a_villacis@palosanto.com 2008-03-28 18:14:18 --- Created an attachment (id=11719) --> (http://bugs.winehq.org/attachment.cgi?id=11719) +event,+x11drv trace of app with blank window, restored incorrectly
Same sequence as previous log, except that this time application was restored while screen was still being updated from minimize. From this, it seems there is a race condition involved somewhere.
http://bugs.winehq.org/show_bug.cgi?id=12196
--- Comment #25 from Alex Villacís Lasso a_villacis@palosanto.com 2008-03-31 12:15:33 --- Created an attachment (id=11769) --> (http://bugs.winehq.org/attachment.cgi?id=11769) Workaround for issuing of PropertyNotify after MapNotify
The root cause of the bug is that dlls/winex11.drv/event.c calls get_window_wm_state() to get the state of the window (which could be NormalState or IconicState for the purposes of this bug) in X11DRV_MapNotify(), but at the moment it does, the window has not yet received the notification that the property has changed, so it sees IconicState even when the window is being restored.
As seen in the attached logs:
trace:event:call_event_handler MapNotify for hwnd/window 0x1002e/4c00007 trace:x11drv:X11DRV_MapNotify win 0x1002e/4c00007 ignoring since state=3 ... trace:event:call_event_handler PropertyNotify for hwnd/window 0x1002e/4c00007 trace:event:EVENT_PropertyNotify 0x1002e/4c00007: new WM_STATE 1
It seems that (at least in Metacity) there is no guarantee that the window state will no longer change when MapNotify is received. It can be any value (IconicState or NormalState) by the time the app gets around to process the event. Here the state changed *after* the MapNotify was received. The handler decided to ignore the event, and when the PropertyNotify was received, it did nothing.
BTW, the WM can choose to change the value *before* MapNotify, even when the PropertyNotify is issued *after* MapNotify. In that case the app is restored normally. The typical race condition. I don't know whether this describes incorrect WM behavior, but a workaround is needed for it.
The attached patch seems to fix this issue for me. It issues X11DRV_MapNotify when it detects that the window is still marked as iconic on a transition from IconicState to NormalState. Please comment on this.
Patch also sent to wine-patches.
http://bugs.winehq.org/show_bug.cgi?id=12196
Alex Villacís Lasso a_villacis@palosanto.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
http://bugs.winehq.org/show_bug.cgi?id=12196
Alex Villacís Lasso a_villacis@palosanto.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #26 from Alex Villacís Lasso a_villacis@palosanto.com 2008-04-02 18:56:04 --- Alexandre committed fixes for this bug (a different and more robust one than the sample patch given here). Bug fixed in current git. Thanks!
http://bugs.winehq.org/show_bug.cgi?id=12196
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #27 from Alexandre Julliard julliard@winehq.org 2008-04-04 10:05:46 --- Closing bugs fixed in 0.9.59.
http://bugs.winehq.org/show_bug.cgi?id=12196
Ploum ploum@fritalk.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ploum@fritalk.com
--- Comment #28 from Ploum ploum@fritalk.com 2008-04-11 04:35:56 --- *** Bug 12211 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=12196
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|CVS/GIT |unspecified