[Bug 54090] New: shell32:autocomplete - test_prefix_filtering() sometimes fails on Windows and Wine
https://bugs.winehq.org/show_bug.cgi?id=54090 Bug ID: 54090 Summary: shell32:autocomplete - test_prefix_filtering() sometimes fails on Windows and Wine Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: shell32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- shell32:autocomplete - test_prefix_filtering() sometimes fails on Windows and Wine: * 2022-07-14 on w8adm (32-bit) autocomplete.c:614: Test failed: Expected (null), got L"aa" * 2022-07-18 on w8adm (32-bit) autocomplete.c:614: Test failed: Expected (null), got L"http://abc.aa.com" * 2022-07-25 w7u-adm (32-bit) autocomplete.c:614: Test failed: Expected (null), got L"www.ax" * 2022-10-12 on debian11-zh-CN (32-bit) for MR!23 autocomplete.c:614: Test failed: Expected (null), got L"ab" autocomplete.c:637: Test failed: Expected (null), got L"www.ax" ... * 2022-11-28 on debian11-zh-CN (32-bit) for MR!1574 autocomplete.c:614: Test failed: Expected (null), got L"ab" autocomplete.c:637: Test failed: Expected (null), got L"www.ax" * 2022-12-05 on debian11-zh-CN (32-bit) for MR!1675 autocomplete.c:614: Test failed: Expected (null), got L"ab" autocomplete.c:637: Test failed: Expected (null), got L"www.ax" See https://test.winehq.org/data/patterns.html#shell32:autocomplete I don't see any trace of these failures in the WineTest nightly runs (though on 2022-12-01 fg-deb64 got the opposite "Expected L"ab", got (null)"). MR!23 is the oldest merge request that I know got impacted by this issue. In total it looks like about 19 merge requests got impacted do far, all with the failure happening on debian11-zh-CN. I also don't see any matching Marvin message on wine-devel so this may be relatively new in Wine. Because of the platform difference and the spread in time (the Windows failures stopping in July and the Wine ones starting in October?) it's not clear if these failures are related, despite being very similar. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=54090 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase -- 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.
https://bugs.winehq.org/show_bug.cgi?id=54090 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gabrielopcode(a)gmail.com -- 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.
https://bugs.winehq.org/show_bug.cgi?id=54090 --- Comment #1 from Gabriel Ivăncescu <gabrielopcode(a)gmail.com> --- This seems like one of those issues where the cursor messes it up. We already had problems with this in the past, so now we move the cursor to the top-left of the main window. Which should work, in theory. In practice, I just ran these tests right now and my cursor was not moved! Because the window spawns at (0,0), and it seems SetCursorPos(0, 0) is a no-op? If I make it move to (1,1) in such case, it works... I can't say with certainty that this is the issue, though. But if I move the mouse over the autocomplete popup, I get very similar errors. I can't reproduce it otherwise. I guess I'll send a MR with SetCursorPos change and see what happens. -- 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.
participants (1)
-
WineHQ Bugzilla