Closed Bug 1336544 Opened 5 years ago Closed 2 years ago
Improve the interaction between scroll meta data and active scrolled roots in the gfx
Prefs::Layout Use Containers For Root Frames() case
In gfxPrefs::LayoutUseContainersForRootFrames() mode (currently only used on Android, which is our only platform that supports APZ zooming), APZ requires the root scroll frame's scroll meta data to be on the root container layer. On Desktop, the root container layer is not scrolled. It can contain both fixed and scrolled child layers, and only the scrolled layers have the scroll meta data for the root scroll frame set on them. On Android, the root container layer is scrolled by APZ, and fixed layers inside it are annotated with a fixed position annotation so that APZ can set the inverse async-scroll transform on them to keep them in place. The root container layer is also where we put the scale transform if you zoom using APZ. This scale transform all parts of the page, so having it on the root container layer is appropriate. FrameLayerBuilder sets scroll meta data based on the ASR (active scrolled root) of the item that generated the layer. For the root container layer, on Android we currently have to pretend that the active scrolled root (ASR) of that container display item is the scrolled ASR instead of the root ASR. (The "root ASR" is the unscrolled ASR that's at the root of the ASR tree.) This workaround confuses a few things, especially the mAccumulatedChildBounds assertion which I'm disabling on Android in bug 1336530. Ideally, we'd be able to separate the zoom and scroll annotations in our layer trees, so that we still zoom the root container layer but only scroll the scrolled layers. Then we wouldn't need to fool FrameLayerBuilder into doing what we want. Bug 1123938 is going to affect this as well, but probably in a good way, because it requires some way to differentiate between the scroll offset of scrolled layers in the page and the pan offset of the zoomed container layer. Those offsets need to be stored separately, but are reflected in the same scrollbar. If we go with the plan outlined above ("set zoom metadata on the root container layer and scroll metadata on the scrolled child layers"), then implementing bug 1123938 might be a somewhat straightforward extension to the purpose of the scroll/zoom metadata of the root container layer. This is still rather fuzzy in my head, so I'm not being very specific. I also don't know how having multiple scroll metadata should be reflected in the APZC tree.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.