You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
nested :has() selector not working [v1.17.2] #2131
Yes, on one hand - nested :has() is not supported by browsers
The :has() pseudo-class cannot be nested within another :has(). This is because many pseudo-elements exist conditionally based on the styling of their ancestors and allowing these to be queried by :has() can introduce cyclic querying
Activity
jhy commentedon Jul 3, 2024
General nested
:has()selectors do work - we have tests here:jsoup/src/test/java/org/jsoup/select/SelectorTest.java
Lines 577 to 594 in c3963d4
I thought this might be related to #2137, but it doesn't seem to be.
But, your selector doesn't work in Chrome either.
So I'm not 100% sure here...
ogolovanov commentedon Jul 6, 2024
Yes, on one hand - nested :has() is not supported by browsers
On the other hand - "pseudo-elements problem" is a problem for browsers, but not for jsoup
https://developer.mozilla.org/en-US/docs/Web/CSS/Pseudo-elements
Anyway, it would be nice if you could fix it.
jhy commentedon Aug 5, 2024
Looking at it some more. I don't think it's specifically the nested has.
The query can be simplified to:
div:has(>div + div)which fails (yet works in browsers). Both
div:has(div + div)anddiv:has(>div)work.https://try.jsoup.org/~0Imle8wRufxJsGLk0Lt2ReHywC8
So there is an incorrect interaction between the ImmediateParentRun and the ImmediatePreviousSibling, somehow.
jhy commentedon Sep 10, 2024
This is an effective dupe of #2187
jhy commentedon Sep 10, 2024
Actually, my reduction of the issue found the same as #2187, but the initial report is something different.
jhy commentedon Sep 10, 2024
div:has(div:has(span) + div:has(span))works OK (now) -- without the>direct child of. The direct child of is not taking the appropriate (?) root.jhy commentedon Sep 11, 2024
OK, fixed! Thanks for the report. It wasn't the root being incorrect, it was re-use of the inflight Element Iterator that was trashing the match.
Use a SoftPool of ElementIterators vs a single ThreadLocal
chore(deps): update all non-major dependencies (mulk/mulkcms2!58)