From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-3 i686; en-US; m17) Gecko/20000807 BuildID: 2000080712 Placing a link to a URL starting with "file:", within a page that was accessed via a "http:" URL, does not work. Clicking on such a link results in no change to the display. Reproducible: Always Steps to Reproduce: 1. Create a simple webpage, like: "<a href="file:/home/http/html>my file</a>". Call it file.html 2. Place this file somewhere on a webserver so that it can be accessed via a URL starting with http: 3. Make sure the file/directory "/home/http/html" exists on the machine running your browser 4. Load the webpage, and try clicking on the link to the file/directory. Actual Results: After clicking on the link, the display was NOT updated to show the file/directory. Expected Results: Mozilla should have displayed the file/directory given by the URL. I gave this a severity of Major, since a major feature of a web browser is the ability to follow hyperlinks.
Try a <A href="file:///home/http/html">my file</A>. The file:/<path>/<file> don't appear to work. Dunno if thats a bug or not though.
Same bug when testing Gregory's suggestion. Gregory said that "file:/path/file" doesn't work for him - I did not see that problem. The file URLs work fine in Mozilla if you either type the url in the navigation field, in the "Open Web Location" dialog, or if you click on it from a page whose URL itself starts with "file:" (whether with one slash or three). The only time it doesn't appear to work is from pages with "http:" URLs.
I searched bugzilla and can't find a dupe of this so i am marking as new 2000080808
CC'ing myself and Adding one little note: The bug is only present if you dont try to open the link in the same window. Oh and finishing my system info. Sorry for not including this stuff in my last comment. 2000080808-M18/Linux/i386 Redhat 6.9.5 (Pinstripe) kernel 2.2.16
over to Networking
cc andreas, this is a dup I think
I guess this url is caught by the nsScriptSecurityManager. There may be a pref to allow file access from http. I will investigate a little bit.
Yes, it's the ScriptSecurityManager that stops the uri and that is no bug. It's a security feature. Disabling the pref "security.checkloaduri" from all.js should allow you to load the file URI if you really want to do such a bad thing. Marking INVALID.
If this is a security feature, then it is very broken. If I "right click" on the link instead of "left click", then I *am* able to get to the new site. Also, I think it is very bad behavior to refuse to follow a link without giving some indication that there is a reason other than "the browser is broken". Lastly, why is this a security issue? Why shouldn't I be able to have some foreign site direct me to a file on my local machine? This should at least be allowed by default for directories, plain text or html files (ie, anything that doesn't execute, but is merely displayed). I can think of many legitimate uses for this.
i agree with Brad it is a very broken inconsistant "feature" and should be removed or at least off by default
Agreed, it is inconsistent. cc-ing mstoltz for the security issue. What is the intention here? How should it work?
*** This bug has been marked as a duplicate of 40538 ***
Brad, a do you mean "Open Link in New Window?" That's the rough equivalent of opening a new window, typing in the link, and hitting return. I don't think there is any security risk there, based on Mitchell's comments, so the security handling would be different, and consistent with the underlying problem.
I believe there is a security risk in "Open in New Window," roughly the same as clicking on a file: link. There's no reason I see why the same security check should not apply to both.
I was wrong about a previous comment, Referer is inherited, but it still wouldn't go anywhere. What happens in a new window that would be bad?
As an example, on Unix systems, clicking a link like <A HREF="file:///dev/zero"> will cause the browser to start writing an infinitely large file of zeros. There are similar problems on Windows. As another example, pointing an IMG tag at a file:// URL allows an attacker to determine if a file exists at a given location on the user's disk (if the file doesn't exist, the image will have zero size). If you or your company want to be able to use file:// links from http:// pages, set the pref "security.checkloaduri" to false.