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

[bugzilla-daemon at webkit.org]

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

Ali Juma <ajuma at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|webkit-unassigned at lists.web |ajuma at chromium.org
                   |kit.org                     |

--- Comment #10 from Ali Juma <ajuma at chromium.org> ---
(In reply to Ali Juma from comment #8)
>
> 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 turns out we *do* have logic for this, but it's broken for scrollers that are descendants of iframes.

Specifically, RemoteLayerTreeDrawingAreaProxy::commitLayerTree checks if there are any fixed or sticky nodes, and if so, it calls viewportChangedViaDelegatedScrolling() to update the positions of fixed and sticky layers. This calls ScrollingTreeFrameScrollingNodeIOS::updateLayersAfterViewportChange on the main frame scroll node, which in turn calls updateLayersAfterAncestorChange on the subframe's scroll node.

And this is where things go wrong -- ScrollingTreeFrameScrollingNode::updateLayersAfterAncestorChange has an empty implementation with a FIXME, and ScrollingTreeFrameScrollingNodeIOS doesn't override this either. So we never recurse into the subframe's scroll nodes.

Implementing ScrollingTreeFrameScrollingNodeIOS::updateLayersAfterAncestorChange fixes the bug. I'll put together a patch.

Any suggestions for how to write a test for this?

-- 
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/20181102/5c628df9/attachment.html>