commit | 8c2d62e7bf4b7e04a071ea1ef4898f9d7559a6e7 | [log] [tgz] |
---|---|---|
author | Nick Diego Yamane <nickdiego@igalia.com> | Wed Apr 16 18:38:16 2025 |
committer | Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> | Wed Apr 16 18:38:16 2025 |
tree | 85fd725450d33ee60eab26de3bed82ff3204cddc | |
parent | bc113e5e8287a0fbd291dd2e5bb7357e7bb330d7 [diff] |
[M136] ozone/wayland: send first set_window_geometry at correct timing Per the spec [1]: > When applied, the effective window geometry will be the set window > geometry clamped to the bounding rectangle of the combined geometry of > the surface of the xdg_surface and the associated subsurfaces. Thus, geometry must be set only when a non-empty buffer gets attached. Otherwise, it's equivalent to setting a 0x0 rectangle. This fixes it by initializing both toplevel and popup window state to `unknown`. Which is set to something else only when the first configure sequence is received (ie: xdg_(toplevel|popup).configure + xdg_surface.configure). That state change is then used to determine when the first xdg_surface.set_window_geometry must be sent. Significant part of this CL is about updating ozone/wayland test expectations as well as test logic in some cases. Remarkably: - Now emulating the first "surface activation" configure sequence is no longer enough to put the xdg surface in "configured" state. Instead, it will only happen once the first buffer is committed. Which, depending on the purpose of the test, is done either (1) by triggering WaylandWindow::OnSequencePoint(), or (2) by creating and attaching a real (shm) buffer. WaylandWindow tests use approach (1), for example, while BufferManager tests use method (2). - Some test logic had to be modified, as they were taking assumptions about the xdg surface state (which no longer apply) and setting expectations upon them. (cherry picked from commit 14941d9d38af4baf14e5120f4c59bc2710a5d9ef) Bug: 361631328 Fixed: 410960094 Test: Manually with gnome 48.1 as well as ozone_unittests Change-Id: Iad3d0a26edef5c8d227533cef1b9227b07cfd1e3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6451729 Reviewed-by: Orko Garai <orko@igalia.com> Reviewed-by: Kramer Ge <fangzhoug@chromium.org> Commit-Queue: Nick Yamane <nickdiego@igalia.com> Reviewed-by: Eliot Courtney <edcourtney@chromium.org> Cr-Original-Commit-Position: refs/heads/main@{#1447216} Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6461047 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Auto-Submit: Nick Yamane <nickdiego@igalia.com> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/branch-heads/7103@{#1036} Cr-Branched-From: e09430c64983fc906f37a9f7e6806275c9b67b86-refs/heads/main@{#1440670}
Chromium is an open-source browser project that aims to build a safer, faster, and more stable way for all users to experience the web.
The project's web site is https://www.chromium.org.
To check out the source code locally, don't use git clone
! Instead, follow the instructions on how to get the code.
Documentation in the source is rooted in docs/README.md.
Learn how to Get Around the Chromium Source Code Directory Structure.
For historical reasons, there are some small top level directories. Now the guidance is that new top level directories are for product (e.g. Chrome, Android WebView, Ash). Even if these products have multiple executables, the code should be in subdirectories of the product.
If you found a bug, please file it at https://crbug.com/new.