632127 - Recipient autocomplete angle brackets characters (doe >> John Doe <[e-mail]>) remain in recipient field and get sent with message header (when clicking send without manually confirming autocomplete)

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[WBT]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7

When typing in an address, the autocomplete mechanism adds a string of the form " >> Contact name <[e-mail]>" in the "To" (CC, etc.) field.  This string remains there when the message is sent, if there are no other user events that switch the focus away and cause the extra string to be removed. 

Reproducible: Always

Steps to Reproduce:
1. Open a new e-mail message in the Compose window.
2. Add in a subject and body;  the "blank subject" dummy-check would be enough to cause non-observation of this bug.
3. Just before you're ready to send the message, add a recipient.  It doesn't matter if this is the first or a later recipient, only that they're already in your address book/list of e-mail addresses. 
4. For example, we'll add "Example Recipient <[e-mail]>."  Do this by typing in "first".
5. Mozilla will change the string to read "first >> Example Recipient <[e-mail]>"
6. Click Send, or use the keyboard shortcut to send. 
Actual Results:  
The message is actually sent, to "first >> Example Recipient <[e-mail]>".
While this particular example would still result in mail delivery, that's less clear if I had continued typing and the mail was sent to "[e-mail] >> Example Recipient <[e-mail]>" as happened with a recent e-mail that I sent.  

Expected Results:  
The text should disappear, the same behavior as if I'd clicked away (e. g. in the Compose Body field) instead of clicked Send.  If I had typed in a full e-mail address that should be fine and it should be sent to just "[e-mail]" instead of the full string.  If I had not entered in a full e-mail address (e. g. "firstfew") it should report an Invalid Recipient Address.  Automatically choosing the first result (as done when a user clicks away to edit the message body) may not be a good idea because the sender has no chance to review this decision and see if that's actually who they intend to send the message to.

Comment 1

[Wayne Mery (:wsmwk)]

this happens. nothing bad happens right? unsure if it's a duplicate.

WBT, shorter STR descriptions would be helpful - you put up a lot of words to read.  TIA

Comment 2

[Thomas D. (:thomas8)]

Still happens as described for TB17 on WinXP, this should be linked up to depend that other bug that we are too agressive in autocompleting the first match without user action.

Comment 3

[Daniel Holbert [:dholbert]]

This happens now even when you're starting to compose a new email -- e.g. type a query into the "To" box, watch Autocomplete complete it, and then hit "tab" a few times to switch to the Subject field. Your "To" field will be left in a busted-looking state, with the search query and the ">>" before the contact.

I'm pretty sure this didn't used to happen with those STR. (At least, these STR are my muscle memory for how to compose an email, and I don't recall it being broken until relatively recently.)

Comment 4

[Wayne Mery (:wsmwk)]

I am also seeing this behavior when using nightly. And I agree with Daniel it did not happen prior to the change to the "new" autocomplete, so I'm not sure this bug report is the proper venue for the "new" problem - it's not described in a "new", currently open bug report - https://bugzilla.mozilla.org/buglist.cgi?f1=short_desc&list_id=10176662&short_desc=auto%20complete&o1=nowordssubstr&classification=Client%20Software&classification=Components&chfieldto=Now&query_format=advanced&chfieldfrom=2014-04-28&f2=OP&short_desc_type=allwordssubstr&component=Address%20Book&component=Autocomplete&component=Composition&component=Message%20Compose%20Window&product=MailNews%20Core&product=Thunderbird&product=Toolkit

Comment 5

[Thomas D. (:thomas8)]

The new bug is bug 1003856, which should be already fixed, last result on Wayne's search. Magnus clipped the summary to not contain >>.

Comment 6

[Thomas D. (:thomas8)]

(In reply to Wayne Mery (:wsmwk) from comment #4)
> I am also seeing this behavior when using nightly. 

Wayne's comment made me test this some more, and indeed, it still fails for important scenarios e.g. when you tab out of recipient field to accept the suggestion, or when TB composition loses focus while the suggestion is active (bug 1009469). Thanks Wayne, helpful comment. :)

Please keep testing this and report anything odd...

Comment 7

[Magnus Melin [:mkmelin]]

This is still an issue after bug 1009469, though a bit of an edge case.

Comment 8

[Thomas D. (:thomas8)]

(In reply to Magnus Melin from comment #7)
> This is still an issue after bug 1009469, though a bit of an edge case.

Less of an edge case might be this variant:
[cursor right] to select first result [searchwords >> matchingContact <email>], then clicking into next recipient input box will also leave the "searchwords >>" part sticking around instead of normalizing the result by removing the searchword and >>, as we correctly do on subsequent results when selected with cursor right.

Comment 9

[Thomas D. (:thomas8)]

Still seen on TB 31.5.0

Edge case or not, this violates user's privacy because the message actually gets sent out, but potentially to a different, valid email address, e.g.:

"doe >> john.doe"@asdf.com

User will also wrongly believe the msg has been sent successfully, until the error mail from the smpt server arrives.

Comment 10

[Thomas D. (:thomas8)]

To mark the 10th anniversary of this bug, I have explicitly fixed this privacy fallacy in bug 1701313!

(In reply to Thomas D. (:thomas8) from comment #8)

Less of an edge case might be this variant:
[cursor right] to select first result [searchwords >> matchingContact
<email>], then clicking into next recipient input box will also leave the
"searchwords >>" part sticking around instead of normalizing the result by
removing the searchword and >>, as we correctly do on subsequent results
when selected with cursor right.

This variant is longer happening in TB 78.

Comment 12

[Thomas D. (:thomas8)]

(In reply to Thomas D. (:thomas8) from comment #10)

To mark the 10th anniversary of this bug, I have explicitly fixed this privacy fallacy in bug 1701313!

In view of elder duplicate bug 348844, it's the 15th anniversary in fact.