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).
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).
We define KeyframeEffectReadonly in KeyframeEffect.cpp since Web Animations also
defines KeyframeEffect and when we come to implement that I expect we'll define
it in the same class, maybe even using the same object.
This patch also adds a few missing includes in places where
KeyframeEffectReadonly is used so that we're not just cargo-culting it in.
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.
This is a bit awkward. We lazily set mName to the transition property and then
return it. The reasons for this approach are:
* We don't really want to eagerly fill in mName for all transitions since in
99% of cases we'll never use it and this will lead to wasted allocations.
* The signature of Name() returns a const nsString reference. This is because
Name() is used when building CSS Animations (to compare different copies of
the same animation when updating). For that case we don't really want to
generate unnecessary copies of nsString objects so we return a reference.
However, that means for transitions as well we need to return a reference so
we can't just generate a temporary string on-demand.
As a result we also have to const-cast ourselves so we can update the mName
member. We could make mName mutable but seeing as it's only set once, the
const_cast seems more appropriate.
This patch (finally) puts pausing animations in the pending player map so that
they are resolved asynchronously.
Since this changes the pausing behavior this patch updates a number of tests so
that they continue to pass.
A number of animation tests assume that pausing happens instantaneously. This
patch adjust many of those tests so that they will continue to work when
pausing happens asynchronously. In many cases this is possible because we
know the ready promise on AnimationPlayer (soon to be Animation) objects will
be resolved so we can wait on it and it will resolve immediately now, but when
asynchronous pausing is introduced the test the promise won't resolve until
after the pause operation is complete.
There are some tests that can't be so easily adjusted and we will have to fix
these at the same time as we turn on async pausing. However, taking care of
this set of tests now should reduce the size of subsequent patches in this
series.
Now that we have separate tests for checking the initial state of startTime we
can remove these checks from tests for setting the startTime.
Also, while we're at it, we needn't check the playState and animationPlayState
since these should be covered by other tests.
AnimationPlayer.ready will currently always be resolved but by updating these
tests to wait on it anyway they should continue to work once we introduce the
delayed animation start behavior.
Since bug 1104433, step_func now passes on the return value of its callback.
That means we can use it directly as a Promise callback function in Promise
chains where the return value of the function is another Promise.
This patch updates existing tests to eliminate the awkward handling we had
around wrapping some parts of Promise callbacks in step() but leaving the return
statement outside it.
This patch moves commonly used addDiv and waitForFrame test methods to
a separate testcommon.js support file.
It also takes advantage of the updates to testharness.js from bug 1104433 to
rework addDiv such that it automatically removes the created div at the end of
the test.
