:has(+ selector) regression.

[XX-J]

В расширении v4.1.39 на FireFox v102.6 ESR следующие два примера работают, в более новых версиях расширения - нет.

1. Скрытие маленького рекламного баннера над списком писем в почте Mail.ru правилом e.mail.ru##div:has(+ .only-new-toolbar). Обязательно: открывать какую-нибудь папку, а не письмо, например https://e.mail.ru/inbox/.

Screenshot:


---

2. Скрытие главного, большого баннера на главной странице https://www.rambler.ru/ правилом www.rambler.ru##div:has(+ .commercial-branding). Причём правило www.rambler.ru###app > div:has(+ .commercial-branding) работает и в v4.1.53 и в v4.1.55

Screenshot:


[ameshkov]

Есть приличный шанс что :has мы теперь нативно применяем, его же в браузеры добавили.

Попробуйте document.querySelectorAll протестировать в браузерной консоли, отличается ли результат?

[XX-J]

Есть приличный шанс что :has мы теперь нативно применяем, его же в браузеры добавили.

Нет, и, надеюсь, в ближайшее время вы не будете его нативно применять, т.к. в Chromium его добавили только со 105-й версии, а в FireFox со 103-й, и то, только через принудительное включение. + Ваш :has круче нативного - он может быть вложен в другой :has (по крайней мере так в вашей справке).

И, я же писал:

В расширении v4.1.39 на FireFox v102.6 ESR следующие два примера работают... Причём правило www.rambler.ru###app > div:has(+ .commercial-branding) работает и в v4.1.53 и в v4.1.55

[krystian3w]

Nesting has usually doesn't make sense, you can rewrite 99% of the rules into a single using has that checks the whole string path at once. Nesting is unlikely to slow down rule so much that a flawed script could not generate an "ad blocking detected" message because of it.

Such a thing is not nesting:

• ##article:has(p) ~ section:has(div)
• ##article:has(p, div)

• ##article:has(p):has(~ section)

  and is compatible with CSS4: https://jsbin.com/wurumey/edit?html,css,output https://output.jsbin.com/wurumey

Detecting that you prefer to use ExtendedCSS (nesting something not allowed in CSS like contains, matches-css), should be fixed mostly within the ticket: https://github.com/AdguardTeam/ExtendedCss/issues/149.

---

в более старших версиях расширения - нет

understood as: in older versions of the extension - no

Besides, rather 99 percent of add-ons don't support reverse repair - I wouldn't expect the release of 4.1.37.1 / 4.1.36.1 / 4.1.22.1 ... 4.0.204.1 (or any old one, e.g., for Firefox 52-56 on line 3.6.17.1) as a fix.

As for repairing it to work without "#app >", I see no contraindication (as long it is not the new mechanism limiting JS checking of several hundred divs on a page - 7 checks vs 599 checks), but in release 4.1.56+.

[XX-J]

Detecting that you prefer to use ExtendedCSS (nesting something not allowed in CSS like contains, matches-css)...

No. I mean only: e.mail.ru##div:has(+ .only-new-toolbar) and www.rambler.ru##div:has(+ .commercial-branding).

в более старших версиях расширения - нет understood as: in older versions of the extension - no

Is not right. Understood as: "...in upward versions of the extension - no." I.e. in v4.1.46 and up - no.

I see no contraindication (as long it is not the new mechanism limiting JS checking of several hundred divs...

Both rules should to work, with #app > or without.

Speaked "...new mechanism limiting JS checking of several hundred divs..." you mean limitation of "Manifest v3" or ..?

[krystian3w]

I am more concerned with assessing whether the rule is efficient regardless of the manifest.

Perhaps based on Mozilla's telemetry, it was determined how often the message "AdGuard slows down the browser/page" is seen and linked to rules that the user manually adds, e.g. checking 500 elements with ExtendedCSS.

[XX-J]

Mozilla's telemetry is off. I don't seen message "AdGuard slows down the browser/page". 599 checks divs is not a lot (IMHO).

[slavaleleka]

it's just a bug of ExtendedCss v2, it shall be fixed in future

we do not apply the :has() pseudo-class natively yet. and Firefox does not support it yet too