tor-browser

commit 6b30f8318890a05dd0849e3355200ecbccbeefc6
parent fd6a1051e6d37464b3d71e66e428801c550c55d0
Author: Ting-Yu Lin <tlin@mozilla.com>
Date:   Thu,  1 Jan 2026 00:19:33 +0000

Bug 2007602 Part 1 - Fix iterating pushed child list in PrepareAbsoluteFrames(). r=layout-reviewers,boris

The old code was wrong to use `GetNextInFlow()` to get the next child in the
loop. It should use `GetNextSibling()`. This patch uses `nsFrameList` iterator,
which hopefully is less error-prone. This fixes a potential bug, but the main
feature is still developing behind bug 1994346, so I didn't try to craft a
testcase.

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

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

1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/layout/generic/AbsoluteContainingBlock.cpp b/layout/generic/AbsoluteContainingBlock.cpp
@@ -137,15 +137,15 @@ bool AbsoluteContainingBlock::PrepareAbsoluteFrames(
   // hasn't reflowed yet. Move any child in that list that is a first-in-flow,
   // or whose prev-in-flow is not in our absolute child list, into our absolute
   // child list.
-  nsIFrame* child = mPushedAbsoluteFrames.FirstChild();
-  while (child) {
-    nsIFrame* next = child->GetNextInFlow();
+  for (auto iter = mPushedAbsoluteFrames.begin();
+       iter != mPushedAbsoluteFrames.end();) {
+    // Advance the iterator first, so it's safe to move |child|.
+    nsIFrame* const child = *iter++;
     if (!child->GetPrevInFlow() ||
         child->GetPrevInFlow()->GetParent() != aDelegatingFrame) {
       mPushedAbsoluteFrames.RemoveFrame(child);
       mAbsoluteFrames.AppendFrame(nullptr, child);
     }
-    child = next;
   }
 
   // TODO (Bug 1994346 or Bug 1997696): Consider stealing absolute frames from