I also ran into this while testing  issue 616995 .

From debugging, it seems like the duration of the animation is set correctly, but when ElementAnimations::TickAnimations is called, animations_[i]->TrimTimeToCurrentIteration(monotonic_time) returns the final duration (causing the instant scroll to the target position) and the animation is eventually deleted.

Initially I thought that we were busy doing other stuff and skipped a bunch of frames, but the stack trace reveals that's not the case.

I tested using the following test page, where scrolling down the main page one mouse wheel tick at a time ultimately repros this issue (https://output.jsbin.com/wohixed/quiet).

I have attached a trace where the first scroll is smooth and the second is instant.

@loyso do you know what could be going on?

Deleted: trace_smooth_then_instant.json.gz 6.0 MB

trace_smooth_then_instant.json.gz 6.0 MB Download

Try stepping through the computation of TrimTimeToCurrentIteration to see why it's returning the final duration. Is the start time set incorrectly?

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

commit 04da03ce765e60b6081ed755b834b9e7e555a64f
Author: ymalik <ymalik@chromium.org>
Date: Thu Aug 18 18:38:16 2016

Fix smooth scroll animation flake on janky pages

Some background:
In each frame, we have AnimateLayers and after we draw we do UpdateState. A call to
AnimateState ticks an animation and UpdateState adds a new animation to be ticked
in subsequent frames.

This CL fixes the following two cases:
1) An animation can get added at an unusual point. This can happen when
GestureScrollUpdate gets delivered after we AnimateLayers but before draw and
a call to UpdateState. In this case, the animation gets started with a stale start time
(last_tick_time_) and a call to AnimateState will jump and "finish" the animation. To
prevent this, we reset last_tick_time_ when element_animations becomes inactive.

2) An animation gets updated while it hasn't started and is in the
WAITING_FOR_TARGET_AVAILABILITY state. This happens when you do two simultaneous
mouse wheel ticks on a janky page. See inline comment for more details.

BUG= 622553 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Review-Url: https://codereview.chromium.org/2251933002
Cr-Commit-Position: refs/heads/master@{#412898}

[modify] https://crrev.com/04da03ce765e60b6081ed755b834b9e7e555a64f/cc/animation/element_animations.cc
[modify] https://crrev.com/04da03ce765e60b6081ed755b834b9e7e555a64f/cc/animation/element_animations_unittest.cc
[modify] https://crrev.com/04da03ce765e60b6081ed755b834b9e7e555a64f/cc/animation/scroll_offset_animations_impl.cc
[modify] https://crrev.com/04da03ce765e60b6081ed755b834b9e7e555a64f/cc/test/animation_test_common.cc
[modify] https://crrev.com/04da03ce765e60b6081ed755b834b9e7e555a64f/cc/test/animation_test_common.h
[modify] https://crrev.com/04da03ce765e60b6081ed755b834b9e7e555a64f/cc/trees/layer_tree_host_impl_unittest.cc