µBlock Origin thread

General discussion about web technology.
User avatar
Thrawn
Master Bug Buster
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: µBlock Origin thread

Post by Thrawn »

yes_noscript wrote:can you please add the feature
Feature requests for gorhill's extensions should be raised on Github, not on these forums.

(Incidentally, much as I like SDC, I don't think it makes sense to integrate it with μMatrix or μBlock Origin.)
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

Re: µBlock Origin thread

Post by barbaz »

In fact, gorhill doesn't accept feature requests to uBlock Origin at all - only bug reports.
https://github.com/gorhill/uBlock/blob/ ... you-submit
Thrawn wrote:(Incidentally, much as I like SDC, I don't think it makes sense to integrate it with μMatrix or μBlock Origin.)
I agree about uBlock Origin, but IMO the exact feature mentioned by yes_noscript is not totally out of line with µMatrix, which already has the option to delete non-blocked session cookies after configurable period of dormancy...
*Always* check the changelogs BEFORE updating that important software!
-
yes_noscript

Re: µBlock Origin thread

Post by yes_noscript »

Ah damn. My request for the cookie feature was for uMatrix, not uBlock.
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:3.0) Goanna/20160728 PaleMoon/27.0.0a2
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

Re: µBlock Origin thread

Post by barbaz »

Just to leave this here. I was having trouble downloading images from Postimage, just getting alert boxes like "The download could not be saved because an unknown error occurred". No related error in the console.

Well, after some struggling with this, I discovered that the issue is my uBlock Origin configuration - I don't disable uBlock Origin for behind-the-scene but I do block the .io TLD by default, and apparently hadn't finished whitelisting Postimage's new domain.

Hope this helps someone else, even if only to serve as another example of why gorhill doesn't recommend enabling blocking of behind-the-scene requests. ;)
*Always* check the changelogs BEFORE updating that important software!
-
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

Re: µBlock Origin thread

Post by barbaz »

@gorhill: At what point do generic cosmetic filters kick in? And what does uBlock Origin do when it hits the DOM to determine generic cosmetic filters?

Had a weird issue on a page at mozillaZine where I know some links should have been hidden with my rules, usually they are but but they weren't this one time. I clicked around in logger and inspectors, kept reloading the page too but still the links not hidden. I don't know what got it to start working again.

Something else odd I saw is that, in the logger, a request to the top-level document was labeled of type websocket, and since I block all websockets by default, it was seemingly blocked. Related?
(Wait it's doing that for every top-level document. I thought that behavior of $websocket was only for Blink-based browsers, not Gecko-based browsers. I'm confused Image)

SeaMonkey '2.46pre' (like Firefox 49 rc1)
uBlock Origin 1.9.4
*Always* check the changelogs BEFORE updating that important software!
-
gorhill
Junior Member
Posts: 48
Joined: Sun Mar 30, 2014 12:19 pm

Re: µBlock Origin thread

Post by gorhill »

barbaz wrote:@gorhill: At what point do generic cosmetic filters kick in? And what does uBlock Origin do when it hits the DOM to determine generic cosmetic filters?

Had a weird issue on a page at mozillaZine where I know some links should have been hidden with my rules, usually they are but but they weren't this one time. I clicked around in logger and inspectors, kept reloading the page too but still the links not hidden. I don't know what got it to start working again.
Without specifics, not much I can say. For generic cosmetic filters, uBO survey the page to find all ids/classesm then ask uBO's core to reduce the collection to only known cosmetic filters. If all usual causes are ruled out (cosmetic filtering off, exception filters, uBO disabled, etc.), I would look into browser console to see if there are errors returned. Maybe something unexpected occurred in the content script which caused an exception to be thrown, and hence the whole cosmetic filtering thing was aborted.
barbaz wrote:Something else odd I saw is that, in the logger, a request to the top-level document was labeled of type websocket, and since I block all websockets by default, it was seemingly blocked. Related?
(Wait it's doing that for every top-level document. I thought that behavior of $websocket was only for Blink-based browsers, not Gecko-based browsers. I'm confused Image)

SeaMonkey '2.46pre' (like Firefox 49 rc1)
uBlock Origin 1.9.4
Are you saying this is occurring now all the time or was this just a one time wirdness? Is this occurring with SeaMonkey stable release?
Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

Re: µBlock Origin thread

Post by barbaz »

gorhill wrote:Without specifics, not much I can say. For generic cosmetic filters, uBO survey the page to find all ids/classesm then ask uBO's core to reduce the collection to only known cosmetic filters. If all usual causes are ruled out (cosmetic filtering off, exception filters, uBO disabled, etc.), I would look into browser console to see if there are errors returned. Maybe something unexpected occurred in the content script which caused an exception to be thrown, and hence the whole cosmetic filtering thing was aborted.
I don't have all the specifics I'd like. All I have is the page, don't even have a specific URL anymore but it was this page http://forums.mozillazine.org/viewtopic ... &t=3018323
The Twitter link in pocttopus' signature should be hidden based on its href attribute.
Actually the issue happened again just now as I clicked the link in a preview of this very post (opening the link in a new tab). Nothing obviously related in Browser Console (Ctrl-Shift-J), this is all that even might be

Code: Select all

about:blank : Unable to run script because scripts are blocked internally.    (unknown)
Actually that's has to be it, I reload the mozillaZine page, watch the element not be hidden, and get the message again.

Something possibly of note, I use this rule to mostly turn off cosmetic filtering on *this* forum

Code: Select all

@@||forums.informaction.com^$elemhide
gorhill wrote:Are you saying this is occurring now all the time
This. Still happening on uBlock Origin 1.9.6, which I updated to yesterday.
gorhill wrote:Is this occurring with SeaMonkey stable release?
Yes, with SeaMonkey 2.40 it happens as well.
*Always* check the changelogs BEFORE updating that important software!
-
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

Re: µBlock Origin thread

Post by barbaz »

And now it works again. That console message still appears..

According to uBlock Origin inspector this is the rule that actually hides the link

Code: Select all

##[href^="https://twitter."]
This rule, which would also hide the element, shows up in the logger but not the inspector

Code: Select all

##[href*="twitter.com"]
*Always* check the changelogs BEFORE updating that important software!
-
gorhill
Junior Member
Posts: 48
Joined: Sun Mar 30, 2014 12:19 pm

Re: µBlock Origin thread

Post by gorhill »

barbaz wrote:

Code: Select all

about:blank : Unable to run script because scripts are blocked internally.    (unknown)
I suppose you are using NoScript with uBO? If so, what are NoScript settings for mozillazine.org?
barbaz wrote:Still happening on uBlock Origin 1.9.6, which I updated to yesterday. ... Yes, with SeaMonkey 2.40 it happens as well.
I am trying with SeaMonkey 2.40 + uBO 1.9.6 (no other extension), right now and I do not see any websocket entries in the logger.
Mozilla/5.0 (X11; Linux i686 on x86_64; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

Re: µBlock Origin thread

Post by barbaz »

gorhill wrote:
barbaz wrote:

Code: Select all

about:blank : Unable to run script because scripts are blocked internally.    (unknown)
I suppose you are using NoScript with uBO? If so, what are NoScript settings for mozillazine.org?
Only forums.mozillazine.org is Allowed, everything else there Forbidden.
gorhill wrote:I am trying with SeaMonkey 2.40 + uBO 1.9.6 (no other extension), right now and I do not see any websocket entries in the logger.
Some reckless testing indicates that may not occur unless blocking all websockets by default. Do you see it if you add this filter?

Code: Select all

*$websocket
*Always* check the changelogs BEFORE updating that important software!
-
gorhill
Junior Member
Posts: 48
Joined: Sun Mar 30, 2014 12:19 pm

Re: µBlock Origin thread

Post by gorhill »

barbaz wrote:Some reckless testing indicates that may not occur unless blocking all websockets by default. Do you see it if you add this filter?

Code: Select all

*$websocket
Ok I see. The filter '*$websocket' or equivalent will force uBO to inject a Content Security Policy header to prevent websocket connections to occur. When uBO injects that CSP in the response headers, it reports doing so to the logger. So blocking websocket by default will cause uBO to inject the CSP for all pages, and the logger will report doing so for every page, regardless of the page make use of websocket or not.
Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

Re: µBlock Origin thread

Post by barbaz »

gorhill wrote:Ok I see. The filter '*$websocket' or equivalent will force uBO to inject a Content Security Policy header to prevent websocket connections to occur. When uBO injects that CSP in the response headers, it reports doing so to the logger. So blocking websocket by default will cause uBO to inject the CSP for all pages, and the logger will report doing so for every page, regardless of the page make use of websocket or not.
Ah, that makes sense. Thanks for the explanation Image
*Always* check the changelogs BEFORE updating that important software!
-
yes_noscript

Re: µBlock Origin thread

Post by yes_noscript »

gorhill, today i found that filterlist for uBlock: https://blocklist.kowabit.de/list.txt

Here the german blog news: https://kowabit.de/blockliste-ueberarbeitet/ & https://kowabit.de/special/geblockte-webseiten/

Maybe (if the list is good) the list can be included in uBlock?
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:3.0) Goanna/20160728 PaleMoon/27.0.0a2
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

Re: µBlock Origin thread

Post by barbaz »

yes_noscript wrote:Maybe (if the list is good) the list can be included in uBlock?
Well, if you're not sure whether or not the list is good, do you really want to use it?
If you do, sure, it can be included. Dashboard > 3rd party filters > Custom, paste in the URL and click Parse. Then make sure it's checked and click "Apply changes".
Done, that was easy wasn't it?


BTW, only use that list with uBlock Origin. Some (most?) other blockers aren't smart enough to realise that it's a list of plain hostnames and will thus wildcard both sides of each line. False-positive city there.
*Always* check the changelogs BEFORE updating that important software!
-
barbaz
Senior Member
Posts: 10841
Joined: Sat Aug 03, 2013 5:45 pm

Re: µBlock Origin thread

Post by barbaz »

barbaz wrote:Had a weird issue on a page at mozillaZine where I know some links should have been hidden with my rules, usually they are but but they weren't this one time. I clicked around in logger and inspectors, kept reloading the page too but still the links not hidden.
And it's wacked again. This one appears be elusive and tricky.
I think the trigger could has something to do with browsing for a long time before ever opening the link. In this browser session I mostly go back and forth between here and mozillaZine.

Checked the asset viewer this time and the subscription is apparently there.
Tried toggling cosmetic filtering off/on from the panel, reloading from the panel each time, with no effect.

Also I run the browser in a sandbox (firejail --overlay-tmpfs) which should be a fresh session every time, with cache & cookies etc clear before starting.

Any of that ring any bells / any suggestions where to look next?

(Thanks again gorhill for your help in this, we'd like to get a formal issue filed on this glitch but first need help figuring repeatable STR even in my main profile.)
*Always* check the changelogs BEFORE updating that important software!
-
Locked