701818 - Forward message, attachment's name changed (charset of attachment part is used in Forward window, without proper character conversion of message body and filename parameter)

Status: RESOLVED DUPLICATE of bug 1026989

(MailNews Core :: Composition, defect)

Description

[raal]

Attachment: test forwarding message.eml

User Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Build ID: 20110928224103

Steps to reproduce:

1- I got an message with attachment name contains special czech characters (všb.jpeg)
2 - forward a message


Actual results:

attachment's name changed to "�"


Expected results:

atachment's name unchanged.
Tested on win, linux. TB version 7 and 10.

Comment 1

[raal]

Attachment: printscreen incoming message

Comment 2

[raal]

Attachment: forward

Comment 3

[Hashem Masoud]

(In reply to raal from comment #2)
I downloaded your attachment and forwarded it. I didn't get this issue. I can see the attachment name with correct characters both in the sent folder and recipient inbox.

I viewed the source of my forwarded e-mail, this is the part where the attachment name is mentioned:

Content-Type: image/jpeg;
 name="=?ISO-8859-2?Q?v=B9b=2Ejpeg?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename*=iso-8859-2''%76%B9%62%2E%6A%70%65%67

Maybe my configuration allows correct name of attachment to be displayed.

Comment 4

[raal]

Hello Mashem,
the same in my TB -  when I open .eml message from hard disk and forward this message,  then see no problem.
Problem is only when I get message to inbox.
I sent to you testing message, please try to forward.

Comment 5

[WADA:World Anti-bad-Duping Agency]

(In reply to raal from comment #4)
> Problem is only when I get message to inbox.

What is your Folder Properties/General, Default Character Encoding setting?
Is "Apply deault to all message ..." checked?

How did you open the Forward window?

If you open utf-8 mail in message pane(the utf-8 mail is selected at thread pane), and if you execute right-click/Forward of a mail at thread pane without left-click, compose window is opened in utf-8 but binary of original charset is used, then garbled display happens. This is known bug.
This is seen at window title(utf-8 is shown because your default character encoding of outgoing message is not utf-8) and at attachment name string of message body in your screen shot.

Different issue but same phenomenon is also reported on draft mail to bug 701694. Different charset from original(utf-8) is used in composition window, but conversion from original charset to utf-8 is not done.
Similar problem to bug 701694?

> Content-Type: image/jpeg;
>	charset=utf8;
>	name="=?iso-8859-2?Q?v=B9b=2Ejpeg?="

"charset=utf8; in Content-Type:" may be relevant to "U+FFFD in attachment pane of forward window" in your case.

Comment 6

[WADA:World Anti-bad-Duping Agency]

Attachment: Test mails : charset=utf-8/charset=koi8-r/no charset in attachment part

charset parameter in Content-Type: of attachment part was cause of problem.
How Forward is executed was irrelevant. Simplest Forward button of mail is sufficient.

(1) Forward => Composition window = utf-8,
               Attachment's name : in message body   : v¹b.txt  
                                   at attachment box : �
> Content-Type: text/plain; charset=utf-8; name="=?iso-8859-2?Q?v=B9b=2Etxt?=" 
> Content-Disposition: inline; filename="=?iso-8859-2?Q?v=B9b=2Etxt?="
(2) Forward => Composition window = koi8-r, Attachment's name : v╧b.txt 
> Content-Type: text/plain; charset=koi8-r; name="=?iso-8859-2?Q?v=B9b=2Etxt?=" 
> Content-Disposition: inline; filename="=?iso-8859-2?Q?v=B9b=2Etxt?="
(3) Forward => Composition window = iso-8859-2, Attachment's name : všb.txt 
> Content-Type: text/plain; name="=?iso-8859-2?Q?v=B9b=2Etxt?=" 
> Content-Disposition: inline; filename="=?iso-8859-2?Q?v=B9b=2Etxt?="
Note: Any "αβγ" in attachment part is written in utf-8, so it's shown as garbage when koi8-r case.

Perhaps charset of last part is used in composition window opened by Forward, without proper character conversion from original charset, for both message body data and filename parameter in Content-Disposition.
So, if the forward mail is sent, next occurs;
(1) Some texts in message body is corrupted, and in worst case, almost all message data is corrupted if origial charset or wrongly used charset is special charset like iso-2022-jp.   
(2) Filename of attachment is altered or garbled.

Comment 7

[raal]

What is your Folder Properties/General, Default Character Encoding setting?
Central european (iso-8859-2)
Is "Apply deault to all message ..." checked?
No

How did you open the Forward window?
Button Forward or right-click on message/forward

Comment 8

[WADA:World Anti-bad-Duping Agency]

When Reply, problem of "charset of attachment part is used by composition window" ocurrs too, but problem of "message data is not converted to used charset" doesn't occur. So, "garbled atachment name string in message body" is not observed if Reply.

Comment 10

[raal]

Regression. tested with old TB 2.0.0.4 - forwarding of "test forwarding message.eml" is correct, attachment name is všb.jpeg

Comment 11

[WADA:World Anti-bad-Duping Agency]

Setting dependecy to bug 716983 for ease of tracking and analysis.

Comment 15

[WADA:World Anti-bad-Duping Agency]

Root cause of "charset is pcked up from last attachment" was resolved by bug 1026989 at last.

Some valuable bug reports from users were hidden/lost/ignored by "duping to bug 716983, then duping bug 716983 to other bug".
Unfortunately, or fotunately, only "garbled display in Forward Inline case" was resolved by unknown bug while the other bug was being processed, so nothing was resolved by the other bug.

Duping this bug to bug 1026989, for ease of tracking, search, understanding current status of problem.

Comment 16

[WADA:World Anti-bad-Duping Agency]

FYI.
Patch of bug 1026989, one liner patch, was proposed in the other bug to which bug 716983(and bug 701818 too) had been duped to. The patch was dig out from the other bug by bug 1026989, and long lived "charset is picked up from last attachment" issue has been resolved by bug 1026989.

Why such "digging out hidden important patch from the other bug" should be needed in B.M.O?