65152 - "file://" -> "file:///"

Status: RESOLVED WONTFIX

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

Description

[Tom Everingham]

Overview Description:  Local file listing on the Macintosh is not displaying 
filenames, only icons
 
Steps to Reproduce:
1.)  Type in file://  or file:// some folder name

Actual Results:  only file icons displayed - no other information

Expected Results:  Should see a file or folder icon, the name of the file, 
date/time stamp info etc.

Build Date & Platform Bug Found:  Mac OS9 and OS8.6 2001-01-04-08-MTEST

Additional Builds and Platforms Tested On:  works on Linux & NT

Additional Information: 
possibly related to bug 13607
using modern skin but have seen this with others

Comment 1

[gordon]

We still hope to fix this in 0.9.1, but we wouldn't hold up the milestone for it.  
Changing target to 0.9.2.

Comment 2

[benc]

mass move, v2.
qa to me.

Comment 3

[benc]

qa to tever (he has "file")

What is the correct behavior of "file://"?

For non-tree based file systems, it is not clear to me how the top level should
be represented as a file URL.

That did not work for me in Comm4 nor Mozilla 0.9 on Win98 either.

Setting Platform and OS to "ALL".

Comment 4

[benc]

nevermind, a conversation where people have answers instead of questions is in
bug 13607.

*** This bug has been marked as a duplicate of 13607 ***

Comment 5

[Tom Everingham]

verified dup

Comment 6

[benc]

REOPEN:
file:// -> file:/// is probably a separate behavior. 
Fixing file:/// is dependent on fix for bug 13607.

Comment 7

[benc]

I'll post in netlib and see if anyone strongly objects...

Comment 8

[benc]

updated summary:

The mapping only happens for the literal case "file://"
file:// -> file:///

Other URLS beginning w/ "file://" are treated normally.

file://string -> file://string
file://string/path -> file://string/path

string is treated as a host. If string is a drive letter, see bug 24431 and bug 

Since this is a single case that maps an illegal URL to the reasonably intended 
target, I'm going to mark this WFM.

This is depends on bug 13607 because in non-Linux systems, the resulting 
display of "file:///" is not working.

Comment 9

[benc]

+verifyme - anyone takers?

Comment 10

[benc]

VERIFIED:
file: URL verification push.

Comment 11

[benc]

updated keywords too.

Comment 12

[benc]

REOPEN: RC1
Only works in Linux now.

Nobody ever said this was expected behavior, so I'm not creating new bug,
keyword regression, etc.

Comment 13

[benc]

What's the expected behavior here?

Comment 14

[benc]

RESOLVED/WFM:
Works "again"... Mac, probably due to the CFM -> Mach-O switch.

updated platforms.

I also created a test document using HTML so I can isolate the behaviors from
URL bar. This expansion is actually occuring in URL parsing, at some level.

andreas: do you know of any reason why we do this expansion, and in UNIX-style
platforms only?

Comment 15

[benc]

Attachment: contains file:, file:/ file://, file:/// links

Comment 16

[Robert Accettura [:raccettura]]

*** Bug 228867 has been marked as a duplicate of this bug. ***

Comment 17

[Doug Turner (:dougt)]

mass reassigning to nobody.