152690 - Non-ascii chars are displaying as QP in the display name after Send later in the CA

Status: VERIFIED FIXED

(MailNews Core :: Internationalization, defect)

Description

[marina]

*** observed with 2002-06-18-1.0.0 build ***
Steps to reproduce:
- compose a mail with non-ascii sender name;
- go to File|Send later;
- go to folder Unsent messages: at this point the name of the recipient is saved
correctly;\
- now sent the unsent message, look into the Collected Addresses, the Display
name is showing up in QP encoding, screen shot to follow

Comment 1

[marina]

Attachment: here is a screen shot to illustrate the problem

Comment 2

[marina]

changing qa contact, nominating

Comment 3

[nhottanscp]

Is this same problem as bug 152471?

Comment 4

[marina]

i didn't see that problem on Linux for Display name with non-ascii cards, unless
it is for Mailing list and that one was reported as bug# 74466. Jeesun do you
see the problem with non-ascii chars in CA right after Send or Send later? Thanks.

Comment 5

[nhottanscp]

I can reproduce this.

The addressbook code expects MIME decoded Unicode string. 
nsMsgSendLater::CompleteMailFileSend has to decode the headers when creating
nsMsgCompFields.
 

Comment 6

[nhottanscp]

Attachment: MIME decode headers when creating nsMsgCompFields for sendlater

Comment 7

[nhottanscp]

I think this is important for POP users.

Comment 8

[Jeesun Cho]

Marina, I see the same problem on linux. But it seems to happen only after send
later, not send.

Comment 9

[Jean-Francois Ducarroz]

Comment on attachment 88226 [details] [diff] [review]
MIME decode headers when creating nsMsgCompFields for sendlater

R=ducarroz

Comment 10

[David :Bienvenu]

Comment on attachment 88226 [details] [diff] [review]
MIME decode headers when creating nsMsgCompFields for sendlater

I much prefer checking decodedString.Length() > 0 rather than relying on the
implicit cast to char * of nsXPIDLCString returning null (instead of say, "")to
check for empty string, but sr=bienvenu anyway.

Comment 11

[Frank Tang]

The chances of putting non ASCII name into the email address is in the following
condiction:
1. user type non-ascii name in address field and LDAP find the email address
2. user reply mail and the to: or cc: field contains non ASCII name in email
address. 
3. user really type the non-ASCII name into the address field by themself.

The case to hit case 3 is rare. But the case of hitting 1 seems normal for
enterprise customer and very common for case 2. 

The chances to use Send Later is common for POP3 users, less common for IMAP4
users. 

What we need to know is what will happen if we try twice in a fresh new profile
of the following condictions:
1. if the first time we do send later , and the 2nd time we do send (now) with
the same email address. What will happen? Will there be two entries in the
address book or one? which one? if there are two entries and we send the 3rd
time, what will show up in my mail composition address field, the corrupt one by
the first time or the correct one by the 2nd time?
1. if the first time we do send (now), and the 2nd time we do send later with
the same email address. What will happen? Will there be two entries in the
address book or one? which one? if there are two entries and we send the 3rd
time, what will show up in my mail composition address field, the corrupt one by
the second time or the correct one by the 1st time?

Comment 12

[marina]

Frank, in the comment#11 you asked:
>1. if the first time we do send later , and the 2nd time we do send (now) with
>the same email address. What will happen? Will there be two entries in the
>address book or one? which one? if there are two entries and we send the 3rd
>time, what will show up in my mail composition address field, the corrupt one by
>the first time or the correct one by the 2nd time?
Here are the answers:
- Send later, send now = is collected in the CA incorrectly (in QP encoding);
- third send (Send now)= at this point the autocompletion in the composition
window shows you 2 options of autocompletion (the correct one from PAB and the
incorrect one from CA);
- chose the correct one and send now;
- opening the CA you'll see that the incorrectly collected one is replaced by
the correct one, so there is only one entry after the third send.

Comment 13

[marina]

i just want to mention that even though the third send seems to solve the
display problem in the CA, the users do not intuitively know that they have to
send for the third time and this will occur not only when you want to use Send
later feature but when you have to use Send later feature when coming back from
working offline , ldap replication etc.

Comment 14

[marina]

second scenario:
- Send now: the right display name is collected in the CA;
- Send later, Send now: the right address in the CA is replaced by the wrong one;
- Third send now: in the composition window the autocomplete gives you two
options- a correct one from the Address Book (PAB) and the incorrect one from
the CA;
- chose the correct one from the PAB, send now, the right address will get
collected (if for some reason you'll decide to chose from the autocompletion
list a wrong one (QP) and send with this address then the wrong one (QP) gets
collected into CA)

Comment 15

[nhottanscp]

Attachment: Changed to check if the string is empty.

Comment 16

[David :Bienvenu]

Comment on attachment 88377 [details] [diff] [review]
Changed to check if the string is empty.

even better, thanks, sr=bienvenu

Comment 17

[nhottanscp]

Comment on attachment 88377 [details] [diff] [review]
Changed to check if the string is empty.

move 'r'

Comment 18

[nhottanscp]

checked in to the trunk

Comment 19

[marina]

verified on the trunk (2002-06-20-11-1.0.0 build), the addresses after Send
later, Send now are collected correctly into the CA.

Comment 20

[marina]

in my comments #19 i meant 2002-06-20-11 trunk build, not the branch build

Comment 21

[marina]

when/if it's checked into the branch will  verify it there.

Comment 22

[Frank Tang]

It is hard to decide this is nsbeta+ or nsbeta-. It generate garbage into the
addressbook but won't damage data which send out. however, it might increase our
future work to fix the problem that garbage data inside the addressbook. So I
still ask adt to approve it. 
adt: please take it if you think flooding the address book with garbage data as
a form of "data lost" (or you should say, the user will be lost in the data)

Comment 23

[scottputterman]

adding adt1.0.1-.  Let's get this in the next release.