Able to reproduce this on Windows-7, Linux Ubuntu 14.04 on 51.0.2693.2. Worked fine on Mac OS 10.11.3.

Good Build: 50.0.2645.0 dev
Bad Build: 50.0.2646.0 dev

CHANGELOG URL:
 https://chromium.googlesource.com/chromium/src/+log/81c4571248f30446f95901a76a5059929b467434..5a8740b5ac0c7cd4e9dc5eb0cea2b89db1899140

Suspecting https://codereview.chromium.org/1678713002 from changelog

@ymalik: Please help in re-assigning if it is not related to your change.

Not sure if it's related to that particular CL yet, but it's definitely related to smooth scrolling (not reproducible with it turned off).

Looking into it now.

Looks like Google Images modifies the scroll offset from javascript every time there is a keyboard scroll. When we get a continuous keyboard scroll, ScrollAnimator updates the target position of the original animation curve with the delta of a new keyboard scroll, but doesn't take into account the amount scrolled by javascript.

In any case, javascript scroll should cancel the ongoing user scroll, but we weren't handling the cleanup correctly in ScrollAnimator. Will upload a patch for review shortly.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d7b5be44530835f2b1f3c3cfc8d6d7ea18a50553

commit d7b5be44530835f2b1f3c3cfc8d6d7ea18a50553
Author: ymalik <ymalik@chromium.org>
Date: Tue Mar 29 23:02:54 2016

Correctly reset ScrollAnimator animation state after cancelling animation

We were calling willAnimaterToOffset with the updated target position before
clearing the animation state when in PostAnimationCleanup. As a result, we
didn't take into account the potentially modified scroll offset by a
programmatic scroll.

BUG= 598548 

Review URL: https://codereview.chromium.org/1842623003

