Local links suddenly download to temporary folder

[Hanspl]

In our small company we use web pages on our local web server with local links like   file:///S:/somepath/somedoc.odt    to documents on our local file server . These links used to directly open the documents on the file server as desired.
For this, we do have in prefs.js (thanks to Giorgio from NoScript; we use NoScript) —

Code: Select all

user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");
user_pref("capability.policy.localfilelinks.sites", "192.168.0.11 server1");
user_pref("capability.policy.policynames", "maonoscript localfilelinks");
user_pref("noscript.policynames", "localfilelinks");
user_pref("noscript.excaps", "false"); 

Since about two weeks, some machines suddenly download the files 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 then FF 50.0.1, now FF 50.1, and I can't see the cause.  Our Linux machines still open from the server.  I tried to compare the prefs.js but didn't find anything obvious.
(On the “bad” (downloading) machines NoScript shows the »blocked« icon and does not list the current local server, but it does allow (!) its scripts.)
Started FF with -safe-mode:  still downloading to Temp.
So this seems not connected to NoScript.  (thus coming over from there, see https://forums.informaction.com/viewtop ... =7&t=22352).
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.

Any ideas, someone?  Thanks, Hans

[Grumpus]

Look under /edit/preferences/applications and see what is used for the .odt files.
You might also want to look at /edit/preferences/general and see how the download section is set.
Look at where downloads are saved and also look to see if the "Ask me where to save files is checked" instead of the direct download.
Also, since .odt is LibreOffice (open text format) check your LibreOffice options for browser and accompanying settings.
You you might want to look at the permissions set in your system for the access and write capability for those files and or folders where the files are copied from.
Sometimes copying from on computer to another or even one drive(system) to another may make affect the permission if the two systems do not parallel the same permissions or if the copying is being performed with or without admin permission. Usually, if opening a file manager with admin capability negates the access to other systems or drives as a default.

P.S: You might also want to check the white list in options for NoScript to see if file access is still OK and if not check the string in noscript.untrusted in about:config to see if it was added to the list. This would stop or affect any use of //:file.

[Hanspl]

This affects all kinds of documents, not only LibreOffice, for instance also PDF.
.odt /.ods are not (yet) listed in Preferences|Applications; PDF is set to Ask or Open with PDFexchange Editor, no difference.
Downloads are pointed to the Download folder; Ask me… is checked or unchecked, no difference.
Pointing at such a link shows file:S:///…; clicking (when set to Ask) yields Open <filename> … from /S:/… — but does not open from there, instead downloading the file to the Temp folder (not the set Downloads folder), then opening the file write-protected from there.
The permissions are alright, the current awkward workaround is to Save As… in the respective editor, browsing back to the original path.

As noted above, this also happens in a clean install of FF, that is, without NoScript installed. But NoScript, if installed, is affected in some mysterious way, too. it does not recognize this local http://server1.

Of course, a file in the WWW outside, say, a PDF pointed to by a Google http://… link, has to be downloaded to Temp first — a file:///… needs not. How does FF decide whether to download or just pass the file:///… link? What can go wrong in this process?

[therube]

https://forums.informaction.com/viewtop ... =7&t=22352

[Hanspl]

@therube: Well, yes, that's my original post when I still suspected NoScript — see the link in my first post above. I think now NoScript is not the culprit but a victim of this issue.

[Grumpus]

It may be a change in the operating system and not Firefox but have you tried a different pdf reader? Evince, XPDF, Atril
Also if the ask option for the file type was set on one of the earlier Firefox updates and the check mark relating to treat filetypes of this kind in the same manner was checked it could be carried over in the code some how. Haven't found an item relative in About:config to reset or clear this as it was removed several updates back
Look at the following items in about:config and see if they make a difference:
browser.download.forbid_open_with true-false
browser.helperApps.neverAsk.openFile; string file (maybe with a wild card) just a guess.
There's also an item in about:configwhich will erase the temp file: browser.helperApps.deleteTempFileOnExit
There may be something in the system which is "seeing" the file:/// call as remote causing the download to temp.
Under NoScript options/Advanced/Trusted - is allow local links checked?

[Hanspl]

browser.download.forbid_open_with true-false

Checked that already; with True the choice to Open With disappears, only Save remains.

browser.helperApps.neverAsk.openFile; string file (maybe with a wild card) just a guess.

Will check.

There may be something in the system which is "seeing" the file:/// call as remote causing the download to temp.

That's my suspicion — but what?  As stated above, even with a fresh clean install of FF and an empty profile I have this problem — could it be some weird Win10 issue?

Under NoScript options/Advanced/Trusted - is allow local links checked?

This problem exists even without having NoScript installed.
That option is dangerous, it globally allows local linking for all web sites.  We did use it previously, until it stopped working with FF28, then we switched to the safer version described in my top post.  Very recently there was a bug in NoScript where checking this option in combination with the above policy actually stopped local links — this surfaced here on two machines where I had forgotten to uncheck it.  Now it is unchecked, but it makes no difference on this issue.

[Grumpus]

Maybe one of the Windows 10 wizards can figure it out, it's past me.
No issue with Linux unless I block access to a folder by denying others with "none" and making sub files under have the same permission level.
Have the permissions for the individual folders you are copying from been changed?
Have the properties for the individual files been given the same permission level as the folders.
Lastly if the files were created, moved or copied by someone while in admin level it may have affected things but I don't know if W10 does that.

[Hanspl]

Can't be a problem with permission, those files are read/writable alright. Must be in FF, since I now tried the following:
a)  On a “good“ machine, created a new empty profile:  local links do not open at all. OK.
b)  Closed FF, pasted those five lines into pref.js, restarted FF:  local ink to a PDF now opens in FF's preview from original path. OK.
c)  Set application options to Ask:  asks, then when choosing Open With downloads to local Temp, opening from there. Bad!
d)  Reset to the original profile:  opens from server. Good! Why?

e)  On the “bad“ machine, created a new empty profile: exactly like a) – c) above. No surprise there.
f)  Copied only prefs.js from the “good” machine:  still downloading, bad.
g)  Used the original “bad” profile with NoScript and all, just copying the “good” prefs.js:  still downloading, bad.
h)  Copied the entire profile from the “good” machine:  now opening from server. Good! Why?

A well-used profile contains a LOT of files and settings.  Where else than in prefs.js should I search for my crooked needle in this haystack?

[Grumpus]

Do you have a program like wdiff for Windows where you can compare individual files?
You have the files which work and the same name files which don't, if you could compare these files it may help track down the issue.
Otherwise I would be guessing as I discontinued use of Microsoft over a decade ago.

[Hanspl]

Yes, I have tools available, and I've already tried to compare some files (copied to my own Linux machine, of course) or grepped for »server1« or «local«. But there are more files in the older “good” profile than in the “bad” (some of them remains from ancient TBs, I think), some binary data or DBs, and there are lots of differences. Haystack…