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
Previously, WR needed to update and track dependencies for all
allocated picture cache tiles in the virtual display port. This
means doing extra CPU work (dependency updates) and in some cases,
extra GPU work (larger off-screen child surfaces) than are strictly
required.
With this patch, each tile determines if it is currently visible in
pre_update. If the tile isn't visible, we skip doing dependency
updates until it is on screen again. More importantly, this is
used to reduce the world culling rect for primitive preparation,
which also means large child surfaces only require allocations
large enough to enclose the visible tiles, rather than the
display port.
Differential Revision: https://phabricator.services.mozilla.com/D51006
--HG--
extra : moz-landing-system : lando
It's not the kind of thing we want people to allow observing, generally, and
even less so the kind of thing that we may want people to rely on.
Move internal callers (all of them tests) to a new DOMWindowUtils.paintCount
method.
Differential Revision: https://phabricator.services.mozilla.com/D50817
--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
This is a gross hack, of course, but has the advantage of not breaking sites
that use both zoom and -moz-transform / -moz-transform-origin.
There should be no behavior change when the pref is off, of course, and the
webcompat team wanted to experiment with this.
Differential Revision: https://phabricator.services.mozilla.com/D49792
--HG--
extra : moz-landing-system : lando
Per the css-contain specification, size contained elements must be sized as if
they were empty. Up until now, we've been handling that by just using "0" as
the intrinsic size of some components, but that doesn't actually match the size
of a "true" empty select, which has some nonzero width from:
(a) the default inline-axis padding on the display frame (added in a rule for
the ::-moz-display-comboboxcontrol-frame pseudo, in forms.css).
(b) the width (inline-size) of the display frame's "placeholder" space
character, which has a small intrinsic width (but which really only exists
for *block-axis* sizing and alignment, when no option is selected from
the dropdown).
This patch addresses issue (a) by explicitly adding the display frame's
inline-axis padding to size-contained elements, and it addresses issue (b) by
changing to use a zero-width space character in empty select elements.
So: as of this patch, size-contained select elements are getting a little wider
(to address (a)), and empty select elements are also getting a little skinnier
(to address (b)), and they'll end up being the same width.
(I chose U+FEFF "zero-width non-breaking-space" since we were previously using
a non-breaking space character. I'm not sure if the non-breaking aspect matters,
but I figured I'd preserve that to be on the safe side.)
Differential Revision: https://phabricator.services.mozilla.com/D48791
--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
Per the css-contain specification, size contained elements must be sized as if
they were empty. Up until now, we've been handling that by just using "0" as
the intrinsic size of some components, but that doesn't actually match the size
of a "true" empty select, which has some nonzero width from:
(a) the default inline-axis padding on the display frame (added in a rule for
the ::-moz-display-comboboxcontrol-frame pseudo, in forms.css).
(b) the width (inline-size) of the display frame's "placeholder" space
character, which has a small intrinsic width (but which really only exists
for *block-axis* sizing and alignment, when no option is selected from
the dropdown).
This patch addresses issue (a) by explicitly adding the display frame's
inline-axis padding to size-contained elements, and it addresses issue (b) by
changing to use a zero-width space character in empty select elements.
So: as of this patch, size-contained select elements are getting a little wider
(to address (a)), and empty select elements are also getting a little skinnier
(to address (b)), and they'll end up being the same width.
(I chose U+FEFF "zero-width non-breaking-space" since we were previously using
a non-breaking space character. I'm not sure if the non-breaking aspect matters,
but I figured I'd preserve that to be on the safe side.)
Differential Revision: https://phabricator.services.mozilla.com/D48791
--HG--
extra : moz-landing-system : lando
This can also fix bug 1586470.
This change basically reverts Bug 1025669 Part 1.
https://hg.mozilla.org/mozilla-central/rev/ae2fd5b2defb0df1bd30521f4793de6757d1e98b
In box-decoration-break-block-margin.html, the `height` in `.inner` is
changed to 79px so that 79px plus 7px margin top and 1px margin end,
total 87px, can be divided by 3 (columns). The modification to reference
file reflects what we currently rendered.
Co-authored-by: Mats Palmgren <mats@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D48484
--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
This makes things better especially when the bounds of the combined blob
is changing but the bound of the separate ones are not.
The current implementation is a bit ugly, but it's simple and
can be cleaned up in the cleanups I have in mind for the future.
Differential Revision: https://phabricator.services.mozilla.com/D47983
--HG--
extra : moz-landing-system : lando
See https://groups.google.com/forum/#!topic/mozilla.dev.platform/70NFnet82cU
This commit introduces a new mathml.xlink.disabled option to disable support
for XLink attributes on MathML elements together with a use counter and
deprecation warning when support is enabled. For now, support is only disabled
in Nightly.
In the past, we relied on custom MathML deprecation warnings but those are
removed here. Corresponding tests for these legacy warning messages are
also removed from test_bug553917.html.
link-1.xhtml is run with XLink support enabled (since it checks xlink:href)
while browser_contentAltClick.js and browser_contentAreaClick.js are updated
to instead check MathML links (i.e. href instead of xlink:href).
Differential Revision: https://phabricator.services.mozilla.com/D43332
--HG--
extra : moz-landing-system : lando
See https://groups.google.com/forum/#!topic/mozilla.dev.platform/vwAkuZIEhnY
* Introduce a new preference option to disable menclose's "radical" notation.
* Disable the notation in Nightly and when running WPT tests.
* Enable the notation in other channels together with a counter and
deprecation warning.
* Update WPT test legacy-menclose-radical-notation.html
- Fix test: "radical" should be equivalent to "", which is not the same as
the default value "longdiv".
See https://github.com/mathml-refresh/mathml/issues/144
- Add a test "box radical" which should be equivalent to "box".
- Remove failure expectation.
* Enable the radical notation for MathML reftests testing it.
Differential Revision: https://phabricator.services.mozilla.com/D46721
--HG--
extra : moz-landing-system : lando
See https://groups.google.com/forum/#!topic/mozilla.dev.platform/vwAkuZIEhnY
* Introduce a new preference option to disable menclose's "radical" notation.
* Disable the notation in Nightly and when running WPT tests.
* Enable the notation in other channels together with a counter and
deprecation warning.
* Update WPT test legacy-menclose-radical-notation.html
- Fix test: "radical" should be equivalent to "", which is not the same as
the default value "longdiv".
See https://github.com/mathml-refresh/mathml/issues/144
- Add a test "box radical" which should be equivalent to "box".
- Remove failure expectation.
* Enable the radical notation for MathML reftests testing it.
Differential Revision: https://phabricator.services.mozilla.com/D46721
--HG--
extra : moz-landing-system : lando
This reverts the changes from bug 1481593 / bug 1317870 which broke
the default rendering on Android only (since it doesn't have
a native theme for <input type=range>).
Differential Revision: https://phabricator.services.mozilla.com/D47345
--HG--
extra : moz-landing-system : lando
This moves the origin of fallback blobs back to the top left of their display
item bounds. This is what they were before the patches in bug 1568227 and makes
more sense because there's not necessarily a reference frame above the fallback
frame which means that the coordinates of the display item can change without
us wanting to invalidate the interior.
Differential Revision: https://phabricator.services.mozilla.com/D47275
--HG--
extra : moz-landing-system : lando
Once this patch lands, all content drawn by WebRender is drawn into
a picture cache surface.
This will incur some extra GPU memory overhead since there are extra
GPU texture buffers. Much of this can be reduced by adding a couple
of simple optimizations in future to detect tiles that are solid
colors only.
With this change, we'll now be able to provide exact dirty rects for
the entire screen without any hacks, and start the work to draw into
OS compositor surfaces directly.
Differential Revision: https://phabricator.services.mozilla.com/D47395
--HG--
extra : moz-landing-system : lando
This moves the origin of fallback blobs back to the top left of their display
item bounds. This is what they were before the patches in bug 1568227 and makes
more sense because there's not necessarily a reference frame above the fallback
frame which means that the coordinates of the display item can change without
us wanting to invalidate the interior.
Differential Revision: https://phabricator.services.mozilla.com/D47275
--HG--
extra : moz-landing-system : lando
Once this patch lands, all content drawn by WebRender is drawn into
a picture cache surface.
This will incur some extra GPU memory overhead since there are extra
GPU texture buffers. Much of this can be reduced by adding a couple
of simple optimizations in future to detect tiles that are solid
colors only.
With this change, we'll now be able to provide exact dirty rects for
the entire screen without any hacks, and start the work to draw into
OS compositor surfaces directly.
Differential Revision: https://phabricator.services.mozilla.com/D47395
--HG--
extra : moz-landing-system : lando
Once this patch lands, all content drawn by WebRender is drawn into
a picture cache surface.
This will incur some extra GPU memory overhead since there are extra
GPU texture buffers. Much of this can be reduced by adding a couple
of simple optimizations in future to detect tiles that are solid
colors only.
With this change, we'll now be able to provide exact dirty rects for
the entire screen without any hacks, and start the work to draw into
OS compositor surfaces directly.
Differential Revision: https://phabricator.services.mozilla.com/D47395
--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
This avoids frequent intermittent failures observed with changes to be made by
bug 1584290 (changes which appear unrelated to this test).
Differential Revision: https://phabricator.services.mozilla.com/D47615
--HG--
extra : moz-landing-system : lando
multicol-span-all-margin-bottom-001.xht and multicol-span-none-001.xht
have been patched upstream. They should pass after we import from wpt.
DONTBUILD because this is a comment-only change.
Differential Revision: https://phabricator.services.mozilla.com/D47340
--HG--
extra : moz-landing-system : lando
Previously, the setup_picture_caching function was hard coded
to support only a very specific shape of display list. With this
change, flags are added to PrimitiveCluster that can specify
if a picture cache slice should be created before / after this
cluster when picture caching is set up.
The usage of these flags in this patch matches the old behaviour,
so should not have any functional effect.
However, in future we will make use of this functionality to
create picture slices for a number of different use cases, such as:
* Creating cache tiles for the UI.
* Slicing the scene where there are video elements, in order to
allow these to be composited directly by the OS. This may also
apply to WebGL and/or canvas elements.
* Slicing the scene when there is a very large fixed position
background image or other element, to avoid invalidating the
entire tile cache each frame.
Differential Revision: https://phabricator.services.mozilla.com/D46125
--HG--
extra : moz-landing-system : lando
Intent to unship: https://groups.google.com/forum/#!topic/mozilla.dev.platform/JnJVGTmIwPE
- Introduce a new preference option mathml.deprecated_alignment_attributes.disabled()
to disable alignment attributes for mfrac/munder/mover/munderover elements.
- Disable the attributes in Nightly and when running WPT tests.
- Enable the attributes in other channels but add a counter and deprecation warning.
- Remove failure expectation for WPT test frac-numalign-denomalign-001.html for mfrac
- Add new WPT test for underover-legacy-align-attribute-001.html for munder/mover/munderover
- Enable the attributes for MathML reftests checking these attributes.
- Disable numalign/denomalign test for Mochitest test_bug975681.html when the attributes
are disabled.
Differential Revision: https://phabricator.services.mozilla.com/D46712
--HG--
extra : moz-landing-system : lando
Previously, the setup_picture_caching function was hard coded
to support only a very specific shape of display list. With this
change, flags are added to PrimitiveCluster that can specify
if a picture cache slice should be created before / after this
cluster when picture caching is set up.
The usage of these flags in this patch matches the old behaviour,
so should not have any functional effect.
However, in future we will make use of this functionality to
create picture slices for a number of different use cases, such as:
* Creating cache tiles for the UI.
* Slicing the scene where there are video elements, in order to
allow these to be composited directly by the OS. This may also
apply to WebGL and/or canvas elements.
* Slicing the scene when there is a very large fixed position
background image or other element, to avoid invalidating the
entire tile cache each frame.
Differential Revision: https://phabricator.services.mozilla.com/D46125
--HG--
extra : moz-landing-system : lando
As it turns out, the difference between the snapped local rect and the
unsnapped local rect was not just that the former contained snapped
primitives and the latter contained unsnapped primitives, but also that
the former took into account surface inflation for primitives, the
entire clip chain instead of just the primitive's local clip, and
removal of culled primitives. As such, the picture's rects can be wildly
different, even if snapping has been taken care of earlier, and parts of
WebRender have come to rely upon this more accurate representation of a
picture.
Differential Revision: https://phabricator.services.mozilla.com/D46605
--HG--
extra : moz-landing-system : lando
As it turns out, the difference between the snapped local rect and the
unsnapped local rect was not just that the former contained snapped
primitives and the latter contained unsnapped primitives, but also that
the former took into account surface inflation for primitives, the
entire clip chain instead of just the primitive's local clip, and
removal of culled primitives. As such, the picture's rects can be wildly
different, even if snapping has been taken care of earlier, and parts of
WebRender have come to rely upon this more accurate representation of a
picture.
Differential Revision: https://phabricator.services.mozilla.com/D46605
--HG--
extra : moz-landing-system : lando
As it turns out, the difference between the snapped local rect and the
unsnapped local rect was not just that the former contained snapped
primitives and the latter contained unsnapped primitives, but also that
the former took into account surface inflation for primitives, the
entire clip chain instead of just the primitive's local clip, and
removal of culled primitives. As such, the picture's rects can be wildly
different, even if snapping has been taken care of earlier, and parts of
WebRender have come to rely upon this more accurate representation of a
picture.
Differential Revision: https://phabricator.services.mozilla.com/D46605
--HG--
extra : moz-landing-system : lando
We don't need this anymore now that we're always
using the visible rect.
This requires bug 1582528 to properly set the visible area.
Differential Revision: https://phabricator.services.mozilla.com/D46628
--HG--
extra : moz-landing-system : lando
`image-short.png` never exists in the first place when this test was
introduced, so the intermittent happens when the test file shows a
broken image icon and the reference file without, or the other way
around.
I believe the `<img>` is served as a monolithic element to overflow
`<div class="short">`. Use an empty src should suffice.
Differential Revision: https://phabricator.services.mozilla.com/D46640
--HG--
extra : moz-landing-system : lando
In particular: in our frontend code, if we happen to end up with a flex/grid
item with 'display:-moz-box', we want it to take the same sizing codepath as
other flex/grid items, which are all block-level (even though -moz-box is not
exactly block-level itself). Notably, we want to use ComputeSizeFlags::eDefault
for sizing (like we do for real block-level things), because that's necessary
in order for grid items to stretch correctly in their inline axis.
Also: this patch renames "isBlock" to "isBlockLevel" to reflect reality. Its
naming is based on the constant NS_CSS_FRAME_TYPE_BLOCK, which in fact is not
specific to 'display:block' but in fact is for frames that are "block-level in
normal flow" (which I think in practice means block-level and not
out-of-flow). That is documented here:
https://searchfox.org/mozilla-central/rev/7531325c8660cfa61bf71725f83501028178cbb9/layout/generic/ReflowInput.h#51
Differential Revision: https://phabricator.services.mozilla.com/D46539
--HG--
extra : moz-landing-system : lando
Delete `td {width: 25%}` and prefixed multi-column properties in
column-box-alignment-rtl.html because they are not needed.
rtl2.html is rtl.html plus `inline-size: 600px` on the column container.
rtl3.html is rtl.html plus `html { writing-mode: vertical-rl; }`.
Similarly, rtl4.html is rtl2.html plus
`html { writing-mode: vertical-rl; }`.
Note: in rtl2-ref.html and re4-ref.html, I added
`box-sizing: content-box` to `table` because `table` defaults to
`box-sizing: border-box`.
Differential Revision: https://phabricator.services.mozilla.com/D44280
--HG--
rename : layout/reftests/columns/column-box-alignment-rtl-ref.html => layout/reftests/columns/column-box-alignment-rtl-2-ref.html
rename : layout/reftests/columns/column-box-alignment-rtl.html => layout/reftests/columns/column-box-alignment-rtl-2.html
rename : layout/reftests/columns/column-box-alignment-rtl.html => layout/reftests/columns/column-box-alignment-rtl-3.html
rename : layout/reftests/columns/column-box-alignment-rtl.html => layout/reftests/columns/column-box-alignment-rtl-4.html
extra : moz-landing-system : lando
Per the css-contain specification, size contained element must be sized as if
they were empty. The code added to handle size containment shortciruits the
(inline) size calculations, and returns 0. However, an empty <select> element
is rendered as if it contained a and some padding gets added to it by
the UA stylesheet (forms.css). This causes reftest that check that
size-contained <select> elements and empty ones look the same.
This commit fixes this by also shortcircuiting the (inline) size calculations
and returning 0 for empty <select> elements.
Replacing the by a zero width space would not have been enough, since
padding would still be added. It would have been possible to add it in the
inline size calculations of size-contained <select> elements as well, but this
padding serves not purpose when the element is empty, so removing it from there
has no downside, and shortcircuitig both cases is simpler (and marginally
faster) than adding the padding in both cases.
Differential Revision: https://phabricator.services.mozilla.com/D45144
--HG--
extra : moz-landing-system : lando
If the <details> has ::first-letter, insertion.mParentFrame may be
modified by GetInsertionPrevSibling(), and points to nsFirstLetterFrame.
Fortunately, nsFirstLetterFrame's content is the details element. We can
check the content to determine if reframing the <details> is needed.
Also, add a reftest to test that an appended text should apply styles in
details::first-line.
Differential Revision: https://phabricator.services.mozilla.com/D45454
--HG--
extra : moz-landing-system : lando
This is required due to different backends being used for SVG images and canvas.
Differential Revision: https://phabricator.services.mozilla.com/D44154
--HG--
extra : moz-landing-system : lando
To prevent these tests depending on Bug 1102175 to pass because they
specify "direction" or "writing-mode" on <body>, replace <body> with
<main>. This patch doesn't change the meaning of the tests.
Except for shape-outside-margin-box-border-radius-008.html, which is
modified manually, all the other files are modified by the follow Python
3 script.
```
import fileinput
import glob
open_tag_before = '<body class="container">'
open_tag_after = '<main class="container">'
end_tag_before = '</body>'
end_tag_after = '</main>'
match_files = 'layout/reftests/w3c-css/submitted/shapes1/*.html'
with fileinput.FileInput(glob.glob(match_files), inplace=True) as f:
found_open_tag = False
for line in f:
if not found_open_tag:
line_open_tag = line.replace(open_tag_before, open_tag_after)
if line_open_tag != line:
print(line_open_tag, end='')
found_open_tag = True
else:
print(line, end='')
else:
# Continue search for end tag
line_end_tag = line.replace(end_tag_before, end_tag_after)
if line_end_tag != line:
print(line_end_tag, end='')
found_open_tag = False
else:
print(line, end='')
```
Differential Revision: https://phabricator.services.mozilla.com/D44942
--HG--
extra : moz-landing-system : lando
Remove test manifest annotations that specifically target fennec,
or likely target the android 4.3 emulator.
Differential Revision: https://phabricator.services.mozilla.com/D45018
--HG--
extra : moz-landing-system : lando
In the next part, the patch generated by a script removes "-moz" prefix
to all multi-column properties.
However, some of the tests already have standard multi-column properties
specified. To avoid duplicating CSS multi-column rules in these
files (after applying the next part), I manually remove the prefixed
rules beforehand as many as possible.
Differential Revision: https://phabricator.services.mozilla.com/D44869
--HG--
extra : moz-landing-system : lando
Flex containers resolve a main-axis size for each of their flex items, and they
impose this size on the flex items by stomping on the items'
ReflowInput::ComputedISize() or ComputedBSize() data. For cases when we're
stomping on the flex item's block-axis, then this can make us improperly treat
this size as definite (i.e. use it for percent resolution).
The flexbox spec does call out some cases where the item's size *is* supposed
to be considered definite[1], but if we're not in one of those cases, we need
to be careful to treat the size as indefinite even though it's been resolved.
This patch achieves this by:
- adding a flag to FlexItem, which gets set in cases where we know we need to
treat the size as indefinite.
- adding a flag to ReflowInput, which gets set whenever a ComputedBSize is
imposed (if the FlexItem had its flag set).
- adding some code to the ReflowInput percent-resolution codepath to test for
this flag and skip past percent-resolution if it's set.
This patch makes us pass all of the existing testcases in the web-platform-test
"percentage-heights-003.html". This patch also adds a few more subtests
there to exercise cases where the flex container and item have orthogonal
writing-modes.
(Note the XXXdholbert comments in the patch about items being "fully
inflexible" in some cases in order to be treated as having a definite size.
If I were to address that comment here, then we would start failing the
web-platform-test "percentage-heights-005.html", which all browsers currently
pass[2]. Therefore, I'm not adding that restriction at this point.)
[1] https://drafts.csswg.org/css-flexbox/#definite-sizes
[2] https://wpt.fyi/results/css/css-flexbox/percentage-heights-005.html
Differential Revision: https://phabricator.services.mozilla.com/D43705
--HG--
extra : moz-landing-system : lando
Previous commit on this bug bumped up the test from a line-height of 1.5
to 1.8, but that's still not taller than the default widget height on Debian.
But 2.5 does seem to be sufficiently tall to produce a size difference.
Differential Revision: https://phabricator.services.mozilla.com/D44719
--HG--
rename : layout/reftests/forms/input/text/line-height-1.8.html => layout/reftests/forms/input/text/line-height-2.5.html
extra : moz-landing-system : lando
Brian Grinstead
Cosmin Sabou
Andrew Osmond
Glenn Watson
Oriol Brufau
Boris Chiou
Lee Salzman
Daniel Holbert
Morgan Reschenberg
Emilio Cobos Álvarez
Nicolas Silva
Ting-Yu Lin
Tim Nguyen
Frederic Wang
Coroiu Cristina
Narcis Beleuzu
Gurzau Raul
Markus Stange
Emma Malysz
Brendan Dahl
Jeff Muizelaar
Jonathan Kew
Mats Palmgren
Brindusan Cristian
arthur.iakab
Ciure Andrei
Brad Werth
Geoff Brown
L. David Baron
Dorel Luca
Andreea Pavel
Mihai Alexandru Michis
Oana Pop Rus
Noemi Erli
Glenn Watson
Cameron McCormack
Jeff Muizelaar
Bogdan Tara
fantasai
Timothy Nikkel
Florian Rivoal
Luca Greco
Bob Owen
Kris Taeleman
Xidorn Quan