Note: There are a few cases of duplicates in user autocompletion which are being worked on.

"file:" URIs are silently not opened even of file type had been activated to be opened

RESOLVED DUPLICATE of bug 84128

Status

()

Firefox
File Handling
--
minor
RESOLVED DUPLICATE of bug 84128
11 years ago
11 years ago

People

(Reporter: Ulrich Windl, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.2pre) Gecko/20061023 SUSE/2.0.0.1-0.1 Firefox/2.0.0.2pre
Build Identifier: 

If you set up the file extension ".DOC" to be opened with Microsoft Word (instead of being saved to a file), Word opens if you have a "http:" URI in a link target. However if you have a "file:" URI in a link target, nothing happens.
In the "Messages" tab of the error console, a message says that a http-type content may not link to a file-type content.
In workgroup environments some people use that to link to shared files on a server, using "local" file protocols to manage server contents.

Reproducible: Always

Steps to Reproduce:
1. <a href="file:///C:/autoexec.bat">A File!</a>
2. <a href="autoexec.bat">Also a File!</a>

Actual Results:  
The first URI wou't open, even there's an application assigned to that type with action "open file". In the second case, the file is opened.

Expected Results:  
Both content types (we are not talking about access types) should be handled the same way.

Not common use, but a valid use case that should work.
See http://kb.mozillazine.org/Links_to_local_pages_don%27t_work
There is a big difference if you open a html file with such links from http:// or from file://.

Case A: 
I open a html file from a http:// URL with the 2 different links from your steps to reproduce

Result:
1.) Gives me a security Error
2.) An autoexec.bat is loaded from my webserver because it's an relatiove URL.
(Http://domain.tld/autoexec.bat)

Case B: I load the html file with the 2 links with file: protocol.


Result:
1.) is loaded
2.) is loaded

This is the expected result as it should be.
Do you see something different than that ?



(Reporter)

Comment 3

11 years ago
The real issue is: While I fully agree with the default security settings of not following file links within http-loaded stuff (and the excellent description from comment #1), I think the following problems exist:

1) It's too hard for the average user to change the security settings

2) If you hover with the mouse over such a to-be-denied link, everything looks just normal, but eventually nothing happens (no pop-up or so) when you click on the link. That leads to the "click-like-mad" effect for a short while, and the average user will think "Firefox is broken".

I could imagine  the cursor changing to a "no entry" style while hovering over an URL that won't be loaded. That could be true for phishing protection as well...

Regarding comment #2, case A, result 1): How does the "security error look like for you? Only an entry in the error console (that doesn't pop up, but has to be inspected manually)?
The whole discussion is not new and the bugs are easy to find in bugzilla if you search better.

I will dupe this to bug 84128, a bug with 300+ comments and created 2001.

re 1) true but it's unwanted from the mozilla developers to make it easy
re 2) for a visible error (maybe an error page or infobar) we have bug 84128. Please don't add a comment to bug 84128 why it hasn't been done already, you can always add a patch to that bug.

and the security error is in the Error Console and i know since 6 years where to search for such an error message :-)

Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 84128
You need to log in before you can comment on or make changes to this bug.