Open Bug 13607 Opened 21 years ago Updated 3 years ago

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

Categories

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

All
Windows 7
defect

Tracking

()

People

(Reporter: marshall, Unassigned)

References

()

Details

(4 keywords, Whiteboard: [necko-would-take])

Attachments

(1 obsolete file)

Currently in Win98 file:/// displays a blank page.  It would be nice if it
displayed a list of drives.
Jud, not sure if this should go to you, is this a possibility? The current
behaviour on 4.x is a blank listing also
Assignee: don → valeski
QA Contact: leger → paulmac
Assignee: valeski → waterson
waterson hooked up the directory viewer (we use the same one for FTP and file).
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.
Assignee: waterson → valeski
gotcha, I thought you had done the file:// dir listing conversion to http-index
too. I understand what needs to happen now.
Target Milestone: M14
QA Contact: paulmac → shrir
qa -> shrir
Seems non-essential for beta. Moving to M15.
Target Milestone: M14 → M15
*** Bug 24431 has been marked as a duplicate of this bug. ***
off to enhancement pile
Target Milestone: M15 → M18
qa:tever
QA Contact: shrir → tever
-> gagan
Assignee: valeski → gagan
Milestone 0.8 has been released. We should either resolve this bug or update its
milestone.
->dougt
Assignee: gagan → dougt
Target Milestone: M18 → Future
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).

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.
Keywords: helpwanted
Summary: file:/// should display a list of drives → RFE - file:/// should display a list of drives
*** Bug 82857 has been marked as a duplicate of this bug. ***
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.
*** Bug 65152 has been marked as a duplicate of this bug. ***
-> file
Component: Browser-General → Networking: File
Summary: RFE - file:/// should display a list of drives → [RFE] file:/// should display a list of drives
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.
Keywords: mozilla1.0
OS: other → All
QA Contact: tever → benc
Hardware: PC → All
Why is it displaying C:?  Why not a list of available drives?
+testcase... use the URL.
Keywords: testcase
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.
Blocks: 65152
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...
Summary: [RFE] file:/// should display a list of drives → [RFE] "file:///" not working, MacClassic & Win98
Whiteboard: pls check linux and update
Blocks: 102724
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.
No longer blocks: 102724
Severity: enhancement → major
Keywords: arch, mozilla0.9.5
Summary: [RFE] "file:///" not working, MacClassic & Win98 → "file:///" broken (MacOS & Win98
Whiteboard: pls check linux and update
Target Milestone: Future → ---
Summary: "file:///" broken (MacOS & Win98 → "file:///" broken (MacOS & Win98)
Target Milestone: --- → Future
Nominating mozilla 0.9.6 - this is the most serious display bug in the file 
component.
can we remove the mozilla0.9.6 keyword now?
-matt
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 
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.
Keywords: pp
*** Bug 129493 has been marked as a duplicate of this bug. ***
*** Bug 140606 has been marked as a duplicate of this bug. ***
nsbeta1 - please fix this for the next release.
Keywords: nsbeta1
*** Bug 151584 has been marked as a duplicate of this bug. ***
*** Bug 151566 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.0
Mozilla 1.2.1
Now it says: "the file / cannot be found"
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.
Summary: "file:///" broken (MacOS & Win98) → "file:///" shows blank page instead of root (Mac & Win)
(wonders why this works in Chimera, but not in Mozilla 1.3b/Mach-O....
Keywords: regression
Summary: "file:///" shows blank page instead of root (Mac & Win) → "file:///" shows blank page instead of root (Mach-O & Win)
adt: nsbeta1-
Keywords: nsbeta1nsbeta1-
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
Never mind my previous comment. The file really wasn't there on that machine.

-David
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:///../"
Flags: blocking1.6b?
Darin, do you think there's any quick and easy solution to this? Not going to
block 1.6 for this. 
Flags: blocking1.6b? → blocking1.6b-
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.





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.
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.
I filed bug 249282 on adding a workaround specific to file:// URLs.  Clearly, we
can support mixed \ and / on Win32 specific file:// URLs.
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
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
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
jphincelin@ares.fr: that's not related at all to this bug.
*** Bug 303157 has been marked as a duplicate of this bug. ***
Assignee: dougt → nobody
QA Contact: benc → networking.file
Priority: P3 → --
Target Milestone: Future → ---
(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?
On OS X, file:/// correctly shows root directory. Must have been fixed (on Mac) at some point in the past decade.
OS: All → Windows 7
Summary: "file:///" shows blank page instead of root (Mach-O & Win) → "file:///" shows blank page instead of root (Win)
Attached file testcase (must be loaded locally) (obsolete) —
I don't understand why someone requested a testcase for this bug, but sure okay.
Keywords: testcase
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.)
Attachment #8579422 - Attachment description: testcase → testcase (must be loaded locally)
Attachment #8579422 - Attachment is obsolete: true
Whiteboard: [necko-would-take]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.