https://bugs.winehq.org/show_bug.cgi?id=53444
Bug ID: 53444 Summary: user32:msg - test_mouse_ll_hook() sometimes gets an unexpecteg mouse position on Windows Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs@winehq.org Reporter: fgouget@codeweavers.com
user32:msg - test_mouse_ll_hook() sometimes gets an unexpected mouse position on Windows:
input.c:1368: Test failed: Wrong new pos: (100,100)
https://test.winehq.org/data/patterns.html#user32:input
This happens on all Windows versions, from Windows 7 to Windows 10 21H2, except, it seems, Windows 8. The invalid mouse position changes from run to run but it seems there are only 14 possible values (out of 550 failure cases), probably because they all come from missed updates.
Wrong new pos: (0,0) Wrong new pos: (100,100) Wrong new pos: (100,99) Wrong new pos: (101,103) Wrong new pos: (102,103) Wrong new pos: (103,102) Wrong new pos: (103,103) Wrong new pos: (140,140) Wrong new pos: (149,149) Wrong new pos: (150,150) Wrong new pos: (160,160) Wrong new pos: (200,200) Wrong new pos: (75,75) Wrong new pos: (99,100)
https://bugs.winehq.org/show_bug.cgi?id=53444
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase
https://bugs.winehq.org/show_bug.cgi?id=53444
--- Comment #1 from François Gouget fgouget@codeweavers.com --- hook_proc1() and hook_proc2() can also issue two related failures with about the same set of invalid positions. For instance:
input.c:1291: Test failed: Wrong set pos: (99,100) input.c:1311: Test failed: GetCursorPos: (99,100)
https://bugs.winehq.org/show_bug.cgi?id=53444
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|user32:msg - |user32:input & user32:msg - |test_mouse_ll_hook() |test_mouse_ll_hook() |sometimes gets an |sometimes gets an |unexpecteg mouse position |unexpecteg mouse position |on Windows |on Windows
--- Comment #2 from François Gouget fgouget@codeweavers.com --- The same failure can happen in user32:input's test_mouse_ll_hook():
input.c:1281: Test failed: GetCursorPos: (100,100) or input.c:1291: Test failed: Wrong set pos: (100,99) or input.c:1447: Test failed: Wrong new pos: (160,160)
Again this happens on all Windows versions, from Windows 7 to Windows 10 21H2, except, it seems, Windows 8. And the coordinates also change from one run to the next but always within the exact same 14 values as for user32:msg (out of 554 failure cases).
https://bugs.winehq.org/show_bug.cgi?id=53444
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|user32:input & user32:msg - |user32:input & user32:msg - |test_mouse_ll_hook() |test_mouse_ll_hook() |sometimes gets an |sometimes gets an |unexpecteg mouse position |unexpected mouse position |on Windows |on Windows
https://bugs.winehq.org/show_bug.cgi?id=53444
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|user32:input & user32:msg - |user32:input - |test_mouse_ll_hook() |test_mouse_ll_hook() |sometimes gets an |sometimes gets an |unexpected mouse position |unexpected mouse position |on Windows |on Windows
--- Comment #3 from François Gouget fgouget@codeweavers.com --- There is no record of this failure happening in user32:msg, at least since 2022-05-30. However it still happens regularly on user32:input. So I modified the bug to only keep the user32:input part.