Tie scroll anchoring adjustments to frame lifecycle instead of layout.

third_party/WebKit/Source/platform/scroll/ScrollableArea.cpp

Index: third_party/WebKit/Source/platform/scroll/ScrollableArea.cpp
diff --git a/third_party/WebKit/Source/platform/scroll/ScrollableArea.cpp b/third_party/WebKit/Source/platform/scroll/ScrollableArea.cpp
index b991948fc11d2ae8bbdbd734b007b4528396ef94..d99e8acc414705fc9abeb604683c870ed260bd75 100644
--- a/third_party/WebKit/Source/platform/scroll/ScrollableArea.cpp
+++ b/third_party/WebKit/Source/platform/scroll/ScrollableArea.cpp
@@ -184,6 +184,7 @@ void ScrollableArea::setScrollOffset(const ScrollOffset& offset,
 
   switch (scrollType) {
     case CompositorScroll:
+    case ClampingScroll:

[szager1, 2016/10/13 17:54:49]

I would have thought this would be treated like a ProgrammaticScroll, no?

[skobes, 2016/10/13 18:00:31]

Generally it is.  The important difference is that we don't clear the scroll
anchor.

We also can't use programmaticScrollHelper here because
ProgrammaticScrollAnimator will pass ProgrammaticScroll to scrollOffsetChanged.

[szager1, 2016/10/13 18:50:56]

This code path doesn't call cancelScrollAnimation(), is that intended?

[bokan, 2016/10/13 18:53:59]

Perhaps programmaticScrollHelper should take a scrollType? When I added it there
was just user and programmatic scrolls.

[skobes, 2016/10/13 18:55:19]

Basically, yes.  I assumed that clamping cancelling animation was an unintended
side effect of reusing the ProgrammaticScroll value.  I can't think of a
scenario where it is important for clamping to cancel animation.

[szager1, 2016/10/13 19:00:39]

I haven't thought too deeply about this, but my instinct is that whenever a
discontinuous scroll happens (including programmatic and clamping scrolls), we
should cancel animation.  Scroll anchoring could be a legitimate exception to
that, though.

       scrollOffsetChanged(clampedOffset, scrollType);
       break;
     case AnchoringScroll: