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

commit e04864cab7755bdc01abf0431cfd825d488b309c
Author: smcgruer <smcgruer@chromium.org>
Date: Mon Jan 30 21:38:42 2017

Detect/report animations that are cancelled after they start.

Previously, we were early-exiting from |animationPlayStateChange| if an
animation was contained in |m_idToAnimation|. However, this means that
we miss cancel events for animations that have already been started,
since the 'start' event causes them to be placed in |m_idToAnimation|.

BUG= 686091 

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

[add] https://crrev.com/e04864cab7755bdc01abf0431cfd825d488b309c/third_party/WebKit/LayoutTests/inspector-protocol/animation/animation-start-cancel-expected.txt
[add] https://crrev.com/e04864cab7755bdc01abf0431cfd825d488b309c/third_party/WebKit/LayoutTests/inspector-protocol/animation/animation-start-cancel.html
[modify] https://crrev.com/e04864cab7755bdc01abf0431cfd825d488b309c/third_party/WebKit/Source/core/inspector/InspectorAnimationAgent.cpp

Marking release block stable because blocked  issue 672457  is also release block stable, so we'll have to merge this one too.

Is this applicable to All OSes or any specific OS?

All; apologies for forgetting to mark the checkbox :)

Your change meets the bar and is auto-approved for M57. Please go ahead and merge the CL to branch 2987 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Merged with https://chromium.googlesource.com/chromium/src/+/aa03ce605a2a545a99a70a2f5cbd3ce8171d1b90

Please merge your change to M57 branch 2987 ASAP (latest before 5:00 PM PT today, Wednesday) so we can pick it up for M57 Beta promotion release this week. Thank you.

Per comment #12, this is already merged to M57.

smcgruer@ Could you please let us know is there any manual repro steps available to verify this issue from Chrome-TE end.

Thanks!

brajkumar@ I'm not sure if there are any manual steps to verify this, it was discovered via a layout test issue.

suzyh@ Do you know if there should be anything Chrome-TE could test? I'm actually surprised to find that if I load up http://output.jsbin.com/gecagud in canary and do animation tracing, the trace still shows that the animation took 10s whilst the actual visual is as expected (near instant cancellation). But perhaps that isn't directly linked to the InspectorAnimationAgent code that was fixed here.

+samli for more DevTools-experienced input

smcgruer: Could we just create a layout-test-style page that logs to console instead of using InspectorTest, and use that to manually verify? I'm not sure what the procedures are for Chrome-TE and what kind of test we need to provide.

I suspect the example in #16 is WAI. The timeline just shows the declarative properties of the animation, showing procedural changes to the animation (in this case cancelling) in its timeline seems like it would be out of scope for the tool to me.

Alternate example to illustrate:
var animation = target.animate({opacity: [0, 1]}, 10000);
setTimeout(() => animation.cancel(), 1000);
The animation would play for 1s but the timeline would capture it as having 10s duration.

Yep, Alan is correct. Visually representing an animation's actual state is extremely complex.
 - the same timeline for an animation is reused for multiple runs of the same animation
 - imagine representing a something which pauses, then stops, then pauses...
 - its designed to simulate a composer's view. Think of something like a video editor. Playback is different to definition.

Alrighty, in that case then there's really nothing for Chrome-TE to verify here. The verification was the layout test itself.

Thanks for the input all.