commit c3b818fd3576d6ac480fabb68f3b57b2c1f64393
author Liam Brady <lbrady@google.com> Fri Jul 25 23:31:25 2025
committer Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> Fri Jul 25 23:31:25 2025
tree ff13f2db1d4fb224c726c5b1f01939a6bd07965b
parent 7bedadc070227c1f80b02341ea970d1191e49904

RenderDocument: Fix Mac size-related tests.

TL;DR: Modify macOS window sizing workaround to set the size for the
RFH/RWHV being navigated, rather than just the existing RFH/RWHV, but
only for non-popups.

With RenderDocument enabled, a bunch of size-related tests are failing
only on the Mac bots. This is happening because of some quirks with how
macOS headless tests handle setting the window size. Since there is no
window created, macOS will not send window size updates, so a workaround
was put in place to simulate those window size updates so that a
primary main frame is set up with the correct window size.

However, the code assumes that the RenderFrameHost being navigated is
the same as the RenderFrameHost that's the existing primary main frame,
and will only send size updates to the currently established primary
main frame. Up until now, that assumption was correct enough for these
tests (cross-site navigations would involve a RFH swap, but these tests
are usually only performing same-origin navigations). With
RenderDocument enabled, all cross-document navigations now involve a RFH
swap. So the workaround will see a new main frame is being created,
update the old RFH's associated RenderWidgetHostView with the window
size, and leave the new RFH's associated RenderWidgetHostView with an
invalid size.

When the RFH swap occurs, the new document will not have received any
window size update, and will therefore have an incorrect window size in
place, causing issues with anything that is either directly testing
size-related parameters (like window.outerWidth) or testing features
that use window size (like scrolling).

To fix this, the newly created RenderWidgetHostView for the newly
created RenderFrameHost gets SetWindowFrameInScreen() invoked, ensuring
that it has the correct value by the time the navigation commits.

In a perfect world, this would be enough of a fix. But this introduces
an extra corner case with popup windows. Because the window size is
updated later than it would normally be updated, there's a race where,
if a popup is created and then resized while navigating, this
intervention will clobber the resized value of the popup window.

(See: mismatched-snapshot-containing-block-size-skips.html)

The intention of this is to ensure that the first top-level frame
created by the test always has the correct size after a navigation. In
the interest of time, and rather than trying to chase down a race
condition for a corner case that only exists due to a workaround when
tests are being run on macOS in headless mode, the intervention in this
CL will only happen if the render frame being created isn't for a popup.

This fixes the following tests with RenderDocument enabled on macOS:
- external/wpt/css/css-overflow/scrollbar-gutter-propagation-007.html
- external/wpt/html/semantics/forms/the-input-element/change-to-empty-value.html
- fast/dom/icon-url-list-viewport.html
- fast/dom/viewport/resize-event-fired-window-resized.html
- fast/dom/Window/window-resize-contents.html
- fast/dynamic/window-resize-scrollbars-test.html
- inspector-protocol/emulation/device-emulation-desktop.js
- svg/custom/mixed-percent-size-zoom.svg
- svg/custom/percent-size-zoom.svg
- virtual/stable/fast/dom/Window/window-resize-contents.html
- virtual/text-antialias/line-break-between-text-nodes-with-inline-blocks.html

Change-Id: I4c19be42d611392273724af419ef113af23696d5
Bug: 40615943
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6779004
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Liam Brady <lbrady@google.com>
Cr-Commit-Position: refs/heads/main@{#1492351}