Now AnimationEventDispatcher ensures that the refresh driver's next tick
happens for cancel event, so we don't need to re-observe the timeline
(it happens in UpdateTiming) once after removing the animation from the
timeline.
MozReview-Commit-ID: 7ivclmYIkPa
--HG--
extra : rebase_source : 286b3d5d29208496bfe8405819b44b5f52f6671c
So that we can now ensure nsRefreshDriver ticks (i.e. nsRefreshDriver doesn't
stop its timer) for all queued events.
Before this patch, dispatching CSS animation/transition events relied on the
fact that DocumentTimeline observes nsRefreshDriver. For this fact,
animationcancel or transitioncancel event did not dispatch properly in some
cases, i.e. the case where the animation was dropped from the DocumentTimeline.
MozReview-Commit-ID: 7JYro0MY2U2
--HG--
extra : rebase_source : 28c8e2a50d29c5344e2c5ca3c43af41f4692fa0f
Now we sort pending events only when dispatching the events, i.e.
only inside DispatchEvent().
MozReview-Commit-ID: BZbuF8gD39b
--HG--
extra : rebase_source : 2a90697356d980b1fd1329d34936eaef1179d12f
Now we sort CSS animation/transition events by scheduled event time prior
to compositor order.
SortEvents() will be a private method in the next patch in this patch
series.
MozReview-Commit-ID: ICkOayquN0f
--HG--
extra : rebase_source : 405c8232e93c54a073c722a4332873af02daa870
In a subsequent patch in this patch series, we want to make nsPresContext
have an AnimationEventDispatcher as RefPtr<>.
Instead, if we were trying to make nsPresContext have the
AnimationEventDispatcher as data object (not RefPtr<>) just like we did in
CommonAnimationManager, we will fall into header inclusion hell since Element.h
includes nsPresContext.h and AnimationEventDispatcher.h ends up including
Element.h. Even if we could solve the inclusion hell, we will suffer from Rust
bindgen issues for some reasons.
MozReview-Commit-ID: B0nX2JzIRJD
--HG--
extra : rebase_source : 4eb998876b2fc39de8d09cac09c19e1a51cd382e
Now single AnimationEventDispatcher can handle both CSS animation/transition
events simultaneously. To do this we had to change AnimationEventInfo and
TransitionEventInfo into a single struct, the struct is also named
AnimationEventInfo.
It results we can sort both CSS animation/transition events altogether. Thus
we make sure CSS animation/transition events are sorted by scheduled event time
prior to their composite order (i.e. transitions is prior to animations).
At this moment, we don't sort both events altogether since nsAnimationManager
and nsTransitionManager has an AnimationEventDispatcher respectively. In the
next patch we move AnimationEventDispatcher into nsPresContext, i.e. each
document has an AnimationEventDispatcher without the distinction between
CSS animations and transitions.
Note that, after this patch, we copy all members in InternalTransitionEvent and
InternalAnimationEvent in the copy-constructor of AnimationEventInfo, this
will be fixed once WidgetEvent has move-constructor and move-assignment
(bug 1433008).
MozReview-Commit-ID: 5JAh6N7C6ee
--HG--
extra : rebase_source : 50da76f51cf65cdd1245d93d8b48aaf0ae0ec94b
Now AnimationEventDispatcher ensures that the refresh driver's next tick
happens for cancel event, so we don't need to re-observe the timeline
(it happens in UpdateTiming) once after removing the animation from the
timeline.
MozReview-Commit-ID: 7ivclmYIkPa
--HG--
extra : rebase_source : d111c63baac0ad3005723c1c76bad08e975555ec
So that we can now ensure nsRefreshDriver ticks (i.e. nsRefreshDriver doesn't
stop its timer) for all queued events.
Before this patch, dispatching CSS animation/transition events relied on the
fact that DocumentTimeline observes nsRefreshDriver. For this fact,
animationcancel or transitioncancel event did not dispatch properly in some
cases, i.e. the case where the animation was dropped from the DocumentTimeline.
MozReview-Commit-ID: 7JYro0MY2U2
--HG--
extra : rebase_source : e1963d9eef996cdf5d64c64f80eb1b93ac6fd18a
Now we sort pending events only when dispatching the events, i.e.
only inside DispatchEvent().
MozReview-Commit-ID: IRqH56BEnKb
--HG--
extra : rebase_source : dd2b8528fdc36d1371815feaf07ead0b258fe453
Now we sort CSS animation/transition events by scheduled event time prior
to compositor order.
SortEvents() will be a private method in the next patch in this patch
series.
MozReview-Commit-ID: ICkOayquN0f
--HG--
extra : rebase_source : 52226c33a511451c31d4c3fef94ff02de8462256
In a subsequent patch in this patch series, we want to make nsPresContext
have an AnimationEventDispatcher as RefPtr<>.
Instead, if we were trying to make nsPresContext have the
AnimationEventDispatcher as data object (not RefPtr<>) just like we did in
CommonAnimationManager, we will fall into header inclusion hell since Element.h
includes nsPresContext.h and AnimationEventDispatcher.h ends up including
Element.h. Even if we could solve the inclusion hell, we will suffer from Rust
bindgen issues for some reasons.
MozReview-Commit-ID: B0nX2JzIRJD
--HG--
extra : rebase_source : cd010ca5fe5b1f9fa8f519fdab0dc47d6e519bef
Now single AnimationEventDispatcher can handle both CSS animation/transition
events simultaneously. To do this we had to change AnimationEventInfo and
TransitionEventInfo into a single struct, the struct is also named
AnimationEventInfo.
It results we can sort both CSS animation/transition events altogether. Thus
we make sure CSS animation/transition events are sorted by scheduled event time
prior to their composite order (i.e. transitions is prior to animations).
At this moment, we don't sort both events altogether since nsAnimationManager
and nsTransitionManager has an AnimationEventDispatcher respectively. In the
next patch we move AnimationEventDispatcher into nsPresContext, i.e. each
document has an AnimationEventDispatcher without the distinction between
CSS animations and transitions.
Note that, after this patch, we copy all members in InternalTransitionEvent and
InternalAnimationEvent in the copy-constructor of AnimationEventInfo, this
will be fixed once WidgetEvent has move-constructor and move-assignment
(bug 1433008).
MozReview-Commit-ID: 5JAh6N7C6ee
--HG--
extra : rebase_source : 06ef844f41cfe81b9a629340b5a328c1bed80e8e
The implementation of the template function is defined in KeyframeUtils.cpp,
whereas the caller is inside KeyframeEffectReadOnly.cpp. I guess it's been
compiled accidentally because of unified builds.
MozReview-Commit-ID: 9GeIT7nDpLG
--HG--
extra : rebase_source : ce58ac6a013ff45d402c51994eb4f0bc28a2c671
Since the function assumes that both of actual and expected values
have the same precision requirements.
MozReview-Commit-ID: 4C3TAH6mUVg
--HG--
extra : rebase_source : 1e40e489745b0d9047d34e851a5f043db616323e
This assertion is supposed to be used where the first argument has a tolerance
but the second argument doesn't have such tolerance. Whereas
assert_times_equal() is supposed to be used for the case both arguments have
the same tolerance, actually it hasn't, it will be fixed in a subsequent patch
in this patch series.
MozReview-Commit-ID: FEDHilbX2rm
--HG--
extra : rebase_source : e773902b474bd9a411e7bb3f234702a93547ebba
For opacity property, we only generate nsChangeHint_UpdateUsesOpacity,
nsChangeHint_UpdateOpacityLayer and nsChangeHint_RepaintFrame. All of them are
included in nsChangeHint_Hints_CanIgnoreIfNotVisible. So we can throttle
opacity animations on out-of-view elements whatever underlying opacity value is.
MozReview-Commit-ID: FdQJbItAndG
--HG--
extra : rebase_source : d011270e4e3e1adc1782665a592fb3fac60f9174
The animation in the test case is not actually additive animation, it's just a
missing keyframe animation and its composite operation is actually 'replace'.
MozReview-Commit-ID: 4A29V5Ke2hF
--HG--
extra : rebase_source : 63b6c7f52943786d06c52b9baa7e0f4f151781ac
The pref has been enabled by default since firefox 49, so it's not worth
checking the pref in test.
MozReview-Commit-ID: 5ADIFaV1ue
--HG--
extra : rebase_source : 8490cc7988cc1e7fe3a650c4f1334b4ed11c7105
It's already specified to true in test_restyles.html.
MozReview-Commit-ID: JMItunKYwIs
--HG--
extra : rebase_source : d54368a93857d8d2a86220be55091735caa074e9
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
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
Hiroyuki Ikezoe
Cosmin Sabou
Wei-Cheng Pan
Brian Birtles
Tom Ritter
Csoregi Natalia
Hiroyuki Ikezoe
Kartikaya Gupta
Boris Chiou
Emilio Cobos Álvarez
Sebastian Hengst
Mantaroh Yoshinaga
Jonathan Watt
Noemi Erli
Ya-Chieh Wu