Other browsers don't, plus it blocks work I want to do to query multiple links
at the same time.
Differential Revision: https://phabricator.services.mozilla.com/D52443
--HG--
extra : moz-landing-system : lando
Consider the following case:
<image style="list-style-image: url(foo.png)"></image>
image.style.MozAppearance = "something"
The early return was preventing us from clearing the image.
This is an ancient bug, but it has started happening in the browser chrome
because the lack of lazy frame construction for XUL elements makes us construct
elements with an outdated style, which means in this case that they wouldn't
have the -moz-appearance rule applied yet.
Differential Revision: https://phabricator.services.mozilla.com/D52112
--HG--
extra : moz-landing-system : lando
Consider the following case:
<image style="list-style-image: url(foo.png)"></image>
image.style.MozAppearance = "something"
The early return was preventing us from clearing the image.
This is an ancient bug, but it has started happening in the browser chrome
because the lack of lazy frame construction for XUL elements makes us construct
elements with an outdated style, which means in this case that they wouldn't
have the -moz-appearance rule applied yet.
Differential Revision: https://phabricator.services.mozilla.com/D52112
--HG--
extra : moz-landing-system : lando
So, we don't create a stacking context for this case. Besides, we also
make sure FindAnimationsForCompositor() work properly for motion-path if
offset-path is not effective (i.e. none and no animations).
Differential Revision: https://phabricator.services.mozilla.com/D51895
--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
This matches the WebKit implementation, and is clearly a violation of the rules
we generally use for ranges in CSS.
But it seems to be depended-on legacy behavior, see the linked WebKit bug, this
bug, and bug 1593317.
Differential Revision: https://phabricator.services.mozilla.com/D51539
--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
Previously, WR needed to update and track dependencies for all
allocated picture cache tiles in the virtual display port. This
means doing extra CPU work (dependency updates) and in some cases,
extra GPU work (larger off-screen child surfaces) than are strictly
required.
With this patch, each tile determines if it is currently visible in
pre_update. If the tile isn't visible, we skip doing dependency
updates until it is on screen again. More importantly, this is
used to reduce the world culling rect for primitive preparation,
which also means large child surfaces only require allocations
large enough to enclose the visible tiles, rather than the
display port.
Differential Revision: https://phabricator.services.mozilla.com/D51006
--HG--
extra : moz-landing-system : lando
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
