We hook the rule into cascade data, and so we can look it up by timeline
name. Now we only use StyleScrollDirection from @scroll-timeline rule.
`source` and `scroll-offsets` are skipped now and use the default values
instead because I'm pretty sure the syntax will be changed in Bug 1733260,
and `scroll-offsets` may be obsolete because the spec proposal intents to
make it be always 0% ~ 100%.
Also, add some reftests for the default `source` and `scroll-offsets`,
and different `orientation`s.
Besides, we disable at-scroll-timeline-start-end.html in Gecko because
we don't support start/end descriptors, and there are too many
intermittents in it.
Differential Revision: https://phabricator.services.mozilla.com/D126452
We allow animating pseudo-elements like ::-moz-progress-bar (and we
treat them like regular elements).
Ideally we should store animations for these in the parent element as
well, so they survive reframes and such. But treating them as regular
elements right now means that we do animate them, but we never update
animations for them correctly because wrapper.rs assumed them to be
non-animatable.
Since it seems reasonable to keep allowing the animations to happen,
let's just correct the update code and add a test.
Differential Revision: https://phabricator.services.mozilla.com/D131794
Before this change, in nsLayoutUtils::FrameIsScrolledOutOfViewInCrossProcess
we call BaseRect::IsEmpty() for the returned value of GetFrameVisibleRectOnScreen,
unfortunately if the returned value size is (0x0), BaseRect::IsEmpty() returns
true thus we misthink the given nsIFrame is out of the visible area of the OOP
iframe where the nsIFrame lives.
Note that we have already done the same check for in-process cases in
IsFrameScrolledOutOfView [1].
The test case in this change fails without this change, suceeds with
the change. Though, to be honest, I don't know the reason those styles
, `display: grid`, etc. generate (0x0) sized frame even if decendants have
sized.
[1] https://searchfox.org/mozilla-central/rev/15de05f0e6d841cbc2ac66f8dcad72ebdada47f6/layout/generic/nsIFrame.cpp#11090-11094
Differential Revision: https://phabricator.services.mozilla.com/D126312
Before this change, in nsLayoutUtils::FrameIsScrolledOutOfViewInCrossProcess
we call BaseRect::IsEmpty() for the returned value of GetFrameVisibleRectOnScreen,
unfortunately if the returned value size is (0x0), BaseRect::IsEmpty() returns
true thus we misthink the given nsIFrame is out of the visible area of the OOP
iframe where the nsIFrame lives.
Note that we have already done the same check for in-process cases in
IsFrameScrolledOutOfView [1].
The test case in this change fails without this change, suceeds with
the change. Though, to be honest, I don't know the reason those styles
, `display: grid`, etc. generate (0x0) sized frame even if decendants have
sized.
[1] https://searchfox.org/mozilla-central/rev/15de05f0e6d841cbc2ac66f8dcad72ebdada47f6/layout/generic/nsIFrame.cpp#11090-11094
Differential Revision: https://phabricator.services.mozilla.com/D126312
We support the setter of Animation.timeline, so it's possible to have a
null |mTimeline| when calculating the start value for off-main-thread
animations. If it's null, it must be different from the document
timeline, so in this case we don't set |mReplacedTransition|.
So let's move the assertion below the if-check of |mReplacedTransition|.
Differential Revision: https://phabricator.services.mozilla.com/D121675
It probably did something more useful in the past, but right now it's
only used to avoid throttling some overflow-causing animations.
It returns 0 everywhere except on Android (for some reason?), but in any
case it doesn't seem this would need to be a LookAndFeel integer, it
could just be a regular pref that we turn on for tests.
However the tests pass with this patch locally, so for now I'm not
adding a pref to replace it.
Differential Revision: https://phabricator.services.mozilla.com/D120871
So that now EffectCompositor::HasAnimationsForCompositor doesn't return true
for such cases, thus we will not accidentally try to generate
nsDisplayBackgroundColor display item for such animations (bug 1699890#c21)
and we will not generate nsChangeHint_RepaintFrame (bug 1701547) either.
Differential Revision: https://phabricator.services.mozilla.com/D115774
So that now EffectCompositor::HasAnimationsForCompositor doesn't return true
for such cases, thus we will not accidentally try to generate
nsDisplayBackgroundColor display item for such animations (bug 1699890#c21)
and we will not generate nsChangeHint_RepaintFrame (bug 1701547) either.
Differential Revision: https://phabricator.services.mozilla.com/D115774
We increase |jumps| for steps(<integer>,jump-both), and the <integer>
could be a large number, so we have to avoid the int overflow. Now we use
CheckedInt32 for it.
Also, `aPortion * aStepFunc.mSteps` may be out of the range of int32_t,
so we clamp it first and use CheckedInt32 for currentStep, too.
The error handling is pretty simple. We don't care about the result of
this unexpected behavior, so we simply roll the value back to the
original one.
Differential Revision: https://phabricator.services.mozilla.com/D112684
This property does nothing since bug 315209 got implemented.
Every single user that I checked was doing the same math by hand, so
hooray for good defaults :-)
Differential Revision: https://phabricator.services.mozilla.com/D112253
We just need this regardless of whether there appears checkerboarding or jank.
To avoid shrinking the content to the minimum-scale size on mobile environments,
we need to specify a meta viewport tag in this test.
Differential Revision: https://phabricator.services.mozilla.com/D75727
We just need this regardless of whether there appears checkerboarding or jank.
To avoid shrinking the content to the minimum-scale size on mobile environments,
we need to specify a meta viewport tag in this test.
Differential Revision: https://phabricator.services.mozilla.com/D75727
When transitioning visibility and opacity at the same time, we create
two effects, one animating opacity, and one visibility.
We're incorrectly throttling the visibility animation due to opacity,
because _that_ effect is not animating opacity, but the other one is and
thus doesn't get throttled.
Use HasAnimationOfOpacity() to check for this case. This is slightly
sketchy, because the first time we get through there we may not even
have started the opacity animation yet. However it kinda works, because
the fact that there's a (non-throttled, because of the
aEffect.HasOpacityChange()) opacity animation means that we'll tick both
of them, and unthrottle them next frame.
This seems better than the alternative which is never throttling
animations in opacity: 0 roots.
Differential Revision: https://phabricator.services.mozilla.com/D76405
Boris Chiou
Joel Maher
Emilio Cobos Álvarez
Sebastian Hengst
Andreea Pavel
Hiroyuki Ikezoe
Matt Woodrow
Geoff Brown
Andrew Halberstadt
Butkovits Atila
Iulian Moraru
Noemi Erli
Andrew Osmond
Kartik Gautam
Dorel Luca
Jonathan Kew
Mihai Alexandru Michis
Cameron McCormack
tkhan
Bogdan Tara
Brindusan Cristian
Masatoshi Kimura