Adapt and reland old position sticky implementation

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

 /*
  * Copyright (C) 1998, 1999 Torben Weis <weis@kde.org>
  *                     1999 Lars Knoll <knoll@kde.org>
  *                     1999 Antti Koivisto <koivisto@kde.org>
  *                     2000 Dirk Mueller <mueller@kde.org>
  * Copyright (C) 2004, 2005, 2006, 2007, 2008 Apple Inc. All rights reserved.
  *           (C) 2006 Graham Dennis (graham.dennis@gmail.com)
  *           (C) 2006 Alexey Proskuryakov (ap@nypop.com)
  * Copyright (C) 2009 Google Inc. All rights reserved.
  *
@@ skipping 1539 matching lines @@
     layoutView()->clearHitTestCache();
     frame().loader().saveScrollState();
 }
 
 void FrameView::didScrollTimerFired(Timer<FrameView>*)
 {
     if (m_frame->document() && m_frame->document()->layoutView())
         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())
         return;
 
     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.
     if (!m_nestedLayoutCount) {
         updateWidgetPositions();
         if (LayoutView* layoutView = this->layoutView())
             layoutView->layer()->setNeedsCompositingInputsUpdate();
     }
 }
 
@@ skipping 485 matching lines @@
         // Don't scroll the FrameView!
         ASSERT_NOT_REACHED();
     }
 
     m_scrollPosition = newPosition;
 
     if (!scrollbarsSuppressed())
         m_pendingScrollDelta += scrollDelta;
 
     clearScrollAnchor();
-    updateLayersAndCompositingAfterScrollIfNeeded();
+    updateLayersAndCompositingAfterScrollIfNeeded(scrollDelta);
     scrollPositionChanged();
     frame().loader().client()->didChangeScrollOffset();
 }
 
 void FrameView::invalidatePaintForTickmarks()
 {
     if (Scrollbar* scrollbar = verticalScrollbar()) {
         scrollbar->setTrackNeedsRepaint(true);
         setScrollbarNeedsPaintInvalidation(scrollbar);
     }
@@ skipping 1901 matching lines @@
     return m_hiddenForThrottling && m_crossOriginForThrottling;
 }
 
 LayoutBox& FrameView::boxForScrollControlPaintInvalidation() const
 {
     ASSERT(layoutView());
     return *layoutView();
 }
 
 } // namespace blink