New subject: [Bug 60171] A click that falls through a native-surface-less active top-level window incorrectly deactivates it

Aug. 14, 2026

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

            Bug ID: 60171
           Summary: A click that falls through a native-surface-less
                    active top-level window incorrectly deactivates it
           Product: Wine
           Version: 11.14
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Keywords: patch
          Severity: normal
          Priority: P2
         Component: win32u
          Assignee: wine-bugs@list.winehq.org
          Reporter: devel@velmeden.info
  Target Milestone: ---
      Distribution: ArchLinux

Created attachment 81813
  --> http://bugs.winehq.org/attachment.cgi?id=81813
Patch

*I ran into this bug but could not find or reproduce the underlying cause
myself, so I investigated it together with an AI assistant. The text and patch
below is written by the AI, based on that interactive troubleshooting session.*

## Summary

`process_mouse_message()` (`dlls/win32u/message.c`) reactivates whatever
top-level window a click's X11 event resolves to, and deactivates the
previously-active window as a side effect, whenever the clicked window
differs from the currently active one. This is correct when the click is a
genuine user action on a different window. It is wrong when the currently
active top-level window has no native (X11) surface of its own: any click
physically within that window's on-screen bounds can only ever be
delivered by the X server to whatever real window happens to be
underneath or around it (typically an ancestor), since the active window
itself has nothing on screen to receive input. Wine currently can't tell
these two cases apart, so it deactivates a window the user visually
clicked on, purely because of how the click was routed at the X11 level.

## Why a top-level window can have no native surface

Some applications create ordinary (non-`WS_CHILD`) top-level windows whose
visible content is presented through some other mechanism than Wine's own
X11 "whole window" — for example, a toolkit-hosted child surface embedded
inside a native host window, where the toolkit's own window/surface object
is what's actually on screen, while the win32-visible `HWND` exists purely
for message routing, focus and activation bookkeeping. In such a case
`X11DRV_get_whole_window(hwnd)` legitimately returns `0` for that `HWND`
even though it is a real, activatable top-level window as far as the
win32 window manager is concerned.

## Observed effect

I diagnosed this on Wine 11.14 against Loxone Config (an MFC + Qt6 hybrid
application), whose MDI document window is exactly such a case: its X11
"whole window" is destroyed early on and never recreated for the rest of
the session (confirmed structural, not a transient timing gap — traced via
`create_whole_window()`/`destroy_whole_window()` instrumentation across a
full session), while Wine's own bookkeeping still tracks it as the active
top-level window (`NtUserGetForegroundWindow()`/`info.hwndActive`).

Any real mouse click physically over that window's on-screen area
resolves, at the raw X11 level, to whichever window is actually behind it
(confirmed via instrumented `X11DRV_ButtonPress` logging the raw event's
`window`/`subwindow` fields together with each window's actual X11 id —
the click's `ButtonPress` event targets the ancestor's real X11 window,
never the document window's, because the latter doesn't have one).
`process_mouse_message()` then runs its normal
`WM_MOUSEACTIVATE`/`set_foreground_window()`/`set_active_window()`
cascade for "a click on a different top-level window", which sends
`WM_ACTIVATE(WA_INACTIVE)` to the window that was actually still active
and that the click was visually intended for. Any interaction state that
window's application logic keeps tied to activation (for example, a
pending drag-and-drop-style operation initiated by an earlier click) gets
torn down as a result, even though the user's click landed squarely
inside that window's visible bounds.

This does not require the click to race anything — in the traced case,
the affected window had already been without a native surface for ~30
seconds before the failing click, so this is a deterministic
misclassification, not a timing-sensitive race.

## Steps to reproduce

1. Download Loxone Config:
https://updatefiles.loxone.com/LoxConfig/LoxoneConfigSetup_17010727.zip
2. Unzip it and run the installer under Wine: `wine LoxoneConfigSetup.exe`
   (click through the installer normally).
3. Launch `LoxoneConfig.exe` and open or create any project.
4. Pick any block/object to add, either via the search dialog (press
   `F5` to open it, type e.g. `RS` to find the "RS Flipflop" block, and
   pick it from the results) or by dragging one of the toolbar symbols —
   either way it attaches to the mouse cursor as a drag preview.
5. Move the mouse over the project canvas and click to place it.

Expected: the block is placed on the canvas.

Actual: the drag preview disappears on mouse-down, but no block is
actually added — no visible change, and `Edit` → `Undo` stays greyed out,
confirming the placement was never registered. This is 100% reproducible.

## Fix

Attached patch adds a `WindowHasNativeSurface(HWND) -> BOOL` user driver
entry point (default `TRUE`; implemented for `winex11.drv` via the
existing `X11DRV_get_whole_window()` helper, other drivers unaffected).
In `process_mouse_message()`, before running the reactivation cascade for
a click that resolves to a different top-level window, check whether the
window Wine still considers active has no native surface and
geometrically contains the click point; if so, treat this as a
click-through rather than a genuine activation change, and skip the
cascade. The check is narrowly scoped: it does not redirect the click
itself, does not touch window-surface creation/lifecycle, and every other
click-resolution/activation path (including everything on drivers other
than `winex11.drv`, where the new hook always returns `TRUE`) is
unaffected.

## Testing

- Live-validated against the real application described above: prior to
  the fix, the described interaction failed 100% of the time; after the
  fix, the specific click-misrouting-to-an-ancestor mechanism no longer
  tears down the document window's activation state (confirmed via the
  same gdb instrumentation, both on a debug and on a release (`-O2`)
  Wine build).
- `dlls/user32/tests/msg.c` and `dlls/user32/tests/input.c` run clean
  (via an isolated `Xephyr` X server, since the interactive desktop
  proved too environment-sensitive for a byte-accurate baseline
  comparison): no activation/`WM_ACTIVATE`/`WM_MOUSEACTIVATE`-related
  failures attributable to the patch across multiple runs.

## Known limitation of this report

I don't yet have a minimal, app-independent C reproduction case for this
specific mechanism (a separate, previously-considered mechanism for the
same user-facing symptom turned out, on later investigation, to be a
distinct and still-open issue in the same application, unrelated to this
patch). I'm glad to build one (the core ingredients — a top-level
window with no native surface set as active, and a second, real window
overlapping its screen area — should be reproducible with plain Win32
API plus one Wine-internal step to force the surface-less state) if that
would help review; in the meantime the patch was developed and validated
against a live repro that exhibits the exact structural condition
described above, with full gdb-level traces at each step (raw X11 event
routing, `set_active_window()` call arguments, and whole-window
create/destroy lifecycle) establishing the mechanism precisely rather
than by inference.

-- 
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 60171] New: A click that falls through a native-surface-less active top-level window incorrectly deactivates it

WineHQ Bugzilla

WineHQ Bugzilla

WineHQ Bugzilla

WineHQ Bugzilla

WineHQ Bugzilla

tags

participants (1)