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
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
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
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
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
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
This patch was generated by running each of the scripts in the folder
layout/reftests/w3c-css/submitted/text-decor-3/support/
(This patch also includes a manual edit to reftest.list, to annotate some Win7
fuzziness that was caused by the new choice of font for a set of tests here.)
Differential Revision: https://phabricator.services.mozilla.com/D44258
--HG--
extra : moz-landing-system : lando
Also, adjust the scripts to leave behind a note in each generated HTML file, to
tell the reader that the file is auto-generated.
Differential Revision: https://phabricator.services.mozilla.com/D44257
--HG--
extra : moz-landing-system : lando
Run broken-column-rule-1.html with column-span enabled because it was
regressed by Bug 1548100 Part 2, but fixed by this patch.
Differential Revision: https://phabricator.services.mozilla.com/D41907
--HG--
extra : moz-landing-system : lando
After enabling column-span, ColumnSet becomes an anonymous child under
ColumnSetWrapperFrame. It doesn't need to handle border and padding,
containment, and non-auto block-size. ColumnSet's final block-size is
simply the union of ::-moz-column-content frames' rects.
However, we should extend ColumnSet's block-size to consume the
available block-size if the ColumnSetWrapper's block-size is constrained
so that the column rules are drawn to the block-end edge of the multicol
container.
Differential Revision: https://phabricator.services.mozilla.com/D39060
--HG--
rename : testing/web-platform/meta/css/css-multicol/multicol-breaking-000.html.ini => testing/web-platform/meta/css/css-multicol/multicol-rule-nested-balancing-001.html.ini
rename : testing/web-platform/meta/css/css-multicol/multicol-breaking-000.html.ini => testing/web-platform/meta/css/css-multicol/multicol-rule-nested-balancing-002.html.ini
rename : testing/web-platform/meta/css/css-multicol/multicol-breaking-000.html.ini => testing/web-platform/meta/css/css-multicol/multicol-span-all-rule-001.html.ini
extra : moz-landing-system : lando
After enabling column-span, ColumnSet becomes an anonymous child under
ColumnSetWrapperFrame. It doesn't need to handle border and padding,
containment, and non-auto block-size. ColumnSet's final block-size is
simply the union of ::-moz-column-content frames' rects.
However, we should extend ColumnSet's block-size to consume the
available block-size if the ColumnSetWrapper's block-size is constrained
so that the column rules are drawn to the block-end edge of the multicol
container.
Differential Revision: https://phabricator.services.mozilla.com/D39060
--HG--
rename : testing/web-platform/meta/css/css-multicol/multicol-breaking-000.html.ini => testing/web-platform/meta/css/css-multicol/multicol-rule-nested-balancing-001.html.ini
rename : testing/web-platform/meta/css/css-multicol/multicol-breaking-000.html.ini => testing/web-platform/meta/css/css-multicol/multicol-rule-nested-balancing-002.html.ini
rename : testing/web-platform/meta/css/css-multicol/multicol-breaking-000.html.ini => testing/web-platform/meta/css/css-multicol/multicol-span-all-rule-001.html.ini
extra : moz-landing-system : lando
If the embedding element uses `object-fit`, then that indicates it's precisely
positioning and/or sizing the embedded SVG document's viewport to fit inside
the embedding element's content area. So, when the internal SVG viewBox
changes, then the embedding element needs to redo that positioning/sizing. For
now, this specifically requires a reflow (and in particular, the nsViewManager
adjustments at the end of nsSubDocumentFrame::Reflow).
Differential Revision: https://phabricator.services.mozilla.com/D37910
--HG--
extra : moz-landing-system : lando
Update the existing reftests to not use 3 valued syntax.
I run the script to update the syntax in
`layout/reftests/w3c-css/submitted/images3/*`,
`layout/reftests/w3c-css/submitted/masking/*`,
`layout/reftests/xul/*`, and
`layout/reftests/webm-video/*`:
```
function rename() {
find layout/reftests/\
-type f\
! -path "./obj*"\
! -path "./.git"\
! -path "./.hg"\
\( -name "*.html" -or\
-name "*.xul" \)\
-exec sed -i -e "s/$1/$2/g" "{}" \;
}
rename "object-position: top 3px center" "object-position: top 3px left 50%"
rename "object-position: center right 25%" "object-position: top 50% right 25%"
```
For `layout/reftests/svg/svg-integration/clip-path/*`, I just manually
update them.
Differential Revision: https://phabricator.services.mozilla.com/D37125
--HG--
extra : moz-landing-system : lando
Note that this is an imperfect implementation, in that it doesn't exactly
match the sizing behavior of a truly empty `<select>` element. I've filed
followup bug 1562057 on that. However, the behavior that's implemented
here *does* successfully make us ignore a `<select>`'s contents for sizing
purposes, and it's much better than what we do currently (which is pretty
broken via inheriting a partial `contain:size` implementation from our
parent class, nsBlockFrame).
Differential Revision: https://phabricator.services.mozilla.com/D36253
--HG--
extra : moz-landing-system : lando