Selector-matching can backtrack when looking for ancestor combinators, so we
can't just arrive there once and forget.
Also, there was a further problem before this patch, which was that
note_next_sequence was called _before_ checking whether all simple selectors
matched, so the sequence you could get there is just wrong.
Bug: 1384020
Reviewed-by: canaltinova
MozReview-Commit-ID: 6g0ibb8EfBU
Otherwise, tests like the following fail, given we always match as unvisited,
and we'd never mark the link as needing invalidation.
<!doctype html>
<style>
a {
color: red !important;
}
.foo :visited {
color: green !important;
}
</style>
<div>
<a href="https://google.es">visit me</a>
<button onclick="this.parentNode.className = 'foo'">Then click me</button>
</div>
Bug: 1368240
MozReview-Commit-ID: LDv6S28c4ju
Once we've encountered a relevant link, stop looking for potential relevant
link. A relevant link is only the nearest ancestor link, so it is incorrect to
keep looking once one is found. This only matters for the somewhat unusual case
of nested links.
MozReview-Commit-ID: LiXsUGWfxg3
To support visited styles, we match and cascade a separate set of styles any
time we notice that an element has a relevant link.
The visited rules and values are held in `ComputedStyle` alongside the
regular rules and values, which simplifies supporting various APIs like
`cascade_primary_and_pseudos` which expect easy access to previously matched
rules.
To simplify passing the additional values around, an additional reference to the
visited `ComputedValues` is placed inside the regular `ComputedValues`.
MozReview-Commit-ID: 2ebbjcfkfWf
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
These are never stored persistently anywhere, and I'm pretty sure it's slower
for the compiler/CPU to operate on non-word-sized flags.
MozReview-Commit-ID: LQNsJbUsw85
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.
