Closed Bug 43689 Opened 20 years ago Closed 18 years ago

Attachment filename in Ja is displayed as raw utf-8 string on Open/Save attachment dialog window


(MailNews Core :: Internationalization, defect, P3)



(Not tracked)



(Reporter: ji, Assigned: mscott)



(Keywords: intl)


(5 files, 1 obsolete file)

Build: 2000062309 comm build.

On the Open/Save attachment dialog window, the attachment filename in Japanese
is displayed as a raw UTF-8 string.

Steps of reproduce:
1. Launch Mail.
2. Compose a mail, attach a file with the filename in Japanese, sent the mail
   to the testing account itself after selecting View | Character Coding | 
Japanese (ISO-2022-JP)
3. After receiving the mail, click on the attachment icon and select the 
attachment file. The Open/Save Attachment dialog window comes up. On that
window the attachment file has its Ja filename displayed as a raw utf-8 string.
Attached image Attached a screen shot.
Reassign to mscott.
Assignee: nhotta → mscott
Summary: Attachment filename in Ja is displayed as raw utf-8 string on Open/Save attachment dialog window. → Attachment filename in Ja is displayed as raw utf-8 string on Open/Save attachment dialog window.
*** Bug 43881 has been marked as a duplicate of this bug. ***
jefft was the actual author of this dialog. Over to Jeff.
Assignee: mscott → jefft
Keywords: nsbeta3
Target Milestone: --- → M18
Keywords: mail2
Per i18n/mail triage meeting, this bug is classified
as [nsbeta3-]. There seems to be little usability impact
from this bug. In future, we might simply not show the
file name in this dialog window.
Qa contact to ji.
QA Contact: momoi → ji
Whiteboard: [nsbeta3-]
I'm pretty sure this is fixed...
Please check!
Yes, it's working now.
Closed: 20 years ago
Resolution: --- → WORKSFORME
Marked it as verified.
removing mail2 keyword.
Keywords: mail2
Repros on 02-15-06 + Win98-JA
Click attachment for message, select Save to Disk.

New attachment: Screen shot of raw utf-8 string in Save as dialog

Please change Status to REOPENED to reactivate this report.
(**Who do I need to see to obtain privileges so I can make this kind of 
administrative change myself in the future?**)
Reproducible on linux 02/14 mtrunk build as well.
Reopened the bug and changed QA contact to Wesley.
Keywords: intl
QA Contact: ji → wesleyg
Resolution: WORKSFORME → ---
Target Milestone: M18 → ---
Reassign to putterman.
Assignee: jefft → putterman
Changing qa contact from wesleyg to ji.
QA Contact: wesleyg → ji
This looks cosmetic to me, but I guess the real question si, would we accept
this for the US product? Maybe for beta, but not for final.

Adding nsbeta1 keyword.
Adding nsbeta1 keyword, was not not added.
Keywords: nsbeta1
moving to 0.9.2 and reassigning to varada.
Assignee: putterman → varada
Whiteboard: [nsbeta3-] → [nsbeta1+]
Target Milestone: --- → mozilla0.9.2
oops, misread the bug and thought it was an attachment in the compose window. 
Reassigning to mscott.
Assignee: varada → mscott
OS: Windows NT → All
Marking as nsCatFood and RTM. IMHO the user should now what they are saving in 
confirmation dialogue (e.g. Saftey).
Keywords: nsbeta3nsCatFood, rtm
Summary: Attachment filename in Ja is displayed as raw utf-8 string on Open/Save attachment dialog window. → Attachment filename in Ja is displayed as raw utf-8 string on Open/Save attachment dialog window
moving to 0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
I'm curious. when the helper app dialog comes up with the Open/Save options we
show the name of the attachment in the windows titlebar at the top of the
dialog. does the file name render correctly there too? Or is it showing the raw

As far as the file name in the save to disk dialog if you select "save to disk"
from the helper app dialog, looks like the problem is here:
    nsXPIDLCString leafName;
    if (leafName)

we get the file name from the url which must be UTF-8 I'm guessing. Then we put
it in a unicode string. Looks like AssignWithConversion is the wrong thing to
use here. Maybe a NS_ConvertUTF8toUCSII would do the trick instead?
Checked this with 07/17 win32, linux and mac branch build.
The problem doesn't exist anymore.
Is there any fix checked in for this?
I'll mark this as wfm for now. I'll reopen if I see this again.
Closed: 20 years ago19 years ago
Resolution: --- → WORKSFORME
If the attachment file doesn't have extension and filename contains space, '[' 
or ']', or filename is in Japanese, the filename is shown as a UTF8 url string 
after received.
Please see bug 91359.
ji are you sure this works if you FIRST see the helper app dialog and then click
save to disk? 

If you are saving the attachment directly from the mail window, w/o seeing the
helper app dialog first, then we have special code in mailnews to convert the
attachment name to unicode to make sure it shows up correctly. 

I'm not sure why this would suddenly be fixed through the save to disk dialog
from the helper app code because I haven't changed it in so long. Although I
won't complain if you say it's fixed =).
Yes, you are right. When I try to save an attachment file, like .vcf file from 
helper dailog, the ja filename is shown as raw utf8 string.
No problem when I save from mail window.
Thanks, and reopening..
Resolution: WORKSFORME → ---
Attached patch possible fix (obsolete) — Splinter Review
Unfortunately on my windows machine, when I bring up a file picker with a pre
filled in file name which contains japanese characters, my OS leaves the file
picker empty. No file name is prefilled. So I can't verify that this patch fixes
the problem but I think it will. The file name (which is an escaped UTF-8
string) was not being unescaped before I was converting it to unicode. 

Many thanks to Shirley for helping me get my OS showing japanese characters. 

This patch is also going to fix 71735 so I'm going to check it in under that bug
and we can see if it fixes this bug too on proper japanese machines. 
Ok, I've gone ahead and checked my patch in. shirley, can you give this a whirl
in Monday's release builds to see if really fixes things for you? Thanks!
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
Verified with 08/10 trunk build. It's fixed. 
It's broken on 10/12 0.9.4 build. 
Resolution: FIXED → ---
Added nsbeta1 keyword.
Keywords: nsbeta1
i wonder why this broke again....
Target Milestone: mozilla0.9.3 → mozilla0.9.6
moving to 0.9.9
Whiteboard: [nsbeta1+]
Target Milestone: mozilla0.9.6 → mozilla0.9.9
Keywords: nsbeta1nsbeta1+
Shirley, does this regression happen for both local and imap mail messages? I'm
wondering if the problem is just with one mail protocol or both of them. Thanks!
Rechecked with 01/24 build, it happpens for both local and imap messages.
Attached patch the fixSplinter Review
The patch for this bug exposes the unescaped suggested file name string the
exthandler is already keeping track of to the helper app dialog. When the
dialog goes to fill in the Title string it will now use the suggested file name
if that name is present. If it isn't, it falls back to trying to extract the
filename out of the url we are running. 

In addition to fixing this bug for mail, this has the added benefit for the
browser of showing the file name retrieved from the content dispostion header
as the filename we put in the window title for the helper app dialog.
Attachment #42898 - Attachment is obsolete: true
Comment on attachment 66393 [details] [diff] [review]
the fix

Attachment #66393 - Flags: review+
fix checked in. 
Closed: 19 years ago18 years ago
Resolution: --- → FIXED
Verified as fixed with the latest trunk build.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.