[Webkit-unassigned] [Bug 178508] Consider non-main frames for AsyncScrollingCoordinator::frameViewRootLayerDidChange

[bugzilla-daemon at webkit.org]

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

--- Comment #1 from Frédéric Wang (:fredw) <fred.wang at free.fr> ---
I just debugged it now with a simple test case. The iframe node is first created with nonzero parentID via:

ScrollingStateTree::attachNode
AsyncScrollingCoordinator::attachToStateTree
RenderLayerCompositor::attachScrollingNode
RenderLayerCompositor::updateScrollCoordinationForThisFrame
RenderLayerCompositor::updateScrollCoordinatedLayer

After that, attachNode is called again with a wrong parentID == 0 value via:

ScrollingStateTree::attachNode
AsyncScrollingCoordinator::attachToStateTree
AsyncScrollingCoordinator::ensureRootStateNodeForFrameView
AsyncScrollingCoordinator::frameViewRootLayerDidChange
RenderLayerCompositor::updateBacking

It turns out that nodeTypeAndParentMatch always returns true when parentID == 0 so at the end attachToStateTree just returns the existing node id for the iframe and does not modify the state tree.

If the second stack trace was done before the scrolling node for the iframe is created, then ScrollingStateTree::attachNode would incorrectly set it as the new root. Also, if for some reason the iframe node was re-parented before that call, the state tree would not be updated. I'm not sure such bugs happen, but in any case, it is wrong for ensureRootStateNodeForFrameView to pass parentID = 0 for non-main frames.

-- 
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/20171020/4707976b/attachment.html>