*** 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
changing qa contact, nominating
Keywords: intl, nsbeta1
QA Contact: ji → marina
Is this same problem as bug 152471?
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.
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
I think this is important for POP users.
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+
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.
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?
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.
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.
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 on attachment 88377 [details] [diff] [review] Changed to check if the string is empty. even better, thanks, sr=bienvenu
Comment on attachment 88377 [details] [diff] [review] Changed to check if the string is empty. move 'r'
Attachment #88377 - Flags: review+
checked in to the trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.1beta
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.
in my comments #19 i meant 2002-06-20-11 trunk build, not the branch build
when/if it's checked into the branch will verify it there.
Status: RESOLVED → VERIFIED
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+
adding adt1.0.1-. Let's get this in the next release.
Keywords: adt1.0.1 → adt1.0.1-
You need to log in before you can comment on or make changes to this bug.