We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
The thumb's position is sent to the compositor in ScrollbarData::mThumbStart
stored on the OwnLayer item built by the slider frame, so we need to
invalidate the slider frame when the thumb's position changes.
Differential Revision: https://phabricator.services.mozilla.com/D176384
We still have some remnants of XUL layout due to nsBox / nsLeafBoxFrame
which XUL trees / nsTextBoxFrame still use.
However all this code can go away before we get rid of those.
nsSplitterFrame was the last thing inheriting from nsBoxFrame.
Differential Revision: https://phabricator.services.mozilla.com/D173601
This rewrites scrollbar layout to work with regular reflow rather than
box layout.
Overall it's about the same amount of code (mostly because
nsScrollbarFrame::Reflow is sorta hand-rolled), but it cleans up a bit
and it is progress towards removing XUL layout altogether, without
getting into much deeper refactoring.
This also blocks some other performance improvements and refactorings I
want to make in this code.
We make some assumptions to simplify the code that to some extent were
made already before, both explicitly and by virtue of using XUL layout.
In particular, we assume that scrollbar / slider / thumb has no border or
padding and that the writing-mode is horizontal ltr.
Differential Revision: https://phabricator.services.mozilla.com/D173489
This rewrites scrollbar layout to work with regular reflow rather than
box layout.
Overall it's about the same amount of code (mostly because
nsScrollbarFrame::Reflow is sorta hand-rolled), but it cleans up a bit
and it is progress towards removing XUL layout altogether, without
getting into much deeper refactoring.
This also blocks some other performance improvements and refactorings I
want to make in this code.
We make some assumptions to simplify the code that to some extent were
made already before, both explicitly and by virtue of using XUL layout.
In particular, we assume that scrollbar / slider / thumb has no border or
padding and that the writing-mode is horizontal ltr.
Differential Revision: https://phabricator.services.mozilla.com/D173489
This is currently used mostly for calculations related to scrollbars,
which are an example of content outside the scroll frame (and in
particular not subject to the zoom of a zoomable scroll frame).
As part of this change, FrameMetrics::
CalculateCompositionBoundsInCssPixelsOfSurroundingContent() is
renamed to CalculateCompositionBoundsInOuterCSSPixels() for brevity.
Differential Revision: https://phabricator.services.mozilla.com/D171142
Although not needed right now (checkerboarding backgrounds get
a slice anyway due to being a different scroll root), this will
be important for the upcoming work to make backdrop filter
roots implicit. This allows WR to know when slicing up a content
slice if the prim is relevant to the backdrop root.
Differential Revision: https://phabricator.services.mozilla.com/D146145
The scroll snap spec defines the concepts [1]. There are three type of scroll
operations. 1) intended end position, 2) intended direction and end position
and 3) intended direction.
Basically our existing ScrollUnits types correspond;
1) DEVICE_PIXELS, WHOLE => intended end position
2) PAGES => intended direction and end position
3) LINES => intended direction
There are two exceptions in the `intended direction and end position` case,
scrollBy() and fling gestures (on Linux). They were defined as scroll operations
with DEVICE_PIXELS unit, but the spec cleary says they are `intended direction
and end position` operations.
Note that we will also use this information for scroll-snap-stop property since
the properly will only have effects on both 2) and 3) cases.
[1] https://drafts.csswg.org/css-scroll-snap/#scroll-types
Depends on D145190
Differential Revision: https://phabricator.services.mozilla.com/D145191
The scroll snap spec defines the concepts [1]. There are three type of scroll
operations. 1) intended end position, 2) intended direction and end position
and 3) intended direction.
Basically our existing ScrollUnits types correspond;
1) DEVICE_PIXELS, WHOLE => intended end position
2) PAGES => intended direction and end position
3) LINES => intended direction
There are two exceptions in the `intended direction and end position` case,
scrollBy() and fling gestures (on Linux). They were defined as scroll operations
with DEVICE_PIXELS unit, but the spec cleary says they are `intended direction
and end position` operations.
Note that we will also use this information for scroll-snap-stop property since
the properly will only have effects on both 2) and 3) cases.
[1] https://drafts.csswg.org/css-scroll-snap/#scroll-types
Depends on D145190
Differential Revision: https://phabricator.services.mozilla.com/D145191
We need them for SVG primitives.
This patch adds a bit of plumbing to disable snapping some of the primitives and forcing the antialiasing shader feature where needed, and uses it for SVG solid rectangles and images.
Differential Revision: https://phabricator.services.mozilla.com/D139024
By resolving the relevant promises, instead of crashing (and if we
didn't crash we'd leave the window registered as a refresh driver
observer, which would be bad).
I wanted to reject them, since that's what we do when the page has no
pres shell, but that'd make this test fail:
https://searchfox.org/mozilla-central/rev/d8194cbbeaec11962ed67f83aea9984bf38f7c63/dom/base/test/browser_promiseDocumentFlushed.js#165-186
For this, we modify the OneShotPostRefreshObserver API to be more
generic (and rename it OneShotManagedRefreshObserver).
We fix APZ's usage of this API, which was doing something extremely
weird (returning a refcounted object in a UniquePtr). This seems like an
artifact from recent OneShotPostRefreshObserver cleanup.
Differential Revision: https://phabricator.services.mozilla.com/D111851
This shouldn't change behavior, but is the biggest cross-platform part
of the change so I'd like to get it landed sooner rather than later.
The two calls like:
GetColor(ColorID::TextSelectBackground, color);
if (color == 0x000000) {
mColorTextSelectForeground = NS_RGB(0xff, 0xff, 0xff);
} else {
mColorTextSelectForeground = NS_DONT_CHANGE_COLOR;
}
that I'm removing are just broken. They were calling the version of
GetColor the function that took a default value when the color wasn't
available, not the version of the color with the outparam.
To prevent such mistakes, add two signatures, GetColor(), returning a
Maybe<nscolor> and Color(), returning a color with a fallback.
Differential Revision: https://phabricator.services.mozilla.com/D110651
This shouldn't change behavior, but is the biggest cross-platform part
of the change so I'd like to get it landed sooner rather than later.
The two calls like:
GetColor(ColorID::TextSelectBackground, color);
if (color == 0x000000) {
mColorTextSelectForeground = NS_RGB(0xff, 0xff, 0xff);
} else {
mColorTextSelectForeground = NS_DONT_CHANGE_COLOR;
}
that I'm removing are just broken. They were calling the version of
GetColor the function that took a default value when the color wasn't
available, not the version of the color with the outparam.
To prevent such mistakes, add two signatures, GetColor(), returning a
Maybe<nscolor> and Color(), returning a color with a fallback.
Differential Revision: https://phabricator.services.mozilla.com/D110651
This patch is the result of auditing all places that look at the presence or absence of a display port to handle minimal display ports (HasDisplayPort, GetDisplayPort, etc).
Broadly speaking the places were in two categories:
1) things related to painting, that want to consider minimal display ports as display ports for purposes of things like sending over metadata and separating out layers.
2) things that care about async scrolling, and so actually want to have a properly sized display port.
Type 1) were not changed by this patch. Type 2) were changed to consider minimal display ports as not display ports.
Again, we are aiming to leave behaviour unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D103856
OneShotPostRefreshObserver works as the caller registers it, and
let it deletes itself via the DidRefresh method. The issue is that
DidRefresh is not guaranteed to run, and it'll leak PresShell
if it doesn't run.
This patch allows nsPresContext to store and release the last
registered OneShotPostRefreshObserver, and converted the existing
usage of OneShotPostRefreshObserver to use that. So instead of asking
OneShotPostRefreshObserver to delete itself, we now ask nsPresContext
to release it.
Differential Revision: https://phabricator.services.mozilla.com/D99939
