2001861 - stop setting mWillBuildScrollableLayer = false inside view transition captures

Status: NEW

(Core :: Panning and Zooming, enhancement, P3)

Description

[Timothy Nikkel (:tnikkel)]

For view transitions, async scrolling does not happen inside view transition captures. So in bug 1961140, comment 3 the first thing that was attempted was to null out the ASR of things inside a view transition capture. This caused some apz invariants to fail (bug 1961140, comment 7), the suggested fix was to stop WebRenderCommandBuilder from sending scroll data when it was processing items inside a view transition capture (bug 1961140, comment 8). That caused a problem where if webrender doesn't get scroll data for a scroll frame/spatial node it assumes the scroll frame is scrolled to (0,0) (bug 1961140, comment 10). The fix for that was to not create spatial nodes for these scroll frames so webrender isn't aware of them and not expecting scroll data for them. This corresponds to setting mWillBuildScrollableLayer = false in ScrollContainerFrame::DecideScrollableLayer, which in turn ensures that EnterScrollFrame is not called in ScrollContainerFrame::BuildDisplayList https://searchfox.org/firefox-main/rev/9332b3b092791b0da65d0068b57558d06a196642/layout/generic/ScrollContainerFrame.cpp#4070 which is what creates the spatial nodes. (Note that the patches discussed here all got moved to bug 1965424.)

This is not ideal. It would be nice to be able to easily tell if a scroll frame is active. With this check we need to walk ancestors in a particular way that matches how painting traverses in order to determine if there is a view transition capture containing the scroll frame before knowing the answer. For example in https://phabricator.services.mozilla.com/D273593 we disable async scroll of CSS anchor pos anchored content if a view transition is active.

But I think setting mWillBuildScrollableLayer = false in ScrollContainerFrame::DecideScrollableLayer when inside a view transition capture is not needed. To avoid the bug of webrender assuming scroll frames at scrolled to (0,0) it is sufficient to not create a spatial node for the scroll frame if it's inside a view transition capture, ie to not call EnterScrollFrame for the scroll frame if its inside a view transition capture. And that's exactly what a later view transition patch did in bug 1961140 https://hg-edge.mozilla.org/mozilla-central/rev/c3452ad78518 And this can be confirmed. The patch that set mWillBuildScrollableLayer = false fixed some view transition tests. If you back out the mWillBuildScrollableLayer = false patch then the patch that fixes those tests is the one just mentioned (c3452ad78518) that skips calling EnterScrollFrame when inside a view transition capture.

Comment 1

[Timothy Nikkel (:tnikkel)]

Note that I realized even if we remove setting mWillBuildScrollableLayer = false we still don't create the ASRs in the BuildDisplayList path in that case, which is the behaviour we need to match in the anchor code, so there would still be more work to do for the anchor code.