Based on the update of github.com/w3c/csswg-drafts/issues/5084,
a 0/0 ratio will serialize as 0/0 in all value stages.
Differential Revision: https://phabricator.services.mozilla.com/D93182
Which allows to run CSS.supports in chrome/user-agent context. We should
probably add a couple more tweaks for stuff like quirks or what not (the
`ParsingMode` enum), but that seem lower priority.
I only added the one-value version of CSS.supports because it should be enough
and supporting the two value version required a bit of awkward code due to when
we parse the CSS property name right now.
Differential Revision: https://phabricator.services.mozilla.com/D92585
So that skip_children(), which just pops the stack and is used by the
dynamic media query evaluation code, works as it should.
Differential Revision: https://phabricator.services.mozilla.com/D92717
But discard it when backplating behind text, so that text is readable.
This should be uncontroversial... Dealing with widgets is a bit harder
so TBD.
Differential Revision: https://phabricator.services.mozilla.com/D91779
This renames the internal -moz-math-script-level property in order to
prepare for full math-depth support. Currently, the property is guarded
under a disabled-by-default flag, so there should be no observable
behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D91285
This patch renames the internal -moz-math-display to math-style and
exposes it under the layout.css.math-style.enabled preference. The
initial value becomes "normal" but that does not affect the default
MathML behavior since the UA style sheet sets the math-style property
explicitly on <math> tags. WPT tests are updated to use the syntax
approved by the CSSWG.
Intent to prototype: https://groups.google.com/forum/#!msg/mozilla.dev.platform/1hQQ7ISudGo/_yLEckEeBQAJ
Differential Revision: https://phabricator.services.mozilla.com/D90731
This is mostly a band-aid, though it also serves sorta as an
optimization.
The issue here is basically bug 1393323. By re-cascading, right now we
can't come up with the right before-change style if CSSOM has mutated
the rules. We really need a better way to come up with the before-change
style, as the animation-only traversal is not really sustainable (nor
fast, for that matter...).
But this avoids crashing and prevents the regression easily, so let's do
that for now.
Differential Revision: https://phabricator.services.mozilla.com/D90700
Adjust is-where-parsing.html to work with both the new and old behavior,
and add a test for the new behavior.
Depends on D90049
Differential Revision: https://phabricator.services.mozilla.com/D90050
Per spec we shouldn't behave differently depending on how we blocked the
image/object/etc.
This may have made sense in the past when ad blockers were implemented
via nsIContentPolicy, but I think nowadays it doesn't make sense, and
showing fallback is preferred.
There's a couple extra cleanups we can do after this lands, like
removing HTMLImageElement.imageBlockingStatus and simplifying a bit that
code. But I'll do that in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D89912
We treat it exactly the same as -moz-broken. The pseudo-class is not
exposed to content, so I don't think we have a reason to keep it around.
Differential Revision: https://phabricator.services.mozilla.com/D89904
When entering or leaving fullscreen in youtube, we spend most of the
restyle time diffing custom properties, under IndexMap::eq.
Turns out that IndexMap equality is not order-aware, and thus you
actually need to make a hashmap lookup for each entry in the map, which
is unnecessarily inefficient.
Instead, just compare the iterators.
See https://github.com/bluss/indexmap/issues/153.
Differential Revision: https://phabricator.services.mozilla.com/D89434
Add -moz-inert and -moz-script-level to the set of internal properties
that aren't included in "all".
-moz-inert may need to be uncacheable in the future if we make it not
change the pointer-events computed value. Left a comment to that effect.
Differential Revision: https://phabricator.services.mozilla.com/D87115
This is strictly better and more flexible, but can change specificity so
have a pref in case it causes trouble. I doubt it will though, the
specificity rules of :is() make more sense, and my gut feeling is that
:-moz-any is not very used on the wild.
Make it early-beta-or-earlier for now to minimize risk, once this is on
nightly for a bit we can enable it everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D86696
Also, for changes in CSS declarations, like changing
cssRules[i].style.color or something, we end up avoiding a lot of the
work we were doing.
This page still trips us in the sense that they add a stylesheet, then
call getBoundingClientRect(), then insert more rules in the stylesheet,
which causes us to rebuild a lot of the cascade data.
We could try to detect appends to the last stylesheet on the list or
something I guess, and avoid rebuilding the cascade data in some cases.
Depends on D85615
Differential Revision: https://phabricator.services.mozilla.com/D85616
This is the first of what will likely be a couple patches for
cross-fade's implementation. Bug 546052 tracks it's complete
implementation.
Differential Revision: https://phabricator.services.mozilla.com/D81889
-moz-inert CSS property reflects inert subtrees concept and can be used to implement HTML:dialog element and HTML:inert attribute
Differential Revision: https://phabricator.services.mozilla.com/D81701
As per the following change to the spec:
6b3d7240b5
The additional failure annotation is added because we don't currently treat
text-combine-upright as non-animatable and this patch exposes the existing bug
(bug 1654195).
Differential Revision: https://phabricator.services.mozilla.com/D84308
This fixes performance issues when there's a massive number of rules and
a massive DOM.
Instead of going through all rules for all the DOM, we now look stuff in
hashmaps.
Differential Revision: https://phabricator.services.mozilla.com/D83506
Instead add a pseudo-class that does the expected size="" attribute parsing.
Removing the Gtk-specific rule setting the text color since it doesn't
seem to have any effect currently.
Differential Revision: https://phabricator.services.mozilla.com/D83448
Forgot to follow up on these two remaining non-standard values that may have
been being used to reset a <meter> or <input type=number> back to its
original appearance, but which telemetry showed no usage of.
Differential Revision: https://phabricator.services.mozilla.com/D83598
