User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2.1) Gecko/20021130 Build Identifier: http://ftp.mozilla.org/pub/mozilla/releases/mozilla1.3/mozilla-mac-MachO-1.3.dmg.gz When launched, Mozilla 1.3 for Mac OS X cannot find my local on-disk homepage (~/html/index.html), giving the standard "This page cannot be found, please check the address, yadda yadda" dialog when any attempt at loading the page is made. 1.2 (which I've gone back to using for now) doesn't have this problem. Further, after the first launch of 1.3 (when the browser goes to mozilla.org to start with) the dialog box appears with *no* browser window, and this dialog cannot be dismissed (though it can be hidden behind other apps and Mozilla can still be quit normally). Attempting to create a new window with cmd-N merely produces another dialog box. I imagine this problem would disappear if I wasn't using an on-disk homepage, but there are reasons I do so. In case you're wondering, I got in the habit of using an on-disk homepage during my Netscape 4.7 days on metered dialup- I found I could save a couple minutes of online time by having Netscape launched before I actually dialed, with an on-disk homepage containing links to all my most frequently accessed sites ready to go once the PPP dialer had done its thing. Reproducible: Always Steps to Reproduce: 1. Create on-disk homepage (~/index/index.html in my case) 2. Using a previous version of Mozilla, set this as your homepage. 3. Launch Mozilla 1.3 Actual Results: Floating dialog sheet with no attached window proclaims that the page in question cannot be found. Dialog cannot be dismissed. Trying to create a new window with cmd-N does nothing but cause an overlay of a new dialog sheet on top of the old one. Expected Results: Properly loaded on-disk homepage OS: Mac OS X 10.2.4 CPU: 450MHz G4 RAM: 224MB Previous Mozilla version used: 1.2 Theme: Default
Perhaps the full URL can be used as a workaround? Something like file:///home/me/html/index.html
Is it possible that you used the classic 1.2.1 ? AFAIK the macho build uses Unix-Style Paths. And also a valid path for a local homepage should be file://blah
I don't believe we ever resolved ~ to the users local home directory.
I don't have a copy of 1.2.1 handy, but I don't think we ever expanded '~' to your home directory on the Mac. Not that we shouldn't but, I don't see how you would run into this problem unless you wanted to edit your prefs file by hand. Using the prefs dialog, when you pick a local file as your homepage, it uses the full Unix path, and it works fine. With it's current summary, this bug is invalid or WFM. If you want to change it to "'~' should be expanded to the home dir on OSX", that's fine.
there are several bugs already on ~ not expanding to homedir on unix. (And it certainly doesn't work on a current trunk CVS build, Linux.)
My apologies- I referred to my home directory in my original report using the notation "~/" for brevity but the actual URL used by Mozilla for my homepage is: file:///Cube%20HD/Users/meneleig/html/index.html This may look unusual to non-Mac folk but it's the way Mac OS browsers (including previous releases of Mozilla for Mac OS) generally handle URLs pointing to files on disk. Most Mac users (in particular those new to OS X) will probably still expect URLs like that to work, especially if they're not familiar with Unix notation for absolute filenames. My own speculation is that the non-Carbon codebase used for the backend in 1.3 isn't aware of that particular quirk of Mac OS on-disk URL notation, but you folks would know better than I. For a screenshot showing the "floating dialog sheet" I'd described earlier, see http://otto.twu.net/mozbug.png You'll notice that the dialog almost appears to be coming from Terminal.app... After switching back and forth between Mozillas 1.2 and 1.3 a few times I did get the dialog to dismiss in 1.3 and give me a blank browser window, but that version still doesn't find the homepage.
firstname.lastname@example.org, due to changes in Mozilla for Mac OS X between 1.2 and 1.3, you will need to update the style of your file URL. Note that Apple's new Safari also uses this new style.
I'll find the dupe later.
Assignee: asa → dougt
Status: UNCONFIRMED → NEW
Component: Browser-General → Networking: File
Ever confirmed: true
QA Contact: asa → benc
-> darin If we init a nsLocalFile on UNIX with a patch such as ~/html/index.html, we do resolve to whatever the HOME directory is (as specified by either the nsDirectoryService). Maybe the OSX implementation should do the same thing? http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsLocalFileUnix.cpp#260
Assignee: dougt → darin
Assignee: darin → ccarlen
dougt: that isn't what the file URL really said (see #9). We don't do shell-style expansion in any other form of UNIX... Several of these bugs have been filed since we went from CFM to Mach-O, but this is not a new issue: Netscape 6 and 7, Mozilla until 1.3f, and probably any IE, Communicator, Mozilla, Netscape running in classic mode all use old-style (HFS?) volume based file: URLs. IE for Mac OS X, Safari, Chimera, Mozilla 1.3f+ (and probably OmniWeb) all use UNIX style, UFS/tree style file: URLs. Several of these bugs have been filed since the Mach-O change, and they should be duplicates of bug 140606. There seemed to be some developer discussion in the bugs, so I was waiting to see if any new decisions would be made as we transition. There was little discussion about migration issues (maybe we need to file a bug in bookmarks about migration which might depend on a file URL bug that would provide HFS->UNIX file URL conversion?). If there are products built and shipped on CFM (Netscape?) this might be a real issue. For bookmark specific breaking, this is probably a duplicate of bug 151538, which depends on bug 140606.
Summary: Mozilla 1.3 cannot find homepage on local disk (~/html/index.html) → Mozilla 1.3f (Mach-O) breaks previous (CFM ) created file: URLs (esp. in bookmarks)
> Several of these bugs have been filed since the Mach-O change, and they should be duplicates of bug 140606. No. Bug 140606 is about old CFM builds not being able to handle current Mach-O file:// URLs. Obviously, nothing can be done about that since we're no longer doing CFM builds so that's a WONTFIX. This bug is the other direction - Mach-O builds reading CFM build file:// URLs. That is bug 197379, that can and should be fixed, and this depends on it.
If this bug is a depends on bug 197379, is this bug reverting back to talking about just problems w/ the home page breaking w/ CFM file URLs? If so, we should update the summary and move to the correct component. I'm already going to test any fix to 197379, but the other blackbox testers (like bookmarks) are going to need to test their stuff.
This was most likely fixed by checkin for bug 197379. This is probably a dup of that one, except it mentions the problem WRT prefs. Ben, I think you were right in suggesting that the summary should be updated and the component changed to prefs.
reading CFM bookmarks should not mater today
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.