77972 - Non-ascii name is garbled in the Reply-to field on the Account Manager mail panel

Status: RESOLVED FIXED

(MailNews Core :: Internationalization, defect)

Description

[marina]

Stesp to repro:
- open Account Wizard, Edit|Account setting;
- enter a non-ascii name into the Replyt- field ( cyrillic name
<[e-mail]>
 - close Mail, reopen;
//note: the non-ascii name is garbled on the Reply-to field

Comment 1

[nhottanscp]

There is a regression bug 77967 today, is this also a regression?

Comment 2

[ji]

After I enter some Japanese characters on Reply-to Address field, save it and go 
back to the same screen again, the Ja chars are saved as ASCII characters. For 
example, hiragana a is save as ascii "B". It happens on 04/26 build too. 
It doesn't look like a regression. Is that we can only be allowed to enter ascii 
in Reply-to Address field?

Comment 3

[marina]

i don't think it is a regression. I remember that we could not enter
"nonasciiname<[e-mail]>" before.

Comment 4

[marina]

in 2001-04-18 build the non-ascii string entered in the Reply-to field on thhe
account wizard is not remembred after you close/reopen Mail, it is just lost. So
in a way it is not a regression but a progress :-)

Comment 5

[nhottanscp]

Reassign to putterman.

Comment 6

[scottputterman]

reassigning to racham.

Comment 7

[ji]

Same problem with BCC antoher address field on copy and folder settings window.

Comment 8

[racham]

ji, 

Is this confirmed with today's build. Lately, fix to the similar problem has
been checked in. It was fixed at prefs level and that should ideally take care
of these kind of problems too. Please let me know. thanks.

bhuvan

Comment 9

[marina]

can not reproduce in 2001-05-09 ; non-ascii chars are saved correctly

Comment 10

[ji]

Just checked Mac 2001-05-10-04 mtrunk build. It has no problem with Latin-1
accented characters, but Japanese characters are garbled. And this happens both
on Reply-to and BCC to other address field. I'll check win32 and linux build
when testable builds are available.

Comment 11

[marina]

with Win 2001-05-09-04 build JA chars can not be saved correctly in any field

Comment 12

[marina]

this problem still exists in mozilla builds , charset that is non-latin1 can not
be correctly saved on the Account manager. For .ex would i use a cyrillic name
for the Reply-to field on english system it would be saved incorrectly. If the
user doesn't know that because the name displays correctly while being typed he
would not understand why he sees garbage in the composition window on the
Reply-to field (and CC and Bcc). This type of mail would not be sent in current
builds because the recipient is not recognized a valid.This is a serious
problem, and needs to be fixed. Nominating 

Comment 13

[marina]

Attachment: here is a screen shot to illustrate the account display problem (cyrillic charset is used)

Comment 14

[marina]

Attachment: here is an error you'll get in case you will send the mail with the incorrect display of the recipient name

Comment 15

[racham]

The Reply-to field is on AccountManager's main panel. Changing the summary to
reflect the same.

Comment 16

[Michael Buckland]

Discussed in Mail News bug meeting with Engineering, QA, Mktng and PjM. 
Decision was to plus this bug.

Comment 17

[scottputterman]

I'm going to minus this because if the user just types their email address in
then it will work, ie <[e-mail]>

Scott

Comment 18

[nhottanscp]

nominate for nsbeta1

Comment 19

[marina]

 The account wizard has three fields: "Account name" (this one accepts non-ascii
names), "Email address" ( this one is explicitly saying that only emails are
expected to be entered ) but in the third field we say :"Reply-to Address" and
the user could try to enter the pretty name here like "[e-mail]". This
field doesn't accept pretty names , the non-ascii string enter here will be
saved as gibberish. So we have a choice to either change the code (in many
places) to be able to save the string in unicode (probably too late for this
release) or maybe change the wording for Reply-to address to make it clear that
ONLY email address (no pretty name) is going to be collected. Jennifer, what's
your take on this? Cc'ing Jennifer and Scott.  

Comment 20

[jglick]

>or maybe change the wording for Reply-to address to make it clear that
>ONLY email address (no pretty name) is going to be collected.

"Reply-to Email Address:" (sorta long) or "Reply-to Email:" (not sure about 
this one)?

Comment 21

[robinf]

I prefer "Reply-to Email Address:" if space allows. This is a more descriptive
label than "Reply-to Email:" . Including the phrase "Email Address" is the
clearest way to describe what we're asking for.

Comment 22

[marina]

The "Reply-to Email Address" sounds good to me... one question though: do we
want to permanently exclude the use of pretty name for the Reply? The "From"
field is made of a combination of two strings: "Your name" and " Email address".
The fact that "Your name" field accepts non-ascii chars allows us to enter a
Name in japanese, chinese etc... The Reply then will only include the email
address though the user could have a different Display name associated with a
reply address... I am thinking how consistent is this design..?

Comment 23

[jglick]

OK, i think i understand better now. "PrettyName <[e-mail]>" works with 
ascii chars but "PrettyName" gets messed up when using non-ascii characters. I 
would think the best solution would be to allow non-ascii characters for 
PrettyName.

Comment 24

[Simon Montagu :smontagu]

Greg, another bug for your consideration.

Comment 25

[Samir Gehani]

Mail triage team: nsbeta1-

Comment 26

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

mass re-assign.

Comment 27

[Mike Cowperthwaite]

Comment on attachment 72816 [details]
here is an error you'll get in case you will send the mail with the incorrect display of the recipient name

This attachment is not useful because the error message being shown is about
the lack of a To: address in the email; it's unrelated to the Reply-To problem.

It is true that Unicode characters (beyond 0xFF) 
are stored oddly, as shown in attachment 72814 [details].  In Mozilla 1.8a6, an illegal
Reply-To header is simply left off the new message; but in TB 1.0, such a
header is truncated at the first illegal character -- see bug 208577.

Comment 28

[Gonzalo HIGUERA DÍAZ]

(In reply to comment #27)
> In Mozilla 1.8a6, an illegal
> Reply-To header is simply left off the new message; but in TB 1.0, such a
> header is truncated at the first illegal character -- see bug 208577.

Being a little pedantic and pointing to comment #23 and the cone I made in bug 208577 (number 6), I would like to stress that this is not limited to illegal characters (such as those in the email address) but also to any non-ASCII character (such as those one might use when preceding the address with a PrettyName).

Comment 30

[Makoto Kato [:m_kato]]

Attachment: fix

Comment 31

[Makoto Kato [:m_kato]]

no easy way to write unit test because this is attribute.

Comment 33

[David :Bienvenu]

Comment on attachment 571270 [details] [diff] [review]
fix

thx for the patch

Comment 34

[Makoto Kato [:m_kato]]

http://hg.mozilla.org/comm-central/rev/8bba60eda697