Changes for nsIDOMWindowUtils.getOMTAValue is in the next commit with come test
cases.
Differential Revision: https://phabricator.services.mozilla.com/D13001
--HG--
extra : moz-landing-system : lando
Changes for nsIDOMWindowUtils.getOMTAValue is in the next commit with come test
cases.
Differential Revision: https://phabricator.services.mozilla.com/D13001
--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
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
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
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
We will remove animation.effect.timing in the next patch.
MozReview-Commit-ID: EyeFNM81NbN
--HG--
extra : rebase_source : 9fe5eb0e5d141ffffa017db255328c742a059611
This pref was introduced in case we encountered compatibility issues from
changing the return value of Animation.playState (bug 1412765). Now that the
change to Animation.playState has shipped to release channel without any known
problems we should drop this pref.
MozReview-Commit-ID: CwMWRRtIf6u
--HG--
extra : rebase_source : b26c59a51880406c2b94baad8da2eafeb3ae3202
KeyframeEffect and KeyframeEffectReadOnly constructors can run in the caller
compartment, which is okay because the current compartment is used in the
following places and all of them are safe:
1. GlobalObject::CallerType(), that is ultimately passed to
nsDocument::IsWebAnimationsEnabled in KeyframeEffectParamsFromUnion,
to decide whether to copy mIterationComposite/mComposite to
KeyframeEffectParams.
GlobalObject::CallerType() can now be different than the target window's one,
if the caller has the system principal and the target is web content, and
in that case nsDocument::IsWebAnimationsEnabled there always returns true
while Web Animations can be disabled on web content.
honoring the mIterationComposite/mComposite properties is OK, since it just
changes the animation behavior, and this is disabled by default until
remaining spec issues are resolved.
2. GlobalObject::Context(), that is ultimately passed to
KeyframeUtils::GetKeyframesFromObject and used while extracting information
from passed-in keyframe object, with iterable/iterator protocols.
Performing that operation in the caller side is okay, since the same thing
can be done on caller, and the operation doesn't perform any GCThing
allocation on the target window global.
KeyframeEffect and KeyframeEffectReadOnly constructors can run in the caller
compartment, which is okay because of the following reasons:
1. The target window global is used for most operation:
* KeyframeEffectReadOnly::ConstructKeyframeEffect uses the target window
global instead of current global.
* KeyframeEffectParamsFromUnion which receives `aGlobal.CallerType()`
In Xray case, Web Animations API can be disabled on web content
(currently disabled on beta/release by default), and in that case some API
won't work even it's triggered from WebExtensions, but it should be fine.
2. GetKeyframesFromObject is executed in the caller's compartment to access
the passed-in JSObject that is keyframe, with iterable/iterator protocols.
This operation doesn't perform any GCThing allocation on the target window
global.
The original value were too small for Android.
MozReview-Commit-ID: 4V6qC8orYNJ
--HG--
extra : rebase_source : 55ea0525bfaafa60d8e5d711cc70dd29d21acc78
'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
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
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
We shouldn't call synthesizeWheelAtPoint() in an rAF callback and observe
animation restyle makers there since we might end up observing an animation
restyle maker which is brought by flushing throttled animation styles for
hit-testing caused by the wheel event. Now we have sendWheelAndPaintNoFlush
which does not flush any styles before sending the wheel event, we use it.
MozReview-Commit-ID: 6WP2ExA7fAv
--HG--
extra : rebase_source : a2a5cea00fbe431dea8096b584a9f82c658158aa
Before this patch the child element actually did not move into the view and
observed an unrelated restyle maker. In the next patch we fix the observation
of the unrelated restyle maker.
MozReview-Commit-ID: 1DejqwF6hJg
--HG--
extra : rebase_source : ea6d6a48043f1b2a52ddedcbc41c321624a723d2
It much makes more sense to check the animation in out-of-view is throttled
and unthrottled once it got visible in a single test.
MozReview-Commit-ID: AZY5Xc0cbDF
--HG--
extra : rebase_source : bcdf999ee10283853c7b0bda8f450a53990a0e1c
Hiroyuki Ikezoe
Andreea Pavel
Brian Birtles
Mark Banner
Zibi Braniecki
Emilio Cobos Álvarez
Tooru Fujisawa
Boris Zbarsky
Jan de Mooij
Sebastian Hengst