The key points appear to be

• Does this work in the Release & Nightly ??
• Is this in fact Bug88293

From the System information provided in this post (see aside) you appear to be using the current Release Fx38 . Whilst I did not try to read through the many comments in

• Bug 995943 - local (file://) links don't work even when configured for company's internal system

I did note it is marked as verified fixed in Fx29

I also note it contained links to an add-on #c147, as you are aware.

I expected the change to be in ESR based on fx31 as the branch 29 comment in the bug header and #c149. If you are not already doing so have you tested a copy of ESR 38.0 https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/38.0.1esr/

Bug 1058527 - Local links (file://) not working Was presumably filed by you. I do not fully understand the subject but it appears one of two things has happened.

• Either your issue is in fact the old
  Bug 88293 - file:// URLs w/ UNCs do not work
  which is not being fixed
• Or you have been affected by some regression. If it is a regression
  • You should ideally use mozregression to find the precise regression range in Nightly.
  • At the very least you should find the point releases of ESR 31 & 38 that are or are not affected by testing each one in turn.

If it is a regression and you are able to show that you may get a fix in your own bug. If it is Bug 88293 I may be able to point you somewhere to get further information elsewhere.

I note this is a continuation from /questions/1011311 I have cross linked from the archived thread

I have looked at 88293 but I don't think it is the same thing. That was raised a long time ago, and opening links worked fine until FF29. 995943 was marked as fixed, as far as I can see, because it will open a link contained in a saved local html file. It will not open a link if the page is served live from a local webserver. At the end of that bug somebody suggested I raise a new one for that. Hence 1058527.

I haven't tried ESR38. I will do so.

If this does not work in ER38 (I donot expect it to) then this issue appearsto be a regression and worked previously. It would be best if you could write some simple Steps To Reproduce and then test using the utility Mozregession.

It is probably easier and faster to try Mozregression than manually running through a series of ESR point releases, and the regression range will be more precise.

That should pin point the changes that caused the problem. It is much more likely the bug may then be confirmed and worked on.

I have just tried ESR38, and it doesn't work.

Steps to reproduce are in bug 1058527. Tell me what more you need and I will do what I can. It worked up to FF28, and stopped in FF29 when the capability.policy system was removed (as I understand it). If you need it narrowed down to specific builds I'll have a go with Mozregression, but it could be a few days before I have time.

As I said I do not fully understand this subject. I am not an intranet user and am making the presumption that what you are reporting is a bug or unintentional regression and not just a deliberate feature removal.

... In order to respond to demands of enterprise users, the localfilelinks policy has been restored with Firefox 30. This allows users to follow links on a Web page (http:// or https://) to the local file system (file:///) especially on corporate internal applications. For the meantime, Firefox Beta or the caps-fileuri extension created by a Mozilla developer can be used to workaround this restriction. { Configurable Security Policies (CAPS))

I understand you re aware of that.

It may just be my lack of knowledge, not being able to follow this but you initially said the problem was with

file:///servername/url

A reply #c1 initially closed the bug as a duplicate

file:///servername/url maps to /servername/url where servername is a folder on the local system.
If you mean to access an unc address the link would be file://///servername/url

In #c3 you are saying Interestingly, I created a skeleton html page to try it out, and links work OK as file:///R:/ or file://///servername. They don't work from our Mediawiki intranet.

Isn't everything explained by #c13

As stated in #12, "file://" only can't refer to local links. It must be file:/// or file://localhost/ followed by the local file path.
Nevertheless, your're right when you say, usable file:-links are a basic and important feature!

As I said earlier I am unsure of lot a of this myself. I will see if I can find someone who is able to look at this and give you a proper answer, but you may just be seeing Bug 88293

If you check the browser console (Ctrl+Shift+j), are you getting one or both of these error messages:

(UNC path)

Security Error: Content at http://serverA/dir/page.html may not load or link to file://///serverB/dir/page.html.

(mapped drive)

Security Error: Content at http://serverA/dir/page.html may not load or link to file:///M:/dir/page.html.

If it's not an exact match, where do you see differences in the errors you're getting?

Can you post your user_pref() code? You can change the server names to serverA, serverB, etc.

I have tried it with UNC and mapped drive paths with various numbers of slashes and it doesn't make a difference. This is why I'm thinking it is not connected to that issue. Besides, like I said, it works fine if you open a link contained in a static html file. We use Mediawiki for our intranet, which is a database-driven site like any other CMS, not static html. That seems to be where it's not working.

I hadn't heard of the console before. When I click a link it gives me,

Security Error: Content at http://research/index.php?title=Main_Page may not load or link to file:///W:/filepath/file.xls.

Our user.js is

user_pref("capability.policy.policynames", "localfilelinks"); user_pref("capability.policy.localfilelinks.sites", "http://serverA http://serverB"); user_pref("capability.policy.default.checkloaduri.enabled", "allAccess");

I will leave you in the capable hands of jscher2000. (Thanks Jeff.)

But will mention the consoles pages

• https://developer.mozilla.org/docs/Tools/
  • https://developer.mozilla.org/en-US/docs/Tools/Browser_Console
  • https://developer.mozilla.org/en-US/docs/Tools/Web_Console

dsearle said

Our user.js is

user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.sites", "http://serverA http://serverB");
user_pref("capability.policy.default.checkloaduri.enabled", "allAccess");

I was going to test these preferences, but I noticed the third one has "default" instead of "localfilelinks" and I wonder whether that is not allowed. (Even if allowed, it seems unwise...) Could you try this for the third line:

user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");

See also:

• http://mxr.mozilla.org/mozilla-release/source/caps/nsScriptSecurityManager.cpp#1397

I think I can follow what the code is doing, but I'm not a software designer, so I'll have to rely on you guys to find the problem.

jscher2000 said

I was going to test these preferences, but I noticed the third one has "default" instead of "localfilelinks" and I wonder whether that is not allowed. (Even if allowed, it seems unwise...) Could you try this for the third line: user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");

It doesn't make a difference - I still get the same error in the console.

I created a test page for this in another thread to ensure this still works in Firefox 39: https://support.mozilla.org/questions/1073300

Have you gotten this working yet (if the only server is "research"):

user_pref("capability.policy.policynames", "localfilelinks"); user_pref("capability.policy.localfilelinks.sites", "http://research"); user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");

No, it doesn't work, and I still get the same error in the console. Once again, I have tried saving a copy of a page as a static html and it works fine. It doesn't work if the page is served dynamically from the database.

dsearle said

I have tried saving a copy of a page as a static html and it works fine. It doesn't work if the page is served dynamically from the database.

I forgot about that aspect and I don't have a convenient way to test it.

However, since the policy is based on protocol+host, it's puzzling to get different results between a static page and dynamic page on the identical protocol+host. Does the wiki use a different port number or have any other obvious difference from your static page?

We've been trying a couple of things here and actually I think that was a bit of a red herring. I saved the html onto a shared file server and the link works from there, but the linked file is also on the same server. We saved the html onto a web server and it didn't work from there. So, it isn't a live vs saved thing.

Any more ideas welcome!

Unfortunately, I don't know how to look inside the running Firefox to see whether it has properly read and digested the preferences.

Does your server URL contain a port number? It might be necessary to add that to the file, for example:

user_pref("capability.policy.localfilelinks.sites", "http://research:8080");

OK, problem solved. It seems I was using an out of date URL for our wiki, which had been moved to another server and the old link redirected, only I hadn't been told about the new name. I just had to put the new server name in the user.js. and in the bookmark for the site so they match.

If there were a 'roll eyes' emoticon here, I would be adding one now.

Thanks for trying, anyway, it is appreciated.