Previously, a transform with a negative scale would result in a
new coordinate system being created when updating the spatial
tree.
This meant that a primitive in that space with a clip in a parent
space would create a clip mask (and was thus unable to be promoted
to a compositor surface).
This change allows negative scales to be part of the same coord
system (since they are still axis-aligned with the parent) and
avoid a clip mask in this case.
Differential Revision: https://phabricator.services.mozilla.com/D109580
Previously, a transform with a negative scale would result in a
new coordinate system being created when updating the spatial
tree.
This meant that a primitive in that space with a clip in a parent
space would create a clip mask (and was thus unable to be promoted
to a compositor surface).
This change allows negative scales to be part of the same coord
system (since they are still axis-aligned with the parent) and
avoid a clip mask in this case.
Differential Revision: https://phabricator.services.mozilla.com/D109580
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
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
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
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
GetIntrinsicSizeFor() is used to get intrinsic size only for images.
This patch removes the restriction by removing the function, and uses
nsIFrame::GetIntrinsicSize() directly to get intrinsic sizes for all
replaced elements.
1183431-orthogonal-modes-8a.html passes because we can now get
<iframe>'s intrinsic size in CalculateHypotheticalPosition().
Differential Revision: https://phabricator.services.mozilla.com/D92874
Most of them are straight-forward. Some fuzziness due to Skia around rounded
corners still. Some tests that already fail in other widgets as expected.
This is enough to green up reftests (but not WPT, yet) on Android, both with and
without WR enabled.
Nothing too concerning, all-in-all.
Differential Revision: https://phabricator.services.mozilla.com/D65667
--HG--
extra : moz-landing-system : lando
Now that we're subclassing nsTextControlFrame we can use the regular replaced
element intrinsic sizing, rather than just faking it in the UA sheet with a
suspicious width declaration.
Differential Revision: https://phabricator.services.mozilla.com/D59981
--HG--
extra : moz-landing-system : lando
The glyph pixel space in which we rasterized glyphs differed from how we
rendered the rasterized glyphs in the shader. They need to be in
agreement because the glyph subpixel offset selected during
rasterization depends on it. This patch should make the paths consistent
with each other.
Additionally, during animations, we now snap the reference frame
relative offset ignoring the impact of any animated transforms. This
helps with minimizing glyph wiggling during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D51305
--HG--
extra : moz-landing-system : lando
The glyph pixel space in which we rasterized glyphs differed from how we
rendered the rasterized glyphs in the shader. They need to be in
agreement because the glyph subpixel offset selected during
rasterization depends on it. This patch should make the paths consistent
with each other.
Additionally, during animations, we now snap the reference frame
relative offset ignoring the impact of any animated transforms. This
helps with minimizing glyph wiggling during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D51305
--HG--
extra : moz-landing-system : lando
font-inflation-1e.html is adapted from font-inflation-1a.html with the
writing-mode set on <html> instead of <body>. It can trigger the
assertion "current writing mode should match that of our flow root" in
nsFontInflationData::FindFontInflationDataFor().
The root cause is: nsCanvasFrame can generate the position:absolute
custom content container to contain elements like AccessibleCaret. When
the container is constructed, the container's writing-mode is always
horizontal-rl, which is getting from nsCanvasFrame that uses
ViewportFrame's style.
If <html> has a vertical writing-mode, custom content container's used
mWritingMode becomes orthogonal to ViewportFrame, because <html>'s used
mWritingMode is propagated all the way up to ViewportFrame.
This patch solves the above issue by making the custom content container
a font inflation root, so FindFontInflationDataFor() stops at it instead
of finding all the way up to the ViewportFrame.
Differential Revision: https://phabricator.services.mozilla.com/D48942
--HG--
extra : moz-landing-system : lando
In 817406-4.html, `<body style="direction: rtl;">` needs to propagate up
to `<html>`, so we should compare its result to 817406-1-ref.html.
Differential Revision: https://phabricator.services.mozilla.com/D45482
--HG--
extra : moz-landing-system : lando
In 817406-4.html, `<body style="direction: rtl;">` needs to propagate up
to `<html>`, so we should compare its result to 817406-1-ref.html.
Differential Revision: https://phabricator.services.mozilla.com/D45482
--HG--
extra : moz-landing-system : lando
Most of these tests have been disabled for a long time; they run well
in the current test environment.
Differential Revision: https://phabricator.services.mozilla.com/D47616
--HG--
extra : moz-landing-system : lando