This implements the following change to the Web Animations specification:
19b6c33cee
The background to that change is described in the corresponding spec issue:
https://github.com/w3c/web-animations/issues/201
MozReview-Commit-ID: GGA64LG5vT
This is in preparation for further changes to these files later in this patch
series.
In particular this patch:
* Moves some code to more modern Javascript that should be easier to read and
maintain
* Makes the tests more strict about when active/after values are specified
- If the timing parameters mean there is no active phase, the test should not
specify a value to test for that phase. If there *is* an active phase, the
test must provide a value to test (if it does not the test will fails when
it compares against the undefined value).
- Likewise for the after phase
This should make it a little easier to incorporate testing the playbackRate.
MozReview-Commit-ID: 17vihK5RSbu
The spec[1] says:
Silently set the animation playback rate of animation to -animation playback
rate.
This must be done silently or else we may end up resolving the current
ready promise when we do the compensatory seek despite the fact that we are
most likely not exiting the pending play state.
This patch add tests that we don't exit the pending play state when calling
reverse() or resolve the ready promise.
[1] https://w3c.github.io/web-animations/#reverse-an-animation
MozReview-Commit-ID: 1X42O5yKpk9
We already pass this test but it seemed like a useful test to add since I was
unsure if the early return we have in Animation::Reverse() is valid or not.
MozReview-Commit-ID: J38Euno3VP6
We are gradually line the tests up better with sections in the spec. Given that
these tests are concerned with testing the "reverse an animation" procedure in
the spec (and not the API per se) they should be moved to an appropriate
subdirectory of timing-model.
We also update the test titles to make it clear that these tests are really
covering the timing model, not the API.
MozReview-Commit-ID: J5gc3HZg9qv
(Once we remove the special clamping behvaior later in this patch series, the
added test here will fail if we don't add special handling for the case
when the progress is zero and we are in the delay phase.)
MozReview-Commit-ID: Dnon2soE1Se
We only use this once to test the timing function when applied to a keyframe.
Now that we have tests for this in
animation-model/keyframe-effects/effect-value-transformed-distance.html
we can drop the check here and simplify these tests considerably.
Also, 'progress' is always set so we can drop the check for an undefined value.
MozReview-Commit-ID: 39ajHZBRWBf
This seems like a Gecko-specific test and even then it's not clear why we
expect the result could be different in this case.
MozReview-Commit-ID: Ix8jZLobwcA
This set of tests are really just testing that we apply the timing function to
the animation effect so they belong in the appropriate part of the timing model
tests (and should check getComputedTiming not getComputedStyle).
I've also started to update tests to ES6 where appropriate since it seems
arrow functions, template literals, etc. are all supported on all UAs that
are implementing or likely to implement Web Animations.
MozReview-Commit-ID: 3kXao0Xi0BA
This test overlaps somewhat with the tests in
web-animations/timing-model/animation-effects/simple-iteration-progress.html.
However, these tests are more specific to just covering the phase calculation
algorithm. Ultimately the tests in simple-iteration-progress.html should be
broken down into separate tests for the different algorithms being tested.
There is also some redundancy in these tests. For example, instead of writing:
.forEach(function(test) {
assert_phase_at_time(animation, test.phase, test.currentTime);
});
we could just define an assert_phases_at_times function that takes the array of
test cases and iterates over them. However, I think writing the test like this
makes it easier to read since it requires less imagination about what
assert_phases_at_times might be doing.
One concern is that this test requires the setter for AnimationEffectTiming.fill
to be implemented. We could rewrite this to create a new animation with the
appropriate fill mode each time but I think this is probably ok.
MozReview-Commit-ID: 82uvBB8bizI
This test overlaps somewhat with the tests in
web-animations/timing-model/animation-effects/simple-iteration-progress.html.
However, these tests are more specific to just covering the phase calculation
algorithm. Ultimately the tests in simple-iteration-progress.html should be
broken down into separate tests for the different algorithms being tested.
There is also some redundancy in these tests. For example, instead of writing:
.forEach(function(test) {
assert_phase_at_time(animation, test.phase, test.currentTime);
});
we could just define an assert_phases_at_times function that takes the array of
test cases and iterates over them. However, I think writing the test like this
makes it easier to read since it requires less imagination about what
assert_phases_at_times might be doing.
One concern is that this test requires the setter for AnimationEffectTiming.fill
to be implemented. We could rewrite this to create a new animation with the
appropriate fill mode each time but I think this is probably ok.
MozReview-Commit-ID: 82uvBB8bizI
