We add a new file, AspectRatio.cpp, to definte the method,
ComputeRatioDependentSize. So we don't have to move this function to
WritingModes.h
Besides, we miss the forward declaration of IPC::ParamTraits, so add it
into AspectRatio.h.
Differential Revision: https://phabricator.services.mozilla.com/D95822
The browser currently only enables plugin behavior for Flash and our internal test plugins. This patch replaces support for those plugins with a simple fallback that shows a transparent region where the plugin would have been. It removes the file system search(es) for the plugin dynamic libraries and short-circuits the logic to determine if plugins should do something special -- all implementations now behave the same in the presence of plugin elements.
The new behavior is:
1. If the <object> or <embed> element lists a type of something other than "x-shockwave-flash" or "x-test" then the behavior is unchanged. This means that non-plugin types behave properly and unknown types (for example, typos) are also unaffected (they reduce to 0x0 elements).
2. If the <object> element has an HTML fallback in the DOM (see spec for <object> elements) then the fallback is always shown.
3. Otherwise, the element is shown as a transparent region with the size specified in attributes.
Differential Revision: https://phabricator.services.mozilla.com/D95902
The browser currently only enables plugin behavior for Flash and our internal test plugins. This patch replaces support for those plugins with a simple fallback that shows a transparent region where the plugin would have been. It removes the file system search(es) for the plugin dynamic libraries and short-circuits the logic to determine if plugins should do something special -- all implementations now behave the same in the presence of plugin elements.
The new behavior is:
1. If the <object> or <embed> element lists a type of something other than "x-shockwave-flash" or "x-test" then the behavior is unchanged. This means that non-plugin types behave properly and unknown types (for example, typos) are also unaffected (they reduce to 0x0 elements).
2. If the <object> element has an HTML fallback in the DOM (see spec for <object> elements) then the fallback is always shown.
3. Otherwise, the element is shown as a transparent region with the size specified in attributes.
Differential Revision: https://phabricator.services.mozilla.com/D95902
The spec text has been improved a while ago, so I think we should do
this. This keeps the current moz-focusring behavior when the pref is
disabled, but when enabled it becomes effectively an alias of
focus-visible.
Differential Revision: https://phabricator.services.mozilla.com/D96697
New versions have shrink_to_fit(). This also explicitly requests the
"std" feature, because otherwise autocfg fails to pass the panic=abort
flag to rustc and it chokes.
Depends on D96130
Differential Revision: https://phabricator.services.mozilla.com/D96131
In order to determine whether classes or ids are case insensitive we
need the document quirks mode. The sheet quirks mode almost always
matches, but may not match when sheets are added by privileged APIs.
Differential Revision: https://phabricator.services.mozilla.com/D95061
This fixes the failures in bug 1671573 and just works thanks to the
invalidation improvements I did for :is / :where.
Added a couple tests for invalidation which is the tricky bit. 001 is a
very straight-forward test, 002 is the :is test but with :is() replaced
by double-:not().
This also fixes default namespaces inside :is() / :where(), which are
supposed to get ignored, but aren't. Added tests for that and for the
pre-existing :not() behavior which Chrome doesn't quite get right.
Differential Revision: https://phabricator.services.mozilla.com/D94142
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Otherwise on Windows, we have a ColorID::Scrollbar but not any of the other scrollbar part
colors, and the Windows-provided value for Scrollbar doesn't work well
with the default values for the other scrollbar parts that come from the
non-native theme.
Differential Revision: https://phabricator.services.mozilla.com/D93728
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
The math-depth implementation is refined to take into account the
ScriptPercentScaleDown and ScriptScriptPercentScaleDown constants (if the
parent's first valid font has a MATH table) in order to calculate the
scale factor between math-deth 0 and 1, and between 0 and 2 respectively.
Behavior is unchanged if the legacy scriptsizemultiplier attribute is
specified or if no MATH table is available.
The preference layout.css.math-depth.enabled remains disabled in nightly
until the remaining bit (support for font-size: math) is implemented in
bug 1667090.
Differential Revision: https://phabricator.services.mozilla.com/D91604
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
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 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 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 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 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 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
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
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
We calculate the size of ratio-dependent axis by aspect-ratio while
initializing its ReflowInput, for most of the basic block cases.
This patch doesn't include "Automatic content-based minimum sizes",
which will be handled later. Besides, replaced elements will be handled
later as well.
We don't pass abspos-004.tentative.html because there is still a
spec issue: https://github.com/w3c/csswg-drafts/issues/5151.
For other tests we didn't pass (e.g. block-aspect-ratio-009.tentative.html,
or replaced-element-00x.tentative.html), we fix them later.
Besides, in this patch, we don't handle the case if the size of
ratio-determining axis uses intrinsic size keywords (which needs to be
calculated by its content size). We will fix this in the following bug
(Bug 1646100).
Differential Revision: https://phabricator.services.mozilla.com/D78964
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
CLOSED TREE
Backed out changeset 17df14f0b129 (bug 1200896)
Backed out changeset 5d9e9bd12cd2 (bug 1200896)
Backed out changeset 7f016de8d52f (bug 1200896)
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
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
Uses of `-moz-appearance: none` are changed to `appearance: none`.
Uses of other values that are simply reverting the appearance back to
its default are changed to `appearance: auto`.
Uses of values in UA sheets that are defining the inherent appearance of
widgets are changed to:
appearance: auto;
-moz-default-appearance: <value>;
since those values are either no longer supported on (-moz-)appearance,
or are still supported but only in some limited form.
There are some uses of `-moz-appearance: textfield` on <input
type=number> elements that are renamed to `appearance: textfield`.
Differential Revision: https://phabricator.services.mozilla.com/D83430
Consider the following:
struct Complex<T> {
something: T,
#[compute(field_bound)]
something_else: Generic<Self, T>,
}
That will generate:
impl<T> ToComputedValue for Complex<T>
where
T: ToComputedValue,
Generic<Self, T>: ToComputedValue<ComputedValue = Generic<Self, <T as ToComputedValue>::ComputedValue>>,
{
// ...
}
That last clause is obviously incorrect. map_type_params correctly maps
the T, but it should know also about Self.
Ideally we could just do the same as for T and do:
<Self as ToComputedValue>::ComputedValue
But that doesn't quite work, because we are in that implementation of
the trait, and the compiler rightfully complains about we don't yet
knowing the computed type. So we need to pass it explicitly, which is
simple enough, if a bit annoying.
Differential Revision: https://phabricator.services.mozilla.com/D83816
This hooks the "monochrome" media query and co to the
nsIPrintSettings.printInColor setting.
This print setting we're using is not exposed in the print preview UI,
but you can test it setting the print.print_in_color preference to
"false", and then print preview will correctly show up greyscale'd.
Once this lands, the UI folks just have to use it as they see fit :)
I would've liked to add a proper rendering test, but the print reftests
check only whether the PDF text matches.
I could add a test to printpreview_helper.xhtml, but I'm refactoring
that file in bug 1648064 so I'd rather wait a bit and add it in a
separate bug. The test for the media feature should make sure that we
test that code path at least.
Differential Revision: https://phabricator.services.mozilla.com/D83552
By the time we get to iterate over the longhands of a shorthand, we've
already advanced the range iterator, so we look at the next duration and
such, which causes this bug.
I'm seriously baffled that no existing test caught this when it
landed, neither in our internal test suite nor wpt... :/
Differential Revision: https://phabricator.services.mozilla.com/D82396
This avoids arbitrary precision loss when computing REM units and so on,
which is particularly important if we ever change the base of our app
units (but useful regardless).
Differential Revision: https://phabricator.services.mozilla.com/D79928
This change extends the DocumentAnimationSet to hold animations for
pseudo-elements. Since pseudo-elements in Servo are not in the DOM like
in Gecko, they need to be handled a bit carefully in stylo. When a
pseudo-element has an animation, recascade the style. Finally, this
change passes the pseudo-element string properly to animation events.
Fixes: #10316
Depends on D80242
Differential Revision: https://phabricator.services.mozilla.com/D80243
This will be used in order to hold animations for pseudo elements in the
DocumentAnimationSet. Also no longer store the OpaqueNode in the
animation and transition data structures. This is already part of the
DocumentAnimationSet key.
Depends on D80241
Differential Revision: https://phabricator.services.mozilla.com/D80242
When animations and transitions change don't always re-resolve node
style, just replace the animation and transition rules and re-cascade.
Depends on D80236
Differential Revision: https://phabricator.services.mozilla.com/D80237
Instead of applying animations and transitions to styled elements,
include them in the cascade. This allows them to interact properly with
things like font-size and !important rules.
Depends on D80234
Differential Revision: https://phabricator.services.mozilla.com/D80235
This begins to address #26625 by properly applying CSS variables during
keyframe computation and no longer using `apply_declarations`. Instead,
walk the declarations, combining them into IntermediateComputedKeyframe,
maintaining declarations that modify CSS custom properties. Then compute
a set of AnimationValues for each keyframe and use those to produce
interpolated animation values.
Depends on D80233
Differential Revision: https://phabricator.services.mozilla.com/D80234
Instead of recalculating the animation style every tick of an animation,
cache the computed values when animations change. In addition to being
more efficient, this will allow us to return animation rules as property
declarations because we don't need to consult the final style to produce
them.
Depends on D80232
Differential Revision: https://phabricator.services.mozilla.com/D80233
This avoids arbitrary precision loss when computing REM units and so on,
which is particularly important if we ever change the base of our app
units (but useful regardless).
Differential Revision: https://phabricator.services.mozilla.com/D79928
This seems to match what other browsers do, and seems saner layout-wise,
at least.
I only annotated outline-width-interpolation.html because it's already
fixed upstream in:
8a489657bc
Differential Revision: https://phabricator.services.mozilla.com/D75360
The background color for the tree column headers is drawn using the
system APIs, but the foreground uses custom colors, which didn't follow
theme. This can lead to unreadable text with specific colors, e.g.
leading to black on black.
Fix this by using system colors for the foreground as well. It also
adds on-hover styling to match possible background change on hover.
Differential Revision: https://phabricator.services.mozilla.com/D78073
Rather than waiting until parsing another id (successfully or
unsuccessfully).
If we error before we even get to PropertyId::parse, we'd incorrectly
associate the error with the wrong property, incorrectly omitting it
sometimes.
Differential Revision: https://phabricator.services.mozilla.com/D78260
This removes an extra layer of abstraction and allows Servo to share
more code with Gecko. In addition, we will need to handle raw
`AnimationValue` structs soon in order to fully implement "faster
reversing of interrupted transitions."
Depends on D78192
Differential Revision: https://phabricator.services.mozilla.com/D78193
This is preparation for sharing this code with layout_2020 and
implementing selective off-the-main-thread animations.
We still look for nodes not in the flow tree in the layout thread.
Depends on D78191
Differential Revision: https://phabricator.services.mozilla.com/D78192
This implementation is more-or-less on par with the one from layout_2013
and in some cases better. There are still some cases where we don't
return the correct "resolved value," but this is enough to test
animations and transitions.
Depends on D78190
Differential Revision: https://phabricator.services.mozilla.com/D78191
This change splits the list of animations and transitions, which are
almost always handled differently. It also renames
`ElementAnimationState` to `ElementAnimationSet` and establishes an
`AnimationState` for every transition and animation. This allows us to
stop continually reallocating lists every time a transition or animation
needs to be canceled.
Fixes#14419.
Depends on D78189
Differential Revision: https://phabricator.services.mozilla.com/D78190
This is a small step toward fixing #19242. The main idea is that the
clock for animations should advance as the event loop ticks. We
accomplish this by moving the clock from layout and naming it the
"animation timeline" which is the spec language. This should fix
flakiness with animations and transitions tests where a reflow could
move animations forward while script was running.
This change also starts to break out transition and animation events
into their own data structure, because it's quite likely that the next
step in fixing #19242 is to no longer send these events through a
channel.
Depends on D78188
Differential Revision: https://phabricator.services.mozilla.com/D78189
This change corrects synchronization issues with animations, by
reworking the animation processing model to do a quick restyle and
incremental layout when ticking animations.
While this change adds overhead to animation ticks, the idea is that
this will be the fallback when synchronous behavior is required to
fulfill specification requirements. In the optimistic case, many
animations could be updated and applied off-the-main-thread and then
resynchronized when style information is queried by script.
Fixes#13865.
Depends on D78187
Differential Revision: https://phabricator.services.mozilla.com/D78188
This is triggered when an animation finishes. This is a high priority
because it allows us to start rooting nodes with animations in the
script thread.
This doesn't yet cause a lot of tests to pass because they rely on the
existence of `Document.getAnimations()` and the presence of
`animationstart` and animationiteration` events.
Depends on D78186
Differential Revision: https://phabricator.services.mozilla.com/D78187
`update_style_for_animation` previously handled both canceling defunct
animations and also updating style to reflect current animation state.
This change splits those two concerns because we want to start handling
replaced or canceled animations and finished animations in two different
places.
This is a refactor, so ideally it shouldn't change any behavior.
Depends on D78185
Differential Revision: https://phabricator.services.mozilla.com/D78186
When doing a restyle, we should apply animations and transitions to the
new style so that it is reflected in `getComputedStyle()` and the new
style information properly cascades. This is the first part of properly
ticking animations and transitions.
This causes a couple new animations tests failures (along with many new
passes), but we currently don't have support for properly handling
animations after they have completed, so this isn't totally unexpected.
Depends on D78184
Differential Revision: https://phabricator.services.mozilla.com/D78185
This refactor is preparation for implementing a specification
compliant transitions and animations processing model.
These data structures hold all the animation information about a single
node. Since adding, updating, and modifying animations for a single node
are all interdependent, it makes sense to start encapsulating animation
data and functionality into a single data structure. This also opens up
the possibility for easier concurrency in the future by more easily
allowing per-node mutexes.
Differential Revision: https://phabricator.services.mozilla.com/D78184
This should help out quite a bit with uBO, which has lots of very
general attribute selectors. We invalidate per attribute name rather
than using a SelectorMap, which prevents matching for attribute
selectors that can't have changed.
The idea is that this should be generally cheaper, though there are
cases where this would be a slight pesimization. For example, if there's
an attribute selector like:
my-specific-element[my-attribute] { /* ... */ }
And you change `my-attribute` in an element that isn't a
`my-specific-element`, before that the SelectorMap would've prevented us
from selector-matching completely. Now we'd still run selector-matching
for that (though the matching would be pretty cheap).
However I think this should speed up things generally, let's see what
the perf tests think before landing this though.
Differential Revision: https://phabricator.services.mozilla.com/D76825
This addresses a minor regression in bloom-matching.html. The common
case here is that there's no selector to the right of the
pseudo-element, so keep that path inline, while keeping all other checks
out of line.
Differential Revision: https://phabricator.services.mozilla.com/D76793
In order to test its parsing and serialization, we expose it but protect
it behind a pref.
Besides, I would like to drop layout.css.aspect-ratio-number.enabled in
the next patch because the spec has been updated. It seems we don't have
to keep this pref and we should always use Number.
Differential Revision: https://phabricator.services.mozilla.com/D74955
After bug 1632647, we can have pseudo-classes inside :not / :is /
:where, which the invalidation and matching code weren't handling.
Add a few tests for this stuff working as expected.
Differential Revision: https://phabricator.services.mozilla.com/D76160
See https://bugzilla.mozilla.org/show_bug.cgi?id=932410#c2 for the
context for which this pseudo-element was added.
In the previous patch, I had to special-case range appearance because of
this pseudo-class, but that patch makes this pseudo-class completely
redundant, as now all form controls, themed and unthemed, display
outlines, unless the native theme displays a focus indicator on its own.
Remove the special case, and make ranges use outlines like everything
else rather than this bespoke pseudo-element.
Differential Revision: https://phabricator.services.mozilla.com/D74734
See https://bugzilla.mozilla.org/show_bug.cgi?id=932410#c2 for the
context for which this pseudo-element was added.
In the previous patch, I had to special-case range appearance because of
this pseudo-class, but that patch makes this pseudo-class completely
redundant, as now all form controls, themed and unthemed, display
outlines, unless the native theme displays a focus indicator on its own.
Remove the special case, and make ranges use outlines like everything
else rather than this bespoke pseudo-element.
Differential Revision: https://phabricator.services.mozilla.com/D74734
Tim Nguyen
Sunita Sen
Emilio Cobos Álvarez
Boris Chiou
David Parks
Bogdan Tara
Mihai Alexandru Michis
Sylvestre Ledru
Markus Stange
Hiroyuki Ikezoe
Narcis Beleuzu
Dzmitry Malyshau
Ricky Stewart
Dorel Luca
Cameron McCormack
Jon Bauman
Razvan Maries
Frederic Wang
tobar2018
Mats Palmgren
Noemi Erli
Masatoshi Kimura
Nicolas Silva
Csoregi Natalia
Zeke Medley
Sean Feng
Shinichi Morimoto
Cristina Coroiu
Jeremy Ir
Butkovits Atila
Brian Birtles
Alexander Surkov
Philipp Zech
Simon Giesecke
Martin Robinson
Matthias Deiml
Utsav Oza
Simon Sapin
Cosmin Sabou
neil
Colomban Wendling
Anthony Ramine