Expect forced-colors-mode-backplate tests to fail because they were passing for the wrong reason,
and the backplate is now properly applied, causing them to fail.
Remove tests for field and fieldtext from color-valid.html because they are tested again
in system-color-valid.html.
Differential Revision: https://phabricator.services.mozilla.com/D66879
--HG--
extra : moz-landing-system : lando
- Add enum AllowImportRules to CSS parsing.
- `replaceSync()` will skip over @import rules and continue parsing.
- `replace()` will skip over @import rules and continue parsing.
- `insertRule()` will throw a syntax error on @import rules.
- Modify WPT test cases to reflect these changes.
Differential Revision: https://phabricator.services.mozilla.com/D61882
--HG--
extra : moz-landing-system : lando
Other browsers allow this and the spec doesn't really disallow it, so fix it,
add a test and carry on.
Differential Revision: https://phabricator.services.mozilla.com/D65107
--HG--
extra : moz-landing-system : lando
This is probably an old-ish bug made more frequent by the font loading
optimizations.
PostRebuildAllStyleData is a bit of a misnomer, but was always calling
ClearCachedData() on the style set, even if we weren't guaranteed to restyle
every element.
This means both wasted work and correctness issues (as the "uses <rare-feature>"
bits are cleared during this call, on the assumption that we'll then visit all
elements and that'd recompute it properly).
For now, unify a bit the different code paths and only clear these bits if we're
guaranteed to restyle all elements.
I should rename this to something better in a follow-up, and ideally also
decouple the ClearCachedData() calls a bit...
Differential Revision: https://phabricator.services.mozilla.com/D65740
--HG--
extra : moz-landing-system : lando
This should be less confusing. This is not supported outside of chrome:// or
user-agent stylesheets so we can name this however we want.
Differential Revision: https://phabricator.services.mozilla.com/D65605
--HG--
extra : moz-landing-system : lando
I think this should work for the animation throttling stuff.
Opacity works on the element tree, so I think this is sound.
Differential Revision: https://phabricator.services.mozilla.com/D64441
--HG--
extra : moz-landing-system : lando
Removing unused arguments and so on.
The origin can always be inferred from the stylesheet so it wasn't being used.
Differential Revision: https://phabricator.services.mozilla.com/D64150
--HG--
extra : moz-landing-system : lando
Removing unused arguments and so on.
The origin can always be inferred from the stylesheet so it wasn't being used.
Differential Revision: https://phabricator.services.mozilla.com/D64150
--HG--
extra : moz-landing-system : lando
This used to be needed for Gecko interop, but now all this is in the Rust side
so we no longer need it.
Depends on D63861
Differential Revision: https://phabricator.services.mozilla.com/D63863
--HG--
extra : moz-landing-system : lando
The heuristic is that we show focus outlines for unknown or key focus, and not
for mouse / touch.
This is probably not the final heuristic we take, but this allows people to play
with it and file bugs.
Once this is mature enough we should remove :-moz-focusring in favor of
:focus-visible.
Differential Revision: https://phabricator.services.mozilla.com/D63861
--HG--
extra : moz-landing-system : lando
This used to be needed for Gecko interop, but now all this is in the Rust side
so we no longer need it.
Depends on D63861
Differential Revision: https://phabricator.services.mozilla.com/D63863
--HG--
extra : moz-landing-system : lando
The heuristic is that we show focus outlines for unknown or key focus, and not
for mouse / touch.
This is probably not the final heuristic we take, but this allows people to play
with it and file bugs.
Once this is mature enough we should remove :-moz-focusring in favor of
:focus-visible.
Differential Revision: https://phabricator.services.mozilla.com/D63861
--HG--
extra : moz-landing-system : lando
This also fixes some backwards logic in nsBlockFrame::ReflowDirtyLines, and adds
some static assertions to nsGenericHTMLElement that almost cause a very subtle
bug.
Depends on D63792
Differential Revision: https://phabricator.services.mozilla.com/D63793
--HG--
extra : moz-landing-system : lando
* Use debug_unreachable for really unreachable code (having a release
unreachable!() there gives us little to no benefit, as a borked union can
already confuse us into reading an arbitrary pointer as a CalcPercentage).
* Avoid a clone of the calc variant when clamping. We only need to mutate the
clamping mode. This was the only clamp_to_non_negative function that didn't
consume the value.
Differential Revision: https://phabricator.services.mozilla.com/D63584
--HG--
extra : moz-landing-system : lando
We never fast-reject numbers (because they could be part of a product). Without
this refactoring we'd accept stuff like calc(10) and crash during the evaluation
for obvious reasons.
Differential Revision: https://phabricator.services.mozilla.com/D63401
--HG--
extra : moz-landing-system : lando
So as to avoid allocating an intermediate tree in Rust to resolve
`<length-percentage>` values.
Differential Revision: https://phabricator.services.mozilla.com/D63399
--HG--
extra : moz-landing-system : lando
This is the meat of the patch. There are a couple improvements done in a couple
later patches which should hopefully be straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D63397
--HG--
extra : moz-landing-system : lando
We'll have different leaf nodes as we progress in the value computation stage.
Differential Revision: https://phabricator.services.mozilla.com/D63396
--HG--
extra : moz-landing-system : lando
We'll use `CalcNode` as the specified value representation for <length> and
<length-percentage> values, so they'll have to implement ToCss.
There's one minor issue (two calls to to_css() instead of to_css_impl() which
are addressed later in the series).
Differential Revision: https://phabricator.services.mozilla.com/D63395
--HG--
extra : moz-landing-system : lando
This assert was wrong. The assert may fire if we resurrect the node from a
different thread and insert a kid fast enough.
We allow resurrecting nodes (bumping the nodes from zero to one) to avoid
allocation churn.
In particular, while the thread dropping the node gets to read the children (so
after the fetch_sub from the refcount, but before the read() of the children),
another thread could plausibly bumped the refcount back, and added a children.
This is a very big edge case of course, but I'm kinda sad I hadn't realized
before.
Differential Revision: https://phabricator.services.mozilla.com/D63286
--HG--
extra : moz-landing-system : lando
I don't think we want to keep the ugly widget hacks forever. Let me know if
you'd rather keep the property behind a pref but I don't think there's a point
in doing that.
Differential Revision: https://phabricator.services.mozilla.com/D62649
--HG--
extra : moz-landing-system : lando
I don't think we want to keep the ugly widget hacks forever. Let me know if
you'd rather keep the property behind a pref but I don't think there's a point
in doing that.
Differential Revision: https://phabricator.services.mozilla.com/D62649
--HG--
extra : moz-landing-system : lando
Daniel Varga
Sam Mauldin
Philipp Zech
Erik Nordin
Emilio Cobos Álvarez
Makoto Kato
Csoregi Natalia
Morgan Reschenberg
Hiroyuki Ikezoe
Razvan Maries
Cosmin Sabou
Noemi Erli
Jonathan Kew
Tim Nguyen
Ciure Andrei
Bogdan Tara
Cameron McCormack