1942695 - Nested CSS :has() selector not matching

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Thomas Jaggi]

Steps to reproduce:

1. Navigate to https://codepen.io/backflip/pen/YPKOXzZ
2. Hover or focus Level 1 in 1. Failing example section

Actual results:

The dropdown containing Level 2 does not appear.

Expected results:

The dropdown should appear both when hovering and focusing.

---

Simplifying the selector fixes the issue, see 2. Working example without :has, 3. Working example with single selector and 4. Working example with reduced nesting.

I don't know whether this is a bug or an edge case covered by the specification.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::CSS Parsing and Computation' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Emilio Cobos Álvarez [:emilio]]

Thanks for the test-case! This looks a lot like an invalidation bug.

So, the failing selector would expand to:

:is(:is(.example-1 li:has(ul)):hover, :is(.example-1 li:has(ul)):focus-within) ul { display: block }

If I'm not wrong. The fact that it matches if you do something like context-menu-clicking or something that triggers other kind of invalidation happens, also makes it clearer this is an invalidation issue.

Interestingly, if I just manually expand the selector then it works. Which makes me smell like something about the relative selector cache might be getting confused, or some of the other invalidation-specific logic from bug 1874042.

David, any chance you can take a look?

Comment 3

[David Shin[:dshin] (PTO Til 17th)]

Yeah - You're right, this is from bug 1874042.

For this bug to trigger, need to have a selector list that only returns "Not matched" and "Unknown" during invalidation.
In matching these, we end up using KleeneValue::any(selector_list, matches_complex_selector), Which &&s the non-true values.
So we have a mix of False and Unknown for each selector (In the compound :has(...):focus-within, invalidation matching result is always Unknown, since that compound matching depends on :has(), whose match we defer), and we want the overall result to be Unknown so that we can run invalidation to figure out the unknown, but since False is stronger in Kleene logic, we end up returning False and not invalidating.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1874042

Comment 5

[David Shin[:dshin] (PTO Til 17th)]

Attachment: Bug 1942695: Ensure that unknown match results don't get overwritten in selector lists. r=#style

Comment 6

[Daniel Holbert [:dholbert]]

We're in a soft code freeze right now, so this probably wants to wait to land until Monday (for Nightly 137), at which point it'd maybe be a good candidate for uplift to beta136 once it's gotten some minimal amount of Nightly bake time. (and maybe uplift to esr 128?)

We can probably consider this wontfix for v135, though, given that 135 is already in release-candidate phase and essentially "done" for anything non-hair-burning, and this particular bug is one that we've been living with for long enough that it's not worth introducing any upheaval for that release. --> Marking as such.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bc9e2229b06c
Ensure that unknown match results don't get overwritten in selector lists. r=firefox-style-system-reviewers,emilio

Comment 8

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/50464 for changes under testing/web-platform/tests

Comment 9

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/bc9e2229b06c

Comment 10

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 11

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:dshin, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox136 to wontfix.

For more information, please visit BugBot documentation.

Comment 13

[David Shin[:dshin] (PTO Til 17th)]

Waiting for a bit more bake time. Perhaps next Monday (Feb 10).

Comment 14

[Donal Meehan [:dmeehan]]

(In reply to David Shin[:dshin] from comment #13)

Waiting for a bit more bake time. Perhaps next Monday (Feb 10).

:dshin do you still want to add a beta uplift request on this? Or, should it ride the train with Fx137?

Comment 15

[Daniel Holbert [:dholbert]]

I think dshin's on PTO until next week, so he probably won't see comment 14 right away. So: likely this'll just be riding the trains with 137. (And that's probably fine -- probably no need to rush to get this one release earlier, since we've been shipping with this bug since version 126, it looks like.)