https://bugs.winehq.org/show_bug.cgi?id=48142
Bug ID: 48142 Summary: shell32:appbar tests fail on some Windows 10 machines Product: Wine Version: 4.20 Hardware: x86 OS: Windows Status: NEW Severity: normal Priority: P2 Component: shell32 Assignee: wine-bugs@winehq.org Reporter: madewokherd@gmail.com
https://test.winehq.org/data/tests/shell32:appbar.html
Some of the "cw" win10 machines fail in shell32:appbar. Mine happens to work when running the test on its own. I haven't been able to find a pattern, other than that none of the machines are on the current build.
Without a machine that can reproduce this, I don't see a way to figure out what's going on.
It would seem based on the results that appbar functionality does not work at all.
One possibility is that a previous test leaves explorer in a bad state. If so, running the test on its own should succeed. It would also explain the correlation between failures here and in shell32:systray https://test.winehq.org/data/a9c4b309f6af82b624604bd0df898ad88d59ab5a/index_...
https://bugs.winehq.org/show_bug.cgi?id=48142
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source, testcase
https://bugs.winehq.org/show_bug.cgi?id=48142
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd@gmail.com
--- Comment #1 from Vincent Povirk madewokherd@gmail.com --- It looks like user32:msg failures correlate as well. Minimized windows don't get their positions set properly, which also makes sense if explorer is broken.
Unfortunately, that doesn't give any more information about what's breaking it.
https://bugs.winehq.org/show_bug.cgi?id=48142
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #2 from Zebediah Figura z.figura12@gmail.com --- I know that user32:win does kill explorer.exe, for what I personally feel are not really worthwhile reasons.
https://bugs.winehq.org/show_bug.cgi?id=48142
--- Comment #3 from Vincent Povirk madewokherd@gmail.com --- That would happen after these failures, though, right?
https://bugs.winehq.org/show_bug.cgi?id=48142
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fgouget@codeweavers.com
--- Comment #4 from Zebediah Figura z.figura12@gmail.com --- (In reply to Vincent Povirk from comment #3)
That would happen after these failures, though, right?
Presumably, yes. Unless we run tests serially without reverting, which I vaguely recall happens in some cases?
https://bugs.winehq.org/show_bug.cgi?id=48142
--- Comment #5 from Vincent Povirk madewokherd@gmail.com --- That could be it. In every failing case, it's <tag>-32 followed by <tag>-64. The -32 succeeds and the -64 fails.
https://bugs.winehq.org/show_bug.cgi?id=48142
--- Comment #6 from François Gouget fgouget@codeweavers.com --- (In reply to Vincent Povirk from comment #5)
That could be it. In every failing case, it's <tag>-32 followed by <tag>-64. The -32 succeeds and the -64 fails.
Yes, the non-TestBot machines (so cw-* and fg-*) first run the 32 bit WineTest and then run the 64 bit WineTest. That's because for these machines a "revert" means restoring the Windows partition from backup so it's a bit on the heavy side.
That's not the case for the TestBot VMs. Those perform a revert between each WineTest run.
That said the tests should try not to completely break the test environment: if a 32 bit test unit kills explorer.exe that could just as well impact the other 32 bit test units that follow.
https://bugs.winehq.org/show_bug.cgi?id=48142
--- Comment #7 from Esme Povirk madewokherd@gmail.com --- Instead of killing explorer, could we create a new desktop that doesn't have a shell?
https://bugs.winehq.org/show_bug.cgi?id=48142
--- Comment #8 from Esme Povirk madewokherd@gmail.com --- I sent a patch that does that: https://www.winehq.org/pipermail/wine-devel/2020-December/178798.html
https://bugs.winehq.org/show_bug.cgi?id=48142
Esme Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Regression SHA1| |bc2e193d9ade47660e17bf720ec | |68d32e9984846 Resolution|--- |FIXED
--- Comment #9 from Esme Povirk madewokherd@gmail.com --- I think this is fixed? At least, I don't see appbar failures in recent builds on test.winehq.org, and at least one of the machines that had been showing failures ran the tests.
https://bugs.winehq.org/show_bug.cgi?id=48142
Esme Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |bc2e193d9ade47660e17bf720ec | |68d32e9984846 Regression SHA1|bc2e193d9ade47660e17bf720ec | |68d32e9984846 |
https://bugs.winehq.org/show_bug.cgi?id=48142
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #10 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 6.0-rc5.
-
WineHQ Bugzilla