[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