file: URL not trigger a warning if authority field is not empty, "localhost" or Win32 drive name




16 years ago
7 months ago


(Reporter: cowan, Unassigned)


({parity-chrome, parity-ie, regression})

parity-chrome, parity-ie, regression

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [necko-backlog], URL)



16 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6

An attempt to enter "file://foo/bar/baz" into the URL bar does not produce an
error message or anything else: Mozilla just sits there.

Reproducible: Always

Steps to Reproduce:
1.  Enter "file://foo/bar/baz" into the URL bar.
2.  Hit Enter.
3.  Wait forever.

Actual Results:  
Nothing happens.

Expected Results:  
Either an error message, or (better) an attempt to locate "foo" on the Windows
network (effectively mapping "file://foo/bar/baz" to the UNC path
"\\foo\bar\baz".  This is what IE does, and IMHO is the most reasonable
behavior, since UNC paths are understood as local by Windows users.
(I know that file://///foo/bar/baz is the Mozilla Way, but compatibility counts

Mozilla Firebird on Linux simply ignores the authority field altogether, which
is reasonable (but giving an error message would be reasonable too).


Comment 1

16 years ago
Confirmed 2003052708 winXP, but I would say that this is more of an severity:
enhancement rather than normal as it does not really effect the functionality of

Comment 2

16 years ago
This was fixed in bug 128909, so this might be a regression.

is this problem specific to urls w/ a bad authority, or any URL that points to a
non-existent filename?
Keywords: regression

Comment 3

16 years ago
Suppose that c:\foo\bar does not exist.

Then if a drive specifier appears as either the authority (file://c:/foo/bar) or
the first element of the path (file:///c:/foo/bar), then a dialogue box appears
saying "The file /c:/foo/bar does not exist.  Please check the location and try

But if the authority is not a drive specifier or empty (file://foo/bar), and
likewise if the authority is empty but the first element of the path is not a
drive specifier (file:///foo/bar), then the browser just sits there as I reported.

So this indeed looks like a regression of #128909.
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:

Comment 5

13 years ago
This problem is still present in Firefox 1.0.7 as well as Firefox 1.5 beta 1.
This is *not* the same as #128909, which by the way is not fixed either.  This
bug reports errors on URLs of the form "file://bad/authority" (with two
slashes), whereas #128909 complains about URLs of the form "file:///bad/path"
(with three).

Comment 6

13 years ago
-> default owner
Assignee: darin → nobody
QA Contact: benc → networking.file

Comment 7

9 years ago
Confirmed: This is still present in Firefox 3.5.2

We are trying to link to "local" UNC path:ed files from our Intranet but since we're trying to move to Firefox we ran into this problem.
this is still a problem on windows - hanging spinner
Whiteboard: [necko-backlog] [good first bug]


3 years ago
Ever confirmed: true
OS: Windows XP → Windows
Hardware: x86 → All
Summary: file: URL ignored if authority field is not empty, "localhost", or Win32 drive name → file: URL not trigger a warning if authority field is not empty, "localhost" or Win32 drive name
Whiteboard: [necko-backlog] [good first bug] → [necko-backlog][parity-IE][parity-chrome]
Confirmed: Still exist in Firefox - Firefox does not respond 
Version 	43.0.1
Build ID 	20151216175450
User Agent 	Mozilla/5.0 (Windows NT 5.1; rv:43.0) Gecko/20100101 Firefox/43.0

Internet Explorer Displays: "Address Bar" messaging Windows cannot find the 'file://foo/bar/baz'. Check the spelling and try again, or try searching for the item by clicking the Start button and then clicking Search. [OK]
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome, parity-ie
Whiteboard: [necko-backlog][parity-IE][parity-chrome] → [necko-backlog]
You need to log in before you can comment on or make changes to this bug.