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.
Now when the front requests the list of AnimationPlayers for a node,
all players for this node + the nodes in its subtree are returned.
Also the mutationobserver starts observing all mutations in the node
and its subtree.
When transitions re-start (when a css class is toggled for instance), new AnimationPlayer objects
are created everytime. But now (since bug 1122414) names are given for AnimationPlayers that
correspond to transitions, and so we can use that to know when a transition re-starts on a node
and therefore send the correct events to the animation-panel.
There are still some other references to "source" in AnimationPlayer such as
HasInPlayerSource and UpdateSourceContent. These are renamed in a subsequent
patch (that doesn't require DOM peer review).
Most of this is fairly obvious. However, the addition of 'override' to
ElementPropertyTransition::Name() is not strictly necessary. It was simply added
because while making these changes I accidentally dropped the 'virtual' keyword
from the method in the superclass and the compiler didn't complain. Adding this
will hopefully make it harder to create the same bug in the future.
(Re-land after backout)
The animation-controler was in charge of getting new animation players and refreshing
the UI when done. This is still the case, but it now listens for mutation events from
the actor too, and when they happen, it simply asks the ui to refresh again.
Also, animations with playState "finished" that remain in the animation inspector panel
can now be played again.
Backed out changeset 527c548ff03c (bug 1149711)
Backed out changeset 2fe22ffef154 (bug 1120833)
Backed out changeset 501fa7c170ed (bug 1120833)
CLOSED TREE
The animation-controler was in charge of getting new animation players and refreshing
the UI when done. This is still the case, but it now listens for mutation events from
the actor too, and when they happen, it simply asks the ui to refresh again.
Also, animations with playState "finished" that remain in the animation inspector panel
can now be played again.
This makes the AnimationsActor listen for animation mutations after each
call to getAnimationPlayersForNode on the code that was passed in.
Whenever animations are added or removed, an event is sent to the front
with the list of changes.
The server doesn't know when the client doesn't require updates for the
current node anymore, so it exposes a new method for this.
Note that removed events for finished aniations are skipped, because the
corresponding animations can still be seeked/resumed, so we want the
AnimationPlayerActor to be preserved.
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.
Although pause() is not yet asynchronous, any time we finish calling it the
ready promise should be resolved so we can safely wait on the ready promise
after calling pause already. This way, once pause() becomes async later in this
bug, code relying on this actor will continue to work.
