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

VERIFIED FIXED in mozilla1.1beta

Status

VERIFIED FIXED
17 years ago
10 years ago

People

(Reporter: marina, Assigned: nhottanscp)

Tracking

({intl})

Trunk
mozilla1.1beta
x86
All
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt3][ish1+])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

17 years ago
*** 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
(Reporter)

Comment 1

17 years ago
Created attachment 88205 [details]
here is a screen shot to illustrate the problem
(Reporter)

Comment 2

17 years ago
changing qa contact, nominating
Keywords: intl, nsbeta1
QA Contact: ji → marina
(Assignee)

Comment 3

17 years ago
Is this same problem as bug 152471?
(Reporter)

Comment 4

17 years ago
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.
(Assignee)

Comment 5

17 years ago
I can reproduce this.

The addressbook code expects MIME decoded Unicode string. 
nsMsgSendLater::CompleteMailFileSend has to decode the headers when creating
nsMsgCompFields.
 
Status: NEW → ASSIGNED
(Assignee)

Comment 6

17 years ago
Created attachment 88226 [details] [diff] [review]
MIME decode headers when creating nsMsgCompFields for sendlater
(Assignee)

Comment 7

17 years ago
I think this is important for POP users.

Comment 8

17 years ago
Marina, I see the same problem on linux. But it seems to happen only after send
later, not send.
Comment on attachment 88226 [details] [diff] [review]
MIME decode headers when creating nsMsgCompFields for sendlater

R=ducarroz
Attachment #88226 - Flags: review+

Updated

17 years ago
Attachment #88226 - Flags: superreview+

Comment 10

17 years ago
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

17 years ago
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?




(Reporter)

Updated

17 years ago
OS: Windows XP → All
(Reporter)

Comment 12

17 years ago
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.
(Reporter)

Comment 13

17 years ago
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.
(Reporter)

Comment 14

17 years ago
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)
(Assignee)

Comment 15

17 years ago
Created attachment 88377 [details] [diff] [review]
Changed to check if the string is empty.
Attachment #88226 - Attachment is obsolete: true

Updated

17 years ago
Attachment #88377 - Flags: superreview+

Comment 16

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

even better, thanks, sr=bienvenu
(Assignee)

Comment 17

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

move 'r'
Attachment #88377 - Flags: review+
(Assignee)

Comment 18

17 years ago
checked in to the trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.1beta
(Reporter)

Comment 19

17 years ago
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.
Keywords: fixed1.0.0
(Reporter)

Comment 20

17 years ago
in my comments #19 i meant 2002-06-20-11 trunk build, not the branch build
Keywords: fixed1.0.0
(Reporter)

Comment 21

17 years ago
when/if it's checked into the branch will  verify it there.
Status: RESOLVED → VERIFIED

Comment 22

17 years ago
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)
Keywords: nsbeta1 → adt1.0.1, mozilla1.0.1, nsbeta1+
Whiteboard: [adt3]

Updated

17 years ago
Blocks: 141008

Comment 23

17 years ago
adding adt1.0.1-.  Let's get this in the next release.
Keywords: adt1.0.1 → adt1.0.1-

Updated

17 years ago
Blocks: 157673

Updated

16 years ago
Whiteboard: [adt3] → [adt3][ish1+]

Updated

16 years ago
Depends on: 180372

Updated

16 years ago
No longer blocks: 157673
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.