Nested CSS :has() selector not matching
Categories
(Core :: CSS Parsing and Computation, defect, P3)
Tracking
()
People
(Reporter: thomas, Assigned: dshin, NeedInfo)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(1 file)
Steps to reproduce:
- Navigate to https://codepen.io/backflip/pen/YPKOXzZ
- Hover or focus
Level 1
in1. 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•21 days ago
|
||
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•21 days ago
|
||
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?
Updated•21 days ago
|
Assignee | ||
Comment 3•19 days ago
•
|
||
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.
Assignee | ||
Updated•19 days ago
|
Comment 4•19 days ago
|
||
Set release status flags based on info from the regressing bug 1874042
Assignee | ||
Comment 5•19 days ago
|
||
Updated•19 days ago
|
Updated•19 days ago
|
Comment 6•11 days ago
|
||
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 9•7 days ago
|
||
bugherder |
Updated•6 days ago
|
Comment 12•5 days ago
|
||
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
towontfix
.
For more information, please visit BugBot documentation.
Assignee | ||
Comment 13•5 days ago
|
||
Waiting for a bit more bake time. Perhaps next Monday (Feb 10).
Description
•