182321 - 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.

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect)

Description

[Michael kmd]

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 <[e-mail]>  to  <[e-mail] (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: <[e-mail]>
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
[e-mail]



Expected Results:  
send the mail to the correct person, with a correct emailaddress in the 'To:' of
the headers.

Comment 1

[[e-mail] (gone - use [e-mail] instead)]

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 <[e-mail]>

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: <[e-mail]>
Date: Wed, 27 Nov 2002 16:46:57 -0800
From: Stephen Donner <[e-mail]>
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 ;-)

Comment 2

[Jean-Francois Ducarroz]

This is very bad! Looking at it right now...

Comment 3

[Jean-Francois Ducarroz]

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.

Comment 4

[Jean-Francois Ducarroz]

Attachment: 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.

Comment 5

[Joe Hewitt (gone)]

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.

Comment 6

[Jean-Francois Ducarroz]

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 7

[Joe Hewitt (gone)]

Comment on attachment 108073 [details] [diff] [review]
Proposed fix, v1

sr=me

Comment 8

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

Comment on attachment 108073 [details] [diff] [review]
Proposed fix, v1

r=sspitzer

Comment 9

[Jean-Francois Ducarroz]

Fix checked in the trunk

Comment 10

[esther]

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.

Comment 11

[esther]

verified 

Comment 12

[Michael kmd]

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 '[e-mail]'
to '[e-mail]' (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: <[e-mail]>
Date: Sun, 20 Apr 2003 03:42:56 +0200
From: KmD <[e-mail]>
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