It's possible that both this_weight and other_weght have calculation errors
which are approximately equal to f64::EPSILON.
MozReview-Commit-ID: 8OddG9rI3qd
--HG--
extra : rebase_source : 9c22d17dcfb8efea7276864502344dc4981c358a
For example, we don't run transform animations on large frames but once
the frame size is small enough we should run transform animations on the frame.
MozReview-Commit-ID: DkfB9g2Gcdi
--HG--
extra : rebase_source : 93a884c3063d4a6c2626e6695583664b24fe11c8
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Previously we used the tweakExpectedRestyleCount function (replaced by the
waitForAnimationReadyToRestyle function in the previous patch) only in cases
where we were actually expecting restyles to happen. For cases where we don't
expect restyles, i.e. cases where we assert the restyle count is zero, we
didn't use this method meaning we didn't bother checking if there was a restyle
expected for the current frame or not.
Since we normally wait for 5 frames anyway before checking that there have been
no restyles, failing to count the number of frames and waiting only 4 frames is
not a problem. However, if a new test were added that just copied this code and
only waited one frame, it might fail to test what it intended. So, to avoid
possible future bugs and in order to be more consistent with tests that do
expect restyles, this patch replaces a number of uses animation.ready with
waitForAnimationReadyToRestyle.
MozReview-Commit-ID: 7qBmobTKolh
--HG--
extra : rebase_source : baa272102fed7a66cc4fc89f6d63ba0333087a2d
And replace tweakExpectedRestyleCount with the function.
MozReview-Commit-ID: 96jC9looyZq
--HG--
extra : rebase_source : 7dae8b258b874a9b366767a6e49de83bf2caccc9
Without this fix layout/reftests/css-animations/ib-split-sibling-opacity.html
would have failed if the next change in this patch series is applied.
MozReview-Commit-ID: CFNXePkXuOs
--HG--
extra : rebase_source : 48df6bf107e1a14dd2b2ae7c23d38d29581aabcb
Apart from whitespace / test description tests this patch also drops an
assertion about the animation playState since it seems unrelated to the purpose
of that particular test.
--HG--
extra : rebase_source : 73be030dd1dc98ae1facd9c2b80dd1b5bcbf04eb
As well as addressing a few FIXMEs this patch drops the checking of start times
since that seems out of scope for this file and is covered elsewhere (I believe
we only added it at first to bootstrap this work).
--HG--
extra : rebase_source : daa067147d6833880deb59b3d270ca122999a64f
This patch updates the tests in this file as follows:
* startTime of a newly created (play-pending) animation is unresolved
-> Covered by 'startTime of a play-pending animation is unresolved'
in wpt/web-animations/interfaces/Animation/startTime.html
However, it would be useful to have a test a new CSS animation is
play-pending so I have extended the test in test_animation-playstate.html
to cover this.
* startTime of a newly created (pause-pending) animation is unresolved
-> Covered by 'startTime of a pause-pending animation is unresolved'
in wpt/web-animations/interfaces/Animation/startTime.html
* startTime is resolved when running
-> Covered by 'startTime is resolved when running'
in wpt/web-animations/interfaces/Animation/startTime.html
* startTime is unresolved when paused
-> Moved to wpt/web-animations/timing-model/animations/pausing-an-animation.html
* startTime while pause-pending and play-pending
-> Moved to wpt/web-animations/timing-model/animations/pausing-an-animation.html
* startTime while play-pending from finished state,
startTime while play-pending from finished state using finish()
-> Merged and moved to wpt/web-animations/timing-model/animations/playing-an-animation.html
* Pausing should make the startTime become null
-> Simplified and merged into the test for 'startTime is unresolved when
paused' / 'Pausing clears the start time' test in
wpt/web-animations/timing-model/animations/pausing-an-animation.html
* Sanity test to check round-tripping assigning to a new animation's startTime
-> Updated and left.
* Skipping forward through animation
-> This is really testing two things:
(a) That you can seek a CSS animation using the start time.
For this it makes sense to have a separate test that also checks that
the computed style is updated (like we have for current time).
(b) That seeking a CSS animation using the start time triggers
dispatching events.
This patch splits the above into two separate tests.
* Skipping backwards through animation,
Redundant change, before -> active, then back,
Redundant change, before -> after, then back,
Redundant change, active -> before, then back,
Redundant change, active -> after, then back,
Redundant change, after -> before, then back,
Redundant change, after -> active, then back
-> All these tests are really just exercising event dispatch which is
already covered by test_event-dispatch.html.
Provided we have a test that checks that events are dispatched when
setting the startTime we don't need to test each combination again since
we have tests for each of these combinations already when using the
currentTime to seek and we can assume UAs are following the same code
path at this point.
As a result this patch drops these tests.
* Setting startTime to null
-> Covered by 'Setting an unresolved start time sets the hold time'
in wpt/web-animations/timing-model/animations/setting-the-start-time-of-an-animation.html
* Animation.startTime after pausing
-> Covered by the new 'Pausing clears the start time' test in
wpt/web-animations/timing-model/animations/pausing-an-animation.html
* Animation.startTime after canceling
-> Merged into
wpt/web-animations/timing-model/animations/canceling-an-animation.html
and made it follow the spec a little more closely (which requires
clearing the start time and hold time).
--HG--
extra : rebase_source : 9bb3d82e18e5c2d9654576502a1d4263a1e46daa
Although many of these tests are similar to tests in the Web Animations
web-platform-tests test suite they focus on the interaction with
animation-play-state and so are probably worth keeping.
There are two exceptions that I felt were worth changing:
* The test for the handling of a ready promise on an aborted pause. I could not
find a similar test in the Web Animations wpt and the test is not really
particular to CSS animations so this patch moves it to Web Animations wpt.
* The test for the resolution value of the ready promise for a paused animation
is covered by the "A pending ready promise should be resolved and not replaced
when the animation is paused" in pausing-an-animation.html in the Web
Animations wpt (although peripherally) and that seems like the better place
for this test anyway (it is not specific to CSS animations) so I have simply
deleted it from this file.
--HG--
extra : rebase_source : b803572692c70fced551d4343ac241068b6f0057
This mostly just involves using promise_rejects to simplify some test code.
The change to the test description of the last test might seem like it is giving
it the opposite meaning but the original test name was "Test finished promise
changes when animationPlayState set to running"[1], and it is about testing
that there are NO changes but that got lost when the "Test" part of the
description was dropped.
[1] https://searchfox.org/mozilla-central/rev/cb846d13d3f9ec5d38ace93a74f749a18e9c67f5/dom/animation/test/css-animations/test_animation-player-finished.html#287
--HG--
extra : rebase_source : e318bd236f522e612a8717c4b7b871b1dd74ed54
These tests are all covered elsewhere:
* The "Test exceptions when finishing infinite animation" test is covered by
the "Finishing an infinite animation throws" test in
finishing-an-animation.html in the Web Animations web-platform-tests.
* The "Test finish() while paused" test is covered by the "Finishing a paused
animation resolves the start time" test in finishing-an-animation.html in
the Web Animations web-platform-tests.
* The "Test finish() while pause-pending with positive playbackRate" test is
covered by the "Finishing a pause-pending animation resolves the pending
task immediately and update the start time" test in
finishing-an-animation.html in the Web Animations web-platform-tests.
* The 'Test finish() while pause-pending with negative playbackRate" test is
covered by the "Finishing a pause-pending animation with negative playback
rate resolves the pending task immediately" test in
finishing-an-animation.html in the Web Animations web-platform-tests.
In fact, it very much looks like these tests were copied to Web Animations'
web-platform-tests at some point without deleting the original.
--HG--
extra : rebase_source : d63b1c3ca7548e7f4f27c607e4671691094ddd86
A number of these tests are redundant with other tests or are otherwise
unnecessary. Other tests should be moved to a more appropriate file.
Some notable examples:
* A number of the tests relate to dispatching events in various phases and have
been moved to test_event-dispatch.html.
* The "Seeking finished -> paused dispatches animationstart" test is covered
by the "After -> Active" test in test_event-dispatch.html (which also
operates on a paused animation).
* The "Animation.currentTime clamping" is really just testing finishing
behavior and is covered by the updating-the-finished-state.html tests in the
Web Animations web-platform-tests (specifically the "Updating the finished
state when playing past end" test).
* Likewise for the "Animation.currentTime clamping for reversed animation"
test.
--HG--
extra : rebase_source : 949ec7e12396fa97c741c7cc90abb3ff64cc7ab7
Some of these names will make more sense after the renaming of files towards the
end of this patch series.
Also a couple of files do not have titles added since they will be subsequently
removed.
--HG--
extra : rebase_source : 6ba046f9c1cc2e062d5aa7f7a49b791ef7ee7e83
We will remove animation.effect.timing in the next patch.
MozReview-Commit-ID: EyeFNM81NbN
--HG--
extra : rebase_source : 9fe5eb0e5d141ffffa017db255328c742a059611
Factoring out this method makes the code a little easier to read, particularly
when in the next patch in this series we add
a TimingParams::MergeOptionalEffectTiming method.
MozReview-Commit-ID: 5AU6IfN2grZ
--HG--
extra : rebase_source : f90614c7dd03413b4ce05d62d3ac73f0ba0e7dc3