(build 6_13_01) If system volume (only 1 volume) is named '•' (filled bullet) Fizilla is unable to run and stops abruptly. Renaming volume to e.g. 'a' enables Fizilla to run. However, renaming back to '•' (filled bullet) after the first run, seems to hang the system. The icons appears in the dock even if the application is not running, it is not visible in 'force quit' either.

cc: a few folks that might be able to help.

a stack trace would probably be very useful. per pinkerton i would have given this to sdagely but i think it's probably a file or nspr issue.

does this happen with OS9? if so, we really need to fix this. Even if it doesn't, 'future' isn't really an acceptable milestone for something like this.

This does not happen on OS 9 I wonder if it is related to error that Quicktime 5 (on OS X) exhibits: 'update existing software' is not able to run iff system volume is named '?' (filled bullet) [option-8 on a UK keyboard, don't know about US]. Renaming the volume enables it.

Fizzilla is more near and dear than future milestone... bringing it in the inner circle :-) and giving it some priority love...

Marking NEW.

bulk move to 0.9.4

darin, do you want to look at this. I understand that you have a 0sX build.

I have an OS X build. Darin, do you want me to take this?

-> ccarlen (thanks... i only have a mach-o tree).

For this problem to happen, the name of the volume must *be* a bullet char rather than *contain* a bullet char? If so -> 0.9.5. If just containing a bullet char kills us, I'll give it higher priority.

Happens for volume names: € [filled bullet] h€r [h and r before and after filled bullet] ærø [ISO8859 characters æ and ø] and probably other similar ones. does not happen for volume name: hr (and other US-ASCII presumably)

Alright, that's a more serious problem. Back to 0.9.4

If I rename the OS X boot volume to the bullet char [option-8], MozillaDebug just exits before its icon does even one hop. No crash, nothing to the console. I couldn't launch CW7 for debugging because it complains about a registration key not being found and quits. So, I launched CW7, renamed the volume and started mozilla in the debugger. On starting it, it crashes with an access fault in CarbonCore before hitting main(). This is bizzare - Today's optimized NS6 build gets as far as putting up the splash screen and immediately crashes. I should be able to collect a stack trace from that and get somewhere.

I changed my volume name to have a bullet char (option-8) between 2 ASCII chars It dies because opening the component registry fails because that code must be passed a path. nsLocalFileMac::GetPath() is returning the wrong thing. The problem goes down to the call to PBGetCatInfo in FullPath.c. When getting the volume name, instead of "X?1", PBGetCatInfo returns "X#2" ??? I'll have to do some research...

Instead of using FSpGetFullPath, which looks like it's not going to work under OS X, we can use a series of calls to FSGetCatalogInfo. At least this returns the name of each node as a unicode string. Unfortunately, this has to be mapped back into the fs charset which GetPath() is supposed to return (argh)

The patch uses FSGetCatalogInfo under Carbon to build the path which works. While the program now starts up, it still doesn't quite run because other code is still referencing code in nsFileSpecMac which is a clone of FSpGetFullPath so it doesn't work. Two options: 1. Get rid of this code (that which uses nsFileSpec -> nsFileURL) 2. If that's too much of a chore, gut the routine in nsFileSpecMac to make an nsILocalFile and get the path from it. Simon, Frank, can you review what's here so far?

Marking as PDT+. We'd like to take this one.

Just noticed something: There are 2 lines like this: + char stackBuffer[33]; The size of 33 got left there as I was testing the condition of running out of buffer space. Ignore that '33'. I changed it to be much larger.

Giving it a nsbranch+ because it already has a PDT+

