Commit 71d35d8940118bc6de6522913fb8c473fa5b2c24 broke the way WM_TAKE_FOCUS protocol is implemented: WM_MOUSEACTIVATE now replies MA_NOACTIVATE by default when using HTCAPTION.
We use the WM_MOUSEACTIVATE -although Windows does not- regardless of the way focus is changed to check whether a window wants focus, and Windows sometimes changes focus regardless of the message reply.
Steam and the Wine system tray are affected for instance.
Signed-off-by: Rémi Bernon rbernon@codeweavers.com ---
Resending just this one as the other seems too risky and has been deferred. I have looked for matching bugs, but couldn't find any for sure, and I'm not sure if opening a bug just for it now is worth it.
The dinput mouse test is going to be broken again until a proper fix is found -not because of the focus on mouse hover as I first thought but because of the CreateWindow / X11 focus message race condition, as described in:
https://source.winehq.org/patches/data/176093
dlls/winex11.drv/event.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dlls/winex11.drv/event.c b/dlls/winex11.drv/event.c index dd8837c11da..07f7a1ad502 100644 --- a/dlls/winex11.drv/event.c +++ b/dlls/winex11.drv/event.c @@ -706,7 +706,7 @@ static void handle_wm_protocols( HWND hwnd, XClientMessageEvent *event ) * whether the window wants to be activated */ LRESULT ma = SendMessageW( hwnd, WM_MOUSEACTIVATE, (WPARAM)GetAncestor( hwnd, GA_ROOT ), - MAKELONG(HTCAPTION,WM_LBUTTONDOWN) ); + MAKELONG( HTMENU, WM_LBUTTONDOWN ) ); if (ma != MA_NOACTIVATEANDEAT && ma != MA_NOACTIVATE) { set_focus( event->display, hwnd, event_time );