:matches-path can't be used at the beginning of a filter rule

[antonok-edm]

Consider the following procedural filter:

example.com##:matches-path(/a/) :matches-attr(ZZZZZZZ)

This shouldn't hide anything on https://example.com/a/ since nothing has an attribute with ZZZZZZZ in it (furthermore, that's not even valid syntax for the :matches-attr(...) argument). However, in Brave it hides the entire page.

This issue was observed in Brave Desktop 1.80.59 as a result of problems caused by the following real filter:

dzen.ru##:matches-path(/a/) div:matches-attr(/[a-z0-9]/=article-bottom-block) > [class*="social"] ~ div

Also observed on:

• Android 1.79.110
• iOS 1.80.84

[TEMP-sP0psk68CZF8WtUN0gBQLd]

I don't get it, this was reported since December.

The problem was that since every Procedural filter has an issue and are broken in some way, I guess the issue got so long, but in 6 months no fixes, nothing about Procedural Filtering, like if the issue didn't exist. So it seems it was pointless to report anything?

This was the comment where :matches-path was mentioned:

#42873 (comment)

And the issues with :matches-path() is simple: it can't be used at the beginning of the rule, it has to be done last, which is something uBlock allows but doesn't recommend because there can be issues in the way a filter can apply if :matches-path() is not in the beginning. It was also reported here: #43818 long time ago.

So any filter with :matches-path at the beginning will hide the whole page, with no fix, because it will hide every element in the page from the root to the last node.

It will fail if you put it as brave.com##:matches-path(/) asdasdasdasdasd and doesn't matter what you add after the :matches-path, if you open devtools you will see every element gets hidden by the Procedural, every script, meta, link, div, html, body... everything.

Of course, this is not the only issue, there are others like :matches-path(), this is not the only one, the previous comment #42873 (comment) talks about how you can apply the matches-path in a page and it might not work as expected. Using sooplive.co.kr##.side-conts:matches-path(LCK) as an example, if you go to directory (탐색) and then find LCK and click on it, probably it will not work, the filter will only work if you go directly to https://www.sooplive.co.kr/directory/category/LCK/live or hit refresh, and if you go again to Directory or another page, the .side-conts element will not reappear, so we got in some pages the doesn't work/barely works Procedural.

Also I used osu! and LCK as an example because other games are in korean and :matches-path doesn't work if the URL of the page contains anything that is not have latin script, which was tested in sooplive a korean streaming site, so difficult to make it work.

Since this issue also talks about matches-attr, well, it has its set of issues too and some not-parity behavior with the way uBlock works. But then, we have the other Procedurals especially the most important one: :has-text() which is the easier to show how it fails easily in many scenarios like uBlock procedurals testing site (last comment in that issue).

In general, there are issues with regex, with the way it handles things, Brave doesn't even have a :has Procedural and native will reject anything that is not a valid CSS selector or pseudo-class, same case as with :not(), it was obvious that many filters wouldn't work because many filters use a :has(:has) because in some situations it is needed, or :not(:has-text()) and that makes Procedurals useless.
There are issues even when pages have 'too many' Procedurals.

Procedurals fail to work in so many scenarios, it's easy to give examples about how not-so-good they are, and the issues are not limited to Procedurals because :remove() also has issues sometimes a filter like this flashscore.*,flashscoreusa.com##.searchResult:has([alt]):remove() will not work and remove all the elements form the search, why? I don't know, it works in uBlock, and it seems like it is just easier to create a JS script or if a page uses jQuery to replace procedurals, especially because you can make JS work without showing and hiding elements in a page like Procedurals do, they will get immediately hidden. So custom code can be better than the seizure inducing Procedurals (uBlock suffers from 'flickering' too), which is something I mention here #45734 (comment)

How different is to use uBlock vs JS to do the job, in fact I had to use custom JS because in Brave it wasn't even working, uBlock was an example to showcase how Procedurals being so slow at hide-remove elements is just terrible.

It's hard to justify reporting bugs anymore to Brave, what is the point? just another issue in the list? I should have removed that issue and move on, because it's crazy, now somehow the issues with :matches-path are being issues and will be 'fixed' like if nobody ever reported the issues.

Yes, procedurals should have never been released in this state, and should have been properly tested not by the basic page where they were tested but proper scenarios, like realistic rules which now somehow are 'causing issues' but they have always caused the same issues, but Brave ignored the issues reported by users, not only mine.

I am sorry but it is incredible the issue appears after 6 months of report because somehow it is affecting 'some people', because it is probably the more severe bug in Procedurals, the other bugs cause the filters not to work, but not to overwork by hiding the whole page, but you have to truly finally fix the Procedurals and stop focusing in cookie whatever made with AI because Brave Procedurals are like 25% effective right now, and I think that's still too high of a percentage.

[antonok-edm]

@TEMP-sP0psk68CZF8WtUN0gBQLd we will get to it... sadly, we all have limited time on this planet for all the code that still needs to be written (and deleted) 😂

Yes, I'm aware there are still some issues with procedural filtering (primarily from looking at #42873 when it was opened), but it's also much easier for me to prioritize a concise issue report than a nearly-4000-words one. That's just the reality of working on a project of this scale.

Anyways, the best way to guarantee these fixes get made is to submit your own PRs. I can see you have the passion and attention to detail that it takes to get it done if you set your mind to it. Otherwise, my only wish is that you don't stress yourself out over issues that aren't fixed according to your schedule.

I do still appreciate the issue reports regardless.