180793 - file: URLs should load when clicked

Status: RESOLVED DUPLICATE of bug 122022

(SeaMonkey :: General, defect)

Description

[Christopher Allen]

User-Agent:       Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.1) Gecko/20020915 Debian/1.1-1
Build Identifier: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.1) Gecko/20020915 Debian/1.1-1

I have a page on my web site with various links on it; one of them is a file:
link pointing to a location in my home directory
(file:///home/cpcallen/file.html).  When I click on the link, nothing happens. 
When I choose 'open in new window' or 'open in new tab', nothing happens.  The
only way I can get Mozilla to follow the link is to middle-click on it which
causes it to open in a new tab.

Searching the bugs database, I find that file: URLs are supposed to be broken in
this way, because of some kind of security issue (?!)  I can see that there
could theoretically be some issue if the file was loaded as a result of an embed
(inline image, e.g.) or because of some Javascript, but WHEN I CLICK ON A LINK,
I EXPECT IT TO BE LOADED.  I can see perfectly well it's a local file: URL - I
don't need to be coddled.  (On the other hand, if there are security problems
with auto-loading local files, I don't want to turn off security.checkloadURI
either...)

I see someone's even reported fact that no error message is given in bug 84128 -
but that's not the problem.  The problem is that when I've given the browser a
clear instruction to load the specified URL it fails to do so.

See also comment #52 on bug 40538.

(I'm almost afraid to report this bug because someone will probably see it and
adjust things so that even middle-clicking won't work.  Don't do that!)



Reproducible: Always

Steps to Reproduce:

Comment 1

[Boris Zbarsky [:bzbarsky]]

You gave directions to the browser to load the link.  The web page gave
directions that the link is a local file.  We don't let web pages access local
files.

Did you actually read the discussion in bug 84128?

A hint:

<a href="file:///dev/tty">Click this!</a>

<a href="file:///dev/zero">Click this too!</a>

<iframe src="data:text/html,<a href='file:///etc/password'>And this</a>"></iframe>

Comment 2

[Christopher Allen]

> Did you actually read the discussion in bug 84128?

Yes. Carefully.  I thought comments #26, #29, #30, #50, #60, #62, #65 and #73
were particularly good.

In any case, I can see that there are security issues with loading file: URIs in
the general case.  This bug does not concern the general case.

> A hint:
> <a href="file:///dev/tty">Click this!</a>
> <a href="file:///dev/zero">Click this too!</a>

I can see the URL on the status bar; if I choose to click it, that's my problem.
 (Well, no: it would be nice if Mozilla declined to device special files, named
pipes, and other things which would case it to hang.  But that's a separate
issue, and one which isn't a security problem, because I can clearly see what
URL is about to be loaded.)

> <iframe src="data:text/html,<a href='file:///etc/password'>And this</a>"></iframe>

This is the same as the above except that clicking on it doesn't work even when
this HTML appears in a local file.


Let me repeat: WHEN I CLICK ON A LINK, THE SPECIFIED URL SHOULD LOAD.


- Turning off security.checkloadURI is not an acceptable solution, because
obviously I don't want to lose protection against malicious pages causing local
files to be loaded automatically.  But if a server presents a file: URL to me,
it should not be necessary for me to copy and paste the URL in order to load it.

- An "are you sure?" dialog would certainly be a good idea - preferably with a
"please don't ask again" checkbox.

- A suitable checkbox in the preferences would be fine too.  It could even have
two: one for <A HREF>s and one for all other cases.  Perhaps the former could be
captioned "I am silly and prone to clicking on links without looking at the link
target."  ;-)

- Please note that this bug is not a duplicate of 84128, because simply telling
me I can't load the specified file isn't really helpful.  (Though it would have
saved me a lot of timem fiddling around trying to figure out what was wrong!)

Comment 3

[Matthias Versen [:Matti]]

*** This bug has been marked as a duplicate of 122022 ***