-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add compatibility with some of ABP's script filters. #1011
Comments
This was discussed internally a long time ago and declined. There is no list used by uBO which make use of this syntax, it's currently only used by ABP's own "Anti-CV" list, which is not to be used in uBO because it would likely break uBO's own anti-blocker solutions. |
Oh shit, I apologize then for opening an issue, somehow missed the comment you reffered, yeah, well, shit happens. |
@gorhill some time ago @DandelionSprout made a request https://gitlab.com/eyeo/adblockplus/adblockpluscore/-/issues/229 for ABP developers that they would add support for uBO's Can you give some comment to them on Gitlab? (You can login to Gitlab via a Github account). I know it's not your pain what ABP does but as a filterlist maintainer I really hope that there were better compatibility between different adblockers. But as I'm not uBO's developer I cannot make exact comments about |
uBO detects at filter compile time whether a filter is to be used natively or transformed into an emulated CSS selector, for instance, this is going to compile into a native CSS selector-based filter:
While this is going to compile into an emulated CSS selector:
Same will apply for I have always been open to support as many sources of filter lists as possible, hence why uBO is compatible with AdGuard syntax where it makes sense, and also with ABP-specific syntax where it makes sense, while ABP has steadfastly ignored the work already established by both AdGuard and uBO to go its own way with their own syntax. I am not going to invest my time arguing with them to be a better blocker and be more compatible with quality filter lists from other sources, they should want this on their own. |
By the way, related to the original issue here (ABP's "snippet filters"), ABP is moving some of its development out of public eye, see https://gitlab.com/eyeo/adblockplus/abp-snippets (ref). That kind of move makes it clear to me they are not interested in sharing, collaborating and being really community-driven -- they will be free to look at uBO/AdGuard work in that field which occurs in full public view, while shielding their own snippet code work behind a private repo. |
The MDN page you pointed at is not fully aligned with what is landing. We actively collaborated with Igalia and they did a huge job to go ahead and propose a This is the reason we raised a concern, whenever current
This is a bit speculative, but it's also not the venue, for me, to provide extra details on that move, or what's next, and it'd be great if we could keep the conversation relevant to what @peace2000 asked, as all we are trying to do, maybe late, but I've personally never been involved in those old decisions, is to simplify the effort for filters' authors, and because we know Thanks in advance for your collaboration. |
I tried the selectors listed in that commit, and found that uBO's
However, it succeeds when removing leading When I look at the use of Except of course for when I can't imagine a scenario where I don't know how @ameshkov feels about this. |
In ABP we are transforming We understand such difference shouldn't be huge, and we probably need to counter parse nested If we decide to go for Thanks. |
In uBO Forcing a filter to be parsed as extended CSS filter when there is a |
That's pretty awesome, because then we can keep our own separation and just consider Thanks for these details, it helped moving forward with our issue. |
Related discussion: - uBlockOrigin/uBlock-issues#1011 (comment)
Regarding |
Which page? I see zero match on the front page.
Unexpected. If you try the following in the dev console:
It works, this means the selector is deemed valid by the browser -- so it does not go through uBO's pseudo cosmetic filtering. However it unexpectedly returns a collection of |
That's wrong, the fix I implemented is supposed to normalize without |
Related issue: - uBlockOrigin/uBlock-issues#1751 Related feedback: - https://www.reddit.com/r/uBlockOrigin/comments/qgd6fe/ It turns out Chromium has started to implement the `:has()` operator, which becomes recognized when the browser flag "Experimental Web Platform features" is enabled. However the hic is that `:has()` is not supported as a declarative CSS style rule and is only supported through `querySelector()` et al. The fix is to no longer detect plain CSS selectors through `querySelector` et al. but rather use an actual stylesheet to validate that a cosmetic filter can be injected into a stylesheet in a declarative way. Additionally, I added support to enforce ABP's semantic regarding cosmetic filter with the `#?#` anchor: when using such anchor, uBO will _first_ try to compile the filter as a procedural one rather than a declarative one. Related discussion: - uBlockOrigin/uBlock-issues#1011 (comment)
Prerequisites
Description
An idea/enhancement to further discuss - what do you think.
uBO currenlty supports / is compatible with some ABP's and AG's script filters for. ex.:
:-abp-has
and:-abp-contains
ABP new filter not working on uBO gorhill/uBlock#2793 (comment):contains()
ABP new filter not working on uBO gorhill/uBlock#2793 (comment)and with some more as well.
Some time ago ABP implemented Snippet filters / Snippet Filters Tutorial .
Some of them - the most common ones, are compatible with uBO, they even wrote that the idea originates from uBlock Origin, for. ex.:
website.com#$#abort-on-property-read property
could be read as/passed towebsite.com##+js(abort-on-property-read.js, property)
website.com#$#abort-on-property-write property
could be read as/passed towebsite.com##+js(abort-on-property-write.js, property)
website.com#$#abort-current-inline-script property string
could be read as/passed towebsite.com##+js(abort-current-inline-script.js, property, string)
website.com#$#uabinject-defuser
could be read as/passed towebsite.com##+js(uabinject-defuser.js)
I know they are limited to Custom Filters and ABP Anti-Circumvention Filter List, but perhaps ABP Anti-Circumvention Filter List could be included and enabled in uBO by default (it's included and enabled by default in ABP as well), what would reduce a bit number of issues reported to uAssets tracker / filters being added to uBO, what would relieve a bit uBO filter creators. Still, issues not covered by ABP Anti-Circumvention Filter List could be fixed in uBO.
Your environment
The text was updated successfully, but these errors were encountered: