This is the refactoring of the tests in !7160. I submit a new seperate MR because I want to get the tests upstreamed first, otherwise making changes to tests patches needs rebasing the implementation patches. So plz review the tests MR first.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7332
If a surface is being clipped and hides the cursor, drawing its own one,
winewayland constrains using a pointer lock and enables Wayland relative
motion. If the application decides to stop drawing its own cursor and
make the cursor visible, winewayland will disable relative motion and
pointer lock, and enable pointer confinement. The user will perceive a
pointer jump from the win32/application drawn cursor to where the
Wayland pointer is after being unlocked and an absolute motion event is
received, because they were desynchronized due to the Wayland one being
locked in place.
The pointer constraints protocol says this:
> If the client is drawing its own cursor, it should update the position
> hint to the position of its own cursor. A compositor may use this
> information to warp the pointer upon unlock in order to avoid pointer
> jumps.
So, right before unlocking, make a request for the compositor to warp
the pointer to the win32 position on pointer unlock.
--
v2: winewayland: Request warp to win32 position on pointer unlock.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7352
--
v2: oleaut32: Add support for decoding SLTG variable help strings.
oleaut32: Add support for decoding SLTG function help strings.
oleaut32: Implement decoding of SLTG help strings.
oleaut32: 'typekind' is the last field of SLTG_OtherTypeInfo structure.
oleaut32: Fix logic for deciding whether type description follows the name.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7334
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57665
---
The issue is that The Medium launcher uses a dialog window procedure, and implements its background by doing a StretchBlt call on WM_PAINT in the dialog procedure call, which happens before the window message loop.
It then itself calls InvalidateRect(hwnd, NULL, 0), which queues a WM_PAINT as well but with only the RDW_INVALIDATE flag.
Next, when the window message loop is executed, the WM_PAINT message is being processed as it should, but as we've invalidate the window with RDW_ERASE ourselves from the expose event, the WM_NCPAINT handler erases the entire window, clearing the pixels that the launcher has just painted.
This regressed since the window surface clipping region logic changed, as the expose event handling was previously not calling `NtUserRedrawWindow` on windows with a surface and without a clipping region. The clipping region was also previously not always set, or set later, and we're setting it more consistently since 51b16963f6e0e8df43118deac63f640aee4698b7, even when it matches the window rect, for compatibility with some old wineandroid logic (where I believe it was used to clip window surfaces to their proper sizes).
--
v3: winex11: Avoid setting RDW_ERASE on expose events.
explorer: Paint the desktop even without RDW_ERASE.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7157
This cleans up `LDR_DONT_RESOLVE_REFS` checks in preparation for !7.
--
v4: ntdlll: Remove redundant LDR_DONT_RESOLVE_REFS checks before calling process_attach().
ntdll: Skip DLL initialization and ldr notification entirely if DONT_RESOLVE_DLL_REFERENCES is set.
kernel32/tests: Test for unexpected loader notification for import dependency loaded with DONT_RESOLVE_DLL_REFERENCES.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7347