Extend restyle hints to check additional cases for visited.
If we are sensitive to visitedness and the visited state changed, we force a
restyle here. Matching doesn't depend on the actual visited state at all, so we
can't look at matching results to decide what to do for this case.
This also updates the snapshot version of `match_non_ts_pseudo_class` to check
the relevant link instead of the element state, just like we do when matching
with regular Gecko elements.
There's also a separate case of a visited-dependent selector when other state or
attributes change. For this, we need to cover both types of matching we use
when cascading values. If there is a relevant link, then we also matched in
visited mode. Match again in this mode to ensure this also matches. Note that
we never actually match directly against the element's true visited state at
all, since that would expose us to timing attacks. The matching process only
considers the relevant link state and visited handling mode when deciding if
visited matches.
MozReview-Commit-ID: CVGquetQ2VW
Adjust the matching process to look for a "relevant link" while matching. A
"relevant link" is the element being matched if it is a link or the nearest
ancestor link.
Matching for links now depends on the `VisitedHandlingMode`, which determines
whether all links match as if they are unvisited (the default) or if the
relevant link matches as visited (and all others remain unvisited).
If a relevant link is ever found for any selector, track this as part of the
`MatchingContext` object. This is used in the next patch to determine if an
additional match and cascade should be performed to compute the styles when
visited.
MozReview-Commit-ID: 3xUbRo7vpuD
This is likely to be important at least for the initial element.
For the rest of them this is likely useless because we create them in a
throwaway fashion.
MozReview-Commit-ID: EFz9WUdB8S0
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
I've chosen this approach mainly because there's no other good way to guarantee
the model is correct than holding the snapshots alive until a style refresh.
What I tried before this (storing them in a sort of "immutable element data") is
a pain, since we call into style from the frame constructor and other content
notifications, which makes keeping track of which snapshots should be cleared an
which shouldn't an insane task.
Ideally we'd have a single entry-point for style, but that's not the case right
now, and changing that requires pretty non-trivial changes to the frame
constructor.
MozReview-Commit-ID: FF1KWZv2iBM
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
My measurements are inconclusive as to whether this really moves the
needle, but it seems like the right way to do it in any case.
MozReview-Commit-ID: 7OuCc2aQ7jH
The current code is busted because:
* It unconditionally flags for revalidation if the sensitivities are not yet
sensitive to attributes.
* It uses is_attr_selector, despite the fact that ID and Class are both handled
by the style sharing cache and should not trigger revalidation.
MozReview-Commit-ID: C7d8QrdKcFm
This improves cache locality and reduces allocations during parsing.
Note that this reverses the iteration order within a sequence of simple selectors,
but that shouldn't matter.
It's clearly wrong to use intersects() there, since the coming check may be a
bigger hint.
MozReview-Commit-ID: 1YZ8OD0ajSz
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
Also, simplify all the pre-snapshot attribute hacks in the script and style
code.
MozReview-Commit-ID: 6c9ipeb7Tnr
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
