Alexandre Julliard pushed to branch master at wine / wine
Commits: 48577bd6 by Rémi Bernon at 2025-11-26T20:51:14+01:00 ddraw/tests: Use a dedicated window instead of the desktop window.
We cannot safely switch to the desktop window, and we also cannot safely destroy and re-create windows without risking to lose focus in favor of a foreign window. Lets create a dedicated window to which foreground will be returned whenever the test windows lose it.
- - - - - 0dc76523 by Rémi Bernon at 2025-11-26T20:51:16+01:00 user32/tests: Use a dedicated window instead of the desktop window.
We cannot safely switch to the desktop window, and we also cannot safely destroy and re-create windows without risking to lose focus in favor of a foreign window. Lets create a dedicated window to which foreground will be returned whenever the test windows lose it.
- - - - - 70b0d301 by Rémi Bernon at 2025-11-26T20:51:59+01:00 win32u: Introduce a NtUserSetForegroundWindowInternal call.
For user drivers to forcefully change foreground window, regardless of the restriction which will be introduced next.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58167
- - - - - dc07b689 by Rémi Bernon at 2025-11-26T20:51:59+01:00 server: Set NULL foreground input when switching to desktop window.
When called from the application.
Changing foreground window to the desktop seems like a bad idea, but it also seem to allow later foreground changes back to application windows, as many D3D tests suggest.
Currently we translate these calls into requests to activate the root window, which will usually have no effect, so allowing further changes should be safe.
When the internal flag is set, we actually change the foreground to the desktop window, which should later forbid any further changes made from the application side, as this happens when a non-Wine or foreign window has been focused.
- - - - - f5944829 by Rémi Bernon at 2025-11-26T20:51:59+01:00 server: Forbid background process window reactivation.
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.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58167
- - - - -
24 changed files:
- dlls/ddraw/tests/ddraw1.c - dlls/ddraw/tests/ddraw2.c - dlls/ddraw/tests/ddraw4.c - dlls/ddraw/tests/ddraw7.c - dlls/user32/tests/input.c - dlls/user32/tests/msg.c - dlls/user32/tests/win.c - dlls/win32u/defwnd.c - dlls/win32u/input.c - dlls/win32u/message.c - dlls/win32u/win32u_private.h - dlls/win32u/window.c - dlls/winemac.drv/window.c - dlls/winewayland.drv/window.c - dlls/winex11.drv/event.c - include/ntuser.h - include/wine/server_protocol.h - server/process.c - server/process.h - server/protocol.def - server/queue.c - server/request_handlers.h - server/request_trace.h - server/winstation.c
View it on GitLab: https://gitlab.winehq.org/wine/wine/-/compare/30bff97d2ff4b9a13557b4c26936b9...