2937 - Mail- Reply To Sender with Kanji characters included in From: line give incorrect To: addresses

Status: VERIFIED FIXED

(MailNews Core :: Internationalization, defect, P2)

Description

[stephenb]

(This bug imported from BugSplat, Netscape's internal bugsystem.  It
was known there as bug #83613
http://scopus.netscape.com/bugsplat/show_bug.cgi?id=83613
Imported into Bugzilla on 02/04/99 18:26)

When someone includes a string of ISO-2022-JP (Kanji) characters in their From:
line in an email note, replying to that email, either through a right-click
option or clicking on the Reply-to icon, gives invalid To: addresses in the
composer window.

Details:
The From: line in the example reads
From: Yoichi (Yoshi) Hariguchi ($BGE8}M[0l(B) <[e-mail]>
(the "($BGE8}M[0l(B)" is Yoichi's GECOS MIME encoded Japanese characters).

When reply-to is selected, the the composer window in this case gives you a 3
'To:' address lines filled out, the three are To:Yoichi, To:Yoshi and
To:Hariguchi.  The actual email address ([e-mail]) never appears.

Note:  Yoichi's email client is NOT Communicator, it is "X-Mailer: Mew version
1.02 on Emacs 19.28.2, Mule 2.2"

I have two or three messages from Yoichi sitting in my mailbox if an example is
needed for someone to see, please email or call me if you would like to see this
problem.

Comment 1

[jfriend]

Mass change TFV to 4.5 from 5.0.

Comment 2

[chuang]

please reassign to the localization team

Comment 3

[chris hofmann]

assigned to msanz

Comment 4

[msanz]

Teruko, can you regress this bug?

Comment 5

[lchiang]

msanz and leger - where do localization bugs go to in bugzilla?

Comment 6

[leger]

msanz, you need to write a bug to have terry add you a International product in
Bugzilla with a description of what that means for him to link to.  Plus, here's
an opportunity to get components for International!  Would like to suggest that
all bugs needing to be moved to Bugzilla be set to international component or
assigned to msanz so she can grab them after component gets set up.

Comment 7

[lchiang]

qa contact set to momoi, default QA contact.

Comment 8

[Teruko Kobayashi]

I reassign this to Frank.

Comment 9

[Frank Tang]

My goodness, this is a bug for the OLD Gromit code base which does not make
sense here in the new world. We probably need to add a field in the "Resolve
bug", which called "DEAD CODE- DON'T NEED TO FIX"  :) I think we should close
it since we have NO messanger yet. Maybe we should mark it - REMIND ????

Comment 10

[leger]

Taking myself off this cc list.

Comment 11

[Katsuhiko Momoi]

One of the things we should do is to close these old code-based
bugs, but at the same time, we should keep a brief summary of
unresolved problems on a separate document so that when our new
mail component is ready, we can check these items off as
working. A list like that will give us a good indication of
how we are in the new code base.

I'm for closing it but with an entry in a new reminder list.
Next week, I'll go through the bugs for which I'm a QA contact
and clean them up. Until then, please leave them open.

Comment 12

[Frank Tang]

Naoki, please take a look at this.

Comment 13

[nhottanscp]

This is likely to be fixed by the new UI. Need verification when UI is
available.

Comment 14

[Frank Tang]

Japanese send mail is OUT for M3. mark target to M4

Comment 15

[nhottanscp]

Reply is not in for M4. Address book mile stone plan is not available.
Setting to M7.

Comment 16

[nhottanscp]

Widgets need to switch to Ender before we can verify this 4.5 bug with 5.0.
Setting to M8 for now.

Comment 17

[nhottanscp]

Adding dependency to 6262.

Comment 18

[bobj]

Bug #6262 has been moved to M9, so moving this one too...

Comment 19

[nhottanscp]

Move to M10, gfx has not landed so far.

Comment 20

[nhottanscp]

Attachment: zip file which contains a test message

Comment 21

[nhottanscp]

Using today's pull (8/19), I saw this is working when gfx wiget on (used
attached test case).
user_pref("nglayout.compatibility.mode", 1);
user_pref("nglayout.widget.mode", 2);
Marking as FIXED, verification should be possible when #6262 is resolved.

Comment 22

[Katsuhiko Momoi]

** Checked with 9/16/99 Win32 M11 build **

Yes. This is now working. The original sender name which has
a structure like:

Roman_name (JPN_LN JPN_FN) <[e-mail]>

does get correctly quoted into the "To: " field in Japanese
without destroying the original structure.

I'm going to mark this verified/fixed but there is one problem.
We don't convert JPN name into iso-2022-jp or B64-encode it
as we send it out. So then, we get an unreadable name in the "To: "
field in the Message view window. (This field does not show in
the thread pane.)
This will be filed as another bug.