InformAction Forums

Passerby_number_721 wrote:It is probably related to the feature Apply restrictions to whitelisted sites too.

Try with the latest version of uBlock Origin, which is a full WebExt embedded in a thin legacy wrapper. If you have @font-face forbidden and you apply restrictions to whitelisted sites, both uBO's UI and internal pages can't use @font-face anymore.

Was that directed at me? If so, I didn't mention uBO at all, actually. I already ruled out extension conflicts by using a profile with no extensions, as mentioned above. EDIT: To be extremely clear, no extensions except NoScript and a handful of lightweight WX extensions, not including uBO, so I had something to test NoScript breakage of WX extensions...

Also, no, I do not use "apply restrictions to whitelisted sites". If I did, it would make most of the Internet unusable for me.

Giorgio Maone wrote:

aloishammer wrote:I'd like to think that I've covered most of the basic troubleshooting steps.

Unfortunately, I'm fairly sure you did not

The basic steps, which I've just covered, are the following:

1. Start latest stable Firefox with a clean profile
2. Install latest stable NoScript and restart Firefox
3. Install a WebExtension (I installed Stylus, since you've mentioned it)
4. Check wether Stylus work. BTW, it did work immediately for me, with no need to change any NoScript setting because moz-extension: has been in the "privileged" whitelist of browser built-in for several months now (you'll notice it's grayed out in the whitelist tab, you couldn't forbid it even if you wanted).

Therefore I suspect either a configuration-specific issue, or an extensions conflict.
To troubleshoot the former, please follow these step:

1. In your "normal" profile, use NoScript Options>Export
2. In your clean profile we've just created, with NoScript & Stylus only, use NoScript Options>Import on the previously exported file
3. Now check whether Stylus still works. If it doesn't, please send me the aforementioned file for analysis.

If, on the contrary, Stylus still works with your specific NoScript options in a clean profile, it's very likely an extensions conflict: try Standard Diagnostic to find the culprit.
If after all the above you're still at lost, as a last resort please send me your whole prefs.js file.

Have you had a chance to examine or test the hardening preferences I linked? TIA

Was that directed at me?
Also, no, I do not use "apply restrictions to whitelisted sites".

Hi,

Sorry it wasn't directed at you but at the NoScript crew. I thought I was giving information on the bug you are having but it seems that I was wrong since you don't have "apply restrictions to whitelisted sites too" enabled.

(uBO has just become an a WebExtension, hence the bug I report which I put in another thread now, since it's a different one)

Passerby_number_721 wrote:

Was that directed at me?
Also, no, I do not use "apply restrictions to whitelisted sites".

Hi,

Sorry it wasn't directed at you but at the NoScript crew. I thought I was giving information on the bug you are having but it seems that I was wrong since you don't have "apply restrictions to whitelisted sites too" enabled.

(uBO has just become an a WebExtension, hence the bug I report which I put in another thread now, since it's a different one)

uBO has multiple editions, of which I don't have the WebExtension installed.

See: https://github.com/gorhill/uBlock/releases

Update: I've been allowing NoScript to auto-update on the development build only, and I'm still on the beta update channel. I've seen no improvements and no changes.

Firefox is on track to release in just a few weeks with every extension broken either by Mozilla (intentional) or NoScript (apparently unintentional). I realize that this isn't Giorgio's experience, but it is my experience, and it's happening on every machine I have access to.

If you check my posting history in this forum, going back some years, you'll see that I've performed all the troubleshooting requested of me and helped find a genuine bug or two in NoScript. If it matters, I'm a repeat Mozilla donator, and I really want to see Firefox and NoScript succeed. Since Firefox' next-gen browser engine looks to be a year to two years off, and I'm only running Firefox for the extensions I can't get in Chrome—and Firefox E10S is still much slower for me than non-E10S, on every machine I have access to—all I can really do is move to Chromium if there are no forthcoming fixes. It will be much less secure than Firefox + NoScript, but at least it will work, and it will be hugely faster. I guess I'll run Chromium inside VMs where I can.

I hope anyone reading this post takes it as meant: I'm not trying to provoke or annoy, and I'm sure you're all busy chasing down other bugs that might prevent NoScript from working when the hard cut-over to Firefox 57 happens. Since I've met a lot of other NoScript + Firefox users in other forums who are trying to figure out why their WebExtensions aren't working, though, I really think it's a mistake to ignore this problem.

You sure it's a NoScript problem? I was able to reproduce it with multiprocess disabled and the user.js you linked, even after disabling NoScript. I was testing with only NoScript latest development build and Stylus, starting from a clean profile.

Well, I reproduced it once. Can't seem to reproduce the problem again, either with or without NoScript.

barbaz wrote:You sure it's a NoScript problem? I was able to reproduce it with multiprocess disabled and the user.js you linked, even after disabling NoScript. I was testing with only NoScript latest development build and Stylus, starting from a clean profile.

Well, I reproduced it once. Can't seem to reproduce the problem again, either with or without NoScript.

I can't be absolutely certain, since I haven't had a chance to clean up a prefs.js and post it. That's probably good for another 100-200 oddball changes, at a guess. Also, like I said, I didn't adopt exactly the changes in the linked user.js. I found some of them to be wildly paranoid and/or counterproductive (like disabling OneCRL), and a few broke functionality I needed or displayed a depressingly limited understanding of what was being disabled or changed.

... Also, I don't know if you looked closely, but there are more than a few commented-out, recommended changes with multiple possible values. Ex: security.pki.sha1_enforcement_level. I applied more than a few of the commented changes; slapping an unmodified copy of Ghacks' user.js in a profile directory doesn't exactly reflect my actual prefs.js.

That does eliminate quite a lot of possible settings, though. Thanks for testing it out.

barbaz wrote:You sure it's a NoScript problem? I was able to reproduce it with multiprocess disabled and the user.js you linked, even after disabling NoScript. I was testing with only NoScript latest development build and Stylus, starting from a clean profile.

Well, I reproduced it once. Can't seem to reproduce the problem again, either with or without NoScript.

Okay, here it is.

https://pastebin.com/HV1wc00J

Note that there's a lot of cruft from unused / uninstalled / disabled extensions; some reaching several years back. Try not to read too much into extensions.* unless it's an internal Firefox variable. Also, print.* has been deleted for length. In terms of contents, there are about six to eight defined local printers (I think), including some print-to-PDF nonsense.

If anyone needs about:support, I'll have to sanitize that as well.

I still don't reproduce it again even with your prefs.js. I have no idea what would have been different the first time I tested this.

Unfortunately for debugging, I did all testing in a sandbox that gets dumped on quit, and I quit Firefox as soon as I had reproduced the bug with NoScript disabled in order to see if I could reproduce it without NoScript at all. I wasn't expecting to get inconsistent results.

I think what we can conclude from this is that:
A) this is not a Windows-specific issue (I use Linux),
B) this is not directly caused by a pref.

Honestly I'm not sure what to suggest here.

I hope I'm being helpful here and not just confusing the issue.

barbaz wrote:I still don't reproduce it again even with your prefs.js. I have no idea what would have been different the first time I tested this.

Unfortunately for debugging, I did all testing in a sandbox that gets dumped on quit, and I quit Firefox as soon as I had reproduced the bug with NoScript disabled in order to see if I could reproduce it without NoScript at all. I wasn't expecting to get inconsistent results.

I think what we can conclude from this is that:
A) this is not a Windows-specific issue (I use Linux),
B) this is not directly caused by a pref.

