Closed Bug 1672018 Opened 4 years ago Closed 4 years ago

[wpt-sync] Sync PR 26139 - [:is/:where] Support :link/:visited

Categories

(Core :: CSS Parsing and Computation, task, P4)

task

Tracking

()

RESOLVED FIXED
84 Branch
Tracking Status
firefox84 --- fixed

People

(Reporter: mozilla.org, Unassigned)

References

()

Details

(Whiteboard: [wptsync downstream])

Sync web-platform-tests PR 26139 into mozilla-central (this bug is closed when the sync is complete).

PR: https://github.com/web-platform-tests/wpt/pull/26139
Details from upstream follow.

b'Anders Hartvoll Ruud <andruud@chromium.org>' wrote:

[:is/:where] Support :link/:visited

For :link/:visited, the current behavior of SelectorChecker is that
both pseudo-classes will match any link (element.IsLink() == true),
regardless of their visited status. We then rely on the "static"
analysis of the selector (ComputeLinkMatchType()) to understand
apply-time whether to apply normal properties, -internal-visited
properties, or both. Hence, we are in a way delaying the "real"
match/no-match decision to apply-time.

This becomes complicated when :not() is involved, because we can no
longer simply invert the result of CheckOne: :link will match
any link, including visited links, so :not(:link) would (naively
implemented) not match visited links (which is should: it should
match anything except an unvisited link). There's an attempted
mitigation in place in CheckPseudoNot, where we check differently
for :link/:visited, but it doesn't work properly. There are still
cases where we don't match what we should (see the updated
test not-links.html).

When :is()/:where() is added to the mix, it becomes even more
complicated, as :not() can effectively nest, for example
:not(:is(:not(:visited))).

To deal with this complexity, this CL proposes an alternative
handling of visited links, in which we sometimes perform selector
matching twice. If we are inside a visited link, we first match the
selector as if we are not inside a visited link, and record the result,
and then match again with the real link status, and record that result
as well. This makes nested :not() scenarios work automatically, because
CheckPseudoClass is now actually checking the link status, rather than
just matching any link.

Obviously matching the same selector twice has performance implications.
To mitigate this as much as possible, we avoid the double matching
behavior for selectors which don't contain :visited or :link (even if
we're inside a visited link).

Bug: 568705
Change-Id: I08eeb225d52418b80535f996cecc888b05e23eec
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2476214
Commit-Queue: Anders Hartvoll Ruud \<andruud@chromium.org>
Reviewed-by: Rune Lillesveen \<futhark@chromium.org>
Cr-Commit-Position: refs/heads/master@{#817900}

Component: web-platform-tests → CSS Parsing and Computation
Product: Testing → Core

CI Results

Ran 12 Firefox configurations based on mozilla-central, and Firefox, Chrome, and Safari on GitHub CI

Total 2 tests

Status Summary

Firefox

PASS: 1
FAIL: 1

Chrome

FAIL: 2

Safari

PASS: 1
FAIL: 1

Links

Gecko CI (Treeherder)
GitHub PR Head
GitHub PR Base

Details

New Tests That Don't Pass

/css/selectors/is-where-visited.html: FAIL (Chrome: FAIL, Safari: FAIL)

Pushed by wptsync@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/34056381c854
[wpt PR 26139] - [:is/:where] Support :link/:visited, a=testonly
https://hg.mozilla.org/integration/autoland/rev/826fd02bff2d
[wpt PR 26139] - Update wpt metadata, a=testonly
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 84 Branch
You need to log in before you can comment on or make changes to this bug.