At least that's my understanding from the following bug :
1. On Firefox 55, install uBlock Origin 1.13.10
2. Install NoScript 5.0.9
3. Forbid @font-face
4. Enable "Apply restrictions to whitelisted sites too"
5. Click on uBO's button and see how the fonts are blocked
6. Browse through uBO's configuration pages and see how the fonts are blocked there too
7. Allow @font-face in NoScript: uBO fonts work again.
8. Forbid @font-face but disable "Apply restrictions to whitelisted sites too": uBO fonts still work.
Reported on uBlock Origin's Github, but this does sound like an issue with NoScript and moz-extension://. When uBO was a legacy add-on, it loaded fonts from chrome://, where apparently NoScript doesn't enforce "Apply restrictions to whitelisted sites too".
"Apply restrictions to whitelisted" affects moz-extension://
"Apply restrictions to whitelisted" affects moz-extension://
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0
Re: "Apply restrictions to whitelisted" affects moz-extensio
I reported it in this NoScript thread too but the thread author says he doesn't have "Apply restrictions to whitelisted sites too" enabled, so it sounds like a different issue.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0
Re: "Apply restrictions to whitelisted" affects moz-extensio
Same experience here. I guess, it is time to stop updating extensions until those kinds of problems are sorted out.
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Re: "Apply restrictions to whitelisted" affects moz-extensio
@alexander.r: Removed the email address. We don't give email support, but this being a public forum there are surely bad bots looking to harvest email addresses for spamming and other nefarious purposes.
How will this help? Does this problem not occur with an older version of NoScript?alexander.r wrote:I guess, it is time to stop updating extensions until those kinds of problems are sorted out.
*Always* check the changelogs BEFORE updating that important software!
-
Re: NoScript brokes Firefox WebExtension background pages
Hello together,
unfortunately I experience comparable problems and also tried some tricks to exclude those. I use Firefox ESR 52.3.0 with uBlock Origin 1.14.4 right now.
If one uses NoScript with really careful, almost paranoid (for standard users, at least) settings (which basically make every site disable JS in every aspect, except if you set it on via hand or by exceptions) and activate the "apply restrictions to whitelisted sites" option (which is a must-have for me), then you will get several blocks from NoScript on WebExtensions like uBlock Origin.
It is pretty easy to prove, as there is exactly one way to go around this: Open the uBlock Origin Configuration site (dashboard basically) and click right on this (webextension) page.
Then you select "NoScript" => "blocked objects" or how ever it is called in english (I use the german language setting => and you see a list of the blocked parts of this page, i.e. the configuration menu page of the WebExtension.
You can then temporarily allow the font and/or the extension and voilá - the font-based icons are back and several functions work again.
Unfortunately there is no way to allow this "site" based in the WebExtension itself permanently, else it could possibly result in a working WebExtension permanently, even after browser restart.
I tried several tricks like adding the WebExtension "URL" in the about:config "capability.policy.maonoscript.sites", which basically works (and adds it as well in the configuration menu of NoScript, even as it wouldn't be removable or add-able there, as the "moz-extension:" is already whitelisted but for some reason doesn't work on WebExtensions as it should), but it doesn't change the problem anyhow.
I also thought about trying it over the "noscript.filterXExceptions" setting, but had no time right now for the right formatting - also I am not sure if this would work.
It is pretty confusing as this problem also appeared with WEBM and mp4 movies, which were blocked multiple times by NoScript on - as example - YouTube. I unblocked them via click one-for-one but because they load several times from several servers and try to load side-videos as marketing stuff it was a pretty long process for around 4-6 clicks each video. I then saw that they could be set as exceptions over the "noscript.allowedMimeRegExp" with a formatting like:
video/webm@https?://[a-z0-9\-]*\.(?:youtube|ytimg|googlevideo|googleusercontent)\.com video/mp4@https?://[a-z0-9\-]*\.(?:youtube|ytimg|googlevideo|googleusercontent)\.com audio/webm@https?://[a-z0-9\-]*\.(?:youtube|ytimg|googlevideo|googleusercontent)\.com video/ogg@https?://[a-z0-9\-]*\.(?:youtube|ytimg|googlevideo|googleusercontent)\.com video/webm@https?://[^/]+\.(?:youtube|ytimg|googleusercontent|googlevideo)\.com video/mp4@https?://[^/]+\.(?:youtube|ytimg|googleusercontent|googlevideo)\.com audio/webm@https?://[^/]+\.(?:youtube|ytimg|googleusercontent|googlevideo)\.com video/ogg@https?://[^/]+\.(?:youtube|ytimg|googleusercontent|googlevideo)\.com
- but this is a) a pretty time consumpting task, b) it still needs two clicks as somehow those exceptions don't cover all types of mime types/urls opened by youtube videos.. and c) it could be around the factor 100 easier and more efficient if - instead of the possibility to allow parts in the "blocked objects" (or however it is called in english language settings..) only temporary.. there would be also a option to allow/exclude them from filtering/blocking permanently. Which adds the clicked object either in a new page of the configuration menu of NoScript itself (good for GUI users / mainstream users to delete set permanent exceptions) or in the about:config settings in the right formatting for it to work.
Without any need to format the strings oneself, like the temporary allowance/exception which works already.. just permanent as a additional option in the menu.
I guess this would help in all cases written in this post, as long as there are no other conflicts (and the temporary allowance would work, either it would not work if set permanently, too - understandable).
Thanks for the good work with NoScript, @Giorgio Maone , but the WebExtensions decision somehow really conflicts with some of the NoScript functions.. some way for power users to have a easy way to set permanent go-arounds for selected pages/WebExtension "pages" would be great.
Best regards
Wolf
unfortunately I experience comparable problems and also tried some tricks to exclude those. I use Firefox ESR 52.3.0 with uBlock Origin 1.14.4 right now.
If one uses NoScript with really careful, almost paranoid (for standard users, at least) settings (which basically make every site disable JS in every aspect, except if you set it on via hand or by exceptions) and activate the "apply restrictions to whitelisted sites" option (which is a must-have for me), then you will get several blocks from NoScript on WebExtensions like uBlock Origin.
It is pretty easy to prove, as there is exactly one way to go around this: Open the uBlock Origin Configuration site (dashboard basically) and click right on this (webextension) page.
Then you select "NoScript" => "blocked objects" or how ever it is called in english (I use the german language setting => and you see a list of the blocked parts of this page, i.e. the configuration menu page of the WebExtension.
You can then temporarily allow the font and/or the extension and voilá - the font-based icons are back and several functions work again.
Unfortunately there is no way to allow this "site" based in the WebExtension itself permanently, else it could possibly result in a working WebExtension permanently, even after browser restart.
I tried several tricks like adding the WebExtension "URL" in the about:config "capability.policy.maonoscript.sites", which basically works (and adds it as well in the configuration menu of NoScript, even as it wouldn't be removable or add-able there, as the "moz-extension:" is already whitelisted but for some reason doesn't work on WebExtensions as it should), but it doesn't change the problem anyhow.
I also thought about trying it over the "noscript.filterXExceptions" setting, but had no time right now for the right formatting - also I am not sure if this would work.
It is pretty confusing as this problem also appeared with WEBM and mp4 movies, which were blocked multiple times by NoScript on - as example - YouTube. I unblocked them via click one-for-one but because they load several times from several servers and try to load side-videos as marketing stuff it was a pretty long process for around 4-6 clicks each video. I then saw that they could be set as exceptions over the "noscript.allowedMimeRegExp" with a formatting like:
video/webm@https?://[a-z0-9\-]*\.(?:youtube|ytimg|googlevideo|googleusercontent)\.com video/mp4@https?://[a-z0-9\-]*\.(?:youtube|ytimg|googlevideo|googleusercontent)\.com audio/webm@https?://[a-z0-9\-]*\.(?:youtube|ytimg|googlevideo|googleusercontent)\.com video/ogg@https?://[a-z0-9\-]*\.(?:youtube|ytimg|googlevideo|googleusercontent)\.com video/webm@https?://[^/]+\.(?:youtube|ytimg|googleusercontent|googlevideo)\.com video/mp4@https?://[^/]+\.(?:youtube|ytimg|googleusercontent|googlevideo)\.com audio/webm@https?://[^/]+\.(?:youtube|ytimg|googleusercontent|googlevideo)\.com video/ogg@https?://[^/]+\.(?:youtube|ytimg|googleusercontent|googlevideo)\.com
- but this is a) a pretty time consumpting task, b) it still needs two clicks as somehow those exceptions don't cover all types of mime types/urls opened by youtube videos.. and c) it could be around the factor 100 easier and more efficient if - instead of the possibility to allow parts in the "blocked objects" (or however it is called in english language settings..) only temporary.. there would be also a option to allow/exclude them from filtering/blocking permanently. Which adds the clicked object either in a new page of the configuration menu of NoScript itself (good for GUI users / mainstream users to delete set permanent exceptions) or in the about:config settings in the right formatting for it to work.
Without any need to format the strings oneself, like the temporary allowance/exception which works already.. just permanent as a additional option in the menu.
I guess this would help in all cases written in this post, as long as there are no other conflicts (and the temporary allowance would work, either it would not work if set permanently, too - understandable).
Thanks for the good work with NoScript, @Giorgio Maone , but the WebExtensions decision somehow really conflicts with some of the NoScript functions.. some way for power users to have a easy way to set permanent go-arounds for selected pages/WebExtension "pages" would be great.
Best regards
Wolf
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Re: NoScript brokes Firefox WebExtension background pages
As an example, I will post three images, to show how this NoScript temporary allowance instantly changes the WebExt behavior back to usual state:
Before the temporary allowance i.e. after each restart:

The settings menu to temporary unblock it with one click:

After temporary allowance it is back to the usual functional look:

Best regards
Wolf
Before the temporary allowance i.e. after each restart:

The settings menu to temporary unblock it with one click:

After temporary allowance it is back to the usual functional look:

Best regards
Wolf
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0