13607 - "file:///" shows blank page instead of root (Win)

Status: NEW

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

Description

[Neil Marshall]

Currently in Win98 file:/// displays a blank page.  It would be nice if it
displayed a list of drives.

Comment 1

[Paul MacQuiddy]

Jud, not sure if this should go to you, is this a possibility? The current
behaviour on 4.x is a blank listing also

Comment 2

[Judson Valeski]

waterson hooked up the directory viewer (we use the same one for FTP and file).

Comment 3

[Chris Waterson]

jud, fwiw, this will require changes to the back-end code that creates the HTTP
index, not the front-end (you still want me to own it? :-). It'll probably
require some #ifdef XP_PC code that calls the Win32 volume enumeration
routines; RJC has written some code in nsFileSystemDataSource.cpp that does
this, as well as doing volume enumeration on Mac.

Comment 4

[Judson Valeski]

gotcha, I thought you had done the file:// dir listing conversion to http-index
too. I understand what needs to happen now.

Comment 5

[Paul MacQuiddy]

qa -> shrir

Comment 6

[Warren Harris]

Seems non-essential for beta. Moving to M15.

Comment 7

[Judson Valeski]

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

Comment 8

[Judson Valeski]

off to enhancement pile

Comment 9

[shrirang khanzode]

qa:tever

Comment 10

[Judson Valeski]

-> gagan

Comment 11

[Oliver Klee]

Milestone 0.8 has been released. We should either resolve this bug or update its
milestone.

Comment 12

[Gagan]

->dougt

Comment 13

[Doug Turner (:dougt)]

rfc state a file url has the follow format:

file://<host>/<path>

<host> is usually empty which leaves

file:///<path>

if <path> is empty, we "could" special case this on non-rooted file systems (eg. 
non-unix-like fs).

Comment 14

[David Hallowell]

