Fix sticky constraints and update sticky layer positions recursively after scroll.

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 f881a6042a874b94b9ee6295408a6c25b0d0dcb8..90e2cf0a4c6d17d3c787b7df3e58e79eb2cb8d06 100644
--- a/third_party/WebKit/Source/core/frame/FrameView.cpp
+++ b/third_party/WebKit/Source/core/frame/FrameView.cpp
@@ -1609,12 +1609,11 @@ void FrameView::updateLayersAndCompositingAfterScrollIfNeeded()
     if (!hasViewportConstrainedObjects())
         return;
 
-    // Update sticky position objects which are stuck to the viewport.
+    // Mark sticky position objects which are stuck to the viewport for positioned movement.
     for (const auto& viewportConstrainedObject : *m_viewportConstrainedObjects) {
         LayoutObject* layoutObject = viewportConstrainedObject;
-        PaintLayer* layer = toLayoutBoxModelObject(layoutObject)->layer();
         if (layoutObject->style()->position() == StickyPosition)
-            layer->updateLayerPosition();
+            layoutObject->setNeedsPositionedMovementLayout();

[chrishtr, 2016/05/31 20:19:53]

What about sticky objects that are not stuck to the viewport?

[flackr, 2016/05/31 20:38:52]

This is already handled by PaintLayerScrollableArea::setScrollOffset calling
updateLayerPositionsAfterOverflowScroll which is used for overflow scrollers.
It's probably best to be consistent with that so I'll use this update method. It
updates the layer positions recursively as needed though does require the same
compositing assert disabler used there:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...

Should I add a second test for an overflow scroller?

     }
 
     // If there fixed position elements, scrolling may cause compositing layers to change.