Nested procedural filtering into :has() did not works

[krystian3w]

Prerequisites

• I verified that this is not a filter issue (MUST be reported at filter issue tracker)
• This is not a support issue or a question
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue
• The issue is not present after wholly disabling uBlock Origin ("uBO") in the browser
• I checked the documentation to understand that the issue I report is not a normal behavior

I tried to reproduce the issue when...

• uBO is the only extension
• uBO with default lists/settings
• using a new, unmodified browser profile

Description

Nested has like:

example.*##div:has(h1:has-text(Example))

will no longer works with Chrome 105 after stable release if Google community no implement better native has in CSS.

So I reccomend mediation with Big "corporations" after bugs form console no looks to fix in Addons. I leave it free to throw this into the chromium and Firefox bugtrackers.

AdguardTeam/ExtendedCss#149

---

This can be too regresion after implement mix has with style #382 or fix Yuki issue #2170

---

AdGuard Base sometimes use domain.tld##foo:has(bar:has-text(word)); I don't checked this in uBo stock list or Regional.

A specific URL where the issue occurs

example.org / example.com

Steps to Reproduce

1. Install Chromium Browser 105+ or Opera 91+

• layout.css.has-selector.enabled in Firefox have same troubles - so can break filters in 2023/2024 after publish function as stable (for now have some glitches, so maybe Moz://a implement something to change nothing in uBo code)

2. Paste filter from description to My Filters (or elmenet picker (with omit domain) - as later step).

3. Open one of two demo Internet pages.

Expected behavior

Website should be "blank".

Actual behavior

Website isn't "blank".

uBlock Origin version

1.44.1b1

Browser name and version

Firefox 103, Opera 91+, Chrome 105+

Operating System and version

Windows 7/10

[gwarser]

@krystian3w this should be detected. Probably new implementation does not throw errors when fed with syntax which is not valid natively. Y:

[gwarser]

[gorhill]

MDN says:

:has( <forgiving-relative-selector-list> )

So :has() is forgiving now, meaning it won't throw when invalid selectors are passed to it.

[gorhill]

Why close? This needs fixing.

[krystian3w]

I meant no possible fix on addon level.

[gorhill]

I need to investigate what can be done.

[krystian3w]

If I correct checked latest stable 105 release of Chrome has landed with enabled has for CSS - so can back e.g. Instagram sponsored posts.

So Google community tries test of implementation on whole people (not on only beta, dev and canary level).

[gwarser]

##body:has(div:has(h1:has-text(Example))) does not work? Nightly with layout.css.has-selector.enabled, uBO 1.44.1b2

[krystian3w]

Also both no implement read :scope as visible in path - bad info for Nordic list.

Firefox also no implemented:

(> (maybe too + and ~)

Chrome ignore/no implemented:

body:has(body > as fallback to ":scope" if these are correct (e.g. in Firefox).

[Yuki2718]

Will uBO uses native :has if possible?

[gorhill]

Yes, that's the goal, it's already the case and it's actually why the issue exist here given that :has(...) has been spec'ed as a "forgiving" operator -- this makes sorting out prrocedural vs. declarative very difficult for uBO.

[gorhill]

I didn't expect Chrome 105 to reach stable already. I will have to do something to fix this and publish a 1.44.2 revision.

[gorhill]

The chosen solution is for filter authors to force the parsing of a filter as procedural by using #?# instead of ##. If a :has(...) filter does not result in the expected behavior for browsers supporting :has(...), force parsing as a uBO procedural by using #?#.

---

That said, ##body:has(div:has(h1:has-text(Example))) is kind of a contrived example since the filter would be better crafted as ##body:has(div h1:has-text(Example)), but it still is a valid filter and it will now work when using #?#.

[gothic-bum]

The chosen solution is for filter authors to force the parsing of a filter as procedural by using #?# instead of ##.

Will #?# also apply to other procedural filters that have native browser support (e.g. :not(...) ), or is it just for :has(...)?

[gorhill]

Any potentially procedural operator, so also :not(...). Normally uBO tries to compile them as declarative, #?# will prevent that.

[gorhill]

I do expect the need to use #?# to be rare, but we will see.

[MasterKia]

What about older rules? Do they all need to be tested again?

Can uBO warn in the syntax highlighter that this rule might need #?# instead of ##?

[krystian3w]

I detected teach browser be add-on how read child's:

firefox_udQvjabKc5.mp4

! https://codepen.io/bramus/pen/MWEvKEg
cdpn.io#?#figure:has(figcaption) img:style(outline: 10px dashed red;)

Without these teach, Mozilla fail don't stylize second image.

[gorhill]

I can reproduce the issue with Firefox with your filter once layout.css.has-selector.enabled is set to true -- not sure why as I stepped in the code once and all seemed to execute as expected -- this needs more investigation.

Without these teach

I don't understand that sentence, what is teach?

[krystian3w]

Mozilla based on devtools ignored has selector and matches second image without figcaption parent.

So uBo temporary teach demo how don't match false positives.

This maybe glitch similar to unhide node.

[Yuki2718]

So ##selector1:has(something) selecotor2 can cause FP on Firefox with layout.css.has-selector.enabled: true.

[krystian3w]

But hopefully not enabled for any groups:

• stable
• beta and oldie Aurora renamed to developer
• nightly

We can still fight for this piece of bread. But I don't see light to implement error for nesting.

[krystian3w]

I detected new regression in works :not() after enforce filter as procedural or in AdGuard style syntax in uBo 1.44.2:

! works simple negation
private-company-webapp.org##table td:has-text(employee1) ~ td:not([class*="day_off"]):style(border-top: 5px solid green)
!
! Both have broken `:not()`
private-company-webapp.org#?#table td:has-text(employee1) ~ td:not([class*="day_off"]):style(border-top: 5px solid green)
private-company-webapp.org#$?#table td:has-text(employee1) ~ td:not([class*="day_off"]) { border-top: 5px solid green }

The negation in enforced procedural and AdGuard syntax are cleared to empty brackets in use (possible see this in uBo logger). Also then no works disable broken filter by Author mode form advance settings (due no match with raw database?).

Minimal demo (PoC due company app is not public):

https://jsbin.com/gejiqan

IMO maybe possible fix instead rewrite filter or back to mixed declarative state.

[Nomes77]

I do expect the need to use #?# to be rare, but we will see.

I'm on FireFox 104.0.1 (layout.css.has-selector.enabled enabled) and with the latest stable uBo update and I only had to change one rule (procedural operator) of all rules I have, namely:
github.com##div.push > .body > :has([href="/apps/github-actions"]) to github.com#?#div.push > .body > :has([href="/apps/github-actions"]), but strangely github.com##div.push > [class="body"] > :has([href="/apps/github-actions"]) also worked.

[krystian3w]

I see breakage in uBo dev with >, ~ and + in html filtering (filters clear body from nodes/dom tree):

• Error:

  Uncaught DOMException: Element.querySelectorAll: ' > a' is not a valid selector
  html-filtering.js:201

• Cited code line:

  return Array.from(root.querySelectorAll(this.selector));

• Examples:

  gorhill.github.io##^#phf #a2 .fail:has(> a > b)
  gorhill.github.io##^#phf #a12 .fail:has(+ a)
  gorhill.github.io##^#phf #a13 .fail:has(~ a:has(b))

---

Workaround can be use upward.

IMO not related with experimental layout.css.has-selector.enabled - Those willing can check whether CSStree in html filtering (and the future implementation of has by browser engine).

Also no checked use "…", '…' or many backslashes to enforce as procedural (I already prefer to use upward).

Maybe works Fine in Firefox 104 and 106 (so can be 105 bug).

[krystian3w]

Latest uBo dev have if condition when found:

foo.who##a, b:has(c)

Because simple CSS hide any a without test exist c inside (only b are checked and no possible check elements above like b:has(body c)) - for joining recommended will be use: :is(a, b):has(c) as the shortest.

In short I mean CSS didn't followed content blockers decision.

[gorhill]

uBO should follow the expected result in CSS. With the previous parser there was not much motivation to do so because of all the added code complications, but this comes free with the new parser.

At this point I think I prefer to leave this to another dev build cycle though.

[krystian3w]

I think this can be regression in deprecated syntax:

1. Open on PC gorhill/uBlock@2f646db
2. Into picker paste ##.pl-s:if-not(*)
3. Filter matches ≈24 elements but only ≈four (4) are without childs, may works fine in ##.pl-s:not(:has(*))

If page don't have .pl-s maybe needed is enable sidebar with catalogs for commits.

In real cases regression will break pages like kobieta.wp.pl with MajkiIT oldie filter line (blank/blinks very important div in dom tree).

[gorhill]

Into picker paste ##.pl-s:if-not(*)

if-not is no longer documented as being valid, it should not be used as a case to fix.

[krystian3w]

So somebody must virtual kicked / prodded MajkiIT to update filter before new parser are stable.

Similar case like #2316 to remember update in filter file (if idea #2328 too much break html filtering).