[Webkit-unassigned] [Bug 176243] requestAnimationFrame causes bad location of position:fixed inside overflow:auto and iframe

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Nov 1 12:04:07 PDT 2018


https://bugs.webkit.org/show_bug.cgi?id=176243

Ali Juma <ajuma at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ajuma at chromium.org

--- Comment #8 from Ali Juma <ajuma at chromium.org> ---
Trying to debug this a bit, there seems to be an issue with the fixed position's layer's position getting clobbered by a layer tree commit. For example:
1) Scroll in the UI Process
1a) ScrollingTreeFixedNode::updateLayersAfterAncestorChange sets layer position's y coordinate to 107
2) Scroll more in the UI Process
2b) ScrollingTreeFixedNode::updateLayersAfterAncestorChange sets layer position's y coordinate to 115
3) WebProcess flushes layers. The most recent scroll that the WebProcess is aware of is (1), so the GraphicsLayer tree is updated to reflect that state.
4) A new layer tree and scroll tree is committed to the UI Process, and the layer position's y coordinate gets set back to 107

At this point, the fixed position's layer's position is wrong, since it's based on the first scroll rather than the most recent one. It won't get corrected until we scroll again in the UI Process. If we draw to the screen before that, we'll draw the layer at the wrong position.

If I hackily change ScrollingTreeFixedNode::commitStateBeforeChildren to restore the old layer position, the fixed-position layer stays perfectly in place.

It seems like we need something like the logic in ScrollingTreeFixedNode::updateLayersAfterAncestorChange to run whenever we commit a new layer tree and scroll tree, to account for any scrolling that's happened in the UIProcess that the WebProcess wasn't yet aware of when it last updated the layer tree.

It's still not completely clear why rAF makes this bug so much worse though.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20181101/236e9b50/attachment.html>


More information about the webkit-unassigned mailing list