Cr-Commit-Position: refs/heads/master@{#383854}

[modify] https://crrev.com/d7b5be44530835f2b1f3c3cfc8d6d7ea18a50553/third_party/WebKit/Source/platform/scroll/ScrollAnimator.cpp
[modify] https://crrev.com/d7b5be44530835f2b1f3c3cfc8d6d7ea18a50553/third_party/WebKit/Source/platform/scroll/ScrollAnimatorCompositorCoordinator.h
[modify] https://crrev.com/d7b5be44530835f2b1f3c3cfc8d6d7ea18a50553/third_party/WebKit/Source/platform/scroll/ScrollAnimatorTest.cpp

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d7b5be44530835f2b1f3c3cfc8d6d7ea18a50553

commit d7b5be44530835f2b1f3c3cfc8d6d7ea18a50553
Author: ymalik <ymalik@chromium.org>
Date: Tue Mar 29 23:02:54 2016

Correctly reset ScrollAnimator animation state after cancelling animation

We were calling willAnimaterToOffset with the updated target position before
clearing the animation state when in PostAnimationCleanup. As a result, we
didn't take into account the potentially modified scroll offset by a
programmatic scroll.

BUG= 598548 

Review URL: https://codereview.chromium.org/1842623003

Cr-Commit-Position: refs/heads/master@{#383854}

[modify] https://crrev.com/d7b5be44530835f2b1f3c3cfc8d6d7ea18a50553/third_party/WebKit/Source/platform/scroll/ScrollAnimator.cpp
[modify] https://crrev.com/d7b5be44530835f2b1f3c3cfc8d6d7ea18a50553/third_party/WebKit/Source/platform/scroll/ScrollAnimatorCompositorCoordinator.h
[modify] https://crrev.com/d7b5be44530835f2b1f3c3cfc8d6d7ea18a50553/third_party/WebKit/Source/platform/scroll/ScrollAnimatorTest.cpp

@ajha, I tested locally, but can you also verify that the issue has been fixed?

Actually this is still not fixed for all cases. More specifically, if we schedule the animation on the compositor from MT, we still have this issue.

Working on a fix.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d115573365c24d26fc93fe9b9d0976d93725e91d

commit d115573365c24d26fc93fe9b9d0976d93725e91d
Author: ymalik <ymalik@chromium.org>
Date: Fri Apr 01 22:51:44 2016

Restore handling of new scroll when waiting to cancel current scroll on cc

https://crrev.com/1678713002 caused this regression. This CL restores the
old handling of a new user scroll when in state WaitingToCancelOnCompositor.

The current behavior is pretty broken when we are in WaitingToCancelAnimation
and a new user scroll arrives. willAnimateToOffset updates the target offset and
goes into WaitingToSendToCompositor. Consequently, ::updateCompositorAnimation
doesn't abort the previous animation and starts a new one with the updated
target and the two animations compete for scroll offsets.

With this CL, when we are in WaitingToCancelAnimation and a new user scroll
arrives, we do nothing and let ::updateCompositorAnimation cancel the running
animation. As subsequent user scrolls arrive, we will now just start a new
animation with the updated target (and the bug is that we will ignore the first
user scroll when in WaitingToCancelAnimation).

The remaining bug is less serious because in general this is a special case when
we are cancelling in the middle of a user scroll and then starting another
scroll right away. This happens in cases where a site listens for the scroll and
updates the scroll offset (programmatic scroll cancels user scroll), and the
user continues to scroll. FWIW, this is the current behavior in M49, and no real
issues have been reported around it.  crbug.com/599876  tracks the correct
handling for this case.

BUG= 598548 

Review URL: https://codereview.chromium.org/1852753002

Cr-Commit-Position: refs/heads/master@{#384714}

[modify] https://crrev.com/d115573365c24d26fc93fe9b9d0976d93725e91d/third_party/WebKit/Source/platform/scroll/ScrollAnimator.cpp
[modify] https://crrev.com/d115573365c24d26fc93fe9b9d0976d93725e91d/third_party/WebKit/Source/platform/scroll/ScrollAnimatorCompositorCoordinator.h
[modify] https://crrev.com/d115573365c24d26fc93fe9b9d0976d93725e91d/third_party/WebKit/Source/platform/scroll/ScrollAnimatorTest.cpp

Checked the issue on 51.0.2699.0 dev,Ubuntu 14.04 and is working fine. i.e; Able to scroll on continuous use up/down key from keyboard

Your change meets the bar and is auto-approved for M50 (branch: 2661)

Please merge your change to M50 branch 2661 by 5:00 PM PST today, 04/04/16 so we can take it for this week beta. Thank you.

M50 Stable is launching very soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged ASAP. All changes MUST be merged into the release branch by 5pm on Apr-8 to make into the desktop Stable final build cut. Thanks!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/54cfe8ed557f0cd75b031cf1049c661fff28baa2

commit 54cfe8ed557f0cd75b031cf1049c661fff28baa2
Author: Yash Malik <ymalik@google.com>
Date: Mon Apr 04 21:35:15 2016

Correctly reset ScrollAnimator animation state after cancelling animation

We were calling willAnimaterToOffset with the updated target position before
clearing the animation state when in PostAnimationCleanup. As a result, we
didn't take into account the potentially modified scroll offset by a
programmatic scroll.

BUG= 598548 

Review URL: https://codereview.chromium.org/1842623003

(cherry picked from commit d7b5be44530835f2b1f3c3cfc8d6d7ea18a50553)

Cr-Original-Commit-Position: refs/heads/master@{#383854}
Cr-Commit-Position: refs/branch-heads/2661@{#481}
Cr-Branched-From: ef6f6ae5e4c96622286b563658d5cd62a6cf1197-refs/heads/master@{#378081}

[modify] https://crrev.com/54cfe8ed557f0cd75b031cf1049c661fff28baa2/third_party/WebKit/Source/platform/scroll/ScrollAnimator.cpp
[modify] https://crrev.com/54cfe8ed557f0cd75b031cf1049c661fff28baa2/third_party/WebKit/Source/platform/scroll/ScrollAnimatorCompositorCoordinator.h
[modify] https://crrev.com/54cfe8ed557f0cd75b031cf1049c661fff28baa2/third_party/WebKit/Source/platform/scroll/ScrollAnimatorTest.cpp

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c0b6caeb9fc2aa138649231d719f8c4139623f70

commit c0b6caeb9fc2aa138649231d719f8c4139623f70
Author: Yash Malik <ymalik@google.com>
Date: Mon Apr 04 21:48:11 2016

Restore handling of new scroll when waiting to cancel current scroll on cc

https://crrev.com/1678713002 caused this regression. This CL restores the
old handling of a new user scroll when in state WaitingToCancelOnCompositor.

The current behavior is pretty broken when we are in WaitingToCancelAnimation
and a new user scroll arrives. willAnimateToOffset updates the target offset and
goes into WaitingToSendToCompositor. Consequently, ::updateCompositorAnimation
doesn't abort the previous animation and starts a new one with the updated
target and the two animations compete for scroll offsets.

With this CL, when we are in WaitingToCancelAnimation and a new user scroll
arrives, we do nothing and let ::updateCompositorAnimation cancel the running
animation. As subsequent user scrolls arrive, we will now just start a new
animation with the updated target (and the bug is that we will ignore the first
user scroll when in WaitingToCancelAnimation).

The remaining bug is less serious because in general this is a special case when
we are cancelling in the middle of a user scroll and then starting another
scroll right away. This happens in cases where a site listens for the scroll and
updates the scroll offset (programmatic scroll cancels user scroll), and the
user continues to scroll. FWIW, this is the current behavior in M49, and no real
issues have been reported around it.  crbug.com/599876  tracks the correct
handling for this case.

BUG= 598548 

Review URL: https://codereview.chromium.org/1852753002

(cherry picked from commit d115573365c24d26fc93fe9b9d0976d93725e91d)

Cr-Original-Commit-Position: refs/heads/master@{#384714}
Cr-Commit-Position: refs/branch-heads/2661@{#482}
Cr-Branched-From: ef6f6ae5e4c96622286b563658d5cd62a6cf1197-refs/heads/master@{#378081}

[modify] https://crrev.com/c0b6caeb9fc2aa138649231d719f8c4139623f70/third_party/WebKit/Source/platform/scroll/ScrollAnimator.cpp
[modify] https://crrev.com/c0b6caeb9fc2aa138649231d719f8c4139623f70/third_party/WebKit/Source/platform/scroll/ScrollAnimatorCompositorCoordinator.h
[modify] https://crrev.com/c0b6caeb9fc2aa138649231d719f8c4139623f70/third_party/WebKit/Source/platform/scroll/ScrollAnimatorTest.cpp

Merged into M50.

Tested the issue on Windows 7, Ubuntu 14.04 using 50.0.2661.66.Observed that scrolling is smooth on using down/up arrow key from keyboard.
Please find attached screencast.

Marking it as TE-Verified.

Deleted: 598548.mp4 10.9 MB

598548.mp4 10.9 MB Download