[Bug 51391] New: On Windows 7 and 8.1 ntoskrnl.exe:ntoskrnl triggers a network firewall dialog, breaks user32:win
https://bugs.winehq.org/show_bug.cgi?id=51391
Bug ID: 51391 Summary: On Windows 7 and 8.1 ntoskrnl.exe:ntoskrnl triggers a network firewall dialog, breaks user32:win Product: Wine Version: 6.10 Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs@winehq.org Reporter: fgouget@codeweavers.com
On Windows 7 and 8.1 ntoskrnl.exe:ntoskrnl triggers a network firewall dialog (see the screenshots for the TestBot WineTest runs on w7u_2qxl and w8). Despite that ntoskrnl.exe:ntoskrnl succeeds.
However it leaves that dialog open which then causes two failures in user32:win:
https://test.winehq.org/data/patterns.html#user32:win
win.c:3394: Test failed: GetActiveWindow() = 00000000 win.c:3394: Test failed: GetFocus() = 00000000
Notes: * These are the same failures as in bug 51390. If it is decided that user32:win is the test that needs fixing then this bug could be merged. * But if the decision is that ntoskrnl.exe:ntoskrnl should either not trigger such a dialog or close it, then this bug should remain separate. * Most of ntoskrnl.exe:ntoskrnl is skipped on Wow64 so this issue does not happen in newtb-w864-32. * The 64-bit ntoskrnl.exe:ntoskrnl test also does not trigger that dialog for some reason.
https://bugs.winehq.org/show_bug.cgi?id=51391
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase
https://bugs.winehq.org/show_bug.cgi?id=51391
--- Comment #1 from François Gouget fgouget@codeweavers.com --- ntoskrnl.exe:ntoskrnl also causes the two extra failures below:
win.c:5101: Test failed: pixel should be black, color is ffffffff win.c:5121: Test failed: pixel should be black, color is ffffffff
https://bugs.winehq.org/show_bug.cgi?id=51391
Rémi Bernon rbernon@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon@codeweavers.com
--- Comment #2 from Rémi Bernon rbernon@codeweavers.com --- I think ebe3cea01d127de612171b6276c473a2b455266d could partially solve this issue, as SetActiveWindow(0) calls were giving focus to the firewall window. The test is otherwise generally able to put its window on top of it, so it shouldn't disturb it so much.
I have some additional patches that were meant for this more specifically, and which re-create test windows on every test instead of relying on windows created on test initialization. As we manipulate foreground and active windows a bit these end up sometimes below the firewall window, and are not always stacked as later tests expect it.
They cause a bit more instability though, as well a slowing down the tests quite a bit, so they need a bit more work.
https://bugs.winehq.org/show_bug.cgi?id=51391
--- Comment #3 from Rémi Bernon rbernon@codeweavers.com --- Looks like it actually got even worse than before... ouch. There's spurious firewall (and other) windows on a lot of the VMs.
https://bugs.winehq.org/show_bug.cgi?id=51391
--- Comment #4 from François Gouget fgouget@codeweavers.com --- This can also generate the following failures: win.c:5666: Test failed: pixel should be black, color is 00ffffff win.c:5686: Test failed: pixel should be black, color is 00ffffff
-
WineHQ Bugzilla