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
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
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
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
Some of the stuff, in particular inside GeckoBindings stuff should be
refactored to be less ugly and duplicate a bit less code, but the rest of the
code should be landable as is.
Some invalidation changes are already needed because we weren't matching with
the right shadow host during invalidation (which made existing ::part() tests
fail).
Pending invalidation work:
* Making exportparts work right on the snapshots.
* Invalidating parts from descendant hosts.
They're not very hard but I need to think how to best implement it:
* Maybe get rid of ShadowRoot::mParts and just walk DOM descendants in the
Shadow DOM.
* Maybe implement a ElementHasExportPartsAttr much like HasPartAttr and use
that to keep the list of elements.
* Maybe invalidate :host and ::part() together in here[1]
* Maybe something else.
Opinions?
[1]: https://searchfox.org/mozilla-central/rev/131338e5017bc0283d86fb73844407b9a2155c98/servo/components/style/invalidation/element/invalidator.rs#561
Differential Revision: https://phabricator.services.mozilla.com/D53730
D29542 fixed the bogus checks that was making nested pseudo-elements match
author rules. This adds tests and ends up being just a cleanup, though as it
turns out we it also fixes an issue with ::slotted() matched from
Element.matches.
Differential Revision: https://phabricator.services.mozilla.com/D27529
This fixes a couple fuzz bugs and prevents special-casing <svg:use> even more in
bug 1431255.
Unfortunately not as many hacks went away as I'd have hoped, since we still need
to match document rules, see the linked SVGWG issues.
But blocks_ancestor_combinators goes away, which is nice since it's on a very
hot path.
Bug: 1450250
Reviewed-by: heycam
Differential Revision: https://phabricator.services.mozilla.com/D2154
MozReview-Commit-ID: C4mthjoSNFh
We could invalidate in a slightly more fine-grained way, but I don't think it's
worth the churn vs. keeping the special-cases minimal.
Bug: 1452640
Reviewed-by: xidorn
MozReview-Commit-ID: 5DkQrgwg9GW
Kinda tricky because :host only matches rules on the shadow root where the rules
come from. So we need to be careful during invalidation and style sharing.
I didn't use the non_ts_pseudo_class_list bits because as soon as we implement
the :host(..) bits we're going to need to special-case it anyway.
The general schema is the following:
* Rightmost featureless :host selectors are handled inserting them in the
host_rules hashmap. Note that we only insert featureless stuff there. We
could insert all of them and just filter during matching, but that's slightly
annoying.
* The other selectors, like non-featureless :host or what not, are added to the
normal cascade data. This is harmless, since the shadow host rules are never
matched against the host, so we know they'll just never match, and avoids
adding more special-cases.
* Featureless :host selectors to the left of a combinator are handled during
matching, in the special-case of next_element_for_combinator in selectors.
This prevents this from being more invasive, and keeps the usual fast path
slim, but it's a bit hard to match the spec and the implementation.
We could keep a copy of the SelectorIter instead in the matching context to
make the handling of featureless-ness explicit in match_non_ts_pseudo_class,
but we'd still need the special-case anyway, so I'm not fond of it.
* We take advantage of one thing that makes this sound. As you may have
noticed, if you had `root` element which is a ShadowRoot, and you matched
something like `div:host` against it, using a MatchingContext with
current_host == root, we'd incorrectly report a match. But this is impossible
due to the following constraints:
* Shadow root rules aren't matched against the host during styling (except
these featureless selectors).
* DOM APIs' current_host needs to be the _containing_ host, not the element
itself if you're a Shadow host.
Bug: 992245
Reviewed-by: xidorn
MozReview-Commit-ID: KayYNfTXb5h
This changes the order to match the normal selector-matching order, which is
usually faster.
That is, when matching div:nth-child(2), for example, before this patch we'd
first try to match :nth-child(2), and only then div.
This patch makes us walk until the end or the next combinator, and only then
match backwards, matching first div, then :nth-child.
Bug: 1443814
Reviewed-by: bholley
It used to be the case that MatchingContext was immutable and thus we didn't
care to have accessors.
This is no longer true, so let's make this code a bit nicer.
Without turning it on yet, of course.
The reason why I didn't use the general PseudoElement mechanism is because this
pseudo is a bit of its own thing, and I found easier to make ::selectors know
about it (because you need to jump to the assigned slot) than the other way
around.
Also, we need to support ::slotted(..)::before and such, and supporting multiple
pseudo-elements like that breaks some other invariants around the SelectorMap,
and fixing those would require special-casing slotted a lot more in other parts
of the code.
Let me know if you think otherwise.
I also don't like much the boolean tuple return value, but I plan to do some
cleanup in the area in a bit, so it should go away soon, I'd hope.
Right now we go through a lot of hoops to see if we ever see a relevant link.
However, that information is not needed: if the element is a link, we'll always
need to compute its visited style because its its own relevant link.
If the element inherits from a link, we need to also compute the visited style
anyway.
So the "has a relevant link been found" is pretty useless when we know what are
we inheriting from.
The branches at the beginning of matches_complex_selector_internal were
affecting performance, and there are no good reasons to keep them.
I've verified that this passes all the visited tests in mozilla central, and
that the test-cases too-flaky to be landed still pass.
These methods are instantiated by the Gecko library, and used during
querySelector, which means that they end up being super-hot in micro-benchmarks.
MozReview-Commit-ID: K1XJb0QyX5a
