[Git][wine/wine][master] 5 commits: ddraw/tests: Use a dedicated window instead of the desktop window.

[Alexandre Julliard (＠julliard)]

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...