[Bug 60179] New: Regression (11.12 → 11.13): mouse clicks on a newly-shown owned/modal dialog are misrouted to the owner window, or silently fail to trigger the clicked control's notification

[WineHQ Bugzilla]

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

            Bug ID: 60179
           Summary: Regression (11.12 → 11.13): mouse clicks on a
                    newly-shown owned/modal dialog are misrouted to the
                    owner window, or silently fail to trigger the clicked
                    control's notification
           Product: Wine
           Version: 11.13
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: win32u
          Assignee: [e-mail]
          Reporter: [e-mail]
  Target Milestone: ---
      Distribution: ArchLinux

Created attachment 81843
  --> http://bugs.winehq.org/attachment.cgi?id=81843
Trimmed WINEDEBUG traces

Between Wine 11.12 and 11.13, mouse click handling for a modal dialog shown on
top of
its owner window regressed. Two related but distinct symptoms are reproducible,
both
tied to the same window/owner relationship at the moment a new top-level dialog
appears:

1. Clicks landing within the dialog's screen bounds are sometimes dispatched to
a
   control on the **owner window underneath** instead of the dialog, even
though the
   dialog is the window actually visible/topmost on screen.
2. When the click **does** reach the correct control (e.g. a "Close" button on
the
   dialog), the button goes through a fully normal-looking
   `WM_LBUTTONDOWN → WM_SETFOCUS → WM_LBUTTONUP → WM_CAPTURECHANGED` sequence,
but
   never sends the resulting `WM_COMMAND` (`BN_CLICKED`) notification to the
dialog,
   so the click has no effect. Activating the same button via keyboard (Space
bar)
   works every time, since that path skips whatever position check is failing
on
   mouse-up.

A user-discovered workaround: briefly "shading" and un-shading the dialog
window
(or resizing/maximizing-then-restoring the owner window) temporarily restores
correct click behavior, consistent with a stale cached window rect/z-order
being
recalculated on any geometry-change event.

Specifically, the program in question is Duplicate Cleaner Free 3.2.7
(DigitalVolcano Software) — a .NET WinForms
application (owner-drawn buttons via `WM_DRAWITEM`, runs under wine-mono).
Likely reproducible with any WinForms app that shows an owned dialog
immediately
after a background operation completes.

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