"file:///" shows blank page instead of root (Win)
Categories
(Core :: Networking: File, defect, P5)
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.
Comment 1•25 years ago
|
||
Jud, not sure if this should go to you, is this a possibility? The current behaviour on 4.x is a blank listing also
Updated•25 years ago
|
Comment 2•25 years ago
|
||
waterson hooked up the directory viewer (we use the same one for FTP and file).
Comment 3•25 years ago
|
||
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.
Updated•25 years ago
|
Comment 4•25 years ago
|
||
gotcha, I thought you had done the file:// dir listing conversion to http-index too. I understand what needs to happen now.
Updated•25 years ago
|
Updated•25 years ago
|
Comment 5•25 years ago
|
||
qa -> shrir
Comment 11•23 years ago
|
||
Milestone 0.8 has been released. We should either resolve this bug or update its milestone.
Comment 13•23 years ago
|
||
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•23 years ago
|
||
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.
Updated•23 years ago
|
Comment 15•23 years ago
|
||
*** Bug 82857 has been marked as a duplicate of this bug. ***
Comment 16•23 years ago
|
||
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•23 years ago
|
||
*** Bug 65152 has been marked as a duplicate of this bug. ***
Comment 18•23 years ago
|
||
-> file
Comment 19•23 years ago
|
||
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•23 years ago
|
||
Why is it displaying C:? Why not a list of available drives?
Comment 22•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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.
Updated•23 years ago
|
Comment 25•23 years ago
|
||
Nominating mozilla 0.9.6 - this is the most serious display bug in the file component.
Comment 26•23 years ago
|
||
can we remove the mozilla0.9.6 keyword now? -matt
Updated•23 years ago
|
Comment 27•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
*** Bug 129493 has been marked as a duplicate of this bug. ***
Comment 30•22 years ago
|
||
*** Bug 140606 has been marked as a duplicate of this bug. ***
Comment 32•22 years ago
|
||
*** Bug 151584 has been marked as a duplicate of this bug. ***
Comment 33•22 years ago
|
||
*** Bug 151566 has been marked as a duplicate of this bug. ***
Comment 34•22 years ago
|
||
Mozilla 1.2.1 Now it says: "the file / cannot be found"
Comment 35•21 years ago
|
||
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•21 years ago
|
||
(wonders why this works in Chimera, but not in Mozilla 1.3b/Mach-O....
Comment 38•21 years ago
|
||
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•21 years ago
|
||
Never mind my previous comment. The file really wasn't there on that machine. -David
Comment 40•21 years ago
|
||
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:///../"
Updated•21 years ago
|
Comment 41•21 years ago
|
||
Darin, do you think there's any quick and easy solution to this? Not going to block 1.6 for this.
Comment 42•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
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•19 years ago
|
||
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•19 years ago
|
||
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•19 years ago
|
||
jphincelin@ares.fr: that's not related at all to this bug.
Comment 50•19 years ago
|
||
*** Bug 303157 has been marked as a duplicate of this bug. ***
Updated•18 years ago
|
Updated•18 years ago
|
Comment 51•15 years ago
|
||
(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•9 years ago
|
||
On OS X, file:/// correctly shows root directory. Must have been fixed (on Mac) at some point in the past decade.
Comment 53•9 years ago
|
||
I don't understand why someone requested a testcase for this bug, but sure okay.
Comment 54•9 years ago
|
||
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.)
Updated•8 years ago
|
Comment 55•7 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Comment 56•3 years ago
|
||
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•2 years ago
|
||
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•2 years ago
|
||
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.
Description
•