We want to drop the cascade data memory as soon as possible, so bug 1544546
introduced an UpdateStylistIfNeeded call from ShellDetachedFromDocument.
Unfortunately, this call can reenter into the global user-agent cascade data if
some of the CSS values kept alive by the cascade data keep alive an SVG
document, see the stack on this bug for an example. Make sure to drop the
user-agent cascade datas when not holding the cache lock to avoid this
situation.
Before bug 1535788, we just destroyed the stylist, so we kept holding a
reference from the cache, and that reference will be dropped sometime later when
other document updated their user-agent stylesheets (if they happened not to
match the cache of course).
Seems to me this doesn't ended up happening in our automation, but it could
happen in the wild, in theory at least.
It's nice that Rust made this a safe deadlock caught by our tests rather than a
very subtle and infrequent memory corruption.
The relevant SVG documents are probably the <input type=number> rules:
https://searchfox.org/mozilla-central/rev/d80f0a570736dce76a2eb184fb65517462089e8a/layout/style/res/forms.css#1050
Differential Revision: https://phabricator.services.mozilla.com/D28299
When you're in a ShadowRoot and can share style with a sibling, the sharing code
is smart enough to skip document author rules.
But then it could get confused if you also include document rules, since
revalidation selectors are matched against these.
This is not a correctness issue, because we're matching more than what we need,
and avoid sharing if we failed.
Also fix the detection for user rules in any_applicable_rule_data.
Differential Revision: https://phabricator.services.mozilla.com/D10117
I plan to change servo to use all: inherit on its UA sheet.
I hope the patch below should make it good enough performance-wise. And also,
it's probably broken so I don't think it's worth supporting it specially.
Differential Revision: https://phabricator.services.mozilla.com/D8686
This also removes one of my FIXMEs from when I was looking at this code.
We don't seem to have a pre-existing test for this feature, sigh. I'll try to
write one if I have cycles for it...
Note that it not applying XBL rules is a feature, given the current state of
affairs. Video controls and such are right now unusable with no styles enabled.
Differential Revision: https://phabricator.services.mozilla.com/D4795
We're wasting 1kb there, which is kind of stupid.
The only advantage of using a bloom filter is that memory usage doesn't increase
even if there's a gazillion attribute selectors and such. But:
* For IDs we already have a bunch of data structures for invalidation and such
which key on the id, so the bloom filter would be a very minor thing.
* For attribute selectors we don't have such a data structure, but if people
used a gazillion attribute selectors we should!
Differential Revision: https://phabricator.services.mozilla.com/D4668
So that we don't waste a bunch of memory with stuff like <svg:use>. I
plan to shrink AuthorStyles further, but this should help regardless, and isn't
very complex.
Differential Revision: https://phabricator.services.mozilla.com/D4618
We only have this so that ::-moz-placeholder keeps serializing as
::-moz-placeholder, but I don't think anybody really cares.
Edge aliases ::-webkit-input-placeholder to ::-ms-input-placeholder at parse
time as well, as can be seen in:
```
let s = document.createElement('style');
s.innerHTML = `input::-webkit-input-placeholder { color: red };`;
document.body.appendChild(s);
document.body.innerHTML = s.sheet.cssRules[0].cssText;
```
And I think this is more consistent with what we do for CSS properties that are
aliases.
Differential Revision: https://phabricator.services.mozilla.com/D2595
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
Inserting a lot of rules in the root level is super-inefficient. This fixes it
by not doing it.
It gives the root rule node to the style, but that's fine, since it's useless.
All this code-path is already pretty messy.
Bug: 1457678
Reviewed-by: xidorn,hiro
MozReview-Commit-ID: GoGHI4YJbKr
No cleaner ideas right now that carrying that counter around... Maybe a custom
type may be cleaner?
This makes ApplicableDeclarationBlock a bit bigger. I could probably try to make
the counter a 4 / 5-bit number or something and pack the counter there in the
SourceOrderAndCascadeLevel somehow...
But doesn't seem really worth the churn, and can be done as a followup in any
case. Let me know if you want to block on that.
Bug: 1454162
Reviewed-by: heycam
MozReview-Commit-ID: 1LdW9S4xA6f
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