I remember 4.x and below on Windows 3.1 doing this but as Win3.1 isn't supported
by Mozilla I don't think it warrants the bug being marked as 4xp. It makes sense
to support this because it's a logical step that if you've got the drives
representing the first part of the path then the root directory (file:///)
should have links to the drives.

Comment 15

[Alex Bishop]

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

Comment 16

[timeless]

nc4.77 w2k no c:\
<TITLE>Directory listing of </TITLE>
<H1>Directory listing of </H1>
<PRE>
</PRE>

ie5.5 w2k no c:\
Windows cannot find 'file:///'. Check the spelling and try again, or try 
searching for the item by clicking the Start button and then clicking Search.

Comment 17

[benc]

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

Comment 18

[benc]

-> file

Comment 19

[benc]

qa to me.
plat/os -> all
+mozilla 1.0
+ URL: example

file:/// shows contents of C drive now (but does not change the URL to file:///C|/)

Mac specific problems could be broken out in bug 65152 later.

Comment 20

[Neil Marshall]

Why is it displaying C:?  Why not a list of available drives?

Comment 21

[benc]

+testcase... use the URL.

Comment 22

[benc]

MacOS: 
Mozilla 0.9.
file:/// displays a list of file icons that have the URLs of directories that
are rooted in the mozilla program folder, e.g. file:///chrome.

Comment 23

[benc]

UPDATE:
Win 98, Mozilla 0.9.4.

"file:///" does show the top level of C, but the tree does not draw directories 
as folders, everything is a file.

Updated summary to reflect current situation.
Need to look at Linux...

Comment 24

[benc]

changed to normal bug.
+arch, +m 0.9.5

Linux: works fine, displays "/"

Win: should provide a list of drives. Optionally, other objects visible at the 
"My Computer" level, such as Web Folders, could be included as well.

MacOS: should provide a list of volumes. Optionaly, the view should be all 
objects on the desktop.

The optional comments are made for thoughtfulness reasons, since file refers to 
"Host-specific file names" (per RFC 1738), making these objects visible is not 
essential, since most of them are actually mapped by the OS from other 
locations in the filesystem.

although "file:///" strictly means "file:///<VOID>" (the "/" is not part of the 
fpath), this URL should work on all platforms or none.

If this needs to be separate bugs for each OS, I'll make them.

Comment 25

[benc]

Nominating mozilla 0.9.6 - this is the most serious display bug in the file 
component.

Comment 26

[m_mozilla]

can we remove the mozilla0.9.6 keyword now?
-matt

Comment 27

[neilr8133]

When I go to the "Location" textbox and enter any of the following:

   file:///
   file:///autoexec.bat
   file:///config.sys
   file:///windows/win.ini

when I hit "Enter" the textbox loses focus, but nothing else happens. 
(Confirmed in windows/tabs that already have items in them, and a New Window
that was blank.)

However, if I go to File | "Open File" then I can open \autoexec.bat,
\windows\win.ini, etc.  I can also open "file:///" files if I use the drop-down
menu for the Location bar.


Mozilla: 2002040303
WindowsME: 4.90.3000 

Comment 28

[benc]

That sounds like a more general regression.

Look for dupes and file a new bug if it is unique.

This bug is strictly for problems with a specific file:// URL.

Comment 29

[benc]

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

Comment 30

[benc]

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

Comment 31

[benc]

nsbeta1 - please fix this for the next release.

Comment 32

[Matthias Versen [:Matti]]

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

Comment 33

[Sander]

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

Comment 34

[benc]

Mozilla 1.2.1
Now it says: "the file / cannot be found"

Comment 35

[Frankie]

In Mach-O there is no way to browse the root level of your system drive (aka
"/"). If you browse to (for example) file:///Users/ and click the "Up to higher
level directory" link, it goes to the blank page.

All other drives are available in file:///Volumes/ but not the system drive.

Comment 36

[benc]

(wonders why this works in Chimera, but not in Mozilla 1.3b/Mach-O....

Comment 37

[Samir Gehani]

adt: nsbeta1-

Comment 38

[David Kahn]

A variant of this bug maybe?

I had my home page set to file:///c:/blank.html
When I upgraded from 1.3 to 1.4rc2, I get an error
message pop-up that it can't find file:/c:/blank.html,
no matter how many slashes I use. (Windows XP Pro SP1 OS).

My workaround was to just set my home page to about:blank,
but apparently file: URLs are a problem in 1.4, my guess anyway.

-David

Comment 39

[David Kahn]

Never mind my previous comment. The file really wasn't there on that machine.

-David

Comment 40

[benc]

This bug gets weirder and weirder. I just noticed today on Mach-O, that there is
a link provided to "up to higher level", and it appears as "file:///", but is
actually: "file:///../"

Comment 41

[Asa Dotzler [:asa]]

Darin, do you think there's any quick and easy solution to this? Not going to
block 1.6 for this. 

Comment 42

[Rudolf Bargholz]

Not sure if this is relevant for the described behaviour, but on WindowsXP using
Firefox 0.9.1 clicking on an href of the form

  <A
HREF="file:///C:\Programme\SQLLIB\DOC\HTML\db2a0/db2a0114.htm"><b>Application
Development Guide - Overview of a Trigger
</b></A>

does nothing.

If I paste

  file:///C:\Programme\SQLLIB\DOC\HTML\db2a0/db2a0114.htm

into the url entry field of the browser it is converted to 

  file:///C|%5CProgramme%5CSQLLIB%5CDOC%5CHTML%5Cdb2a0/frame3.htm#db2a0114

and loads correctly.

The links are created automatically by the DB2 UDB v7.1 HTML documentation
engine, so I have no influence on the format.

Comment 43

[Darin Fisher]

Rudof: Yeah, it does sound like you are reporting a different problem.  It
appears that DB2 UDB v7.1 is not adhering to RFC 2396.  That is unfortunate.

Comment 44

[Andreas Otte]

Yes, this is something different. We expect more (better standards compliance!)
from a link than from something in the urlbar. \ is not a path separator in
urls, / is. In the urlbar we convert \ to / on windows, but not in links. I
suggest filing an evangelism bug against the DB2 UDB v7.1 HTML documentation
engine to get them fix their file urls.

Comment 45

[Darin Fisher]

I filed bug 249282 on adding a workaround specific to file:// URLs.  Clearly, we
can support mixed \ and / on Win32 specific file:// URLs.

Comment 46

[Mike Kaply [:mkaply]]

poke with an owner of the DB2 UDB documentation, and they have redesigned their
help system since v7.1. The new system no longer uses any file:/// links

Comment 47

[jphincelin]

I have the following problem in Mozilla 1.7.3 and Firefox 1.0 on a Windows 2000
PC with a form containing an input type=file for the user wanting to display an
image from its own discs :
The user chooses a file, then a
document.getElementById('myPhoto').innerHTML="<img
src='"+document.foto.file.value+"'>" does NOT display the photo. 
To have it displayed, I must transform the value by inserting file:///C:/ etc
The problem does not exist in IE 6.

Is that the same bug or another one ?
Any help ? Thanks

Comment 48

[jphincelin]

I have the following problem in Mozilla 1.7.3 and Firefox 1.0 on a Windows 2000
PC with a form containing an input type=file for the user wanting to display an
image from its own discs :
The user chooses a file, then a
document.getElementById('myPhoto').innerHTML="<img
src='"+document.foto.file.value+"'>" does NOT display the photo. 
To have it displayed, I must transform the value by inserting file:///C:/ etc
The problem does not exist in IE 6.

Is that the same bug or another one ?
Any help ? Thanks

Comment 49

[Christian :Biesinger (don't email me, ping me on IRC)]

[e-mail]: that's not related at all to this bug.

Comment 50

[benc]

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

Comment 51

[G.T.B.]

(In reply to comment #13)
> rfc state a file url has the follow format:
> 
> file://<host>/<path>
> 
> <host> is usually empty which leaves
> 
> file:///<path>
> 
> if <path> is empty, we "could" special case this on non-rooted file systems (eg. 
> non-unix-like fs).

The problem I've seen (with Firefox as far back as I can remember) is that file://<host>/<path> doesn't work. I see that putting c:, etc., in the URL bar can get me to local files, but the real usefulness is the network-shared files that everyone on Windows passes around with file:// links. All the Internet Explorer people can click these links and pull up files, while we poor Firefox users have to manually open them (in business, this happens many, many times per day).

Did file://<host>/<path> syntax get broken when this local drives were being fixed, or has it never been implemented?

Comment 52

[Frankie]

On OS X, file:/// correctly shows root directory. Must have been fixed (on Mac) at some point in the past decade.

Comment 53

[Frankie]

Attachment: testcase (must be loaded locally)

I don't understand why someone requested a testcase for this bug, but sure okay.

Comment 54

[Jesse Ruderman]

Comment on attachment 8579422 [details]
testcase (must be loaded locally)

This bug had the "testcase" keyword to indicate that it already had a testcase of sorts. (Nowadays, I think we'd use the "reproducible" keyword instead, or just not add the "testcase-wanted" keyword.)

Comment 55

[Firefox Bug Husbandry Bot]

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

Comment 56

[Daniel Bodea [:danibodea]]

Loading "file:///" will not show the drives in either Windows 10 and Windows 7, however, it will display the contents of a drive when loading "file:///c:/".

This behavior does not apply to Ubuntu 20 or Mac OS 11.

Comment 57

[Randell Jesup [:jesup] (needinfo me)]

Current status is mostly unchanged; works on linux/mac, shows nothing on windows (it doesn't change the displayed page at all; it gets ignored - this is a change from the previous blank page).

Note that chrome does something similar, though not exactly the same. On Linux, it shows the root. On windows, it gives a "This page isn't working" "redirected you too many times"

Comment 58

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.