1411318 - Assertion failure: (!animation.originTime().IsNull() && animation.startTime().type() == MaybeTimeDuration::TTimeDuration) || animation.isNotPlaying() (If we are playing, we should have an origin time and a start time), at /builds/worker/workspace/build/sr

Status: RESOLVED FIXED

(Core :: DOM: Animation, defect, P3)

Description

[Jason Kratzer [:jkratzer]]

Attachment: trigger.html

Testcase found while fuzzing mozilla-central rev a80d568a417e.

Comment 1

[Jason Kratzer [:jkratzer]]

Attachment: log_minidump.txt

Comment 2

[Jason Kratzer [:jkratzer]]

Attachment: log_stderr.txt

Comment 3

[Ryan VanderMeulen [:RyanVM]]

INFO: Last good revision: dca52e4ed76197ec3e3629e659020c3d5c8d81bb
INFO: First bad revision: 095c3fdfc66234228388ba5c0ebaf3d35f2a9868
INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=dca52e4ed76197ec3e3629e659020c3d5c8d81bb&tochange=095c3fdfc66234228388ba5c0ebaf3d35f2a9868

Comment 4

[Brian Birtles (:birtles, Feb 26~ parental leave)]

This appears to be just a mismatch between the condition we use for setting the origin time (has a timeline with a resolved current time) and the condition we use for determining if we are playing or not (has a timeline or not).

In this specific case, we end up with an animation with a timeline but where the timeline returns null from ToTimeStamp. Presumably because either there is no navigation timing object or because its navigationstart timestamp is null. That's not surprising given its the DocumentTimeline associated with this document:

  (new DOMParser).parseFromString('', 'text/html');

So I think we probably just want to fix that mismatch, perhaps by marking animations without an originTime as "not playing" when we send them to the compositor.

Comment 5

[Brian Birtles (:birtles, Feb 26~ parental leave)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=9d55b362235733c81904fe20deaa2baa9339797e

Comment 6

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Attachment: Bug 1411318 - Don't consider an animation playing if its timeline is inactive;

When we receive animations on the compositor, we assert that either they're not
playing, or they have a resolved start and origin time.

However, on the main thread we determine if an animation is playing by checking
if it has a timeline, if it's in the correct state, and if it has a non-zero
playback rate.

The problem with this check is that if an animation has a timeline but it is
inactive, that is, its current time is null, we will not be able to get
a resolved origin time -- yet we will still report that is is playing.

This patch fixes this mismatch by treating animations with an inactive timeline
as "not playing".

The IsPlaying() method is used a number of call sites but it appears that they
all would expect an animation with an inactive timeline to be considered "not
playing". Furthermore, this makes IsPlaying() consistent with the check we do
for an active timeline in other functions such as Animation::Tick(),
TriggerNow(), SilentlySetCurrentTime(), UpdateFinishedState(),
and IsPossibleOrphanedPendingAnimation().

Review commit: https://reviewboard.mozilla.org/r/193214/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/193214/

Comment 7

[Hiroyuki Ikezoe (:hiro)]

Comment on attachment 8922181 [details]
Bug 1411318 - Don't consider an animation playing if its timeline is inactive;

https://reviewboard.mozilla.org/r/193214/#review198412

Comment 8

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Thanks for the quick review!

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2d7eb64ec7d0
Don't consider an animation playing if its timeline is inactive; r=hiro

Comment 10

[Hiroyuki Ikezoe (:hiro)]

(In reply to Brian Birtles (:birtles) from comment #8)
> Thanks for the quick review!

I did look at the patch in the try. :)

Comment 11

[Attila Craciun [:arny]]

https://hg.mozilla.org/mozilla-central/rev/2d7eb64ec7d0

Comment 12

[Intermittent Failures Robot]

1 failures in 912 pushes (0.001 failures/push) were associated with this bug in the last 7 days.    

Repository breakdown:
* mozilla-inbound: 1

Platform breakdown:
* linux64-stylo-disabled: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1411318&startday=2017-10-23&endday=2017-10-29&tree=all