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

Status: VERIFIED FIXED

(Core :: Security: CAPS, defect)

Description

[Robert Geißler]

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

Steps to reproduce:

We configure our Firefox installations with the following settings in a cfg file:

lockPref("network.protocol-handler.expose.file", false);
lockPref("network.protocol-handler.external.file", true);
lockPref("capability.policy.policynames", "localfilelinks");
lockPref("capability.policy.localfilelinks.sites", "list of hostnames and ips");
lockPref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");

This is for an internal wiki system to open file:// links from a network share - for example file://M:\somefolder\something.pdf with the windows standard application


Actual results:

In Firefox 29 Beta, the files are not opend with the configuration above. The browser console shows an error message (German: "Sicherheitsfehler: Inhalt auf http://something/ darf file M:\somefolder\something.pdf nicht laden") that the website is not allowed to load the file M:\somefolder\something.pdf
The settings are not working anymore - the errormessage is the standard error message which is shown, when local links are clicked on.

Are there any changes related to local links and the file handling?
Our settings are locked correctly in about:config, our cfg File works - but the options are not showing the expected result.


Expected results:

The local file should open with the windows standard application.
Our configuration works in Firefox 28 and older versions.

Comment 1

[Alice0775 White]

Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/681ab70f6707
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 ID:20131213184052
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/093a4a3a68ca
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 ID:20131213191653
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=681ab70f6707&tochange=093a4a3a68ca

Triggered by: Bug 913734

Comment 2

[Alice0775 White]

This is affected to next ESR.
This bug should fix for the enterprise use, I think.

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Hey bholley, any chance you could take a quick peek at this?

Comment 4

[Sylvestre Ledru [:Sylvestre]]

A fix will have to come fast to make it to 29...

> This is affected to next ESR.
Yes but we have time (the next ESR will be 31).

Comment 5

[Bobby Holley (:bholley)]

