If both end time and start delay are Infinity, the result of interval
end time is undefined, so now we return zero duration to avoid the
assertion in StickyTimeDuration.
Differential Revision: https://phabricator.services.mozilla.com/D153818
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
