75449 - Attachment name is garbled when attachment is forwarded inline

Status: VERIFIED FIXED

(MailNews Core :: Internationalization, defect, P2)

Description

[marina]

*** observed with 2001-04-10 build ***
Steps to reproduce:
- compose a mail with non-ascii chars in the Subject field;
- forward this message as an attchment;
- get message, select it and forward inline this time;
//note: non-ascii chars are garbled in the attachment area when getting attached 
and when you'll get this email click on the envelope and observed garbage for 
the attachment name

Comment 1

[nhottanscp]

This is a new problem or also happens with NS 6.0/6.01?

Questions:
>- compose a mail with non-ascii chars in the Subject field;
What charset did you choose? Did the non-ascii chars have valid code points with 
that charset?
>- forward this message as an attchment;
What charset did you choose for the forwading message? Was that the same charset 
as the original?
>- get message, select it and forward inline this time;
What charset did you choose for this?

Comment 2

[marina]

< compose email with non-ascii chars in the Subject field:
 two test cases :
first: used accented chars for the first scenario(
        tést ön prügres)
- sent them out as latin-1;
second: cyrillic chars , sent them out as Cyrillic KOI8-R;
( result is the same: forwarding inline an email that was forwarded as an 
attachment garbles the header);
i'll report about 6.01
 

Comment 3

[marina]

it doesn't happen in the rtm build, added regressin keyword

Comment 4

[nhottanscp]

I am still not clear about the procedure.
Do I have to forward twice, as attachment first then as inline with the same
charset?

Comment 5

[marina]

yes, that the sequence: forward twice (as an attachment first and as inline 
after it)

Comment 6

[nhottanscp]

Is the first foward attachment is really needed to reproduce?
If you forward as inline first then you don't see the problem?

Comment 7

[marina]

to repro it you have  to forwarded as an attachment first and then inline,
because the problem is seen in the attachment area and when you forward inline
the attachment doesn't show up there, i'll attach a screen shot

Comment 8

[marina]

Attachment: screen shot of the garbled string

Comment 9

[marina]

Attachment: a screen shot for the envelope (cyrillic message sent out as KOI8-R in both cases)

Comment 10

[nhottanscp]

I see, not header in the thread pane, not header in the quoted body, but the
string of the attachment.

Comment 11

[nhottanscp]

So do you see any other problem related to this (like the body cannot be seen)
or just the attachment names are garbled?

Comment 12

[marina]

just the attachment names are garbled, body and subject in the thread are fine; 
changing the summary to clarify the problem

Comment 13

[nhottanscp]

Could you attach the two messages?
One after the forward as attachment, other after the forward as inline?
I would like to see where the data got broken.

Comment 14

[marina]

Attachment: this a message after forwarding as an attachment

Comment 15

[marina]

Attachment: the message after being forwarded inline

Comment 16

[marina]

what i found out is that the problem is generic, not non-ascii only case. The
problem is in Mozilla incorrectly treating space in the headers while displaying
the file name. Look at the scree shot of the ascii file name displayed
incorrectly in the attachment area. Naoki, please reassign to core people

Comment 17

[marina]

Attachment: screen shot of the wrong display of the attachment name

Comment 18

[nhottanscp]

The latest screen shot shows %20 which is space but it's also has something else
like %5B and %5C.
Please try again with ASCII only case.

Comment 19

[marina]

The latest screen shot is pure ascii case: as far as i understand %5B and %5C
stand for ":" and "[]"

Comment 20

[nhottanscp]

That's right, let me change the summary and reassign to putterman.

Comment 21

[scottputterman]

reassigning to varada, cc'ing ducarroz.  Is this related to recent checkins
regarding the attachment name?

Comment 22

[varada]

The reason you see it as garbled is because we escape the characters. This was
done to fix another bug about not being able to forward inline any message that
was sent from a reply or forward message. We have a bug to fix the UI for the
attachments. 

Comment 23

[ji]

QA contact to marina.

Comment 24

[nhottanscp]

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

Comment 25

[Jaime Rodriguez, Jr.]

This should be considered as must fix, as it is a regression, and it has been
hit by multiple people testing the product. Please assign M0.9.1

Comment 26

[scottputterman]

Sounds like this might be a dup of http://bugzilla.mozilla.org/show_bug.cgi?id=43689

Comment 27

[marina]

as far as i understand bug # 43689 the problem is observed when the attachment
is open from the envelop in a new browser window and is for JA file names, the
problem in this bug report is generic: it happens with ascii file names as well
and in different place: in composition window 

Comment 28

[Jaime Rodriguez, Jr.]

Varada - What's the status on this one?

Comment 29

[scottputterman]

moving to 0.9.2

Comment 30

[marina]

i think we have to consider fixing this bug because it effect Edit as new case
as well. Even though it is a core ( not specifically Intl) bug a lot of inlt
users will be affected ( attachment with ascii letters is somewhat readable
whereas non-ascii ones look like garbage)

Comment 31

[Jaime Rodriguez, Jr.]

Removing intl keyword, per Marina's comments.

Comment 32

[varada]

Patch in hand

Comment 33

[varada]

Current patch is not good - working on a better solution.

Comment 34

[varada]

There are few more parts to this bug than what met the eye.
1-on winnt (us verson) attach a file with a iso-8859-1 name like (prügres.txt).
 send as normal (not as latin-1)when it arrives, name of attachment is "pr".

2-fwd inline of a  fwd attached, the inner message mime type is Content-Type:
text/html, not message/rfc-822

3-
Content-Type: message/rfc822;
 name="=?iso-8859-1?Q?t=E9st=20=F6n=20pr=FCgres?=" -4.x

Content-Type: text/html;
 name="t%E9st%20%F6n%20pr%FCgres" -6.x

Comment 35

[scottputterman]

adding PDT+, but as we discussed, let's see if we can get a safe fix in the next
couple of days. If not, we'll move into 0.9.3.  If you don't think that's enough
time then let's move into 0.9.3

Comment 36

[varada]

Attachment: Patch V1

Comment 37

[varada]

This patch fixes the compose front-end escaping of the attachment name as well
as inserts the correct Content Type for the forwarded attachment.

Comment 38

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

talked to varada, he's going to use NS_MsgHashIfNecessary() to make the file
name safe for the underlying OS.

Comment 39

[varada]

Attachment: Patch V 2

Comment 40

[varada]

Attaching new patch with using NS_MsgHashIfNecessary and separating the
extensions before the hash.
r=ducarroz

Comment 41

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

there are some edge cases that we have to defend against, and varada's got a new
patch that addresses them.

Comment 42

[varada]

Attachment: Patch V 3

Comment 43

[varada]

Attached new version of patch to address the edge case concerns.

Comment 44

[Jean-Francois Ducarroz]

oh good, you addressed the <giant string>.<giant string> case. R=ducarroz

Comment 45

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

sr=sspitzer

Comment 46

[Asa Dotzler [:asa]]

a= [e-mail] for checkin to the trunk.
(on behalf of drivers)

Comment 47

[varada]

Marking Fixed.

Comment 48

[varada]

Really Marking Fixed.

Comment 49

[marina]

varada, so we are not using the file name when forwarding inline? all i see is
e472d61f.eml..?

Comment 50

[marina]

because we are escaping the file name in the attachment now ( is that the same
as  the "salted" file name while downloading?) this bug is fixed, verifying...