24862 - Chineese Headers encoded with RFC1522 are displaying wrong in forwarded (as attachment) messages

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P3)

Description

[Henrik Gemal]

If you have a mail with the following in the address fields of a forwarded mail 
the string renders really funny. Attached is the mail that gives you funny chars 
and a picture of the result.

Comment 1

[Henrik Gemal]

Attachment: forwarded mails that renders funny addresses

Comment 2

[Henrik Gemal]

Attachment: the result

Comment 3

[Phil Peterson]

The first attachment, with the message contents, doesn't show the funny address. 
Did you get this out of View Source, or the folder itself?

Anyway, reassigning to rhp, cc mscott

Comment 4

[rhp (gone)]

Good catch. I have this fixed in my tree and will checkin when the tree opens 
later today.

- rhp

Comment 5

[rhp (gone)]

Just checked in the fix for this problem.

- rhp

Comment 6

[Henrik Gemal]

I'm using 2000012609 and here's another string that get wrong:
news://news.mozilla.org/388FD504.2589D5B7%40uswest.net

When reading it it renders Japanesse chars!
(See the attachment1 [details] [diff] [review])

When forwarding this post and reading it, it renders Latin1 chars!
(See the attachment2 [details] [diff] [review])

Comment 7

[Henrik Gemal]

Attachment: Mail renders japaneese chars!

Comment 8

[Henrik Gemal]

Attachment: forward mail renders latin1 chars!

Comment 9

[Henrik Gemal]

Actually I meant:
news://news.mozilla.org/388E88FB.9703ED9D%40hotmail.com
but I think the other news URL gets it wrong too!

Comment 10

[leger]

Clearing FIXED resolution due to reopen.

Comment 11

[rhp (gone)]

Ok, I need some I18N help on this one. First, keep in mind that the characters 
that get rendered in 4.x for these headers are WRONG. The garbage looking 
characters (果子探險隊隊員 <[e-mail]>) should be displaying in 
Traditional Chineese (Big5). 

Now, I'm no expert so when you say they are displaying in Japanese, I'll take 
your word for it that you know the difference between Traditional Chineese and 
Japanese, because I sure don't. 

Naoki: Is what we are displaying for this mail message header incorrect?

Now, quoting is another issue and I am looking into that now, but I'm not so 
sure that what is being displayed in the envelope is wrong.

- rhp

Comment 12

[rhp (gone)]

Ok, after consulting with Jeff Tsai (someone who can read Chineese) he assured 
me that this is correct. (From: Translation = "a member of fruit discovery 
adventure team") It is also correct when forwarding inline.

So, I am looking into the forwarding case to see what is going on there.

- rhp

Comment 13

[rhp (gone)]

Ok, we do have a problem with displaying this message when it is forwarded as 
an attachment. Investigating.

- rhp

Comment 14

[rhp (gone)]

Fixing grammar :-)

Comment 15

[rhp (gone)]

Ok, I have a fix for the forwarding issue. I will get this into the tree later 
today.

- rhp

Comment 16

[rhp (gone)]

This should be fixed now.

- rhp

Comment 17

[lchiang]

Henrik or Kat - can you verify this for me?

Comment 18

[lchiang]

cc: kat to see my previous comment

Comment 19

[Katsuhiko Momoi]

Rich, I don't understand just what was fixed.

1. With the example posted by gemal on 1/24/2000,
   there is no MIME-encoding info on the header or body
   part and so unless the user happens to send the mail 
   guessing what the encoding of the article was and setting
   the encoding to match on send, this is not going to 
   work. 

2. The 2nd exmple posted on 1/27/2000 has MIME-encoded (Big5)
   header and charset info (Big5) on body. But since the body contains
   only ASCII, the only display issue would be with the header.
   If you don't set the send encoding explicitly, it used to go out
   following the default charset-- whatever it was. Now it should go out
   honoring the main body body charset (Big5).
   But since the header was properly MIME-encoded, you can see
   it under 4.7 by changing the Viewe | Character Set to Big5 even
   if the main body goes out as something other than Big5 when you
   forward/as attachment -- we don't touch the attached message itself
   in this case.

   Under Mozilla, we decode the MIME-encoded headers of attachments
   with M13 and so it does send & display OK, for example, with 1/25/2000
   build. Forwarded/as attachment msg actually displayed OK
   with M12 also.
   Thus, I don't see that we ever had any problem with these
   messages for forward/as attachment.

Rich, can you explain more in detail just what was fixed?

Comment 20

[rhp (gone)]

The bug was when these RFC1522 messages were forwarded, they would display like 
the following: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=4599

I fixed this a while back with a patch to the emitters.

Does this help.

- rhp

Comment 21

[Katsuhiko Momoi]

Rich, I forwarded/attachment the very same article posted to Mozilla
mail-news group using M12 and M13 as well as the current (2/6/2000) builds.
In none of these cases, we ever touched the MIME-encoded header
of the original msg. And I had no problem displaying it
under 4.7x or Mozilla. When was it broken? Was it broken only
for a few days after M13 went out?

Comment 22

[rhp (gone)]

Believe me...it was broken. It was after mscott landed his performance changes. 
We were not decoding the header that were in the bodies. Please see:

http://bugzilla.mozilla.org/showattachment.cgi?attach_id=4599

for the way it looked. I'm not sure about the exact timing, but it was broken 
and this fixed it.

- rhp

Comment 23

[Katsuhiko Momoi]

Thanks. Then, it sounds like we had a few day problem at some
point. The important thing is that this problem is no
longer observed with 2/6/2000 Win32 build. 
Marking it verified/fixed.