This fixes it and seems to be an acceptable fix... Should I make it conditional
on box-sizing: border-box for completeness? The display frame has border-box
box-sizing, and not having it would be a bug, I'd think...
Differential Revision: https://phabricator.services.mozilla.com/D41939
--HG--
extra : moz-landing-system : lando
* Tweak headers to add title and WPT meta tags.
* Simplify text content and use the Ahem font to avoid "random" result.
* Remove dir-11 since it has already been exported to
mathml/relations/css-styling/dynamic-dir-1.html by @bkardell
* Move dir-10 to mathml/presentation-markup/direction/direction-010.html
* Move dir-9 to mathml/presentation-markup/direction/direction-009.html
and add a .ini file for the corresponding failure expectation (bug 787215).
* Move dir-8 to mathml/presentation-markup/direction/direction-008.html
and add a .ini file for the corresponding failure expectation.
* Move dir-7 to mathml/presentation-markup/direction/direction-007.html
* Move dir-6 to mathml/presentation-markup/direction/direction-006.html
Differential Revision: https://phabricator.services.mozilla.com/D41922
--HG--
rename : layout/reftests/mathml/dir-6-ref.html => testing/web-platform/tests/mathml/presentation-markup/direction/direction-006-ref.html
extra : moz-landing-system : lando
In the previous commit, we expanded layout viewport height but during reflow
the expanded layout viewport size hasn't reflected in
ScrollReflowInput::mContentsOverflowAreas.ScrollableOverflow(). We explicitly
need to use the expanded height to tell whether we need vertical vertical
scrollbars or not.
Note that the expanded layout viewport height should NOT be used for non-overlay
scrollbars cases since, for example, if the content width is specified by
`width: 100%`, the non-overlay vertical scrollbar narrows down the content's
used width a little bit because of the vertical scrollbar width, which in turn
the minimum scale gets bigger because the content's width became bit narrower,
thus the layout viewport size calculated with the minimum scale gets smaller,
then it results the vertical scrollbar no longer needs to be rendered, thus
the minimum scale gets back to the original value, then the vertical scroll
needs to be rendered again, thus this sequence of processes happens repreatedly.
Differential Revision: https://phabricator.services.mozilla.com/D40772
--HG--
extra : moz-landing-system : lando
As a result of the expansion, position:fixed elements are attached to the
expanded layout viewport.
The expanded value is used behind a pref which is enabled by default on nightly
initially, and the pref will be fliped in bug 1571599 on other channels.
scrollbars-in-landscape-content.html still fails since the vertical overlay
scrollbar doesn't appear since we are not yet using the expanded value during
reflow to tell whether we need overlay scrollbars or not. This will be fixed
by the next commit.
Differential Revision: https://phabricator.services.mozilla.com/D40771
--HG--
extra : moz-landing-system : lando
scrollbars-in-landscape-content.html doesn't fail on environments where we don't
use overlay scrollbars because scrollbars for the visual viewport are not
rendered there.
Differential Revision: https://phabricator.services.mozilla.com/D40770
--HG--
extra : moz-landing-system : lando
There needs a position:fixed element at the right bottom to make the test
failure without proper fixes.
Differential Revision: https://phabricator.services.mozilla.com/D40766
--HG--
extra : moz-landing-system : lando
position-fixed-on-half-height-content.html is a test case that the document's
layout viewport contains no visible contents area without scaling.
position-fixed-on-landscape-content.html is a test case that the document's
layout viewport will contain no visible contents area if the document is scaled
down to fit the document to screen size.
position-fixed-on-square-content.html is a test case that the document's layout
viewport will contain no visible contents ares if the document is scaled up to
fit the document to screen size.
The latter two cases currently fail.
Differential Revision: https://phabricator.services.mozilla.com/D40765
--HG--
extra : moz-landing-system : lando
So that the vertical scrollbar on the root element doesn't accidentally appear
because of the expanding the scrollable area.
Differential Revision: https://phabricator.services.mozilla.com/D40763
--HG--
extra : moz-landing-system : lando
* All but the last parameter of test_opentype-limits.html are verified by
mathml/presentation-markup/scripts/underover-parameters-1.html
* test_opentype-fraction.html is equivalent to
mathml/presentation-markup/fractions/frac-parameters-1.html
(however, fraction-1.otf is used by other tests).
* mathml/tests/test_opentype-radical.html is equivalent to
mathml/presentation-markup/radicals/root-parameters-1.html
* test_opentype-scripts.html is equivalent to
mathml/presentation-markup/scripts/subsup-parameters-1.html
* mathml/tests/test_opentype-stack.html is equivalent to
mathml/presentation-markup/fractions/frac-parameters-2.html
Differential Revision: https://phabricator.services.mozilla.com/D41783
--HG--
extra : moz-landing-system : lando
Also includes some documentation gardening for TextDrawTarget on what we don't support.
Differential Revision: https://phabricator.services.mozilla.com/D41272
--HG--
extra : moz-landing-system : lando
In ColumnSetFrame's reflow methods, mCBReflowInput is equal to
mParentReflowInput in most of the cases.
However, a multicol <button> has the HTMLButtonControl as the outermost
frame, where ColumnSetWrapper is its -moz-button-content anonymous
child. In this case, mCBReflowInput is HTMLButtonControl's reflow input.
To get the correct computedBSize of ColumnSetWrapper, we need to use
mParentReflowInput.
Differential Revision: https://phabricator.services.mozilla.com/D41497
--HG--
extra : moz-landing-system : lando
This bug became an unexpected PASS on tier-2 android platform after
landing the fixes for bug 1572197. The fixes in that bug were
specifically to fix this test on windows platforms, so it's not
surprising that it also fixes it on android.
Differential Revision: https://phabricator.services.mozilla.com/D41493
--HG--
extra : moz-landing-system : lando
CORS only works on http channels, so anything else that tries to do a
CORS-enabled request fails catastrophically.
resource:// images are useful for extension developers, so don't perform CORS
checks on them. We may want to also do file:// and fix bug 1565509, while at it,
if we consider it's causing developer pain.
Differential Revision: https://phabricator.services.mozilla.com/D40651
--HG--
extra : moz-landing-system : lando
This annotation matches the one in
layout/reftests/css-invalid/select/reftest.list for
select-disabled-fieldset-1.html (which should really produce the same
rendering, and have the same reference).
This is a one-pixel fuzz on the fieldset border near the bottom right corner.
It's unclear which patch of this pushlog, if any, caused this:
https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=4a49d88894d8d88f87760ac59ae35b2158fab7b2
Probably bug 1404868, which added reftests and tickled something. But it seems
this is not really that patches' fault, so to avoid speculatively backing it
out, with the chance of it not being the offender, let's mark it as fuzzy for
now.
I kept the exact same annotation as the other test, since this goes directly to
central, so it's less risky.
We could try to make it fuzzy-if(Android,9-9,1-1), maybe, though given it seems
to be affected to changes to adjacent reftests that may be unwise.
Also drive-by remove some useless prefixes since user-select was unprefixed in
bug 1492739.
Differential Revision: https://phabricator.services.mozilla.com/D40456
--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
On its own (without the previous patch), this fixes bug 1406291.
Combined with the previous patch, this patch fixes this bug (bug
1420528) when column-span is not enabled (today's configuration), and
also fixes 1411799.
Differential Revision: https://phabricator.services.mozilla.com/D39818
--HG--
extra : moz-landing-system : lando
This patch fixes bug 1420528 when column-span is enabled, and it also
fixes bug 1468654.
Differential Revision: https://phabricator.services.mozilla.com/D39582
--HG--
extra : moz-landing-system : lando
Note that I introduced a blank line to make the intent of the NOTE
clearer, which I had to research. I think it's clear it covers the
three tests below it based on
https://hg.mozilla.org/mozilla-central/rev/53489b3e14f1 and
https://bugzilla.mozilla.org/show_bug.cgi?id=967311#c0 .
I'm also running this test both with and without the column-span pref,
because those two states will be fixed by different patches.
Co-authored-by: L. David Baron <dbaron@dbaron.org>
Co-authored-by: Daniel Holbert <dholbert@cs.stanford.edu>
Differential Revision: https://phabricator.services.mozilla.com/D39581
--HG--
extra : moz-landing-system : lando
These tests were marked as `fails-if(geckoview&&!webrender)`. They are
failing on geckoview because of bug 1558513: there is an offset
between the emojis in the test and reference images.
The reason that they were passing on webrender previously was because
the emojis weren't being drawn at all, so both the test and reference
images were blank. Bug 1562316 fixed the emojis being drawn with
webrender, but bug 1558513 remains (they are still offset).
Differential Revision: https://phabricator.services.mozilla.com/D40191
--HG--
extra : moz-landing-system : lando
We expect ColumnSet and -moz-column-content to be block outside.
If ColumnSets' display style is inherit from ColumnSetWrapper, then a
multicol with "display: inline-block" is going to wrap ColumnSet in a
inline nsLineBox when ColumnSet is added to ColumnSetWrapper, which is
not what we want.
This change fixed [.multicol 4] and [.multicol 6] in
multicol-gap-percentage-001.html with column-span disable, but it can
also fix [.multicol 5] in multicol-gap-percentage-001.html when
column-span is enabled (bug 1489298), so I go ahead and enable the pref
in that test.
Differential Revision: https://phabricator.services.mozilla.com/D39997
--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
This might seem like we are including the parent scale twice because it is also included in mInheritedTransform but FrameLayerBuilder::ChooseScale only incorporates the passed in scale when combining it with a scale computed purely based on the local transform induced by this stacking context item.
This also fixes bug 1564698 and doesn't regress bug 1495163 (the only testcase I can still find for the regressing bug, bug 1415987).
Differential Revision: https://phabricator.services.mozilla.com/D39867
--HG--
extra : moz-landing-system : lando
The reftest-paged tests don't trigger the document clone code-path (I realized
that after writing them), but I guess they don't hurt, the printpreview test
does fail without the previous patch.
Depends on D39053
Differential Revision: https://phabricator.services.mozilla.com/D39054
--HG--
extra : moz-landing-system : lando
After bug 1555060, <tabs> elements should not use dom accessors to get
to the <tab> elements inside a <tabs>. This test was using lastChild,
this patch brings it up to date.
Differential Revision: https://phabricator.services.mozilla.com/D38526
--HG--
extra : moz-landing-system : lando
