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
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
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
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
`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
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
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
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
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
The regressing bug regressed some calc() expressions like the one in the
test-case:
max-width: calc(100% - <some-fixed-length>);
Where floating point precision basically made us lose a little bit of
precision here and there.
Before bug 1841612, this worked because we'd operate in fixed point for
such simple expressions at least. Things could easily go equally south
for more complex things including e.g. rem().
Rounding seems like the better default for calc() since we basically
have no idea of what the output is going to be, and makes the answer
more likely to be precise.
Note that this only affects actual mixed calc() expressions: If things
resolve to a percentage we keep existing behavior.
Differential Revision: https://phabricator.services.mozilla.com/D202746
This will allow calling InspectorUtils.ColorTo("red", "lab") and
receive {color: "lab(54.3 80.8 69.9)", components: [54.3, 80.8, 69.9, 1.0], adjusted: false}.
The adjusted value is always "false", because gamut checking and mapping
is not supported at the moment. See:
https://bugzilla.mozilla.org/show_bug.cgi?id=1823363
Depends on D192673
Differential Revision: https://phabricator.services.mozilla.com/D169942
When transition-behavior is allow-discrete, the animation values are
transitionable even if they are not interpoltable, given that the
animation type of the CSS property is by computed value.
Also, we remove `animate()` check from `needs_transitions_update_per_property`.
This check was added for handling the transition between `auto` and
other values long time ago, but now it may be redundant (because we
still pass the tests without it) and we do the same things in
nsTransitionManager as well, so it should be fine to drop it, especially
after we support discrete transitions.
Differential Revision: https://phabricator.services.mozilla.com/D201865
The implementation is straight-forward. We have to check
if `transition-behavior` is `allow-discrete` when trying to create a new
transition and when checking if we have to cancel a running transition.
Also, the test case is out-of-date, so I tweak it a little bit and add
more general test cases for transtiion-behavior. Besides, I enable the
preference in the WPT folders which use `transition-behavior` (but
those tests may be passed already or failed due to reasons other than
`transition-behavior`).
Differential Revision: https://phabricator.services.mozilla.com/D201864
Inherited properties with universal syntax and unregistered properties should
behave basically the same.
This removes some redundant checks and guarantees that we have the same
code-paths in those two cases.
Differential Revision: https://phabricator.services.mozilla.com/D200995
Note that although this builds, it would (by itself) result in some test breakage;
this is resolved in the following patches that build on this.
Differential Revision: https://phabricator.services.mozilla.com/D198790
