From 238c631b0ca3145880a51e9c80ae15972b76df14 Mon Sep 17 00:00:00 2001 From: BREW <81044362+b-re-w@users.noreply.github.com> Date: Tue, 10 Nov 2026 05:45:02 +0900 Subject: [PATCH] Fix: Lay the page area out again whether or not the frame view's layout is recorded Whale records no frame view layout, so Rivet's relayout took the frame change path and the page area stayed where it was after the appbar showed again. The browser view's page area is now laid out first on every path. Co-Authored-By: Claude Opus 5.5 --- rivet/runtime/windows/src/frame.rs | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/rivet/runtime/windows/src/frame.rs b/rivet/runtime/windows/src/frame.rs index e638ddf..722d5d7 100644 --- a/rivet/runtime/windows/src/frame.rs +++ b/rivet/runtime/windows/src/frame.rs @@ -2028,12 +2028,12 @@ unsafe fn sync_strip(window: HWND) { unsafe fn relayout(window: HWND) { // The frame view lays out again on request, which also works for a maximized window. crate::features::vertical_tabs::invalidate_strip(window); + // The frame view lays its client view out again only when the client view's bounds change, + // and a new appbar width can leave them as they were while the page area must move. The + // browser view lays its page area out again here, whether or not the frame view's own layout + // is recorded, as on Brave and Whale the page otherwise waits for the next input. + crate::hooks::page_area::relayout(window); if frame_layout::relayout(window) { - // The frame view lays its client view out again only when the client view's bounds - // change, and a new appbar width can leave them as they were while the page area must - // move. The browser view lays its page area out again here, as on Brave and Whale it - // otherwise waits for the next input. - crate::hooks::page_area::relayout(window); if is_waiting(window) { crate::trace::trace("attach: asked the frame view to lay out again"); }