Tested on MacOS 9 with MN6-2000-10-27: - Save a html file on your desktop - Put a slash in the name (for instance test/1.html) - Open the file in Mozilla ==> The page stays blank. It's a problem of character conversion within the URL where '/' is converted to ":" before being encoded. With the example above, Mozilla attempts to load file:///LeBook/Desktop%20Folder/test%3A1.html (= test:1.html) instead of file:///LeBook/Desktop%20Folder/test%2F1.html (= test/1.html). If you enter the correct URL (the one with %2F), it works.

Perhaps this has something to do with this bit of code: http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsFileSpecMac.cpp#133

->dougt

Open Networking bugs, qa=tever -> qa to me.

what is milestone "mozilla1.0" anyway? Moving to future.

I think we need to address this before future gets here :-) reeling it in...

bulk move to 0.9.4

qa to me. clarified summary - interesting cause...

re-bucket-ing milestone

+testcase

This is a problem of the conversion from file url to nsIFile. Obviously a / in a filename has to be escaped when inside a file-url. The same should be true for : inside filenames in file-urls. Why we use this : <-> / conversion for the mac is beyond my understanding. Okay, I heard that : is used as directory delimiter on mac filepaths, so transforming : to / when converting from macfilepath to file url and transforming / to : the other way seems okay. If everything else is properly escaped no harm is done. But we do both transformations all the time. Somehow this complete exchange is not honored on the nsIFile-side I guess or if nsIFile is okay maybe some old implementation like nsFilePath is used.

A couple problems with the nsLocalFileMac::GetURL. I will attach a patch.

Andreas, Pierre, could I get a review of this patch.

Hmmm ... I think this will work for this problem, but might break nasty filenames which already have something in it that looks like an escaped character. That's why esc_Forced should be used, but that's no longer possible here ...

Doug: Try Escaping with esc_FileBaseName+esc_Forced (should escape all /), then replace all ocurrances of %3A (escaped :) with /. That should do it.

Andreas, can you review 48314?

Comment on attachment 48314 [details] [diff] [review] what Andreas said. looks good to me. r=andreas.otte@primus-online.de

Doug, I think there are some other places where this kind of conversion happens. nsStdURL.cpp/GetFile/SetFile comes to my mind (which should go away I think). Also we should make sure the conversion from filepath to url and the other way around is reversable with identical results.

