On Linux, Solaris platform and in japanese locale, file name in "File Name:" text field of filepicker becomes garbage when japanese file is selected. Please try the following steps to reproduce. I tried on RH6.2J. 1) make a file with japanese filename 2) Start Mozilla 3) Open file dialog by File -> Open File... You can see the file can be displayed correctly as japanese on file list pane 4) select the file "File name:" text field will be filled by the filename. However, it becomes garbage. 5) However, the document can be loaded properly by clicking Open button I'll attach the snapshot.

Another problem, when the user correct the gabled file name using IME then the file cannot be opened. Reassign to pavlov%netscape.com.

I'll take this for the javascript bits. We're doing append, initWith etc. instead of their Unicode versions.

Can someone test this?

Hi Peter. I'm still seeing the problem with you patch. When I selected the japanese filename, the text field shows garbage. I don't know well about filepicker, but I guess the following code sets the filename into the textfield. Can you check file.leafName is correct? function onSelect(e) { ... textInput.value = file.leafName; ... }

Whoops, forgot a whole bunch of unicode* attributes. New patch coming up.

Masaki: thank you for testing this, I have tried getting japanese input working but so far haven't succeeded. I believe I now have converted all non-unicode uses to unicode, the only thing which might go wrong is when nsIFile is converted to nsIFileURL, and back (when you double click on a directory / file for example).

Thanks, Peter. Now filepicker with your patch succeeded to display japanese in file: field. I've filed a separate bug 60943 for saving file with japanese filename. Peter and Kato-san, do you think it's the same problem? Actually, with Peter's patch, japanese filename could be created properly. However, I'm still seeing the following problems, - After loading a file with japanese filename, then File->Save As... japanese filename became garbage (I'll attach the snapshot) - Deleted the garbage string, then I entered the japanese, then clicked OK button. The filename of japanese became garbage on Saving File dialog (that dialog is used for downloaing file)

Interesting... After loading a file with a Japanese filename, does the filename display correctly in the URL bar? If I recall correctly, urls are 8-bit, which may be part of the problem here...

In URL field, the file name is displayed as %90V%8BK%C3%B7%BD%C4%95%B6%8F%91 format. I'm seeing the similar problem on WIndows. After I opened a file with japanese filename, Save As ... would not display the filename on File: field (just blank) on WIndows FileSelection box (On Linux, it became garbage). When I opened a file with ascii filename, it would be displayed on File: Field. So, I'm thinking that filepicker in Linux and FIleDIalog of Windows are correct, but data at Mozilla -> filepicker is broken. FIleDialog box of Windows rejects the invalid string, but filepicker shows the garbage. Any comments?

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

The second problem of my comment 2000-12-10 19:36 (garbage on Save File dialog) seems to be bug 42173. Is the first problem (garbage on Save As... Dialog) also the same problem? Kato-san, do you know? Should I file new bug for the first problem? Anyway, I believe the patch for this problem (also bug 60943) is ready. Peter, please check-in the patch if you get code review.

> - After loading a file with japanese filename, then File->Save As... > japanese filename became garbage (I'll attach the snapshot) That problem still exists, right? Is there a good way an URL can contain Japanese characters? Because when you save a file, it takes the URL to determine the filename, and if your URL is incorrect (which it looks like to me, but I might be wrong) your filename will be incorrect as a result.

Katakai-san, please wait until 12/15 since my build environment is borken :-<. I will write fix code...

Added intl, nsbeta1 keywords This bug is a potential showstopper for Sun's NS 6 release

Katakai-san. I found the cause about bug 60943 and screen shot at 12/10. This problem is that converting from URL to local file path. If it selects file, onSelect event occur. In onSelect event, it converts from URL to local path and shows local path. So for fixing this problem, it must not use URL on directory tree.

I think that it fixs rdf/datasource/src/nsFileSystemDatasource.cpp, too...

I tested Peter's patch on RedHat 6.2 + ja-locale. It seems to work fine. But I found a pretty problem. @@ -273,19 +273,19 @@ : : - // window.alert("Directory "+parent.path+" doesn't seem to exist, can't save "+file.path); + // window.alert("Directory "+parent.path+" doesn't seem to exist, can't save "+file.unicodePath); ret = nsIFilePicker.returnCancel; : : please change parent.path -> parent.unicodePath. looks good except to my comment. Katakai-san, If you use Peter's patch, this issue isn't fixed, let me know.

I forgot to answer about Katakai-san's comment. > - Deleted the garbage string, then I entered the japanese, > then clicked OK button. The filename of japanese became > garbage on Saving File dialog (that dialog is used for downloaing > file) This is bug 42173, If this is ship stopper of Sun. Let me know.

add myself to cc list. This bug also happens on HPUX, and will have significant impact on japanese users. file picker related changed a lot after in trunk. Need to figure out a way to fix the bug in branch. Probably incorporate all changes in trunk?

Peter, it seems to me that a fix is agreed by all parties, at least for the open file part. Can you check it into trunk? If you need any help, let me know. Thanks!

Sure, but I'll need an r= and sr= from someone per the checkin rules. Seeing how you have tested this patch, can I use one of you as the reviewer of this patch? I'll get the sr= from someone soon.

sr=blizzard@mozilla.org.

I am working on it now. My current build is oem branch, I need a trunk build to verify this. It should be done pretty soon.

I applied the patch and tested on linux, it works as expected. I believe all changes are reasonable and correct. r = shanjian

Peter, It seems that many changes have been made in trunk. Do you see any risk in adopting those changes in branch? I tried copying nsFilePicker.js, filepicker.js, filepicker.xul, and it works ok on my local branch tree.

As far as I know, all changes made to the xpfe file picker were restricted to and contained within those three files you named, so I think it's safe to synchronize the branch (I assume you're talking about a branch off of the Mozilla 0.6 branch) to the trunk in this regard, without possibly affecting anything else. I will check into the trunk as soon as the tree opens.

Tree opened, fix checked in.

What more needs to be done for this bug?

I just got approval and checked it into oem branch. Peter, you can mark the bug as fixed. thanks.

Marking fixed.

Changed QA contact to ylong@netscape.com.

I checked on 01-09-2001 Mtrunk build. This filepicker issue has been fixed when you try to open a Japanese named file. However, when you want to change the file name of same page by go to [File]|[Save as], then you will see the garbage Japanese file name poped up in "File name" text field of "Save File" dialog. I have another bug 65010 for this issue. Please let me know if