Add $path modifier of Adguard or any equivalents of this

[Yuki2718]

Prerequisites

• I verified that this is not a filter issue (MUST be reported at filter issue tracker)
• This is not a support issue or a question
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue
• The issue is not present after wholly disabling uBlock Origin ("uBO") in the browser
• I checked the documentation to understand that the issue I report is not a normal behavior

I tried to reproduce the issue when...

• uBO is the only extension
• uBO with default lists/settings
• using a new, unmodified browser profile

Description

AdguardTeam/CoreLibs#124 (comment)
The modifier is useful at least on Japanese sites and blog.livedoor.jp is the best example where thousands of different structure of pages share the same domain. This resulted in tons of verbose filters in my personal lists to avoid false positive, otherwise a filter working for a page breaks another page. An actual case reported to me (https://jbbs.shitaraba.net/bbs/read.cgi/internet/25463/1598352715/206) is that blog.livedoor.jp###containerWrap > #container > .blog-title-outer + #content.hfeed made for http://blog.livedoor.jp/sexykpopidol/ breaks http://blog.livedoor.jp/kknao81/. Currently for this very reason I ignore some ad-placeholder on blog.livedoor.jp in AdGuard Japanese, which can fully be resolved if the modifier becomes available.

(Not worth your time but in https://blog.livedoor.com/ranking/ you can pick many blog.livedoor.jp sites with different structure each.)

A specific URL where the issue occurs

blog.livedoor.jp

Steps to Reproduce

NA

Expected behavior

NA

Actual behavior

NA

uBlock Origin version

1.37.2

Browser name and version

Irrelevant

Operating System and version

Irrelevant

[uBlock-user]

We wouldn't need to use $shide to partially disable cosmetic filtering on google shopping pages(uBlockOrigin/uAssets#9642, uBlockOrigin/uAssets#9694) if we could use $path to narrow blocking google product ads to google search engine pages only.

Likewise for bing ?

[gorhill]

An actual case reported to me

This works now without having to further complicate the code base and neither have to wait:

blog.livedoor.jp##link[rel="alternate"][href*="sexykpopidol"]:upward(html) #containerWrap > #container > .blog-title-outer + #content.hfeed

[Yuki2718]

@gorhill I already fixed the issue and the point is not that I can't address them within the current arsenal. I can fix each case, but every time the rules become more complex and verbose.

[Yuki2718]

But okay it seems link[rel="alternate"][href*=...]:upward(html) can always be used in case of blog.livedoor.jp. Since in the current uBO procedural engine will only be triggered if the first matching node exists, it can hardly be a matter. How about another point made by @uBlock-user ?

[gorhill]

I could add a procedural operator like so:

blog.livedoor.jp##:match-path(/sexykpopidol) #containerWrap > #container > .blog-title-outer + #content.hfeed

This way implementation becomes quite trivial without having to further complicate the code base for all cosmetic filters. The disadvantage is that this is a procedural cosmetic filters, but it's opened to optimisation, i.e. a filtering engine could have special treatment for such filter in order to have them injected early along with other plain CSS selector-based filters.

Also an advantage is that we just keep reusing the same now familiar operator-based approach, which was the entire point of these operators, that is easy to extend with little to no impact on codebase complexity.

---

To calrify "code complexity", the suggested [path=...] approach by AdGuard adds quite more complexity to the parsing/storing/lookup of cosmetic filters, while a mere new procedural operator requires no refactoring, procedural operators were designed to naturally be extensible with no added widespread complication.

[uBlock-user]

Would it be possible to have whitelist approach with :match-path ? I would like simply skip a path such as /shop at google/bing.

[gorhill]

If argument to :match-path() can be a regex, than you can just use a negative lookahead?

---

Or even :not(:match-path(...)) ... should work I gather?

[Yuki2718]

Sounds great! The reason AG use [path=...] is that they already use a similar [app=...] but probably they can transform [path=...] to :match-path() just like they do for other filters, so I have no problem.

[uBlock-user]

:not(:match-path(/shop)) would do.

[gorhill]

Trying to come out with a name I won't feel like changing in the future, please advise. Should it be:

• :matches-path(...)
• :match-path(...)
• :path-has-text(...)
• ?

Keep in mind this is the list of supported operators for now: https://github.com/gorhill/uBlock/blob/b44d9219c321cf42379b1b7e8711728321ef0a16/src/js/static-filtering-parser.js#L1818-L1838. Consistency is important.

[uBlock-user]

Third can be changed to :has-path() as :path-has-text() sounds un-necessarilly longer.

[Yuki2718]

Trying to come out with a name I won't feel like changing in the future, please advise. Should it be:

• :matches-path(...)
• :match-path(...)
• :path-has-text(...)
• ?

Consistency is important.

I'm not English-native but it appears match-path is inconsistent with matches-css.

[gorhill]

I am also not English-native, and I wonder whether :matches-css() was the right choice, so I wouldn't want to repeat the same mistake, and if this was a mistake, I can always deprecate :matches-css() and instead make :match-css() official. I often make mistakes with those trailing s in English, so I am not a reference on when to properly use these.

[uBlock-user]

Both are fine, no need to change anything regarding :matches-css()