http://bugs.winehq.org/show_bug.cgi?id=27403 --- Comment #24 from denis bonnenfant <denis.bonnenfant@diderot.org> --- Created attachment 81198 --> http://bugs.winehq.org/attachment.cgi?id=81198 [PATCH 2/2] winex11.drv: Suppress spurious foreground changes from transient _NET_ACTIVE_WINDOW states When an application rapidly calls SetActiveWindow(A) followed by SetActiveWindow(B), Wine sends two _NET_ACTIVE_WINDOW ClientMessages to the window manager. The WM processes these asynchronously; Wine may receive the PropertyNotify confirmation for A before its request for B has reached the WM, or before it has been processed. Multiple Wine threads independently receive the same root-window PropertyNotify. A thread that did not initiate the request has no pending serial and treats the PropertyNotify as an "unexpected" update, potentially triggering a spurious Win32 foreground change to A even though the intended final state is B. A concrete case occurs with SolidWorks PropertyManager: when the user types a digit in a numeric input field, SolidWorks creates a suggestion popup window (P). SetActiveWindow(P) is called (to show it), then immediately SetActiveWindow(field) is called to return focus. X11DRV_ActivateWindow for P calls set_input_focus() directly (P is not WM-managed), causing the WM to update _NET_ACTIVE_WINDOW to P's X11 window. Wine threads process this PropertyNotify and change the Win32 foreground to P, which sends WM_ACTIVATE(deactivate) to the input field, causing it to lose focus and discard the typed digit. Fix by tracking the last _NET_ACTIVE_WINDOW target requested by any thread in a process-wide volatile variable (process_last_nav_request). This variable is updated in set_net_active_window() before the deduplication guard, so it reflects the intended final state even when no new X11 request is actually sent (because the pending state already matches the target). When GetWindowStateUpdates() would change the Win32 foreground based on a PropertyNotify, it first checks whether the notified X11 window matches the last requested target; if not, the PropertyNotify reflects an intermediate transient state and the foreground change is suppressed. Additionally, in net_active_window_notify(), when the requesting thread receives a PropertyNotify that mismatches its pending target (the WM confirmed an intermediate request before the final one arrived), the desired/pending state is restored to the final target and a non-zero sentinel is placed in expect_serial to continue blocking GetWindowStateUpdates on that thread until the final confirmation arrives. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.