tor-browser

commit 237e8563f6569f547c6c7fe47ce6997726c0d38b
parent 98d14e2dc81960e63ae50bceab379450f0b0c5d9
Author: Timothy Nikkel <tnikkel@gmail.com>
Date:   Wed, 26 Nov 2025 13:04:53 +0000

Bug 1988030. Detect and reject an anchor that is outside of the positioned frame's containing block. r=layout-reviewers,emilio

This should be the case but due to spec issues that we are still getting sorted out in bug 1997026 it does not currently hold with our existing code that accurately implemented an older version of the spec. The anchor pos async scroll code in this bug depends on this condition even if other anchor pos code seems to be okay without it as of now.

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

Diffstat:
M
layout/base/AnchorPositioningUtils.cpp
 | 
9
++++++++-

1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/layout/base/AnchorPositioningUtils.cpp b/layout/base/AnchorPositioningUtils.cpp
@@ -893,8 +893,15 @@ nsIFrame* AnchorPositioningUtils::GetAnchorThatFrameScrollsWith(
   }
 
   const nsAtom* defaultAnchorName = pos->mPositionAnchor.AsIdent().AsAtom();
-  return const_cast<nsIFrame*>(
+  nsIFrame* anchor = const_cast<nsIFrame*>(
       aFrame->PresShell()->GetAnchorPosAnchor(defaultAnchorName, aFrame));
+  // TODO Bug 1997026 We need to update the anchor finding code so this can't
+  // happen. For now we just detect it and reject it.
+  if (anchor && !nsLayoutUtils::IsProperAncestorFrameConsideringContinuations(
+                    aFrame->GetParent(), anchor)) {
+    return nullptr;
+  }
+  return anchor;
 }
 
 }  // namespace mozilla