Bug 194289

Created attachment 361194 [details] wip

The existing code computes fixed position rect based on the last layout scroll position in web process and then tries to make it match the actual layer position by applying offsets in the UI process. This patch gets rid of all that and simply computes the correct fixed position rect entirely in the UI (scrolling tree) side.

Created attachment 361197 [details] test case

Design statement: all data which is input to the scrolling tree should be computed independent from any scroll positions or viewport rects which the scrolling tree itself manipulates. That implies that the scrolling tree should compute layer positions simply using the data in the scrolling tree + the current state of scrolling-tree-owned scroll positions (for the root, frames and overflow) and viewport rects. We'll need to be careful that the "viewport constraints" used for fixed and sticky are "pure" in the sense the they don't encode the current layout and viewport rects. I'm not sure what should happen when a programmatic scroll (when zoomed) affects visual and viewport rects; they need to be update synchronously in the web process for various APIs to work correctly, then I guess the "requested scroll position" is sent to the scrolling tree, and the scrolling thread/UI process basically replicate the same logic and hopefully end up with the same rects?

Things to test while you're working on this (all should test with busy content that is triggering layouts): * fixed in the main frame * fixed in subframes * fixed in overflow scroll (can test the shipping code path with -webkit-overflow-scrolling: touch) * sticky relative to the main frame * sticky relative to overflow scroll (-webkit-overflow-scrolling: touch) * behavior of fixed when zoomed on iOS (layout vs. visual viewports) * behavior of fixed while zooming on iOS (layout/visual viewports) Test everything on macOS too, including with zooming.

<rdar://problem/47836678>

Pulling scroll positions out of layer geometry seems do-able, with a bit of refactoring of RenderLayer::updateLayerPosition(). We'd also need to have RenderLayer::offsetFromAncestor() be able to ignore scroll positions, and plumb some state through all the callers (e.g. clip rect computation) that need scroll-position-independent values, avoiding clip rect caching at the same time. Scroll position also proposes through layout (see offsetFromContainer()), and it seems harder to extract that. It's also very unclear where that feeds into data that can affect compositing and scrolling tree state.

> Scroll position also proposes through layout (see offsetFromContainer()), ^propagates

Moved the patch to https://bugs.webkit.org/show_bug.cgi?id=194433 since this has turned into architecture master bug.

There's another tricky piece to having the scrolling tree inputs be scroll position-independent for layers inside overflow scroll: for a positioned layer whose position is affected by overflow scrolling, that position is a factor of both container scroll position and other CSS positioning. If we were to do as this bug proposes, updating geometry on such layers in a normal compositing update would have to be followed by running the scrolling tree layer positioning logic. So every compositing update would have to be followed by a scrolling tree pass. Maybe not terrible, but some additional complexity. Right now, avoiding jank on such layers is done via the ScrollingLayerPositionAction::Sync stuff, which is also error-prone.

(In reply to Simon Fraser (smfr) from comment #10) > were to do as this bug proposes, updating geometry on such layers in a > normal compositing update would have to be followed by running the scrolling > tree layer positioning logic. So every compositing update would have to be > followed by a scrolling tree pass. Actually you only need to do the scrolling tree pass on each compositing flush (and you have to do that before computing tiling areas which rely on these positions).

(In reply to Simon Fraser (smfr) from comment #11) > Actually you only need to do the scrolling tree pass on each compositing > flush (and you have to do that before computing tiling areas which rely on > these positions). And with UI-side compositing we effectively do this already in RemoteLayerTreeDrawingAreaProxy::commitLayerTree(), by calling m_webPageProxy.scrollingCoordinatorProxy()->viewportChangedViaDelegatedScrolling().

Right. This is more like a recognition (and sharpening) of how things already work rather than a new architectural concept.

Some more detail: The geometry of fixed layers is based on the geometry of layers in the z-order ancestor chain (because the layer tree is unavoidably in z-order, because that's the only way to have CA do the right back-to-front ordering. That means that a fixed layer can be deeply nested in the z-order tree; even though its containing block is trivially the RenderView, we must compute the position for that fixed layer relative to its parent in z-order, which can be some arbitrary layer, even inside of overflow:scroll. That, in turn, means that layout information is baked into FixedPositionViewportConstraints::m_layerPositionAtLastLayout, and we need pass m_viewportRectAtLastLayout in order to compute deltas in the scrolling tree. This means that it's impossible to unbake scroll positions out of inputs to the scrolling tree in anything other than the most trivial cases.

With fixed, there's one thing you could do: tell the scrolling tree the viewport-relative offsets, then, on the scrolling thread/UI process side, do two -[layer convertPoint:toLayer:] to the root, and to the parent layer, and then set the fixed layer positions as the difference. However, that means you're using the CALayer tree as a source of data, so you risk racing with layer flushing (on macOS). Also, that wouldn't work for sticky, where part of the constraints are containing block bounds, which aren't represented in the layer or scrolling trees at present. It would also not work for my up-coming positioned layers, whose containing blocks aren't represented in either tree either.