It's just a struct aggregating stylesheets + CascadeData, with a quirks_mode
parameter because XBL sucks so bad.
Bug: 1436059
Reviewed-by: xidorn
MozReview-Commit-ID: 7q99tSNXo0K
The reason why bug 1355721 regressed this is because in non-e10s we definitely
flush before parsing the standards quirks-mode. And bug 1355721 introduced an
unconditional UpdateStylistIfNeeded, unless the counter style / font
equivalents.
That means that the stylist wouldn't remain on its initial state after the first
flush, which itself means that when the compat mode changed, the UA and user
rules were already on the stylist with the quirks mode keys. That makes
class-names be keyed in ascii lowercase.
After that no user style changed, so no rebuild happens for the cascade data in
the user origin, so we keep looking at the wrong keys indefinitely.
We should try to avoid the flush there and ensure that by the time we create a
pres shell the quirks mode is already up-to-date...
Bug: 1394233
Reviewed-by: xidorn
MozReview-Commit-ID: 25dD2bca3tN
In particular, `rebuild` is now done entirely by CascadeData, which simplifies
more stuff.
The eventual final state for this is that the data structure we use to store the
XBL / Shadow DOM stuff will be something like:
struct AuthorStyles { CascadeData, AuthorSheetCollection }
MozReview-Commit-ID: 8TExtP58L4X
This will make it easier to handle it properly for Shadow DOM, though this patch
doesn't do that.
This also makes some method inline and infallible for convenience, since nobody
checks the errors anyway.
Bug: 1436798
Reviewed-by: bholley
MozReview-Commit-ID: Hq3erAUs5tf
Chances are we need to pass it around in a bit.
Also invert the boolean because I don't want to reason about double negations,
even if they're simple.
MozReview-Commit-ID: KhX4lDKwDoj
This avoids resetting the computed values all the time, and paves the way to
avoid using a StyleSet on XBL bindings / Shadow DOM, which we should really
really do because it's super overkill.
There are some XBL bits that are kind of hacky, in particular the mStylistDirty,
but they'll go away soon, since I want to redo how we store styles in XBL.
The alternative, which was returning an array of indices or something was even
more hacky I think.
Bug: 1435939
Reviewed-by: xidorn
MozReview-Commit-ID: 6tEl5gebXVF
Otherwise removal of stylesheets may get out of sync with other DOM changes, and
we may fail to invalidate the style of the affected elements.
Bug: 1432850
Reviewed-by: bz
MozReview-Commit-ID: DrMTgLzQcnk
Now that we have an Element around on cascade, we can stop using the cascade
flags mechanism to pass various element-related state, like "is this element the
root", or "should it use the item-based display fixup".
That fixes handwaviness in the handling of those flags from style reparenting,
and code duplication to handle tricky stuff like :visited.
There are a number of other changes that are worth noticing:
* skip_root_and_item_based_display_fixup is renamed to skip_item_display_fixup:
TElement::is_root() already implies being the document element, which by
definition is not native anonymous and not a pseudo-element.
Thus, you never get fixed-up if your NAC or a pseudo, which is what the code
tried to avoid, so the only fixup with a point is the item one, which is
necessary.
* The pseudo-element probing code was refactored to return early a
Option::<CascadeInputs>::None, which is nicer than what it was doing.
* The visited_links_enabled check has moved to selector-matching time. The rest
of the checks aren't based on whether the element is a link, or are properly
guarded by parent_style.visited_style().is_some() or visited_rules.is_some().
Thus you can transitively infer that no element will end up with a :visited
style, not even from style reparenting.
Anyway, the underlying reason why I want the element in StyleAdjuster is because
we're going to implement an adjustment in there depending on the tag of the
element (converting display: contents to display: none depending on the tag), so
computing that information eagerly, including a hash lookup, wouldn't be nice.
Not super-proud of this one, but it's the easiest way I could think of.
The changeset looks bigger than what it is, because while at it I've rewrapped a
fair amount of functions around to use proper block indentation.
Alternatives are parameterizing Stylist by <E>, which is not fun, or moving the
concrete element from layout_thread to layout, but that implies layout depending
on script, which isn't fun either.
Other alternative is implementing an empty enum and making anon boxes work on
it. It has the advantage of removing the annoying type parameter, but the
disadvantage of instantiating `cascade` twice, which isn't great, and having to
maintain all the boilerplate of a `TElement` implementation that just does
nothing.
This is a partial revert of
ce1d8cd232
If you're in a shadow tree, you may not be slotted but you still need to look at
the slotted rules, since a <slot> could be a descendant of yours.
Just use the same invalidation map everywhere, and remove complexity.
This means that we can do some extra work while trying to gather invalidation
if there are slotted rules, but I don't think it's a problem.
The test is ported from https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/fast/css/invalidation/slotted.html?l=1&rcl=58d68fdf783d7edde1c82a642e037464861f2787
Curiously, Blink fails the test as written, presumably because they don't flush
styles from getComputedStyle correctly (in their test they do via
updateStyleAndReturnAffectedElementCount), due to <slot>s not being in the flat
tree in their implementation.
Bug: 1429846
Reviewed-by: heycam
MozReview-Commit-ID: 6b7BQ6bGMgd
style: Remove some unneeded indirection.
All TElement's implement Copy, and are just pointers, so the double indirection
is stupid.
I'm going to try to see if removing this double-indirection fixes some
selector-matching performance, and this is a trivial pre-requisite while I wait
for Talos results.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/19734)
<!-- Reviewable:end -->
All TElement's implement Copy, and are just pointers, so the double indirection
is stupid.
I'm going to try to see if removing this double-indirection fixes some
selector-matching performance, and this is a trivial pre-requisite while I wait
for Talos results.
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.
This function is only ever used with one type. This gets rid of the
only use of the `smallvec::VecLike` trait, which we may want to
deprecate. (If we do need to make this function generic in the future,
we can do it using standard traits instead.)
In Gecko, we handle XBL rules like author rules everywhere, except that
XBL rules are added and sorted in an independent step, behave as if it
has a separate level.
It is not clear to me why Stylo chose to add a separate level for XBL
rules, but it doesn't seem that there is anything special to do with
XBL rules.
This bug happens because we don't handle XBL important rules which are
handled as part of author rules in Gecko due to lack of the additional
level there. We should just follow what Gecko does here and handle them
all the same.
