Correctly reset ScrollAnimator animation state after cancelling animation

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

Index: third_party/WebKit/Source/platform/scroll/ScrollAnimator.cpp
diff --git a/third_party/WebKit/Source/platform/scroll/ScrollAnimator.cpp b/third_party/WebKit/Source/platform/scroll/ScrollAnimator.cpp
index ab02ae1b29876a54f6bf9a60375de1bec3c4b0fc..b0cbc0ddd7dfa573a8861e5d5f217634e5d5a8b7 100644
--- a/third_party/WebKit/Source/platform/scroll/ScrollAnimator.cpp
+++ b/third_party/WebKit/Source/platform/scroll/ScrollAnimator.cpp
@@ -112,6 +112,9 @@ ScrollResult ScrollAnimator::userScroll(
         return ScrollAnimatorBase::userScroll(granularity, delta);
     }
 
+    if (m_runState == RunState::PostAnimationCleanup)
+        resetAnimationState();

[ajuma, 2016/03/29 18:41:57]

What happens to the actual cleanup (specifically, the removal of the main thread
scrolling reason)?

[ymalik, 2016/03/29 19:42:17]

That's a good point (though that's a separate issue from this).

This is the special case when we get a user scroll while we are in the
PostAnimationCleanup state after an animation is cancelled. Note that to remove
the main thread scrolling reason, we need to be in compositing clean.

After the call to willAnimateToOffset below, we will either start a new
animation (or update the current one) or not do anything. If we start a new
animation, we will add main thread scrolling reason anyway, so it's probably
okay to not clear it here. We were not handling the latter, which I think is
fixed if we stay in the PostAnimationCleanup state. Does that make sense?

+
     FloatSize consumedDelta = computeDeltaToConsume(delta);
 
     FloatPoint targetPos = desiredTargetPosition();