tor-browser

commit ed73d3bdf8597830aa5109b5438d538e54fc9652
parent d9ac0270640ebc21dc6d78848ba564804aa3d56e
Author: David Shin <dshin@mozilla.com>
Date:   Tue, 21 Oct 2025 19:50:54 +0000

Bug 1995284: When finishing abspos reflow, distinguish running out of fallbacks vs. not having any.  r=layout-anchor-positioning-reviewers,layout-reviewers,emilio,jwatt

No behavioural change currently, but distinguishing the two scenarios is
necessary to know to determine if we commit to the new scroll offset vs.
Roll back to what we started with.

Differential Revision: https://phabricator.services.mozilla.com/D269218

Diffstat:
M
layout/generic/AbsoluteContainingBlock.cpp
 | 
10
+++++++---

1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/layout/generic/AbsoluteContainingBlock.cpp b/layout/generic/AbsoluteContainingBlock.cpp
@@ -1191,9 +1191,13 @@ void AbsoluteContainingBlock::ReflowAbsoluteFrame(
 
     aKidFrame->DidReflow(aPresContext, &kidReflowInput);
 
-    if (usedCb.Contains(aKidFrame->GetRect()) && aStatus.IsComplete()) {
-      // We don't overflow our CB, no further fallback needed.
-      isOverflowingCB = false;
+    const bool fits =
+        aStatus.IsComplete() && usedCb.Contains(aKidFrame->GetRect());
+    if (fallbacks.IsEmpty() || fits) {
+      // We completed the reflow - Either we had a fallback that fit, or we
+      // didn't have any to try in the first place.
+      // TODO(dshin, bug 1987963): Hypothetical scroll will be committed here.
+      isOverflowingCB = !fits;
       break;
     }