Open peace2000 opened 3 years ago
Fyi, I have also opened this same issue report on uBO's and on ABP's issue trackers: https://github.com/uBlockOrigin/uBlock-issues/issues/1692 https://gitlab.com/eyeo/adblockplus/abc/adblockpluscore/-/issues/361
@ameshkov FYI now that @gorhill added this functionality to uBO 1.37.3b15+ it would be helpful for testing/filter maintenance purposes to also see this implemented in AdGuard to help eliminate issues such as https://github.com/AdguardTeam/AdguardFilters/issues/91708#issuecomment-902942341 and other issues that would end up only applying for AdGuard users.
Most filters I am coming up with are based on test environment in uBO so would like to have consistency in rules engine so know that I am not creating a possible issue for AdGuard users if I add a generic filter to Web Annoyances Ultralist. For the last couple years I try to stay away from adding generic filters anyway, but would be a nice feature to help other maintainers as well.
Also add this into ag apps for Windows/macOS/Android.
Maybe in iOS if Apple no block by limiting in content block API l.
Problem Description / ### Proposed Solution
There have been numerous occasions where Annoyance lists have blanked out websites because either
html
orbody
have contained values that have been matched by a generic cosmetic filter. This is a pretty common issue for Annoyance lists, though there have been a few occasions in normal adblocking as well.Usually these issues have been fixed by adding
:not(html)
or:not(body)
exception to the problematic generic cosmetic filter.I was wondering if it would be reasonable to add a safeguard measure to Adguard: to prevent it from applying cosmetic filters, that have a match in
html
orbody
in websites where an user is visiting. I think that neitherhtml
orbody
should ever be blocked as that will result in a blank website.One recent sample issue from Fanboy's Annoyance: https://github.com/easylist/easylist/pull/8431 -
https://webshop.elektroskandia.no/
was blanked out becausebody
in that website had a value of.consent-summary-shown
. It was matched by this generic GDPR filter:##.consent-summary-shown
. (It was later fixed by adding an exception:##.consent-summary-shown:not(body)
).But that wasn't the only case. In Fanboy's Annoyance list, there are currently:
260
:not(html)
exceptions 298:not(body)
exceptionsAdguard Annoyance:
127
:not(html)
exceptions 160:not(body)
exceptionsEasylist:
4
:not(html)
exceptions 7:not(body)
exceptionsI know these website blanking issues are mainly related to Annoyance lists that are not turned on by default in Adguard, but they are still available and people use them. Not all issues get reported to filter list maintainers and there could be many unreported issues relating to these lists. Each
:not(html)
or:not(body)
exception that currently exists, are related to fixing blank websites.A sample page to test this issue with:
https://webshop.elektroskandia.no/ (fixed now in Fanboy's Annoyance but this one is a recent case so I'll use it as a sample)
##.consent-summary-shown
Alternatives Considered
Such don't really exist, unless each generic filter would be pre-supplied with
:not(html):not(body)
exception pre-emptively.Additional Information
-