1860373 - :has() Invalidation Doesn't Work with CSS Nesting

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[dogatmidnight]

Attachment: input.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/118.0

Steps to reproduce:

See attached HTML. It uses the "hidden checkbox" trick so that clicking on a label ("Berlin", "London", or "Paris") should change the color of the #result div.
The CSS relies on the :has() function for this, but the corresponding rule is never triggered.
In developer tools, the first click on any not checked label results in a color change if the div element is selected in the inspector.

Actual results:

The color of #result remains blue, regardless of the checked state of the input elements. Clicking on a label does change the checked property. Also, removing the div around the input and label elements and adjusting the corresponding styles to

input#tab1:checked ~ #result {
background-color: blue;
}
input#tab2:checked ~ #result {
background-color: green;
}
input#tab3:checked ~ #result {
background-color: red;
}

(i.e. effectively removing the :has() function) makes the HTML behave as expected, i.e. color is changed on label click.

Expected results:

Chrome and Safari show the correct behavior:
The div is initially blue. Clicking on "London" changes it to green, clicking on "Paris" to red and on "Berlin" to blue again.

Comment 1

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

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

Comment 2

[dogatmidnight]

The "about.config" parameter layout.css.has-selector.enabled is set to true.

Comment 4

[dogatmidnight]

The bug that this one is a duplicate of has been closed. While apparently, it is not fixed (otherwise, I'd not have encountered the described issue).

Comment 5

[Tom S [:evilpie]]

Judging from your using agent string, you are using Firefox 118 and not 119. Thanks for the report anyway.

Comment 6

[dogatmidnight]

Attachment: Testcase for frozen 'has:' in FF119

Now that FF119 is out, I tested again – not fixed in my opinion (see test case below). 

Description: 
- Initially, "Europa" is `checked`, label `color: black; background-color: white`. That's correct. 
- Click on "Radtour": Europa has now label `color: black: background-color: blue`, "Radtour" has label `color: white; background-color: white`.That's **not** correct.
- Click anywhere in Developer tools window: Europa has now label `color: white; background-color: blue` and "Radtour" has label `color: black; background-color: white`. That's correct

Testcase:

Comment 7

[Emilio Cobos Álvarez (:emilio)]

I can repro comment 6 on nightly. David mind taking a look?

Comment 8

[dogatmidnight]

Attachment: Bug still present in FF119

Comment 9

[dogatmidnight]

Now that FF119 is out, I tested again – not fixed in my opinion (see test case attached ).

Description:

• Initially, "Europa" is checked, label color: black; background-color: white. That's correct.
• Click on "Radtour": Europa has now label color: black: background-color: blue, "Radtour" has label color: white; background-color: white.That's not correct.
• Click anywhere in Developer tools window: Europa has now label color: white; background-color: blue and "Radtour" has label color: black; background-color: white. That's correct

Comment 10

[David Shin[:dshin]]

Attachment: Minimized Test Case

Ah, the new case has to do with interaction with nesting.

Comment 11

[Emilio Cobos Álvarez (:emilio)]

Should be reproducible without nesting too right? :is(.outer:has(.foo)) .bar or so.

Comment 12

[David Shin[:dshin]]

So that works if I replace the nested selector with:

:is(.outer:has(.foo)) .bar {
  background: purple;
}

Comment 13

[Emilio Cobos Álvarez (:emilio)]

Is the has invalidation set somehow getting built before replacing the nesting selector? That seems wrong if so, but I don't see how that could happen.

Comment 14

[David Shin[:dshin]]

Ah, this is indeed an issue on relative selector invalidation end... We use a map hashed by relative selector pointer + the invalidation it generates to collapse duplicate invalidations into one. Since .outer:has(.foo) and & .bar share the has selector at pointer level, they are considered the same, and we think these two are duplicate of each other when it's not.

Comment 15

[David Shin[:dshin]]

Attachment: Bug 1860373: Don't collapse invalidations from selectors shared by nesting. r=emilio

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2fd60169f484
Don't collapse invalidations from selectors shared by nesting. r=emilio

Comment 17

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

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

Comment 18

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/2fd60169f484

Comment 19

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

Upstream PR merged by moz-wptsync-bot

Comment 20

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

Upstream PR was closed without merging

Comment 22

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

Copying crash signatures from duplicate bugs.