[PATCH v2 1/3] user32/tests: Skip inconsistent OemKeyScan tests on non-us keyboard.

[Rémi Bernon]

Signed-off-by: Rémi Bernon <rbernon(a)codeweavers.com>
---

Supersedes: 205706-205709

Proper fix for test_GetRawInputBuffer failures in PATCH 2, the tentative
fix from the previous version aren't actually making any different.

The issue was that the win test leaves the cursor in a different
position, above the window that the test creates, when testbot makes
several runs for various archs or locales, the first run has the cursor
in a good place, but later runs are affected by the win test outcome.

When the cursor is moved, there may be some additional WM_INPUT messages
generated from X11 events, if the cursor is above the window (or if it
suddenly leaves the window) that aren't when it's not.

Making sure the window is not above the window (and will not cross it
when it's moved) on test startup fixes the problem.

 dlls/user32/tests/input.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/dlls/user32/tests/input.c b/dlls/user32/tests/input.c
index 3d4f0d03d0d..d10a7f6504d 100644
--- a/dlls/user32/tests/input.c
+++ b/dlls/user32/tests/input.c
@@ -4167,6 +4167,13 @@ static void test_OemKeyScan(void)
     WCHAR oem, wchr;
     char oem_char;
 
+    BOOL us_kbd = (GetKeyboardLayout(0) == (HKL)(ULONG_PTR)0x04090409);
+    if (!us_kbd)
+    {
+        skip("skipping test with inconsistent results on non-us keyboard\n");
+        return;
+    }
+
     for (oem = 0; oem < 0x200; oem++)
     {
         ret = OemKeyScan( oem );
-- 
2.31.0

[PATCH v2 2/3] user32/tests: Initialize the cursor position in test_GetRawInputBuffer.

[Rémi Bernon]

Signed-off-by: Rémi Bernon <rbernon(a)codeweavers.com>
---
 dlls/user32/tests/input.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/dlls/user32/tests/input.c b/dlls/user32/tests/input.c
index d10a7f6504d..1679048794b 100644
--- a/dlls/user32/tests/input.c
+++ b/dlls/user32/tests/input.c
@@ -2236,10 +2236,15 @@ static void test_GetRawInputBuffer(void)
     UINT size, count, rawinput_size;
     HWND hwnd;
     BOOL ret;
+    POINT pt;
 
     if (is_wow64) rawinput_size = sizeof(RAWINPUT64);
     else rawinput_size = sizeof(RAWINPUT);
 
+    SetCursorPos(300, 300);
+    GetCursorPos(&pt);
+    ok(pt.x == 300 && pt.y == 300, "Unexpected cursor position pos %dx%d\n", pt.x, pt.y);
+
     hwnd = CreateWindowA("static", "static", WS_VISIBLE | WS_POPUP,
                          100, 100, 100, 100, 0, NULL, NULL, NULL);
     SetWindowLongPtrA(hwnd, GWLP_WNDPROC, (LONG_PTR)rawinputbuffer_wndproc);
-- 
2.31.0

[PATCH v2 2/3] user32/tests: Initialize the cursor position in test_GetRawInputBuffer.

[Marvin]

Hi,

While running your changed tests, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?

Full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=90497

Your paranoid android.


=== w7u_2qxl (32 bit report) ===

user32:
input.c:757: Test failed:  0 (a4/0): 00 from 00 -> 80 unexpected
input.c:757: Test failed:  0 (a4/0): 41 from 01 -> 00 unexpected

=== w7u_el (32 bit report) ===

user32:
input.c:4447: Test failed: SendInput triggered unexpected message 0xc042

=== w1064v1809 (32 bit report) ===

user32:
input.c:2789: Test failed: 0: expected WM_MOUSEMOVE message
input.c:2789: Test failed: 1: expected WM_MOUSEMOVE message
input.c:2789: Test failed: 2: expected WM_MOUSEMOVE message

=== wvistau64 (64 bit report) ===

user32:
input.c:757: Test failed:  0 (a4/0): 01 from 01 -> 00 unexpected
input.c:757: Test failed:  0 (a4/0): 11 from 01 -> 00 unexpected
input.c:757: Test failed:  0 (a4/0): a2 from 01 -> 00 unexpected

=== w1064_2qxl (64 bit report) ===

user32:
input.c:1303: Test failed: Wrong set pos: (100,98)
input.c:1323: Test failed: GetCursorPos: (100,98)
input.c:1372: Test failed: Wrong new pos: (100,98)

[PATCH v2 3/3] user32/tests: Recreate the window to make it more likely to have focus.

[Rémi Bernon]

Signed-off-by: Rémi Bernon <rbernon(a)codeweavers.com>
---
 dlls/user32/tests/input.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/dlls/user32/tests/input.c b/dlls/user32/tests/input.c
index 1679048794b..654cabb76d9 100644
--- a/dlls/user32/tests/input.c
+++ b/dlls/user32/tests/input.c
@@ -2763,6 +2763,10 @@ static void test_rawinput(const char* argv0)
         {
         case 14:
         case 15:
+            DestroyWindow(hwnd);
+            hwnd = CreateWindowA("static", "static", WS_VISIBLE | WS_POPUP,
+                                 pt.x - 50, pt.y - 50, 100, 100, 0, NULL, NULL, NULL);
+            ok(hwnd != 0, "CreateWindow failed\n");
             SetWindowPos(hwnd, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOSIZE|SWP_NOMOVE);
             SetForegroundWindow(hwnd);
             empty_message_queue();
-- 
2.31.0

[PATCH v2 3/3] user32/tests: Recreate the window to make it more likely to have focus.

[Marvin]

Hi,

While running your changed tests, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?

Full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=90498

Your paranoid android.


=== w7u_2qxl (32 bit report) ===

user32:
input.c:757: Test failed:  0 (a4/0): 00 from 00 -> 80 unexpected
input.c:757: Test failed:  0 (a4/0): 41 from 01 -> 00 unexpected

=== w7u_el (32 bit report) ===

user32:
input.c:4451: Test failed: SendInput triggered unexpected message 0xc042

=== wvistau64 (64 bit report) ===

user32:
input.c:757: Test failed:  0 (a4/0): 01 from 01 -> 00 unexpected
input.c:757: Test failed:  0 (a4/0): 11 from 01 -> 00 unexpected
input.c:757: Test failed:  0 (a4/0): a2 from 01 -> 00 unexpected

[Rémi Bernon]

On 5/14/21 4:04 PM, Rémi Bernon wrote:
> Signed-off-by: Rémi Bernon <rbernon(a)codeweavers.com>
> ---
>
> Supersedes: 205706-205709
>
> Proper fix for test_GetRawInputBuffer failures in PATCH 2, the tentative
> fix from the previous version aren't actually making any different.
>
> The issue was that the win test leaves the cursor in a different
> position, above the window that the test creates, when testbot makes
> several runs for various archs or locales, the first run has the cursor
> in a good place, but later runs are affected by the win test outcome.
>
> When the cursor is moved, there may be some additional WM_INPUT messages
> generated from X11 events, if the cursor is above the window (or if it
> suddenly leaves the window) that aren't when it's not.
>
> Making sure the window is not above the window

I meant the cursor, obviously.

FWIW I was confused that the testbot pattern page reports this failure 
only since 05/03. I guess maybe the way the tests are run have changed 
around that date.

I could reproduce the same failure when running the tests in winetest 
since Wine 6.7 at least (and it was probably the case even before), 
although it's not marked as failing there:

   https://test.winehq.org/data/patterns.html#user32:input
-- 
Rémi Bernon <rbernon(a)codeweavers.com>

[Francois Gouget]

On Fri, 14 May 2021, Rémi Bernon wrote:
[...]
> FWIW I was confused that the testbot pattern page reports this failure only
> since 05/03.

Looking at the reports before that date shows that this failure did not 
happen then.
> I guess maybe the way the tests are run have changed around that date.

It's possible something changed on fg-deb64*, cw-gtx560* and cw-rx460* 
since they have unattended upgrades. However the TestBot's debiant2 VM 
does not and I did not change anything in that VM around that date (I 
updated vkd3d on 2021-03-02 and added MwmDecor on 2021-05-11).

So the only explanation I can think of is that some other test changed 
on that date, causing this one to start failing [1].
> I could reproduce the same failure when running the tests in winetest since
> Wine 6.7 at least (and it was probably the case even before), although it's
> not marked as failing there:
>
> https://test.winehq.org/data/patterns.html#user32:input

I had the same issue with msxml3:domdoc. test.winehq.org showed it 
starting to fail on Linux on 2021-03-25 but it was still crashing even 
when I tried older builds. Eventually it turned out to be an old 
refcounting bug so probably something changed in the build toolchain 
that caused it to crash due to the memory corruption.


[1] When a test mysteriously starts failing on a TestBot Windows VM 
    another possibility is that of a change in the build toolchain used 
    for the official WineTest binary. But for Linux TestBot VMs the 
    TestBot uses its own self-built binaries so that rules out changes 
    in the build toolchain (unless the VM snapshot was changed in which 
    case anything goes).

-- 
Francois Gouget <fgouget(a)codeweavers.com>

[Marvin]

Hi,

While running your changed tests, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?

Full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=90496

Your paranoid android.


=== w7u_2qxl (32 bit report) ===

user32:
input.c:757: Test failed:  0 (a4/0): 00 from 00 -> 80 unexpected
input.c:757: Test failed:  0 (a4/0): 41 from 01 -> 00 unexpected

=== w1064v1809 (32 bit report) ===

user32:
input.c:2784: Test failed: 0: expected WM_MOUSEMOVE message
input.c:2784: Test failed: 1: expected WM_MOUSEMOVE message
input.c:2784: Test failed: 2: expected WM_MOUSEMOVE message

=== wvistau64 (64 bit report) ===

user32:
input.c:757: Test failed:  0 (a4/0): 01 from 01 -> 00 unexpected
input.c:757: Test failed:  0 (a4/0): 11 from 01 -> 00 unexpected
input.c:757: Test failed:  0 (a4/0): a2 from 01 -> 00 unexpected

=== w1064_2qxl (64 bit report) ===

user32:
input.c:1303: Test failed: Wrong set pos: (100,100)
input.c:1323: Test failed: GetCursorPos: (100,100)

=== w10pro64 (64 bit report) ===

user32:
input.c:1303: Test failed: Wrong set pos: (100,100)
input.c:1323: Test failed: GetCursorPos: (100,100)