So, we don't create a stacking context for this case. Besides, we also
make sure FindAnimationsForCompositor() work properly for motion-path if
offset-path is not effective (i.e. none and no animations).
Differential Revision: https://phabricator.services.mozilla.com/D51895
--HG--
extra : moz-landing-system : lando
I have recently enabled many mochitests on Android, but a few of those tests are
still failing intermittently; let's skip those tests again to avoid the intermittent
failures.
Differential Revision: https://phabricator.services.mozilla.com/D50562
--HG--
extra : moz-landing-system : lando
Most of these tests have been disabled for a long time; they run well
in the current test environment.
I intend to enable still more mochitests in a future patch.
Differential Revision: https://phabricator.services.mozilla.com/D49524
--HG--
extra : moz-landing-system : lando
The original test case doesn't crash reliably but the test case in this commit
crashes 100% locally without this fix.
Differential Revision: https://phabricator.services.mozilla.com/D48009
--HG--
extra : moz-landing-system : lando
We are going to use these functions in gfx/layers/apz/tests/mochitest/ for
fission.
Differential Revision: https://phabricator.services.mozilla.com/D44418
--HG--
extra : moz-landing-system : lando
Seems we'll update the change hint properly via SetTarget if we get a new
target.
Differential Revision: https://phabricator.services.mozilla.com/D43397
--HG--
extra : moz-landing-system : lando
Also waitForAnimationReadyToRestyle should use owner window object instead of
global `window`.
Differential Revision: https://phabricator.services.mozilla.com/D42078
--HG--
extra : moz-landing-system : lando
The animations of motion path are not running on the compositor, and the
properties in [motion-1] is not part of transform-like properties (i.e.
nsCSSProperties::TransformLikeProperties()) for now, so we should run
transform animations on the main thread if offset-path is not `none`.
Differential Revision: https://phabricator.services.mozilla.com/D39966
--HG--
extra : moz-landing-system : lando
This refactors things to run until the animation is unthrottled. It confirms
the proper amount of time has passed; and then awaits another styling to ensure
that markers.length = 0 (unless it took very long (over 200ms) that it should
be 1.
Differential Revision: https://phabricator.services.mozilla.com/D38808
Depends on D38807
--HG--
extra : rebase_source : 1b668b212c788511962d2557d298af990bd430ad
We fix this by clamping the requestAnimationFrame timestamp in the test before comparing it.
We don't clamp the requestAnimationFrame timestamp normally because it would be meaningless:
rAF fires on a regular frequency and someone perfoming a fine-grained timing attack will be
able to determine the timestamp from when it fires.
We need to use parseFloat to knock off any extra epislon we gain.
This shouldn't cause any major blow-ups because timelines are disabled in release and beta,
so at least any potential fallout would be constrained.
Differential Revision: https://phabricator.services.mozilla.com/D38807
Depends on D38806
--HG--
extra : rebase_source : d6f6170ae3082022d422f925e8d5619400e845ed
This refactors things to run until the animation is unthrottled. It confirms
the proper amount of time has passed; and then awaits another styling to ensure
that markers.length = 0 (unless it took very long (over 200ms) that it should
be 1.
Differential Revision: https://phabricator.services.mozilla.com/D38808
--HG--
extra : moz-landing-system : lando
We fix this by clamping the requestAnimationFrame timestamp in the test before comparing it.
We don't clamp the requestAnimationFrame timestamp normally because it would be meaningless:
rAF fires on a regular frequency and someone perfoming a fine-grained timing attack will be
able to determine the timestamp from when it fires.
We need to use parseFloat to knock off any extra epislon we gain.
This shouldn't cause any major blow-ups because timelines are disabled in release and beta,
so at least any potential fallout would be constrained.
Differential Revision: https://phabricator.services.mozilla.com/D38807
--HG--
extra : moz-landing-system : lando
This refactors things to run until the animation is unthrottled. It confirms
the proper amount of time has passed; and then awaits another styling to ensure
that markers.length = 0 (unless it took very long (over 200ms) that it should
be 1.
Differential Revision: https://phabricator.services.mozilla.com/D38808
--HG--
extra : moz-landing-system : lando
We fix this by clamping the requestAnimationFrame timestamp in the test before comparing it.
We don't clamp the requestAnimationFrame timestamp normally because it would be meaningless:
rAF fires on a regular frequency and someone perfoming a fine-grained timing attack will be
able to determine the timestamp from when it fires.
We need to use parseFloat to knock off any extra epislon we gain.
This shouldn't cause any major blow-ups because timelines are disabled in release and beta,
so at least any potential fallout would be constrained.
Differential Revision: https://phabricator.services.mozilla.com/D38807
--HG--
extra : moz-landing-system : lando
We move the check of important rule and animation level into
KeyframeEffect::ShouldBlockAsyncTransformAnimations(), and add a new warning
for it.
Note:
1. ShouldBlockAsyncTransformAnimations() only cares about transforms. And
for other compositor animation properties, we count on
HasEffectiveAnimationOfPropertySet() (in IsMatchForCompositor()).
2. If we check the important rules in both
EffectCompositor::HasAnimationsForCompositor() and
ActiveLayerTracker::IsTransformMaybeAnimated(), we may get the incorrect
animation warnings (i.e. TransformFrameInactive). In most cases, we
check these two functions together, so perhaps move the check of important
rules outside HasEffectiveAnimationOfPropertySet() is fine.
Besides, ActiveLayerTracker just tracks if there is a style change on this
property (or display item) on the active layers, so should be OK to not
check important rules in it.
So IsMatchForCompositor() should check all transform-like properties,
instead of each one, to get the correct result. (That's why we have to
refactor KeyframeEffect::GetPropertiesForCompositor() as well.)
Differential Revision: https://phabricator.services.mozilla.com/D34432
--HG--
extra : moz-landing-system : lando
(The pref is about to be removed, but even before its removal, it defaults to
'true' so these tests don't need to bother setting/checking it.)
Differential Revision: https://phabricator.services.mozilla.com/D33805
--HG--
extra : moz-landing-system : lando
In particular:
- The tests test_disabled_properties.html and
test_animations_with_disabled_properties.html just want to be able to toggle
some pref to turn off some property. So, this patch changes them to use a more
recently-added pref-controlled property (-webkit-line-clamp). (We'll probably
have to update these tests again when we eventually remove the pref for that
property. Oh well.)
- The tests 1265611-1.html and test_transitions_with_disabled_properties.html
are more picky -- they require a pref-controlled property **whose initial value
is 'currentcolor'**. We don't have any such property anymore, once the
layout.css.prefixes.webkit pref is removed. For the crashtest, we might as
well keep the test, with a disclaimer that its tested codepath has changed.
And for the mochitest, we can't really "fix" the test, so let's just remove
it. (We can take some comfort in knowing that the still-present test
'test_animations_with_disabled_properties' is very similar and covers some of
the same codepaths.)
Differential Revision: https://phabricator.services.mozilla.com/D33804
--HG--
extra : moz-landing-system : lando
This is split from the previous changeset since if we include dom/ the file size is too
large for phabricator to handle.
This is an autogenerated commit to handle scripts loading mochitest harness files, in
the simple case where the script src is on the same line as the tag.
This was generated with https://bug1544322.bmoattachments.org/attachment.cgi?id=9058170
using the `--part 2` argument.
Differential Revision: https://phabricator.services.mozilla.com/D27457
--HG--
extra : moz-landing-system : lando
We want to set the performance warning by a property set, so update it.
Besides, add more tests for individual transforms (translate, rotate,
scale).
Differential Revision: https://phabricator.services.mozilla.com/D19633
--HG--
extra : moz-landing-system : lando
We should also throttle other transform-like animations which can run on
the compositor thread, on visibility hidden element without 0% or 100%
keyframe.
Depends on D22568
Differential Revision: https://phabricator.services.mozilla.com/D19634
--HG--
extra : moz-landing-system : lando
This also adds the missing preference in test_transition_per_property.html.
Depends on D22567
Differential Revision: https://phabricator.services.mozilla.com/D22568
--HG--
extra : moz-landing-system : lando
Disabled all instances of test_event_listener_leaks.html scattered across the `dom/` test suite.
There exists a bug, 1530894 to track the failures, which has seen no movement for the 3 weeks it has been on file for.
Differential Revision: https://phabricator.services.mozilla.com/D23755
--HG--
extra : moz-landing-system : lando
There are many bugs regarding our use of EffectSet::GetEffectSet(nsIFrame*)
because the intention of the caller is not clear. If it is called for the
primary frame of display:table content do we expect it to get the EffectSet
associated with the style frame or not? Generally it depends on if we are
looking for transform animations or not.
Rather than inspecting each call site and making it choose the appropriate frame
to use, this patch introduces a new method to EffectSet to get the appropriate
EffectSet based on the properties the caller is interested in.
This patch also uses this function in FindAnimationsForCompositor which in turns
fixes the glitching observed on Tumblr that arose since a number of places in
our display list code were passing the style frame to
EffectCompositor::HasAnimationsForCompositor.
Over the remainder of this patch series we will convert more callers of
EffectSet::GetEffectSet(nsIFrame*) to this new method before renaming
EffectSet::GetEffectSet to GetEffectSetForStyleFrame to make clear how the
method is intended to work.
Differential Revision: https://phabricator.services.mozilla.com/D23282
--HG--
extra : moz-landing-system : lando
There are few things that are either Fennec-specific or don't work
currently under GeckoView w/ e10s under TestRunnerActivity. Disable
these so we can get some testing going in automation.
This also replaces 'isFennec' with the more correct 'is_fennec'.
Differential Revision: https://phabricator.services.mozilla.com/D19016
--HG--
extra : moz-landing-system : lando
A forthcoming spec change will require that Animatable.animate() and other
methods that mutate animations do not flush style:
https://github.com/w3c/csswg-drafts/issues/3613
Bug 1525809 will add web-platform-tests for this change once it is made (and
tweak the behavior introduced in this patch if necessary).
Currently Firefox and WebKit will flush styles when calling
Animatable.animate(). This is undesirable since this method will _also_
invalidate style. As a result, if content triggers multiple animations in
a single animation frame, it will restyle every time it creates an animation.
This patch removes the style flush from a number of these methods.
In general the style flush is not necessary. For example, we don't need to flush
style before getting the computed style to pass to UpdateProperties. That's
because if there are pending style changes, then UpdateProperties will be called
with the updated style once they are applied anyway. Flushing style first means
that we may end up resolving style twice, when once would be sufficient.
For GetKeyframes() however, when used on a CSS animation, it should return
the most up-to-date style so for that call site we *do* want to flush style.
The test case added in this patch will fail without the code changes in the
patch. Specifically, we will observe 10 non-animation restyles (from the
5 animations) if we flush styles from SetKeyframes.
Differential Revision: https://phabricator.services.mozilla.com/D18916
--HG--
extra : moz-landing-system : lando
Tim Nguyen
Boris Chiou
Nicolas Silva
Geoff Brown
Hiroyuki Ikezoe
Adam Gashlin
Mark Banner
Tom Ritter
Emilio Cobos Álvarez
Daniel Varga
Andreea Pavel
Victor Porof
Daniel Holbert
Sebastian Hengst
Brian Birtles
Brian Grinstead
Edwin Gao
James Willcox