Comment on attachment 48314 [details] [diff] [review] what Andreas said. >Index: mozilla/xpcom/io/nsLocalFileMac.cpp >=================================================================== >RCS file: /cvsroot/mozilla/xpcom/io/nsLocalFileMac.cpp,v >retrieving revision 1.65 >diff -w -u -2 -r1.65 nsLocalFileMac.cpp >--- nsLocalFileMac.cpp 2001/07/25 07:54:09 1.65 >+++ nsLocalFileMac.cpp 2001/09/05 20:09:25 >@@ -2204,16 +2204,15 @@ > > nsresult rv; >- char* ePath = nsnull; >+ char* rawPath = nsnull; > nsCAutoString escPath; > >- rv = GetPath(&ePath); >- if (NS_SUCCEEDED(rv)) { >- >- SwapSlashColon(ePath); >+ rv = GetPath(&rawPath); > >- // Escape the path with the directory mask >- rv = nsStdEscape(ePath, esc_Directory+esc_Forced, escPath); > if (NS_SUCCEEDED(rv)) { should these lines (below) be left indented 4 spaces? >+ // Escape the path with the directory mask >+ rv = nsStdEscape(rawPath, esc_FileBaseName+esc_Forced, escPath); > >+ if (NS_SUCCEEDED(rv)) { >+ escPath.ReplaceSubstring("%3A", "/"); > escPath.Insert("file:///", 0); > >@@ -2229,5 +2228,5 @@ > } > } >- CRTFREEIF(ePath); >+ CRTFREEIF(rawPath); > return rv; > } otherwise, sr=darin

oops.. rather, the line above should be left indented 4 spaces if (NS_SUCCEEDED(rv)) looks like it is not aligned correctly.

not enough time. 0.9.5 -> 0.9.6

darin, was that a sr after I fixed up the spacing?

Comment on attachment 48314 [details] [diff] [review] what Andreas said. >Index: mozilla/xpcom/io/nsLocalFileMac.cpp >- // Escape the path with the directory mask >- rv = nsStdEscape(ePath, esc_Directory+esc_Forced, escPath); > if (NS_SUCCEEDED(rv)) { >+ // Escape the path with the directory mask >+ rv = nsStdEscape(rawPath, esc_FileBaseName+esc_Forced, escPath); looks like the comment needs to be updated too. with that sr=darin.

we should bake this for a while. Moving to 0.9.7

I tested out the patch and could open a file with a '/' in it. However, if there is a '/' in the path to the app and chrome is registered for the first time, it will be registered again on every subsequent launch. This needs to be figured out first. This was with Carbon OS X.

conrad, any idea why we reregister

Haven't debugged it yet. Stepping through the chrome registry would probably find it. I could do that later tonight.

conrad, if you do not have time for this, please assign back.

mass move to 0.9.8

conrad, if you are working on this, shouldn't status==ASSIGNED?

*** Bug 77758 has been marked as a duplicate of this bug. ***

Mass move to 0.9.9

-> recent nsFileSpec to nsIFile mods may have solved this. can someone verify w/ a new trunk build?

This works with 20020201. I'd say it's due to rjc's recent nsFileSpec expulsion. -> to rjc to let him call it fixed.

Well, my removal of nsFileSpec usage in RDF certainly didn't fix this bug (although, they might have helped with chrome reregistering problems mentioned; I have no idea there.) However, accompanying changes made to nsIOServiceMac.cpp in Necko regarding colons/slashes probably did the trick. Indeed, I can now load files with slashes in them into Mozilla with no problems. However, dougt's second patch are changes to nsLocalFileMac.cpp in XPCom... so I'd suspect that they are still appropriate changes. Reassigning this bug back to dougt so they he (or maybe Conrad) can make the final call.

conrad, let me know if you can look at this prior to 099

Round and round we go. This time, just resolving it since it does in fact work. Robert, yeah it probably was what you did in nsIOServiceMac.cpp. I was probably thinking nsFileSpec usage because that did contribute to this problem in the past. It had a slightly different way of dealing with ':' and '/' than the code in necko, which is where the code which used to be in nsLocalFile came from. This meant that a conversion from nsFileSpec -> URL -> nsIFile when the path contained a '/' would fail. Get/SetURL has been completely removed from nsLocalFile so the patches here aren't relevant anymore. But, if the code in nsFileSpec does not match the newly rev'd code in nsIOServiceMac.cpp, we may still have a problem.

Mozilla 0.9.8 for Mac OS X. STEPS: 1- File | Open File 2- select file (Macintosh HD:filename w/ slash) (double clicking in the file view is blocked by ) Fails to open, error message says cannot find file (filename is URL encoded string w/ incorrect colon ("%3A") for slash. NOTE: Mac OS X does not allow the creation of files w/ "/" even on HFS volumes (probably due to it's UNIX heritage. I need to look at MacOS 9 tomorrow and possibly re-open.

> Mozilla 0.9.8 for Mac OS X. What's the relevance of 0.9.8? This was fixed around 20020201. If you're going to re-open, it has to be with a current build.

reopen bug; I see this problem on my Macintosh (9.2) with a debug build from yesterday. I renamed one of my html files to have a '/' in it, double-clicked. The app came to the foreground, a new browser window was opened, and an alert came up: "The file /Quest/Desktop%20Folder/foo%3Abar.html cannot be found. Please check the location and try again."

(brade, thanks for the help...) I wanted to get more analysis in, but the clock ran out, so I went with what I had at the time... sorry about the mess.

> I renamed one of my html files to have a '/' in it, double-clicked. Yep, it doesn't work. However, opening the file with Cmd-O does. Need to find out what's different between the two cases...

> Need to find out what's different between the two cases... Found it. The code in nsCommandLineServiceMac.cpp uses a $#@! nsFileSpec to create the URL to open. I changed that code to use nsILocalFile and now it works. Patch coming up...

Can I get r=/sr= on this?

Comment on attachment 47531 [details] [diff] [review] Encodes slashes manually prior to calling our standard encoder. obsolete since this code no longer resides in nsLocalFileMac.cpp

Comment on attachment 48314 [details] [diff] [review] what Andreas said. obsolete since this code no longer resides in nsLocalFileMac.cpp

Comment on attachment 73067 [details] [diff] [review] patch to use nsILocalFile r=rjc

Simon, can you sr=?

Comment on attachment 73067 [details] [diff] [review] patch to use nsILocalFile sr=sfraser

This bug also appears if you try to send a message with a file attached, and that file has a slash in the filename. When you do that, two dialog boxes appear. The first is shows the progress of attaching the file to the message. It is set to 0%. The second is the error dialog box (its presence is what keeps the progress bar at 0%) and it says, "Sending of message failed. Please verify that your Mail & Newsgroups account settings are correct and try again." This is with Mozilla 0.99 for Mac OS 9, build 2002031106. I'm surprised this bug has existed, in one form or another, for over a year!

Comment on attachment 73067 [details] [diff] [review] patch to use nsILocalFile a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Fix checked in.

VERIFIED: Mozilla 0.9.9, Mac OS X and classic file URL's seem to want to download rather than display, but I think that is a File Handler bug...