Filter using procedural cosmetic filtering not working in Brave

[jlivak]

Description

The following filter doesn't seem to match anything when added to Brave, however works correctly if added to uBlock Origin installed in Brave.

! YT Home - Hide Videos Below 1K Views (backup version - less efficient)
www.youtube.com##ytd-browse[page-subtype="home"] ytd-rich-item-renderer:not(:has(#video-title[aria-label~="views"], .yt-lockup-view-model-wiz--collection-stack-2)) :is(#metadata-line>span:first-of-type, .yt-content-metadata-view-model-wiz__metadata-row):not(:has-text(/[KMB]\b/)):upward(ytd-rich-item-renderer)

Steps to reproduce

1. Add the above filter to your custom filters list.
2. Open the YouTube home page, preferably logged into an account, so recommended videos are populated.

Actual result

No elements on the page are matched or blocked.

Expected result

Any videos with under 1000 views are blocked.

Reproduces how often

Easily reproduced

Brave version (brave://version info)

Brave | 1.77.101 Chromium: 135.0.7049.115 (Official Build) (64-bit)
Revision | 26bbcaf2303c02c94bd16823418eb1e83a00b86b
OS | Windows 11 Version 21H2 (Build 22000.527)

Channel information

• release (stable)
• beta
• nightly

Reproducibility

• with Brave Shields disabled
• with Brave Rewards disabled
• in the latest version of Chrome

Miscellaneous information

No response

The issue with your rule is that Brave doesn't have a Procedural :has() or :not().

So in the case of your rule using a :not(:has-text( )) will not work because native :not() and :has() needs to have a native CSS selectors or Pseudo-classes.

So that's the issue, if you remove that and only use the :has-text() without being inside the :not(), then it will work, of course, it will hide the higher viewer count videos, but you can make the regex do the opposite instead of using the KMB to find the smaller count.

So using this or something similar/better to avoid issues should work:

www.youtube.com##ytd-browse[page-subtype="home"] ytd-rich-item-renderer:not(:has(#video-title[aria-label~="views"], .yt-lockup-view-model-wiz--collection-stack-2)) :is(#metadata-line>span:first-of-type, .yt-content-metadata-view-model-wiz__metadata-row):has-text(/[^KMB] (views|watching)/):upward(ytd-rich-item-renderer)

Saying this, Brave Procedurals in many situations fail to apply, you can read about many of those scenarios here: #42873, where websites don't have to be complex to make the Procedural Filtering just stop working, like uBlock test page, which is simple but I think it fails because of the :after or :before stuff it has, so if that was the case.

But this should work in Youtube.

Sometimes the solution about :has-text() (and other Procedurals of course), is try try and use a higher HTML element, rather than using a more specific deeper ones in the tree of elements, so sometimes you can just test to see in what specific element Procedurals stop working and figure something out from there. Let's hope this gets fixed eventually soon though and that it works in Brave like it does in uBlock soon.
But sometimes making simpler rules and less specific will work the same, like with your rule, you go down and then use :upward to go up, but you could have just use www.youtube.com##ytd-browse[page-subtype="home"] ytd-rich-item-renderer: and then the :has-text with whatever you want to find.

Procedural filters are just custom selectors made out of JavaScript, and they are questionable to use in many cases. so they are not too recommended unless you can't use native ones (like in this case), but by being JS, that means you can just build better specific selectors yourself with JavaScript that work better because there is no 'flickering' of elements.

For example when :has-text() fails to work, I inject the JS code through trused-replace-node-text (or rpnt) or custom scriptlets (not too necessary if it is only for a page) and then using something like filter() and a textContent.match() and then regex if necessary and some MutationObserver, I get to have a better ':has-text()' where I can even use .remove()if possible, but in the end unlike Procedurals, you don't see the 'flickering' of elements being hidden or removed which is something that happens if you use the:remove()` action operator, not just Procedurals.

So even if Procedurals fail to work, you can create some custom JS that can do the same job and perform better and removes things before the 'eye can see it', since you don't care if millions of people use your produce and if X or Y pages might suffer for performance issues or it is 'too much' to just do what you can do through native JS or jQuery (because if a page loads jQuery library you can also take advantage of it, by injecting a JS that will run something jQuery specific to make it easier) and then don't depend on buggy Procedurals (like in Brave) or slower Procedurals (like in every adblocker because JS can do the job immediate without having to see the elements being hiding or removed).

But your rule should work for the most part, you just can't use :has-text() inside the :not(), so you will have to get the element you want to find with a specific text rather than getting the element that doesn't have the specific text.

An example of what I mean by Procedurals in Brave don't work sometimes, even if uBlock they suck and custom JS can make better procedurals, so it's more understood and how anyone can forget about Brave state of Procedurals and make your own if necessary.

flashscore.*,flashscoreusa.com##.searchResult:has-text(/[\S\s]*/)

This is a simple Procedural, but doesn't work in Brave. If you go to flashscore or flashscoreusa.com and you make a search, nothing gets hidden.

If you use the same rule in uBlock, the rule will work, but now make a search for any team or sport, and in some seconds you will totally see the elements showing and then hiding again, and everytime you type and something changes, that will be the results in uBlock, Brave (when it works) and Adguard and ABP and all of them.

Now disable that rule and use:

flashscore.*,flashscoreusa.com##+js(rpnt, script, /^/, `addEventListener("load", (event) => { const handleMutations = (mutations) => { for (const mutation of mutations) { for (const node of mutation.addedNodes) { let regex = new RegExp("[\S\s]*"); const elems = document.querySelectorAll(".searchResult"); Array.from(elems).filter(v => v.textContent.match(regex) ? v.style.display = 'none' : v); } } }; const observer = new MutationObserver(handleMutations); observer.observe(document, { childList: true, subtree: true }); });`, includes, window.loggingServiceConfig)

(or use a useful specific regex like RegExp("hockey","i"); and then test it better.)

and you will not see any 'flickering' of elements, they will be hidden to the eye. You should only see how the page is trying to fetch the results but they won't show in any way as they do in uBlock and then get hidden.

Of course in Flashscore, there are ways to hide stuff with native CSS selectors, with alt, using href, or src image, but the point is to show a simple example about how Procedurals are not exactly the best thing in the world and custom JS can be better in some cases if you want to go free and don't depend on Procedurals JS code and how it won't be any faster and actually it will show elements while they are hiding which might be annoying in some cases.

But in this example can even use .remove() instead of .style.display, which means the elements will be removed and not searchable if that's what you want and the page allows).

Because I just saw how using :remove() doesn't work in Brave either in this scenario:

flashscore.*,flashscoreusa.com##.searchResult:has([alt]):remove()

But if you use it in uBlock, you will notice how it you will also see elements showing and hiding as you type, while using the JS above with .remove() will not do the same only show the 'fetching data' animation flashscore uses.

Since Procedurals and Action operators like :remove() are made out of JS and not native, then building your own can work better and do what you want to do.