231732 - Unusual email address displays correctly, can not be replied to

Status: RESOLVED DUPLICATE of bug 229399

(MailNews Core :: Composition, defect)

Description

[Kim Davies]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113

The following header in a email message displays correctly, but when you try to
reply to it - Mozilla seperates it into multiple invalid addresses:

From: Example Name =?iso-2022-jp?B?GyRCPzkyPEJZOSgbKEI=?= <[e-mail]>

When you hit reply you get

To: Example
To: Name
To: <junk>

None of the components are the correct address, [e-mail]. The "junk" is
not a correct representation of the encoded part, which should be Japanese
characters.

Reproducible: Always

Steps to Reproduce:
1. Create an email message with "From: Example Name
=?iso-2022-jp?B?GyRCPzkyPEJZOSgbKEI=?= <[e-mail]>" as a header. 
2. Reply to this message
Actual Results:  
As above.

Expected Results:  
Should reply to "Example Name (some japanese characters) <[e-mail]>"

Comment 1

[Max Alekseyev]

It's a different issue but symptoms are similar to bug 122972

Comment 2

[Mike Cowperthwaite]

Kim Davies, I am trying to reproduce this problem and do not see the same 
symptoms, exactly.  I'm using 1.7.2 and 1.8a3-0806 (Win2K).  

I do see the junk, but it's all on a single Reply line:
  Example Name ?$B?92
(actually, the first ? appears as the No-Such-Glyph empty box).  As noted, the 
mail address is not included in the junk.

Also, the text inside the address field is not completely selectable (using the 
mouse or Ctrl-A) which I believe is another bug, related to the undisplayable 
glyph.  

Does this match your experience with a current build?


The From: address given as an example at bug 252240 has a similar issue.  That 
one *does* split into multiple pieces, because an unquoted comma exists in the 
name, but that's a separate thing.

Bug 122972 does show the symptoms of a name being split into multiple pieces 
(again because of a comma), but not the junk translation.  Since with a current 
build I'm not seeing the name split with this particular header (which contains 
no encoded commas), I think the two bugs are unrelated.

Comment 3

[Mike Cowperthwaite]

Found a dupe.

*** This bug has been marked as a duplicate of 229399 ***