For elements that have box-sizing:border-box specified, the aspect ratio
calculation code subtracts out border & padding from any specified property
values.
So, when we create a fake "override" specified property value for a flex item
whose main size has been resolved, we need to add in the border and padding to
account for the fact that they're going to be subtracted out later.
Differential Revision: https://phabricator.services.mozilla.com/D17712
--HG--
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-001-ref.html => layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-007-ref.html
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-001.html => layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-007.html
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-001v.html => layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-007v.html
extra : moz-landing-system : lando
All of these tests have an .ini file indicating a failure for at least one of
them right now, in the copy that lives in the WPT harness, because
- they trigger a scrollbar in the WPT harness
...and:
- the scrollbar is a slightly different size in the reference case vs.
in one of the testcases, e.g. due to a tiny margin being honored (or not)
on the final piece of content.
This patch shrinks the content a bit in these test files so that they all fit
in a 400x400 viewport and won't trigger a scrollbar. I expect this should make
them pass in the WPT harness when they make the roundtrip through our
synchronization process.
Differential Revision: https://phabricator.services.mozilla.com/D16935
--HG--
extra : moz-landing-system : lando
This patch makes us handle calc with percentages when we can convert to
percentages the same way we handle plain percentages in table layout.
We still treat length + percentage as auto (this matches Blink / WebKit as
well). There's one case we differ with Blink / WebKit, which is calc(% + 0px),
which they'd treat as auto instead of a percentage.
I think this is a bug on them (or at least worth some spec clarification). I
filed https://github.com/w3c/csswg-drafts/issues/3482 for that.
In practice what that'd means for us if the WG decides that Blink / WebKit is
right in that case is that we'd need to keep track of whether the calc()
specifies lengths, and return false from ConvertsToPercent if so.
In any case, nothing that would massively change this patch, and I think enough
of an edge case that is not worth blocking on the CSSWG decision here. Though I
could be convinced otherwise of course.
Differential Revision: https://phabricator.services.mozilla.com/D15719
--HG--
extra : moz-landing-system : lando
1. Test the most simple cases when we use max-content/min-content on
width/height/block-size.
* block-size-with-min-or-max-content-1a.html
* block-size-with-min-or-max-content-1b.html
2. Test base cases when we use max-content/min-content on
width/height/block-size inside the table element.
* block-size-with-min-or-max-content-table-1a.html
* block-size-with-min-or-max-content-table-1b.html
3. For {horizontal|vertical} writing mode, we use max-content/min-content on
{min-|max-}{height|width} and {min-|max-}block-size on the inner element.
* hori-block-size-small-or-larger-than-container-with-min-or-max-content-1.html
* vert-block-size-small-or-larger-than-container-with-min-or-max-content-1.html
4. For {horizontal|vertical} writing mode, we use max-content/min-content on
{min-|max-}{height|width} on the outer element (i.e. the container).
* hori-block-size-small-or-larger-than-container-with-min-or-max-content-2a.html
* vert-block-size-small-or-larger-than-container-with-min-or-max-content-2a.html
5. For {horizontal|vertical} writing mode, we use max-content/min-content on
{min-|max-}block-size on the outer element (i.e. the container).
* hori-block-size-small-or-larger-than-container-with-min-or-max-content-2b.html
* vert-block-size-small-or-larger-than-container-with-min-or-max-content-2b.html
Depends on D14320
Differential Revision: https://phabricator.services.mozilla.com/D13485
--HG--
extra : moz-landing-system : lando
Support unprefixed min-content and max-content and treat the prefixed
version as aliases for
1. width, min-width, max-width if inline-axis is horizontal, and
2. height, min-height, max-height if inline-axis is vertical, and
3. inline-size, min-inline-size, max-inline-size, and
4. flex-basis.
Besides, update the test cases to use unprefixed max-content and
min-content.
Depends on D7535
Differential Revision: https://phabricator.services.mozilla.com/D7536
--HG--
extra : moz-landing-system : lando
This class wasn't applied due to a typo, and it's unnecessary anyway -- there's
a separate 'fieldset {...}' CSS rule further down in the file that has the same
effect (hiding the border and the textual contents).
Differential Revision: https://phabricator.services.mozilla.com/D12618
--HG--
extra : moz-landing-system : lando
Note that we don't get this correct for form controls yet, so the -002 test is annotated as "fails" for now.
Differential Revision: https://phabricator.services.mozilla.com/D12617
--HG--
extra : moz-landing-system : lando
Note that Firefox doesn't actually match this expectation yet, so I've added a
'fails' annotation to the manifest with the followup bug number.
Also, this patch makes several other improvements to this test:
- remove red background in testcase. This was making the testcase spuriously
fail in Chrome, because Chrome paints (at least) a 1px-tall background-area
on empty buttons, which meant a 1px-tall red area in the testcase vs. a
1px-tall gray area in the reference case.
- clear floats to prevent them from piling up awkwardly.
- use 'vertical-align:top' to turn off baseline alignment in parts of the test
where the testcase has text and the reference case does not (and where we're
not intentionally testing the baseline's influence on layout).
Depends on D12614
Differential Revision: https://phabricator.services.mozilla.com/D12615
--HG--
extra : moz-landing-system : lando
add fuzzy-if statements to allow reftests to run on new windows10 AMI image
Differential Revision: https://phabricator.services.mozilla.com/D12553
--HG--
extra : moz-landing-system : lando
The modification to nsLayoutUtils::GetFirstLinePosition() is needed because we
need to get the correct first line position from child (i.e. ColumnSet) when
there's an outside bullet on ColumnSetWrapperFrame.
The difference between the two newly added tests is "overflow: hidden" on
the columns.
Differential Revision: https://phabricator.services.mozilla.com/D7009
--HG--
extra : moz-landing-system : lando
adjust fuzzy-if statements for win10 tests that are fialing on new windows 10 ami image
Differential Revision: https://phabricator.services.mozilla.com/D11914
--HG--
extra : moz-landing-system : lando
The current spec says: "If only the X value is given, the Y value
defaults to the same value.", so we should update the behavior.
Besides, we also update the serialization, so we serialization both
specified and computed value by servo. We enable the preference
for all the css-transforms, so some of them are passed now.
Differential Revision: https://phabricator.services.mozilla.com/D10638
--HG--
extra : moz-landing-system : lando
shape-outside, shape-margin, shape-image-threshold have been shipped in Firefox
62. We can remove the preference.
The change in devtools/shared/css/generated/properties-db.js is generated by
"./mach devtools-css-db"
The actual shape-image CORS mode tests in file_shape_outside_CORS.html are
moved into test_shape_outside_CORS.html because we don't need the <iframe>
trick to enable the feature.
Differential Revision: https://phabricator.services.mozilla.com/D10804
--HG--
extra : moz-landing-system : lando
The CSSWG has recently resolved that layout containment
suppress baseline alignment, while size containment does not:
https://github.com/w3c/csswg-drafts/issues/2995
Spec text (https://drafts.csswg.org/css-contain/#containment-layout):
"7. For the purpose of the vertical-align property,
or any other property whose effects need to relate
the position of the containing element's baseline
to something other than its descendants,
the containing element is treated as having no baseline."
And a note in (https://drafts.csswg.org/css-contain/#containment-size):
"Note: size containment does not suppress baseline alignment.
See layout containment for that."
This patch does this change just switching IsContainSize()
by IsLayoutSize() in several places related to baseline alignment
in the source code.
With the patch several WPT tests start to pass. Apart from that,
some of the tests under vendor-imports are updated to follow
the new behavior.
--HG--
extra : amend_source : 05dc9a320afeb1d58981e2bd8bc47b435999f2f9
When contain:size is set for a grid container, ignore sizes from children when
computing own size during layout.
Differential Revision: https://phabricator.services.mozilla.com/D4429
--HG--
rename : layout/reftests/w3c-css/submitted/contain/contain-size-flex-001-ref.html => layout/reftests/w3c-css/submitted/contain/contain-size-grid-001-ref.html
rename : layout/reftests/w3c-css/submitted/contain/contain-size-flex-001.html => layout/reftests/w3c-css/submitted/contain/contain-size-grid-001.html
extra : moz-landing-system : lando
This patch fixes a trivial typo and brings the <link rel="match"> tag into
alignment with what we've already got in our reftest.list file.
Landing as DONTBUILD (skipping builds/tests) because this won't impact test
runs, since this <link> tag is inactive in this local copy of the test.
--HG--
extra : rebase_source : 1b0f6f79d671416fb6e617804158925a10499f17
This test is basically a copy of its -001 variant, with some "float:left"
sprinkled around on contained descendants.
Before this patch, this test had an additional arbitrary sizing difference as
compared to the -001 version -- there's one element that arbitrarily has class
"outer" in the -002 test whereas it has class "inner-lg" in the -001 version.
These classes have different sizing characteristics, which makes a difference
to whether scrollbars show up, because this element is not contained (though it
is a layout container itself).
This patch undoes this arbitrary difference and also adds a "float" class to
make it easier to see which elements we've sprinkled float styling onto.
Differential Revision: https://phabricator.services.mozilla.com/D3826
--HG--
extra : rebase_source : 2630420b4dfc1a307cbfe20447e66fbfecf7b0aa
Andrew Osmond
Andreea Pavel
Daniel Holbert
Emilio Cobos Álvarez
Cristina Coroiu
Boris Chiou
Manuel Rego Casasnovas
Joel Maher
Ting-Yu Lin
Lee Salzman
Gurzau Raul
Jonathan Kew
Mats Palmgren
Jeff Muizelaar
Ryan VanderMeulen
Cosmin Sabou
Gerald Squelart
Henrik Winnemöller