fix(engine): propagate viewport changes to the live JS context

[danperks]

What & why

set_viewport updated the process-global metrics that seed a future JS context, but never touched
a context that already existed. A loaded page therefore kept the size it started at forever:

• window.innerWidth / innerHeight / devicePixelRatio stayed frozen at load-time values
• width-based media queries never re-evaluated, so matchMedia(...).matches went stale
• no resize event was ever dispatched

Anything doing its own responsive work in JS was pinned to its load-time layout. I hit this building
a GPUI frontend against the engine: resizing the window resized the framebuffer, but the page inside
it kept laying out for the old width.

__viewportChanged is added to the browser environment — it refreshes the globals, re-evaluates
live MediaQueryLists and dispatches resize — with Session::notify_viewport_changed to drive it.
This deliberately mirrors the existing notify_color_scheme_changed path rather than inventing a
second mechanism.

Ordering: re-layout happens before dispatch

The part worth reviewing closely. A resize handler exists in order to measure, and
getBoundingClientRect reads the pushed rect table, not the globals set above. Dispatching first
therefore let handlers observe pre-resize geometry and cache the wrong values — a stale layout is
arguably worse than no event, because the page acts on it confidently.

So set_viewport now drops the layout cache, re-runs ensure_layout, and re-pushes the rect table
before dispatching. The cache is dropped once more afterwards, so DOM mutations made by handlers
are laid out on the next render (the same reasoning as set_color_scheme).

The regression test pins this ordering specifically. It asserts on a percentage-width div measured
inside the handler, because the root's own clientWidth falls back to innerWidth and so would
pass even if layout had never re-run. Verified in both directions — with the re-layout removed the
handler sees 500 (the pre-resize width) instead of 320.

Noted but deliberately not fixed here

clientWidth/clientHeight are never populated for non-root elements: set_layout_rects feeds
getBoundingClientRect but not the __elemMetrics padding-box fields, so a non-root element reads
0. That is a pre-existing gap unrelated to resize, and folding it in would have muddled this
change — happy to open a separate issue or PR for it if useful.

🤖 How this was built

• Authored primarily with an LLM (which: Claude Opus 5, driven via Cursor)

Checklist

• PR title is a Conventional Commit
• cargo test --workspace passes — adds
  resize_relayouts_before_handlers_observe_geometry, which also covers that an unchanged
  viewport does not re-enter JS at all
• cargo fmt --all + cargo clippy clean for this change (clippy reports some pre-existing
  warnings in wurl and net, untouched here)
• No conformance regressions — this path is not exercised by the WPT reftest runner, which uses
  a fixed viewport; covered by the unit test above instead

Made with Cursor

[danperks]

Pushed a follow-up: the "no change" early return I added was also skipping
js::set_device_metrics, not just the JS re-entry it was meant to avoid.

Those metrics are process-global and start at their own 1200x780 default
(crates/js/src/eval_loop.rs) rather than at the engine's 800x600. So an embedder
whose first call names the size the engine already holds never synced them, and every
document it loaded reported 1200x780 for window.innerWidth/innerHeight.

The WebDriver server does exactly that — a session with no requested size is 800×600, so
set_viewport(800, 600, 1.0) on a fresh engine hit the guard. I caught it measuring a
WPT sweep and finding innerWidth was 1200 where the runner had asked for 800:

main                        {"inner":[800,600]}
before this follow-up       {"inner":[1200,780]}
after                       {"inner":[800,600]}

It cost one real test in css-overflow
(scrollable-overflow-fixed-positioned-initial-containing-block.html), which is passing
again now.

The publish now happens before the guard — it's a cheap atomic store that has to reflect
the current viewport either way — and the guard still covers the layout churn and
resize dispatch it was added for. The new test drives it through WebDriver, where the
bug was actually reachable, and asserts both the unchanged and the resized path so the
fix can't degenerate into just dropping the guard.