November 2025 - Wine-GitLab

[PATCH v4 0/5] MR9511: Draft: server: Forbid background process window reactivation.
by Rémi Bernon Nov. 19, 2025

Nov. 19, 2025

Pegasus Mail posts a WM_USER + 8991 message to its own window when it loses focus, then calls SetFocus on its window when processing this message. Several other applications have been seen calling SetWindowPos during WM_ACTIVATE message, which might also attempt to reactivate the window. That processing happens shortly after we have changed the foreground window to the desktop window, when focus is lost, then SetFocus tries to change the foreground window again. This SetFocus behavior is tested, and should work like this, but would only activate the window if the process is allowed to do so. Windows has various rules around this, and it seems to boil down to something like: * Allow taking focus if the process never was foreground, ie: when process is starting and gets initial focus on its windows. * Allow taking focus if the process was foreground but lost it recently because of a window being destroyed. * Forbid taking focus back if the process had foreground and called SetForegroundWindow explicitly to give it to another process. This doesn't implement all this rules, but rather keep rely on the host window management with some additional heuristics to avoid activating windows which lost foreground recently. This is mostly about keeping track of user input time, updating it on user input and on focus change. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58167 --- I think this should be enough to prevent spurious window reactivation, either from calls to SetWindowPos during WM_ACTIVATE messages like in https://gitlab.winehq.org/wine/wine/-/merge_requests/9398 or from calls to SetFocus from posted messages right after window deactivation as described above. Fwiw we could have tests for that, and show that this MR is fixing them but fvwm doesn't implement window minimization properly, and doesn't change focus when window is minimized, so the tests would be meaningless. -- v4: server: Forbid background process window reactivation. server: Set NULL foreground input when switching to desktop window. win32u: Introduce a NtUserSetForegroundWindowInternal call. user32/tests: Use a dedicated window instead of the desktop window. ddraw/tests: Use a dedicated window instead of the desktop window. https://gitlab.winehq.org/wine/wine/-/merge_requests/9511

1 5

[PATCH 0/7] MR9531: msado15: Reimplement Field::get_Value and Field::put_Value.
by Piotr Caban (＠piotr) Nov. 19, 2025

Nov. 19, 2025

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/9531

2 7

[PATCH v3 0/5] MR9511: Draft: server: Forbid background process window reactivation.
by Rémi Bernon Nov. 19, 2025

Nov. 19, 2025

Pegasus Mail posts a WM_USER + 8991 message to its own window when it loses focus, then calls SetFocus on its window when processing this message. Several other applications have been seen calling SetWindowPos during WM_ACTIVATE message, which might also attempt to reactivate the window. That processing happens shortly after we have changed the foreground window to the desktop window, when focus is lost, then SetFocus tries to change the foreground window again. This SetFocus behavior is tested, and should work like this, but would only activate the window if the process is allowed to do so. Windows has various rules around this, and it seems to boil down to something like: * Allow taking focus if the process never was foreground, ie: when process is starting and gets initial focus on its windows. * Allow taking focus if the process was foreground but lost it recently because of a window being destroyed. * Forbid taking focus back if the process had foreground and called SetForegroundWindow explicitly to give it to another process. This doesn't implement all this rules, but rather keep rely on the host window management with some additional heuristics to avoid activating windows which lost foreground recently. This is mostly about keeping track of user input time, updating it on user input and on focus change. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58167 --- I think this should be enough to prevent spurious window reactivation, either from calls to SetWindowPos during WM_ACTIVATE messages like in https://gitlab.winehq.org/wine/wine/-/merge_requests/9398 or from calls to SetFocus from posted messages right after window deactivation as described above. Fwiw we could have tests for that, and show that this MR is fixing them but fvwm doesn't implement window minimization properly, and doesn't change focus when window is minimized, so the tests would be meaningless. -- v3: server: Forbid background process window reactivation. server: Set NULL foreground input when switching to desktop window. win32u: Introduce a NtUserSetForegroundWindowInternal call. user32/tests: Use a dedicated window instead of the desktop window. ddraw/tests: Use a dedicated window instead of the desktop window. https://gitlab.winehq.org/wine/wine/-/merge_requests/9511

1 5

Re: [PATCH v4 0/1] MR9442: comctl32/treeview: check for child item before SendExpanding
by Thomas Csovcsity (＠thc13) Nov. 19, 2025

Nov. 19, 2025

On Wed Nov 19 15:27:47 2025 +0000, Zhiyi Zhang wrote: > Could you add a test? Not ATM. I do not know, what prerequisites trigger this bug. Could only test it with UltraEdit, which is closed source. Explorer in wine does not trigger this bug. Hints and help with the test is appreciated. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9442#note_122942

1 0

[PATCH 0/7] MR9489: mf: Fix seeking within sample grabber.
by Brendan McGrath (＠redmcg) Nov. 19, 2025

Nov. 19, 2025

This fixes seeking within sample grabber by matching Windows functionality. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9489

3 8

