When you type English characters in the title before you save the document, the title will automatically be displayed in the save document dialog. However, if you type Japanese characters in the title, the Japanese title in the Save document dialog is not displayed correctly. Steps of reproduce 1. Open Composer and type Japanese characters 2. Select menu File|Save At this time, the document title "Enter a title for the current page. The title identifies the page in the window title and bookmarks." will show up to ask the user to input the title of the document. 3. Type Japanese characters for the title and click OK Notice that the Japanese title will be displayed as "...html" in "Save Document As" dialog. Tested 1-06-15 Win32 build.

Changed QA contact to teruko@netscape.com

Reassign to cmanske. Charley, I assume this is just a matter of not using a PRUnichar or something. I'm sure ftang or someone in I18n can help you get setup to do debugging on a JA system. Teruko: do you see this problem on other OS/platforms or just Windows?

Frank: We could use your help here! We are getting the title as a PRUnichar*, then copying to a nsString ("title"); Is that OK? If saving for the first time, this title is used as the basis for the suggested filename in the "Save" dialog, after appending ".html". Is the problem that we are trying to append "latin" characters to a Japanese Unicode string? Are Japanese characters allowed for filenames? The relevant code is in the method nsEditorShell::SaveDocument in mozilla/editor/base/nsEditorShell.cpp.

I checked this in Linux (010515 build) and Mac (010515 build). At the step #3, the title you enter when you try to save is not automatiocally displayed in "Save Document As" dialog. In both Mac and linux build, the user has to enter the document name in "Save Document As" dialog.

The following two lines are OK since nsString is PRUnichar * internal. No problem 1293 nsString title; 1294 res = HTMLDoc->GetTitle(title); The prompt part is probably also OK. 1386 fileName = title + nsString(".html"); looks ok since all the operation is under Unicode howerver, I don't think the following is correct 1389 char *leafName = docFileSpec.GetLeafName(); 1390 if (leafName) 1391 { 1392 fileName = leafName; 1393 nsCRT::free(leafName); 1394 } 1395 docFileSpec.GetParent(parentPath); 1396 1397 // TODO: CHANGE TO THE DIRECTORY OF THE PARENT PATH? Also, it is also possible the file widget does not do the right job to convert PRUnichar from the interface to the locale encoding correctly. I think this is an interface problem. XP interface such as file spec should always passing PRUnichar* or nsString around. Then it can do the correct Unicode conversion inside the platform implementation. If you need to convert in the editor code. Then you should convert it by using nsIUnciodeDecoder/Encoder (In this case, convert char* into PRUnichar, use nsIUnicodeDecoder). The charset name can be get by calling nsIPlatformCharset. Ask for the FileName selector.

Thanks for the help. However, when you are saving a newly-created page, the code you think is wrong is not called at all, since we don't have an existing filename. Taruko: Isn't that the condition in which the bug occurs? We are constructing it from the users "Title" supplied in the first dialog. Thus your explanation doesn't tell me why there is a problem! Also, what about my general questions about what characters are allowed in a filename: Are Japanese characters even allowed? I.e., should we do the "make filename out of page title by appending '.html'" only if characters are latin?

Charley, I answer your question. 1. Your explanation doesn't tell me why there is a problem! When the user type the Japanese title at saving, the title characters does not reflected as file name in "Save Document AS" dialog. It shows up as "...html". If the title will automatically be displayed as file name in the Save Document dialog, this behavior is wrong. 2. What about my general questions about what characters are allowed in a filename: Are Japanese characters even allowed? I.e., should we do the "make filename out of page title by appending '.html'" only if characters are latin? Japanese characters are allowed as filename.

I am reassigning this to ftang, Frank can you help us out on this one?

Erik- we have multiple problem here. The nsFileSpec is one of the problem here. Please take a look at this also.

This can be reproduce on my Mac now...

