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
The way CommitStyles called into servo caused it to call the closure
multiple times, and we were not dealing with that properly.
Handle the "was called" state internally.
Differential Revision: https://phabricator.services.mozilla.com/D131411
`profiler_thread_is_being_profiled` is used a lot for markers, so it makes sense to have a specialized version, which is a bit shorter, and lives in ProfilerMarkers.h.
Differential Revision: https://phabricator.services.mozilla.com/D130009
`profiler_thread_is_being_profiled` is used a lot for markers, so it makes sense to have a specialized version, which is a bit shorter, and lives in ProfilerMarkers.h.
Differential Revision: https://phabricator.services.mozilla.com/D130009
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
This will make implementing the new behavior behind a pref
really straight-forward, and is generally nicer.
Depends on D121858
Differential Revision: https://phabricator.services.mozilla.com/D121705
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's unused on mozilla-central, and Thunderbird can just use the canvas
frame as regular (X)HTML documents, so just use a canvas frame instead
of an nsRootBoxFrame for XUL as well.
nsRootBoxFrame was needed because of various XUL-specific things like
tooltips and so on lived there. But with the move away from XUL, that
functionality has been added to nsCanvasFrame already, behind a
principal check instead.
This also allows simplifying our background propagation setup, which was
only half-working for XUL documents (this bug is a consequence of that).
With this, most of the callers of nsCSSRendering::IsCanvasFrame can go.
They're only two of the frames that would return true for that that
actually paint backgrounds (nsCanvasFrame and nsRootBoxFrame), so the
codepaths in display list building and painting can just check
frame->IsCanvasFrame() instead.
The remaining caller to that function is
nsContainerFrame::SyncWindowProperties, and the change is also legit, in
the sense that the only thing SyncWindowProperties() really cares about
is propagating the max/min-width constraints from the root element's
style to the view/widget, and the only frame that would return true from
IsCanvasFrame and have a view is the viewport frame which is the root of
the frame tree.
Differential Revision: https://phabricator.services.mozilla.com/D90846
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
Emilio Cobos Álvarez
Sebastian Hengst
Gerald Squelart
Cristian Tuns
Jeff Muizelaar
Andreea Pavel
Hiroyuki Ikezoe
Matt Woodrow
Cosmin Sabou
Geoff Brown
Kagami Sascha Rosylight
Boris Chiou
Alexandru Michis
Tooru Fujisawa
Andrew Halberstadt
Butkovits Atila
Iulian Moraru
Noemi Erli
Edgar Chen
Florian Quèze
Simon Giesecke
Mike Hommey