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

RESOLVED WONTFIX

Status

()

Core
Networking: File
P3
normal
RESOLVED WONTFIX
18 years ago
3 years ago

People

(Reporter: Tom Everingham, Unassigned)

Tracking

(Depends on: 1 bug, {testcase})

Trunk
Future
x86
Windows 98
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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

Updated

18 years ago
Target Milestone: --- → mozilla0.9.1

Comment 1

18 years ago
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.
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 2

17 years ago
mass move, v2.
qa to me.
QA Contact: tever → benc

Updated

17 years ago
Priority: -- → P3

Comment 3

17 years ago
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".
Component: Networking → Networking: File
OS: Mac System 9.x → All
QA Contact: benc → tever
Hardware: Macintosh → All
Summary: local file listing not working → file:// and file:/// does not display

Comment 4

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

*** This bug has been marked as a duplicate of 13607 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 5

17 years ago
verified dup
Status: RESOLVED → VERIFIED

Comment 6

17 years ago
REOPEN:
file:// -> file:/// is probably a separate behavior. 
Fixing file:/// is dependent on fix for bug 13607.
Status: VERIFIED → REOPENED
Depends on: 13607
Resolution: DUPLICATE → ---
Summary: file:// and file:/// does not display → file:// -> file:///

Updated

17 years ago
Assignee: gordon → dougt
Status: REOPENED → NEW
Keywords: testcase
QA Contact: tever → benc

Comment 7

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

Updated

17 years ago
Target Milestone: mozilla0.9.2 → ---

Updated

17 years ago
Target Milestone: --- → Future

Comment 8

17 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → WORKSFORME
Summary: file:// -> file:/// → "file://" "file:///"

Comment 9

17 years ago
+verifyme - anyone takers?
Keywords: verifyme
Summary: "file://" "file:///" → "file://" -> "file:///"

Comment 10

17 years ago
VERIFIED:
file: URL verification push.

Comment 11

17 years ago
updated keywords too.
Status: RESOLVED → VERIFIED
Keywords: verifyme

Comment 12

16 years ago
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

16 years ago
What's the expected behavior here?
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---

Comment 14

16 years ago
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?
OS: All → Windows 98
Hardware: All → PC

Comment 15

16 years ago
Created attachment 121108 [details]
contains file:, file:/ file://, file:/// links
*** Bug 228867 has been marked as a duplicate of this bug. ***

Comment 17

11 years ago
mass reassigning to nobody.
Assignee: dougt → nobody
Status: REOPENED → NEW
Status: NEW → RESOLVED
Last Resolved: 17 years ago3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.