http://bugs.winehq.org/show_bug.cgi?id=60179 --- Comment #4 from kahlil88mph@protonmail.com --- Ran a full regression test using `git bisect run` with an automated pass/fail oracle rather than manual testing at each step. Setup: - Built from source (`./configure ... --disable-tests --without-opencl`, gcc 16.2.1 host / mingw-w64-gcc 16.1.0 PE, ccache) at each candidate commit. - Narrowed the bisect range with a pathspec, since the area of the regression was already known from earlier WINEDEBUG tracing: `git bisect start -- dlls/win32u/input.c dlls/win32u/message.c dlls/win32u/window.c dlls/win32u/defwnd.c dlls/user32/input.c server/queue.c server/window.c` - `git bisect good wine-11.12`, `git bisect bad wine-11.13` (confirmed both endpoints manually before trusting the automation). - Oracle script: launch Duplicate Cleaner Free in a dedicated WINEPREFIX, run a scan against a small fixed local dataset, then perform a realistic (gradual mouse movement + held press, not an instant synthetic click) click on the "Scan Complete" dialog's Close button. exit 0 if the dialog actually closes, exit 1 if it's still open after 5 attempts, exit 125 (skip) on any build/launch failure unrelated to the regression itself. - `git bisect run` completed unattended across the narrowed ~15-commit range. Result: 695e721719e761023018a90a0f0828a566bd676b is the first bad commit commit 695e721719e761023018a90a0f0828a566bd676b Author: Rémi Bernon <rbernon@codeweavers.com> Date: Tue Jun 9 14:44:43 2026 +0200 win32u: Keep track of client surface toplevel window. dlls/win32u/window.c | 17 +++++++++++++---- dlls/winewayland.drv/wayland_surface.c | 6 ++++-- dlls/winewayland.drv/window.c | 2 +- dlls/winex11.drv/init.c | 4 ++-- include/wine/gdi_driver.h | 1 + 5 files changed, 21 insertions(+), 9 deletions(-) This matches the mechanism suspected from the earlier trace evidence. Before this commit, `X11DRV_client_surface_present`, `client_surface_update_geometry`, and the Wayland equivalents called `NtUserGetAncestor(hwnd, GA_ROOT)` fresh on every use to find a surface's current top-level window. This commit caches that lookup once in a new `surface->toplevel` field (set in `client_surface_create()` and refreshed only in `client_surface_update_locked()`) and switches those call sites to use the cached value instead of re-querying it. The cache doesn't appear to get invalidated at the right moment when a new owned/modal dialog is created and becomes the real top-level window for a control's rendering surface. The surface's X11-level geometry/stacking stays associated with the previous top-level window, which is consistent with both symptoms in this report: clicks geometrically inside the new dialog being routed to a control on the old (owner) window, and — when the click does reach the right control — the surface/window state around it being stale enough that the click-to-notification step silently fails. Happy to test a candidate patch, attach the full build/bisect log, or provide any additional WINEDEBUG traces against this specific commit if that's useful. -- 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.