InformAction Forums

I'm not sure whether this is an issue with NoScript or Firefox or just an obscure setting:
We use local links like   file:///S:/somepath/somedoc.odt    to documents on our local file server in web pages on our local web server.
These links used to directly open the documents on the file server as desired.
Since yesterday, they download the file to   %USER%\AppData\Local\Temp   and open it write protected from there so they cannot be edited and written back easily anymore.
The funny thing is, we have some Win10 machines which still open it from the server and others which now download to Temp, all current with NS 2.9.5.2 or FF 50.0.1 and I can't see the cause. Linux machines with FF 50 still open from the server.
We do not use NS's setting   Options|Advanced|Allow local links   for this, we do have in prefs.js (thanks to Giorgio) — Any ideas ,someone?  (What does   "noscript.excaps"   do, anyway?)

Thanks, Hans
P.S. I've just noticed: Those downloading machines show the red blocking NS icon although our server1 IS allowed, and the NS icon's menu does not list server1 at all, neither for blocking nor for allowing. The “good” machines correctly show the blue NS icon and do list server1.

This might be connected to viewtopic.php?f=7&t=22355 and viewtopic.php?f=10&t=16994.
On the “bad” machines (downloading) NoScript shows the »blocked« icon and does not list the current local server, but it does allow (!) its scripts. This remains so even after resetting NoScript to its defaults.
On the “good” machines (opening from server) NoScript shows the »allowed« icon and does list the current local server and allows its scripts. This remains so even after resetting NoScript to its defaults (and re-allowing the local server).
After resetting both NoScript's exported settings are nearly identical (but only after sorting!), just differing in closing } in surrogate.imagebam.replacement and surrogate.skimlinks.sources.
Now I'm stumped:  both have the same hardware, the same quite fresh Win10, the same current FF 50.0.2, the same current NS 2.9.5.2. What the heck??
Their prefs.js are quite different though; grepping them for noscript gives no big differences:
the “good” one had an extra user_pref("capability.policy.maonoscript.javascript.enabled", "allAccess"); adding this to the “bad” did not help (what is that about,anyway?);
the “bad” had an extra user_pref("noscript.ABE.migration", 1); deleting this did not help.

What now?

not sure whether this is an issue with NoScript or Firefox

On an affected browser/Profile/machine, disable NoScript & see.

Sorry for the delay, other trouble…
Disabled NoScript:  still downloading to Temp.
Started FF with -safe-mode:  still downloading to Temp.
So this seems not connected to NoScript.  But what then? And why is the local server not listed in NoScript?
Did a fresh clean install of FF with empty profile, just adding those five lines for local links in prefs.js:  still downloading to Temp. I'm stuck.

I'm not sure what the problem is, especially if different machines are giving different results. But it appears to be unrelated to NoScript. For general Firefox debugging, you might find more people who can help you on mozillaZine.

Posted over at http://forums.mozillazine.org/viewtopic ... #p14725328, no enlightenment yet.
Could this be some odd Win10 issue, not even a FF problem?  How does FF decide whether to download first (from a WWW http://… link) or just pass the file:///… link to the respective document editor?

I think now this is not caused by NoScript.  But NoScript, if installed, is affected in some mysterious way, too:  it does not recognize this local http://server1, see screenshot above.  On the “bad” (downloading) machines NoScript shows the »blocked« icon and does not list the current local server1, but it does allow its scripts.  server1 is not seen in NS's whitelist (NS preferences or about:config) and I also cannot add it manually in NS preferences. So, server1 is thoroughly ignored but allowed — huh?