tor-browser

commit 970db2137c0979122d6b0e6f80a8a22fac4e37d2
parent f24cbbb7a2d1c2fe21276360d3f2aa1eb92c6834
Author: Timothy Nikkel <tnikkel@gmail.com>
Date:   Wed, 26 Nov 2025 13:55:42 +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