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
If we waited for a single requestAnimationFrame and changed the style inside
the callback, we have no chance to process the style change there.
* Before this change:
- Tick:
Start observing restyles
Process restyling but there is no need to do.
- Next tick:
Run requestAnimationFrame callbacks
set the style
finish observing restyles
* After this change:
- Tick:
Set the style
Start observing restyles
Process restyling the style
- Next tick:
Run requestAnimationFrame callbacks
finish observing restyles
MozReview-Commit-ID: JNQLjOXz3AZ
--HG--
extra : rebase_source : 68da01d65fcade7137c6a06551438e64cd157d0f
As mentioned in the previous commit, with the conformant Promise handling there
are cases where a requestAnimationFrame callback can happen in the same tick of
the refresh driver, that is, the same animation frame. We should only count
callbacks that occur in frames subsequent to the current one.
MozReview-Commit-ID: IEC7uFwGysS
--HG--
extra : rebase_source : 9a0642507c73ce8195145290bb783a3de3f9ba1b
With the conformant Promise handling, there are cases that we are still in the
same tick even after we got a reqeustAnimationFrame. For example, if we call
requestAnimationFrame() in the callback for an animationstart event, the
callback is processed just before the callback for requestAnimationFrame is
processed in a tick, so we are still in the same tick even after we got the
requestAnimationFrame.
MozReview-Commit-ID: Cgnu7Mk4Nl8
--HG--
extra : rebase_source : 6adfdef01e1ad1ab0cf5f93f89bc4946f49c0638
We have already start() call at the top of this test file, the start() there
is called after setting 'layout.css.devPixelsPerPx' pref, that should be only
one call for start().
MozReview-Commit-ID: A43vfwfLer3
--HG--
extra : rebase_source : 7cf3157bb781c135c726d252048fe52393ead428
This patch will :
* Create test div element after waiting for document load, then wait for
painting after it.
* Change to waiting for MozAfterPaint event without workaround of waiting for
excessive frames.
MozReview-Commit-ID: 6Ytxln3tJi4
--HG--
extra : rebase_source : 53b5f038ec95dd47b76d4a0bcf8dfd964bff451d
This reflects the change made to the Web Animations specification in:
9e2053f5531c3415f4cc
(I got it wrong the first time. The second commit fixes the first.)
And discussed in:
https://github.com/w3c/web-animations/issues/196
In summary, we are splitting the "pending" play state out into a separate
boolean member so that it is possible to distinguish between "play-pending" and
"pause-pending" and because most of the time when you check for
animation.playState === 'running' you also really want to include play-pending
animations.
MozReview-Commit-ID: IJSNoZTKW2I
--HG--
extra : rebase_source : 5d17239fd087cfe3cce1c9697eff97d062b6dd4b
The difference between nsDocument::IsWebAnimationsEnabled and
nsContentUtils::AnimationsAPICoreEnabled is that the former checks the caller
type and treats the preference as set for system callers which is particularly
needed for enabling things like the getProperties() API for DevTools etc.
Generally in API-facing call sites we have a JS context / CallerType and so we
want to distinguish between system callers and non-system callers. However, for
a few internal uses--specifically filling-in missing keyframes--we don't care
about the caller type and always follow the pref setting.
That may or not be quite what we want, but this patch doesn't change that except
for one call site: KeyframeUtils::GetKeyframesFromObject. This patch changes
GetKeyframesFromObject from *not* checking the caller type to checking the
caller type. That seems to be the correct behavior here since this is called
from KeyframeEffectReadOnly::SetKeyframes(JSContext*, JS::Handle<JSObject*>,
ErrorResult&) (i.e. a JS API-facing call site) where we *should* enable the full
API when the caller is chrome code.
MozReview-Commit-ID: FQJBk3zytwd
--HG--
extra : rebase_source : 577bca1e551e39fecfab309f64c993eba110337f
There are two places where I have to cache the status of MayHaveOpacityAnimation
and MayHaveTransformAnimation. First place is in |nsIFrame:init()| where an
element is associated with a frame. Second place is in
|KeyframeEffectReadOnly::UpdateEffectSet()| where the script can add animations
on element.
btw I keep the original two flags of MayHaveOpacityAnimation and
MayHaveTransformAnimation in EffectSet because there is no guarantee that
an element has been associated with a frame when we call to |UpdateEffectSet()|.
But we still want to keep the benefits that we can quickly look up
MayHaveOpacityAnimation or MayHaveTransformAnimation. So I keep them in
EffectSet and transfer the status into nsIFrame when we bind an element
to a frame in nsIFrame:Init().
MozReview-Commit-ID: JDwyAQQTKA7
Before this change, the test calls getAnimations() after changing animation
duration. Unfortunately it was wallpapering what's going on there actually
since getAnimations() flushes pending styles. This patch drops the
getAnimations() call and makes it clear how many restyles happen there.
MozReview-Commit-ID: A0a5MlTyBnD
--HG--
extra : rebase_source : cc20d2c6945f81f72c753137441b8d84ff52ff63
This follows from the previous patch; these values feed into UpdateMinMaxScale
as well, which explicitly wants to use floats, so there's no point in creating
doubles. The source of this information is also a float-based matrix.
MozReview-Commit-ID: LPk4Xm9AaJJ
--HG--
extra : rebase_source : d7714755fb1078880133d6f044cc9bc7743439ee
When paintingSuppressed flag is true, paint_listener.waitForPaints() defers the
waiting paint to the next tick. The paintingSupressed flag is set when pres
shell is initialized and at that time if the document has not been loaded yet,
a timer is created to clear the flag after nglayout.initialpaint.delay
elapsed. And when the timer is fired, the flag is cleared, but if there is
still pending reflow, it's not cleared.
So what happened in the failure case;
1) In the first promise_test we wait for document load
2) The paintingSuppressed flag is set in the first promise_test and create the
timer
3) When the document has been loaded but the timer has not yet been fired,
start test refresh mode and create an element in the subsequent promise_test
4) Creating the element triggers a reflow
5) waitForPaints() is called
6) The timer is fired, but there is a pending reflow, so skip clearing the flag
7) Now it's in the test refresh mode, the pending flow will never be processed
until some triggers happen (i.e. mouse movement, calling
advanceTimeAndRefresh, etc.)
8) The test is timed out
MozReview-Commit-ID: 5fLn9SNHp1J
--HG--
extra : rebase_source : 3115a5d5ac1405f18efde7ade1fb9738858c518f
Hiroyuki Ikezoe
Boris Chiou
Emilio Cobos Álvarez
Sebastian Hengst
Mantaroh Yoshinaga
Brian Birtles
Jonathan Watt
Noemi Erli
Ya-Chieh Wu
Csoregi Natalia
Kartikaya Gupta
Joel Maher
Jan de Mooij