75577 - file:// URLs do not give meaningful errors from pages served by http

Status: VERIFIED DUPLICATE of bug 40538

(Core :: Security, defect)

Description

[Greg Ingram]

An HREF like:

  <a href="file:///home/ingram/index.html"> Link </a>

won't load.  I don't get any error message.  Curiously, when I use the open dialog
to select the same file, it produces this exact URL in the location bar.

I'm using 0.8.0 and I see same behavior on Win98 and Linux.

Regards,

- Greg

Comment 1

[Asa Dotzler [:asa]]

Worksforme with 2001041104 mozilla win32 and 2001041108 linux build.  I opened
an html document with file open, copied the URI from address field and used that
to create an HREF in a new html document.  I opened the new document, clicked on
the link and it opened the original document.  Resolving as Worksforme.  If you
are still seeing this in a current nightly build please reopen.  Thanks.

Comment 2

[Greg Ingram]

Am I doing something stupid?

I grabbed the nightly build (2001041208) and it doesn't work.  The HTML in
my file looks exactly like:
 
<a href="file:///home/ingram/src/html/private/index.html"> Local </a><br>
 
When I click on it *nothing* happens.  It doesn't even look like it tries.
No error, no nothing.  If I copy the quoted UR[IL] (I've never fully known
the precise distinction) and paste it into the location window, the file
comes up perfectly.                                                             

Comment 3

[Asa Dotzler [:asa]]

I really don't know what could be wrong here.  It works fine for me.  Over to
Networking: File for further investigation.

Comment 4

[Mitchell Stoltz (not reading bugmail)]

Our security policy prevents http pages from linking to file:// URLs. Clicking a
file:// link in a page loaded from the Web just doesn't do anything. If the page
containing the link is also a file:// URL, the link will work normally.

We need a console message saying the link has been blocked, this is bug 40538. I
will dup this bug, but I'd like some confirmation that it's behaving as I
described. Asa was probably loading a copy of the file locally, which is why the
blocking didn't show up.

Reporter, can you confirm that this problem only occurs when the page in
question is coming in over the Web, as opposed to being a lcoal file?

Comment 5

[Greg Ingram]

Yes, I can open the file:// resource if I open the original page as a file. 
This solution works for me because, in fact, both files are local and I'll just
change my home page from http:// to file:// and everything should work.

I do think it needs a message explaining why it refused to open the document.

Incidentally, I tried Open Link in New Window and I got this:

JavaScript error:
 line 0: uncaught exception: [Exception... "Component returned failure code:
0x805303f4 [nsIScriptSecurityManager.checkLoadURI]"  nsresult: "0x805303f4
(<unknown>)"  location: "JS frame ::
chrome://communicator/content/contentAreaUtils.js :: openNewWindowWith :: line
58"  data: no]                                      

Hmm...

Comment 6

[timeless]

we could treat this as a dupe or as invalid, but let's try to improve user 
notification of the security violation. [new summary]

Comment 7

[Mitchell Stoltz (not reading bugmail)]

The weird error you see when you do an Open Link In New WIndow is because the
same security check is done there, and it responds simply by returning a
"failure" error. This needs better error reporting as well. I will do this soon.

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

Comment 8

[benc]

VERIFIED:
same problem