[PATCH 0/1] MR9529: user32: Avoid out-of-bounds read in DdeCreateDataHandle with offset (ASan).
by Bernhard Übelacker Nov. 19, 2025

Nov. 19, 2025

Current implementation applies offset to the source buffer. But it looks like it has to be applied to the destination buffer. The bytes in the destination below the offset seem to get initialized with zero. [Testbot run with this patch](https://testbot.winehq.org/JobDetails.pl?Key=160951) <details> <summary>ASan report details</summary> ``` ================================================================= ==684==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000140292045 at pc 0x6ffffe8ccfac bp 0x7ffffe1feed0 sp 0x7ffffe1fef18 READ of size 5 at 0x000140292045 thread T0 #0 0x6ffffe8ccfab in memmove /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt\lib/asan/../sanitizer_common/sanitizer_common_interceptors_memintrinsics.inc:100:3 #1 0x6ffffa6dd6e4 in DdeCreateDataHandle .../wine/dlls/user32/dde_misc.c:1328 #2 0x000140061ffe in test_DdeCreateDataHandle .../wine/dlls/user32/tests/dde.c:1943 #3 0x00014005b743 in func_dde .../wine/dlls/user32/tests/dde.c:2764 #4 0x000140268dc2 in run_test .../wine/include/wine/test.h:780 #5 0x0001402687cb in main .../wine/include/wine/test.h:900 #6 0x00014026aa5a in mainCRTStartup .../wine/dlls/msvcrt/crt_main.c:62 #7 0x6ffffaf57a54 in BaseThreadInitThunk (C:\windows\system32\kernel32.dll+0x178027a54) #8 0x6ffffdcb06d6 in RtlUserThreadStart (C:\windows\system32\ntdll.dll+0x1700506d6) 0x000140292045 is located 27 bytes before global variable '"Expected non-NULL ptr\n"' defined in '.../wine/dlls/user32/tests/dde.c:1915' (0x000140292060) of size 23 '"Expected non-NULL ptr\n"' is ascii string 'Expected non-NULL ptr ' 0x000140292045 is located 0 bytes after global variable '"data"' defined in '.../wine/dlls/user32/tests/dde.c:1886' (0x000140292040) of size 5 '"data"' is ascii string 'data' SUMMARY: AddressSanitizer: global-buffer-overflow .../wine/dlls/user32/dde_misc.c:1328 in DdeCreateDataHandle ``` </details> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9529

1 1

[PATCH 0/1] MR9528: winevulkan: Avoid returning innacurate extension counts.
by Rémi Bernon Nov. 19, 2025

Nov. 19, 2025

We need to adjust the extension count to take the extra client-side extension into account but we did it in an opportunistic way, adjusting it the maximum possible count when no buffer is provided, then returning a lower number once we were able to filter the extension list. It's been reported to be confusing, so this makes sure the returned extension count is always correct, by requesting the host extensions to an internal buffer. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9528

1 1

[PATCH v2 0/1] MR9479: dlls/sane.ds: Load last settings from registry immediatly when opening the DS
by Bernd Herd (＠herdsoft) Nov. 19, 2025

Nov. 19, 2025

This allows combining the capability negotiation with the application program with the user interface. # Capability values ignored with User Interface The recent patch to save sanner parameters from the twain user interface to the registry restores these parameters from the registry while displaying the dialog box. Settings performed by the application program via the capabilities mechanism are thus overwritten from the registry and ignored. So negotiated parameters are only honoured if the Twain user Interface is not being displayed. In that case _all_ old settings from the previous scan with UI displayed are ignored. # Solution in this merge request The TWAIN 2.4 specification says on Page 4-2 (PDF-Page 76): ``` At the time of loading the data source, all current values for the appropriate capabilities would be set to values that have either been restored from a previous session, or those that are "preferred" by the data source. This current value will remain until it has been explicitly changed by the calling application, or that application issues a MSG_RESET. ``` This is the approach choosen for this merge request: The new function SANE_LoadOptions loads parameter values from the registry when the data source is being opened and transfers them to the sane parameter store. The code in InitializeDialog, that loaded data from the registry, is restored to an older version and does not handle the registry at all. Instead dialog controls are filled based on the information in the SANE parameter database. Saving changed parameters remains as before. -- v2: dlls/sane.ds: Load last settings from registry immediatly when opening the DS https://gitlab.winehq.org/wine/wine/-/merge_requests/9479

4 3

[PATCH v2 0/4] MR9526: win32u/tests: Test which Vulkan/GL/D3D graphics objects hold shared resource handles.
by Derek Lesho (＠dlesho) Nov. 19, 2025

Nov. 19, 2025

In prep for my OpenGL shared resource series. The behavior there seems to be heavily driver-specific. -- v2: Apply 1 suggestion(s) to 1 file(s) https://gitlab.winehq.org/wine/wine/-/merge_requests/9526

2 4

[PATCH 0/4] MR9527: widl: Use the metadata short name for parameterized types.
by Hans Leidekker (＠hans) Nov. 19, 2025

Nov. 19, 2025

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/9527

3 5