The aSamePointerStructs argument is unused now.
Also, aIgnoreVariables can be true everywhere now, since variable changes can't
generate change hints, and anonymous boxes and such don't care about whether
they really changed or not.
Only one caller cares about struct equality, and that already compares variables
manually as an optimization on the rust side.
We had this optimization inconsistently in some cases but not others.
MozReview-Commit-ID: F2EISKlxR3K
It might be possible that the animation does not start being restyled in the
initial frame. Eventually we should drop tweakExpectedRestyleCount in bug
1425778 and replace it with a function that waits for animation.ready and waits
to start being restyled something like this;
async function waitForAnimationReadyToBeRestyled(aAnimation) {
await aAnimation.ready;
if (animationStartsRightNow(aAnimation)) {
await waitForFrame();
}
}
MozReview-Commit-ID: ByN25hMAK76
--HG--
extra : rebase_source : 6dd3a44661905ffff7bce748540572df2d40425b
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
For now, we are going to make _all_ CSS Animations related timer fuzzing
only applicable in Resist Fingerprinting Mode (addressing the last couple
that had not already been configured that way.)
We hardcode their content mix-ins as zero, but leave comments indicating
how they should behave.
MozReview-Commit-ID: KhmV7wO8Pt5
--HG--
extra : rebase_source : 3b087d40b6332d447b442b435ed6fee8993e0145
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 : ff1ccb0ab155ad7e782ecf43f7768ea67f9b9bcf
We rename the file_XXX contents to test_XXX_to_rename so that these tests keep
running (so long as they begin with file_ and not test_ the test harness will
refuse to run them). If we rename these files to test_XXX in the same patch
Mercurial will not treat this as a rename and so we will lose the history
associated with file_XXX.
Instead, we rename test_XXX_to_rename to test_XXX in the next patch in this
series and by doing this Mercurial will treat this as two rename operations and
`hg log -f test_XXX` will show the history file_XXX as well.
One minor exception to this occurs due to the fact that we have two naming
conventions:
(a) For tests in css-animations, css-transitions, style etc.
Most of these tests should eventually land in web-platform-tests. However,
in many cases that's not yet possible because, for example, CSS
Animations 2 does not yet specify the behavior tested by the
css-animations tests.
For tests in web-platform-tests we generally separate words using -.
However, our mochitest running machinery requires that tests begin with
test_. Hence we name tests: test_abc-def-ghi.html.
(b) For tests in mozilla
These tests are never intended to be part of web-platform-tests and
generally for mochitests we use _ to separate words (hence the test_
prefix). Hence we name these tests test_abc_def_ghi.html
Now, there are some tests in the 'mozilla' directory that use the (a) naming
scheme instead of (b). In this case, instead of renaming file_xxx-xxx.html to
test_xxx-xxx_to_rename.html in this patch, and then renaming
test_xxx-xxx_to_rename.html to test_xxx-xxx.html in a second patch, we can just
delete test_xxx-xxx.html and rename file_xxx-xxx.html to test_xxx_xxx.html in
the one patch and Mercurial will recognize this as a rename because the file
names don't overlap.
MozReview-Commit-ID: Etcdmyfx0zf
--HG--
rename : dom/animation/test/css-animations/file_animation-cancel.html => dom/animation/test/css-animations/test_animation-cancel_to_rename.html
rename : dom/animation/test/css-animations/file_animation-computed-timing.html => dom/animation/test/css-animations/test_animation-computed-timing_to_rename.html
rename : dom/animation/test/css-animations/file_animation-currenttime.html => dom/animation/test/css-animations/test_animation-currenttime_to_rename.html
rename : dom/animation/test/css-animations/file_animation-finish.html => dom/animation/test/css-animations/test_animation-finish_to_rename.html
rename : dom/animation/test/css-animations/file_animation-finished.html => dom/animation/test/css-animations/test_animation-finished_to_rename.html
rename : dom/animation/test/css-animations/file_animation-id.html => dom/animation/test/css-animations/test_animation-id_to_rename.html
rename : dom/animation/test/css-animations/file_animation-pausing.html => dom/animation/test/css-animations/test_animation-pausing_to_rename.html
rename : dom/animation/test/css-animations/file_animation-playstate.html => dom/animation/test/css-animations/test_animation-playstate_to_rename.html
rename : dom/animation/test/css-animations/file_animation-ready.html => dom/animation/test/css-animations/test_animation-ready_to_rename.html
rename : dom/animation/test/css-animations/file_animation-reverse.html => dom/animation/test/css-animations/test_animation-reverse_to_rename.html
rename : dom/animation/test/css-animations/file_animation-starttime.html => dom/animation/test/css-animations/test_animation-starttime_to_rename.html
rename : dom/animation/test/css-animations/file_animations-dynamic-changes.html => dom/animation/test/css-animations/test_animations-dynamic-changes_to_rename.html
rename : dom/animation/test/css-animations/file_cssanimation-animationname.html => dom/animation/test/css-animations/test_cssanimation-animationname_to_rename.html
rename : dom/animation/test/css-animations/file_document-get-animations.html => dom/animation/test/css-animations/test_document-get-animations_to_rename.html
rename : dom/animation/test/css-animations/file_effect-target.html => dom/animation/test/css-animations/test_effect-target_to_rename.html
rename : dom/animation/test/css-animations/file_element-get-animations.html => dom/animation/test/css-animations/test_element-get-animations_to_rename.html
rename : dom/animation/test/css-animations/file_event-dispatch.html => dom/animation/test/css-animations/test_event-dispatch_to_rename.html
rename : dom/animation/test/css-animations/file_event-order.html => dom/animation/test/css-animations/test_event-order_to_rename.html
rename : dom/animation/test/css-animations/file_keyframeeffect-getkeyframes.html => dom/animation/test/css-animations/test_keyframeeffect-getkeyframes_to_rename.html
rename : dom/animation/test/css-animations/file_pseudoElement-get-animations.html => dom/animation/test/css-animations/test_pseudoElement-get-animations_to_rename.html
rename : dom/animation/test/css-animations/file_setting-effect.html => dom/animation/test/css-animations/test_setting-effect_to_rename.html
rename : dom/animation/test/css-transitions/file_animation-cancel.html => dom/animation/test/css-transitions/test_animation-cancel_to_rename.html
rename : dom/animation/test/css-transitions/file_animation-computed-timing.html => dom/animation/test/css-transitions/test_animation-computed-timing_to_rename.html
rename : dom/animation/test/css-transitions/file_animation-currenttime.html => dom/animation/test/css-transitions/test_animation-currenttime_to_rename.html
rename : dom/animation/test/css-transitions/file_animation-finished.html => dom/animation/test/css-transitions/test_animation-finished_to_rename.html
rename : dom/animation/test/css-transitions/file_animation-pausing.html => dom/animation/test/css-transitions/test_animation-pausing_to_rename.html
rename : dom/animation/test/css-transitions/file_animation-ready.html => dom/animation/test/css-transitions/test_animation-ready_to_rename.html
rename : dom/animation/test/css-transitions/file_animation-starttime.html => dom/animation/test/css-transitions/test_animation-starttime_to_rename.html
rename : dom/animation/test/css-transitions/file_csstransition-transitionproperty.html => dom/animation/test/css-transitions/test_csstransition-transitionproperty_to_rename.html
rename : dom/animation/test/css-transitions/file_document-get-animations.html => dom/animation/test/css-transitions/test_document-get-animations_to_rename.html
rename : dom/animation/test/css-transitions/file_effect-target.html => dom/animation/test/css-transitions/test_effect-target_to_rename.html
rename : dom/animation/test/css-transitions/file_element-get-animations.html => dom/animation/test/css-transitions/test_element-get-animations_to_rename.html
rename : dom/animation/test/css-transitions/file_event-dispatch.html => dom/animation/test/css-transitions/test_event-dispatch_to_rename.html
rename : dom/animation/test/css-transitions/file_keyframeeffect-getkeyframes.html => dom/animation/test/css-transitions/test_keyframeeffect-getkeyframes_to_rename.html
rename : dom/animation/test/css-transitions/file_pseudoElement-get-animations.html => dom/animation/test/css-transitions/test_pseudoElement-get-animations_to_rename.html
rename : dom/animation/test/css-transitions/file_setting-effect.html => dom/animation/test/css-transitions/test_setting-effect_to_rename.html
rename : dom/animation/test/document-timeline/file_document-timeline.html => dom/animation/test/document-timeline/test_document-timeline_to_rename.html
rename : dom/animation/test/mozilla/file_cubic_bezier_limits.html => dom/animation/test/mozilla/test_cubic_bezier_limits_to_rename.html
rename : dom/animation/test/mozilla/file_disabled_properties.html => dom/animation/test/mozilla/test_disabled_properties_to_rename.html
rename : dom/animation/test/mozilla/file_document-timeline-origin-time-range.html => dom/animation/test/mozilla/test_document_timeline_origin_time_range.html
rename : dom/animation/test/mozilla/file_hide_and_show.html => dom/animation/test/mozilla/test_hide_and_show_to_rename.html
rename : dom/animation/test/mozilla/file_restyling_xhr_doc.html => dom/animation/test/mozilla/test_restyling_xhr_doc_to_rename.html
rename : dom/animation/test/mozilla/file_set-easing.html => dom/animation/test/mozilla/test_set_easing.html
rename : dom/animation/test/mozilla/file_transform_limits.html => dom/animation/test/mozilla/test_transform_limits_to_rename.html
rename : dom/animation/test/mozilla/file_underlying-discrete-value.html => dom/animation/test/mozilla/test_underlying_discrete_value.html
rename : dom/animation/test/style/file_animation-seeking-with-current-time.html => dom/animation/test/style/test_animation-seeking-with-current-time_to_rename.html
rename : dom/animation/test/style/file_animation-seeking-with-start-time.html => dom/animation/test/style/test_animation-seeking-with-start-time_to_rename.html
rename : dom/animation/test/style/file_animation-setting-effect.html => dom/animation/test/style/test_animation-setting-effect_to_rename.html
rename : dom/animation/test/style/file_composite.html => dom/animation/test/style/test_composite_to_rename.html
rename : dom/animation/test/style/file_missing-keyframe-on-compositor.html => dom/animation/test/style/test_missing-keyframe-on-compositor_to_rename.html
rename : dom/animation/test/style/file_missing-keyframe.html => dom/animation/test/style/test_missing-keyframe_to_rename.html
(This is a helper patch -- I'm splitting this into its own patch since it's
changing files in other directories, and also so that the main patches here
can be a bit more direct.)
Without this change, the other patches in this series would cause compile
failures in the headers that I'm fixing up here (because the other patches will
be removing #includes from some headers that these files were inadvertently
depending on).
As of this patch, ComputedTimingFunction.h will now be including:
- nsDebug.h to provide NS_ASSERTION
- nsStringFwd.h to provide a forward-declaration for "nsAString&"
- Assertions.h to provide MOZ_ASSERT
- Maybe.h to provide Maybe<ComputedTimingFunction>
(I think it's been leaning on nsTimingFunction.h's include of nsString.h to
indirectly provide these.)
FrameMetrics.h will now be including:
- PLDHashTable.h to provide PLDHashNumber
(I think it's been leaning on nsStyleCoord.h/nsStyleConsts.h to indirectly
provide this.)
MozReview-Commit-ID: AoFoEe9GisK
--HG--
extra : rebase_source : 63c69343acaf42511ebdeb0238f4385a0c6345a5
If the element has throttled animations that will be affected by pending style
changes, the throttled animations will be updated though sequential tasks after
normal styling process. E.g. UpdateEffectProperties, UpdateCascadeResults etc.
So we don't need to flush them in advance of the sequential tasks.
The first test case in this patch fails without this fix.
MozReview-Commit-ID: GystAqK2bQE
--HG--
extra : rebase_source : c01160e14bb5a2984dcc4d63ec44d4d465b829a2
In the subsequent patch, we want to observe animation restyles caused by
synchronous styling. If we used the original asynchronous observer for that,
we will observe restyles in normal scheduled styling, it's bit confusing.
MozReview-Commit-ID: 1V2IavKNECG
--HG--
extra : rebase_source : ee112acf2426ecf54435f77b8801a6228318459c
Transform animation in out-of-view element might move in visible area so if we
throttle it the transform animation might come in view suddenly. So we don't
throttle transform animations in ouf-of-view element anymore if it's not
infinite. Finite animations don't last so that they won't consume CPU so much
time.
MozReview-Commit-ID: HaMjmxqXPIK
--HG--
extra : rebase_source : 1c008e4e435bcc9c1ad8fcc84667080247c0b161
So that we don't need to include nsStyleStruct.h in gfx any more.
MozReview-Commit-ID: 6nOaAbssLCz
--HG--
extra : rebase_source : 9c195c90277a4584dc14a6949e9eea53bcd8487c
Now the test works fine with the new microtask handling.
MozReview-Commit-ID: EhFcN2XAClw
--HG--
extra : rebase_source : f1066bf09df07c1bcbfe5dc5dcc59596530424d0
Because the scrollable parent might be transformed by its ancestors.
MozReview-Commit-ID: FuCPLg54z7h
--HG--
extra : rebase_source : 7c11c5384d2aed6c663b915fcacae7c627052a43
Everyone calls them with the shell of the current composed document, and this
allows the multi-presShell stuff to just be in UpdateCurrentStyleSources /
DoGetStyleContextNoFlush.
The only reason we need to use OwnerDoc()->GetShell() instead of the composed
doc in GetStyleContext / GetStyleContextNoFlush is Element::GetBindingURL, which
does expect to get the binding URL for stuff outside of the composed doc (and
changing that gave me a useless browser).
That's technically a behavior change on the cases that used to pass nullptr, but
I think all callers are fine with that. I could also just add a special function
for that particular case, it may be worth it.
MozReview-Commit-ID: 2XlnkgdgDCK
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
