We only store relevant animations on the timeline. Relevant animations are
any animations that are running or yet to run ("current animations") or
which have finished but are still applying a fill mode ("in effect animations").
AnimationTimeline.getAnimations() only ever returns relevant animations so
this is the minimum set we need to keep track of. Keeping track of any more
than this would prevent us from garbage-collecting any no longer relevant
animations since we keep a strong reference to this animations.
The reason we keep a strong reference is that if an animation is attached to
a timeline, even if there are no references to it from script or markup it
needs to be kept alive in order to dispatch events or resolve promises. An
irrelevant animation however is not going to do either of these things without
outside intervention so we don't need to keep it alive.
This is in anticipation of adding Animation::SetTimeline(). Once we set the
timeline out of band, there's a chance that getting it could return null so
this patch makes the WebIDL and method name reflect that.
The connection between an Animation and an AnimationTimeline is optional. That
is, it is possible to have an Animation without an AnimationTimeline. Until now
we have often just assumed the timeline will be set but eventually we need to
support the possibility of the timeline being null. Indeed, later in this patch
series we will set the timeline out-of-band (i.e. not in the constructor) using
SetTimeline which opens up the possibility that timeline will be null for
a period of time.
This patch paves the way for having an optional timeline by storing the global
used for, e.g. creating promises, on the Animation object itself.
This is not strictly necessary yet but we will want to implement methods
like GetAnimations() on the base class, AnimationTimeline, so we may as well do
that now rather than adding that code to DocumentTimeline and moving it later.
Earlier in this patch series we added an assertion to the destructor for
CSSAnimation and CSSTransition to check that the owning element has been
cleared when the animation is destroyed.
This assertion fails, however, for transitions because there are a two
code paths where a transition may be destroyed without being cancelled.
This patch adjusts those two code paths to ensure transitions are always
cancelled before being destroyed.
Having created composite ordering methods for the different kinds of animations
this patch adds a Comparator class so that they can be used to sort an
array of such animations.
This patch uses this Comparator object to sort the results returned by
Element.getAnimations. For this case, the order in which we create animations
and transitions happens to almost perfectly correspond with the composite
ordering defined so that no sorting is necessary.
One exception is that some -moz-* transitions may be created after transitions
that they should sort before when sorting by transition property. In this
case the sorting added in this patch should ensure they are returned in the
correct sequence.
Unfortunately, we can't easily test this since the test files we have are
intended to be cross-browser (where -moz-* properties won't be supported).
Once we implement AnimationTimeline.getAnimations (bug 1150810) we'll have
a better opportunity to test this sorting. For now, the added tests in this
patch just serve as a regression test that the sorting hasn't upset the
already correct order (and an interop test in future once we move them to
web-platform-tests).
