Closed Bug 140606 Opened 23 years ago Closed 22 years ago

file: URL OS X filespace not supported in CFM builds

Categories

(Core :: Networking: File, defect)

Product:
Core
Component:
Networking: File
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WONTFIX
Milestone:
Future

People

(Reporter: dp_bluegreen, Assigned: dougt)

References

Details

(Keywords: platform-parity, testcase, Whiteboard: does not affect Chimera or Mach-O)

After installing the 1.0rc for OSX, my Imported IE Favorites that use protocol "file://localhost/" don't work -- no page is loaded and no popup occurs. Pasting these urls into the location box has the same result. I have to change "file://localhost/" to "file:///Macintosh%20HD/" to get the pages to load.
-> networking:File
Assignee: Matti → dougt
Component: Browser-General → Networking: File
QA Contact: imajes-qa → benc
Whiteboard: dupeme
David: Take a look at the other bug. If it is the same problem, you can mark this verified. You should put a sample file URL into that bug, as well as more info (is this IE for Mac OS 9?), etc. *** This bug has been marked as a duplicate of 13607 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Whiteboard: dupeme
I believe this is a separate bug from that described by 13607. I'm not sure if I'm violating etiquette by reopening this bug, but I wasn't sure that this update would be mailed out if the status wasn't changed (by comparion, gnatsweb doesn't send mail if the status isn't changed). In IE 5.1 for Mac on OSX, this url retrieves a file on my local drive: file://localhost/Users/david/Projects/jdom/binary/jdom-b7/build/apidocs/index.html But pasting this url into the location box of Moz1.0rc, over the url of some loaded page like http://my.yahoo.com, and hitting return doesn't cause the Moz icon to spin or make any visible change to the loaded page. I believe that 'localhost' is an OS-independent networking alias to the local default dir. Not only does 'localhost' work for retrieving items, but if you use File|Open in IE 5.1 for Mac, it will use 'localhost' in the url displayed for any file opened from your local drive. If you load the same file using Moz1.0rc, instead of 'localhost', it uses the local drive name: file:///Macintosh%20HD/Users/david/Projects/jdom/binary/jdom-b7/build/apidocs/index.html The customer-facing impact of this bug is that bookmarks imported from IE 5.1 for Mac won't work for any bookmark to a local file.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Several points: You used the term "protocol 'file://localhost/'". "file" is a protocol described by a URL scheme. "file://localhost" would be an example of the file protocol syntax, it is not a protocol in itself. That is why I marked the bug a duplicate, because it seemed like you wanted just the top level to work (which doesn't and is discussed in that bug). Now that you have provided an example, we see that this was not the problem you are having. Reopening the bug was the right thing to do. Here's the answers to your questions. File URLs in a page served from a network service cannot be clicked by default. This is a feature (bug 122022). You need to follow the instructions to make any file URL work (try using the file URLs created by Mozilla on your yahoo page, they won't work either.) After you fix this preference, your old URLs will STILL not work, because you have found an actual bug. RC1 still uses the older Mac OS classic API's, which do not mount the UNIX filesystem at root natively. Both the IE and Mozilla file URLs are valid, because applications are allowed to view the filespace as the OS presents it to them. This is not really an RFC violation, but it certainly is weird, and is possibly fixable. -> NEW cc:sdagley, who can probably use correct developer-speak to summarize what I just said.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Mac System 9.x → MacOS X
Summary: Protocol "file://localhost/" not supported by OSX Moz 1.0rc → file: UNIX filespace not supported for URLs
+testcase, better summary
Keywords: testcase
Summary: file: UNIX filespace not supported for URLs → file: UNIX filespace not supported in Mac OS X
*** This bug has been marked as a duplicate of 142074 ***
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → DUPLICATE
REOPEN:
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 142074 has been marked as a duplicate of this bug. ***
*** Bug 150663 has been marked as a duplicate of this bug. ***
Adding "URL" to Summary to better catch searches.
Summary: file: UNIX filespace not supported in Mac OS X → file: URL UNIX filespace not supported in Mac OS X
Keywords: helpwanted
Target Milestone: --- → Future
*** Bug 157504 has been marked as a duplicate of this bug. ***
*** Bug 153493 has been marked as a duplicate of this bug. ***
+nsbeta1, pp: file URL's should work between browsers...
Keywords: nsbeta1, pp
*** Bug 169704 has been marked as a duplicate of this bug. ***
I have a test case that may be related to this bug. In Flash MX (Mac OSX) the help section and tutorials link to local URLs, for example: file://localhost/Volumes/System%20HD/Applications/Macromedia%20Flash%20MX/Help/Flash/ContextHelp_tut2.htm However this does not work in Mozilla 1.0.1, Chimera .5, or Mozilla Nightly... in fact it doesn't load a URL *at all* it just acts like no URL is being attempted. After cutting and pasting the URL from IE I found that I must remove the word "Volumes" from the directory path for it to work. So as an example this URL *does* work in Mozilla: file://localhost/System%20HD/Applications/Macromedia%20Flash%20MX/Help/Flash/ContextHelp_tut2.htm Of course Internet Explorer does work with the first syntax. But I refuse to make Internet Explorer my default web browser. I assume that each browser is retreiving the localhost root a little differently... I would really like to see this fixed as many web designers use flash and the Mozilla standards compliance is a very attractive feature to web designers... however it doesn't mean jack if Macromedia's tools don't work well with it (no matter whos fault it is).
Take a look at http://bugzilla.mozilla.org/show_bug.cgi?id=130237#c11. I think that comment is the problem you are talking about.
Is this bug what causes FizzillaCFM to write file URLs in chrome.rdf *with* the volume name, and FizzillaMach to write them *without*?
Tried to clarify summary so that it blames the correct type of builds. If someone can clarify this further
Summary: file: URL UNIX filespace not supported in Mac OS X → file: URL UNIX filespace not supported in Mac OS X (CFM builds)
Whiteboard: does not affect Chimera
*** Bug 181943 has been marked as a duplicate of this bug. ***
*** Bug 155676 has been marked as a duplicate of this bug. ***
CFM has retired. Mach-O follows Unix file conventions. What now?
Summary: file: URL UNIX filespace not supported in Mac OS X (CFM builds) → file: URL OS X filespace not supported in CFM builds
Whiteboard: does not affect Chimera → does not affect Chimera or Mach-O
Sorry for the spam. Fizzilla CFM build is dead; should this bug go with it?
Keywords: qawanted
*** Bug 151538 has been marked as a duplicate of this bug. ***
Mach-O is the present and future.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 22 years ago
Keywords: helpwanted, nsbeta1, qawanted
Resolution: --- → WONTFIX
Blocks: 151538
VERFIED: wontfix. CFM RIP. The converse of this bug (get Mach-O to understand old-style file URLs, is bug 197283 and/or bug 197379).
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.