Description:
For some reason uBO has a problem with this filter:
https://zerodot1.github.io/CoinBlockerLists/list_browser_UBO.txt
After having applied it to uBO's list of custom filters, everything seems to work fine at first.
..but after having used it for some time, it suddenly can't be updated anymore (see screenshot below).
This has happened to me three times now.
When it comes to fixing the issue, simply removing and re-adding the filter doesn't work.
The only method I've found that works, has been to delete ublock0.sqlite, and then reconfigure/re-add everything.
Screenshot:

Reference:
https://github.com/gorhill/uBlock/issues/3600
--
Before opening the issue: did you use the logger as asked?
LOL!
I actually had no idea that uBO's logger would display anything from the filter updating process.
Thanks for the info, gorhill.. that solved it!! :)
The update process gets blocked by the 'NoCoin Filter List' filter, because of this rule:
||github.io^$third-party,xmlhttprequest,domain=~github.com|~tumblr.com
I'll report it to the filter's author.
Don't report it to the filter list author -- it's not his fault. I just wanted it to be investigated on your side.
The issue is caused by the change in 1.15.20, in which I removed the behind-the-scene whitelist directive. You may put it back if you want. A real fix would be to find out whether the Firefox/legacy framework can provide the equivalent of Firefox/webext's documentUrl in the HTTP observer. I suspect it's possible, however not sure I will have time to work on this.
Actually, the change was not applied to Firefox/legacy, so this means you had removed the behind-the-scene directive yourself from the Whitelist pane. In any case, if someone wants to bring the same logic to Firefox/legacy as that of Firefox/webext, i.e. the documentUrl thing, that would help prevent such false positives.
Actually, I just performed a clean install of uBO 1.15.24 (XUL), and the behind-the-scene whitelist directive IS missing by default!
But how come that the rule in 'NoCoin Filter List' doesn't prevent uBO from updating that other filter ALWAYS?
At the moment, I can update just fine.
Only after a few days does the issue take hold again.
Very strange.
I just performed a clean install of uBO 1.15.24 (XUL), and the behind-the-scene whitelist directive IS missing by default!
As detailed in the Release notes of 1.15.20, you have to add the behind-the-scene directive manually for a new installation.
I didn't have behind-the-scene whitelisted even before 1.15.20 but they didn't get blocked unless $domain=behind-the-scene was used, so what changed ?
Edit - behind-the-scene * * allow and ||github.io^$third-party,xmlhttprequest,domain=~github.com|~tumblr.com|~behind-the-scene didn't have any effect, have to add ||github.io^$third-party,xmlhttprequest,domain=~github.com|~tumblr.com,badfilter to be able to bypass the blocking filter.
As detailed in the Release notes of 1.15.20, you have to add the behind-the-scene directive manually for a new installation.
Obviously.
But you just said that the change was not applied to Firefox/legacy, and therefore I must have removed the directive myself.
I'm simply pointing out the fact that the directive has been removed from uBO lagacy too.
Anyway, this still doesn't explain why I'm able to update the CoinBlockerLists for several days each time, before it suddenly becomes a problem.
It's becoming difficult to make sense of comments when focus is being lost. Here is the precise issue:
behind-the-scene scope is not whitelisted by default||github.io^$third-party,xmlhttprequest,domain=~github.com|~tumblr.com, blocks a behind-the-scene network request which URL is https://zerodot1.github.io/CoinBlockerLists/list_browser_UBO.txtThe last question:
But how come that the rule in 'NoCoin Filter List' doesn't prevent uBO from updating that other filter ALWAYS?
I don't know, you could investigate this. Speculating: the resource is fetched from the browser cache, thus bypassing uBO's HTTP observer.
Whatever I said above does not apply to the webext version of uBO, so no point bringing webext behavior here.
if someone wants to bring the same logic to Firefox/legacy as that of Firefox/webext, i.e. the documentUrl thing, that would help prevent such false positives.
Just a thought; but wouldn't it be much easier to simply add the behind-the-scene whitelist directive back to the XUL version of uBO by default?
Most helpful comment
Just a thought; but wouldn't it be much easier to simply add the
behind-the-scenewhitelist directive back to the XUL version of uBO by default?