197283 - Mozilla 1.3f (Mach-O) breaks previous (CFM ) created file: URLs (esp. in bookmarks)

Status: RESOLVED WONTFIX

(Core :: Networking: File, defect)

Description

[gummigoof]

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

Comment 1

[R.K.Aa.]

Perhaps the full URL can be used as a workaround?
Something like file:///home/me/html/index.html

Comment 2

[Matthias Versen [:Matti]]

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

Comment 3

[Simon Fraser [no longer active]]

I don't believe we ever resolved ~ to the users local home directory.

Comment 4

[Conrad Carlen (not reading bugmail)]

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.

Comment 5

[R.K.Aa.]

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.)

Comment 6

[gummigoof]

  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.

Comment 7

[Greg K.]

[e-mail], 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.

Comment 8

[benc]

I'll find the dupe later.

Comment 9

[R.K.Aa.]

bug 189350?

Comment 10

[Doug Turner (:dougt)]

-> 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

Comment 11

[Doug Turner (:dougt)]

to darin.

Comment 12

[Darin Fisher]

-> conrad

Comment 13

[benc]

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.

Comment 14

[Conrad Carlen (not reading bugmail)]

> 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.

Comment 15

[benc]

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.

Comment 16

[Conrad Carlen (not reading bugmail)]

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.

Comment 17

[Matthias Versen [:Matti]]

reading CFM bookmarks should not mater today