cs_clip_rectangle is slow because we evaluate distance AA for every fragment
the shader touches. With SWGL, we can do much better since we have control
over span. We calculate an inner opaque octagon which can just use a cheap
solid fill and an outer AA octagon within which we need to actually we do
AA and outside which we can just do another solid clear. This reduces most
of the cost of rounded-rectangles to just some setup work, a few fragments
of distance AA on the ends of a span, and large runs of solid color where
we don't have to do much work.
Differential Revision: https://phabricator.services.mozilla.com/D106658
This also adds related DLLs to be delay loaded to xul's moz.build. This means
that if we don't create the devices they are not loaded at all.
Differential Revision: https://phabricator.services.mozilla.com/D105630
Other browsers don't have this UI, and there's no way to know whether
the form will actually be validated, so it can cause false-positives.
Depends on D105968
Differential Revision: https://phabricator.services.mozilla.com/D105969
There's no way to know whether the submission will actually be
validated, because formnovalidate on submit buttons is a thing (and even
if all the submit controls had formnovalidate, you could still submit
the form and validate it via form.submit()), so it seems better to make
these pseudo-classes not depend on this.
Differential Revision: https://phabricator.services.mozilla.com/D105968
We basically use a couple primitives to draw these
(PaintRoundedRectWithRadius, FillRect), so making the code a bit generic
implementing stuff with WebRender seems straight-forward.
I've kept using the fallback codepath for the bits that draw complex
paths like arrows and such, but the rest of the things should work with
this patch.
A thing I'm not too happy about is the scrollbar painting setup (requires a lot
of boilerplate), but modulo template hacks make nsNativeBasicTheme a template
that receives its super class as a parameter or something) it seems hard to do
better.
Differential Revision: https://phabricator.services.mozilla.com/D105931
We basically use a couple primitives to draw these
(PaintRoundedRectWithRadius, FillRect), so making the code a bit generic
implementing stuff with WebRender seems straight-forward.
I've kept using the fallback codepath for the bits that draw complex
paths like arrows and such, but the rest of the things should work with
this patch.
A thing I'm not too happy about is the scrollbar painting setup (requires a lot
of boilerplate), but modulo template hacks make nsNativeBasicTheme a template
that receives its super class as a parameter or something) it seems hard to do
better.
Differential Revision: https://phabricator.services.mozilla.com/D105931
We basically use a couple primitives to draw these
(PaintRoundedRectWithRadius, FillRect), so making the code a bit generic
implementing stuff with WebRender seems straight-forward.
I've kept using the fallback codepath for the bits that draw complex
paths like arrows and such, but the rest of the things should work with
this patch.
A thing I'm not too happy about is the scrollbar painting setup (requires a lot
of boilerplate), but modulo template hacks make nsNativeBasicTheme a template
that receives its super class as a parameter or something) it seems hard to do
better.
Differential Revision: https://phabricator.services.mozilla.com/D105931
No other browser supports anything like this and we don't even have
internal users. Only uses of this I've found on the wild were just
resetting the box shadow internal styling we added in bug 582277 (and
since removed in bug 600151).
Differential Revision: https://phabricator.services.mozilla.com/D105955
Some sites use pixelated/crisp image-rendering and/or 1x1 images as color
sources. When we hit these, we fall off the fast-path. Try to handle some
of those cases we are finding in the wild, namely nearest filtering and
repeat filtering.
There is some slight movement in the wrench fuzz due to the composite shader
being accelerated in situations it was previously not due to nearest filter.
Differential Revision: https://phabricator.services.mozilla.com/D105864
The same optimization of looking for merged linear gradients can also be
applied to radial gradients by solving the quadratic equation to check
how large a span we can process within a given merged span. This allows
us to save a bunch of table lookup and some other math in the inner loops.
Differential Revision: https://phabricator.services.mozilla.com/D105858
For linear gradients, we are currently bottlenecked by looking up a gradient
table entry, doing interpolation, and converting to pixel formats for every
sample.
We can accelerate this by instead looking for contiguous segments of gradient
within the range of entries we need to sample and then interpolating these
as a single gradient. This also enables us to convert to relevant pixel formats
only when setting up this gradient, which greatly reduces the per-pixel processing
down to essentially a shift and add.
To enable this sort of crawling of the gradient table, the output gradients have
been modified such that each entry's step value will equal an adjacent entry's
step value if and only if they are from same gradient. We can ensure this by, in
the very rare case two segments of gradient have the same step, using the equivalent
of nextafter() to imperceptibly alter the value so that the invariant is maintained.
Differential Revision: https://phabricator.services.mozilla.com/D105716
This matches closer what Chrome and Safari do (Safari paints outside of
the box when this happens, but the layout box still respects the
author), see:
data:text/html,<button style="padding: 0; width: 0">
data:text/html,<input type=checkbox style="width: 0">
Etc. For checkboxes, this matches what OSX does, too.
Since we still want checkboxes to be slightly larger than what they'd be
otherwise, we add a hook to tweak it when non-native theme is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D105798
This matches closer what Chrome and Safari do (Safari paints outside of
the box when this happens, but the layout box still respects the
author), see:
data:text/html,<button style="padding: 0; width: 0">
data:text/html,<input type=checkbox style="width: 0">
Etc. For checkboxes, this matches what OSX does, too.
Since we still want checkboxes to be slightly larger than what they'd be
otherwise, we add a hook to tweak it when non-native theme is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D105798
With this patch series, firefox now renders
flexbox-table-flex-items-1.html the same as Google Chrome. Hence the
modification to flexbox-table-flex-items-1-ref.html.
Both table-as-item-flex-cross-size.html and
table-as-item-stretch-cross-size.html contain multiple captions. We still
don't support multiple caption (bug 144517), but passing them means we
correctly subtract caption's block-size when overriding table flex
item's block-size.
We also don't have enough test coverage for table flex items in column
flex container. Add some reftests adapted from existing ones that tests
table flex items in a row flex containers
Differential Revision: https://phabricator.services.mozilla.com/D103440
I thought we didn't support outline-offset on auto-style outline.
The rect we get is already inflated, so we just got to compute the
radius using that.
Differential Revision: https://phabricator.services.mozilla.com/D105125
I couldn't come up with a way to effectively cause this effect with
regular CSS I could put in marquee.css... But this matches the legacy
xul behavior and the chrome behavior, which should be compatible.
This undoes a reftest expectation change I included in bug 1618584. Our
behavior in those tests before this patch matches Safari, but Safari
passes the test I'm adding on this bug, so it is somewhat inconsistent.
Differential Revision: https://phabricator.services.mozilla.com/D105045
This addresses some deficiencies in the way solid spans are handled when clip-masking
or AA is used. In that case, the overhead of the extra blend stage is significant and
we can do a better just by temporarily disabling the those parts of the blend stage
and fast-pathing them instead of just going through commit_solid_span.
Differential Revision: https://phabricator.services.mozilla.com/D104963
Now that most of the complicated alpha-pass features such as clip-masking and anti-aliasing
are handled in SWGL during the blend stage, most of the fast-paths are identical and only call
swgl_commitTextureLinear in a tight loop. We can do a lot better here by just moving that loop
into SWGL, not only making it faster but removing all the redundant boiler-plate code out of
the shaders.
Differential Revision: https://phabricator.services.mozilla.com/D104536
Now that most of the complicated alpha-pass features such as clip-masking and anti-aliasing
are handled in SWGL during the blend stage, most of the fast-paths are identical and only call
swgl_commitTextureLinear in a tight loop. We can do a lot better here by just moving that loop
into SWGL, not only making it faster but removing all the redundant boiler-plate code out of
the shaders.
Differential Revision: https://phabricator.services.mozilla.com/D104536
This makes -moz-outline-radius a no-op, but keep it for now.
If/when we make this the default in release, we can remove it.
Differential Revision: https://phabricator.services.mozilla.com/D104324
This patch has a few moving parts. We have to first tell WR that when it
detects the extension that it is actually allowed to use it. We have to make
the glsl-to-cxx translator eat the blend_supports_all_equations layout
qualifier. We have to enable generation of advanced-blend-equation variants
in the SWGL build setup. Then we report the actual extension inside SWGL.
Finally, we actually add all the necessary blend equation enums, hash them
down to a blend key, and implement all the blend modes therein.
Differential Revision: https://phabricator.services.mozilla.com/D103804
This patch has a few moving parts. We have to first tell WR that when it
detects the extension that it is actually allowed to use it. We have to make
the glsl-to-cxx translator eat the blend_supports_all_equations layout
qualifier. We have to enable generation of advanced-blend-equation variants
in the SWGL build setup. Then we report the actual extension inside SWGL.
Finally, we actually add all the necessary blend equation enums, hash them
down to a blend key, and implement all the blend modes therein.
Differential Revision: https://phabricator.services.mozilla.com/D103804
To accurately test the condition we need to tweak a transform every 74 ms. This leads to problems on platforms that can't complete a full paint cycle through the reftest harness (which consists of two paints, the one for the screen and then one to update the reftest canvas). This only used to affect android debug builds severely but seems to have gotten worse on linux debug and asan builds.
Differential Revision: https://phabricator.services.mozilla.com/D103738
This patch improves nsCanvasFrame::Reflow in a few ways.
First, we now iterate over mFrames and reflow every child.
This makes it more robust vis-à-vis the order of any placeholders
and the root frame, and also resilient against a missing root
frame (this fixes the fatal assertion in this bug). We now
also actually reflow all placeholders which wasn't the case
before. It seems like a prudent thing to do.
I also added a separate nsReflowStatus for each child.
We now also call SetOverflowAreasToDesiredBounds() in all
cases. We failed to do that in the 'mFrames.IsEmpty()' case
before, which triggered the assertions in bug 1655630 and
bug 1392106.
Differential Revision: https://phabricator.services.mozilla.com/D103592
Once all the remaining patches for test tweaks / fixes have landed, this
patch should be green on try. Couple test annotation changes:
* clip-003.html fails the same way it fails on mac (odd, but couldn't
repro...). I'll try to dig a bit more before calling it a day.
* radiobutton-min-size starts behaving like every other platform.
* Event-dispatch-redispatch and baseline-alignment-and-overflow start
passing.
* Couple minor fuzzy annotations (one was backwards, the other was
missing).
Differential Revision: https://phabricator.services.mozilla.com/D103327
The non-native theme does two things which, combined, cause this test to
fail.
The first one is that it has slightly bigger checkboxes than other
themes (14px vs. 13px).
The second one is that it has a 2px widget-imposed border, like Mac:
https://searchfox.org/mozilla-central/rev/0dfbe5a699cc6c73cf8c14d1aa10ba10ef3ec8fa/widget/nsNativeBasicTheme.cpp#1367-1369
Which causes its baseline to go down by that amount. This was done
intentionally in bug 1675389, though I guess it could be reconsidered.
These two things combined make the checkbox grow the line slightly in
this test-case, causing the elements to move 1px apart.
The test is intended to check that the baseline calculation of a
checkbox/radio is correct, which it is, so prevent that undesired side
effect by resetting the margin to zero.
Differential Revision: https://phabricator.services.mozilla.com/D103324
With non-native theme, number inputs have zero padding-inline-end by
default, so otherwise the test would fail by a few pixels.
Differential Revision: https://phabricator.services.mozilla.com/D103246
This doesn't change behavior by default but allows authors to remove the
padding if they wish to.
I thought this was going to be problematic because of the windows
arrowbutton, but that doesn't respect select padding so we're good.
Differential Revision: https://phabricator.services.mozilla.com/D103245
Combobox select has the block-axis padding in the comboboxcontrol frame.
Moving it fixes bug 1560824 and should be better, so will do that there.
1px block axis padding on buttons matches Chrome too, so shouldn't be a
problem compat-wise.
Differential Revision: https://phabricator.services.mozilla.com/D103244
This patch makes the following changes:
1. Don't call ReflowInput::CalculateBlockSideMargins() for nsTableFrame
so that setting nsTableFrame's computed margins to zero in
SizeComputationInput::InitOffsets() remains true. Also, add an assertion
in nsTableFrame::Reflow() to ensure that.
2. Remove useless nsTableFrameWrapper::GetChildMargin() because the
method is used to get nsTableFrame's margins, which are now all zero.
Also, the old code that subtracts the block-axis margin from available
block-size doesn't really make sense.
3. Pass all-zero innerMargins to nsTableWrapperFrame::SetDesiredSize(),
and use table wrapper's content-box inline-size as the final desired
border-box inline-size rather than reconstructing it from caption and
inner table's inline-size & margin like the old code.
This inline-size already takes inner table's intrinsic size and
caption's inline-size into consideration in
nsTableWrapperFrame::ComputeAutoSize(), and is the final inline-size we
want to use.
In the next part, we are going to simplify all nsTableWrapperFrame's
methods that take inner frame's margin.
Differential Revision: https://phabricator.services.mozilla.com/D103065
I'm using "/^Windows\x20NT\x206\.1/.test(http.oscpu)" to check for Windows 7,
which I found (with Win7-related code comments) elsewhere in reftest.list
files.
I'm replacing a "fuzzy-if(!nativeThemePref,...)" annotation here, which I think
was simply mis-applied here -- this test doesn't have any form controls or
theme-related stuff, so it doesn't make sense that its rendering would be
theme-dependent. I suspect this annotation was added by mistake, due to this
test intermittently failing by coincidence on a try run where the
!nativeThemePref configuration was being tested.
Differential Revision: https://phabricator.services.mozilla.com/D103083
This matches other browsers, and the default themed textareas on Windows
too.
To be landed after the soft freeze, just in case, of course.
Differential Revision: https://phabricator.services.mozilla.com/D102843
This matches other browsers, and the default themed textareas on Windows
too.
To be landed after the soft freeze, just in case, of course.
Differential Revision: https://phabricator.services.mozilla.com/D102843
This will allow the browser chrome to use `<dialog>` etc, see
bug 1685313.
Tweak the check to support scrolling="false" on reftests, so that we can
test this.
Differential Revision: https://phabricator.services.mozilla.com/D102623
This will allow the browser chrome to use `<dialog>` etc, see
bug 1685313.
Tweak the check to support scrolling="false" on reftests, so that we can
test this.
Differential Revision: https://phabricator.services.mozilla.com/D102623
This allows us to default to skipping the bundled Twemoji Mozilla font when running on Win8.1 or later,
where we can assume Segoe UI Emoji is available.
The new pref here replaces the existing pair of boolean prefs that were only supported on Android,
and is now respected on all platforms. Available settings are:
0 disable use of app-bundled fonts
> 0 enable use of app-bundled fonts
< 0 default (auto): decide at startup, based on the system environment
(The pref is relevant only at startup; changing its value during a session will not make the bundled fonts
appear/disappear dynamically.)
Differential Revision: https://phabricator.services.mozilla.com/D102085
We add two @-moz-document functions: `plain-text-document()`, matching the
obvious, and `unobservable-document()`, which matches a top-level document with
no opener. This is the equivalent check we do for automatic darkening of
`about:blank` here:
https://searchfox.org/mozilla-central/rev/014fe72eaba26dcf6082fb9bbaf208f97a38594e/layout/base/PresShell.cpp#5282
The former we don't need to use, but it's nice to let user stylesheets target
plaintext documents properly (rather than relying on extensions or what not).
Note that these are not content-observable.
Add two tests: One showing that we produce different rendering when on dark
mode, and one showing that we produce the same one from an iframe, regardless
of dark mode.
Depends on D101517
Differential Revision: https://phabricator.services.mozilla.com/D101518
We add two @-moz-document functions: `plain-text-document()`, matching the
obvious, and `unobservable-document()`, which matches a top-level document with
no opener. This is the equivalent check we do for automatic darkening of
`about:blank` here:
https://searchfox.org/mozilla-central/rev/014fe72eaba26dcf6082fb9bbaf208f97a38594e/layout/base/PresShell.cpp#5282
The former we don't need to use, but it's nice to let user stylesheets target
plaintext documents properly (rather than relying on extensions or what not).
Note that these are not content-observable.
Add two tests: One showing that we produce different rendering when on dark
mode, and one showing that we produce the same one from an iframe, regardless
of dark mode.
Depends on D101517
Differential Revision: https://phabricator.services.mozilla.com/D101518
We add two @-moz-document functions: `plain-text-document()`, matching the
obvious, and `unobservable-document()`, which matches a top-level document with
no opener. This is the equivalent check we do for automatic darkening of
`about:blank` here:
https://searchfox.org/mozilla-central/rev/014fe72eaba26dcf6082fb9bbaf208f97a38594e/layout/base/PresShell.cpp#5282
The former we don't need to use, but it's nice to let user stylesheets target
plaintext documents properly (rather than relying on extensions or what not).
Note that these are not content-observable.
Add two tests: One showing that we produce different rendering when on dark
mode, and one showing that we produce the same one from an iframe, regardless
of dark mode.
Depends on D101517
Differential Revision: https://phabricator.services.mozilla.com/D101518
We add two @-moz-document functions: `plain-text-document()`, matching the
obvious, and `unobservable-document()`, which matches a top-level document with
no opener. This is the equivalent check we do for automatic darkening of
`about:blank` here:
https://searchfox.org/mozilla-central/rev/014fe72eaba26dcf6082fb9bbaf208f97a38594e/layout/base/PresShell.cpp#5282
The former we don't need to use, but it's nice to let user stylesheets target
plaintext documents properly (rather than relying on extensions or what not).
Note that these are not content-observable.
Add two tests: One showing that we produce different rendering when on dark
mode, and one showing that we produce the same one from an iframe, regardless
of dark mode.
Depends on D101517
Differential Revision: https://phabricator.services.mozilla.com/D101518
Also disable for users with 64-bit Firefox with 1-2 cores, and less than
2 GB of physical memory. It was already disabled for 32-bit Firefox.
Differential Revision: https://phabricator.services.mozilla.com/D101052
This test spams the same assertion either 4 or 6 times, with this variation
probably being due to an extra reflow which we sometimes incur due to a
font-fallback task having coincidentally just completed, as described in
https://groups.google.com/g/mozilla.dev.platform/c/VBh6oLm4EbQ/m/dbaJcAe6BgAJ
Previously the test was annotated as asserting exactly 4 times, but now we
need to allow for it to sometimes assert 6 times instead.
Differential Revision: https://phabricator.services.mozilla.com/D101506
This is a minor adjustment to the font-selection heuristics implemented in bug 1371386:
for emoji codepoints, we should accept the font(s) specified in the font.name-list.emoji
preference even if it's a monochrome font for characters that would normally be expected
to use a color rendering, as this is the user's choice.
Differential Revision: https://phabricator.services.mozilla.com/D101162
This test spams the same assertion either 4 or 6 times, with this variation
probably being due to an extra reflow which we sometimes incur due to a
font-fallback task having coincidentally just completed, as described in
https://groups.google.com/g/mozilla.dev.platform/c/VBh6oLm4EbQ/m/dbaJcAe6BgAJ
Previously the test was annotated as asserting exactly 4 times, but now we
need to allow for it to sometimes assert 6 times instead.
Differential Revision: https://phabricator.services.mozilla.com/D101100
Lee Salzman
Andrew Osmond
Emilio Cobos Álvarez
Bob Owen
Stephen A Pohl
Daniel Holbert
smolnar
Noemi Erli
Mats Palmgren
Dorel Luca
Ting-Yu Lin
longsonr
Jonathan Kew
Bogdan Tara
Pierre TALLOTTE
Butkovits Atila
Brad Werth
Csoregi Natalia
Brindusan Cristian
Markus Stange
Timothy Nikkel
Cameron McCormack
Mihai Alexandru Michis
Ryan VanderMeulen
Nicolas Silva