(In reply to mozilla from comment #0)
> lockPref("capability.policy.policynames", "localfilelinks");
> lockPref("capability.policy.localfilelinks.sites", "list of hostnames and
> ips");
> lockPref("capability.policy.localfilelinks.checkloaduri.enabled",
> "allAccess");

Yeah, we removed the entire capability.policy subsystem. So this isn't going to work anymore.
 
> This is for an internal wiki system to open file:// links from a network
> share - for example file://M:\somefolder\something.pdf with the windows
> standard application

I think the solution there is to create a tiny page-mod extension that binds the the pages you want to privilege, finds all the links, and adds an onclick handler for each one, which sends a message to the extension code to load the file from a privileged context.

scaleworld, would that solve your problem? Gabor, does that all sound workable to you?

Comment 6

[Robert Geißler]

Thank you for the fast answers.

About a year ago, we had to find an alternative for our very very old Opera and SeaMonkey versions (with "built in" local links ability), because the old browsers couldn't render the new mediawiki versions correctly.
The solution with Firefox was just perfect - easy to deploy with our software distribuition, an up-to-date browser which is safe and local links functionality on defined, internal websites.

So yes - if the "new" solution let us open local links from defined websites and I'm able to configure / deploy it, this is for sure a solution for me. I have to find a solution for our company - If you could help me to find a smart solution (no 10 year old browser without any security, no extra installation on a FF28 base for internal wiki use only, .......) - honestly, I knew that someday the configuration would not work any more :)

Comment 7

[Gabor Krizsanits (INACTIVE)]

(In reply to Bobby Holley (:bholley) from comment #5)
> scaleworld, would that solve your problem? Gabor, does that all sound
> workable to you?

Yes, this sounds right. A good place to find more info about it would be: https://developer.mozilla.org/en-US/Add-ons/SDK/Tutorials/Modifying_Web_Pages_Based_on_URL

Comment 8

[Lukas Blakk [:lsblakk] use ?needinfo]

We're not going to get anything into FF29 at this time, is this worth tracking for 30?  It looks like we just need to ensure a fix in FF31 for our next ESR.

Comment 9

[Bobby Holley (:bholley)]

(In reply to Lukas Blakk [:lsblakk] from comment #8)
> We're not going to get anything into FF29 at this time, is this worth
> tracking for 30?  It looks like we just need to ensure a fix in FF31 for our
> next ESR.

No, this is basically WONTFIX. See comment 5.

Comment 10

[Lukas Blakk [:lsblakk] use ?needinfo]

I see, extensions ftw.  Thanks.

Comment 11

[Tory Dombrowski]

(In reply to Bobby Holley (:bholley) from comment #5)
> (In reply to mozilla from comment #0)
> > lockPref("capability.policy.policynames", "localfilelinks");
> > lockPref("capability.policy.localfilelinks.sites", "list of hostnames and
> > ips");
> > lockPref("capability.policy.localfilelinks.checkloaduri.enabled",
> > "allAccess");
> 
> Yeah, we removed the entire capability.policy subsystem. So this isn't going
> to work anymore.
>  
> > This is for an internal wiki system to open file:// links from a network
> > share - for example file://M:\somefolder\something.pdf with the windows
> > standard application
> 
> I think the solution there is to create a tiny page-mod extension that binds

What does this mean for us Small Business IT Managers that have deployed Web Applications with local file links?  I see you are basically not going to fix this, but I am not an Extension coder so simply stating "extensions ftw" doesn't help me.  Will there be a publicly available extension to cover this particular situation?  Otherwise you will drive me and my user base back to heresy with IE  (***shivers at the thought***)
> the the pages you want to privilege, finds all the links, and adds an
> onclick handler for each one, which sends a message to the extension code to
> load the file from a privileged context.
> 
> scaleworld, would that solve your problem? Gabor, does that all sound
> workable to you?

Comment 12

[Boris Zbarsky [:bzbarsky]]

Bobby, I don't think we should have broken this without providing a simple replacement; the current system was put in place precisely because this is a common request in intranet environments and the extension route is too high a bar.

How hard would it be to just support the old pref syntax?  If too hard, how hard is it to create a new simpler-to-support syntax and auto-migrate prefs?

Comment 13

[Boris Zbarsky [:bzbarsky]]

And I'm sorry I didn't catch this until we're releasing it.  :(

Comment 15

[Boris Zbarsky [:bzbarsky]]

I think this is bad enough we may want to chemspill for it, personally.  :(

Comment 16

[Bobby Holley (:bholley)]

(In reply to Boris Zbarsky [:bz] from comment #15)
> I think this is bad enough we may want to chemspill for it, personally.  :(

Hm, why? And what would we do? Trying to add back C++ support for this is not going to be pretty.

We could pretty easily write a drop-in add-on replacement. It would do the following:

(1) Read + Watch capability.policy.* prefs, and create a list of domains for which we want to allow these loads.

(2) Register a pagemod on the domains in (1) that, upon loading, adds an click listener to each file:// link in the page.

(3) That listener prevents the default action, and sends a message to the chrome-privileged parent, which invokes open() on the URI.

This is probably a half-hour job for someone who knows the addon sdk. I'm happy to take a crack at it tomorrow if that works.

Comment 17

[garydean]

(In reply to Bobby Holley (:bholley) from comment #16)
> 
> We could pretty easily write a drop-in add-on replacement. It would do the
> following:
> 
> (1) Read + Watch capability.policy.* prefs, and create a list of domains for
> which we want to allow these loads.
> 
> (2) Register a pagemod on the domains in (1) that, upon loading, adds an
> click listener to each file:// link in the page.
> 
> (3) That listener prevents the default action, and sends a message to the
> chrome-privileged parent, which invokes open() on the URI.
> 
> This is probably a half-hour job for someone who knows the addon sdk. I'm
> happy to take a crack at it tomorrow if that works.


please take a crack! this bug has crippled my corporate intranet. i have hordes of employees demanding why they can't open client files on our network. i need a fix for this fast.

Comment 19

[Boris Zbarsky [:bzbarsky]]

> And what would we do?

Ideally, make the existing prefs work again in as transparent a way as possible.

If we want to then start having deprecation messages, etc, that seems fine, but just breaking this outright is no good at all.

C++ support would be fine if we can keep it simple, and I suspect it would be way simpler than the old setup.

The page-mod thing is workable, but then requires that extension to be deployed on all the many intranets that are using this stuff.

Comment 20

[Bobby Holley (:bholley)]

Attachment: caps-fileuri.xpi

I just hacked up an extension to seamlessly parse the old-style CAPS prefs and restore the previous behavior. Can try it out and let me know whether it does the trick?

Comment 21

[Bobby Holley (:bholley)]

Source is on github: https://github.com/bholley/caps-fileuri

Comment 22

[garydean]

(In reply to Bobby Holley (:bholley) from comment #20)
> Created attachment 8415037 [details]
> caps-fileuri.xpi
> 
> I just hacked up an extension to seamlessly parse the old-style CAPS prefs
> and restore the previous behavior. Can try it out and let me know whether it
> does the trick?

tried it out. did nothing that i was able to descern. my local user.js as follows:

user_pref("network.protocol-handler.expose.file", false);
user_pref("network.protocol-handler.external.file", true);
user_pref("network.protocol-handler.warn-external.file", true);
user_pref("capability.policy.default.checkloaduri.enabled", "allAccess");
user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");
user_pref("capability.policy.localfilelinks.sites", "http://okusi0");

link to file:/// in intranet web page (okusi0) still does nothing. it should execute /usr/bin/nautilus and display folder contents.

Comment 23

[Bobby Holley (:bholley)]

Comment on attachment 8415037 [details]
caps-fileuri.xpi

Looks like I was testing against an old version of release Firefox that was lying around (26). Testing it against 29 doesn't seem to work. Looking into it.

Comment 24

[Bobby Holley (:bholley)]

Attachment: caps-fileuri.xpi (v2)

Ok, this one should work. Can you give it a shot?

Comment 25

[Bobby Holley (:bholley)]

(Let me know if you're actively testing this, and I'll stay up a bit longer to hear how it goes)

Comment 26

[garydean]

(In reply to Bobby Holley (:bholley) from comment #25)
> (Let me know if you're actively testing this, and I'll stay up a bit longer
> to hear how it goes)

it's working to the extent that it's opening up the folder in a web page.

however, for my purposes, it's not using the external application to open the link. this would abe a separate oissue i would guess.

Comment 27

[garydean]

correctio(In reply to garydean from comment #26)
> (In reply to Bobby Holley (:bholley) from comment #25)
> > (Let me know if you're actively testing this, and I'll stay up a bit longer
> > to hear how it goes)
> 
> it's working to the extent that it's opening up the folder in a web page.
> 
> however, for my purposes, it's not using the external application to open
> the link. this would abe a separate oissue i would guess.

correction: it's a bit more subtle than i thought.  i have a link on my intranet web page: <a href='file:///home/gary/okusi0/KLIEN/DEGA'>folder</a>. it's a link to a folder.

on clicking, it presents the contents of the folder in a web page.  on clicking folder icons on that page, my external program (nautilus) is executed!

Comment 28

[garydean]

in other words, you seem to be tantilisingly close! good work!

Comment 29

[Bobby Holley (:bholley)]

(In reply to garydean from comment #26)
> (In reply to Bobby Holley (:bholley) from comment #25)
> however, for my purposes, it's not using the external application to open
> the link. this would abe a separate oissue i would guess.

Hm. Boris, when you wake up, can you have a look at [1] and let me know if anything jumps at out at you? It seems like the prefs in comment 22 are supposed to force an external application, which isn't working here. Do those only come into play for user-driven loads or somesuch?

[1] https://github.com/bholley/caps-fileuri/blob/master/lib/main.js

Comment 30

[Robert Geißler]

(In reply to Bobby Holley (:bholley) from comment #24)
> Created attachment 8415051 [details]
> caps-fileuri.xpi (v2)
> 
> Ok, this one should work. Can you give it a shot?

Thank you.
Basically - it is working, but not exactly as it worked before version 29.
It will work with standard-files like pdf and so on, but for example not with .exe oder .bat
.exe, .bat, .... are the reason, why we bypassed the firefox open command and let windows do the opening (see my configuration in the start post) - so all files are opend with there windows standard application and all files can be opened.

Comment 31

[garydean]

(In reply to Bobby Holley (:bholley) from comment #29)
 
> It seems like the prefs in comment 22 are
> supposed to force an external application, which isn't working here. Do
> those only come into play for user-driven loads or somesuch?

the external application only works when the url on the webpage is file:///blah/blah/blah/ ... when i click on the icons or filenames on that page, the external application is executed correctly.

the problem seems to be that the external application does not execute from a link within a non-local url (in my case, my intranet domain).

Comment 32

[Murz]

Confirm this bug and regression too, it stops all processes in our company, because we active use links to local files in coprorate CRM and other systems.

> Created attachment 8415051 [details] caps-fileuri.xpi (v2)
- thanks for this extension, but it is not work for me. Maybe I need to do some other actions for activate it after install? Can you describe short howto-use?

Comment 33

[Bobby Holley (:bholley)]

(In reply to Murz from comment #32)
> > Created attachment 8415051 [details] caps-fileuri.xpi (v2)
> - thanks for this extension, but it is not work for me. Maybe I need to do
> some other actions for activate it after install? Can you describe short
> howto-use?

In theory, you should just need to install it, and it should work automatically.

Can you post the relevant parts of your preferences file?

Comment 34

[evan.milefchik]

So evidently the good folks at Mozilla didn't think this one through. Apparently you didn't realize how many businesses were utilizing this sub system.

Allow me to be the first to say that creating an extension as a fix is ridiculous. I'm not going to install some random extension on 50 computers to get this functionality again, and to suggest that as solution is asinine.

This blatant disregard has infuriated me, but I digress. Unless this is properly fixed soon my company will be moving on from Mozilla and will never return to your products. Updates should improve functionality, not break what's already there. (Not to mention the UI is horrid in Version 29, what were you guys thinking??). I really hope someone at Mozilla is listening.

Comment 35

[Boris Zbarsky [:bzbarsky]]

> Do those only come into play for user-driven loads or somesuch?

This pref:

  user_pref("network.protocol-handler.external.file", true);

should in theory cause Gecko to never use our built-in file:// handler.  But it will only work if the preference is read before the first time someone tries to get the file:// handler, which I suspect is not very likely to happen if it's set as a user pref.

This pref:

  user_pref("network.protocol-handler.expose.file", false);

affects the return value of nsIExternalProtocolService.isExposedProtocol.  This is checked in the OnLinkClickSync code in docshell, and if the protocol is not exposed we hand the load over to the external protocol service to handle instead of handling it internally.  

Presumably you want to do something like that in the extension too?  http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/text.xml#331 has some code you should be able to crib.

Comment 36

[Sylvestre Ledru [:Sylvestre]]

(In reply to evan.milefchik from comment #34)
> Apparently you didn't realize how many businesses were utilizing this sub
> system.
We expect business to use ESR ( https://www.mozilla.org/en-US/firefox/organizations/faq/ ). It is made for companies and we qualify them using two cycles.

Comment 37

[Bobby Holley (:bholley)]

Attachment: caps-fileuri.xpi (v3)

Ok, here's an updated extension that should open file:// URIs with an external application when "network.protocol-handler.expose.file" is set.

Gary, can you take a look?

Comment 38

[Bobby Holley (:bholley)]

Flagging Murz for needinfo to make sure that we fix whatever bug is causing this not to work there.

Comment 39

[Bobby Holley (:bholley)]

Jorge, once this extension is finalized (hopefully in the next couple of hours), can we fast-path it onto AMO? How long will that take?

Comment 40

[Mike Kaply [:mkaply]]

I'm going to port this extension over to be a regular extension so it can be in distribution/bundles. I have no idea if we would actually do this, but this might be a useful extension to bundle with the ESR.

Comment 41

[Jorge Villalobos [:jorgev] (he/him)]

Provided it isn't massive or we find any problems with it, we can approve it within an hour or so.

Comment 42

[Mark Gunnett]

Extension works fine. Browser needs a restart though for it to kick in. Maybe add a trigger to the plugin to ask users to restart the browser on install?

Comment 43

[Mike Kaply [:mkaply]]

> Extension works fine. Browser needs a restart though for it to kick in. Maybe add a trigger to the plugin to ask users to restart the browser on install?

I'm going to rework it as a non restartless extension (since it can't be anyway) and it will also allow it to be bundled in the Firefox distribution directory.

Comment 44

[garydean]

(In reply to Bobby Holley (:bholley) from comment #37)
> Created attachment 8415447 [details]
> caps-fileuri.xpi (v3)
> 
> Ok, here's an updated extension that should open file:// URIs with an
> external application when "network.protocol-handler.expose.file" is set.
> 
> Gary, can you take a look?

works! thanks very much for your help with this!

are you going to make it available as an add-on in mozilla?

Comment 45

[Bobby Holley (:bholley)]

(In reply to garydean from comment #44)
> (In reply to Bobby Holley (:bholley) from comment #37)
> > Created attachment 8415447 [details]
> > caps-fileuri.xpi (v3)
> > 
> > Ok, here's an updated extension that should open file:// URIs with an
> > external application when "network.protocol-handler.expose.file" is set.
> > 
> > Gary, can you take a look?
> 
> works! thanks very much for your help with this!
> 
> are you going to make it available as an add-on in mozilla?

I'm going to put it on AMO, yes. And Mike is going to package it up to make it easily deployable in an enterprise environment (comment 43), but that might take some time.

Comment 46

[Bobby Holley (:bholley)]

bz, can you give me an informal DOM-side review of https://github.com/bholley/caps-fileuri/blob/master/lib/main.js , and then I'll submit it to AMO?

Comment 47

[Boris Zbarsky [:bzbarsky]]

>                     ' if (link.href.indexOf("file://") == 0) {',

How about checking link.protocol == "file:"?

This extension is completely ignoring the "target" attribute on the link...  Get it up for now, but then let's fix that part and post an update?

Comment 48

[Bobby Holley (:bholley)]

Addon posted here:

https://addons.mozilla.org/en-US/firefox/addon/caps-fileuri/

Kmag, can you fast-track it?

Comment 49

[Robert Geißler]

(In reply to Bobby Holley (:bholley) from comment #37)
> Created attachment 8415447 [details]
> caps-fileuri.xpi (v3)
> 
> Ok, here's an updated extension that should open file:// URIs with an
> external application when "network.protocol-handler.expose.file" is set.
> 
> Gary, can you take a look?

works fine - thank you!

Comment 50

[Bobby Holley (:bholley)]

> 1) Iterating over every link in a document can be extremely expensive. Your current approach is also
> going to miss links which are script-generated, or have their `href` attribute programmatically changed.
> Please add a top-level click event listener, and check if the target is a file: link when your handler is
> called.

Fixed.

> 2) You should check `event.defaultPrevented` and bail if it's true.

Fixed.

> 3) When not forcing the use of an external link handler, you should correctly handle middle-click
> and ctrl+click, and open the link in a new tab.

Fixed.

> 4) I know that the chances of a click happening on a background tab are low (though not
> impossible; synthetic click events are known to happen), but you should be using `worker.tab`
> rather than `tabs.activeTab` to open the link.

Fixed.

> 5) You are using an outdated version of the Add-ons SDK, which we no longer accept. Please repack
> your code with the latest stable version of the SDK: https://addons.mozilla.org/en-US/developers/builder

Fixed.

> I'm also somewhat reluctant to give this full review at all. It works based on the values of
> hidden preferences, so it's not likely to be usable by a general audience, which is a bar that we
> set for full reviewed add-ons.

Well, it's really only useful for people who already have this set up, and want to restore the old functionality with minimal fuss. I don't know it it matters all that much, but it'd be nice to have some sort of official stamp on the addon so that sysadmins can feel comfortable installing and deploying it.

Re-uploading addon to AMO.

Comment 51

[André G.]

Thanks a lot for your work, but even with the new extension some things are not entirely working like before. I have a JSF2 application and as soon as I am partially updating a part of my page the local links in the affected part of the page stop working again. This was working perfectly fine with older versions of Firefox.

Comment 52

[tsuchim]

> Created attachment 8415447 [details]
> caps-fileuri.xpi (v3)
> 
> Ok, here's an updated extension that should open file:// URIs with an
> external application when "network.protocol-handler.expose.file" is set.
> 
> Gary, can you take a look?
This permits to access to local files via link at website on all of domains, right?
Previous method using capability.policy.policynames could limit domains to access local files without unofficial plugin. That was much more smart, I think.
Why you remove the good exception method? I would like you to revert the modification.

Comment 53

[Boris Zbarsky [:bzbarsky]]

> This permits to access to local files via link at website on all of domains, right?

No, it reads the prefs.  See the source, please.

Comment 54

[Bobby Holley (:bholley)]

(In reply to André G. from comment #51)
> Thanks a lot for your work, but even with the new extension some things are
> not entirely working like before. I have a JSF2 application and as soon as I
> am partially updating a part of my page the local links in the affected part
> of the page stop working again. This was working perfectly fine with older
> versions of Firefox.

I believe v0.2 should fix your problem. It's waiting on review on AMO, but in the mean time, can you give it a try here? https://addons.mozilla.org/en-US/firefox/addon/caps-fileuri/versions/?page=1#version-0.2

Comment 55

[André G.]

(In reply to Bobby Holley (:bholley) from comment #54)
> (In reply to André G. from comment #51)
> > Thanks a lot for your work, but even with the new extension some things are
> > not entirely working like before. I have a JSF2 application and as soon as I
> > am partially updating a part of my page the local links in the affected part
> > of the page stop working again. This was working perfectly fine with older
> > versions of Firefox.
> 
> I believe v0.2 should fix your problem. It's waiting on review on AMO, but
> in the mean time, can you give it a try here?
> https://addons.mozilla.org/en-US/firefox/addon/caps-fileuri/versions/
> ?page=1#version-0.2

I'm sorry, but I can't test the new version right now, but thanks for trying to solve this issue! I won't be able to give you a feedback before Monday, since I am away over the weekend.

Comment 56

[Kris Maglione [:kmag]]

Done.

Comment 57

[Bobby Holley (:bholley)]

Thanks kmag! The addon is now fully up on AMO: https://addons.mozilla.org/en-US/firefox/addon/caps-fileuri/

mkaply, can you notify the EWG? Also, can you file a separate bug for your non-restartless port of the addon? Once that's done, I think we can close this bug.

Comment 58

[Guillaume]

Thx for the add-on, this is certainly a good temporary solution. But FF29 not working out of the box with local files is a BIG problem for corporate users.

Any plans to reinstate 'capability.policy' in user_pref in Firefox 30 ??

Comment 59

[Bobby Holley (:bholley)]

(In reply to Guillaume from comment #58)
> Thx for the add-on, this is certainly a good temporary solution. But FF29
> not working out of the box with local files is a BIG problem for corporate
> users.
> 
> Any plans to reinstate 'capability.policy' in user_pref in Firefox 30 ??

Not in C++, no. But Mike Kaply is building an old-style extension, which should be deployable in the same way that the lockprefs are deployable. So anybody using the latter can also use the former.

There's also been discussion about shipping Mike's extension with ESR, which is something that I don't really have the knowledge to comment on.

Comment 60

[Mike Kaply [:mkaply]]

I understand your frustration, but this change was checked in for four months before someone reported it.

If you are choosing to use the the rapid releases of Firefox in your organization, it is imperative that you test with at least early Beta and Aurora and hopefully even nightly.

If you aren't willing to do that kind of testing, you should be sticking with the ESR so that things like this don't surprise you.

Comment 61

[Guillaume]

Of course you are right about ESR. Just wondering though, did you evaluate the impact of disabling 'capability.policy' on your users before implementing the change?? Did you provide them with a clear transition path to make the change as painless as possible?

I bet there are thousands, even tens of thousands of companies and web apps relying of local file access that are left out in the cold by this change. I'm just one of the first IT managers to raise the flag about this.

I'm sure wishing to see Firefox gain market shares in the corporate world, but that kind of change sure does not help in any way. You have to balance rapid development cycles with basic functionalities perennity.

In conclusion, I think it would be a mistake for the Mozilla team to close this bug, and merely rely on ESR adoption and an add-on as a permanent fix.

Your call.

Comment 62

[Mark Gunnett]

Well this change basically leaves MSIE as the only browser (of the main three I see deployed at companies) that natively supports local file links at this time. Chrome and FireFox both provide that functionality through an extension or addon now. I use FireFox in a corporate environment, but that is because I choose to use it. Our Company doesn't officially support FireFox so we don't even use ESR. Most of the people who use it at my company are going to be using the Rapid Release because we're just plain old users in that regard.

I understand Australis was essentially a rebuild of the browser in terms of customization and "Look and Feel", but it also seems to be a backwards step in functionality. I personally don't mind using the addon that's been created, but that's only if it continues to be supported in the foreseeable future.
---
I Digress. Thanks for getting that Addon up Bobby Holly (And everyone else) as fast as you did. Local File Links are not mission critical to my work (And if I really needed to I could have used MSIE). As far as I can tell the latest version seems to work just fine for what I'm using it for. I'll report any bugs I find while using it.

Comment 63

[Murz]

After installing updated package v0.2 - all works well, thanks!

Will be good to integrate whitelist domains editing:

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

into this extension, because at now this is not trivial for not-improved users.

Comment 64

[mozillafan]

For statistics: Here's another company (> 200 users) that switched back to MSIE - our local wiki has hundreds of file links we use on a daily basis. We don't use ESR, bacause FF is not officially supported but tolerated as long as it doesn't make problems. Still, we had conviced ca. two thirds of our users to use it (so many rebels at heart...). Now our SysAd is not willing to install another AddOn (even when it comes from Bobby Holley!), so that's it for us... I hope we can get the functionality back in the basic package! Please?

Comment 65

[Thomas Noirez]

Hello

We have a java intranet application using many links files.
This is a huge problem for us and our 1500 users.

I hope we don't have to get back to IE.

Cheers Thomas

Comment 66

[Mhtagada]

Hi,

like lots of people, we can't use this addon, because we can't add it for all our users
I think it must be included natively,

please don't let us like this, 
unless it will be resolve, the only choice for us is to use IE

Comment 67

[evan.milefchik]

(In reply to Mike Kaply (:mkaply) from comment #60)
> I understand your frustration, but this change was checked in for four
> months before someone reported it.
> 
> If you are choosing to use the the rapid releases of Firefox in your
> organization, it is imperative that you test with at least early Beta and
> Aurora and hopefully even nightly.
> 
> If you aren't willing to do that kind of testing, you should be sticking
> with the ESR so that things like this don't surprise you.

Sorry Mike but your expectations here are completely unrealistic. Do you really think IT managers have time to test every beta you put out to make sure you don't just gut important pieces for seemingly no reason at all?

If this is truly what the folks at Mozilla expect then they can also expect to lose many users. How do you remove something without any viable replacement. Updates are supposed to improve upon software, not remove features arbitrarily.

Comment 68

[Mike Kaply [:mkaply]]

> Sorry Mike but your expectations here are completely unrealistic. Do you really think IT managers have time to test every beta you put out to make sure you don't just gut important pieces for seemingly no reason at all?

I'll let someone else address the reasons they were removed, but as far as testing goes, if you don't have the ability to do some level of testing before Firefox is released (preferably beta and Aurora), you should be using the ESR.

I agree with you that this situation is frustrating. Better notice could have been given that this change was coming. I don't think it was understood how impactful this change was going to be.

Comment 69

[Tory Dombrowski]

I am an IT Manager of a company of roughly 90 users.
I recommend Firefox to my users.
I developed our intranet sites that use the file:// links.

I do have control to deploy ESR and may do that moving forward as it makes sense in my circumstances.
Previously I was not aware of ESR so I have a lot of regular plain old Firefox deployed.

We are struggling with this as users get automatically updated to the latest version.
I am willing to help test, but not sure where to start.

I have just tried the extensions both publicly available under the same name as the one listed in this thread and the one listed at the top of this thread and neither seem to work, but perhaps I am not sure how to use it properly.

Comment 70

[Bobby Holley (:bholley)]

(In reply to torbs from comment #69)
> I have just tried the extensions both publicly available under the same name
> as the one listed in this thread and the one listed at the top of this
> thread and neither seem to work, but perhaps I am not sure how to use it
> properly.

Is this the one you tried https://addons.mozilla.org/en-US/firefox/addon/caps-fileuri/

If it doesn't work - can you post the relevant parts of your preferences file (the parts with capability.policy)?

Comment 71

[Maxime Poulin]

Hello!
I have the same problem, tried to install the extension, which is not working for me either.

Here's my pref settings

user_pref("network.protocol-handler.expose.file", false);
user_pref("network.protocol-handler.external.file", true);
user_pref("capability.policy.default.checkloaduri.enabled", "allAccess");
user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.sites", "https://ctm.canam.ws https://ctmfiles.canam.ws");
user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");

We have more than 300 users that have this problem for the moment. A quick solution or a quick fix to that extension would be greatly appreciated.

Comment 72

[Maxime Poulin]

(In reply to Maxime Poulin from comment #71)
> Hello!
> I have the same problem, tried to install the extension, which is not
> working for me either.
> 
> Here's my pref settings
> 
> user_pref("network.protocol-handler.expose.file", false);
> user_pref("network.protocol-handler.external.file", true);
> user_pref("capability.policy.default.checkloaduri.enabled", "allAccess");
> user_pref("capability.policy.policynames", "localfilelinks");
> user_pref("capability.policy.localfilelinks.sites", "https://ctm.canam.ws
> https://ctmfiles.canam.ws");
> user_pref("capability.policy.localfilelinks.checkloaduri.enabled",
> "allAccess");
> 
> We have more than 300 users that have this problem for the moment. A quick
> solution or a quick fix to that extension would be greatly appreciated.

Just to make sure, the links are dynamically created after an ajax request, using the knockout framework...

Comment 73

[Maxime Poulin]

The extension is working, but the user must use the right click... Could this improved so that a natural left click would work too? I'm not familiar with the extension SDK at all...

Comment 74

[Tory Dombrowski]

(In reply to Bobby Holley (:bholley) from comment #70)
> Is this the one you tried
> https://addons.mozilla.org/en-US/firefox/addon/caps-fileuri/
> 
> If it doesn't work - can you post the relevant parts of your preferences
> file (the parts with capability.policy)?

Hi I just removed whatever I had installed restarted Firefox and then installed the one you just linked.  Still links on the intranet sites don't work.

Here are the settings relevant (sorry I just copied them out of the config and didn't format as others)
> capability.policy.localfilelinks.checkloaduri.enabled;allAccess
> capability.policy.localfilelinks.sites;http://mtl http://test http://itd http://itrack http://rpt http://reports http://task http://itl http://task http://task_beta
> capability.policy.policynames;localfilelinks

Comment 75

[Jeron]

I have had no success with the caps-fileuri 0.2 extension.

In my environment, the local files are used for local images.

Error:
Security Error: Content at http://www.domain1.com/msgframe.php may not load or link to file:///c:/images/icon.png.
 

user.js valid on all previous FF versions>

user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.sites", "http://www.domain1.com http://www.domain2.com http://www.domain5.com");
user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");

Comment 76

[Boris Zbarsky [:bzbarsky]]

The extension only handles links, not all URI loads.  :(

In particular, not images, not scripted location sets, not stylesheets, not file:// scripts, etc.

Comment 77

[Mark Hill]

I'm just chiming in as yet another corporate user affected by the file:// local links issue.  Firefox has been the only browser we support on our intranet.  Our intranet apps and wiki not only link to local documents, but we also display images from local links (which the addon does not address, as I understand it).

I have directed the IT department to freeze Firefox at the last ESR while the software developers cross their fingers and
- evaluate the feasibility of transitioning to IE (yuck)
- implement http proxies so we can replace existing local links
- don't use local links for anything new!

Comment 78

[Bobby Holley (:bholley)]

Just discussed this with bz and jst - we're going to add C++ support for this back in (file:// URIs only). I'll write up a patch.

Comment 79

[Paul Smith]

I have had limited success with the caps-fileuri 0.2 extension.  I managed to get it to work on my workstation.  I have been unable to get it to work for two other users.  Besides installing the https://addons.mozilla.org/en-US/firefox/addon/caps-fileuri/ extension, are there other steps need to make it work!  It is very frustrating that we are getting inconsistent results with the install/setup of this extension.  What do you need to debug the issue?

Comment 80

[Lukas Blakk [:lsblakk] use ?needinfo]

(In reply to Bobby Holley (:bholley) from comment #78)
> Just discussed this with bz and jst - we're going to add C++ support for
> this back in (file:// URIs only). I'll write up a patch.

Would love to get something of this nature tested in FF30.  As we have already gone ahead with a FF29.0.1 it looks like we have two options here for the next 4.5 weeks until that fix might ship:  Using ESR builds for organizations (https://www.mozilla.org/en-US/firefox/organizations/) and the extension for many of the average user needs.

Comment 81

[Bobby Holley (:bholley)]

(In reply to Paul Smith from comment #79)
> I have had limited success with the caps-fileuri 0.2 extension.  I managed
> to get it to work on my workstation.  I have been unable to get it to work
> for two other users.  Besides installing the
> https://addons.mozilla.org/en-US/firefox/addon/caps-fileuri/ extension, are
> there other steps need to make it work!  It is very frustrating that we are
> getting inconsistent results with the install/setup of this extension.  What
> do you need to debug the issue?

Hi Paul,

As a debugging step, try whitelisting people.mozilla.org, and visting http://people.mozilla.org/~bholley/testcases/fileuri.html . Can you get the file links to open, both on the machine that works and on the machine that doesn't?

Comment 82

[Dante Ortolani]

Hello, We have a web-based intranet application using many links files. This is a huge problem for us and our 40 users. I hope you can fix this problem soon!
Cheers
LucaS

Comment 83

[Paul Smith]

(In reply to Bobby Holley (:bholley) from comment #81)
> (In reply to Paul Smith from comment #79)
> > I have had limited success with the caps-fileuri 0.2 extension.  I managed
> > to get it to work on my workstation.  I have been unable to get it to work
> > for two other users.  Besides installing the
> > https://addons.mozilla.org/en-US/firefox/addon/caps-fileuri/ extension, are
> > there other steps need to make it work!  It is very frustrating that we are
> > getting inconsistent results with the install/setup of this extension.  What
> > do you need to debug the issue?
> 
> Hi Paul,
> 
> As a debugging step, try whitelisting people.mozilla.org, and visting
> http://people.mozilla.org/~bholley/testcases/fileuri.html . Can you get the
> file links to open, both on the machine that works and on the machine that
> doesn't?

I finally determined why some users were working and others were not.  It had to do with  the following line in the prefs.js file.

user_pref("capability.policy.localfilelinks.sites", "file://///idserver ");

The trailing space at the end of the file://///idserver was causing what appeared to be a parsing issue.  I would have thought that the caps-fileuri 0.2 extension would have been able to parse the data better but apparently not.  The issue has frustrated me to no end this week as I have spent too many hours attempting to get Firefox 29 working again.  I would guess others are in a similar situation.  My final solution was to back users off of this version and monitor the situation for a future fix.

Comment 84

[Bobby Holley (:bholley)]

(In reply to Paul Smith from comment #83)
> I finally determined why some users were working and others were not.  It
> had to do with  the following line in the prefs.js file.
> 
> user_pref("capability.policy.localfilelinks.sites", "file://///idserver ");
> 
> The trailing space at the end of the file://///idserver was causing what
> appeared to be a parsing issue.  I would have thought that the caps-fileuri
> 0.2 extension would have been able to parse the data better but apparently
> not.

Thanks for figuring that out! I've uploaded a fix. Can you give it a try?

https://addons.mozilla.org/en-US/firefox/addon/caps-fileuri/versions/?page=1#version-0.3

> The issue has frustrated me to no end this week as I have spent too
> many hours attempting to get Firefox 29 working again.  I would guess others
> are in a similar situation.  My final solution was to back users off of this
> version and monitor the situation for a future fix.

I'm working on a built-in fix for Firefox 30. Sorry for the trouble!

Comment 85

[Bobby Holley (:bholley)]

Attachment: Part 1 - Clean up some silly stuff surrounding prefs in CAPS. v1

Comment 86

[Bobby Holley (:bholley)]

Attachment: Part 2 - Allow access to file:// URIs from pref-whitelisted sites. v1

Comment 87

[Thomas Koch]

Bobby,
I don't have file links (like "file://///idserver") in my prefs.js. It's like this:

user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");
user_pref("capability.policy.localfilelinks.sites", "http://intranet.mydomain.net https://extranet.mydomain.net");
user_pref("capability.policy.policynames", "localfilelinks");

I get the following errors (with caps-fileuri v0.2 installed):
1. Sicherheitsfehler: Inhalt auf http://intranet.mydomain.net/myapp.php darf
file:///K:/Anwendungen/Test-Anhang.txt nicht laden oder verlinken.

2. Fehler: Error: Access to 'file:///K:/Anwendungen/Test-Anhang.txt' from script denied

Thanks for fixing this!
Thomas

Comment 88

[Bobby Holley (:bholley)]

Hi Thomas, can you try v0.3 linked in comment 84?

Note that I've attached patches to restore this functionality in the platform, which should land on all branches in a couple of days. After that, you should be able to get this functionality by downloading Firefox Beta. I'll let you know when it's ready.

Comment 89

[Thomas Koch]

I installed v0.3 and tried the nearly same scenario with exactly the same errors as in comment 87.
The only difference is the calling URL: "http://intranet.mydomain.net/app/wl/article.php?current=1".

Comment 90

[Paul Smith]

(In reply to Bobby Holley (:bholley) from comment #84)
> (In reply to Paul Smith from comment #83)
> > I finally determined why some users were working and others were not.  It
> > had to do with  the following line in the prefs.js file.
> > 
> > user_pref("capability.policy.localfilelinks.sites", "file://///idserver ");
> > 
> > The trailing space at the end of the file://///idserver was causing what
> > appeared to be a parsing issue.  I would have thought that the caps-fileuri
> > 0.2 extension would have been able to parse the data better but apparently
> > not.
> 
> Thanks for figuring that out! I've uploaded a fix. Can you give it a try?
> 
> https://addons.mozilla.org/en-US/firefox/addon/caps-fileuri/versions/
> ?page=1#version-0.3
> 
> > The issue has frustrated me to no end this week as I have spent too
> > many hours attempting to get Firefox 29 working again.  I would guess others
> > are in a similar situation.  My final solution was to back users off of this
> > version and monitor the situation for a future fix.
> 
> I'm working on a built-in fix for Firefox 30. Sorry for the trouble!

the latest version fixes the issue with extra spaces.

Comment 91

[André G.]

(In reply to Bobby Holley (:bholley) from comment #54)
> (In reply to André G. from comment #51)
> > Thanks a lot for your work, but even with the new extension some things are
> > not entirely working like before. I have a JSF2 application and as soon as I
> > am partially updating a part of my page the local links in the affected part
> > of the page stop working again. This was working perfectly fine with older
> > versions of Firefox.
> 
> I believe v0.2 should fix your problem.

It's working now. In version 0.3 as well. Thanks!

Another problem arose though: My links seem to ignore "target='_blank'". I know this is a not well liked feature in the web community, but sometimes it is necessary.

Comment 92

[graefrath]

Hey, I just installed the caps-fileuri 0.3 addon, but now I don't get any console.log output in Firebug anymore. WTF?

Comment 93

[Bobby Holley (:bholley)]

(In reply to André G. from comment #91)
> Another problem arose though: My links seem to ignore "target='_blank'". I
> know this is a not well liked feature in the web community, but sometimes it
> is necessary.

Given that we're adding support for this back to the platform, I think it's probably not worth implementing that in the stopgap addon.

(In reply to graefrath from comment #92)
> Hey, I just installed the caps-fileuri 0.3 addon, but now I don't get any
> console.log output in Firebug anymore. WTF?

I can't reproduce this.

Comment 94

[tsuchim]

(In reply to Boris Zbarsky [:bz] from comment #53)
> > This permits to access to local files via link at website on all of domains, right?
> 
> No, it reads the prefs.  See the source, please.

Thank you for your reply. I understand the plugin behavior. And I'm sorry for missing link to its source.
However I'm wonder it is not easy to use Firefox in safety, if we must see the source code whenever security critical modification.

Comment 95

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8419016 [details] [diff] [review]
Part 1 - Clean up some silly stuff surrounding prefs in CAPS. v1

r=me

Comment 96

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8419017 [details] [diff] [review]
Part 2 - Allow access to file:// URIs from pref-whitelisted sites. v1

Hrmp.  So the old code allowed any combination of ' ' and ',' as separators, hence we can't just use nsCharSeparatedTokenizer?  That's annoying.  :(

>+    for (uint32_t base = SkipPast(policies, 0, IsWhitespaceOrComma), bound = 0;
>+         base < policies.Length(); base = SkipPast(policies, bound, IsWhitespaceOrComma))

I think a linebreak after ';' there would help readability.

>+        NS_LossyConvertUTF16toASCII policyName(Substring(policies, base, bound - base));

Why did we bother with GetString() instead of GetCString() then?  Also, does this end up matching the behavior of the old code if someone uses raw UTF-8 in the policy name, unlikely as that is?

>+        // Figure out if this policy allows checkURI. If not, we can skip it.

"allows linking to file:// URIs", right?

>+nsScriptSecurityManager::AddSitesToFileURIWhitelist(const nsString& aSiteList)

This, on the other hand, should probably use nsWhitespaceTokenizer instead of reinventing it.

You probably want to remove the commented-out pushPrefEnv bit in the test.

r=me

Comment 97

[Bobby Holley (:bholley)]

(In reply to Boris Zbarsky [:bz] from comment #96)
> Comment on attachment 8419017 [details] [diff] [review]
> Part 2 - Allow access to file:// URIs from pref-whitelisted sites. v1
> 
> Hrmp.  So the old code allowed any combination of ' ' and ',' as separators,
> hence we can't just use nsCharSeparatedTokenizer?  That's annoying.  :(

Yeah :-( http://mxr.mozilla.org/mozilla-esr24/source/caps/src/nsScriptSecurityManager.cpp#2512

> >+    for (uint32_t base = SkipPast(policies, 0, IsWhitespaceOrComma), bound = 0;
> >+         base < policies.Length(); base = SkipPast(policies, bound, IsWhitespaceOrComma))
> 
> I think a linebreak after ';' there would help readability.

Ok.

> Why did we bother with GetString() instead of GetCString() then?  Also, does
> this end up matching the behavior of the old code if someone uses raw UTF-8
> in the policy name, unlikely as that is?

Looks like the old code actually just does GetCString, even for the domains (which is technically wrong, but whatever). I'll switch to that. I'm also going to switch the predicates to templates (instead of function pointers) while I'm at it, so that this stuff has a better chance of being inlined.
 
> >+        // Figure out if this policy allows checkURI. If not, we can skip it.
> 
> "allows linking to file:// URIs", right?

Fixed.

> 
> >+nsScriptSecurityManager::AddSitesToFileURIWhitelist(const nsString& aSiteList)
> 
> This, on the other hand, should probably use nsWhitespaceTokenizer instead
> of reinventing it.

I'd actually argue that we should maintain local consistency here. We already have to do this whole SkipPast/SkipUntil pattern for the IsWhitespaceOrComma above, and anyone trying to audit or grok this code is going to have an easier time if the two for loops work the exact same way. Otherwise, they have to wetware simulate AND look up the behavior and quirks of nsWhitespaceTokenizer.

Is that ok?

> You probably want to remove the commented-out pushPrefEnv bit in the test.

Fixed.

Comment 98

[Bobby Holley (:bholley)]

Try push with comments addressed, assuming bz is ok with the above:

https://tbpl.mozilla.org/?tree=Try&rev=c30abf62ce03

Comment 99

[Boris Zbarsky [:bzbarsky]]

> Is that ok?

Alright, I guess.

Comment 100

[garydean]

i am experiencing problems with version 0.3. it does not work on any of the computers on my network.

most are using ubuntu 12.04, but a couple are using 14.04. 

version 0.1 works fine.

sorry, no other diagnostic info.

Comment 101

[Bobby Holley (:bholley)]

Green with a followup:

https://tbpl.mozilla.org/?tree=Try&rev=c30abf62ce03
https://tbpl.mozilla.org/?tree=Try&rev=3439e4cc4cc3

Pushed to inbound:

remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/9899ea7e3a32
remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/96dbf1ff169c

Comment 102

[Thomas Noirez]

Hello,

this issue has been created to resolve the Firefox Bug 995943 - local (file://) links don't work with firefox 29.

Not the developpement of a plugin, please don't mix the problems, create another issue

We have to check if we continue with Firefox

thanks

Comment 103

[Carsten Book [:Tomcat]]

hey Bobby, sorry had to backout this change, seems its created a Unexpected Pass on OSX https://tbpl.mozilla.org/php/getParsedLog.php?id=39337620&tree=Mozilla-Inbound

Comment 104

[Bobby Holley (:bholley)]

(In reply to Carsten Book [:Tomcat] from comment #103)
> hey Bobby, sorry had to backout this change, seems its created a Unexpected
> Pass on OSX
> https://tbpl.mozilla.org/php/getParsedLog.php?id=39337620&tree=Mozilla-
> Inbound

Do we really need to back out changes when the number of expected assertions goes down?

Anyway, removed the assertion annotation and relanded:

remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/75c4a4809761
remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/86ce795b95c4

Comment 105

[Thomas Koch]

I've just installed FF 29.0.1 but the same problem. I can not open my file on network shares.
Please notice my comment #89 (https://bugzilla.mozilla.org/show_bug.cgi?id=995943#c89).

If I can assist in fixing this problem, please let me know!

Our intranet is almost USELESS when we cannot open our file:// URLs.

PLEASE fix this asap!

Comment 106

[Bobby Holley (:bholley)]

(In reply to Thomas Koch from comment #105)
> I've just installed FF 29.0.1 but the same problem.

There is unlikely to be a fix for this in FF29. But it should land in FF30 in a couple of days.

Comment 107

[Thomas Koch]

The point is: caps-fileuri 0.3 doesn't work for me! Help, please!

Comment 108

[Bobby Holley (:bholley)]

(In reply to Thomas Koch from comment #107)
> The point is: caps-fileuri 0.3 doesn't work for me! Help, please!

If you want to help debug the addon and figure out why it's not working, by all means please do!

Otherwise, if you wait a day or two, this will be fixed (without the need for an addon) in Firefox Beta, at which point you can switch to that (or to ESR).

Comment 109

[Jamie Jones]

Neither the extension nor FF30b3 properly handle URI in objects:

<object data="file:///c|/song.mp3" type="audio/x-mpeg" width="200" height="20"></object>

Comment 111

[Peter Huber]

The caps-fileuri extension seems to ignore the content type in a URI.

A link like this:
<a href="file:///X:/doc/test.xhtml" type="startapp/notepad">
is opened in a new tab in FF, even though for "startapp/notepad" an external application is defined in mimeTypes.rdf.

This worked in FF version 28.

Stupid question: Why was it again that a feature that worked perfectly and that people obviously need and want has been removed from FireFox?

Comment 112

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/75c4a4809761
https://hg.mozilla.org/mozilla-central/rev/86ce795b95c4

Comment 113

[Bobby Holley (:bholley)]

Hi Everyone,

This should be fixed (without the need for an add-on) on mozilla-central. I'd like to backport it so that it ships in Tuesday's Beta, but I want to confirm that it works for everyone first. As such, it would be extremely helpful if people could test these builds within the next 12 hours and confirm whether or not the problem is fixed.

Given that this is a bleeding-edge build, I'd suggest making a backup of your profile data before running it.

Windows: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32-pgo/1399905032/firefox-32.0a1.en-US.win32.zip
Mac OSX: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-macosx64/1399894924/firefox-32.0a1.en-US.mac.dmg
Linux: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-linux-pgo/1399905032/firefox-32.0a1.en-US.linux-i686.tar.bz2
Linux64: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-linux64-pgo/1399905032/firefox-32.0a1.en-US.linux-x86_64.tar.bz2

Comment 114

[Mark Gunnett]

I tested, and it works for what I use it for. I made sure to disable the Caps Addon first before testing on the nightly.

Comment 115

[Bobby Holley (:bholley)]

Comment on attachment 8419017 [details] [diff] [review]
Part 2 - Allow access to file:// URIs from pref-whitelisted sites. v1

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 913734 (shipped in FF29)
User impact if declined: Enterprise configurations with CAPS-style prefs to allow file:// URIs for certain domains won't work.
Testing completed (on m-c, etc.): Landed to m-c. One positive user report.
Risk to taking this patch (and alternatives if risky): Low risk.
String or IDL/UUID changes made by this patch: None.

Comment 116

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 8419017 [details] [diff] [review]
Part 2 - Allow access to file:// URIs from pref-whitelisted sites. v1

It's early enough in Beta that we can take this and, if errors abound, pull it out again before shipping.  I'll flag this for release notes too because we'll want to mention it's fixed (or not).

Comment 117

[Bobby Holley (:bholley)]

remote:   https://hg.mozilla.org/releases/mozilla-aurora/rev/a5e59def8c4a
remote:   https://hg.mozilla.org/releases/mozilla-aurora/rev/68256ee0ec48

remote:   https://hg.mozilla.org/releases/mozilla-beta/rev/c1b7c8d03129
remote:   https://hg.mozilla.org/releases/mozilla-beta/rev/5b3bfd0a529a

All - This should now be in the Beta released tomorrow. If you want to wait and give feedback on that instead of the builds in comment 113, that's fine too.

Comment 118

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/c1b7c8d03129
https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/5b3bfd0a529a

Comment 119

[Bobby Holley (:bholley)]

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #118)
> https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/c1b7c8d03129
> https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/5b3bfd0a529a

Note that this doesn't really matter for b2g, but doesn't hurt either.

Comment 120

[mozillafan]

(In reply to Bobby Holley (:bholley) from comment #113)

> Windows:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-
> central-win32-pgo/1399905032/firefox-32.0a1.en-US.win32.zip

Works fine with our Wiki. Now waiting for the official release...
Thanks!

Comment 121

[Robert Geißler]

(In reply to Bobby Holley (:bholley) from comment #113)
> Windows:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-
> central-win32-pgo/1399905032/firefox-32.0a1.en-US.win32.zip

Works as expected with this version.

Comment 122

[Thomas Koch]

I cannot get this to work:
Windows: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32-pgo/1399905032/firefox-32.0a1.en-US.win32.zip

I only get "Server not found" errors when starting FF or trying to open URLs. Originally I run a German localization of FF.

Things I've already tried:
1. I've copied the Archive Content into C:\Program Files (x86)\Mozilla Firefox
2. I've replaced the Content of C:\Program Files (x86)\Mozilla Firefox with the Archive content
3. I've tried all of https://support.mozilla.org/en-US/kb/server-not-found-connection-problem?redirectlocale=en-US&redirectslug=Server+not+found

Please help.
Thomas

Comment 123

[Maxime Poulin]

(In reply to Bobby Holley (:bholley) from comment #113)
> Hi Everyone,
> 
> This should be fixed (without the need for an add-on) on mozilla-central.
> I'd like to backport it so that it ships in Tuesday's Beta, but I want to
> confirm that it works for everyone first. As such, it would be extremely
> helpful if people could test these builds within the next 12 hours and
> confirm whether or not the problem is fixed.
> 
> Given that this is a bleeding-edge build, I'd suggest making a backup of
> your profile data before running it.
> 
> Windows:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-
> central-win32-pgo/1399905032/firefox-32.0a1.en-US.win32.zip


I confirm that the Windows version is working well too, for our needs at least. Thanks a lot for your work, it's really appreciated!

Comment 124

[Guillaume]

We've tested the nightly build on our intranet with local files url, and all works fine!

Thx for all your efforts, it is much appreciated!

(In reply to Maxime Poulin from comment #123)
> (In reply to Bobby Holley (:bholley) from comment #113)
> > Hi Everyone,
> > 
> > This should be fixed (without the need for an add-on) on mozilla-central.
> > I'd like to backport it so that it ships in Tuesday's Beta, but I want to
> > confirm that it works for everyone first. As such, it would be extremely
> > helpful if people could test these builds within the next 12 hours and
> > confirm whether or not the problem is fixed.

Comment 125

[garydean]

is there a linux build available? i can't seem to find it.

Comment 126

[garydean]

(In reply to garydean from comment #125)
> is there a linux build available? i can't seem to find it.

found. ignore.

Comment 127

[Mark Hill]

30.0b3 for 32 bit Windows installed but crashed on launch, so I can't give any feedback about this issue.

Comment 128

[Kohei Yoshino]

https://twitter.com/FxSiteCompat/status/466283639961964545

Comment 129

[Kohei Yoshino]

https://developer.mozilla.org/en-US/Firefox/Releases/29/Site_Compatibility

Comment 130

[Bobby Holley (:bholley)]

This should now be fixed in the latest Beta. I'd encourage everyone to switch to Firefox Beta or Firefox ESR for the remainder of this cycle.

Comment 131

[Catalin Varga [QA][:VarCat]]

Hi I've tried reproducing the issue in order to verify the bug but I didn't manage.
Can you offer me more information of the way the network sharing is done on your side?
I've done a simple windows folder sharing used your configuration:

lockPref("network.protocol-handler.expose.file", false);
lockPref("network.protocol-handler.external.file", true);
lockPref("capability.policy.policynames", "localfilelinks");
lockPref("capability.policy.localfilelinks.sites", "list of hostnames and ips");
lockPref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");

but I manage to open the shared files.

Comment 132

[Robert Geißler]

Hi,

which information do you need?
It's a mediawiki installation with direct links to files on network shares in the articles, for example:
file:///N:/somefolder/somefile.pdf

the hostnames and ips of our wiki servers are defined in the capability.policy.localfilelinks.sites entry.

In the firefox default configuration, the files are not opend for security reasons - with the configuration in my first post, the files are opend with firefox versions before 29.

Comment 133

[Chris]

I have updated to Firefox 30b4 and am still having issues.  We have a link that looks like this: 

file://///server1/share$

The link is accessed from https://webserver.local and we have the following lines added to the prefs.js file:

user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");
user_pref("capability.policy.localfilelinks.sites", "https://webserver.local");
user_pref("capability.policy.policynames", "localfilelinks");

In Firefox 28, the setup works.  I've read thru most of the comments above and we couldn't get it to work in FF29 with the addon nor is it working in FF30b4.  Based on the responses above, it sounds like the issue was fixed but we are still having trouble.  Did I miss something?

Comment 134

[Boris Zbarsky [:bzbarsky]]

Chris, are you willing to try some nightlies to see when things stopped working for you?  In particular, do things work for you in the nightly in http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/12/2013-12-14-03-02-04-mozilla-central/ ?

Comment 135

[Chris]

Sorry, was just getting ready to update the case.  I discovered it was an addon that was causing the issue...should have tried disabling all of them first.  The bug is fixed.  Much thanks for everyone's work on this!

Comment 136

[l2jdrlecter]

I don't know if it would be necessary to create a new ticket, but we've got an organization centered application with CKeditor based rich text editor, and FF29 took away the clipboard access CAP. Nightly 32.0a1 ain't solving it as of yet. We've got to stick with, or downgrade to FF28. Anybody could shed us some light?

Comment 137

[Kohei Yoshino]

Clipboard access has not been restored with Firefox 30. That's Bug 1004260.

Comment 138

[Catalin Varga [QA][:VarCat]]

Verified as fixed using the following environment:

FF Beta 30.0b5
Build Id: 20140515140857
Os: Win 7 x64, Ubuntu 14.04 x64, Mac Os X 10.7.5

Comment 139

[Catalin Varga [QA][:VarCat]]

Verified as fixed using the following environment:

FF Aurora 31
Build Id: 20140521004003
FF Nightly 32
Build Id: 20140521030200
Os: Win 7 x64, Ubuntu 14.04 x64, Mac Os X 10.7.5

Comment 140

[Alan]

Hello

I have a similar situation to Chris.  My local link was working on FF 24.  I upgraded it to FF 30 tonight and its broke again. I have no extensions installed.

file://///my.domain/XXX/XXXXXX/XXXXXXXXX/testing.txt

user.js

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

Thank you

Comment 141

[u279076]

(In reply to Alan from comment #140)
> I have a similar situation to Chris.  My local link was working on FF 24.  I
> upgraded it to FF 30 tonight and its broke again. I have no extensions
> installed.

Please file a new bug and provide steps to reproduce, including details about how your environment is configured so that we may investigate your specific usecase. This bug report has been closed.

Comment 142

[Kohei Yoshino]

One Linux user is reporting that this is not fixed yet. Alan, what's your platform?
https://twitter.com/purecaldari/status/476727393374453762

Comment 143

[Alan]

(In reply to Kohei Yoshino [:kohei] from comment #142)
> One Linux user is reporting that this is not fixed yet. Alan, what's your
> platform?
> https://twitter.com/purecaldari/status/476727393374453762

Windows 7 and Windows 8 x64

Comment 144

[Giorgio Maone [:ma1]]

This work-around fails to properly emulate the policy.sites syntax for hostnames only (without protocol).
Specifically, up to ESR 24 you could specify

user_pref("capability.policy.mypolicy.sites", "mozilla.org");

and have the policy apply to www.mozilla.org.

Current implementation (Gecko 30 and above) ignores the above syntax (just one hostname), while having a hostname together to with any other entry causes the following error to be spit by the console:

"Unable to add site to file:// URI whitelist: mozilla.org"

Steps to reproduce:

1. Open a chrome-enabled Scratchpad in latest Nightly
2. Open the browser console and watch for chrome-generated error messages
3. Execute the following code in Browser context:
// BEGIN SNIPPET
function p(n, v) Services.prefs.setCharPref(n, v);

p("capability.policy.policynames", "lf");
p("capability.policy.lf.checkloaduri.enabled", "allAccess");
p("capability.policy.lf.sites", "mozilla.com mozilla.org");
content.open("http://www.mozilla.org").addEventListener("load", function(ev) {
  ev.currentTarget.document.body.innerHTML ="<iframe src=file:///></iframe>"
}, false)

// END SNIPPET

* Expected result: no error message is shown in the console as a result of running the code from step #3

* Actual result: the browser console spits out
  Unable to to add site to file:// URI whitelist: mozilla.com
  Unable to to add site to file:// URI whitelist: mozilla.org
  Security Error: Content at http://www.mozilla.org/en-US/ may not load or link to file:///.

As a reference, running the same code in Firefox ESR 24.x doesn't cause any error, and if file:/// is replaced with an actual local filesystem resource it gets loaded in the iframe.

Comment 145

[Bobby Holley (:bholley)]

Giorgio - This bug is closed, and reopening it will confuse release tracking. Please file a new one and mark it as blocking this one.

Comment 146

[u279076]

Setting this back to verified fixed since that's what it was before.

Comment 147

[garydean]

Comment on attachment 8415447 [details]
caps-fileuri.xpi (v3)

resolved

Comment 148

[denzilsearle]

Forgive me if the this is the wrong place to ask, but I can't find an answer elsewhere. Is this supposed to be fixed in FF30? Statements above imply that it is, yet I was told on support.mozilla.org that it "may be included in the next ESR 31". Links on our internal wiki still don't work with FF30 and the add-on doesn't work either. Has it been restored in 31? Should we switch to the ESR?

Comment 149

[Sylvestre Ledru [:Sylvestre]]

(In reply to denzilsearle from comment #148)
> Is this supposed to be fixed in FF30? 
Yes, it is. ESR 31 will contain the fix.

Comment 150

[Emanuel Hoogeveen [:ehoogeveen]]

So if things aren't working for you on 30 or 31 (which the ESR will be based on) you may need to adjust something on your end or file a new bug to figure out what's up. Note that this bug only restored a small part of the former behavior.

Comment 151

[exp_support]

this is not officially fix, I have tested v30,31, 32

Comment 152

[Mike Kaply [:mkaply]]

exp_support:


Please open a new bug if you experience a problem, but first check bug 1061136 to see if that is what you are experiencing. Also the default check loadURI policy is not implemented. You'll have to use the CCK2 to get that.

Comment 153

[tstorm317]

Cannot get this to work on Windows 8 systems.  capability.policy.localfilelinks.sites does not get loaded.

user_pref("capability.policy.default.checkloaduri.enabled", "allAccess");
user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.sites", "http://10.1.1.115", "http://localhost");
user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");
user_pref("capability.policy.trustable.sites", "http://10.1.1.115");
user_pref("capability.policy.maonoscript.javascript.enabled", "allAccess");

Comment 154

[Thomas Koch]

I think you should use it like this:
user_pref("capability.policy.localfilelinks.sites","https://site1.domain.tld http://site2.domain.tld");

Comment 155

[tstorm317]

No that doesn't seem to work either. Forgot to mention that things work fine (both methods) in a Windows 7 environment.  It's the move to Windows 8 that seems to break it.

Comment 156

[Ditta]

Just perfect:
* First this feature, many of us really need, was removed without notice.
* The argument for doing this is one expected from MS or Apple (nonsense in other words), as it does not pose any security risk to any normal user. You have to manually edit Prefs.js to enable local file links and this is nothing which happens by accident.
* There is no alternative, no transition provided in the first place.
* The add-on, which is really a poor replacement, does not seem to work on Windows 8. What about Windows 10? Who knows? Happy planning of you IT infrastructure.
* And now it became clear it will not work for long in any case. This add-on is not signed and from FF42 on unsigned add-ons will not work anymore. Just perfect.

I must say that from the time when FF started the rapid release cycles I was continuously dragged away and offended by the "improvements" (FSync with own server to mention another master piece). I really loved FF and I am using it for ages now. But I am sorry to say that it is time to move on now. I really wish the FF community to find back to the spirit they had once.

Comment 157

[Kohei Yoshino]

(In reply to Ditta from comment #156)
> * First this feature, many of us really need, was removed without notice.

This has already been documented, see my Comment 129.

Comment 158

[Bobby Holley (:bholley)]

(In reply to Ditta from comment #156)
> * And now it became clear it will not work for long in any case. This add-on
> is not signed and from FF42 on unsigned add-ons will not work anymore. Just
> perfect.

This functionality was restored to to the platform in this bug, without the need for the add-on. Can you clarify whether the current behavior is causing problems for you? I believe it should all Just Work.

Comment 159

[Ditta]

It works. Insofar my post was off-topic and I want to apologize for this. It was a culmination of disappointments with recent FF developments, which went off at the wrong place. To abandon FF is a personal decision and should not be discussed here. Sorry for this. I just feel sad about it.

Comment 160

[dominicafonso]

the behavior described in the original bug report is being experienced as of ff48

Comment 161

[evan.milefchik]

(In reply to dominicafonso from comment #160)
> the behavior described in the original bug report is being experienced as of
> ff48

It's not the same bug, as far as I can tell, but a new bug that also affects local file links. The behavior I'm getting (happened on 4 different computers so far) is that the file opens, but it downloads a copy and opens as a read-only, instead of opening it up directly as it should. One other odd thing I noticed is that if I told Firefox in the Applications settings to open PDFs in Adobe Reader instead of the in-browser plug-in it still opens in the plug-in. So it would seem that the bug is causing Firefox to ignore multiple user settings.

So far I've gotten past this by deleting the user's profile folder (Users/username/appdata/roaming/mozilla/firefox/profiles) and deleting the profile entry in the profiles.ini config file in the parent folder. Then reopen Firefox and create a new profile. Add local file link access back to the users prefs file and it works again.

Comment 162

[Guillaume]

Broken again since Firefox 51. Worked well in Firefox 50.1.0 and all recent versions for the past two years.

Platform: Windows 10, 64-bit, FF51 32-bit.

Behavior example:

Links that point to mp3 playlists (m3u) in local file system, or in network resources, are not properly passed to external application in FF51.

Example of url that worked well in all prior FF versions and that stopped working in FF51
<a href="file:\\c:\cdaudio2\Gameboy Gamegirl - Golden Ghetto EP/Gameboy Gamegirl - Golden Ghetto EP.m3u">Play!</a>

In Firefox 50.1.0, it passes the following to the external mp3 player, and it works
C:\cdaudio2\Gameboy Gamegirl - Golden Ghetto EP\02 fruit salad.mp3

Since Firefox 51,  it passes the following to the external mp3 player, and it DOES NOT works
C:\Users\IEUser\AppData\Local\Temp\02 fruit salad.mp3

A permanent fix for this would be appreciated, thx.

Comment 163

[Boris Zbarsky [:bzbarsky]]

Guillaume, that sounds like a different issue.  This bug is about clicking on a link like that not working at all.  That is, security policy would deny it, and nothing would be passed to anything.

Your issue is that clicking still works, but a different filename is now passed to the helper app.  Chances are, that was due to out-of-process web renderers (e10s) being enabled for the first time in 51; you should be able to test that by setting any preferences with "remote.autostart" in the name to false in about:config and seeing if the problem goes away.

Please file a separate bug on your issue; it will need to be debugged by totally different people from the ones involved in this bug.  Please make sure to include detailed steps to reproduce, because those people are not familiar with the special prefs that have to be set to make this work at all...

If you cc me on the new bug, I'll make sure the right people see it.

Comment 164

[Guillaume]

(In reply to Boris Zbarsky [:bz] (still a bit busy) from comment #163)
> Guillaume, that sounds like a different issue.  This bug is about clicking
> on a link like that not working at all.  That is, security policy would deny
> it, and nothing would be passed to anything.
> 
> Your issue is that clicking still works, but a different filename is now
> passed to the helper app.  Chances are, that was due to out-of-process web
> renderers (e10s) being enabled for the first time in 51; you should be able
> to test that by setting any preferences with "remote.autostart" in the name
> to false in about:config and seeing if the problem goes away.
> 
> Please file a separate bug on your issue; it will need to be debugged by
> totally different people from the ones involved in this bug.  Please make
> sure to include detailed steps to reproduce, because those people are not
> familiar with the special prefs that have to be set to make this work at
> all...
> 
> If you cc me on the new bug, I'll make sure the right people see it.

Hi Boris, I've followed your suggestion and it works!

One note though the preference I had to change in about:config is called 'browser.tabs.remote.autostart.2' and is listed as being a 'user set' preference that is set by default to 'true'. Just to make sure it is not a preference I've introduced by mistake, I've installed FF51 on a brand new VM, and here is what you'll find under autostart preference:

browser.tabs.remote.autostart    --> default  --> boolean --> false
browser.tabs.remote.autostart.2  --> user set --> boolean --> true

Are theses params supposed to be set by default like that ?? Anyhow, it's only when I manually set browser.tabs.remote.autostart.2 to 'false' that the web app I designed with local links to m3u opening in a external mp3 player start working correctly again!!

Comment 165

[Boris Zbarsky [:bzbarsky]]

> Hi Boris, I've followed your suggestion and it works!

OK, please file that separate bug!

> and is listed as being a 'user set' preference

Sure.  That's because it's set (by some Firefox code) and has no default value initially (which is why it's considered "user set").

> Are theses params supposed to be set by default like that ??

Yes, that's expected.  The name of the preference got changed at some point for various complicated reasons that had to do with people cargo-culting setting it...

Comment 166

[Blake Kaplan (:mrbkap) (inactive)]

Hi Guillaume, your issue looks a lot like bug 1303727. Can you try Firefox 52 (which has the fix for that bug) and see if this has already been fixed?

Comment 167

[Guillaume]

Confirmed!! It works on FF52 without having to adjust either browser.tabs.remote.autostart or browser.tabs.remote.autostart.2 in about:config.

I've tried it on a brand new VM with a fresh FF52 install, and local links, or network links for that matter, work like they used to.

So it really looks like it was bug 130727 after all, which affected FF versions which had e10s turned on (namely FF51)

Thx for your input Blake!

Comment 168

[Guillaume]

Sorry, I meant bug 1303727