The default bug view has changed. See this FAQ.

A file: link on a http: page is not followed.

VERIFIED DUPLICATE of bug 84128

Status

()

Core
Security
VERIFIED DUPLICATE of bug 84128
16 years ago
16 years ago

People

(Reporter: dthiede, Assigned: dougt)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
Evaluation Procedure: A local file reference is typed into the url edit field.
The reference is converted to a file: style of url and the page is loaded. This
url is extracted and placed on a web page referenced via http: method. The page
is loaded and the link is clicked on but the link is not followed. 

Perform the same operation as above but copy the generated url into another
local file page. Load the page and click on the file: link on that page. The
links are followed. 

A page that has a file: reference. Right click on the link and use the "Copy
link location" option. Paste this link into the url box and press return. The
page is loaded.

The above tests imply that when attempting to follow a file: link on a page that
was loaded with a http: type reference, the link is not functional. I have
observed this behavior for serveral if not most of the versions of mozilla that
I have used. It is still a problem with 0.9.2. There has been quite a bit of
discussion about file: references associated with bug 66194 but I don't belive
that this is a platform dependancy or related to the number of "slashes" in a
file: url.

I hope that this issue is resolved since a lot of application documentation is
loaded as local pages and not being able to access them from a http: referenced
page is pretty cumbersome.

Dave
Reporter:
You mean you have a page : Http://... which contains a link to file:// ?
marking invalid...

from bug 75577
------- Additional Comments From Mitchell Stoltz 2001-04-12 12:34 -------

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.


Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID
(Reporter)

Comment 3

16 years ago
At least the comments allowed me to come up with a workaround. I now use the
file:///home/httpd/html/index.html as my default home page instead of the
http:// format as I have been able to do for many years with various browsers.
It was the change in policy that threw me.

Updated

16 years ago
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---

Comment 4

16 years ago
REOPEN:
need to mark this duplicate so we keep "score" accurately :)

Comment 5

16 years ago
RESOLVED/DUPLICATE:
Matti: thanks handling this bug report. 
I'm duping new problem reports to bug 84128 because that is where we can fix it.

It is clear since we fixed bug 40538, that -nobody- is using the javascript
console and seeing the error message.

*** This bug has been marked as a duplicate of 84128 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → DUPLICATE
verified dupe
Status: RESOLVED → VERIFIED

Comment 7

16 years ago
-> sec:gen
Component: Networking: File → Security: General
QA Contact: tever → bsharma
You need to log in before you can comment on or make changes to this bug.