[Bug 59965] New: x11drv UI elements become unclickable after switching windows due to unexpected WM_CANCELMODE during mouse grab

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=59965

            Bug ID: 59965
           Summary: x11drv UI elements become unclickable after switching
                    windows due to unexpected WM_CANCELMODE during mouse
                    grab
           Product: Wine
           Version: 11.12
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: blocker
          Priority: P2
         Component: -unknown
          Assignee: [e-mail]
          Reporter: [e-mail]
                CC: [e-mail], [e-mail]
  Target Milestone: ---
      Distribution: ---

When switching focus between applications via Alt+Tab, the application's
buttons and UI elements sometimes become completely unresponsive to mouse
clicks.

Steps to Reproduce (occurs from time to time):

Open an application.
Interact with the UI (e.g., click down on a scrollbar, a custom button, or
start a drag operation).
While the application is in this state, switch focus to another window
(Alt+Tab).
Switch back to the affected application.

Sometimes the bug occurs.

Actual Results: The UI ignores mouse clicks. The application is not frozen (it
might still respond to keyboard input), but the internal mouse capture/UI state
is broken.

Workaround: The only way to restore mouse functionality is to minimize the
affected window, switch to another app, and then restore the window. Minimizing
forces a hard state reset and ReleaseCapture, while restoring forces a full
WM_PAINT. This fixes the unclickable UI.

Expected Results: Switching windows should not permanently break the
application's internal mouse capture or UI state machine. Buttons should remain
clickable after returning to the application.

Technical Details & Proposed Fix: The issue occurs because winex11.drv sends a
WM_CANCELMODE message to the foreground window when it loses focus, even if the
application currently holds an X11 mouse grab
(x11drv_thread_data()->grab_hwnd). This causes a desync: the application resets
its internal state (cancels menus/captures due to WM_CANCELMODE), but the
X11-level grab might persist or the app's internal framework gets stuck in a
transitional state.

Skipping WM_CANCELMODE when a mouse grab is active completely resolves the
issue.

Here is the patch that fixes the bug:


diff --git a/dlls/winex11.drv/event.c b/dlls/winex11.drv/event.c
--- a/dlls/winex11.drv/event.c
+++ b/dlls/winex11.drv/event.c
@@ -888,5 +888,12 @@
     if (hwnd != NtUserGetForegroundWindow()) return;
     if (!(NtUserGetWindowLongW( hwnd, GWL_STYLE ) & WS_MINIMIZE))
-        send_message( hwnd, WM_CANCELMODE, 0, 0 );
+    {
+        if (x11drv_thread_data()->grab_hwnd)
+        {
+            TRACE("Skipping WM_CANCELMODE, mouse is grabbed by %p.\n",
x11drv_thread_data()->grab_hwnd);
+        }
+        else
+            send_message( hwnd, WM_CANCELMODE, 0, 0 );
+    }

This is the same root cause as here (fix is the same):
https://bugs.winehq.org/show_bug.cgi?id=59653

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

[Bug 59965] x11drv UI elements become unclickable after switching windows due to unexpected WM_CANCELMODE during mouse grab

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=59965

Ken Sharp <[e-mail]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|blocker                     |normal

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