The 1st patch did not work when the file for which the path was requested did not exist. The newer patch fixes that. It also makes the routine used by nsFileSpecMac (which doesn't work) delegate the task to a temp nsILocalFileMac. Need reviews.

Comments: MacFileHelpers::PathNameFromFSSpec() changes-- I'm a little concerned about performance here. I suspect this is something that gets called a lot, and I worry that the new way is slower than the old way. Do we have any performance measurements here? nsFSStringConversionMac: I prefer 'gFoo' for globals, rather than 'mgFoo'. Alternatively, use 'sFoo' for "static". Have you debugged through it to ensure that the ConvertFromTextToUnicode/ ConvertFromUnicodeToText loops perform correctly when they have to iterate more than once? That's a complex API, and hard to get right first time. mgHasHFSPlusAPIs: same comment about global naming as above.

> I'm a little concerned about performance here Yes. In microseconds, the new way is slower (about 2000 vs. 1000) PathNameFromFSSpec gets called about 40 times when starting up and opening mail. What I haven't measured is how much of that is in building the path vs. Unicode -> FS conversion. When bug 94323 is landed, we will only ever be returning Unicode so the conversion will go away. On the other hand, as far as performance, not sure what else we can do. PBGetCatInfo is returning the wrong thing for the name in this case. > Have you debugged through it to ensure that the ConvertFromTextToUnicode Yes. The looping works. True, they are complex APIs. If you know of anybody with experience with these APIs, it would help. I'll make the naming changes you suggest.

0.9.4 is out the door.

0.9.4 is out the door.

This is not on Tian Tian Must Fix list for this release, and is marked P3. Propose we up the priority, or consider minusing it.

Should this be a P1 and on Tian Tian list?

Can we try the patch on the trunk and then decide if it's a nsbranch+ requirement

Sounds like a good idea. What I'd like is for somebody to apply the patch and try it on an Asian system first. I asked ftang about this. If anybody knows anybody else who can do that, let me know.

> and then decide if it's a nsbranch+ requirement The question is not whether it's a requirement but if the patch is ready to go in. Not being able to launch on systems with non-ASCII chars in the path is about as bad as it gets for large parts of the world.

I meant to type 'nsbranch+ candidate'. Good point on the non-ASCII parts of the world so let's get some trunk testing going. ftang is back in town (I saw him yesterday) so hopefully he can test for you soon or direct somebody else in his group to try it.

Comment on attachment 49143 [details] [diff] [review] updated patch have not be able to test on Asian system. the patch looks good.

After testing on a system set for Japanese UI and script, I had to make a small change: Instead of: + UnicodeMapping mapping = { kTextEncodingUnicodeDefault, kTextEncodingMacHFS, kUnicodeUseLatestMapping }; + err = ::CreateUnicodeToTextInfo(&mapping, &mgEncoderInfo); I had to use this: + err = ::UpgradeScriptInfoToTextEncoding(smSystemScript, kTextLanguageDontCare, + kTextRegionDontCare, NULL, &theEncoding); and then ::CreateUnicodeToTextInfoByEncoding using that encoding. Simon, I changed the prefix on class statics from "mg" to "s" Can I get sr= on it?

sr=sfraser

qa to me, triaging "file" component... is this really related to file or some component (xpcom, strings)?

Checked into trunk. As soon as I hear results from IQA (and assuming they're good), will check into branch.

Can still repro this bug with trunk build 2001092721 on JA MacOS X (Version 10.0.4, build 4Q12) 1. most of high ACSII chars still have the same problem. 2. some JA double-byte signal chars, like '?' (sjis), have the problem.

Rui, do you have a build from today? It was checked in it Sep 28 02:19.

The latest build under ftp://.../10.x/ppc/2001-09-27-20-trunk/ is: Netscape6-macosX.sit.bin 13476 Kb Fri Sep 28 00:02:00 2001 Binary Executable Not sure whether it is including your fixes or not.

talk to build team, they said they only do MacOS X build every 8PM. Untill 8PM tonight, we cannot verify that.

Can still repro this bug with trunk build 2001093021 on JA MacOS X (Version 10.0.4, build 4Q12)

Rui, it sounds like this had no effect on a Japanese system. That may be another problem. Can you verify this bug as originally reported: non-ASCII chars on a U.S. or Euro system. If the name of the drive (the one for mozilla & system) contained a bullet char [option-8] it would crash on launch. If we can verify that is fixed, this will have done some good, as long as we are no worse off on a Japanese system.

Sorry, I could not find an US MacOS X. Can someone help with it?

For your reference: Changed my system Language/Locale setting from Japanese/Japan to US English/US, tested with trunk build 2001093021 on MacOS X (Version 10.0.4, build 4Q12, the same version with JA), the results are: 1. Using problematic high-ASCII chars cannot repro this bug. 2. Using JA double-byte chars can repro this bug.

> 1. Using problematic high-ASCII chars cannot repro this bug. That's good. > 2. Using JA double-byte chars can repro this bug. How can I know I'm using double-byte chars when I have my system set to Japanese/Japan? Can you mail me some strings which I can copy & paste? When I tested, not knowing the language, I just typed randomly :-/

Please find a JA test chars file attached (JA test chars.rtf), hope it helps.

After some testing with file names in attachment 51733 [details], this can't be solved easily. On Mac HFS+, file names are all stored as Unicode internally. Using the new ::FSGetCatalogInfo routine on OSX, it does return the correct Unicode file name (verified). Since nsIFile::GetPath() has to return a char* string, it needs to be converted from Unicode into what we consider the FS charset. On the Mac, each component of a file path can have a different encoding when not represented as Unicode and there doesn't appear to way to find out the non-Unicode encoding of those components. In short, this problem can't really be solved until nsLocalFileMac uses HFS+ when available (on systems >= OS 9) and all path accessors on nsIFile are Unicode-only.

Did this ever make it on the branch?

> Did this ever make it on the branch? No, because I couldn't conclude that the fix on the trunk worked based on: > 1. Using problematic high-ASCII chars cannot repro this bug. > 2. Using JA double-byte chars can repro this bug. (1) confirms the the fix worked for the problem reported here but (2) is what worries me. Rui, can you confirm that (2) is no worse than before this was checked into the trunk? If so, I'll check it in.

Verified with 2001-10-10 trunk. 1. On US language/locale, can still repro with JA double-byte chars. 2. On JA language/locale, can still repro with some JA double-byte chars and high ACSII chars.

0.9.5 is out the door. bumping TM up by one.

So, this is an open problem for the 094 branch and trunk?

Teruko or Ruixu, is this bug still needed for the branch? It looks like from Ruixu's comments that the bug is not fixed on the trunk even with this patch.

Rui, please answer Lisa's question.

Yes, this bug is not fixed completely on the trunk even with current patch.

If, by not completely fixed, you mean these cases, 1. On US language/locale, can still repro with JA double-byte chars. 2. On JA language/locale, can still repro with some JA double-byte chars and high ACSII chars. those are different than the original bug report and what the patch intended to fix. What I'd like verified is this: (1) the bug as reported (non-ASCII single-byte chars on a US system) (2) with the patch that's now in the trunk, that the other problems you found are not any worse on Japanese systems than before the patch.

As per Conrad's comments, should we separate i18n issue to a new bug?

Making this a dup of bug 96481. As I commented on 2001-10-04 08:41, this really cannot be fixed until we are using Unicode file system routines available on OS 9.1 and X (bug 95481) and the nsIFile API is Unicode-only. *** This bug has been marked as a duplicate of 95481 ***

Verified.