Bug 273125 – :has(:is(...)) / :has(:where(...)) is broken when there are multiple :has() rules on the same selector

• Status: NEW
• Component: CSS

[Benoît Rouleau]

Created attachment 471070 [details]
test case

Maybe related to bug #253944

See the attached test case. The `.container` element should be blue (like in Chrome and Firefox), but it's red in all the versions of Safari that I tested it in. Notice that if you remove the first rule (the `.card:has(button)` one), then it is blue as expected.

Marked this as critical because this has the potential to break whole features that rely on `:has()` being supported (which it now is in all the big browsers).

[Benoît Rouleau]

Created attachment 471071 [details]
actual test case (ignore the other one, forgot to save -_-)

[Karl Dubost]

Created attachment 471098 [details]
rendering in safari, firefox, chrome

confirmed

[Radar WebKit Bug Importer]

<rdar://problem/126960335>

[Roman Komarov]

Wanted to report a similar bug, my repro: https://codepen.io/kizu/pen/abMbrya (in my case I was able to work around it by adding an extra `&, &` nesting level, not sure why it did work)

[Benoît Rouleau]

A valid CSS selector that doesn't match what it should seems pretty critical to me. 🫠

[Eric Kwoka]

Seems that whatever logic Webkit uses to optimize :has starts to fail even on some not all that complicated ones.

Like a `:has(> &)` just needs to select the immediate parent, which works, until the dom depth is too far, then it just fails. As if they just whole ass disable `:has` once the depth is too far

[Simon Fraser (smfr)]

Do these bugs still reproduce in Safari Tech Preview? We've made a number of fixes in this area.