Build: 2000060508 comm When settting the file path for signature file, if the file path contains Ja characters, the file path is displayed as garbage on the file dialog window. Steps of reproduce: 1. Create a signature file with a Japanese filename under a Japanese directory name. 2. Launch Mail. 3. Select Edit | Mail/News Account Settings. 4. Click on Choose button to set the file path of signature file, you'll get a file dialog window. On this file dialog widow, the directory and file name in the filepath of the signature file is displayed garbage. But after you choose the signature file, the filepath is displayed alright on the account setting window. This doesn't happen on Windows.

I mentioned that after choosing the signature file, the filepath is displayed alright on the account setting window. But I noticed that after the setting is saved and opened again, the filepath is displayed as garbage as well. These two problems may be related. Please let me know if I need to file a seperate bug for this

>But I noticed that after the setting is saved and opened again, >the filepath is displayed as garbage as well. Is this also Linux only?

No. It also happens on Windows. Will file a separate bug for it.

Bug 41606 has been filed for the second problem.

put pp Scott please reassign to the owner of this.

reassigning to alecf.

really reassigning this time.

mass moving to M18 and adding nsbeta3 keyword

A duplicate of 41083, or the other way????

This sue does look like a duplicate of Bug 41083. ji, please comparte the 2 bugs and see if you can resolve this and Bug 41606 as duplicates of thefirst one.

This is a linux specific bug. The Ja signature file path is initially displayed as garbage on the file dialog window which is popped up by clicking the Choose button on the account setting window. This is not a dup of 41083, but 41606 is.

I have fixed the prefs issue (36965) so I can now fix this bug very easily.

Adding mail2 nomination keyword for triage effort.

+ per mail triage

- per mail triage. Since "after you choose the signature file, the filepath is displayed alright on the account setting window."

Marking future.

Actually I have a fix in hand, and I have to fix this to fix 42102

The file dialogue window for attch file also has this problem. To reproduce: 0. Have a Japanese directory name and filename somewhere in your machine. 1. Open mail compose window. 2. Click on Attach button 3. On the file dialogue window, go to the place where you have Ja directory name and filename On the directory/file list, the Japanese directory name and file name are displayed alright. But once you select it, it will be displayed garbled on the filepath. Nominating for rtm.

marking [rtm-]

sorry for the extra email. Removing mail2 keyword.

filters/search UI->gayatrib

oops back to me

Moving this bug to sspitzer. I think we should fix this bug before the next release.

Is this a dup of 60941?

No, hotta-san, this bug depends on bug 60941, but not dup bug.

This bug occurs since it uses datatype="nsIFileSpec" on am-main.xul We should rewrite to nsILocalFile.

sorry. you ignore my comments. Hotta-san, That's right!! This bug should be dup of 60941

marking nsbeta1- as per I18N triage. But if we have a fix in hand already, feel free to pursue it.

Mass change of QA contact to ji for the bugs filed by her.

ji, could you reproduce on latest build?

hotta san, could you review?

Please also ask sspitzer for a review. My questions, * What is GetFilePref -> GetFileXPref for? * In nsMsgCompose.cpp, it's converting back to nsIFileSpec. Is this because msgCompose uses nsIFileSpec? Would it be a big change if you also need to change msgCompose to use nsILocalFile? * In nsMsgComposeParams.h, +#include "nsString.h", is this related to this bug?

Checked the latest linux mtrunk build (2001-01-29-08-mtrunk). The problem originally described in the report is gone.

> * What is GetFilePref -> GetFileXPref for? Because I want to use nsILocalFile. This problem is nsIFileSpec. > * In nsMsgCompose.cpp, it's converting back to nsIFileSpec. Is this > because msgCompose uses nsIFileSpec? Would it be a big change if > you also need to change msgCompose to use nsILocalFile? I already tried changing to all nsILocalFile. But nsIFileStreams.h and nsIFileStream.h occured conflict... So this change is too hard since all mailnews codes must change. > In nsMsgComposeParams.h, +#include "nsString.h", is this related > to this bug? Because I changed from #include "nsFileSpec.h" to #include "nsILocalFile.h". nsFileSpec.h include nsString.h

Xianglan, you mentioned that the original problem has gone. Is there any remaining problem?

The system I tested with is RH6.2J and it only has EUC support. The path containing Ja characters can be displayed correctly in the file dialogue window. The only convern left is the shift-jis locale support in UNIX environment, like HPUX. If it works in shift-jis locale, we can resolve this as worksforme. Added shanjian on the CC list.

Katakai-san has Solaris. Maybe he or Tajima-san can check this on their Solaris under Shift_JIS locale.

I changed FileSpec code since old code may not work on Mac and I resolved conflict. Original bug is occured since it uses nsIFileSpec as datatype on XUL. Also, bug 66868 is the same issue. But bug 66868 is other point.

I've verified Kato-san's latest patch on Solaris EUC and Shift_JIS locale.

Checked 05/17 trunk build. It's fixed even w/o Kato-san's patch. Resolved it as fixed. Please reopen it if you see the problem in SJIS locale.

Verified.