215949 - Incorrect display of attachment filenames in MailNews main window (Japanese only?)

Status: RESOLVED EXPIRED

(MailNews Core :: Internationalization, defect)

Description

[Kalin Kozhuharov]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030808
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030808

Lately I am having problems with attachment filenames in Mail...

I am not sure, but I think in 1.2 tihs was working.

When I get a message with attachment filename that is in Japanese, it's name is
not displayed correctly bu the UI.

The following cases:

Auto detect Japanese off||on -> garbage in file name, mail text is OK; (there is
a dot in front of ISO-2022-JP). If you choose to save as the attachment, file
name is garbage.

Auto detect Japanese off||on; manually select ISO-2022-JP (although it is
selected) -> file name OK, mail text is OK; (there is a dot in front of
ISO-2022-JP). If you choose to save as the attachment, file name is OK (at least
in the dialog box).

* || ->> or, doesn't mater;

In both cases View source (Ctrl+U) works and I can see the name properly
(ISO-2022-JP is selected automatically).


Reproducible: Always

Steps to Reproduce:
1. Get a correctly encoded Japanese mail in ISO-2022-JP with attachment with a
japanese file name.

Actual Results:  
Filename is garbage.

Expected Results:  
Filename is readable.

I think this has something to do with the time autodetect is fired (i.e. mail
body is displayed after autodetect, attachment name before (despite it is after
the body in the actual MSG))

Comment 1

[Kalin Kozhuharov]

Attachment: e-mail MSG with attachment and japanese name (edited)

Concerned about privacy, I snipped some of the text.

Comment 2

[Kalin Kozhuharov]

Attachment: The part of the mail screen that shows attachment filename

Privacy concerned, didn't attach the whole screen.

Comment 3

[Kalin Kozhuharov]

Ok, I did some more poking around and seem to understend that if the name of the
attachment is not in ISO-8859-1, it shoild be "escaped" the same way such a
Subject is escaped... That is something like :
===
Content-Type: image/jpeg;
 name="=?ISO-2022-JP?B?GyRCJUYhPCVWJWsbKEIuanBn?="
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="=?ISO-2022-JP?B?GyRCJUYhPCVWJWsbKEIuanBn?="
===

And Mozilla Mail does that...

So this bug may be invalid or marked "Envagelism"...

Or if we want to suuport broken MUAs (like Outlook) may be we should guess the
encoding according to the main part of the message? It will work with Japanese
Outlooks, at least.

Anybody on this?

Comment 4

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 5

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.