Prevent uBO from hiding html or body when matched by a generic cosmetic filter #1692

@felix-22 thanks for links!

Yeah adding :not(body):not(html) after each generic entry systemically, would pre-emptively help and would completely solve this issue, I even suggested that same thing recently: easylist/easylist#8367 though it would bloat filterlist a bit. I don't know about performance impact. But encountering this same issue over and over again (hundreds of :not(html) and :not(body) exceptions) feels unnecessary as it would be possible to do pre-emptive measures.

The best thing to do is to adjust blockers not to block body and html elements. The question is, could all major blockers work together to achieve that?

The best thing to do is to adjust blockers not to block body and html elements. The question is, could all major blockers work together to achieve that?

I hope so:

https://github.com/AdguardTeam/AdguardBrowserExtension/issues/1845
https://gitlab.com/eyeo/adblockplus/abc/adblockpluscore/-/issues/361

The best thing to do is to adjust blockers not to block body and html elements.

Majority of CSS selector-based cosmetic filters are enforced through user styles, this means internally each of those filters would need to be suffixed with :not(html):not(body), while ensuring they are still properly reported in the logger. It's not trivial.

What if this is taken care of at the DOM surveyor level?

-            pendingNodes.add(document.querySelectorAll('[id],[class]'));
+            pendingNodes.add(document.querySelectorAll(':not(html):not(body)[id],:not(html):not(body)[class]'));

I'm guessing that this would cause issues for selectors containing descendant and child combinators.

If this were to be implemented, it still should be possible to be able e.g. to target html or body via different styling rules or via scriplets, the only thing that should be prevented is using display: none !important to them.

it still should be possible to be able e.g. to target html or body via different styling rules or via scriplets

The way I see it the automatic exclusion of html/body should apply only to generic cosmetic filters which are made of a single class or id identifier, so this means you would still be able to target html or body by using these explicitly.

I'm guessing that this would cause issues for selectors containing descendant and child combinators.

This is an interesting idea. The issue of combinators maybe could be solved by having a separate reporting for ids/classes taken directly from html/body elements.

I'm guessing that this would cause issues for selectors containing descendant and child combinators.

To clarify, let's say there's a document like this:

<body>
  <article>article>
body>

And a filter like ##.page-body > article.

The document uses JS to add the page-body class to the body element.

If the DOM surveyor ignores the body element, the filter will never work?

If the DOM surveyor ignores the body element, the filter will never work?

When I say "separate reporting", I mean the ids/classes of html/body elements would be reported in special properties (not through these), and treated differently in the background process -- for these uBO would only look-up the complex set, and thus would be able to find and apply something like .page-body > article.

which are made of a single class or id identifier

There are some generics that have multiple values (samples from Fanboy's Annoyances):

##.js-stickyFooter.u-bottom0.u-fixed
##.u-zIndexMetabar.u-fixed
##.article-section > .ui-button-close
###coiOverlay[role="banner"][style*="flex"]

Though I agree that they are not very common.

Installed 1.37.3b15 and tested with the site (webshop.elektroskandia.no) and with the sample rule I gave (##.consent-summary-shown), works fine, thanks!

Maybe * aka all URL-s also need similar disable breakage.

Now possible use * to avoid create specific filter with :watch-attr() if someone must check ID/Classes/attribs injected very late into dom tree/main nodes.

E.g.:

https://czyodebrac.pl/co-to-za-numer-dzwonil/2147483647/

on page no longer works these generic filter:

##.cli-modal-open #cookie-law-info-bar

#cookie-law-info-bar is not body/html tag but "

".

or have very Race Conditon in uBO 1.37.3rc0, but 1.37.2 injected filter almost immediately.

High profile case involving highly generic cosmetic filter: uBlockOrigin/uAssets#11244.

Highly generic cosmetic filters should not longer affect html/body elements. To confirm, I used the original steps-to-reproduce, except with the following filter:

##[class*="consent-summary-shown"]

I would propose to add article tag to html and body. Should I open a new issue?

Should I open a new issue?

No, doing what you suggest would just allow advertisers to use article to bypass cosmetic filters -- there is no restriction on the number of article tags in a page.