commit 66d347cb0dba02332c82178c920f97e6c59b99ab
parent 970db2137c0979122d6b0e6f80a8a22fac4e37d2
Author: Timothy Nikkel <tnikkel@gmail.com>
Date: Wed, 26 Nov 2025 13:55:43 +0000
Bug 1988032. Don't async scroll with anchors if there is an active view transition. r=layout-reviewers,emilio
Being inside an active view transition forces a scroll frame to be inactive.
https://searchfox.org/firefox-main/rev/70425199e9a5fa80aa7419fa51763013a67226e1/layout/generic/ScrollContainerFrame.cpp#4349
IsInViewTransitionCapture is set on a stacking context basis. This means that when painting walks from a placeholder frame to its out of flow then IsInViewTransitionCapture follows. But the ASR tree (which we must construct for async scrolling the anchor pos) strictly follows the parent (not the placeholder). So we'd have to do a completely separate walk, and I'm not sure it's worth it. If it turns out to be important we can implement something, or even better just remove that code in DecideScrollableLayer which I'm pretty sure we don't need but I don't want to open that can of worms right now.
Differential Revision: https://phabricator.services.mozilla.com/D273593
Diffstat:
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/layout/generic/nsIFrame.cpp b/layout/generic/nsIFrame.cpp
@@ -4427,7 +4427,12 @@ void nsIFrame::BuildDisplayListForChild(nsDisplayListBuilder* aBuilder,
// what, so don't bother checking for async scrolling with a CSS anchor
// pos anchor.
!aBuilder->IsInViewTransitionCapture() &&
- child->IsAbsolutelyPositioned(disp)) {
+ child->IsAbsolutelyPositioned(disp) &&
+ // If there is an active view transition in this document it is tricky
+ // to determine what will be an active scroll frame outside of that
+ // frame's BuildDisplayList, so don't bother to async scroll with an
+ // anchor in that case. Bug 2001861 tracks removing this check.
+ !PresContext()->Document()->GetActiveViewTransition()) {
scrollsWithAnchor =
AnchorPositioningUtils::GetAnchorThatFrameScrollsWith(child);
}