Honestly I'm not sure what to suggest here.

I hope I'm being helpful here and not just confusing the issue.

I can add that I'm using both Linux and Windows systems with approximately the same profile (forked a couple years ago).

Maybe it's a prefs-and-extensions issue? I'm not sure, either.

Other than NoScript and Stylus, the only other extensions involved in my case would be whatever "system addons" are bundled with Firefox (56.0b8 EME-free).

Here is an easy way to reproduce this issue:

1. Install Tor Browser (currently 7.0.4/FF52.3.0)
2. Update both NoScript and HTTPS Everywhere to the latest versions
3. Restart Tor Browser
4. Disable scripts globally with NoScript
5. And you're done - now you can't access the settings of HTTPS Everywrehe (as well as any other WebExtension) until you disable NoScript again.

This happens even if the "Apply restrictions to whitelisted sites" setting is turned off.

Okay, here's a fairly major clue: I enabled E10S—which took a hell of a lot of convincing on my part—and now I can use Stylus.

HOWEVER, NoScript is still claiming that 'moz-extension://49e58b54-bb47-4d94-bd58-455eff41359c/manage.html' is untrusted... except that sometimes it's marked untrusted, and sometimes it isn't. There's no chrome to trust it; I assume because moz-extension: is already whitelisted. I have to assume either that's NoScript's fault or Firefox'; not mine. The Stylus options page appears to work either way; I was finally able to import my old styles from Stylish—or so it appears—more testing warranted.

Happily, E10S isn't... yet... producing the massive, unwarranted lag I've seen in the past, so I'm leaving it on for now. I'm going to work my way to other machines and see what the result of enabling E10S is. Frankly, Stylish was my one previously unmentioned dealbreaker; I assume at least some of y'all are familiar with how both the extension and userstyles.org were sold on, and the newer releases of Stylish have embedded spyware with (at last report) no opt-out. I was using the last 'public' release.

Initially, toggling browser.tabs.remote.autostart;true resulted in Firefox reporting that E10S was disabled 'by accessibility'. I'm listing the total number of switches I had to toggle, in case that's useful:

Wolf, your posts are now here: https://forums.informaction.com/viewtop ... =7&t=23235

As already noted, the "Apply these restrictions to whitelisted sites too" issue is different from the issue discussed in this thread.

Please check latest development build 5.0.10rc3, thanks.