Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
x11: Fix window enumeration order when WM doesn't set |_NET_CLIENT_LI…
…ST_STACKING| Chrome needs to know what window to send Xdnd events to during a drag-and-drop operation. It does so through |X11TopmostWindowFinder::FindWindowAt|, which calls into |EnumerateWindows| when the WM has not set |_NET_CLIENT_LIST_STACKING|. GNOME/mutter set this property, so this is a little-tested code path. However, setting this property is not mandated by the spec, and in practice wlroots/Sway do not currently set it. Chrome's current |EnumerateWindows| fallback path is incorrect, resulting in downstream bugs like swaywm/sway#5692 and swaywm/wlroots#2889. |EnumerateWindows| ends up calling |EnumerateChildren|, which uses |XQueryTree| to determine the stacking order. |XQueryTree| returns windows in bottom-to-top order, so the list has to be reverse-iterated to get a top-down order that |FindWindowAt| expects (and to match the order reported by |_NET_CLIENT_LIST_STACKING|). The original code introduced in da11eed did so; however, it regressed in 3c64537 -- currently, the code comments are inconsistent with the actual logic. This commit switches |EnumerateChildren| to use a reverse iterator. It is not used anywhere but as a fallback when |_NET_CLIENT_LIST_STACKING| is not present, so this should be a safe change. I have not touched the iteration order of Chrome's X11 menus. I suspect that these are in the right order already. TEST=manually tested on Sway 1.6, with Chromium overlapping an X11 gedit window Change-Id: I8f777aa566db1e8d0614187fa4b3d156caa1e0f9 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2844104 Reviewed-by: Maksim Sisov <msisov@igalia.com> Commit-Queue: Maksim Sisov <msisov@igalia.com> Cr-Commit-Position: refs/heads/master@{#878767}
- Loading branch information