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
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
Cosmin Sabou
Mats Palmgren
Andrew Osmond