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

Status: NEW

(Core :: Networking: File, defect, P3)

Description

[John Cowan]

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
too.)

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

None.

Comment 1

[Dan Backes]

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
mozilla.

Comment 2

[benc]

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?

Comment 3

[John Cowan]

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
again."

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.

Comment 4

[Gervase Markham [:gerv]]

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:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 5

[John Cowan]

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

[Darin Fisher]

-> default owner

Comment 7

[Mårten Woxberg]

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.

Comment 8

[Patrick McManus [:mcmanus]]

this is still a problem on windows - hanging spinner

Comment 9

[Michelle Funches - QA]

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]

Comment 10

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 11

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 12

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)