This patch reflects the following change to the Web Animations spec:
abf76745b5
MozReview-Commit-ID: A2GD1igUf5f
--HG--
extra : rebase_source : 8129f6386b144adebc3bf0320ca7d6bfbba7a2e9
These tests can be passed now, I don't know what fixed them, presumably
bug 1421476 and bug 1379515 fixed it.
MozReview-Commit-ID: 2srFKTWWvK
--HG--
extra : rebase_source : 418d366ade78d5a9994cb9bbbab39c4c0b42a2a4
The call stack where this assertion would otherwise fail is as follows:
KeyframeEffectReadOnly::UpdateProperties
KeyframeEffectReadOnly::DoUpdateProperties
KeyframeEffectReadOnly::BuildProperties
KeyframeUtils::GetAnimationPropertiesFromKeyframes
KeyframeUtils.cpp::GetComputedKeyframeValues
KeyframeEffectReadOnly::EnsureBaseStyles
In bug 1407898 we made GetComputedKeyframes return an empty list when the pres
context is nullptr so if we get a null pres context in EnsureBaseStyles (which
uses the same method for getting the pres context:
nsContentUtils::GetContextForContent) we know that |aProperties| will be empty.
Also, if |aProperties| is empty we're not going to dereferences |presContext| so
we don't need to assert that it is non-null.
I have not included the crashtest in this patch for the same reason as described
in bug 1407898 comment 6.
MozReview-Commit-ID: 6OZ2yJfRLMV
--HG--
extra : rebase_source : b2a711a54623ea177560cf1b69b3c332654bc938
Animation.finish() in a micro task for Animation.ready leads to a restyle and
a redundant restyle due to bug 1415457. The redundant restyle has been observed
in a single frame without the conformant Promise handling. But once we have the
conformant Promise handling we can tell it in a later frame.
(see https://bugzilla.mozilla.org/show_bug.cgi?id=1415457#c1 to know what's
going on there)
MozReview-Commit-ID: FoojunfYZ6k
--HG--
extra : rebase_source : 2820dce4513329fb648ef387d58cac469f680a6d
The expected restyle count depends both on animation state and micro task
handling.
If we have the conformant Promise handling and if the animation begins at the
current time, we will observe 1 less restyles than observed frames since we
skip the first restyle in the initial frame. This represents correctly what
we do and what we *should* do.
If we don't have the conformant Promise handling and if the animation doesn't
begin at the current time, we will observe 1 more restyles than obsered frames
since the Promise in observeStyling (precisely the Promise is inside the
callback for requestAnimationFrame) is fulfilled once after a restyling process
followed by the requestAnimationFrame.
MozReview-Commit-ID: FLhSRx4y1V7
--HG--
extra : rebase_source : 59e2bb2439f69bc1415a441c0b84a81463d8229f
The test case checks document timeline's currentTime to make sure that we are
in the first frame which happened after 200ms since the animation started. It
is unfortunate for us from the point of view of restyling that the first frame
includes the restyling process in the frame without the conformant Promise
handling, doesn't include the process with the Promise handling. So we need
to tweak there depends on the Promise handling.
I did intentionally add the forked version of the function with the same name
since branching depending on the conformant flag inside the original function
will be hard to understand and also we can easily remove the original version
once we have the conformant Promise handling.
FWIW, here is the diff between them:
@@ -365,6 +365,9 @@ waitForAllPaints(() => {
await SpecialPowers.pushPrefEnv({ set: [["ui.showHideScrollbars", 1]] });
+ // Make sure we start from the state right after requestAnimationFrame.
+ await waitForFrame();
+
var parentElement = addDiv(null,
{ style: 'overflow-y: scroll; height: 20px;' });
var div = addDiv(null,
@@ -379,13 +382,17 @@ waitForAllPaints(() => {
var markers;
var now;
while (true) {
- markers = await observeStyling(1);
- // Check restyle markers until 200ms is elapsed.
now = document.timeline.currentTime;
if ((now - timeAtStart) >= 200) {
+ // If the current time has elapsed over 200ms since the animation was
+ // created, it means that the animation should have already
+ // unthrottled in this tick, let's see what observes in this tick's
+ // restyling process.
+ markers = await observeStyling(1);
break;
}
+ markers = await observeStyling(1);
is(markers.length, 0,
'Transform animation running on the element which is scrolled out ' +
'should be throttled until 200ms is elapsed');
MozReview-Commit-ID: 3WfY6aVnsXk
--HG--
extra : rebase_source : ddf51217f03fc1bfe421c344a7a7811dc591a9af
Animation.finish() in a micro task for Animation.ready leads to a restyle and
a redundant restyle due to bug 1415457. The redundant restyle has been observed
in a single frame without the conformant Promise handling. But once we have the
conformant Promise handling we can tell it in a later frame.
(see https://bugzilla.mozilla.org/show_bug.cgi?id=1415457#c1 to know what's
going on there)
MozReview-Commit-ID: FoojunfYZ6k
--HG--
extra : rebase_source : 2820dce4513329fb648ef387d58cac469f680a6d
The expected restyle count depends both on animation state and micro task
handling.
If we have the conformant Promise handling and if the animation begins at the
current time, we will observe 1 less restyles than observed frames since we
skip the first restyle in the initial frame. This represents correctly what
we do and what we *should* do.
If we don't have the conformant Promise handling and if the animation doesn't
begin at the current time, we will observe 1 more restyles than obsered frames
since the Promise in observeStyling (precisely the Promise is inside the
callback for requestAnimationFrame) is fulfilled once after a restyling process
followed by the requestAnimationFrame.
MozReview-Commit-ID: FLhSRx4y1V7
--HG--
extra : rebase_source : 59e2bb2439f69bc1415a441c0b84a81463d8229f
The test case checks document timeline's currentTime to make sure that we are
in the first frame which happened after 200ms since the animation started. It
is unfortunate for us from the point of view of restyling that the first frame
includes the restyling process in the frame without the conformant Promise
handling, doesn't include the process with the Promise handling. So we need
to tweak there depends on the Promise handling.
I did intentionally add the forked version of the function with the same name
since branching depending on the conformant flag inside the original function
will be hard to understand and also we can easily remove the original version
once we have the conformant Promise handling.
FWIW, here is the diff between them:
@@ -365,6 +365,9 @@ waitForAllPaints(() => {
await SpecialPowers.pushPrefEnv({ set: [["ui.showHideScrollbars", 1]] });
+ // Make sure we start from the state right after requestAnimationFrame.
+ await waitForFrame();
+
var parentElement = addDiv(null,
{ style: 'overflow-y: scroll; height: 20px;' });
var div = addDiv(null,
@@ -379,13 +382,17 @@ waitForAllPaints(() => {
var markers;
var now;
while (true) {
- markers = await observeStyling(1);
- // Check restyle markers until 200ms is elapsed.
now = document.timeline.currentTime;
if ((now - timeAtStart) >= 200) {
+ // If the current time has elapsed over 200ms since the animation was
+ // created, it means that the animation should have already
+ // unthrottled in this tick, let's see what observes in this tick's
+ // restyling process.
+ markers = await observeStyling(1);
break;
}
+ markers = await observeStyling(1);
is(markers.length, 0,
'Transform animation running on the element which is scrolled out ' +
'should be throttled until 200ms is elapsed');
MozReview-Commit-ID: 3WfY6aVnsXk
--HG--
extra : rebase_source : ddf51217f03fc1bfe421c344a7a7811dc591a9af
It is possible that animating computed style becomes the same value as the
value in the previous tick if Animation.mPendingReadyTime is pretty close
to the timeline current time.
MozReview-Commit-ID: COuur4Wlufx
--HG--
extra : rebase_source : 5dea9ef0bce7cb606dc290277e04b779fe608bbd
The 'is' check there will be replaced 'todo_is' after the commit for the new
micro task checkpoint.
MozReview-Commit-ID: EGFZWy8BD3O
--HG--
extra : rebase_source : 034717a9e7aac0edb82613321ec056ed07cdb996
If element which has script animations is detached between Animation::Tick and
styling process, the element persists in EffectCompositor::mElementsToRestyle
(bug 1417354). When the element is attached to the document again, the element
in mElementsToRestyle is considered as a target element that needs to be
traversed in the first animation-only restyling. Thus the remaining restyle
request can be observed with the new micro task checkpoint for animations.
MozReview-Commit-ID: F6gs2QXcZ8X
--HG--
extra : rebase_source : 09ccf76e4d28ee55facc5a62f3e8f08e0eeb3e03
Similar to the previous commit, if Animation.pause() is called between
restyling process and the next refresh driver's tick and if we wait for
Animation.ready after the pause(), there should be one restyle that hasn't
yet processed.
MozReview-Commit-ID: JnpwhOuDvPz
--HG--
extra : rebase_source : b6f14e05837754d1bd51c8a50ce8d82a0c7d751a
If Animation.finished promise was fulfilled in Animation::Tick, at the moment we
haven't yet restyled the final animation value. So once we have new micro task
checkpoint there we can observe a restyle marker after Animation.finished was
fulfilled.
MozReview-Commit-ID: LiEl4Iu2Cbr
--HG--
extra : rebase_source : d88b037eba2fd07d75a3ab429c028e23e5137b52
'finish_from_pause' supposes that finish() is called after pause pending state
is finished. Whereas 'finish_from_pause_pending' supposes that finish() is
called during pause pending state. We should check the state respectively.
MozReview-Commit-ID: DUq2ghK6h9I
--HG--
extra : rebase_source : 2d4ded71387e75efcff9bb184b8e51475bc8bc56
With this patch we still use a global MutationObserver and a single target
element and re-use them in all test cases. Eventually each test should create
a target element and a MutationObserver to avoid explicit cleanup jobs (e.g.
clearing styles and flushing styles for the global target element), but it's
not in the scope of this bug.
MozReview-Commit-ID: IqEjMbTrpAK
--HG--
extra : rebase_source : 7463c21ce946f5c15f2b7bc4a71c90dba784385d
Most of test cases in the test file has been moved so that the test no longer
takes over default time out (5 minutes).
MozReview-Commit-ID: 9rrr7WrkcFH
--HG--
extra : rebase_source : 44ca3c0e42a389d82185e55b257c1dceb6d407d4
Below list is animation test cases remain in test_animation_observers_async.html
* single_animation : waiting for animationend event
* single_animation_cancelled_fill : waiting for animaitonend event
* tree_ordering : waiting for animationend event
* coalesce_change_cancel : testing a non-cancelling change to an animation
followed immediately by a cancelling change sends only one removal
notification, I am concerned that adding explicit style flush
(e.g. getComputedstyle) might change the test purpose.
* play : redundant play() seems to be affected by asynchronous.
I haven't dug into detail.
* finish_from_pause : waiting for Animation.ready to make sure pause pending
state to finish.
MozReview-Commit-ID: HAelOTwSqgv
--HG--
extra : rebase_source : 819e8975028f62580dccd07fedc53d250b71f97a
Below list is transition test cases remain in test_animation_observers_async.html
* single_transition : waiting for transitionend event
MozReview-Commit-ID: 5ecgpJm1W6p
--HG--
extra : rebase_source : d5c77cf77521f62a693897230d73287deab8b6c7
In the first frame after the initial paint, we skip restyling if the initial
paint took over vsync refresh rate as an optimization and to avoid jumpy
animations. To avoid checking this skipped restyling that we'd actually expect
a restyle maker there, firstly we check there is no restyle marker after the
initial paint for scrolled out animation for five frames, and we then make the
element visible and check a restyle marker there.
MozReview-Commit-ID: 5XkJhdtUly5
--HG--
extra : rebase_source : 1a441296ad6f6cc42b50d300ebacd66e5dee77a1
This change is the same as bug 1422995. With the conformant Promise handling
and performing micro task checkpoint in Animation tick, waitForFrame() inside
the callback for Animation.ready does not make sure that the next frame happens.
MozReview-Commit-ID: KEz4xmHpGlk
--HG--
extra : rebase_source : 6285f2f3df3d5cb617579bb4f449832ff155e34d
We clamp animation start time on the second restyling when the initial paint
for the animation took over vsync refresh rate (16.6ms normally as of today).
The clamping leads the animation progress to the same value as the initial one.
Once this clamping happens, the animation value does not change even after
waiting for Animation.ready and a reqeustAnimationFrame. To make the animation
value change happen we should wait for one more requestAnimationFrame.
MozReview-Commit-ID: 8OTC0xkKBrr
--HG--
extra : rebase_source : 4c0313f3a96ffc85306f5687630abc13d88aed61
We have ServoCSSParser class, and I think it's better to move those
Servo FFI into this class to avoid including ServoBindings.h everywhere.
MozReview-Commit-ID: 6orXtddp9ZU
--HG--
extra : rebase_source : 6da4158c4fec606aaee49fddee3192f94d6c85a3
With the conformant Promise handling (bug 1193394) and performing micro task
checkpoint in Animation tick (bug 1416966), if we call waitForFrame() inside
the callback for Animation.ready.then it will still be done in the same refresh
driver's tick.
MozReview-Commit-ID: GQJiDHHUlyD
--HG--
extra : rebase_source : 55813e6c1fc24193e0b4b1c87934debe80d357b5
sendWheelAndPaintNoFlush which calls in waitForWheelEvent() waits for
MozAfterPaint and calls a given callback function when the MozAfterPaint is
received. The MozAfterPaint is processed after we did a paint process.
However, observeStyling counts the number of requestAnimationFrame callbacks
and yet there will be no opportunity to process restyles between the
MozAfterPaint callback and the next call to requestAnimationFrame. As a result,
if we are expecting restyles to happen on every frame, our count will be off by
one. To avoid this, we wait until the next requestAnimationFrame callback
before calling observeStyling.
Note that we *could* try to adjust observeStyling to automatically do this for
us but sometimes we want observeStyling to observe restyles in the *current*
frame. Since there's no obvious way to detect what we are trying to do it's
easier to just let each test decide from which point it wants to count restyles.
MozReview-Commit-ID: 1B8EZNozjFj
--HG--
extra : rebase_source : 748f874dbb42e06b72b12582762626a31d1e8d75
Brian Birtles
Tom Ritter
Hiroyuki Ikezoe
Csoregi Natalia
Hiroyuki Ikezoe
Kartikaya Gupta
Cosmin Sabou
Boris Chiou
Emilio Cobos Álvarez