General filter chit-chat

[THEtomaso]

Edit by Dandelion Sprout 25th of February 2020: GitHub spectacularly failed to tell me that there was a comment limit of 2,500 comments in issue threads?! So now it seems that discussion has been forcibly moved to #63 instead.

———————————————————————————————————

This thread is a megathread about adblock discussions in general. Here one can request syntax help, reproduction confirmations, info about differences between adblockers, assistance with making new lists, and so on. They'll be answered or considered by the biggest Adfilt contributors, and occasionally by members of the uBlock Origin development team (although in an unofficial fashion). (This header section was last updated on the 24th of April 2019 by DandelionSprout.)

None of the rules for this thread are obligatorily enforced, but are considered customary as of at the time of the last edit:

• Anything ad-, adblocker-, and adblocking-related of any sort goes.
• Temporary derails are permitted.
• Political discussions are only permitted if they are directly related to something adblock-related.
• Disclosing personal opinions about everyday topics (e.g. family life, non-tech worklife, strong political stances, pizza toppings) is normally discouraged, on the assumption that it could lead to thread participants losing some of their respect for one another.
• When mentioning websites that are (not) affected by adblocking, it is customary to wrap website names and adblocker entries into ` (Grave accents). This will allegedly make it harder for the websites to find this thread in search engines.
• Swearing is normally permitted, but is considered bad form. Swearing as a part of an insultment is even more of a bad form.
• While the following has not been a problem in this thread, they have been sporadic problems among uBO enthusiasts: It is advised to not be hyper-excited when writing comments, whereas reporting thread participants or this repo to GitHub (unless you have a very good reason) is probable grounds for insta-removal from the thread and for the humiliation and pariah-ism of you from the uBlock Origin community.
• If you wish to emote-react to your own comment: Why not use Windows+. to insert the emote into the end of the actual comment instead? It'll save some vertical space as well. (This rule is sleeping for W7 users until 14th of January 2020, and for W8 users until further notice.)

This thread originally started out as a simple report about removing the blurring from the preview of a premium news article, and is still visible below this line:

———————————————————————————————————

Affected site:

https://www.aftenposten.no/

Example:

https://www.aftenposten.no/karriere/Viktoria-16-betaler-n-million-for-en-karrire-som-ender-nar-hun-er-40-12051b.html

Issue:

Cosmetic filtering blocks the "salesposter" for subscription articles.
This results in strangely abrupted page layouts, that gives you the impression that the pages haven't loaded properly, or has some type of error on them.
As annoying as these type of "salesposters" may look, it's better not to block them, to avoid confusion!

Problem filter:

Dandelion Sprouts norske filtre for ryddigere nettsider

Problem rule:

aftenposten.no##.widgets.widget-salesposter

--

• OS/version: Windows 8.1 Pro (x64)
• Browser/version: Pale Moon v27.9.3 (x64)
• Adblock Extension/version: uBlock Origin v1.16.4.2 (XUL)

[DandelionSprout]

At least originally, I felt it was a problem that the sales poster also blurred out the lower lines of the articles previews, and that it would therefore be better for people who didn't intend to subscribe, to remove the blur (which it appears to me that I can't do without also blocking the sales poster).

However, this is a perfectly good issue report and feedback, so I'll look into resolving this issue within the next 15min.

[THEtomaso]

I felt it was a problem that the sales poster also blurred out the lower lines of the articles previews

I think it only blures out the last line partially.
The line is still readable too, so it's not an issue.

Thanks for the quick fix! :)

[DandelionSprout]

For me it seemed to give a slight blur to the last two lines, but that's just pedantics of mine. 😄

Closing the issue now that it has been fixed.

[DandelionSprout]

Update:

After an hour of trial and error, I eventually uncovered that the line blur stemmed from aftenposten.no##.widgets-salesposter:before, with :before being some kind of pre-emptive pseudo-child-element that I've had very little prior experiences with.

Having now accomplished this win-win situation, I'll add the new and vastly improved entry to the list sometime today.

[THEtomaso]

aftenposten.no##.widgets-salesposter:before

Nice catch! :)

[THEtomaso]

Same thing @ digi.no

Example:
https://www.digi.no/artikler/442745/

Fix:
digi.no##.faded-article-content:after

[DandelionSprout]

Splendidly done of you to have researched it enough to have created a fix entry for it. This'll of course be added to the filter list as soon as possible. 💜

[THEtomaso]

Those type of pseudo-element syntaxes works just fine with uBO.
..but after a recent discussion in the Pale Moon forum, I discovered that ABP-based blockers seems to use a different method (see post 7):
https://forum.palemoon.org/viewtopic.php?f=46&t=19682/
Perhaps you're able to make sense of it?

[DandelionSprout]

It doesn't seem to be possible to do it in Adblock Plus at all, from what I can determine.

Adblock Plus' syntax is quite the mess, since I suspect that they're using their goal of encouraging better ads, as a bad excuse to refuse to support new features that originate from other adblockers (e.g. URL wildcards á la google.* in element blocking rules, :has-text, etc.). Coupled with poor documentation (to the point where uBlock Origin GitHub issue threads are more informative about ABP features than ABP's official websites), few examples of such ABP-formatted entries in active use, and that I frankly don't even want to test my lists in Adblock Plus due to its simplified UI, indicates that I think that Adblock Plus is outdated and that I can't recommend its everyday usage in all but the most narrow of cases.

[DandelionSprout]

There is the small theorethical possibility that it's possible to trick :-abp-properties into only detecting :before and :after elements, but I wouldn't place my bets on it. Plus that :-abp-properties isn't even supported in uBO or Nano due to performance concerns (Okay, so advanced adblockers aren't 100% universally covering, either, I must admit), so I can't use Nano's element picker to experiment with it.

[THEtomaso]

Thanks for elaborating.

[THEtomaso]

Fix for dagbladet.no:
dagbladet.no##.CTA-body-faded

Example:
https://www.dagbladet.no/tema/69884034/

[THEtomaso]

Fix for tu.no:
tu.no##.faded-article-content:after

Example:
https://www.tu.no/artikler/440961/

[THEtomaso]

OFF TOPIC:

Are you located in Norway?
I ask because I'm currently trying to solve a strange filter issue, but no one is able to reproduce it.
I've pretty much ruled out UA sniffing and other potentially browser-discriminating schemes at this point, so the most likely explanation seems to be that the problem is location-dependent.

So far, the respective filter authors have refused to include the necessary exceptions in their filters, on the count of them not being able to reproduce the issue from their ends.
If this situation remains, the best solution would probably be to include the exceptions in your filter, which is currently the best known Norwegian filter available.

Let me know if you're interested, and I'll post the links to the GitHub discussions here.

[DandelionSprout]

Indeed I am a Norwegian who lives in Norway, and who'd be up for such a challenge.

[THEtomaso]

Great!

Here are the two reference links:
ryanbr/fanboy-adblock#512
AdguardTeam/AdguardFilters#20596

It's a bit to read up on. :)

[DandelionSprout]

I think I could be seeing the cause of the problem. Are you currently using I Don't Care About Cookies (or anything similar) as one of your filter lists?

[THEtomaso]

No, as you can see from my tests, I made sure to troubleshoot it using ONLY the filters in question!

[DandelionSprout]

Ah, okay.

I can confirm that popsugar.*#@##_evidon_banner works splendidly on my end, but this creates for an interesting situation that I need a few minutes to think on. Don't get too heated up in the meantime, I'm working on it.

[THEtomaso]

So, you can confirm that you get a cookie consent warning that looks like this:

And that any one of these three blocking rules alone is enough to block it?:

##.evidon-banner
###_evidon_banner
/evidon-banner.

[DandelionSprout]

Yes, I can confirm that I get a cookie consent that looks like that, and that the latter two entries (except ##.evidon-banner) blocks it.

The thing I'm currently pondering on, is whether it'd be correct conduct or not of me to use my Norwegian list to cover up for the mistakes of mostly unrelated annoyances lists. I need some consideration time on it, and in the meantime there's nothing that stops you from placing popsugar.*#@##_evidon_banner into your personal entries in uBO, so that it's at least fixed on your end.

[THEtomaso]

Yes, I can confirm that I get a cookie consent that looks like that, and that the latter two entries (except ##.evidon-banner) blocks it.

Are you absolutely sure that you tested this properly, and that this rule isn't whitelisted somewhere in your filters?
Because from my end, ##.evidon-banner completely blocks it!
(Whitelisted cosmetic rules aren't visible in uBO's logger, you know)

The thing I'm currently pondering on, is whether it'd be correct conduct or not of me to use my Norwegian list to cover up for the mistakes of mostly unrelated annoyances lists.

No worries.
Given this new "evidence", I think we'll be able to convice the other filter authors to include the necessary exceptions in their own filters.

in the meantime there's nothing that stops you from placing popsugar.*#@##_evidon_banner into your personal entries in uBO, so that it's at least fixed on your end.

Of course, I've already done that.
But my goal is to prevent others from running into the same problem. :)

[DandelionSprout]

Are you absolutely sure that you tested this properly, and that this rule isn't whitelisted somewhere in your filters?

Okay, my fault, I tested it again with ##.evidon-banner and it blocks it.

I don't think this is a Norway-only problem: Because GDPR is involved in this, I'm thinking that Popsugar may have chosen (poorly) to differ between EU and non-EU visitors, but I'm trying to look for more proof of that they've done that. I've asked my friends about what they're seeing, one lives in an EU country, and one lives in a non-EU-nor-EEC Eastern European country, and I'm awaiting their replies.

[THEtomaso]

Great, the issue have been confirmed then!!
I'll look into convincing the respective filter authors now.. :)

[gwarser]

github.com/notifications/beta

Refined Github extension does not support it for now, and there is no way to open all notifications at once.

Also, it's bit crowdy on mobile.

[liamengland1]

Yeah, I don't like the beta, already switched out of it.

[THEtomaso]

This doesn't work for Chromium either:
deviantart.com##:xpath(//span[contains(text(), 'Comments') or contains(text(), 'Favourites')]/..[@class])

Simply removing the [@class] part at the end fixed it! :)
I think all rules are Chromium-compatible now:
#7 (comment)
(I've also modified one of the other rules, which previously broke parts of the comment fields)

[THEtomaso]

@DandelionSprout:

I just updated uBO to v1.25.0 in Chromium-ungoogled.
Now, there's a problem with the following rule (found in your Nordic filter):
vg.no##+js(acis, Math.floor, g00)
It completely breaks this page!:
https://www.vg.no/sport/i/GGbJ04/
Is it caused by a bug in this particular uBO version?

--

EDIT:
I went back to uBO v1.24.2..
Your rule is applied without causing any issues again!
The converted rule doesn't cause any issues with uBO Legacy either, so I guess there really IS a bug in uBO v1.25.0!
Can someone confirm, before contacting gorhill?

[okiehsch]

It completely breaks this page!:
https://www.vg.no/sport/i/GGbJ04/

Site looks fine on my end with the latest uBO version using Firefox.
I can't test with Chromium at the moment.

[gwarser]

Can be gorhill/uBlock@1a85717

You can check if 1.24.5b3 is working and 1.24.5b4 not.

[DandelionSprout]

No breakage on my end with 1.25.0 in Vivaldi.

[okiehsch]

Site looks fine with 1.24.5b4 using Chrome.

[THEtomaso]

I'll run more tests tomorrow.

[THEtomaso]

I found the problem, and it's a bug in uBO..
I have this rule in my own filter list:
vg.no##+js(abort-current-inline-script.js, Math.floor, g00)
It is the same rule as this one (found in DS's Nordic list):
vg.no##+js(acis, Math.floor, g00)
The only difference is that the rule in my filter list uses the legacy syntax.
When the two rules are used together in uBO v1.25.0, this page fails to load!:
https://www.vg.no/sport/i/GGbJ04/
In uBO v1.24.4, the two rules can be used together, without causing any issues!

--

EDIT:

You can check if 1.24.5b3 is working and 1.24.5b4 not.

Where can I find those builds now?

[gwarser]

• 1.24.5b3 is working (more or less, some blank spaces, problem with video - can be only for me)
• 1.24.5b4 only pink background

So most likely gorhill/uBlock@1a85717 (Harden abort-current-inline-script scriplet)

Two other commits:

• gorhill/uBlock@a806dd4
• gorhill/uBlock@44fe38c

@gorhill

add these two filters:

vg.no##+js(abort-current-inline-script.js, Math.floor, g00)
vg.no##+js(acis, Math.floor, g00)

tested in

Name 	Firefox
Version 	73.0.1
Build ID 	20200217142647

URL

https://www.vg.no/sport/i/GGbJ04/

---

Where can I find those builds now?

Only build for yourself, I'm afraid.

[JustOff]

So most likely gorhill/uBlock@1a85717 (Harden abort-current-inline-script scriplet)

This is definitely the reason (verified by reversing this commit).

[gorhill]

Prior to the commit, uBO would avoid trapping a property which was already trapped, with the assumption uBO itself was the trapper. Then it turns out a site was found trapping the property uBO was intended to trap, thus leading to uBO's trapper not being installed, hence the site was able to defuse uBO's defuser. The commit fixed this, and going back to the previous version would not be good, especially given that the current case is a custom filter interfering, while the case fixed is a site working around uBO.

Possibly I can make the scriptlet a bit more smart to call the trapper's (whoever it is) getter if there is one installed. Is the issue also present in Firefox? The Chromium version is not published yet, so not a big deal, but Firefox has been published today, so I wonder whether this qualify as an emergency fix.

[THEtomaso]

Is the issue also present in Firefox?

Yes.

[ghajini]

Mention @gorhill, otherwise he will not get notified 😃

[liamengland1]

He already commented... 😂

[DandelionSprout]

So I did some research that could change subdomain-specific Facebook list entries forever, which I've published at https://github.com/DandelionSprout/adfilt/blob/master/Wiki/Facebook%20domain%20functionality%20tiers.md.

Besides only some minor details, this means that e.g. m.facebook.com,m.beta.facebook.com,touch.facebook.com,touch.beta.facebook.com,m.facebookcorewwwi.onion##article:has(footer > div > div > a[href^="/friends/center/?fb_ref="]) in uBlock Filters would be changed to b-m.facebook.com,b-m.facebookcorewwwi.onion,iphone.beta.facebook.com,iphone.facebook.com,iphone.facebookcorewwwi.onion,m.beta.facebook.com,m.facebook.com,m.facebookcorewwwi.onion,mobile.facebook.com,mobile.facebookcorewwwi.onion,mtouch.beta.facebook.com,mtouch.facebook.com,mtouch.facebookcorewwwi.onion,touch.beta.facebook.com,touch.beta.facebookcorewwwi.onion,touch.facebook.com,touch.facebookcorewwwi.onion,x.beta.facebook.com,x.facebook.com,x.facebookcorewwwi.onion##article:has(footer > div > div > a[href^="/friends/center/?fb_ref="]).

Similar mass expansions would occur for any entries out there that are currently specific to www.facebook.com (with the "www." in front) or mbasic.facebook.com.

[liamengland1]

Is something flying over my head here? Why does every subdomain need to be listed and not just facebook.com?

[DandelionSprout]

Some entries in major lists are specific to the phone versions of Facebook (Usually Tier 2), and I presume they're specific to them for whatever reason they may have for it.

[THEtomaso]

Speaking of Facebook..
I wonder why none of the social media filters simply use a rule like this:
~facebook.com##a[href*="facebook.com"]
It would efficiently kill most of the remaining Facebook buttons/links, which currently infects the whole web!
The same can be done for other social media services, like Instagram, LinkedIn, Twitter, etc..

[liamengland1]

Some entries in major lists are specific to the phone versions of Facebook (Usually Tier 2), and I presume they're specific to them for whatever reason they may have for it.

why not something like ~www.facebook.com,facebook.com## ?

[DandelionSprout]

(To THEtomaso) Such an entry would've needed some deeper modifications to avoid removing text links in text article paragraphs, unfortunately.

(To llacb47) Early on in the research, I too felt that would've been a good option, but that was before I remembered about the existence of the locale-tag subdomains for www.facebook.com, e.g. nb-no.facebook.com.

[THEtomaso]

Such an entry would've needed some deeper modifications to avoid removing text links in text article paragraphs

I think for most people that are using social media filters, the removal of such links would be preferable.
But I guess it's debatable, and would probably result in heated discussions.

[liamengland1]

I can leave a comment here for some reason, you might want to lock this.

NEW General filter chit-chat: #63

[DandelionSprout]

It appears that ~32 comments have been deleted from this thread's total amount in the past month...?!

Seems like a good a time as any to try to figure out how to lock this thread. Give me a minute or so.