This way, something like:
*:where(.foo, .bar)
Will end up twice on the selector map, just as if you would've written
.foo, .bar.
But we're a bit careful to not be wasteful, so:
.foo:where(div, span)
Will still end up using the .foo bucket.
It needs a bit of borrow-checker gymnastics to avoid cloning the entry
in the common path. It's a bit gross but not too terrible I think.
Differential Revision: https://phabricator.services.mozilla.com/D71457
See the comment about why this is valuable. For a selector like:
.foo:is(.bar) > .baz
Before this patch we'd generate an Dependency for .bar like this:
Dependency {
selector: .bar,
offset: 0,
parent: Some(Dependency {
selector: .foo:is(.bar) > .baz,
offset: 1, // Pointing to the `>` combinator.
parent: None,
}),
}
After this patch we'd generate just:
Dependency {
selector: .foo:is(.bar) > .baz,
offset: 1, // Pointing to the `>` combinator.
parent: None,
}
This is not only less memory but also less work. The reason for that is that,
before this patch, when .bar changes, we'd look the dependency, and see there's
a parent, and then scan that, so we'd match `.bar` two times, one for the
initial dependency, and one for .foo:is(.bar).
Instead, with this we'd only check `.foo:is(.bar)` once.
Differential Revision: https://phabricator.services.mozilla.com/D71423
That way we can look at the parent dependency as described in the previous
patch. An alternative would be to add a:
parent_dependency: Option<&'a Dependency>
on construction to `Invalidation`, but this way seems slightly better to avoid
growing the struct. It's not even one more indirection because the selector is
contained directly in the Dependency struct.
Differential Revision: https://phabricator.services.mozilla.com/D71422
The tricky part of :is() and :where() is that they can have combinators inside,
so something like this is valid:
foo:is(#bar > .baz) ~ taz
The current invalidation logic is based on the assumption that you can
represent a combinator as a (selector, offset) tuple, which are stored in the
Dependency struct. This assumption breaks with :is() and :where(), so we need
to make them be able to represent a combinator in an "inner" selector.
For this purpose, we add a `parent` dependency. With it, when invalidating
inside the `:is()` we can represent combinators inside as a stack.
The basic idea is that, for the example above, when an id of "bar" is added or
removed, we'd find a dependency like:
Dependency {
selector: #bar > .baz,
offset: 1, // pointing to the `>` combinator
parent: Some(Dependency {
selector: foo:is(#bar > .baz) > taz,
offset: 1, // Pointing to the `~` combinator.
parent: None,
})
}
That way, we'd start matching at the element that changed, towards the right,
and if we find an element that matches .baz, instead of invalidating that
element, we'd look at the parent dependency, then double-check that the whole
left-hand-side of the selector (foo:is(#bar > .baz)) actually changed, and then
keep invalidating to the right using the parent dependency as usual.
This patch only builds the data structure and keeps the code compiling, the
actual invalidation work will come in a following patch.
Differential Revision: https://phabricator.services.mozilla.com/D71421
This way, something like:
*:where(.foo, .bar)
Will end up twice on the selector map, just as if you would've written
.foo, .bar.
But we're a bit careful to not be wasteful, so:
.foo:where(div, span)
Will still end up using the .foo bucket.
It needs a bit of borrow-checker gymnastics to avoid cloning the entry
in the common path. It's a bit gross but not too terrible I think.
Differential Revision: https://phabricator.services.mozilla.com/D71457
See the comment about why this is valuable. For a selector like:
.foo:is(.bar) > .baz
Before this patch we'd generate an Dependency for .bar like this:
Dependency {
selector: .bar,
offset: 0,
parent: Some(Dependency {
selector: .foo:is(.bar) > .baz,
offset: 1, // Pointing to the `>` combinator.
parent: None,
}),
}
After this patch we'd generate just:
Dependency {
selector: .foo:is(.bar) > .baz,
offset: 1, // Pointing to the `>` combinator.
parent: None,
}
This is not only less memory but also less work. The reason for that is that,
before this patch, when .bar changes, we'd look the dependency, and see there's
a parent, and then scan that, so we'd match `.bar` two times, one for the
initial dependency, and one for .foo:is(.bar).
Instead, with this we'd only check `.foo:is(.bar)` once.
Differential Revision: https://phabricator.services.mozilla.com/D71423
That way we can look at the parent dependency as described in the previous
patch. An alternative would be to add a:
parent_dependency: Option<&'a Dependency>
on construction to `Invalidation`, but this way seems slightly better to avoid
growing the struct. It's not even one more indirection because the selector is
contained directly in the Dependency struct.
Differential Revision: https://phabricator.services.mozilla.com/D71422
The tricky part of :is() and :where() is that they can have combinators inside,
so something like this is valid:
foo:is(#bar > .baz) ~ taz
The current invalidation logic is based on the assumption that you can
represent a combinator as a (selector, offset) tuple, which are stored in the
Dependency struct. This assumption breaks with :is() and :where(), so we need
to make them be able to represent a combinator in an "inner" selector.
For this purpose, we add a `parent` dependency. With it, when invalidating
inside the `:is()` we can represent combinators inside as a stack.
The basic idea is that, for the example above, when an id of "bar" is added or
removed, we'd find a dependency like:
Dependency {
selector: #bar > .baz,
offset: 1, // pointing to the `>` combinator
parent: Some(Dependency {
selector: foo:is(#bar > .baz) > taz,
offset: 1, // Pointing to the `~` combinator.
parent: None,
})
}
That way, we'd start matching at the element that changed, towards the right,
and if we find an element that matches .baz, instead of invalidating that
element, we'd look at the parent dependency, then double-check that the whole
left-hand-side of the selector (foo:is(#bar > .baz)) actually changed, and then
keep invalidating to the right using the parent dependency as usual.
This patch only builds the data structure and keeps the code compiling, the
actual invalidation work will come in a following patch.
Differential Revision: https://phabricator.services.mozilla.com/D71421
This works even if the Rust standard library’s allocator is not `libc::malloc`,
so we can remove the `known_system_malloc `feature flag
and make the `fallible` crate unconditional.
Differential Revision: https://phabricator.services.mozilla.com/D71742
This change adds support for canceling CSS transitions when a property
is no longer transitionable or when an element becomes styled with
display:none. Support for canceling and replacing CSS transitions when
the end value changes is still pending. This change also takes advantage
of updating the constellation message to fix a bug where transition
events could be sent for closed pipelines.
Cherry-picked from https://github.com/servo/servo/pull/26244
(though this is not part of the Gecko build).
This intermediate data structure doesn't really buy us anything and is a
bit confusing.
Cherry-picked from https://github.com/servo/servo/pull/26214
(though this is not part of the Gecko build).
RuleTree::gc is now a safe method that any thread can call
at any time, and StrongRuleNode values can all be dropped
whenever their owner want to, on any thread.
Cherry-picked from https://github.com/servo/servo/pull/26227
Just because we didn't find a child when read-locking a node children list
doesn't mean it still won't exist while we wait to upgrade the read lock
into a write lock to create the child.
This cherry-picks https://github.com/servo/servo/pull/26220
MANUAL PUSH: So that I can preserve reviewer information.
This implements the easy / straight-forward parts of the :where / :is
selectors.
The biggest missing piece is to handle properly invalidation when there
are combinators present inside the :where. That's the hard part of this,
actually.
But this is probably worth landing in the interim. This fixes some of
the visitors that were easy to fix.
Differential Revision: https://phabricator.services.mozilla.com/D70788