I found the problem on Mac /widget/src/mac/nsFileWidget.cpp 177 PRBool nsFileWidget::Show() 178 { 179 nsString filterList; 180 GetFilterListArray(filterList); 181 char *filterBuffer = filterList.ToNewCString(); 182 183 Str255 title; 184 Str255 defaultName; 185 nsMacControl::StringToStr255(mTitle,title); 186 nsMacControl::StringToStr255(mDefault,defaultName); It convert nsString to Str255 by using nsMacControl::StringToStr255 I think for Mac, we should fix this by changing the implementation of 380 void nsMacControl::StringToStr255(const nsString& aText, Str255& aStr255) 381 { 382 char buffer[256]; 383 384 aText.ToCString(buffer,255); 385 386 PRInt32 len = strlen(buffer); 387 memcpy(&aStr255[1],buffer,len); 388 aStr255[0] = len; 389 } 390 391 //------------------------------------------------------------------------- 392 // 393 // 394 //------------------------------------------------------------------------- 395 396 void nsMacControl::Str255ToString(const Str255& aStr255, nsString& aText) 397 { 398 char buffer[256]; 399 PRInt32 len = aStr255[0]; 400 401 memcpy(buffer,&aStr255[1],len); 402 buffer[len] = 0; 403 404 aText = buffer; 405 } to convert from/to system script Same problem in Window /widget/src/windows/nsFileWidget.cpp 90 PRBool nsFileWidget::Show() 91 { ... 93 mDefault.ToCString(fileBuffer,MAX_PATH); ...... 102 char *filterBuffer = filterList.ToNewCString(); 103 char *title = mTitle.ToNewCString(); this conversion is not good. We need to convert to CP_ACP as what we did for window title. Also, in widget/src/gtk/nsFileWidget.cpp 109 PRBool nsFileWidget::Show() 110 { ... 115 116 gtk_file_selection_set_filename(fs, (const char*)nsAutoCString(mDefault)); It should convert the mDefault from nsString to the file system encoding.

add pierre to the CC since he wrote StringToStr255, and Str255ToString. Pierre- are you ok if I change these two function to convert to Unicode from/to Str255 by using TEC and assume the charset in System Script ?

Pierre: do you mind that we change the implementation of Str255ToString and StringToStr255 by using TEC to convert to the system script instead of droping the higher 8 bits as what we currently did. Reassign to nhotta for help. Naoki- this should be easy to fix, you need to call the native converter and convert from/to smSysScript on mac, CP_ACP on Window and the charset of the locale (by using nsIPlatformCharset) on Gtk.

Why do we need to call native converters instead of the xpcom converter?

It's fine with me: you can fix Str255ToString and StringToStr255. I will let you guys figure out what's the best way to do it (TEC or xpcom). Note: I just opened bug 24948 which is maybe related to that one.

Could someone clarify if this is a [PP] bug as the summary says or not (i.e. I need to fix for all platforms)?

Removing [PP] from the summary, implementation is platform specific but the bug itself is not platform specific.

Removing "pp" from the keywords field for the same reason.

Checked in a fix for windows (only).

Checked in for Macintosh too, available for verification (Windows and Macintosh).

I am not confident fixing this for unix, any volunteer (Tao, Frank)?

Adding Xianglan to cc. Xianglan, could you try to reproduce this problem on Linux?

Checked with 2000013114 linux build. It is reproducible. The Japanese title shows as "....html" on the file save dialog window.

nhotta, Did you use ftang's suggestions from his comment on 2000-01-24 15:00? He included a suggested patch for GTK too.

Whoops. ftang did not suggest a patch as I just commented, he just noted the problem... ftang wrote: 116 gtk_file_selection_set_filename(fs, (const char*)nsAutoCString(mDefault)); It should convert the mDefault from nsString to the file system encoding. But I assume he meant to convert to the current locale encoding instead of the "file system" encoding. On Unix, wouldn't that be our best guess?

I think nsIPlatformCharset::GetDefaultCharsetForLocale() can be used for unix.

Checked in for unix, marking as FIXED.

PDT+ in case it gets reopend

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

For verification, please also try Bug 22863. Note that need localized Japanese systems for Windows and Macintosh to verify. Linux, set locale to ja_JP.EUC.

I verified this in 2000020315 Mac and 2000020108 Win32 build. I cannot verify this in Linux build because of bug 26252.

I tested on 2000-02-04-10-M14 + Windows NT 4.0 SP6a JPN. BUG 22863 isn't fix!!!! hotta san seems to understand BUG 22863. The Problem of BUG 22863 is nsFileSpec of XPCOM (and nsFileWidget). I think that BUG 22863 should not dup to this.

I reopened 22863 instead of this bug.

> hotta san seems to understand BUG 22863. No, I was not able to reproduce that. >The Problem of BUG 22863 is nsFileSpec of XPCOM (and nsFileWidget). Thanks, I mentioned that in 22863.

I verified this in 2000021008 Linux build.