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

Status: VERIFIED FIXED

(MailNews Core :: Internationalization, defect, P3)

Description

[ji]

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.

Comment 1

[ji]

Attachment: Attached a text file with a Japanese filename.

Comment 2

[ji]

Attachment: Attached a screen shot.

Comment 3

[nhottanscp]

Reassign to mscott.

Comment 4

[nhottanscp]

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

Comment 5

[Scott MacGregor]

jefft was the actual author of this dialog. Over to Jeff.

Comment 6

[Katsuhiko Momoi]

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.

Comment 7

[Henrik Gemal]

I'm pretty sure this is fixed...
Please check!

Comment 8

[ji]

Yes, it's working now.
Thanks.

Comment 9

[ji]

Marked it as verified.

Comment 10

[scottputterman]

removing mail2 keyword.

Comment 11

[Wesley George]

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

Comment 12

[Wesley George]

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?**)

Comment 13

[ji]

Reproducible on linux 02/14 mtrunk build as well.
Reopened the bug and changed QA contact to Wesley.

Comment 14

[nhottanscp]

Reassign to putterman.

Comment 15

[Andreas Becker]

Changing qa contact from wesleyg to ji.

Comment 16

[Jaime Rodriguez, Jr.]

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.

Comment 17

[Andreas Becker]

Adding nsbeta1 keyword, was not not added.

Comment 18

[scottputterman]

moving to 0.9.2 and reassigning to varada.

Comment 19

[scottputterman]

oops, misread the bug and thought it was an attachment in the compose window. 
Reassigning to mscott.

Comment 20

[Jaime Rodriguez, Jr.]

Marking as nsCatFood and RTM. IMHO the user should now what they are saving in 
confirmation dialogue (e.g. Saftey).

Comment 21

[scottputterman]

moving to 0.9.3

Comment 22

[Scott MacGregor]

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
UTF-8?

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;
    url->GetFileName(getter_Copies(leafName));
    if (leafName)
      mSuggestedFileName.AssignWithConversion(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?

Comment 23

[ji]

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.

Comment 24

[ji]

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.

Comment 25

[Scott MacGregor]

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 =).

Comment 26

[ji]

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..

Comment 27

[Scott MacGregor]

Attachment: possible fix

Comment 28

[Scott MacGregor]

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. 

Comment 29

[Scott MacGregor]

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!

Comment 30

[ji]

Verified with 08/10 trunk build. It's fixed. 

Comment 31

[ji]

It's broken on 10/12 0.9.4 build. 

Comment 32

[ji]

Attachment: A screenshot of the dialog when openning a file with Ja filename.

Comment 33

[ji]

Added nsbeta1 keyword.

Comment 34

[Scott MacGregor]

i wonder why this broke again....

Comment 35

[scottputterman]

moving to 0.9.9

Comment 36

[Scott MacGregor]

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!

Comment 37

[ji]

Rechecked with 01/24 build, it happpens for both local and imap messages.

Comment 38

[Scott MacGregor]

Attachment: the fix

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.

Comment 39

[Bill Law]

Comment on attachment 66393 [details] [diff] [review]
the fix

r=law

Comment 40

[(not reading, please use [e-mail] instead)]

Comment on attachment 66393 [details] [diff] [review]
the fix

sr=sspitzer

Comment 41

[Scott MacGregor]

fix checked in. 

Comment 42

[ji]

Verified as fixed with the latest trunk build.