These patches update these tests as follows:
* Used async/await where it simplifies the tests
* Updated the test descriptions to reflect what they are testing in the timing
model
* Fixed a couple of bugs where we set the playbackRate on a pause-pending
animation (which causes it to no longer be pause-pending).
In the process I noticed a couple of tests that don't really belong here. They
will be moved in the next patch.
MozReview-Commit-ID: C33o7qLNMMd
These tests are not testing the interface so much as the 'finish an animation'
procedure.
This patch simply moves the tests as-is. They will be simplified in the next
patch in this series.
MozReview-Commit-ID: 5nloB5GtxHv
I didn't like the way these tests were written so I decided to rewrite them to
make it more clear what they are trying to test.
MozReview-Commit-ID: IBqMUh24crS
The test under web-animations/interfaces/Animation/playbackRate.html is really
testing the timing model so this patch moves it there. We'll simplify it in the
next patch.
MozReview-Commit-ID: HbhjlVtQLQA
Using async/await makes these tests easier to read and appears to be supported
in all browsers now. This patch updates the tests in
web-animations/timing-model/animations since we will update these tests later in
this patch series and it will be easier if we convert them to using async first.
MozReview-Commit-ID: 70QKlkXTHW
In this folder we have a mixture of tests named after the procedure they are
testing or the section that contains the procedure. The latter seems to be more
common and makes it a little easier to check that all sections are tested so
this patch renames files to refer to the section titles instead. It also updates
a few of the test file titles and URLs.
MozReview-Commit-ID: 2udhvAKP5VR
These patches update these tests as follows:
* Used async/await where it simplifies the tests
* Updated the test descriptions to reflect what they are testing in the timing
model
* Fixed a couple of bugs where we set the playbackRate on a pause-pending
animation (which causes it to no longer be pause-pending).
In the process I noticed a couple of tests that don't really belong here. They
will be moved in the next patch.
MozReview-Commit-ID: C33o7qLNMMd
These tests are not testing the interface so much as the 'finish an animation'
procedure.
This patch simply moves the tests as-is. They will be simplified in the next
patch in this series.
MozReview-Commit-ID: 5nloB5GtxHv
I didn't like the way these tests were written so I decided to rewrite them to
make it more clear what they are trying to test.
MozReview-Commit-ID: IBqMUh24crS
The test under web-animations/interfaces/Animation/playbackRate.html is really
testing the timing model so this patch moves it there. We'll simplify it in the
next patch.
MozReview-Commit-ID: HbhjlVtQLQA
Using async/await makes these tests easier to read and appears to be supported
in all browsers now. This patch updates the tests in
web-animations/timing-model/animations since we will update these tests later in
this patch series and it will be easier if we convert them to using async first.
MozReview-Commit-ID: 70QKlkXTHW
In this folder we have a mixture of tests named after the procedure they are
testing or the section that contains the procedure. The latter seems to be more
common and makes it a little easier to check that all sections are tested so
this patch renames files to refer to the section titles instead. It also updates
a few of the test file titles and URLs.
MozReview-Commit-ID: 2udhvAKP5VR
This assertion is supposed to be used where the first argument has a tolerance
but the second argument doesn't have such tolerance. Whereas
assert_times_equal() is supposed to be used for the case both arguments have
the same tolerance, actually it hasn't, it will be fixed in a subsequent patch
in this patch series.
MozReview-Commit-ID: FEDHilbX2rm
Note that we don't need tests for the cancel events of CSS Animations or CSS
Transitions since we already have them in
dom/animation/test/css-{animations|transitions}/file_event-dispatch.html
(See the tests named "Call Animation.cancel after cancelling
transition/animation".)
MozReview-Commit-ID: GRtSxEvMkjz
Hopefully most of these changes are self-explanatory however a few notes follow.
* In timing-model/animations/play-states.html, as well as making the tests match
the updated spec, one or two tests have also been moved to better reflect the
order in the spec (to make it obvious which branch of the algorithm is being
tested).
* In timing-model/animations/set-the-timeline-of-an-animation.html we previously
had two tests that check:
a) That the playState was 'pending' before and after setting the timeline.
b) That the playState was 'pending' before setting the timeline and then,
after setting the timeline and waiting on the ready promise, would become
'running'.
Likewise we had the same test for pausing.
Since these are basically the same test--(b) just adds the wait on the ready
promise--we combine them here into one test that covers both (a) and (b).
MozReview-Commit-ID: CLoDJvsdwmF
Currently we have a test in interfaces/Animation/playState.html that somewhat
randomly tests the result of the `playState` member.
However, there's no complex logic associated with the `playState` member in the
IDL. It simply returns "The play state of this animation". The logic we need to
test is in the definition of 'play state' which is in the timing model.
As a result we move this test to timing-model/animations/play-states.html
However, this test as it stands does not test the calculation of the play state
in a particularly thorough manner. For example, it does not contain a single
test for the 'finished' state.
Given that this patch series will change the definition of the 'play state' we
first fix this test to cover each of the different cases in the definition of
the 'play state' prior to these changes. That is, we update the tests based on
the definition of 'play state' here:
https://www.w3.org/TR/2016/WD-web-animations-1-20160913/#play-states
(Note that at this point in the patch series the pref to turn on the changed
definition behavior has not been enabled even for tests so this patch is
actually testing the behavior when that pref is false. We'll replace much of
this test in the next patch but by updating the test first, we should be able to
more clearly see the changes in the next patch.)
MozReview-Commit-ID: 1xkOmuY1SxD
This patch does not attempt to be exhaustive but fixes a few instances where to
are obvious benefits to using template literals.
MozReview-Commit-ID: A7iRY2oOOfV
Because 'const' is longer than 'var', in quite a number of places this patch
also updates the indentation of subsequent lines.
Also, in a number of cases this means the line now needs to be wrapped. In
general I've used 'prettier' to do the line wrapping which means that the line
wrapping style differs a little from the existing code (which is already quite
inconsistent). Hopefully in the future we can use prettier on all files to make
this more consistent.
Also, in some cases, to avoid further line wrapping, this patch uses shorthand
property names (specifically replacing 'composite: composite' with just
'composite'). This appears to be supported in all browsers like to implement Web
Animations (Firefox 33+, Chrome 47+, Edge, Safari 9+).
MozReview-Commit-ID: 2xEaeZSYjlc
It's not necessary to say "tests" or "tests for" in the title of these tests.
It's obvious from the context that these are test files.
This patch:
* Remove "Tests for" and "tests" from the titles
* Makes the titles match the spec sections they test more closely where
practical
* Makes the titles more consistent in general (e.g. not putting () after method
names)
* Updates a few spec links
* Drops a few author annotations since we decided to no longer use them
There are still some inconsistencies:
- The naming of the setTarget.html test file
- The location of the effect-value-visibility.html file
- The getComputedStyle.html test
- etc.
These will be fixed in subsequent patches in this series.
Now that some of these tests have been moved to the timing-model directory, it
makes less sense to refer to the actual API being tested. Intead they should
refer to the concept in the model being tested.
MozReview-Commit-ID: 7Y65o0IilSq
I replaced a couple instances of 'var' with 'const' or 'let' but otherwise the
test content is untouched. I will update a few test descriptions in the next
patch.
MozReview-Commit-ID: ASVp54dzQUL
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
