Closed Bug 23384 Opened 20 years ago Closed 20 years ago

Japanese title is not display in Save document dialog

Categories

(Core :: DOM: Editor, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: teruko, Assigned: nhottanscp)

Details

(Whiteboard: [PDT+] fixes checked in for Win & Mac. waiting 26252 to verify Linux build)

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.
QA Contact: sujay → teruko
Changed QA contact to teruko@netscape.com
Assignee: beppe → cmanske
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?
Status: NEW → ASSIGNED
Target Milestone: M14
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.
Summary: Japanese title is not display in Save document dialog → [PP]Japanese title is not display in Save document dialog
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.
Assignee: cmanske → ftang
Status: ASSIGNED → NEW
Target Milestone: M14
I am reassigning this to ftang, Frank can you help us out on this one?
Status: NEW → ASSIGNED
Target Milestone: M14
Erik- we have multiple problem here. The nsFileSpec is one of the problem here. 
Please take a look at this also.
Keywords: pp
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. 
OS: Windows NT → All
Hardware: PC → All
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.
Assignee: ftang → nhotta
Status: ASSIGNED → NEW
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.
Status: NEW → ASSIGNED
Summary: [PP]Japanese title is not display in Save document dialog → Japanese title is not display in Save document dialog
Removing "pp" from the keywords field for the same reason.
Keywords: pp
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.
Whiteboard: fixes checked in for Win & Mac.
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.
Keywords: beta1
Checked in for unix, marking as FIXED.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
PDT+ in case it gets reopend
Whiteboard: fixes checked in for Win & Mac. → [PDT+] fixes checked in for Win & Mac.
*** 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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I reopened 22863 instead of this bug.
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
> 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.
Whiteboard: [PDT+] fixes checked in for Win & Mac. → [PDT+] fixes checked in for Win & Mac. waiting 26252 to verify Linux build
I verified this in 2000021008 Linux build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.