This is the first step towards the animation-inspector UI v3 (bug 1153271).
The new UI is still hidden behind a pref, and this change doesn't implement
everything that is in the current v2 UI.
This introduces a new Timeline graph to represent all currently animated nodes
below the currently selected node.
v2 used to show them as independent player widgets. With this patch, we now show
them as synchronized time blocks on a common time scale.
Each animation has a preview of the animated node in the left sidebar, and a time
block on the right, the width of which represents its duration. The animation name
is also displayed.
There's also a time graduations header and background that gives the user information
about how long do the animations last.
This change does *not* provide a way to know what's the currentTime nor a way to
set it yet.
This also makes the existing animationinspector tests that still make sense with
the new timeline-based UI run with the new UI pref on.
The failing test was rewinding a player and expecting it to pause at 0.
But rewing first pauses (async) and then sets the time (async), and the test
was only waiting for the player to pause.
With this change, we now also wait until the time is the expected one.
This changes a few animationinspector tests by making them wait until the expected animation
state is reached rather than just waiting for the next animation auto-refresh update, which
might, in some cases, not be enough.
This is a re-landing of bug 1134500 and bug 1149711.
Backed out changeset 527c548ff03c (bug 1149711)
Backed out changeset 2fe22ffef154 (bug 1120833)
Backed out changeset 501fa7c170ed (bug 1120833)
CLOSED TREE
On particularly slow test environments, it might not be enough to wait for the next
AnimationPlayerActor state update.
I introduced a helper function that makes it possible for tests to wait for state
updates until the animation state reaches the expected value. In most cases, we use
it to wait until an animation reaches a given playState (paused, running, finished).
The AnimationPlayerFront needs to emit events when its auto-refresh
mode is enabled, whenever the state changes. Until now, it was doing
so with EventEmitter.
But because decorating the class with EventEmitter adds on/once/off
functions to the instance, it ends up hiding the on/once/off functions
that were already there because the class extends addon sdk EventTarget.
Instead of waiting for the next auto-refresh event only (which could be a
response to an older request, therefore not having the expected state yet),
wait until the state changes to what we expect in the test.
This means that if the play/pause button doesn't work anymore, then the test
will timeout, but at least it won't intermittently fail as it was doing until
now.
