Adapt and reland old position sticky implementation

third_party/WebKit/Source/core/frame/FrameView.cpp

Index: third_party/WebKit/Source/core/frame/FrameView.cpp
diff --git a/third_party/WebKit/Source/core/frame/FrameView.cpp b/third_party/WebKit/Source/core/frame/FrameView.cpp
index 143a285cec09eff55cdb35f7bca6233e0eb36fbd..4d38918be209225f784b542ad52e48c5508a8bee 100644
--- a/third_party/WebKit/Source/core/frame/FrameView.cpp
+++ b/third_party/WebKit/Source/core/frame/FrameView.cpp
@@ -1557,7 +1557,7 @@ void FrameView::didScrollTimerFired(Timer<FrameView>*)
         m_frame->document()->fetcher()->updateAllImageResourcePriorities();
 }
 
-void FrameView::updateLayersAndCompositingAfterScrollIfNeeded()
+void FrameView::updateLayersAndCompositingAfterScrollIfNeeded(const DoubleSize& scrollDelta)
 {
     // Nothing to do after scrolling if there are no fixed position elements.
     if (!hasViewportConstrainedObjects())
@@ -1565,6 +1565,14 @@ void FrameView::updateLayersAndCompositingAfterScrollIfNeeded()
 
     RefPtrWillBeRawPtr<FrameView> protect(this);
 
+    // Update sticky position objects which are stuck to the viewport.
+    for (const auto& viewportConstrainedObject : *m_viewportConstrainedObjects) {
+        LayoutObject* layoutObject = viewportConstrainedObject;
+        PaintLayer* layer = toLayoutBoxModelObject(layoutObject)->layer();
+        if (layoutObject->style()->position() == StickyPosition)
+            layer->updateLayerPositionAfterFrameScroll(scrollDelta);

[chrishtr, 2015/12/09 00:37:38]

So on a scroll, first the positions of the sticky elements will be updated, then
they will invalidate paint for themselves?
Does the invalidation happen in scrollContentsFastPath (for the root)?

I'm trying to understand in particular how this will work correctly with
position-sticky elements
on top of a composited scroller.

[chrishtr, 2015/12/09 19:12:21]

I think PaintLayerScrollableArea, line 384, needs to remove the
layer()->isRootLayer() condition, since sticky elements may not be composited
even if they are within a composited scroller.

[flackr, 2015/12/10 23:43:14]

All of these cases do seem to be working, but I need to instrument and figure
out how these paths work to be able to explain why. I will get back to you on
this.

[flackr, 2015/12/10 23:43:15]

Actually, sticky elements which have an ancestor scroller (e.g. not the
FrameView) are not even in the viewportConstrainedObjects.

+    }
+
     // If there fixed position elements, scrolling may cause compositing layers to change.
     // Update widget and layer positions after scrolling, but only if we're not inside of
     // layout.
@@ -2070,7 +2078,7 @@ void FrameView::scrollTo(const DoublePoint& newPosition)
         m_pendingScrollDelta += scrollDelta;
 
     clearScrollAnchor();
-    updateLayersAndCompositingAfterScrollIfNeeded();
+    updateLayersAndCompositingAfterScrollIfNeeded(scrollDelta);
     scrollPositionChanged();
     frame().loader().client()->didChangeScrollOffset();
 }