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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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.
This cherry-picks servo/servo#21788.
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.
This cherry-picks servo/servo#21746.
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.
--HG--
extra : rebase_source : f839ff86986d5c8a17506a808ba676f69c7ef407
This saves about 37 KiB of memory across the UA style sheets.
MozReview-Commit-ID: EoZnlmyWwxX
--HG--
extra : rebase_source : cd8ef0ba838618f9a4583b7d9896caa3a0602199
Summary:
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.
Test Plan: WPT for style invalidation, covered by existing tests otherwise.
Reviewers: heycam
Tags: #secure-revision
Bug #: 1450250
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.
MozReview-Commit-ID: 9kFXBzLFAzE
--HG--
extra : rebase_source : 41fa45dc3c59b2f44d33bdbe86b3eb2e29a31319
Now that rustfmt is getting close to stable, and work on the style system has died down a bit, it seemed like an opportune time to auto-format the style crates.
The first commit disables import reordering, since tidy and rustfmt don't currently agree on the correct ordering. The second commit does a bunch of manual fixups such that the output of rustfmt passes tidy. The third commit runs rustfmt on the three aforementioned crate.
There are a few dozen warnings in the style crate about lines longer than 100 characters. It would be good to fix these, but I don't have time for that now.
Source-Repo: https://github.com/servo/servo
Source-Revision: 9a900ef019cd643bff961d7b20db6da69f3edb29
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 2b228d52a084bc832444ac686290840c4369f98d
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
Source-Repo: https://github.com/servo/servo
Source-Revision: e11c2d97552d192b761b0684c8c6852b9dea0921
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 00941db97d18fcbea845f225d318eae4d47aab22
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
Source-Repo: https://github.com/servo/servo
Source-Revision: cb754b262747e7cab794411df55588f0f0b30b5e
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 2ebbb2578ff9dbadfe905ae501cd52bd61a9fe9a
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
Source-Repo: https://github.com/servo/servo
Source-Revision: 8e52f8a523e2f12b2666536d0f8ff3fa40b83ef5
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 4b8b140e54485fb2762745f13af285c640d39254
