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
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
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
By doing this we will have all the KeyframeEffect* related code in
KeyframeEffectReadOnly.{h,cpp} so we can rename them to KeyframeEffect.{h,cpp}
in the next patch and make it easier to examine the history for the bulk of this
code.
The added [HeaderFile] annotation will be removed in a subsequent patch in this
series.
MozReview-Commit-ID: Fxk6fPukgAS
--HG--
extra : rebase_source : 0bb0f846aba69e2b79724adb3148948317667eae
This might seem a bit odd but later in this patch series we will rename
KeyframeEffectReadOnly to KeyframeEffect.
MozReview-Commit-ID: H9b8brtA36W
--HG--
extra : rebase_source : 9e34d583c087733b3fa05d99a67def55653c4556
It might seem a bit odd to move the setters to the read-only class that we are
ultimately planning to drop but the reason for doing this is that
KeyframeEffectReadOnly.cpp has a *lot* more code than KeyframeEffect.cpp.
In order to simplify code archaeology we take the following approach:
1. Move code from KeyframeEffect.{h,cpp} to KeyframeEffectReadOnly.{h,cpp}.
2. Delete KeyframeEffect.{h,cpp}.
3. Rename KeyframeEffectReadOnly.{h,cpp} to KeyframeEffect.{h,cpp}.
Note that at least steps 2 and 3 must be performed in separate patches as
mercurial does not successfully track renames when the target name already
exists.
MozReview-Commit-ID: LwJoxGJitKR
--HG--
extra : rebase_source : ae437c6e74435b983c7390df301055472fa3c4ff
In pseudo element cases mTarget->mElement is the parent element of the pseudo,
thus we inefficiently use the parent frame and walked through parent
continuations.
MozReview-Commit-ID: DsNRXaM346D
--HG--
extra : rebase_source : e62eeff02897ca08e800c1d807f81a0d4cf38dd1
In FindAnimationsForCompositor(), we can ensure
EffectCompositor::GetAnimationElementAndPseudoForFrame doesn't return nullptr
since EffectSet::GetEffectSet(const nsIFrame*) at the top of
FindAnimationsForCompositor() also uses GetAnimationElementAndPseudoForFrame.
MozReview-Commit-ID: CtWdUt40Zyx
--HG--
extra : rebase_source : 7ea1058f4fb740ca35c2ebdc8d2f69d7b634a257
For table element nsDisplayTransform's mFrame is the primary frame not style
frame.
MozReview-Commit-ID: 9BMSpuGE7lC
--HG--
extra : rebase_source : 19edd8978165cfa3904dcabea3e382e9b7c16ee3
GetAnimationFrame is bit ambiguous, the name should match what we call it.
MozReview-Commit-ID: GuyhVrUFgiW
--HG--
extra : rebase_source : 1120e34aa3fdd20cf26552fda01d1a473e3ffff0
In bug 1237454, we introduced a new change hint that is produced when
visibility property is changed from 'visible' to 'hidden' or from 'hidden'
to 'visible'. Animations producing this new change hint can be throttled
if the animation element is out-of-view, but can not be throttled in the case
where the element is in-view. In the bug, a test case for a visibility change
animation on out-of-view element was added, but no test for in-view case was
added.
MozReview-Commit-ID: BhiRm13rfRr
--HG--
extra : rebase_source : 264954ff349d5a9c5a00b940b2eaf2045f0952ae
The test added in this patch fails without the corresponding code changes
(specifically the second gGetComputedTimingTests test fails the comparison of
the 'easing' member).
MozReview-Commit-ID: 9eyXruVrPuN
--HG--
extra : rebase_source : 927f55c0670bf770e03d38eb876202efbb700c1e