Currently CSS Animations are exempted from Reduce Timer Precision, so this isn't needed.
Additionally, when we test by overriding that restriction, these tests aren't run, which
leads to confusion.
MozReview-Commit-ID: Gv6T3oGO475
--HG--
extra : rebase_source : 6bd70341fe5d047b685cae0db2965bf86116b4a0
Calling RequestRestyle() for update cascade results is weird since in general
RequestRestyle() is a result of updating cascade results (e.g. when an
!important style is changed). In the case where we already know that we need
to update cascade results we can do it right after all the other processes that
may need to update cascade results has done so that we don't need to worry about
the cases additional cascade results update happens.
MozReview-Commit-ID: 6lh0NgTPF9j
--HG--
extra : rebase_source : 4dbec85f55a14776907b677f2876421abc141384
We will call the function directly in a sequential task in the case where we
already detected that !important styles for animations has been changed in
parallel traversal.
MozReview-Commit-ID: 7j6CfONYD08
--HG--
extra : rebase_source : 5ac29124cefbc8e57231d0acb9b1749b2c9587c0
It would be convenient to get nsPresContext from nsIDocument.
MozReview-Commit-ID: Ei6V3UE8XGr
--HG--
extra : rebase_source : 8d2a917eb62cf341e4e1810451fd01c01dbc3bad
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.
We will use this to calculate the unconstrained current time when we implement
pending playback rate changes.
MozReview-Commit-ID: 7GlmHiGeXF6
--HG--
extra : rebase_source : 32c0c4d86293bf11220017fa1b126ae239b0301d
We will re-use these methods to perform various calculations once we introduce
the pending playback rate.
MozReview-Commit-ID: 2HV44TTNxHg
--HG--
extra : rebase_source : 19e32b13c6fee9cfe9993918557f2433aa687e11
This is the IDL added to the Web Animations specification:
5af5e276ba
Note that some of the changes in the above commit were reverted in the following
commit:
673f6fc126
A folded version of the changes:
https://gist.github.com/birtles/d147eb2e0e2d4d37fadf217abd709411
MozReview-Commit-ID: CJV7bzizXg4
--HG--
extra : rebase_source : 3b168e779883ba91c8f572478185b55013952d1a
We will use this to calculate the unconstrained current time when we implement
pending playback rate changes.
MozReview-Commit-ID: 7GlmHiGeXF6
--HG--
extra : rebase_source : 82280cdd62c0426c114ce54bb92fcd7ed766d85a
We will re-use these methods to perform various calculations once we introduce
the pending playback rate.
MozReview-Commit-ID: 2HV44TTNxHg
--HG--
extra : rebase_source : dcc883fb6db897a799900d709ca9c182dc149764
This is the IDL added to the Web Animations specification:
5af5e276ba
Note that some of the changes in the above commit were reverted in the following
commit:
673f6fc126
A folded version of the changes:
https://gist.github.com/birtles/d147eb2e0e2d4d37fadf217abd709411
MozReview-Commit-ID: CJV7bzizXg4
--HG--
extra : rebase_source : 6dc6819e158bcdd094962769096a17da6cd2026a
In the case where we throttle transform animations in visibility:hidden
element, we just need to unthrottle only if the element is scrolled out since
unlike the scrolled out element, visibility:hidden element keeps invisible
even after the element moved into view.
MozReview-Commit-ID: 7X2SsOLz4Y5
--HG--
extra : rebase_source : ca7210f7ed637f858127c4008fe98fbeec874a10
This patch does basically throttle animations on visibility:hidden element
and unthrottle it once the animating element became visible or a child of the
animating element became visible. But still there are some cases that we don't
throttle such animations perfectly. For example;
div.style.visibility = 'hidden'; // the 'div' has no children at this moment
div.animate(..);
// The animation is throttled
div.appendChild(visibleChild);
// The animation isn't throttled
visibleChild.style.visibility = 'hidden';
// Now the animation should be throttled again, but actually it's not.
To throttle this case properly, when the |visibleChild|'s visibility changed
to hidden, we would need to do either
1) Check all siblings of the |visibleChild| have no visible children
or
2) The parent element stores visible children count somewhere and decrease it
and check whether the count is zero
To achieve 1) we need to walk up ancestors and their siblings, actually it's
inefficient.
2) is somewhat similar to what we already do for animating images but it's hard
to reuse it for CSS animations since it does not take into account that
descendants' visibilities.
Another example that this patch does not optimize is the the case where
animating element has children whose visibility is inherited and the element
itself initially visible something like this;
let child = document.createElement('div'); // child visibility is 'inherit'
div.appendChild(child);
div.animate(..); // the 'div' is visible
// The animation isn't throttled since the animating element is visible
div.style.visiblily = 'hidden';
// Now the animation should be throttled, but it's not since this patch does
// not descend down all descendants to check they are invisible or not when the
// animating element visibility changed to hidden.
This patch adds a test case for this case introduced with todo_is().
Another test case added in this patch fails if we don't use
nsPlaceholderFrame::GetRealFrameFor() in HasNoVisibleDescendants().
MozReview-Commit-ID: BJwzQvP9Yc4
--HG--
extra : rebase_source : e56505706bb2799b59bbfb3bbcce4a9ce86892f4
This new change hint doesn't influence layout so that it can be regarded
as nsChangeHint_Hints_CanIgnoreIfNotVisible. Note that if visibility changed
from collapse or to collapse, we set NS_STYLE_HINT_REFLOW separetely.
MozReview-Commit-ID: AirDWeBYVKG
--HG--
extra : rebase_source : a462845ac2d8280986bb8db5e6482bf401f65322
There are a few different reasons why tests needed updating (not an exhaustive list):
- Tests assume that successive operations take place at different times.
- Tests assume that an operation took a minimum amount of time.
- Tests hardcodes a specific delay.
In most cases we hardcode the preference off. In some cases this is the best approach,
in others, we would like to improve. The bug for tracking those improvements is Bug 1429648
An improvement that is present in some tests is to hardcode a specific precision reduction
that is acceptable based on the confides of the test. (Obviously this needs to be a fix for
the test framework and not a requirement on the feature being tested.)
In a few places, the test itself can be fixed, for example to no longer require the end
time of an operation to be strictly greater than the start time, and allows it to be equal
to it.
MozReview-Commit-ID: J59c7xQtZZJ
--HG--
extra : rebase_source : df8a03e76eaf9cdc9524dbb3eb9035af237e534b
This patch creates the capability to have callsites specify if timestamps
should be clamped only in Resist Fingerprinting Mode, or in the more expansive
Timer PRecision Reduction Mode.
Then it changes the CSS Animation callsite to only apply in RFP Mode.
This avoids regressing RFP.
MozReview-Commit-ID: B1pSri0kRk6
--HG--
extra : rebase_source : f3d8c1f9561fbb19d1ca8594ba2b69cffd25445b
The original value were too small for Android.
MozReview-Commit-ID: 4V6qC8orYNJ
--HG--
extra : rebase_source : 55ea0525bfaafa60d8e5d711cc70dd29d21acc78
In this test we need to know precise time for checking that we unthrottle
throttled transform animations periodically.
MozReview-Commit-ID: ICLf448KFLr
--HG--
extra : rebase_source : 26128735231679031bd1e727cf9d9016054e7664
This patch creates the capability to have callsites specify if timestamps
should be clamped only in Resist Fingerprinting Mode, or in the more expansive
Timer PRecision Reduction Mode.
Then it changes the CSS Animation callsite to only apply in RFP Mode.
This avoids regressing RFP.
MozReview-Commit-ID: B1pSri0kRk6
--HG--
extra : rebase_source : 5c1a3a1bb7cb10cd5c4a608f30bf097bd7e119b9
This patch does basically throttle animations on visibility:hidden element
and unthrottle it once the animating element became visible or a child of the
animating element became visible. But still there are some cases that we don't
throttle such animations perfectly. For example;
div.style.visibility = 'hidden'; // the 'div' has no children at this moment
div.animate(..);
// The animation is throttled
div.appendChild(visibleChild);
// The animation isn't throttled
visibleChild.style.visibility = 'hidden';
// Now the animation should be throttled again, but actually it's not.
To throttle this case properly, when the |visibleChild|'s visibility changed
to hidden, we would need to do either
1) Check all siblings of the |visibleChild| have no visible children
or
2) The parent element stores visible children count somewhere and decrease it
and check whether the count is zero
To achieve 1) we need to walk up ancestors and their siblings, actually it's
inefficient.
2) is somewhat similar to what we already do for animating images but it's hard
to reuse it for CSS animations since it does not take into account that
descendants' visibilities.
Another example that this patch does not optimize is the the case where
animating element has children whose visibility is inherited and the element
itself initially visible something like this;
let child = document.createElement('div'); // child visibility is 'inherit'
div.appendChild(child);
div.animate(..); // the 'div' is visible
// The animation isn't throttled since the animating element is visible
div.style.visiblily = 'hidden';
// Now the animation should be throttled, but it's not since this patch does
// not descend down all descendants to check they are invisible or not when the
// animating element visibility changed to hidden.
This patch adds a test case for this case introduced with todo_is().
Another test case added in this patch fails if we don't use
nsPlaceholderFrame::GetRealFrameFor() in HasNoVisibleDescendants().
MozReview-Commit-ID: BJwzQvP9Yc4
--HG--
extra : rebase_source : ceb95bdce1042cbfc16751d6d023fc6feee5845e
This new change hint doesn't influence layout so that it can be regarded
as nsChangeHint_Hints_CanIgnoreIfNotVisible. Note that if visibility changed
from collapse or to collapse, we set NS_STYLE_HINT_REFLOW separetely.
MozReview-Commit-ID: AirDWeBYVKG
--HG--
extra : rebase_source : 1cd03a78a522b1a6965ba73ebf002ddacb0ab4f2
Since we do not support async-transform for individual-transform yet.
MozReview-Commit-ID: gfOzHpjOnQ
(grafted from dd508458f70d5473256a4bfe5a2f6bc665bbac9d)
--HG--
extra : source : dd508458f70d5473256a4bfe5a2f6bc665bbac9d
And disallow using copy constructor and copy assignment for the structs.
MozReview-Commit-ID: 7jSktlu1SqN
--HG--
extra : rebase_source : cc8bcb1f95843a2a46a044e226c299a6196ef2a2
tweakExpectedRestyleCount() is supposed to work with observeStyle() which is
called right after tweakExpectedRestyleCount(). That's because
tweakExpectedRestyleCount() adjusts the expected restyle count which will
happen in continuous frames that begins from the startsRightNow() call,
especially a redundant restyle might be observed in the last frame if the
animation did not begin at the current timeline time and if the Promise inside
the last requestAnimationFrame is fulfilled after restyling happened.
Instead of using tweakExpectedRestyleCount(), we need to check whether the
animation begun at the current timeline time when the animation started, and if
the animation begun at the current timeline time, we don't observe the
superfluous restyle in a frame after the animation element was re-attached.
MozReview-Commit-ID: 6TLQERSSbjU
--HG--
extra : rebase_source : 1a1dcb56b889bebedb44346bbc315ec01870cf79
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
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
We are going to use SimpleTest.js in the sub window.
MozReview-Commit-ID: HAAMnY7xDNn
--HG--
extra : rebase_source : 3600376a992abf5e1e55baba99bff1a656afdaa6
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
This was automatically generated by the script modeline.py.
MozReview-Commit-ID: BgulzkGteAL
--HG--
extra : rebase_source : a4b9d16a4c06c4e85d7d85f485221b1e4ebdfede
Before this patch, we had been checking each scrollable ancestor is scrolled
out of its scrollable ancestor. So if the target animating frame is at the
bottom of its scrollable parent and if half of the scrollable parent is
scrolled out of its ancestor, the animating frame was considered as 'in-view'.
MozReview-Commit-ID: BDueuF3cT4I
--HG--
extra : rebase_source : de1dead6e67a44691887c8364be23734c3b1adef
When we receive animations on the compositor, we assert that either they're not
playing, or they have a resolved start and origin time.
However, on the main thread we determine if an animation is playing by checking
if it has a timeline, if it's in the correct state, and if it has a non-zero
playback rate.
The problem with this check is that if an animation has a timeline but it is
inactive, that is, its current time is null, we will not be able to get
a resolved origin time -- yet we will still report that is is playing.
This patch fixes this mismatch by treating animations with an inactive timeline
as "not playing".
The IsPlaying() method is used a number of call sites but it appears that they
all would expect an animation with an inactive timeline to be considered "not
playing". Furthermore, this makes IsPlaying() consistent with the check we do
for an active timeline in other functions such as Animation::Tick(),
TriggerNow(), SilentlySetCurrentTime(), UpdateFinishedState(),
and IsPossibleOrphanedPendingAnimation().
MozReview-Commit-ID: BQOBpHHFMoD
--HG--
extra : rebase_source : e84a50a16a61d48553610cb7ea0863f09ba86c60
This fixes multiple things:
* EffectCompositor was using the light tree instead of the flat tree.
* When we insert an element inside the document, we may not style it right away
(we mark it for lazy frame construction with the NODE_NEEDS_FRAME). Since we
trigger animations and transitions from the traversal, we can't skip flushing
if we call getComputedStyle on any of those.
MozReview-Commit-ID: DpAhmLH3uJ2
There are no reliable steps to make this happen but it appears to have happened
at least twice during fuzzing. As a result, it doesn't matter too much what the
behavior here is as long as we don't crash.
MozReview-Commit-ID: 4gdiBL2wngU
--HG--
extra : rebase_source : 54afce721f8b59c2ad038e0c2222f64e71a9b917
2017-10-25 15:34:50 +09:00
Matt Woodrow ext:(%2C%20Miko%20Mynttinen%20%3Cmikokm%40gmail.com%3E%2C%20Timothy%20Nikkel%20%3Ctnikkel%40gmail.com%3E)
This implements the changes specified in these three spec changesets:
8efd180bd9f43ecdfbe5a4f1ad1a60
MozReview-Commit-ID: KFhgZ5ip6BA
--HG--
extra : rebase_source : aa18f8e3fbcd5d96194ff9a5239a3c415622dc2f
This implements the following change to the Web Animations specification:
19b6c33cee
The background to that change is described in the corresponding spec issue:
https://github.com/w3c/web-animations/issues/201
MozReview-Commit-ID: GGA64LG5vT
--HG--
extra : rebase_source : 92c2a60a250071926c2c998dbfadc5979b89cc0c
We could handle this case by dropping the animation from the pause-pending table
but that's an extra hashtable lookup that so far seems to be unnecessary.
I have verified that the crashtest added in this patch fails without the code
changes included here.
MozReview-Commit-ID: Ed6u7WRLD2t
--HG--
extra : rebase_source : 8b175ef2d06b4394f3c51f740a1d305aeea9ed04
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
When we set the playback rate to zero on a play-pending animation that is
resuming from an aborted pause we can arrive in a state where both the start
time and hold time are resolved. However, we previously added an assertion that
only one of these is ever set at a time.
Part of the assertion is warranted since that method contains the following
code:
if (mStartTime.IsNull()) {
mStartTime = StartTimeFromReadyTime(aReadyTime);
if (mPlaybackRate != 0) {
mHoldTime.SetNull();
}
}
Here StartTimeFromReadyTime requires a non-null hold time. So either mStartTime
or mHoldTime needs to be non-null. The requirement that only one or the other be
non-null, however, is not in the spec and not necessary (as the test cases in
this bug show).
What this assertion does bring to light, however, is that in the case where we
have *both* the start time and the hold time, we need to consider whether to use
the start time as-is, or calculate it from the hold time.
I have filed the following spec issue for this:
https://github.com/w3c/web-animations/issues/200
MozReview-Commit-ID: CTCT7Up1E5n
--HG--
extra : rebase_source : 95233f7cd2bc3c4bcc56615d8387fe54852986c1
As required by the recent spec change:
d696468777
MozReview-Commit-ID: Ev6kUk1uLAY
--HG--
extra : rebase_source : 70f8ca3143a8b3bb4e03016b9989925d5a328049
nsFrame::SchedulePaint() invokes InvalidateRenderingObservers, and
InvalidateRenderingObservers ends up posting change hints during we are
processing sequential tasks for animations, but we don't allow posting any
change hints while we are in the middle of restyling process.
Though the change hints posted by InvalidateRenderingObservers are not harmful
in this case since the change hints will be processed in a second post
traversal without problems. That's said, InvalidateRenderingObservers stuff
should be processed in display list based invalidation anyway (bug 1284053).
MozReview-Commit-ID: GKVRZ98lvEN
Otherwise, if getKeyframes() returns an empty array, we don't check each keyframes
at all.
MozReview-Commit-ID: LSBIgetZq2G
--HG--
extra : rebase_source : cc24d093a1e0c9223ac696e44d297602016189a2
Skips flushing current document if the target of getComputedDOMStyle cannot be
affected by any pending restyles.
MozReview-Commit-ID: C87HDIDvOth
--HG--
extra : rebase_source : 064880493f9aac2599689cdd0749200bb579c60b
If we don't increment the reference count for the Atom in servo side, it's
possible to try to release the Atom in servo side even if we have already
released in gecko side. When it happens, nsIAtom::mKind is no longer reliable.
MozReview-Commit-ID: GrxbcYxowRB
--HG--
extra : rebase_source : 94e054e3357b31e398e8e5e81522dab3019c561c
The SchedulePaint() ends up calling
nsSVGEffects::InvalidateDirectRenderingObservers, it doesn't need for retained
display list, and causes harmful restyle events for stylo.
We will call ScheulePaint without involing InvalidateDirectRenderingObservers
later in another bug.
MozReview-Commit-ID: 10V9JLHZmCs
--HG--
extra : rebase_source : 664718eb91e973a4619847e4bfa94327e410f364
The overall progress is factored in iteration start, so even if
TimingParams.mIterations is less than UINT64_MAX, it will exceed UINT64_MAX.
MozReview-Commit-ID: CEOYAGsCoIE
--HG--
extra : rebase_source : 54ed450ebd0218ee2cac9f27125601c6575ee1a5
Because our ComputedTiming.mCurrentIteration is uint64_t.
MozReview-Commit-ID: FjbhEvTUMr4
--HG--
extra : rebase_source : d8ba72c914aac6661f0a5a21885505f94844ce38
When an animation is newly created while the same property transition is
running, the transition style rule persists until we call RequestRestyle() for
transitions level. That means if user calls getComputedStyle for the property
right after creating animation, the style obtained by getComputedStyle still
included the transitions level rule. As a result, the transitions level style
overrides newly created animation style until the next normal restyling process
happens (i.e. process transition level restyle request). Vice versa, in the
case where an animation is removed, transitions level style does not appear
until the next normal restyling.
This patch fixes this problem by trigerring a resyle of the transitions level
when an animation is created or removed.
MozReview-Commit-ID: HY6amLmDHTi
--HG--
extra : rebase_source : 67e58dc9a6c695299c3eef684bf7357153c5168b
Automation also uses env vars to change the Stylo mode, so reading the pref is
not enough. Change the test to `isStyledByServo` which covers all cases.
MozReview-Commit-ID: KLh42b4roF4
--HG--
extra : rebase_source : f77e78694d00489d4e5c7d7f4eaffca0610f128a
Replace it with NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION, because it
has been the same for a while.
MozReview-Commit-ID: 5agRGFyUry1
--HG--
extra : rebase_source : 5388c56b2f6905c6ef969150f0c5b77bf247624d
This test called waitForPaints() after creating an animation, but waitForPaints()
didn't wait for a MozAfterPaint event actually since
DOMWindowUtils.IsMozAfterPaintPending which is checked a MozAfterPaint event has
been queued return false[1]. (i.e. This test didn't wait for a MozAfterPaint)
This is related to bug 1341294. If gecko can receive a MozAfterPaint
corresponded to own paint, waitForPaint() does not need to check for
DOMWindowUtils.IsMozAfterPaintPending.
This patch is a workaround until bug 1341294 is resolved.
[1] http://searchfox.org/mozilla-central/rev/5696c3e525fc8222674eed6a562f5fcbe804c4c7/testing/mochitest/tests/SimpleTest/paint_listener.js#60
MozReview-Commit-ID: 6Rnv8MBP6Se
--HG--
extra : rebase_source : 052f62b01df819961040f6652954e1068f86fc47
Adopt from Tor #16337.
This patch makes Animation API to report a rounded time when 'privacy.resistFingerprinting'
is true. The Animation API uses AnimationUtils::TimeDurationToDouble() to convert
its time duration into a double value and reports it when someone tries to query
time through Animation API. So, we use nsRFPService::ReduceTimePrecisionAsMSecs()
inside this method to round the time in the scope of the millisecond.
MozReview-Commit-ID: 8o01G6AlAu9
--HG--
extra : rebase_source : e2d52f04c1d63accb786f6cf9b1a102607eed517
We should not be declaring forward declarations for nsString classes directly,
instead we should use nsStringFwd.h. This will make changing the underlying
types easier.
--HG--
extra : rebase_source : b2c7554e8632f078167ff2f609392e63a136c299
This is a temporary step until we implement bug 1391537. It is needed to
maintain consistent behavior with Gecko and provide sensible output,
particularly in the case where we have longhands whose values are drawn from
unparsed shorthands.
MozReview-Commit-ID: 9aD2tsLagBp
--HG--
extra : rebase_source : cdabb26be17b96a574ea8b2e8093e11abb1af430
calc() serialization in stylo changed to align to the spec more closely (modulo percentage order).
See the linked issue.
MozReview-Commit-ID: GyzZvdumMSe
In Servo, the max value for 'translate' is different from normal float since
is using Au ( AppUnit ). The value which we introduced as MAX_AU_PX
( 1.78957e+7 ) in this test is calculated by following mechanis.
1. Like this time, if the value is larger than max float, stored into specified
value as infinity by parsing.
2. Then, when converts to the computed value Au from the specified value
(infinity), ABSOLUTE_LENGTH_MAX (1 << 30) = 1073741824 stores into the Au.
[1]
3. Finally, when get the PX value, returns the value which devided by
AU_PER_PX ( 60 ). This value is 1.78957e+7.
[1] to_au_round() method
https://searchfox.org/mozilla-central/source/servo/components/style/values/specified/length.rs#249
MozReview-Commit-ID: BVfDhOKXaWw
--HG--
extra : rebase_source : e55be1f42d9198c35bb8f29882ff19ec9de8f2fa
The serialization of the value in getKeyframes() on both Gecko and Servo is
different, especially 'initial', 'inherit' and 'unset' on discrete animation.
Gecko returns those value as is, but Servo returns computed value.
We are understanding computed value (Servo) is right, so we change expected
values for them. Also, we skip them if this test is running on Gecko.
MozReview-Commit-ID: 4GFpCpec0eP
--HG--
extra : rebase_source : 8bb9fc670fb7ffd56935cdfb4f038be334782de7
Since we made -moz-appearance animatable, append to the moz prefixed properties
test.
MozReview-Commit-ID: 9tdouU1umEB
--HG--
extra : rebase_source : 79e9639360461452249ce54ff538294f25b6cd4f
From the official link for -moz-force-broken-image:
A value of 1 means that the broken image icon is even shown if the image has
an alt attribute. A value of 0 only displays the alt attribute.
It's really ambiguous how we handle other values. Actually stylo's parser
rejects other values. We should use the valid values for this test.
MozReview-Commit-ID: CzmIvsmauke
--HG--
extra : rebase_source : a6387e07b3578cf811bd17f772d791ec73bfa1e7
Unlike Gecko, Stylo currently invokes a needless RequestRestyle(Standard)
for this test case (bug 1388560). For this reason, the check right after
re-attaching the orphaned element passes accidentally.
MozReview-Commit-ID: JUG1dgMUQEX
--HG--
extra : rebase_source : a86d72a41c160edc30f83d82179ebe1226b842de
Actually we have a chance to run styling process when we attach an orphaned
element to a document in this test setup. Precisely, we can process a restyle
between rAF callbacks and Promise.then() callback for waitForAnimationFrames().
So if we call RequestRestyle(Layer) when we attach the element to the document
(bug 1388557), the animation starts restyling in the first frame. *BUT* this
behavior will also change once our micro tasks handling becomes the HTML spec
compliance (bug 1193394). When the micro tasks handling changes, we should also
fix a bunch of test cases and test utilities in bug 1388557.
MozReview-Commit-ID: GyH1ofGhXOP
--HG--
extra : rebase_source : 3536c315960150960fd43286b205c03c584d53ca
DOMWindowUtils.isStyledByServo checks not only the preference value but also
STYLO_FORCE_ENABLED value. This is important especially when we run test on
our CI. On our CI, the preference value is false but just STYLO_FORCE_ENABLED
is set.
MozReview-Commit-ID: FKEd5LFwcxf
--HG--
extra : rebase_source : 1ffd8a68a8339babed14f441bf2d69c9ffd9e3ee
It has been able to pass on stylo since bug 1376248.
MozReview-Commit-ID: 142ptKlqrHe
--HG--
extra : rebase_source : 3bb601122b1593d87a520d3585cc84c0868d6ac8
This removes about 2/3 of the occurrences of nsXPIDLString in the tree. The
places where nsXPIDLStrings are null-checked are replaced with |rv| checks.
The patch also removes a couple of unused declarations from
nsIStringBundle.idl.
Note that nsStringBundle::GetStringFromNameHelper() was merged into
GetStringFromName(), because they both would have had the same signature.
--HG--
extra : rebase_source : ac40bc31c2a4997f2db0bd5069cc008757a2df6d
Current Gecko does not need this (see bug 1367975 comment 10 for the reason),
but this is the right thing to do for our animation styling machinery
especially for updating animations on the compositor.
MozReview-Commit-ID: H6mgTXMHecG
--HG--
extra : rebase_source : ef2e5127a5c56008771a434cc5c342ebeca1b7be
Tom Ritter
Hiroyuki Ikezoe
Tooru Fujisawa
Brian Birtles
arthur.iakab
Csoregi Natalia
Narcis Beleuzu
Boris Zbarsky
Cameron McCormack
cku
Cosmin Sabou
Wei-Cheng Pan
Hiroyuki Ikezoe
Kartikaya Gupta
Boris Chiou
Emilio Cobos Álvarez
Sebastian Hengst
Mantaroh Yoshinaga
Jonathan Watt
Noemi Erli
Ya-Chieh Wu
Joel Maher
Jan de Mooij
Nika Layzell
Zibi Braniecki
Andrew McCreight
Matt Woodrow ext:(%2C%20Miko%20Mynttinen%20%3Cmikokm%40gmail.com%3E%2C%20Timothy%20Nikkel%20%3Ctnikkel%40gmail.com%3E)
Nicholas Nethercote
J. Ryan Stinnett
Tim Huang
Eric Rahm
Daisuke Akatsuka
Brad Werth
Xidorn Quan