Build: 2001-09-18 Steps: 1. Start installer, follow the steps till Setup Type dialog appears. 2. Click Browse button to bring up Select a directory dialog. 3. To create a new install directory, enter the double-byte characters into Directories box as attached files (the characters are entered using Phonetic and Korean (Hangul) IME). 4. Click OK, look at the directory name. 5. Click Yes, look at the error message. Actual: 1. The double-byte directory name is garbled in Step 4. 2. Got the following error message in Setp 5: "Could not create folder: xxxxxx Make sure you have access to create the folder."

same would happen if the dir contains non-ascii chars, and i think that we had a bug on it.

Rui, are these problematic chars the same as those you discovered in window title display problem (bug 94011 and bug 94024)?

Yes, I tested with the same problematic chars in bug 94011 and bug 94024 so far, to keep the problem clearly and avoid any confusion. But, please note that the problematic chars are not only one or two.

So it seems we have a generic problem with those extended Chinese and Korean characters. Could you check if it happens on file dialog window when selecting File | Open File on navigator window in case that the folder name contains those characters? Thanks.

I agree with Xianglan, looks like we couldn't handle those extended Chinese and Korean characters in any where of our application. I believe you have some more bugs about it, they may all caused by a same reason. cc Frank.

i take back my comment about non-ascii chars, the install doesn't fail with those char in the path, at least on Win2K and XP

here is a bug i was talking about that was verified as fixed, # 58866. Rui, please read the lenghty discussion there and see if those bugs are related.

Xianglan, I tried to select File | Open File on navigator window, it has no problem. In this case, navigator calls system functions. Marina, thanks a lot for letting me know bug# 58866. I am trying to locate all those bugs in our product and these information are very helpful.

Xianglan, I forgot to mention that the navigator cannot pickup those problematic folder names from Open File dialog correctly after calling system functions. This bug will be sent separately.

dveditz/dougt: how could I debug the installer? ==== ccin'g dveditz and dougt

samir or sean know how.

windows installer == ssu expertise

I used various Unicode WAPIs (eg. GetOpenFileNameW(), CallWindowProcW(),etc); but none worked well. We really need to compile apps as an Unicode. Settign the milestone to moz 1.0 and lowering the Priority.

Note to reproduce: - Install Chinese Traditional IME Phonetic in W2K-CS - Type 'u'+'l'+ <Space> + page down + select 6th char

Please also refer to bug 93507 and bug 93528 for detailed char input steps.

Actually, it is difficult to fix these unicode issues with local APIs and patches since the problems mainly happened on the system layer. It might be better to improve the architecture for unicode support and fixing those unicode bugs.

nsbeta1- works for default OS locale

This bug also happened with CHT chars on CHT WinNT/Win2K, and KOR chars on KOR WinNT/Win2K.

push to future

problem on SCH OS can be addressed by bug 126744 and problem with korean characters on KO os can be addressed by bug 126752

bug 126744 and bug 126752 fixed the problem as reported originally, but it's still impossible to install in a folder whose name includes a character outside the repertoire of the current default system locale(that is, Hindi folder under French locale on Win2k/XP. On Win9x/ME, it's impossible no matter what we do, but on Win2k/XP, it's possible by fixing bug 162361 for which I have a working patch.). I'm changing the summary line accordingly.

jshin in comment #23: > still impossible to install in a folder whose name includes a character outside > the repertoire of the current default system locale(that is, Hindi folder under > French locale on Win2k/XP. On Win9x/ME, it's impossible no matter what we do, > but on Win2k/XP, it's possible by fixing bug 162361 for which I have a working > patch.). I'm changing the summary line accordingly. is this fixed by bug 162361? is bug 100243 a dupe?

(In reply to comment #24) > is this fixed by bug 162361? No, it's not. bug 162361 is an important step forward, but installer still uses nsILocalFile methods like 'SetNativeLeaf*' and Win32 'A' APIs extensively (even for text drawing) > is bug 100243 a dupe? No. The issue there was fixed a long time ago. Originally, it was a dupe, but I changed this bug for something else.

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

(In reply to comment #25) > No, it's not. bug 162361 is an important step forward, but installer still > uses nsILocalFile methods like 'SetNativeLeaf*' I was just reminded by biesi's comment in bug 100364 that the installer does not use xpcom. So, the problem is its use of 'A' APIs instead of 'W' APIs.

Is this fixed by bug 305039?

(In reply to comment #28) > Is this fixed by bug 305039? I'm not sure if the original bug report was filed for the NSIS installer, but yes, the current installer on trunk and 1.9.1 branch can handle Unicode path names.