dthiede Reporter
	Description • 23 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

	Matthias Versen [:Matti]
	Comment 1 • 23 years ago

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

	Matthias Versen [:Matti]
	Comment 2 • 23 years ago

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.

	dthiede Reporter
	Comment 3 • 23 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.

	benc
	Comment 4 • 23 years ago

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

	benc
	Comment 5 • 23 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 ***

	Matthias Versen [:Matti]
	Comment 6 • 23 years ago

verified dupe

	benc
	Comment 7 • 23 years ago

-> sec:gen