Adapt and reland old position sticky implementation

third_party/WebKit/Source/core/layout/LayoutBox.h

Index: third_party/WebKit/Source/core/layout/LayoutBox.h
diff --git a/third_party/WebKit/Source/core/layout/LayoutBox.h b/third_party/WebKit/Source/core/layout/LayoutBox.h
index 0f1f6553aed304a30d1286f42e05e937590400b2..f0718b9ba88c18f21147a69cd83f8f0c97e46d5e 100644
--- a/third_party/WebKit/Source/core/layout/LayoutBox.h
+++ b/third_party/WebKit/Source/core/layout/LayoutBox.h
@@ -1013,6 +1013,7 @@ private:
         // Should check this object for paint invalidation.
         if (!needsLayout())
             setMayNeedPaintInvalidation();
+        invalidateScrollAncestorConstraints();

[chrishtr, 2016/03/09 16:53:08]

Is this where you handle the case of an element with the same scroller as a
position-sticky element that may affect
the sticky constraints for that scroller?

Does the CL have a test for this scenario?

[flackr, 2016/03/14 19:04:26]

Yes.
It does now :-) - sticky-container-moved.html

[chrishtr, 2016/03/16 21:52:39]

Hmm. I'm trying to think of whether it is possible to not change the frame rect
but still screw things up. What if a transform is
changed on an element between the scroller and the sticky element?

How about instead always invalidating the sticky constraints for any containing
scroller whenever style or layout of any element changes? That should be
complete.

[flackr, 2016/03/22 21:44:32]

I'm fairly certain that transforms shouldn't be included in the sticky
constraints. Trying to include transforms would require also supporting
animations of transforms.

     }
 
     // Returns true if the box intersects the viewport visible to the user.