A scoped style can match the featureless shadow host:
* Constructed stylesheets adopted by the shadow DOM
* Implicit scope defined in `<style>` at shadow root
* Explicit scope with `scope-start` selector of `:host`
Hence, they should not be considered non-featureless selector during parse time,
adding to featureless host rules when we can determine if we're in one of the
above cases.
Differential Revision: https://phabricator.services.mozilla.com/D207782
This is a bit less complicated than lengths because there's no cycle
possible which could turn the color-scheme declaration invalid afaict.
So it's just that we need to defer the colors when color-scheme is
specified, which is slightly annoying, but maybe not too bad.
I had to tweak a bit the code to defer properties to fix a bug that we
were papering over accidentally. We were using the wrong registration
here:
https://searchfox.org/mozilla-central/rev/f60bb10a5fe6936f9e9f9e8a90d52c18a0ffd818/servo/components/style/custom_properties.rs#1613
That's the registration for reference.name, not for name, which
papered over some issues. The fix is simple tho, which is storing a
single CustomPropertiesMap.
Differential Revision: https://phabricator.services.mozilla.com/D211860
If `getComputedStyle(...).getPropertyValue` is called on a registered
custom property that is used in a transition and that custom property's
registration is removed, `to` can be `None`.
Differential Revision: https://phabricator.services.mozilla.com/D211947
If hsl/hwb colors were created with rcs, then they are assumed to be
modern syntax and thens hould not be gamut mapped/clipped in any way.
Differential Revision: https://phabricator.services.mozilla.com/D210615
Such cas is invalidated out-of-band in `RestyleManager` because
their invalidation can be trivially determined. Don't consider them
again while determining the general-case relative selector invalidation.
Also fix `:only-child` being classified as a simple edge selector, and
prevent them from ending up in the any (`*`) bucket in `InvalidationMap`.
Differential Revision: https://phabricator.services.mozilla.com/D210343
The only use of this type used to be carrying around an owning reference
to a thread-local. However, since bug 1577439 we're leaking the
allocation intentionally, so we can simplify the code to explicitly use
`Box::leak()`, which in turn removes all unsafe usage around these, and
allows us to drop the owning_ref dependency altogether.
Differential Revision: https://phabricator.services.mozilla.com/D209912
The only use of this type used to be carrying around an owning reference
to a thread-local. However, since bug 1577439 we're leaking the
allocation intentionally, so we can simplify the code to explicitly use
`Box::leak()`, which in turn removes all unsafe usage around these, and
allows us to drop the owning_ref dependency altogether.
Differential Revision: https://phabricator.services.mozilla.com/D209912
This doesn't yet expose it to a11y but that will be done by the a11y
folks, since this blocks some of the a11y interop test-cases.
Modify the tests to not hit the network, and make -moz-alt-content not
exposed to content (we only need it for UA stylesheets).
Differential Revision: https://phabricator.services.mozilla.com/D209690
This is the logical continuation of bug 1121792. This improves on the
existing support by totally removing all the manual nsTArray bindings,
which have always been a bit clumsy.
This is a prerequisite for bug 1281158 because I want to use ThinVec to
avoid a few extra heap allocations in the computed values of the Content
property.
Differential Revision: https://phabricator.services.mozilla.com/D209689
Most of this code is already dead. The native appearance on macOS
doesn't work on dark mode, and on Windows and Linux we are already
overriding it.
Add a first-column tree property to be able to align the inner borders
on macOS properly.
Differential Revision: https://phabricator.services.mozilla.com/D206526
We keep track of whether there was an origin color available so that we
can serialize hsl and hwb colors in modern srgb syntax.
Differential Revision: https://phabricator.services.mozilla.com/D209490
Add one extra branch if we have before-change style but its display
is none, and the new style is not display:none. Also, we add an extra
subtest if we use the container query to change the display property.
Differential Revision: https://phabricator.services.mozilla.com/D208572
Now we use the starting style if we have, to replace the before-change
style. This includes a minor refactoring of the handling of transitions
because it becomes a little bit complicated.
Differential Revision: https://phabricator.services.mozilla.com/D208571
Per spec, we define starting style for an element as the after-change style
with @starting-style rules applied in addition.
If an element does not have a before-change style for a given style change
event, the starting style is used instead of the before-change style to
compare with the after-change style to start transitions.
The basic idea in this patch is:
1. We add a flag to indicate if this element may have starting style. We
set this flag during its full matching, and store this flag in the
element data.
2. So during process animations, we check this flag, if this element may
have starting style and specifies transitions, we resolve the
starting style. Use it as the before-change style.
The implmentation in process_animations() and tests are in the following
patches.
Differential Revision: https://phabricator.services.mozilla.com/D208570
The rules inside @starting-style doesn't apply to primary style, and
they are used only for CSS transitions (when computing starting style).
So adding a flag to make us easier to filter them out.
Differential Revision: https://phabricator.services.mozilla.com/D208569
The values that we take from our parent should be zoomed in. Similarly,
root values should also be zoomed in by the effective zoom (for that, we
unzoom root values to zoom-independent pixels when storing them on the
device).
Container-relative units probably need more care / thought, because they
are in the layout (so zoom-independent) coordinate space already, since
they come from frames. Bug 1894104 is filed for this.
Differential Revision: https://phabricator.services.mozilla.com/D208599
For the selector highlighter, we were retrieving the desugared selector of each
displayed rule, and using the selector text in querySelectorAll to retrieve the
elements matching the rule.
This can be very expensive, especially for deeply nested rule, for a feature that
might not even be used.
This patch is adding a method which takes a root node, and will return the
elements inside the root node that match the rule's selectors.
We're only exposing the method that existed in glue.rs to get the SelectorList
of a given Rule, and call `Servo_SelectorList_QueryAll` with it to get our NodeList.
A test file is added to ensure this works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D208363
We can have combinator sequences like [>, <part>], and they are fine.
Add a test to make sure they're handled correctly.
Differential Revision: https://phabricator.services.mozilla.com/D208668
- Rename ColorParser to ComponentParser.
- Move origin color parsing to parse_color_function.
- Inline the parse_components function.
Differential Revision: https://phabricator.services.mozilla.com/D207836
- Rename ColorParser to ComponentParser.
- Move origin color parsing to parse_color_function.
- Inline the parse_components function.
Differential Revision: https://phabricator.services.mozilla.com/D207836
When an origin color is specified in RCS, using the channel keywords
from the original color should be replaced by the values from the origin
color.
Differential Revision: https://phabricator.services.mozilla.com/D207117
In some cases, it can be more useful to only get the token value than the whole
token text (e.g. for 'Function`, where the value is the function name, while
the text includes the opening parenthesis)
Refactor `test_lexer` to better test the tokens we get, including their value property.
Differential Revision: https://phabricator.services.mozilla.com/D207400
This new InspectorCSSParser makes use of the cssparser crate so DevTools end
up using the same code as the CSS engine.
At the moment, we can't get the token start and end offsets, so we create
a JS wrapper class to compute them in JS. This might be removed if we get
a way to retrieve utf16 position from the cssparser.
The existing lexer xpcshell test is modified so it can run against both js-based
and rust-based lexers.
Differential Revision: https://phabricator.services.mozilla.com/D202909
When an origin color is specified in RCS, using the channel keywords
from the original color should be replaced by the values from the origin
color.
Differential Revision: https://phabricator.services.mozilla.com/D207117
We were getting a line byte index for the
actual char matching the line we want, but
we actually need the index _after_ that
new line char.
A test case is added to cover this fix.
Differential Revision: https://phabricator.services.mozilla.com/D207156
The ColorParser trait only has one implementation so we can make it a
concrete type now. It will be extended in the future.
Differential Revision: https://phabricator.services.mozilla.com/D207009
This abstraction was in place when the color parsing still lived in
the cssparser crate, but now it is not needed any more and by removing
it we make the parsing more flexible.
Note: the ColorParser trait itself is still in tact and will be
addressed in another patch.
Differential Revision: https://phabricator.services.mozilla.com/D207008
No behaviour is changed and the functions are only merged to a single
more generic version. Avoid code duplication and will make future
changes much easier and less error prone.
Differential Revision: https://phabricator.services.mozilla.com/D206993
`InspectorUtils.getRuleBodyTextOffset` was returning bytes position, and we
were using them directly in Javascript `substring`, which causes problem
with non-ascii chars.
Instead of returning offsets to compute the rule string, we directly return
the string from InspectorUtils which is easier to work with.
Differential Revision: https://phabricator.services.mozilla.com/D204523
The next patch modifies `getRuleText` so it only returns the text, and no
longer the offset at which the rule starts.
The only consumer of the returned offset was in `StyleRuleActor#setRuleText`,
so we migrate this directly to a InspectorUtils method to avoid mixing JS string
indexes with Rust bytes position.
Differential Revision: https://phabricator.services.mozilla.com/D204522
We introduce this rule and parse it in this patch. Also, fix some wpt
expectations for ERROR.
We will introduce CSSStartingStyleRule in the following patch, and test
it there.
Differential Revision: https://phabricator.services.mozilla.com/D206428
We introduce this rule and parse it in this patch. Also, fix some wpt
expectations for ERROR.
We will introduce CSSStartingStyleRule in the following patch, and test
it there.
Differential Revision: https://phabricator.services.mozilla.com/D206428
This patch implements the `::target-text` pseudo element.
Similarly to the Custom Highlight API, this is done implementing
a new Selection type.
Differential Revision: https://phabricator.services.mozilla.com/D195687
This patch implements the `::target-text` pseudo element.
Similarly to the Custom Highlight API, this is done implementing
a new Selection type.
Differential Revision: https://phabricator.services.mozilla.com/D195687
This patch implements the `::target-text` pseudo element.
Similarly to the Custom Highlight API, this is done implementing
a new Selection type.
Differential Revision: https://phabricator.services.mozilla.com/D195687
This patch implements the `::target-text` pseudo element.
Similarly to the Custom Highlight API, this is done implementing
a new Selection type.
Differential Revision: https://phabricator.services.mozilla.com/D195687
* Linux doesn't support them already.
* macOS doesn't draw anything either.
* Windows doesn't have dark-color-scheme support so the relevant
windows that have them need to set appearance none already.
Remove them and simplify the relevant code.
Differential Revision: https://phabricator.services.mozilla.com/D205872
This is simpler given we only have a couple of windows with these looks,
and removes the dual mode of the ToolbarWindow class.
We just draw the title into the window frame and rely on CSS reserving
enough space (exposed as a new -moz-mac-titlebar-height environment
variable).
We remove the toolbox and toolbar appearance values on mac, now that
they do nothing (toolbar did, but it didn't support dark mode and is
effectively unused).
Differential Revision: https://phabricator.services.mozilla.com/D205469
Basically, we implement `Animate` for `PathOrShapeFunction` manually
when either *from* or *to* value is `path()` function, and the other one
is `shape()` function.
Differential Revision: https://phabricator.services.mozilla.com/D205491
This matches what WebKit and Blink ship. Bug 1887627 is the more complex
fix, though I'm a bit concerned about the performance implications
there, and I don't think that necessarily blocks shipping zoom...
This should be uncontroversial and unblocks getting zoom out of the
door.
Differential Revision: https://phabricator.services.mozilla.com/D205562
We treat it as other basic shapes (excluding path(), which has some
special handling and it doesn't rely on the current layout position).
Therefore, we don't have any implementation for caching and we would like to
leave this part to Bug 1837042.
Also, add some more simple tests in css/motion to make sure we render it
properly.
Differential Revision: https://phabricator.services.mozilla.com/D204440
* Linux doesn't support them already.
* macOS doesn't draw anything either.
* Windows doesn't have dark-color-scheme support so the relevant
windows that have them need to set appearance none already.
Remove them and simplify the relevant code.
Differential Revision: https://phabricator.services.mozilla.com/D205872
This is simpler given we only have a couple of windows with these looks,
and removes the dual mode of the ToolbarWindow class.
We just draw the title into the window frame and rely on CSS reserving
enough space (exposed as a new -moz-mac-titlebar-height environment
variable).
We remove the toolbox and toolbar appearance values on mac, now that
they do nothing (toolbar did, but it didn't support dark mode and is
effectively unused).
Differential Revision: https://phabricator.services.mozilla.com/D205469
We have shipped them for more than 3 months and we don't have issue
right now. Chromium also removed the flags, so it should be fine to drop
them to make the code simpler.
Differential Revision: https://phabricator.services.mozilla.com/D205615
It's possible to set `animation-name` to any of the keyword of other
properties, and this may cause ambiguity when serializing `animation`
shorthand (because we may reuse this result as an input of another
`animation` shorthand to get the same result).
So we still have to serialize these properties even if they are initial
values if `animation-name` matches them.
e.g.
Set `animation` to `normal normal`. Its serialization should be
`normal normal`, instead `normal`, because using `normal` as an input of
another `animation` shorthand makes its `animation-name` be `none`.
(Note: we parse `animation-direction` first.)
Differential Revision: https://phabricator.services.mozilla.com/D204995
We still have some ambiguous issue when `animation-name` is the same as
other keywords. We will fix it in the following patch.
Differential Revision: https://phabricator.services.mozilla.com/D204692
It's possible to set `animation-name` to any of the keyword of other
properties, and this may cause ambiguity when serializing `animation`
shorthand (because we may reuse this result as an input of another
`animation` shorthand to get the same result).
So we still have to serialize these properties even if they are initial
values if `animation-name` matches them.
e.g.
Set `animation` to `normal normal`. Its serialization should be
`normal normal`, instead `normal`, because using `normal` as an input of
another `animation` shorthand makes its `animation-name` be `none`.
(Note: we parse `animation-direction` first.)
Differential Revision: https://phabricator.services.mozilla.com/D204995
We still have some ambiguous issue when `animation-name` is the same as
other keywords. We will fix it in the following patch.
Differential Revision: https://phabricator.services.mozilla.com/D204692
This is significantly faster. While at it:
* Remove unused "additional_methods".
* Fix help text to remove an option that no longer exists.
Differential Revision: https://phabricator.services.mozilla.com/D205047
Substring attribute selectors should never match when an empty string is
provided. This fixes [attr^=""], [attr$=""], [attr*=""] and [attr~=""]
in Servo, which broke when D180529 removed never_matches.
Gecko doesn't use this code at all, so no change in behavior.
Differential Revision: https://phabricator.services.mozilla.com/D205187
Instead of Option<ElementSelectorFlags>, it can be ElementSelectorFlags,
representing None as ElementSelectorFlags::empty().
No change in behavior.
Differential Revision: https://phabricator.services.mozilla.com/D205051
Update clip-path-shape-003.html and clip-path-shape-004.html because
1. Per SVG2 spec, we don't accept comma among commands, so I remove them.
2. Basically, these two tests want to test the result of `shape()`
should be identical to the result of `path()`. However, I noticed the
original tests which put a `clip-path:path()` with `position:absolutely`
may have a fuzzy result if the path has some curves there. This may be
caused by anti-alias together with absoultely positioned element
(note: perhaps there are some floating point calculation in layout for
this, so the final rendering coordinates may have some fractions).
Therefore, I drop the absolutely positioned element, and just test
that if the result of `shape()` is identical to the result of `path()`.
Also, add two more tests for different reference-boxes together with
the usage of `shape()` (to make sure we resolve percentage values properly).
Differential Revision: https://phabricator.services.mozilla.com/D202884
Also, we don't have Unkonwn type, so we have to do some minor
refactoring in BuildPath(), and templatize this function so we can use
it for both shape() and path().
This patch doesn't change the behavior.
Note that we instantiate BuildPath() with CSSFloat for now. Once we
instantiate it for StyleAngle and LengthPercentage (i.e. shape()), we
have to tweak this function more. Let's do that in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D202883
Implement the style part for shape(). Besides, update some issues in the
test file, e.g. avoid using viewport height so we get the fixed result
on different devices.
I will refactor `PathCommand` to let it be a specialization of
`GenericShapeCommand` in the following path.
Differential Revision: https://phabricator.services.mozilla.com/D202882
There are still some unhandled edge cases, like making the removal of an
@property rule not interpolate (bug 1885798).
Also, a todo is added to more granularly handle custom properties in
is_discrete_animatable (bug 1885995).
Differential Revision: https://phabricator.services.mozilla.com/D204863
This should be flexible enough. In the future Servo might want to make
more guarantees about what threads the style thread pool contains.
Differential Revision: https://phabricator.services.mozilla.com/D204506
The parsing functions now return typed values like NumberOrPercentage or
NumberOrAngle and only once they are converted to AbsoluteColor (which
will change in the near future to accommodate RCS) are they converted to
f32 values.
Depends on D203465
Differential Revision: https://phabricator.services.mozilla.com/D203410
With nesting it might not hold. It still doesn't change the correctness
of that code tho. We might need to rework this a bit more in the future
to handle specificity properly, see linked spec issue.
But for now crashing is not useful at all.
Differential Revision: https://phabricator.services.mozilla.com/D204304
Add a TODO for bug 1883255, since D203361 fixes bug 1870348.
Add a TODO for bug 1884606, since WPTs for interpolating custom
properties with syntax `<transform-function>` and with value `none` now
fail.
Differential Revision: https://phabricator.services.mozilla.com/D203361
Unparsed custom properties are the
ComputedRegisteredValueInner::Universal variant.
Although the inner value is the ComputedRegisteredValueInner type,
custom property maps hold only the
ComputedRegisteredValueInner::Universal variant to keep behavior
unchanged for now.
D203360 also removes Arc<> from the CustomPropertiesMap value.
Differential Revision: https://phabricator.services.mozilla.com/D203360
Now that registered custom property values contain URL data, URL data is
eliminated as an argument in some places, and the ComputedValue.url_data
field is removed.
Differential Revision: https://phabricator.services.mozilla.com/D203359
The URL data is necessary to uncompute the value for animation. This was
handled previously by adding the URL data to CustomAnimatedValue.
However, now that a registered custom property is passed to
CustomAnimatedValue::from_computed instead of a VariableValue, that
registered custom property should include URL data.
Differential Revision: https://phabricator.services.mozilla.com/D203358
Add a TODO for bug 1883255, since D203361 fixes bug 1870348.
Add a TODO for bug 1884606, since WPTs for interpolating custom
properties with syntax `<transform-function>` and with value `none` now
fail.
Differential Revision: https://phabricator.services.mozilla.com/D203361
Unparsed custom properties are the
ComputedRegisteredValueInner::Universal variant.
Although the inner value is the ComputedRegisteredValueInner type,
custom property maps hold only the
ComputedRegisteredValueInner::Universal variant to keep behavior
unchanged for now.
D203360 also removes Arc<> from the CustomPropertiesMap value.
Differential Revision: https://phabricator.services.mozilla.com/D203360
Now that registered custom property values contain URL data, URL data is
eliminated as an argument in some places, and the ComputedValue.url_data
field is removed.
Differential Revision: https://phabricator.services.mozilla.com/D203359
The URL data is necessary to uncompute the value for animation. This was
handled previously by adding the URL data to CustomAnimatedValue.
However, now that a registered custom property is passed to
CustomAnimatedValue::from_computed instead of a VariableValue, that
registered custom property should include URL data.
Differential Revision: https://phabricator.services.mozilla.com/D203358
During an animation restyle, two links might share the same rules while
not sharing the same link-ness.
This is a temporary state, but let's deal with it correctly.
Differential Revision: https://phabricator.services.mozilla.com/D203891
This was done using bindgen's "emit_diagnostics" feature, which shows
unused allowlist entries.
Enabling it by default would need extra dependencies so for now don't.
Differential Revision: https://phabricator.services.mozilla.com/D203533
Even if `mask-origin` is at its initial value `border-box`, we still have to
serialize it to avoid ambiguity iF the `mask-clip` longhand has some other
`<coord-box>` value (i.e. neither `border-box` nor `no-clip`).
Differential Revision: https://phabricator.services.mozilla.com/D203209
Jonathan Watt
David Shin
Tiaan Louw
Emilio Cobos Álvarez
Zach Hoffman
Gregory Pappas
Sandor Molnar
Tamas Szentpeteri
Mike Hommey
Cristian Tuns
Ting-Yu Lin
Jonathan Kew
Stanca Serban
Narcis Beleuzu
Noemi Erli
Erich Gubler
Boris Chiou
Nicolas Chevobbe
Emily McDonough
Aron Cseh
Ashley Hale
Jan-Niklas Jaeschke
keithamus
Norisz Fay
Niels
Oriol Brufau
Vincent Hilla
Natalia Csoregi
serge-sans-paille
Liu
Peter Van der Beken
Frédéric Wang