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.
--HG--
rename : dom/animation/Animation.cpp => dom/animation/KeyframeEffect.cpp
rename : dom/animation/Animation.h => dom/animation/KeyframeEffect.h
rename : dom/animation/test/css-animations/test_animation-name.html => dom/animation/test/css-animations/test_effect-name.html
rename : dom/animation/test/css-animations/test_animation-target.html => dom/animation/test/css-animations/test_effect-target.html
rename : dom/animation/test/css-transitions/test_animation-name.html => dom/animation/test/css-transitions/test_effect-name.html
rename : dom/animation/test/css-transitions/test_animation-target.html => dom/animation/test/css-transitions/test_effect-target.html
rename : dom/webidl/Animation.webidl => dom/webidl/KeyframeEffect.webidl
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.
--HG--
rename : dom/animation/test/css-animations/test_animation-effect-name.html => dom/animation/test/css-animations/test_animation-name.html
rename : dom/animation/test/css-transitions/test_animation-effect-name.html => dom/animation/test/css-transitions/test_animation-name.html
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.
The tests in dom/animation/tests/ use an old version of idlharness.js that
doesn't support inherited interfaces. As discussed in bug 1152619 we're not
looking at updating these old tests (under dom/imptests) at the moment which
means we won't be able to update the IDL tests in dom/animation/tests/ to
continue passing once we introduce DocumentTimeline as a subinterface of
AnimationTimeline.
As a result, this patch simply the removes the IDL tests for this interface from
dom/animation/tests. However, we have a test for this interface in
web-platform-tests where I've set up a pull request to apply the required
renaming so we should eventually get test coverage for this renaming.
https://github.com/w3c/web-platform-tests/pull/1748
In the long run, all the tests in dom/animation/tests should end up in
web-platform-tests. The main reason they aren't there yet is that most of them
test the mapping between the Web Animations API and CSS and there's currently no
spec defining that so there's no place to put them in the web-platform-tests
repository.
There are a few tests for animation timeline which could be landed in
web-platform-tests (and then removed from dom/animation/tests) but we need to
discuss with Google if this is the desired behavior or not first. For the time
being I have a branch setup for that and I'm leaving the tests in
dom/animation/tests so we continue to test what *we* think the behavior should
be in the meantime. That branch is here:
https://github.com/birtles/web-platform-tests/compare/rename-animation-timeline...birtles:add-hidden-iframe-tests
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.
