We manually implement ComputeSquaredDistance for Translate, Rotate, and
Scale because we have to handle mismatch cases, and actually we don't
need to implement it for specified types.
Depends on D11934
Differential Revision: https://phabricator.services.mozilla.com/D11935
--HG--
extra : moz-landing-system : lando
It's worth to serialize the timing function from web animation api with
servo, too. However, we need an FFI to do that, so this patch also add a
new FFI.
Depends on D10443
Differential Revision: https://phabricator.services.mozilla.com/D10444
--HG--
extra : moz-landing-system : lando
For now, we keep supporting the prefixed version, since there are examples/instructions
on the Web that don't include an unprefixed value.
Differential Revision: https://phabricator.services.mozilla.com/D10451
--HG--
extra : moz-landing-system : lando
For some content both transitions and animations are triggered simultaneously.
As a result of bug 1301305, if the set of animations includes animations that
affect geometry, then we ensure that any transform animations are run on the
main thread, rather than on the compositor.
However, we have observed some content where this synchronizing is not necessary
and produces unnecessary jank. In the particular cases we have observed,
the transitions and animations do not need to be synchronized so this patch
refines the approach from bug 1301305 to only synchronize within the set of CSS
transitions or the set of non-transition animations.
Differential Revision: https://phabricator.services.mozilla.com/D10328
--HG--
extra : moz-landing-system : lando
This matches the spec, https://drafts.csswg.org/css-values/#angles, which says:
> All <angle> units are compatible, and deg is their canonical unit.
And https://drafts.csswg.org/css-values/#compat, which says:
>When serializing computed values [...], compatible units [...] are converted into a single canonical unit.
And also other implementations (Blink always serializes angles as degrees in
computed style for example).
Also allows us to get rid of quite a bit of code, and makes computed angle value
representation just a number, which is nice.
Differential Revision: https://phabricator.services.mozilla.com/D8619
--HG--
extra : moz-landing-system : lando
When a compositor animation finishes that doesn't apply a fill, rather than
jumping back to the underlying value immediately we should apply a fill mode
until the main thread has a chance to remove the animation from the compositor.
This ensures that any main thread effects that are intended to synchronize with
the end of the animation have a chance to run before we show the underlying
style and helps to avoid flicker in such cases.
Currently we apply this synthesized fill mode to animations when they run
forwards (i.e. positive playback rate), but not backwards. This patch makes us
apply the same handling when running in reverse.
Differential Revision: https://phabricator.services.mozilla.com/D7259
--HG--
extra : moz-landing-system : lando
According to the new svg 2 spec update (#543), we flip the flag half way for
path interpolation.
Differential Revision: https://phabricator.services.mozilla.com/D6192
--HG--
extra : moz-landing-system : lando
Add tests for ComputeSquaredDistance on |offset-path:path()|.
Depends on D4791
Differential Revision: https://phabricator.services.mozilla.com/D4788
--HG--
extra : moz-landing-system : lando
flushComputedStyle is as follows:
var cs = getComputedStyle(elem);
cs.marginLeft;
That _probably_ flushes style in most engines, but it's possible some engine in
the future will optimize things in a way that it can flush marginLeft without
flushing, say, backgroundColor. Before moving these tests to wpt, it would be
better to explicitly flush the property (or at least one of the properties) we
are transitioning.
This patch also updates the "Setting zero combined duration" test from
test_animation-cancel.html since, in making this change, I realized the test was
wrong.
Specifically, it was testing that when we set a combined duration of zero that
a transition is canceled. However, nothing in the spec requires this. The spec
only requires a non-zero combined duration to _start_ a transition and only
cancels an existing transition if the combined duration becomes _zero_ if the
"the end value of the running transition is not equal to the value of the
property in the after-change style".
This test passed, however, because it changed the transition property to
margin-top, hence it was actually testing the same condition as the previous
test.
--HG--
extra : rebase_source : ab1890c3125cb0a136869cd665efd2aa358304f0
This patch splits the first test into four separate tests since it really seems
to be testing four different things.
Likewise, the later patch for replacing the effect is split into two parts:
- One to test the playState behavior
- One to test the value reported by transitionProperty
The test, "After setting a transition's effect to null, transitionend is still
dispatched", is dropped since it is covered by the last test in
test_event-dispatch.html.
--HG--
extra : rebase_source : dae7ade8a7217e7916930278050b1c9fae847553
This patch merely tidies up some whitespace and uses of quotes / template
strings. There are no substantive changes.
--HG--
extra : rebase_source : 09383565b47c2a6173e1839756058e2b20dfff16
This mostly just tidies up these tests to give them sensible titles.
The only test with major substantive changes is the first test. This test tests
three things:
1) That getAnimations() returns one transition per transitioning property
2) That getAnimations() returns transitions in the order they were generated
3) That CSS transitions have their start time set based on when they were
generated.
(2) is covered later in this file by the test: 'getAnimations sorts
transitions by when they were generated'
(3) is really a test for startTime, if anything, not getAnimations().
I'm not sure how necessary it is, but I've added it to
test_animation-starttime.html for now.
As a result, this patch updates this first test to only cover (1).
--HG--
extra : rebase_source : 992861421e83e8fc391f865888428de22ed16914
This is mostly whitespace tidy-ups. The only substantive change is the fix to
the test description which previously seemed to be missing some words.
--HG--
extra : rebase_source : 9eb84f5a845ece8fe60d5322de6d5f8a6580c370
Apart from obvious tidy-ups the substantive changes to tests in this file are as
follows:
* Skipping forward through animation
-> This is really testing two things:
(a) That you can seek a transition using the start time.
(b) That seeking a transition using the start time triggers
dispatching events.
This patch splits the above into two separate tests.
* Skipping backwards through animation,
-> All these tests are really just exercising event dispatch which is
already covered by test_event-dispatch.html.
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 'Pausing clears the start time'
in wpt/web-animations/timing-model/animations/pausing-an-animation.html
--HG--
extra : rebase_source : ed598e907085d1cb06ef2142d6471eec4a34300d
The test: 'A new ready promise is created each time play() is called the
animation property', is covered in:
web-animations/interfaces/Animation/ready.html
by the 'A new ready promise is created when play()/pause() is called' test.
As a result, this patch removes that test.
--HG--
extra : rebase_source : 61059b90fec505784b9df67c9b8a2962ca45204b
This seems to be adequately covered by:
web-animations/timing-model/animations/pausing-an-animation.html
(specifically the last test: 'The animation's current time remains fixed
after pausing')
web-animations/timing-model/animation-effects/simple-iteration-progress.html
(which checks that the iteration progress is correctly calculated from the
current time)
--HG--
extra : rebase_source : 58fc61afb9ae638568f17950723bdba0c758c6a5
For the first test, we really want to check that it is possible to restart
transitions (since they are otherwise disassociated once they finish) hence this
patch updates the test to the actual output in style rather than timing.
The second test is covered in
web-animations/timing-model/animations/reversing-an-animation.html
by the 'Playing a finished and reversed animation seeks to end' test so this
patch removes it from this file.
--HG--
extra : rebase_source : 415b8c9ca314085e64ffc715bf72046db264cf52
This patch basically completely rewrites this file to make it simpler and remove
unnecessary tests.
In particular:
* It sets the duration and delay to 100s to match what we use in most tests
* All the helper methods at the start are inlined into the relevant tests
because doing so makes the tests much easier to read and debug.
* The first two tests are combined and extended
- Testing the initial current time is zero is not generally useful but it is
when we're testing setting it
- What the second test really wants to test is that the style updates (i.e.
you really can seek a transition, not just that the currentTime value
updates)
- The trick where we set the start time just to get out of the pending state
seems unnecessary, we may as well just wait on ready. In fact, we don't
_need_ to do that, but this test is about checking you can seek a transition
in motion.
* In the fourth test, 'Skipping backwards through transition', we don't check
the event is dispatched since that is covered in test_event-dispatch.html
in the 'Active -> Before' test.
* The final test, 'Animation.currentTime after pausing', is covered by
web-animations/timing-model/animations/pausing-an-animation.html
--HG--
extra : rebase_source : 113af8f3e4b4f2ffe90cb9bb87be3c2e72a82289
We're a bit inconsistent about this, but generally we try to keep this files as
minimal as possible.
There is still a lot of other cruft in the starttime and currenttime test files
but we will remove that when we tidy up those files in later patches in this
series.
--HG--
extra : rebase_source : 93ef290315b4650650de960551ff07572ff7656e
As part of this change, the "Restart transition after cancelling transition
immediately" test in test_event-dispatch.html needed significant changes.
The reason is that this test was calling:
watcher.wait_for([ 'transitioncancel',
'transitionrun',
'transitionstart' ]);
However, it was not waiting for the result of that call and hence was not
actually checking if the events were being dispatched. And, they are not.
There are two problems. Firstly, this test cancels the transition by setting
display:none. However, transitions don't run on display:none elements so
attempting to restart the transition will not generate transition events.
This might be a bug, but it is not a recent regression in any case (I tested
back to Firefox 54).
However, this test does not require using display:none to cancel. There are
_many_ tests that check that display:none generates a transitioncancel event.
This test only needs to make the transition idle. As a result, this patch makes
that test call transition.cancel() instead.
However, even with that change this test will not pass because it sets
a transition-delay of 100s (presumably so that it does not need to check for
a transitionstart event). As a result this test should not wait on _both_
transitionrun and transitionstart but just transitionrun.
--HG--
extra : rebase_source : a0af0928fd5668b23c92bd8ca142d4b8e99f5429
This patch also drops the checkStateOnSettingCurrentTimeToZero function since it
is no longer used.
--HG--
extra : rebase_source : bd4fdb9368d55b120c839330dbd90a0a89464370
The applying change hints are the same as what we apply for transform style
changed from something to 'none'.
All test cases pass with this fix fail without the fix.
MozReview-Commit-ID: 7HStU26lRPq
--HG--
extra : rebase_source : 701361d477ab7954ab15fde75fd40d98724e47b3
All test cases here pass without any changes on the current trunk, but all
counter part test cases for transform introducing in a subsequent patch will
fail without the proper fix.
MozReview-Commit-ID: 3hgsVfFJPrZ
--HG--
extra : rebase_source : 535b74c6ddb070af1b1803d966a94bf7ae7bd37d
background-color animations will run on the compositor. So we have to change
the property in tests which suppose that background-color animation runs on the
main-thread.
The reason why we use z-index is that the property produces only
nsChangeHint_RepaintFrame, thus it's throttled and won't be unthrottled
periodically on out-of-view elements just like background-color animations.
MozReview-Commit-ID: LZYs0qOGskh
--HG--
extra : rebase_source : f299e46a293db067f771ebd50be34ba9460e8ea7
It would be easier to understand what happens.
MozReview-Commit-ID: 5lidrbNBzFm
--HG--
extra : rebase_source : d4f1e75928cee449f98ee8224b8740b2ba0f9898
This is probably the last thing we will ship since it needs the most spec work.
MozReview-Commit-ID: LLmDBLCsCBJ
--HG--
extra : rebase_source : c06752c9201a9ede87e1ac200ab12577bf784ce6
This feature should not be shipped until the various definitions of addition for
each additive property are properly specified.
Unlike other patches in this series, compositing is not frequently used
internally (e.g. by DevTools etc.) so there is no need to enable this by default
for system code.
Also, it turns out we have inadvertently been shipping part of this feature for
some time now. The next patch in this series will add tests for that case and
disable that part of the feature (a suitable intent to unship will follow). This
patch merely adapts and extends the existing tests without affecting the surface
area covered by the combination of the newly-added pref and the existing
dom.animations-api.core.enabled pref.
MozReview-Commit-ID: Htr6mlyCBav
--HG--
rename : dom/animation/test/mozilla/file_disable_animations_api_core.html => dom/animation/test/mozilla/file_disable_animations_api_compositing.html
rename : dom/animation/test/mozilla/test_disable_animations_api_core.html => dom/animation/test/mozilla/test_disable_animations_api_compositing.html
extra : rebase_source : 7715a25e59568eb122ba3f7dbd2c2b2ffdd19954
This preference controls whether authors are allowed to specify animations
without a 0% or 100% keyframe.
We intend to ship this soon but this preference acts as a safeguard in case we
discover we need to disable it.
This feature is very convenient and commonly used so this patch ensures it is
always enabled for system content.
MozReview-Commit-ID: BHTsuS2xO61
--HG--
rename : dom/animation/test/mozilla/file_disable_animations_api_core.html => dom/animation/test/mozilla/file_disable_animations_api_implicit_keyframes.html
rename : dom/animation/test/mozilla/test_disable_animations_api_core.html => dom/animation/test/mozilla/test_disable_animations_api_implicit_keyframes.html
extra : rebase_source : 04fd93dd26a4765c14b0b22febdb0311b650ea59
We don't intend to ship this in the near future until the integration with
AnimationWorklet is clear (although we might ship a read-only version).
That said, we use this feature extensively internally (e.g. in DevTools etc.) so
we enable this feature for system callers.
MozReview-Commit-ID: AhB7ZmU1Xzw
--HG--
extra : rebase_source : 630d7dc56b44a9261bb34aa5417cb9b7050efba4
Many tests set the dom.animations-api.core.enabled pref to true when all they
really require are the features covered by the dom.element-animate.core.enabled
pref. Now that we have removed that pref and permanently enabled that
functionality we can drop the annotations from such tests.
MozReview-Commit-ID: CGOLp6pVFLE
--HG--
extra : rebase_source : e298e9404d76d55421d9ca4b514410d02cc243b1
When the pending animation having no target element sets a new effect having
a target element associated with a document, PendingAnimationTracker has to
start tracking the animation regardless of mPendingReadyTime.
MozReview-Commit-ID: DxmbXtLhjCT
--HG--
extra : rebase_source : 46c9a51e7d3b971a0c0ffcf94b579d22450028f5
If we have a rotate axis whose length is extremely large, we will get an
infinite value, and its normalized vector is a zero vector, instead of an
unit vector, i.e. (x/inf, y/inf, z/inf) == (0, 0, 0).
The solution is: we scale the vector, so the length becomes a finite value,
and we could get a valid unit vector. Therefore, we use
a different normalization method, robust_normalize().
MozReview-Commit-ID: L8SteFe09aO
--HG--
extra : rebase_source : 4568c8bf906a9246e4ef13672a9ed541852b974a
This call was added in bug 929362, but the key factor to fix the bug was just
setting a flag representing that the target frame doesn't allow the animation
running on the compositor and checking the flag in the function whether the
animation can be run on the compositor or not in later ticks. So the call
wasn't necessary in the first place.
The test case here fails without this fix. The test case actually doesn't
observe animation restyle count at all, so it might look a bit awkward in
file_restyles.html, if we add other test cases checking SchedulePaint calls
in future, we will move the tests in a different file.
(The reason there is no animation restyles in this case is that we properly
throttle the animation in this case.)
MozReview-Commit-ID: AyHciRJHM0s
--HG--
extra : rebase_source : f3963336ea9165b0a9c1a662bdac5c645b209219
Before this change, we don't acend up frame tree across different documents,
but it's possible that subframe document is scrolled out in the parent document,
if there are animations in such subframes, we should throttle the animations
too.
The test case added here fails without this fix.
MozReview-Commit-ID: EdOEVEwomPc
--HG--
extra : rebase_source : 4d6366cf609d9269ec05b3722f5adb21d940a9e3
Because now we don't try to send the animations on visibility:hidden element.
MozReview-Commit-ID: IFqIc8ewz5T
--HG--
extra : rebase_source : ed031b3a55fd89f74437b71812f90dfc1825e823
Even if we unthrottled the invisbile animations to update the overflow region,
we don't need to send the animations to the compositor since the scroll bar
updates caused by the overflow should have been finished before sending
animations to the compositor.
MozReview-Commit-ID: GtKdPfBSyRB
--HG--
extra : rebase_source : 3b15f4578ed60740c1409304fe35ecd4f53fbd5b
The styles for placeholder frames differ from the styles for the real frames so
that the styles don't have visibility:hidden even if the parent has
visibility:hidden style.
The placeholder style is resolved by ServoStyleSet::ResolveStyleForPlaceholder
in nsCSSFrameConstructor::CreatePlaceholderFrameFor.
MozReview-Commit-ID: GgFn5VJOvcl
--HG--
extra : rebase_source : a32771f5bb6c6862e483fe36a2060d604ee2413d
When an animation targets a CSS property that could cause a containing block to
be generated for its descendants, this containing block must be generated even
if the particular property values used by the animation would not normally
trigger generation of a containing block (e.g. transform: none). This is due
to the implicit application of will-change defined in CSS Animations[1] and Web
Animations[2].
Since this containing block is generated at the start of the animations, we can
throttle animations that produce the UpdateContainingBlock change hint for
animations that are not visible since they shouldn't have any further side
effects beyond the generation of containing blocks (which have already happened).
[1] https://drafts.csswg.org/css-animations/#animations
[2] https://drafts.csswg.org/web-animations-1/#side-effects-section
Unfortunately perspective animations starting with 'none' and transform
animations from 'none' to 'none' don't create a containing block (bug 1470349
and bug 1470370). That doesn't block the optimization in this patch, however,
since those bugs occur regardless of element visibility.
MozReview-Commit-ID: 8rTl8dShHrD
--HG--
extra : rebase_source : 886b003d0f3c555a12baf0de81b4130ef2d71e82
In the case where the target element is scrolled out or visibility:hidden and
has no visible descendants, we can treat nsChangeHint_UpdateOverflow just like
transform animations which produce nsChangeHint_UpdatePostTransformOverflow,
i.e. unthrottle the animations periodically if the target element is inside a
scrollable element. Some transform animations produce UpdateOverflow hint,
so it would be really nice to optimize the hint.
MozReview-Commit-ID: E1MgPZRi8mW
--HG--
extra : rebase_source : d29a29e137742f88a64b3b18a5a7d4e64e76f54f
The styles for placeholder frames differ from the styles for the real frames so
that the styles don't have visibility:hidden even if the parent has
visibility:hidden style.
The placeholder style is resolved by ServoStyleSet::ResolveStyleForPlaceholder
in nsCSSFrameConstructor::CreatePlaceholderFrameFor.
MozReview-Commit-ID: GgFn5VJOvcl
--HG--
extra : rebase_source : 5ea5b101fff03cb2a834e218f4e6df0a0527dfdb
When an animation targets a CSS property that could cause a containing block to
be generated for its descendants, this containing block must be generated even
if the particular property values used by the animation would not normally
trigger generation of a containing block (e.g. transform: none). This is due
to the implicit application of will-change defined in CSS Animations[1] and Web
Animations[2].
Since this containing block is generated at the start of the animations, we can
throttle animations that produce the UpdateContainingBlock change hint for
animations that are not visible since they shouldn't have any further side
effects beyond the generation of containing blocks (which have already happened).
[1] https://drafts.csswg.org/css-animations/#animations
[2] https://drafts.csswg.org/web-animations-1/#side-effects-section
Unfortunately perspective animations starting with 'none' and transform
animations from 'none' to 'none' don't create a containing block (bug 1470349
and bug 1470370). That doesn't block the optimization in this patch, however,
since those bugs occur regardless of element visibility.
MozReview-Commit-ID: 8rTl8dShHrD
--HG--
extra : rebase_source : f2f89c8ad074f1ad73ebd5652311d22e71cf7344
In the case where the target element is scrolled out or visibility:hidden and
has no visible descendants, we can treat nsChangeHint_UpdateOverflow just like
transform animations which produce nsChangeHint_UpdatePostTransformOverflow,
i.e. unthrottle the animations periodically if the target element is inside a
scrollable element. Some transform animations produce UpdateOverflow hint,
so it would be really nice to optimize the hint.
MozReview-Commit-ID: E1MgPZRi8mW
--HG--
extra : rebase_source : d29a29e137742f88a64b3b18a5a7d4e64e76f54f
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
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
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
