The "-auto" and "-scroll" variants of this test used to be expected to mismatch
("!="), but our behavior changed with stylo such that they started matching, so
it was marked as "fails !=". But now we've decided that the post-stylo
matching behvavior is actually correct, so this patch is changing the manifest
line to "==" so that the expectation is that they match.
This is primarily to fix sizing of 'box-decoration-break:clone' inlines,
but also some 'slice' edge cases by recognizing more break opportunities,
and to improve sizing when BIDI-continuations are involved.
Differential Revision: https://phabricator.services.mozilla.com/D32915
--HG--
extra : rebase_source : 45a76e55e3eb5ac41fd60b11eb2acce24c6a1dd1
extra : amend_source : d8980854573522ddf761f0cf036aaa4ee0d96cac
The only different part is to resolve intrinsic image size. This patch
implements explicit requirements of the spec, but an edge case is tricky.
It's not clear per spec what the intrinsic image size is for an SVG
without explicit width/height, something like:
<svg>
<image href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg'><rect width='40' height='90' fill='red' /></svg>"/>
</svg>
Chrome treats the intrinsic size of the href svg as the default size of
a replaced element (300x150), our image/VectorImage.cpp doesn't resolve
size in this case.
We can handle this particular case in some seperate bug if necessary, I think.
Differential Revision: https://phabricator.services.mozilla.com/D32415
--HG--
extra : moz-landing-system : lando
We previously (in bug 1491235) adjusted some utility code to make
layout-contained frames behave as if they have no baseline.
But that's not sufficient. To make frames fully report lack-of-a-baseline,
we now do the following for layout-contained frames, as of this patch:
(a) We now leave the ReflowOutput outparam's BlockStartAscent member at its
default value (which is what we do for frames without a baseline like
e.g. nsCheckboxRadioFrame and nsHTMLCanvasFrame). And if the parent cares
about the baseline, it'll then ask directly, using a baseline getter.
(b) We now return 'false' in more implementations of bool-returning
baseline-getter-methods (where 'false' indicates 'no baseline').
(c) We now return the margin-box-bottom edge, in the nscoord-returning
'GetLogicalBaseline()' getter method. (We typically do this by deferring
to the inherited method, which ultimately comes from nsFrame's
implementation). It's appropriate to use the margin-box-bottom edge when
there's no baseline, per the definition of 'vertical-align: baseline',
here: https://drafts.csswg.org/css2/visudet.html#propdef-vertical-align
Depends on D32182
Differential Revision: https://phabricator.services.mozilla.com/D32183
--HG--
extra : moz-landing-system : lando
In particular:
- In contain-layout-suppress-baseline-002.html, the test currently indirectly
relies on the 50px-tall-canvas being the tallest thing in each flex
container. This isn't robustly true (and in fact on windows, the textarea is
taller at 50.8px tall). So I'm adjusting this test so that it no longer has a
hardcoded flex container size and no longer depends on this.
- In contain-layout-baseline-005.html and its reference case, we need to
explicitly specify 'vertical-align:baseline' to test baseline-alignment,
because some of its tested form controls have other UA-stylesheet-provided
default values of 'vertical-align'.
(e.g. <select multiple> defaults to 'vertical-align:text-bottom")
- Also: in that same test, we need to reduce the width of the an <input>
textfield -- otherwise, it and the other elements on its line may not fit and
may linewrap, which prevents us from effectively testing baseline-alignment
on the linewrapped element.
- In contain-layout-button-001.html, the expectation was not correct. Before
this patch, the test expects that a layout-contained button will have the
same baseline as an empty button, and that's an invalid expectation. An empty
button uses a point inside of its content-box as its baseline, whereas a
layout-contained element *has no baseline*, which means that it does
'vertical-align:baseline' alignment by aligning its own margin-bottom edge
with the parent's baseline, per
https://drafts.csswg.org/css2/visudet.html#propdef-vertical-align
So, I'm amending the test to have this expectation and updating its meta tags
to reference the updated expectation and with a reference to that spec text.
Firefox fails the amended contain-layout-button-001.html test, so this patch
adds a .ini file to reflect that failure. The next patch in this series will
fix our implementation to make us pass the test, and will remove the .ini file.
Chrome also fails the amended contain-layout-button-001.html tests, and I filed
https://bugs.chromium.org/p/chromium/issues/detail?id=965740 on them with an
explanation.
Differential Revision: https://phabricator.services.mozilla.com/D32182
--HG--
extra : moz-landing-system : lando
We previously (in bug 1491235) adjusted some utility code to make
layout-contained frames behave as if they have no baseline.
But that's not sufficient. To make frames fully report lack-of-a-baseline,
we now do the following for layout-contained frames, as of this patch:
(a) We now leave the ReflowOutput outparam's BlockStartAscent member at its
default value (which is what we do for frames without a baseline like
e.g. nsCheckboxRadioFrame and nsHTMLCanvasFrame). And if the parent cares
about the baseline, it'll then ask directly, using a baseline getter.
(b) We now return 'false' in more implementations of bool-returning
baseline-getter-methods (where 'false' indicates 'no baseline').
(c) We now return the margin-box-bottom edge, in the nscoord-returning
'GetLogicalBaseline()' getter method. (We typically do this by deferring
to the inherited method, which ultimately comes from nsFrame's
implementation). It's appropriate to use the margin-box-bottom edge when
there's no baseline, per the definition of 'vertical-align: baseline',
here: https://drafts.csswg.org/css2/visudet.html#propdef-vertical-align
Depends on D32182
Differential Revision: https://phabricator.services.mozilla.com/D32183
--HG--
extra : moz-landing-system : lando
The relevant definition in the spec;
https://drafts.csswg.org/css-device-adapt/#min-scale-max-scale
Before this change, if both of initial-scale and maximum-scale are negative,
both values are clamped to 0.25. Whereas with this change, negative scale
values are treated as if it's not specified so that initial-scale value is
automatically calculated based on the layout viewport size.
negative-initial-and-maximum-scale.html is a test case for the case.
Also with this change, initial-scale values are going to be clamped to the
range [0.25, 10] during parsing it so that initial-scale-0.html and
initial-scale-100.html need to be modified, now the former is scaled by 0.25x,
the latter is scaled by 10x.
(Before this change, initial-scale=0 and initial-scale=100 were treated as
invalid scale values in nsViewportInfo::ConstrainViewportValues[1])
[1] https://searchfox.org/mozilla-central/rev/6c9f60f8cc064a1005cd8141ecd526578ae9da7a/dom/base/nsViewportInfo.cpp#15,19
Differential Revision: https://phabricator.services.mozilla.com/D32098
--HG--
extra : moz-landing-system : lando
This patch contains two isolated changes related to upcoming picture
caching improvements. Specifically:
* Determine the blit reason for stacking contexts with clips
earlier, during scene building. This simplifies the code and
allows better detection of redundant stacking contexts.
* Centralize the code for pushing batch instances into a small
number of places. This will simplify the switch to adding
a single primitive to multiple batch lists, in the case of
dirty regions with different batchers.
Differential Revision: https://phabricator.services.mozilla.com/D31898
--HG--
extra : moz-landing-system : lando
We don't store post-transform overflow areas for frames within preserve-3d, but we do store pre-transform overflow areas.
Rather than just recomputing the changed overflow for the root, we should recompute overflows for all ancestors up to the 3d root.
Differential Revision: https://phabricator.services.mozilla.com/D31213
--HG--
extra : moz-landing-system : lando
This is the main performance improvement, and means that we no longer have to iterate all the cells for each column.
It has a couple of behaviour changes:
The first is that we no longer apply stacking context effects (like opacity) to column and column group backgrounds.
I believe this is correct as per both CSS2.1 Appendix E, and css-tables-3 (quoted in nsTableColFrame::BuildDisplayList).
This matches the behaviour of blink and WebKit.
We also previously created items in column,row ordering, whereas now they will be in row,column. In cases where two cells
overlap (using rowspan and colspan to extend multiple neighbours in to the same place) this can render backgrounds in a
different order, but the new behaviour matches blink and WebKit.
Differential Revision: https://phabricator.services.mozilla.com/D29280
--HG--
extra : moz-landing-system : lando
This also changes behaviour a bit, previously we interleaved column and column group backgrounds. where we now put all the column group backgrounds behind all columns.
I believe this is the correct ordering as per CSS2.2 Appendix E.
Column backgrounds can overlap when using 'span', and we now render this in a different order, but this matches what other browsers do.
Differential Revision: https://phabricator.services.mozilla.com/D29278
--HG--
extra : moz-landing-system : lando
This affects a number of our existing reftests, so we'll need to update those
to not expect auto-hyphenation of a sentence-initial (capitalized) word.
(Hyphenation behavior is not sufficiently well-specified for this to be tested
at the WPT level, so we just use Gecko-specific reftests.)
Differential Revision: https://phabricator.services.mozilla.com/D30912
--HG--
extra : moz-landing-system : lando
CSS containment is enabled on early beta or earlier. Using
"default-preferences" to flip column-span pref overrides CSS
containment's pref at the first line in the reftest.list, which make the
two test fail on late beta.
Differential Revision: https://phabricator.services.mozilla.com/D30674
--HG--
extra : moz-landing-system : lando
multicol-span-000.xht passes because the id in
<div id="column-span">123456</div>
was incorrect replaced by "-moz-column-span". Strip the "-moz" prefix
fixed it.
Except failures.list, other files were modified mechanically by running
import-tests.py against https://github.com/web-platform-tests/wpt commit
15f199c91a72b0d51bf0a12b3b77827ecb5051ff (the same commit in
received/import.log).
Differential Revision: https://phabricator.services.mozilla.com/D30406
--HG--
extra : moz-landing-system : lando
Also, build gPrefixRegexp and replace lines only if gPrefixedProperties
is non-empty. Otherwise, the import tests are messed up due to bogus
gPrefixRegexp.
Differential Revision: https://phabricator.services.mozilla.com/D30405
--HG--
extra : moz-landing-system : lando
Add multicol-width-004.html and multicol-width-005.html to test "width:
min-content" and "width: max-content" with column-span:all children.
There's no size containment in these tests.
Note it may be worth to reuse nsBlockFrame's mCachedMinISize and
mCachedPrefISize to cache intrinsic size for ColumnSetWrapperFrame, but
this can be done separately.
Differential Revision: https://phabricator.services.mozilla.com/D29616
--HG--
extra : moz-landing-system : lando
ColumnSetFrame always tries to reflow column content regardless of it's
dirtiness. Making ColumnSetWrapperFrame's children dirty can have the
same effect.
Differential Revision: https://phabricator.services.mozilla.com/D29435
--HG--
extra : moz-landing-system : lando
Per bug 1487927, margin-bottom value is not always rendered as expected
with our column balancing algorithm. I'd like to remove it from
column-balancing-nested-001.html, and add <br> to separate each cases.
Differential Revision: https://phabricator.services.mozilla.com/D30287
--HG--
extra : moz-landing-system : lando
ColumnSetFrame always tries to reflow column content regardless of it's
dirtiness. Making ColumnSetWrapperFrame's children dirty can have the
same effect.
Differential Revision: https://phabricator.services.mozilla.com/D29435
--HG--
extra : moz-landing-system : lando
