Open Bug 143021 Opened 23 years ago Updated 3 years ago

Local files w/ relative file URLs need to have a drive letter.

Categories

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

Product:
Core
Component:
Networking: File
Platform:
x86
Windows ME
Type:
defect

Tracking

()

Milestone:
Future

People

(Reporter: jcrodriguez, Unassigned)

References

Details

(Whiteboard: [necko-would-take])

Opening a page from a local drive the browser don't open images and css style files with absolute path to the local drive. Example: file: d:\test.html ------------------------------ <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <title>Absolute path</title> </head> <body> <img src="/test.gif"> </body> </html> ---------------------- Exist d:\test.gif
Wouldn't an absolute path be "/d|/test.gif"? the "d:" is not the hostname, but is part of the path....
Assignee: Matti → darin
Summary: Opening pages from a local drive. Not loading relates files with absolute path. → Opening pages from a local drive. Not loading relates files with absolute path.
I believe that bzbarsky is correct: the proper absolute pathname would be <img src="/d|/test.gif"> Please resolve this bug WONTFIX.
hmm.. although we already do make certain exceptions w.r.t. drive letters for XP_WIN. in this case, it'd be trivial to determine that /test.gif does not start with a drive letter, and we could then go ahead and use the baseURI's drive letter. it'd be interesting to see how IE and nav4x interpret this href.
Darin, did you want to look into this further?
Status: UNCONFIRMED → NEW
Component: Browser-General → Networking: File
Ever confirmed: true
QA Contact: imajes-qa → benc
-> future
Target Milestone: --- → Future
(attempted summary clarification). Historically, we have contemplated this smart-path logic for file URLs, and generally decided that some of this belongs in URL bar (because it compensates for user error), but not in the content loading stuff for layout. There are usually problems, in this case, implementing that would conflict with a long-standing request for actually obeying the hostname field of file URLs. Forcing the author to provide a correct file path is the proper solution, and this should be done w/ UNC's so that the file URL does not break becuse the drive's mount-letter is hard coded (if you used "file:///d:/test.gif", pity the person w/ two local partitions mounting the networking drive on "e:". suggesting WONTFIX.
Summary: Opening pages from a local drive. Not loading relates files with absolute path. → Local files w/ relative file URLs need to have a drive letter.
benc: actually, there is no confusion between drive letter and hostnames. our parser already determines whether the text after the first set of slashes is a drive letter or a hostname. for windows, we have extra code in the parser that checks for URLs like: file://c:/foo.html the code treats this URL as if it were: file:///c:/foo.html so, i don't see any reason why we can't fix this bug.
+clean report oh. I thought that was a URL bar behavior... are we simply never going to implement the hostname field?
Keywords: clean-report
I am having the same issues for images i.e file://mako1/testweb/someimage.jpg displays not image even though this is properly formed. Now I can understand why this has not been implemented. If you are going to run a website then you should use a web server, not a mapped network drive/folder, (note it does not have to have a drive letter assigned to it, you can use the hostname plus the directory path.) but still this begs the question, then why do you ever support page links that are the same way? This is inconsistent. You should either allow it all are not allow all, not we will for links but not for images. This rates to me a nescience more then a bug.
Okay, I'm not sure if I understood benc's explanation. I tried a lot of different syntaxes both with URIs and UNCs, and couldn't get it to work the way I wanted. Maybe I'm stupid, but... The thing I'm trying here is to have a way to point to a file in a static folder inside the present volume, _without_ having to refer to the drive letter. Granted, _usually_ the proper way to set up HTML pages is through a Web server, not referring to disk paths, but there are some situations where the disk paths are useful. One trivial example: using HTML to do a quick-and-dirty menu application for a CD-ROM. I'm trying to do something of the sort, and running into the problem of linking to the global stylesheet. Now, Darin asked about IE's behavior. It resolves "/styles/stylesheet.css" as a reference to "<localdriveletter>:\styles\stylesheet.css", which works. The same syntax doesn't work in Mozilla. I tried a lot of variations, both using URIs and UNCs, and couldn't find a way to refer to the root of the present volume. As I said, maybe I'm stupid...
No, you are not. Mozilla has no concept of semi-absolute file urls for windows. All absolute file urls on windows must have a drive letter. ben's argument is that in "file://test/test.gif" the "test" could als be a hostname, which is a part of the file-url specification. It is very seldom used, because only localhost or the name of the local host make any sense as hostname and those can be savely omitted. The file-protocol has no concept of network access. Whenever network access happens with the file protocol it comes in the form of an UNC-*path*, like file://///hostname/path. I think we should have the following behavior (windows only!): 1. file://c:/path/test.gif => file:///c:/path/test.gif 2. file:///c:/path/test.gif no change 3. file://path/test.gif => file://path/[current drive]/test.gif 4. file:///path/test.gif => file:///[current drive]/path/test.gif The first two are already happening. The forth is the typical case discussed here. The third case is the strange case where someone could possibly used a hostname in the url or simply forgot a /. If it really is the hostname (and it is the local host!) the url will work, otherwise it will fail.
*** Bug 269860 has been marked as a duplicate of this bug. ***
I would like to advocate for this bug being solved. Ross Wells in duplicate bug report 269860 develops HTML pages locally on disk before exporting them to a web server, like I do, and a browser interpreting "/my_folder" as a reference to "my_folder" in the root of the current disk is an absolute necessity for testing such pages. I go one step further. I have many small "HTML applications" available on my disks, all referring to script files and icons stored in the "_common" folder that I have in the root of all my disks, including my memory key disk so it is easy to take examples out for demonstrations. The earliest dates in the documentation files for my _common folder stuff is from October 1998, and since then - and before - Netscape has rendered itself useless as my general browser due to its lack of resolving my absolute addresses. I hoped that FireFox was a better choice, but unfortunately it has the same lack. That is really a pity because in my opinion it is much superior to IE in many respect. As I read Andreas' comment (#11), it is a question of further exceptions in an already existing parser. Wouldn't it be feasible to implement that without lots of efforts?
It should certainly be possible to implement case 4 without much effort but then again file:///path/test.gif could also be a malformed access to an UNC path and the author really meant file://///path/test.gif where path is the UNC-path host. If we do this we will cause other bugs. There simply is no way to tell without checking for shares first which will take endless time to fail (if not existing) and cause bugs like "mozilla hangs on url". Or we could look for local access first with the current drive and if that fails try the share-version instead. However this kind of guessing is beyond the scope of the url-parser and comes down to a very smart way to try different kind of url-fixup from the webshell. And that is a major task.
But the reports concerning this bug refer to interpreting /path/file.ext, not to the parsed version file:///path/file.ext. "/path" is a common way to refer to folder "path" in the root of the "current device" no matter whether it is a web or a disk partition. If the programmer ment "//path", it is his/her fault that the target was misinterpreted.
*** Bug 274196 has been marked as a duplicate of this bug. ***
*** Bug 301615 has been marked as a duplicate of this bug. ***
*** Bug 336075 has been marked as a duplicate of this bug. ***
Assignee: darin → nobody
QA Contact: benc → networking.file
There are so many complaint about this bug as follows. It takes only five minutes to fix this bug. Firefox has not fixed this bug for 4 years like Netscape. I was the lover for Netscape. I hated IE. But Netscape never fixed any small bugs for many years. Then Netscape disappeared. Same thing is occurring to FF. OstGote! 2004-12-13 02:46:43 PDT *** Bug 274196 has been marked as a duplicate of this bug. *** Comment #17 [reply] OstGote! 2005-07-21 16:27:31 PDT *** Bug 301615 has been marked as a duplicate of this bug. *** Comment #18 [reply] Jesse Ruderman 2006-05-01 05:41:13 PDT *** Bug 336075 has been marked as a duplicate of this bug. *** Comment #19 [reply] Phil Ringnalda 2007-04-13 16:59:16 PDT *** Bug 377368 has been marked as a duplicate of this bug. **
I would like to suggest that a fix of this bug is now really in order because of the use of many more portable FF installs and I am told this bug affects use of FF on a USB memory stick. I would like to use my own local, auto-loaded home page when FF boots from the mem-stick and I can't set the relative path to it. I have to load it manually because FF can't know what drive number the USB stick will be on various computers, which _isn't_ the way people use home pages nor is it germain to portable software. Please increase the priority of this bug in light of the increase in use of portable software.
Whiteboard: [necko-would-take]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P5
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 5 duplicates.
:kershaw, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(kershaw)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(kershaw)
You need to log in before you can comment on or make changes to this bug.