User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2) Gecko/20021126 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2) Gecko/20021126 I found out this problem when sending an important email to a friend whose email address changed recently. the mail never arrived at the correct address due a wrong 'To:' in the headers. what happened: I typed his name, and autocomplete mentioned his old emailaddress, so I corrected this (without using mouse) to his new one. I pressed 'send', the email was sent, but never arrived at the correct address. a phonecall made me suspicious, i was sure i sent it correctly, so i checked the sent folder. i checked the source of the sent email and instead of his emailaddress, his name and other characters were written in the 'To:' . so i started testing a bit and it appears that when correcting the suggested emailaddress UNTIL the '@' from right to left,when ONLY using the keyboard, mozilla messes up the correct strings out of the addressbookdatabase ex. correcting <firstname.lastname@example.org> to <email@example.com (don't touch the @ or other characters) and leave the < open) results in a 'To: c-h, ">>", Gerry' in the headers of the sent mail (when gerry exists as a contactname in de db), instead there should be mentioned his complete emailaddress! From - Wed Nov 27 22:49:41 2002 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00800000 Message-ID: <3DE53DF5.firstname.lastname@example.org> Date: Wed, 27 Nov 2002 22:49:41 +0100 From: Chaim <XXXXXXXXXXX> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2) Gecko/20021126 X-Accept-Language: en-us, en MIME-Version: 1.0 To: c-h, ">>", Gerry Subject: (no subject) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have 2 mozilla clients running and both can reproduce this error, also with other contacts out of my addressdatabase (just change the domainname.com and send) both are the final 1.2 distribution i installed yesterday. I would like to see anybody to verify this. especially on Windows platform. possible problems could be caused during upgrade from 1.2b-2810 and 1.0.1 on the other client to 1.2 final. but i'm nearly sure i didn't have this problem before. Reproducible: Always Steps to Reproduce: try not to use the mouse, only the keyboard when correcting 1. launch mail composer and type the beginning of the name of a contact in the addressbook you have. let autocomplete complete the address. 2. change the emailaddress domainname untill the '@' (not more), use only the keyboard, make sure the address isn't selected anymore (not grey) 3. press send 4. go to sent mail folder 5. type ctrl-U to view the source 6. verify the To: it should mention an emailaddress, not a nickname or other characters. Actual Results: the To: has the wrong string. there should be an emailaddress, not the name or other characters mentioned. probably the mail I sent was delivered to the person with an email like Gerry@MYINTERNETPROVIDER.be Expected Results: send the mail to the correct person, with a correct emailaddress in the 'To:' of the headers.
Confirming this bug with trunk build 2002-11-27-08, Windows 2000. Using autocomplete to match my string 'stephen', it completed to: stephend >> Stephen Donner <email@example.com> Upon using the backspace and hitting up until the @ (but _not_ at the @), I typed in 'fjlkdsjflsdjfldsjlf.com', knowing that it would be non-existent domain. I then pressed send. Here are the results: Mail returned from our SMTP server: This Message was undeliverable due to the following reason: The following destination addresses were unknown (please check the addresses and re-mail the message): SMTP <Stephen> Here's the actual message that went out: Message-ID: <3DE56781.firstname.lastname@example.org> Date: Wed, 27 Nov 2002 16:46:57 -0800 From: Stephen Donner <email@example.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021127 Netscape/7.0+ X-Accept-Language: en-us, en MIME-Version: 1.0 To: stephend, ">>", Stephen, Donner Subject: test Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Basically, I just restated what Michael already knew, but I have to do that sometimes to understand things ;-)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: correcting a suggested emailaddress from the addressbook results in an incorrect 'To:', the (nick)name (and other characters) are taken instead of the correct emailaddress in the headers. → correcting a suggested emailaddress from the addressbook results in an incorrect 'To:', the (nick)name (and other characters) are taken instead of the correct emailaddress in the headers.
This is very bad! Looking at it right now...
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.3alpha
If you remove the '>' at the end of the address, it's normal it become an invalid one. However, we should correctly remove the [nickname] >> part of the autocompletion when the user correct the adress.
Created attachment 108073 [details] [diff] [review] Proposed fix, v1 this patch force to finish the autocomplete (which will remove any extra "[nickname] >>") when the user either click in the input text or when the user navigate with the left or right arrow key.
Attachment #108073 - Flags: review?(hewitt)
Comment on attachment 108073 [details] [diff] [review] Proposed fix, v1 I dunno about this. What if you make a typo and use the left arrow key to go back and correct it? You'd probably find it irritating to have autocompletion occur at that moment.
Autocomplete append only if the input cursor is at the far right, that as alwways been like that. Therefore the case where the user move the cursor to the left will temporary disable autocompletion. The fact I call finishAutoComplete does not mean you wont be able to have autocompletion after that, it just means it will finish and clean up the current autocomplete for the previous key stoke. Once the user a character, autocompletion will start again (as long the cursor is at the far right). I have tested this patch with both email and url completion and I haven't found any problem with it!
Comment on attachment 108073 [details] [diff] [review] Proposed fix, v1 sr=me
Attachment #108073 - Flags: review?(hewitt) → review+
Comment on attachment 108073 [details] [diff] [review] Proposed fix, v1 r=sspitzer
Attachment #108073 - Flags: superreview+
Fix checked in the trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
I can't reproduce the originally stated problem with the build this was reported on. I could reproduce Stephen's scenario, and verify the >> is not listed in the recipients list with the 20030225 trunk build. Reporter can you try your scenario again and comment in this bug if it's fixed too. Thanks.
Status: RESOLVED → VERIFIED
a bit late, but it seems i missed the original email asking me to verify. so here it is. I did the same steps I described in comment #1 to produce the error. still, I think I have to make an important remark. when I correct an email (only with keyboard as described in the first comment AND not closing the string with '>') moz only puts the name of the recipient. not the correct email address (see source of email below). ex. like in comment #1 I tried to correct with the keyboard 'firstname.lastname@example.org' to 'email@example.com' (not touching the @ and leaving the '>' out) will show the following result: ========================================= From - Sun Apr 20 03:43:00 2003 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00800000 Message-ID: <3EA1FB20.7030508@Flashmail.com> Date: Sun, 20 Apr 2003 03:42:56 +0200 From: KmD <F-----------@-------.com> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gerry Subject: test ignore Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit ========================================= notice only a name is mentioned, not a correct email address! still, when people correct the email address of the recipient. most will forget to close the address with a '>' , resulting in an incorrect or incomplete recipient address. (maybe this is allready mentioned in an other bug report?) thank you. kmd
You need to log in before you can comment on or make changes to this bug.