1058527 - Local links (file://) not working

Status: RESOLVED WORKSFORME

(Core :: Networking: File, defect)

Description

[denzilsearle]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release)
Build ID: 20140716183446

Steps to reproduce:

On a company wiki, click a link to a file on a local server. Links are in the form

file:///servername/url

user.js is configured on client PC as

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


Actual results:

Nothing


Expected results:

Linked file opens in application specified in FF applications preferences.

Comment 1

[Cork]

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

Based on that I'm marking this a dup of bug 88293

Comment 2

[denzilsearle]

See also this bug https://bugzilla.mozilla.org/show_bug.cgi?id=995943 Capability preferences were disabled in FF29, supposedly partially reinstated in FF30 and 31. The capsfileuri add-on referred to in the previous bug doesn't work either.

Sorry, I should have been more specific, we link to mapped drives in the form file:///R:/filepath. Links to the actual server name with five slashes as above don't work, either.

Comment 3

[denzilsearle]

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. They worked fine until FF29, so it still implies a Firefox issue rather than Mediawiki.

Comment 4

[Loic]

If you think there is a regression since FF30 or 31, install the tool mozregression (see http://mozilla.github.io/mozregression/ for details) and paste here the console result.
In your case, you'll need to create a test profile with your "corporate" user.js to use with mozregression (see the tutorial).

Comment 5

[denzilsearle]

I'm not sure if this counts as a regression? It worked fine in FF28, stopped working in 29, and hasn't worked since. I can do the testing to see if any build does work, but it could take a while.

I have done another test. I copied the source html from a page on our wiki, saved it as an html file elsewhere and links work OK from that. So, it seems there is a difference in how FF interprets the page served from the wiki and 'normal' html.

Comment 6

[Loic]

Is it reproducible directly with links from files saved on the localhost (id est my own computer as I d'on have any local server to test)?

If yes, could you provide a simple testcase (with a text file or something like that).

Comment 7

[denzilsearle]

That's the problem. Our wiki is served live from a web server, it isn't opening a saved html file. I could save a simple html/text example, but that will work OK and you will tell me there is no problem. I don't know how to recreate the behaviour of a web server with a text file example!

Comment 8

[Alice0775 White]

(In reply to denzilsearle from comment #0)

> 
> user.js is configured on client PC as
> 
> user_pref("capability.policy.policynames", "localfilelinks");
> user_pref("capability.policy.localfilelinks.sites", "http://servername1",
> "http://servername2");
> user_pref("capability.policy.default.checkloaduri.enabled", "allAccess");
> 

First of all, capability.policy.localfilelinks.sites should be space separated value.
So, you should set preferences as follows.
user_pref("capability.policy.localfilelinks.sites", "http://servername1 http://servername2");

Comment 9

[denzilsearle]

Doesn't make any difference. I also tried it with only one server entry, and it still doesn't work.

Comment 10

[denzilsearle]

Why has another bug 1061128 been raised as a duplicate of this one?

Comment 11

[Alice0775 White]

(In reply to denzilsearle from comment #10)
> Why has another bug 1061128 been raised as a duplicate of this one?

Please ignore bug 1061128.
Instead please refer bug 1061136.

Comment 12

[Peter Eff]

Beside the policy settings, this bug addresses the very old (see bug 88293) wrong interpretation of the file-URI-scheme for an UNC-path, where the 2 backslashes are taken as part of the hostname.

But:
The RFC 173 URL states a file URL takes the form:
file://<host>/<path>

The UNC scheme is defined (see e.g. http://msdn.microsoft.com/en-us/library/gg465305.aspx) as

UNC =  \\<hostname>\<sharename>[\<objectname>]*

with 
    <hostname>: Represents the host name of a server or the domain name of a domain hosting resource; the string MUST be a NetBIOS name as specified in [MS-NBTE] section 2.2.1, a fully qualified domain name (FQDN) as specified in [RFC1035] and [RFC1123], or a textual IPv4 as specified in [RFC1123] section 2.1 or IPv6 address as specified in [RFC4291] section 2.2.

That is, the <host> in RFC 1738 is equivalent to the MS-definition of a <hostname> and the two backslashes are part of the UNC scheme and not part of the hostname!

As a result, the UNC path \\servername\share\file.ext must become file://servername/share/file.ext

On Windows, a localhost file link for C:\path\file.ext must be file://localhost/c|/path/file.ext or file:///c|/path/file.ext as stated in other bug reports.

Firefox should apply these conversion rules!


To be fault tolerant, it should consider file://-links with 4 or more slashes following immediately after "file:" as variants of the complete scheme including the <host>.

That is, the following examples should be converted correctly into the appropriate local file handles:
file://servername/share/file.ext    correct syntax
file:///servername/share/file.ext   valid only on a Unix system for the file "/servername/share/file.ext", normally invalid on Windows
file://localhost/c|/path/file.ext   correct syntax for a local Windows file "c:\path\file.ext" (valid for a Unix, if someone has a "/c|/path" directory with "file.ext" in it...)
file:///c|/path/file.ext            short for file://localhost/c|/path/file.ext

As aliases for file://servername/share/file.ext would be tolerated:
file:////servername/share/file.ext
file://///servername/share/file.ext
file:////////servername/share/file.ext
and so on

Thank you for implementing this ASAP!

Comment 13

[denzilsearle]

Is this likely to be fixed? The problem is still there in FF33. We can get round it with the LocalLink add-on, but it is awkward.

Comment 14

[Neo Futur]

using FF35 ( beta channel ) on linux, , file:// for local files not working again, fix needed asap, this is an basic and important feature  ;(

Comment 15

[Peter Eff]

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!

Comment 16

[Ryan VanderMeulen [:RyanVM]]

(In reply to denzilsearle from comment #13)
> Is this likely to be fixed? The problem is still there in FF33. We can get
> round it with the LocalLink add-on, but it is awkward.

I regression range would still be really helpful in tracking this down. Would you be willing to try the mozregression tool for narrowing it down? Something like |mozregression --good-release 28 --bad-release 29| should make narrowing it down pretty straightforward.
http://mozilla.github.io/mozregression/

Thanks!

Comment 17

[denzilsearle]

I asked the question on the support forum as well. Sorry, I should have updated this as well.

https://support.mozilla.org/en-US/questions/1066709#answer-741219

It is slightly embarrassing, but it turned out that the name of the server had been changed and the old name left as a redirect. That explains why the links worked with, for example, a copy and paste into Explorer. As soon as I put the new server name in user.js it worked OK. I am marking it as resolved on that basis. Thanks to everyone who tried to help.

Comment 18

[Ryan VanderMeulen [:RyanVM]]

Thanks for the quick response :)