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
I'm going to unconditionally generate the PseudoElement combinator, and this
causes issues since we'll put the raw `::pseudo` selectors in the host bucket,
which is obviously wrong.
Differential Revision: https://phabricator.services.mozilla.com/D27528
::slotted() is already weird in the sense that it supports a pseudo-element
afterwards (so ::slotted(*)::before is valid for example).
::part() is weirder because you are supposed to allow stuff like
::part(foo):hover, ::part(foo):hover::before, etc.
In order to avoid making the already-complex parse_compound_selector more
complex, shuffle stuff so that we pass the progress of our current compound
selector around, and is the parsing code for each selector which decides whether
it's ok to parse at the given point.
Differential Revision: https://phabricator.services.mozilla.com/D27158
We could keep using ParsedCaseSensitivity::CaseSensitive as a temporary stand-in
for "case-sensitive or maybe not depending on what HTML says" until we check the
attribute list, but it seems better to make that explicit.
Differential Revision: https://phabricator.services.mozilla.com/D14093
The selectors that crash seem just corrupted data structures, none of the
selectors from crash dumps make sense, and the ones for which I could trace the
source found no issue.
This implements the selector(<complex-selector>) syntax for @supports.
See https://github.com/w3c/csswg-drafts/issues/3207 for explainer and
discussion.
Probably would should wait for that to be sorted out to land this, or maybe we
should put it behind a pref to get the code landed and change our
implementation if the discussion there leads to a change.
Differential Revision: https://phabricator.services.mozilla.com/D8864
This reverts the relevant bits from #21746 so that style and dependencies can
build with stable.
This is important because:
* `selectors` is a published crate.
* Gecko compiles with stable (more or less).
I reviewed that PR under the assumption that the union feature was stable, since
untagged unions are stable since 1.19, but turns out that smallvec uses non-Copy
types in unions, which are still unstable.
This leaves the union feature used on Servo, so that it gets testing, taking
advantage of features being additive.
We had a mix of 0.6.2 and 0.6.5 (which is the current release),
this unifies to the latest version. It also enables the union
feature which removes the discriminant, reducing memory usage.
To support that, this patch also does the following.
- Removes the insert(), remove() and might_contain() methods, because they are
specialized versions of insert_hash(), remove_hash(), and
might_contain_hash(), and they are only used by tests within this file.
- Moves hash() from the top level into create_and_insert_some_stuff().
- Changes create_and_insert_some_stuff() so that instead of hashing consecutive
integers, it instead hashes stringified consecutive integers, which matches
real usage a little better.
- Raises the false_positives limit a little to account for the above changes.
Bug: 1484096
Reviewed-by: heycam
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
It seems that the result of hash algorithm used in bloom filter depends
on the pointer length. On 64bit platforms, there are 135 false positives
in the first part of that test, and 8 in the second part. However, on
32bit platforms, the numbers become 157 and 16 correspondingly.
16 is still less than 20% in the second part, so all fine, but 157 is
slightly larger than 15% in the test assertion. Given it is what we are
shipping, we probably should just accept this and loosen the assertion.
Bug: 1457524
Reviewed-by: heycam
MozReview-Commit-ID: 9kFXBzLFAzE
