Use ScrollAnchor in FrameView and PaintLayerScrollableArea.

third_party/WebKit/Source/core/layout/ScrollAnchor.cpp

 // Copyright 2015 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "core/layout/ScrollAnchor.h"
 
+#include "core/layout/LayoutObject.h"
 #include "platform/scroll/ScrollableArea.h"
 #include "wtf/Assertions.h"
 
 namespace blink {
 
 ScrollAnchor::ScrollAnchor(ScrollableArea* scroller)
     : m_scroller(scroller)
     , m_anchorObject(nullptr)
 {
     ASSERT(m_scroller);
@@ skipping 11 matching lines @@
 }
 
 static DoublePoint computeRelativeOffset(const ScrollableArea* scroller, const LayoutObject* layoutObject)
 {
     // TODO(skobes): implement.
     return DoublePoint();
 }
 
 void ScrollAnchor::save()
 {
-    if (!m_anchorObject)
+    if (!m_anchorObject) {
         m_anchorObject = findAnchor(m_scroller);
-
-    if (m_anchorObject)
-        m_savedRelativeOffset = computeRelativeOffset(m_scroller, m_anchorObject);
+        if (!m_anchorObject)
+            return;
+        m_anchorObject->setIsScrollAnchorObject();
+    }
+    m_savedRelativeOffset = computeRelativeOffset(m_scroller, m_anchorObject);

[ojan, 2016/02/05 11:01:52]

I think this could be inside the if clause above as well? Any time something
changes that could affect this offset, we have to clear the anchorObject
anyways. So, with that, you could just have an if (m_anchorObject) early return.

[skobes, 2016/02/05 17:52:31]

In theory, yes, but that seems brittle to me.  Suppose something changes that
affects this offset, but we fail to clear the anchor.  If save() always
recalculates the relative offset, we will just anchor to a poorly-chosen node. 
But if we cache the offset we may *create* a visible jump where there wouldn't
have been one, which is much worse.

[ojan, 2016/02/06 00:09:27]

I can't think of any scenario in which it would make sense to keep the anchor
but not the offset. If we had such a thing, it would represent a real bug that
we need to fix anyways, so this extra defensiveness would just mask the bug.
computeRelativeOffset will be doing real work on each layout. It's not the end
of the world, but it's one of a thousand cuts that isn't serving a purpose.

 }
 
 void ScrollAnchor::restore()
 {
     if (!m_anchorObject)
         return;
 
     DoubleSize adjustment = computeRelativeOffset(m_scroller, m_anchorObject) - m_savedRelativeOffset;
     if (!adjustment.isZero())
         m_scroller->setScrollPosition(m_scroller->scrollPositionDouble() + adjustment, AnchoringScroll);
 }
 
+void ScrollAnchor::clear()
+{
+    LayoutObject* anchorObject = m_anchorObject;
+    m_anchorObject = nullptr;
+
+    if (anchorObject)
+        anchorObject->maybeClearIsScrollAnchorObject();
+}
+
 } // namespace blink