Should record the reason of not-compositing non-paintsContent fixed position layer so that ScrollingCoordinator won't treat the layer as a fast-scrolling blocker.
Created attachment 194946 [details] Patch
Thanks Xianzhu, I think this looks great.
Simon, could you please review the patch? Thanks.
Comment on attachment 194946 [details] Patch R=me, this looks great. See if you can get Simon to take a look as well before landing.
I think bug 110430 covers the same issue.
Comment on attachment 194946 [details] Patch Assuming no objection from Simon :)
Comment on attachment 194946 [details] Patch Where is NotCompositedForNoVisibleContent actually consulted? I would expect to see a test for it in FrameView::scrollContentsFastPath(), but do not.
Comment on attachment 194946 [details] Patch Clearing flags on attachment: 194946 Committed r146940: <http://trac.webkit.org/changeset/146940>
All reviewed patches have been landed. Closing bug.
Please respond to my comment.
(In reply to comment #7) > (From update of attachment 194946 [details]) > Where is NotCompositedForNoVisibleContent actually consulted? I would expect to see a test for it in FrameView::scrollContentsFastPath(), but do not. In ScrollingCoordinator::hasVisibleSlowRepaintViewportConstrainedObjects(), there is an existing test that any viewport constrained object not composited with explicit reasons (layer->viewportConstrainedNotCompositedReason() != RenderLayer::NoNotCompositedReason) won't cause main-thread scrolling. Seems that we need the same test in FrameView::scrollContentsFastPath().
(In reply to comment #11) > (In reply to comment #7) > > (From update of attachment 194946 [details] [details]) > > Where is NotCompositedForNoVisibleContent actually consulted? I would expect to see a test for it in FrameView::scrollContentsFastPath(), but do not. > > In ScrollingCoordinator::hasVisibleSlowRepaintViewportConstrainedObjects(), there is an existing test that any viewport constrained object not composited with explicit reasons (layer->viewportConstrainedNotCompositedReason() != RenderLayer::NoNotCompositedReason) won't cause main-thread scrolling. > > Seems that we need the same test in FrameView::scrollContentsFastPath(). This seems what bug 110430 covers. This bug covers the main-thread scrolling issue caused by no-content fixed element. I should have used "main-thread scrolling" instead of ambiguous "slow-scrolling"/"fast-scrolling". Will work on bug 110430 for the remaining issue in FrameView::scrollContentsFastPath().