Some issues with Adblock Procedural Filters / Feedback #42873
Comments
ghost
added
OS/Android
|
Also, another feedback is that, there has to be a Procedural :has() and :not(). For example if you go to cgpress.org and use this filter it will not work in Brave Adblocker becasue the 'invalid' selectors will not work with the native :has(). A :has(:has()) will not work, that's why the filters I gave have the What uBlock does is that it uses the native pseudo :has() when it is a simple :has() with no invalid selectors inside, and it will use the Procedural one when it reads it has other Procedurals. Of course that rule in cgpress is not necessary, but it is to show what you can find in uBlock ruleset, like I quickly opened the uBlock lists and found this one:
as you can see the with I didn't find many rules with procedural :not() like that only this one:
But it has more than just a simple :not() with a :has-text inside. But overall the feedback is how different in terms of blocking somethin is to say |
|
Another feedback is since the introduction of Procedural Filters, Quora is impossible to browse, it loads and then becomes too slow to even scrolldown. It has to do with the xpath rules, even if they are not in use, scrolling down became impossible and then the page will freeze, and if you disable most xpath, the page will work better but eventually it will freeze, so disabling all xpath rules https://github.com/uBlockOrigin/uAssets/blob/4a1d7a78fcb109c6c0525d0a72494af5422314f9/filters/filters.txt#L700-L702 and https://github.com/uBlockOrigin/uAssets/blob/4a1d7a78fcb109c6c0525d0a72494af5422314f9/filters/filters.txt#L705-L706 fix the issue and quora is responsive again without any issues. Easy to test, go to and try to scroll down. So it is an issue when the page seems to load things even if rules will not match anything. |
ghost
changed the title
|
I also compared the Procedural filters that are supported in Brave against the ones in uBlock to see if something is not compatible and noticed regex support is missing from:
|
|
Also, I was testing :has-text(), I found an inconsistency in the way Brave does the if you add It will work in Brave, but not in uBlock In uBlock it needs to be
While it seems Brave is doing the correct thing by seeing any transformation, and taking into account because it is what the user would see, instead of opening the devtools and see 'why the text doesn't work', it seems like uBlock, ABP and Adguard do the same, they just see the text's node case and not the final rendered one in the page, so the consortium is that Brave is 'wrong' I guess the difference by using the rendered text vs the one in the node is that and example like this: https://codepen.io/kitasenjudesign/pen/zYgZgRm with a rule like this, will not work as expected like uBlock does. in Codepen, you can do any code and just Reload Frame to test the adblocker, so if you Reload Frame, you will see In uBlock that wouldn't happen because it will always be Or for example this: https://codepen.io/FritzAPI/pen/aJvaWq or Look how different Brave and uBlock does it, uBlock will almost hide everything (This is) but that's good, because elements might have different CSSproperties affecting it, but it is easy to see why Brave way of doing things makes more sense, because it is only hiding what truly matches what the user can see, although when you select and copy the text might be Also, I noticed Brave supports So for example, this doesn't work in Brave. Of course, I only few like 5 facebook rules with it https://github.com/uBlockOrigin/uAssets/blob/9b0ec459aa526e2a0db120af5a6a082b973e0ae3/filters/filters-mobile.txt#L47-L51 which have the |
|
seems like But also, there are some issues, especially in heavy dynamic JS websites, where you have to refresh the page for thing to display correctly. Example 1or This will not work correctly because if you go from This one in Twitch displays the issue even better. Go to For instance: This one in Cgchannel works correctly correctly. You go to cgchannel's main page, then to Example 2Also the filter is not working fine, like... it will work depending on the page and the selector it has or how deep the element is in the DOM? I guess depends on complexity where Brave has trouble doing what uBlock does. For example, this will not work: But this will work: Example 3The rule is invalid if you use Korean: It works fine if you use one of the few non-korean games: Saying this, uBlock has no issues about this, also it seems using matches-path will hang the page and cause more issues. Procedural Filtering needs proper testing in many websites, not just simple ones, while they work for the most part, seems like they are not working correctly unless the page is refreshed. While they seem okay for the most part, I am the ones who test them in various websites from heavy to light and compare it to uBlock and it Procedural Filtering needs to be good in Brave like it is in uBlock, where it feels like it doesn't add anything to the page and just works. |
|
Ok, seems like Of course, it should work either way, because you are allowed, just to avoid issues the beginning is better.
So this works: And this doesn't work I guess now it makes sense why it would hide the whole page and everything, if it is pretty much doing it on the html tag! my mistake I guess 👍 |
|
Another issue I found testing the is that in the example: https://codepen.io/FritzAPI/pen/aJvaWq doesn't work in Brave, but works fine in uBlock. This is the reason I had to use This works fine: because action operators or procedural filters are not like normal CSS selectors and there can only be one affecting comma list selector, so something like Of course in Brave the whole rule is rendered useless and not even using the guess is another thing to be tested. I just tested the same scenario and yes.
So another missbehavior. |
|
Opps, I forgot to mention this about This is allowed in uBlock: But in Brave you have to specify the class, reason why I used regex Also, Brave Adblocker doesn't work in https://cdpn.io/FritzAPI/fullpage/aJvaWq which loads the content in the so not even using I tried to make it work, but it seems the only way to make it work is to opening devtools, Edit as HTML the srcdoc attribute with something, like adding a space and once you click out, the cosmetic or procedural will get applied, but it seems to be a probelm with brave with srcdoc attribute, because I also tested https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_iframe_srcdoc, and same issue, oh well, it's pretty rare. To test the performance, I had to modify codepen example a little change, like adding a dot to the HTML and then Testing Brave 795ms - 321ms - 314ms - 395ms - 312ms uBlock 373ms - after any subsequent reload the Procedural filter is already applied, like if it got cached, while on Brave it always gets applied on every reload by the few milliseconds, sometimes hardly seen by the eye. So there is a difference in there too but I guess nothing interestesting, in more complex pages the difference get more minimal since you can see the procedural being applied and in some cases faster in Brave. |
|
Seems like I will have to stop testing Procedurals, because everytime I test something, I find some little tiny missbehavior. It has to do with Besides the value not being optional in Brave where it is optional in both uBlock and Adguard, as I described in one of my comments. Now the issue is that the value as a string doesn't match the exact value, it will match it and anything beyond around or not around quotes. So a rule liks this: is matching The only way to workaround this is to use regex, as This same thing happens with the attr though (less of an issue though), in the case of that rule, it will also match anything class+, for example: So regex should be use it to match non-exact values and attributes, not the other way around, which is wrong compared to what uBlock and Adguard does. Although Adguard even supports wildcard in the attr and value as shown by their documentation https://adguard.com/kb/general/ad-filtering/create-own-filters/#extended-css-matches-attr, something not even uBlock does, which should achive the same Brave is doing without regex, but since uBlock doesn't support it, I guess no uBlock rule has it, but still something Brave might consider to support because Adguard does it, and uBlock says "The supported syntax is exactly as per AdGuard's documentation", so they might do it someday in the future as well. |
|
Another test where Brave fails to do what Procedural Filtering, what uBlock does without any issue.
|
|
I was making some tests for brave/adblock-rust#415 (comment) I found couple issues, with regex now parsing But the biggest issue is that adding too many rules will break the rules, they are not parsed anymore in some cases or it becomes random when they are going to parse or not. I got a nice test where I added these rules and went to https://abptestpages.org/en/filters/remove where all rules are compatible or https://abptestpages.org/en/filters/remove-extended where most are compatible, it would just be be random if the rules would be applied or not on refresh. If you use a small set of rules they will work, but it seems Procedural Filtering and Action Operators just break like that when too many rules are applied to a page. ! <------------------- Remove ------------------->
! https://abptestpages.org/en/filters/remove
abptestpages.org###remove-id:remove()
abptestpages.org##div[id='{{remove-id}}']:remove()
abptestpages.org##.remove-class:remove()
abptestpages.org##.testcase-area > .remove-descendant:remove()
abptestpages.org##.testcase-examplecontent + .remove-sibling:remove()
abptestpages.org##div[height="40"][width="40"]:remove()
abptestpages.org##div[href="http://testcase-attribute-remove.com/"]:remove()
abptestpages.org##div[style="width: 42px;"]:remove()
abptestpages.org##div[href^="http://testcase-startswith-remove.com/"]:remove()
abptestpages.org##div[style^="width: 43px;"]:remove()
abptestpages.org##div[style$="width: 44px;"]:remove()
abptestpages.org##div[style*="width: 45px;"]:remove()
! https://abptestpages.org/en/filters/remove-extended
abptestpages.org#?#div:matches-css(width: 46px):remove()
abptestpages.org#?#div:matches-css(width: 46px):remove()
abptestpages.org#?#div:-abp-has(>div>span.remove-abp-has):remove()
abptestpages.org#?#div:has(>div>span.remove-has):remove()
abptestpages.org#?#span:-abp-contains(remove-contains-target):remove()
abptestpages.org#?#span:has-text(remove-has-text):remove()
abptestpages.org#?#div:-abp-has(> div:matches-css(width: 47px)):remove()
abptestpages.org#?#div:matches-css(WiDtH: 48px):remove()
abptestpages.org#?#.remove-wildcard:matches-css(cursor:*):remove()
abptestpages.org#?#div:matches-css(/width: 13[1-5]px;/):remove()
abptestpages.org#?#div > div:-abp-contains(/remove-containsregex/):remove()
Recording.mp4 |
|
https://gorhill.github.io/uBlock/tests/procedural-cosmetic-filters.html gorhill.github.io#?##pcf #a7 .fail:has-text(needle)
gorhill.github.io#?##pcf #a8 .fail:has-text(/NEEDLE/i)Don't work for whatever reason, even in simple pages, the Procedurals fail to work. Probably So this does something: gorhill.github.io#?##pcf #a7:has-text(needle)
gorhill.github.io#?##pcf #a8:has-text(/NEEDLE/i)
gorhill.github.io#?##pcf:min-text-length(300)the The others So a simpler example, where Procedurals like |
Description
I have been testing the Procedural Filters in Brave for a while, while I stick to native CSS selectors unless
has-textorupwardis the only way to accomplish what I want to hide, I have notice some issues with them compared to uBlock in terms of being applied to some specific cases with heavy dynamic JS in place.First issue
For example, in some extreme case like Twitch chat, the structure of the html tree will look like this:
Each message will be the
<div class="Layout-sc-1xcs6mc-0">.If I use a filter like this it will work fine:
But if I use this one it will not work
My theory is that the procedural filtering will be applied because the
<div class="Layout-sc-1xcs6mc-0">element is being created, and makes it easier for the engine to work, and not using like something inside that element.using
.Layout-sc-1xcs6mc-0:has-text(/(FIRST|SECOND)/)is not possible for Twitch because many elements have that class, which means it will hide the whole thing.And using works fine too.
but using anything below
.Layout-sc-1xcs6mc-0in the will not work, only using that element will work great.With uBlock you can use any element and it will work. like using
.chat-line__message:has(.text-fragment):has-text(/(FIRST|SECOND)/)As you can imagine uBlock doesn't have these issues.
Second issue:
This might be connected to the first one and how the DOM is read when elements are created with JS and all that.
But I noticed a similar issue by using
:upward()which probably would have worked better depending on the 'final' selected element to hide, but it was to hide Channels based on their tags, I just use normal:has()for that, I just wanted to try it, but I remember the :upward worked in the main Top Channels directory, but then it didn't work for when I went to an individual game to see the live channels.So using this will not work
But also the issue would be present if you use this:
My theory in this case is that it has to do with the channels and how they get updated with the JS, so if you go to a game that doesn't have many channels, the tags will not get hidden because the DOM will not get updated with new channels, like it only starts kicking in when the DOM gets updated and fetching other channels when you scroll down or when enough channels get hidden that the channels page just fetch more channels by itself.
So Top Channels having thousands of channels will work fine, but not a game with only 12 live channels or less it will not hide the tags, unless there were more channels and then the DOM gets updated after a while. (hope it makes sense)
I mean, it is pretty situational but as you can imagine, there is no issues like this in uBlock, it always hide things without any issue on any selected node, the problem is while I am using the extreme case of a heavy JS website like twitch, many websites should have similar issues if their DOM has many things around.
Steps to reproduce
Use
twitch.tv##.chat-line__message:has-text(ANY WORD)Go to any Twitch channel, better a big one with tons of spam to have a lot to test from.
No text gets hidden
use
twitch.tv##.tw-tower > div:has(.tw-tag):has-text(English)ortwitch.tv##.tw-tag[data-a-target="English"]:upward(.tw-tower > div)Go to https://www.twitch.tv/directory/all
it works
go to any game with few live channels and nothing will get hidden
Actual result
Procedural Filtering is failing in some circumstances
Expected result
Elements should hide like uBlock does.
Reproduces how often
Easily reproduced
Desktop Brave version (brave://version info)
1.75.93 Chromium: 132.0.6834.46 (Official Build) nightly (64-bit)
Windows 11 Version 24H2 (Build 26100.2605)
Android device
Channel information
Reproducibility
Miscellaneous information
No response
The text was updated successfully, but these errors were encountered: