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
This is a large patch which tries to switch many of the external consumers of
nsGlobalWindow to instead use the new Inner or Outer variants.
MozReview-Commit-ID: 99648Lm46T5
To do that, ideally we can wait for MozAfterPaint, but it's sometimes fired
before we do a paint process (bug 1341294), we should avoid using it until
that bug is fixed.
So, we wait for two requestAnimationFrames instead. The callback for
requestAnimationFrame is called before styling process, so we need to wait for
one more frame there. For now a Promise in waitForFrame is processed after
paint process, so these tests would have been working fine with waiting for a
single requestAnimationFrame. But after bug 1193394, the Promise will be
processed right after requestAnimationFrame, thus these tests will fail with a
single requestAnimationFrame.
MozReview-Commit-ID: 4pbofZ3DUm3
--HG--
extra : rebase_source : 133d0a259f81142fb9781d697642e82a577abb6b
So that we can surely receive these animation events in the handler before
the EventWatcher receives the events.
MozReview-Commit-ID: 9jVJ3TgwYeq
--HG--
extra : rebase_source : 470b63b35c3a52f48ddd08d4b529c6b1eb957cb2
And unthrottle them on every 200ms just like we do for transform animations on
the compositor. To unthrottle the transform animations properly, we need to
update UpdateLastTransformSyncTime each time we compose the style for the
animations instead of updating it when we send the transform animation to the
compositor. That's because display item for transform is built even while we
are throttling the transform animations for some reasons, so if we updated the
last transform sync time there, the time will not match what it should be.
MozReview-Commit-ID: GwMzJqUlzd2
--HG--
extra : rebase_source : 09e379191970687a9f35aead871acf450c63813e
Now test_restyles.html runs in content window, so theoretically we no longer
receive unexpected animation restyles in chrome window.
MozReview-Commit-ID: GJq6WTdEBy8
--HG--
extra : rebase_source : cfdbf0b6c709d6a24d6d038ec71f664ccf745317
In TimingParams::CalcActiveDuration(), we intentionally use IsZero() instead
of the bool() operator since the value |aDuration| is Maybe<StickyTimeDuration>
, it's easily misread as Maybe::bool().
MozReview-Commit-ID: D5Nb7cxh7wi
--HG--
extra : rebase_source : e30fe73c5b02d09ab5116bcfc6ca20a902b13b75
The synthetic mouse move flushes animation styles during running test cases on
Linux, it breaks these tests!
MozReview-Commit-ID: DOT7m3fhrZi
--HG--
extra : rebase_source : 6fe04028073277276df9ae4a24ad62f9e4419d5c
Hiroyuki Ikezoe
Sebastian Hengst
Mantaroh Yoshinaga
Brian Birtles
Jonathan Watt
Noemi Erli
Ya-Chieh Wu
Csoregi Natalia
Kartikaya Gupta
Joel Maher
Jan de Mooij
Nika Layzell
Zibi Braniecki