- create an html file on the desktop called "4/23 results" - drag it into navigator expected: - page should load actual: - nada if you remove the '/' in the filename, the file can be loaded.

this doesn't work with files opened from the "open" dialog either, it's not just drag/drop. i'll file another bug that the file has to have an extension in order for it to be seen by the dialog.

--> pchen. i doubt blake will fix.

Buy me a mac and I will.

I think some one should just buy Blake a mac ;-)

nav triage: not an rtm stopper.

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

So I've found out half of the problem. nsLocalFile::GetURL blindly converts '/' into ':' and ':' into '/', reason being that ':' is the directory seperator character on MacOS and '/' being the directory seperator for unix and URL's, so we're trying to convert from platform specific to url form. Problem is that '/' is a valid filename/directory name character, and swapping it for a ':' confuses MacOS even more. Everyone swears this was working, but I think everyone just remembers us fixing this problem in 4.x many times over. At any rate, I hacked a MacEscape() routine to encode the '/' before swapping '/' and ':', and then the file url looks good. The problem then is that the backend code can't deal with the escaped '/', so it looks like I need to find the correct place to unencode the '/' character. Sheesh, nothing is ever simple in this codebase. At any rate, I'm pretty sure that I'll cause some regressions with this, so I don't think we should take this for 0.9.3. And as Pinkerton said, we've foisted this bug on our users this long, what's another milestone between friends. Pushing out to mozilla0.9.4

nav triage team: moving to 0.9.5

Mass-moving lower-priority 0.9.5 bugs off to 0.9.6 to make way for remaining 0.9.4/eMojo bugs, and MachV planning, performance and feature work. If you disagree with any of these targets, please let me know.

Given my current set of tasks, I won't be able to get to this for 0.9.6, pushing out to mozilla0.9.8

> So I've found out half of the problem. nsLocalFile::GetURL blindly converts '/' This isn't the problem. The GetURL/SetURL methods of nsIFile give correct round-trip conversion. What is probably going on is that an nsFileSpec/nsFilePath is being used somewhere along the line. Conversions between files and URLs between nsIFile and nsFileSpec are not round-trip. I discovered this a long time ago when the chrome registry had this problem. Using nsIFile and not mixing with nsFileSpec fixed it.

->jag

Dup. *** This bug has been marked as a duplicate of 58533 ***

Verified Duplicate