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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Oct 19 02:16:22 PDT 2017


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

            Bug ID: 178508
           Summary: Consider non-main frames for
                    AsyncScrollingCoordinator::frameViewRootLayerDidChange
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Frames
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: fred.wang at free.fr
                CC: simon.fraser at apple.com
            Blocks: 176914

AsyncScrollingCoordinator::frameViewRootLayerDidChange seems to assume that frameView is always a main-frame:

* It calls ensureRootStateNodeForFrameView, which always attaches a frame node with parentID = 0.
* It has an ASSERT to check m_scrollingStateTree->rootStateNode(), instead m_scrollingStateTree->stateNodeForID(frameView.scrollLayerID()).

It seems that the only place where AsyncScrollingCoordinator::frameViewRootLayerDidChange can be called with a non-main frame is RenderLayerCompositor::updateBacking.

I guess we should either ASSERT that frameView is a main frame, or update the function to consider non-main frames. In the latter case, I guess we should re-use the work of RenderLayerCompositor::scrollCoordinatedAncestorInParentOfFrame to calculate the parentID.

I'm making this blocking bug 176914, just because for non-main frames we might also need to calculate a childIndex or similar if we want to ensure z-index ordering.

@Simon: WDYT?


Referenced Bugs:

https://bugs.webkit.org/show_bug.cgi?id=176914
[Bug 176914] Async iframes in the scrolling tree should be in the z-index order
-- 
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/20171019/d5473a78/attachment.html>


More information about the webkit-unassigned mailing list