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
