http://bugs.winehq.org/show_bug.cgi?id=12142
Summary: "make test" fails in user32/msg.ok Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: user32 AssignedTo: wine-bugs@winehq.org ReportedBy: wine@fatlxception.no-ip.org
I get the following failures when running "make test" on user32/msg.ok:
msg.c:4117: Test failed: SetWindowPos:WmSWP_ResizeNoZOrder: the msg 0x0047 was expected, but got msg 0x0005 instead msg.c:4117: Test failed: SetWindowPos:WmSWP_ResizeNoZOrder: the msg 0x0005 was expected, but got msg 0x030f instead msg.c:4117: Test failed: SetWindowPos:WmSWP_ResizeNoZOrder: the msg sequence is not complete: expected 0000 - actual 001c msg.c:6103: Test succeeded inside todo block: Alt press/release: marked "todo_wine" but succeeds
I've been seeing this failure for quite a while and been skipping past it. Just reproduced it in today's git. I'm running Ubuntu Gutsy 32-bit. Did a "rm -rf ~/.wine && wineprefixcreate" immediately before the test. I'm running on a 'bare' X server (nothing but xterm), and winecfg is set to not allow managed windows. If I reconfigure it to use a virtual desktop, the test failures go away but the succeeding todo_wine remains.
Let me know if there's more information I can provide.
http://bugs.winehq.org/show_bug.cgi?id=12142
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |DUPLICATE
--- Comment #1 from Austin English austinenglish@gmail.com 2008-03-21 18:40:07 --- Duplicate. Apparently user32 is very finicky, and because of the variations in window managers, hard to fix for everyone. While I think we should attempt to fix it for as many as possible (submit bugs upstream to the WM's for instance), ATM this is a wontfix.
*** This bug has been marked as a duplicate of bug 12053 ***
http://bugs.winehq.org/show_bug.cgi?id=12142
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #2 from Austin English austinenglish@gmail.com 2008-03-21 18:40:20 --- Closing.
http://bugs.winehq.org/show_bug.cgi?id=12142
--- Comment #3 from Brad Martin wine@fatlxception.no-ip.org 2008-03-21 20:02:22 --- I sent these comments to Austin and he asked me to post them here.
As my original comment stated, I ran the test both with wine-managed windows with no window manager running, and in a virtual desktop window. In both cases there is no window manager to report bugs against. I understand not wanting to fix the test for every single window manager anyone might be running, but fixing it for either (or both) of these cases seems like the easiest and most reproducible approach for everyone. As it stands, all that would be needed to fix it for the virtual desktop setup would be to remove the todo_wine around the one test that is passing.
Having a regression test suite that only one person can run doesn't help me much in determining if I've broken something.
http://bugs.winehq.org/show_bug.cgi?id=12142
--- Comment #4 from Dmitry Timoshkov dmitry@codeweavers.com 2008-03-22 04:53:59 --- (In reply to comment #3)
Having a regression test suite that only one person can run doesn't help me much in determining if I've broken something.
What are you trying to fix that requires running user32 message tests? Anyway, having the same set of tests failing in the same fashion before and after your patch is a good start.
http://bugs.winehq.org/show_bug.cgi?id=12142
--- Comment #5 from Brad Martin wine@fatlxception.no-ip.org 2008-03-22 13:57:30 --- (In reply to comment #4)
What are you trying to fix that requires running user32 message tests? Anyway, having the same set of tests failing in the same fashion before and after your patch is a good start.
Nothing specifically yet, I just wanted to get a baseline for the project as a whole before I started changing anything. I thought make test was intended to be a project-wide regression test, so I tried using it for that purpose. When I got failures I asked on IRC whether make test was expected to pass or not, and I was told yes, and to report any failures as bugs. If make test is only intended to be used by one person then disregard; however this diminishes the potential usefulness of the test suite IMO. In the meantime I can patch up my local git branch to pass the tests I expect to pass, but that doesn't prevent someone else from asking the same questions in the future. Seems like it would be helpful to explain this somewhere, as well as things like don't run make test on the ALSA driver (dsound fails), or with any serial ports enabled on your computer (kernel32 fails). I don't see any of this in the Developer's Guide section on make test; is there somewhere else I should be looking?
http://bugs.winehq.org/show_bug.cgi?id=12142
--- Comment #6 from Alexandre Julliard julliard@winehq.org 2008-03-22 14:08:22 --- Tests are supposed to pass everywhere, but getting to that point is a lot of work.
If you really want to fix the message test the first step is to run in managed mode, the other modes are much less interesting as far as window management is concerned.
http://bugs.winehq.org/show_bug.cgi?id=12142
--- Comment #7 from Dmitry Timoshkov dmitry@codeweavers.com 2008-03-22 22:16:19 --- (In reply to comment #5)
I thought make test was intended to be a project-wide regression test, so I tried using it for that purpose. When I got failures I asked on IRC whether make test was expected to pass or not, and I was told yes, and to report any failures as bugs. If make test is only intended to be used by one person then disregard; however this diminishes the potential usefulness of the test suite IMO.
'make test' is intended to run and pass in all cases, but there are cases when a test fails. In that case the first thing to do is investigate *why* the test fails, and only when there is a good understanding what's the source of the misbehaviour try to fix it.
user32 message were passing for me completely without single failure until recent WM related changes. That doesn't mean that changes are incorrect, that simply discovers bugs and inconsistent behaviour in WMs out there.
http://bugs.winehq.org/show_bug.cgi?id=12142
--- Comment #8 from Brad Martin wine@fatlxception.no-ip.org 2008-03-23 01:35:28 --- (In reply to comment #6)
If you really want to fix the message test the first step is to run in managed mode, the other modes are much less interesting as far as window management is concerned.
That's unfortunate; managed mode is the furthest from working without failures on my setup. Tried it on my normal compiz/emerald desktop (didn't really expect good results there) and on a bare X server with only metacity running.
What window managers are known to pass this test in managed mode?
http://bugs.winehq.org/show_bug.cgi?id=12142
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|CVS/GIT |unspecified
-
wine-bugs＠winehq.org