470656 - Autocomplete reinstates undesired to-recipient contacts, e.g. after cursor left or DEL (can't delete suggested email address)

Status: RESOLVED DUPLICATE of bug 533109

(Thunderbird :: Message Compose Window, defect)

Description

[Thomas D. (:thomas8)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081219 Shredder/3.0b2pre

During mail composition, when typing new email address that trigger autocomplete match, TB reinstates undesired autocomplete contacts that have been explicitly dismissed by the user instead of accepting new user input.
a) Cursor left(!) in what you just typed (e.g. to fix a typo) will overwrite your input with matching autocomplete.
b) Dismissing the highlighted suggestion by deleting it (blue background with >> autocomplete suggestion) is simply ignored as soon as you move on with ENTER, TAB, etc. Again, your deliberate input is not respected (though perhaps not yet a valid email address).

This bug is similar to Bug 457820 -  Shredder reinstates deleted recipients
(cf. my duplicate Bug 460598 -  first autocomplete contact cannot be deleted from to-Recipient field when composing mail)

This bug is related to Bug 464914 -  AltGr (or Ctrl+Alt) triggers email selection from the suggestion list
(cf. my duplicate  Bug 470610 -  contacts autocomplete during mail composition wrongly overwrites user input when @ is pressed)

Reproducible: Always

Steps to Reproduce:
1. start typing email address, like service... --> Autocomplete correctly suggests:
service >> Customer Service <customers(at)service.info.com>
2. a) use cursor left to fix typo (you wanted to type server-admin@...)
b) alternatively, use DEL or Backspace to delete/dismiss highlighted suggestion, press ENTER (TAB, Cursor, you name it) to leave your input "as-is" (though perhaps incomplete)

Actual Results:  
a) in the cursor-left scenario, TB simply overwrites my input with the current matching autocomplete
b) in the dismissed-suggestion scenaria, TB overwrites my input on cursor right or leaving the field even though there is no text except my (incomplete) address input in the recipient field

Expected Results:  
a) cursor-left should not change my input
b) confirming any given string in the recipient field should not change that string (just as TB accepts incomplete addresses when they do not match with autocomplete). What you see is what you get - I just deleted the highlighted suggestion from the input field, so I don't want it. The suggestion is no longer visible in the input field - so why does it return when I press enter?

ad a) I can accept that Cursor *RIGHT* selects the suggestion, but Cursor *LEFT* definitely shouldn't. The effect is even worse when user deliberately deletes highlighted suggestion before cursoring to the right of his input - this really should NOT bring back the just-dismissed suggestion.

b) is less disturbing, but it violates wysiwyg anyway. In rare cases, it might prevent the user from entering a new address:
existing contact (autocomplete suggestion): customers(at)service.info.com
new contact (typed in by user): customers(at)service.info
Result: User cannot enter new contact, as it will always be overwritten by autocomplete.

A possible SOLUTION would be to use same approach as Firefox awesome bar (as has been suggested in similar bugs): autocomplete just shows the list for the user to choose from (by using cursor down), without interfering with the actual typing in any way. It's one tiny, but completely transparent extra key to get there (Cursor down, ENTER instead of just ENTER, and only if the match was right), but you'd be getting rid of all sorts of annoying effects of the present implementation.

Comment 1

[Pavel Kotrc]

Confirming on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090226 Shredder/3.0b3pre.

It seems like "scenario a)" (hitting left arrow) is a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=202333.

Comment 2

[Wayne Mery (:wsmwk)]

Gary, dupe forward to Bug 486501?  --  edit an address after autocomplete and autocomplete reselects the first choice

Comment 3

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to comment #2)
> Gary, dupe forward to Bug 486501?  --  edit an address after autocomplete and
> autocomplete reselects the first choice

I'm not sure myself -- this bug doesn't seem a 1-for-1 duplicate.

cc Bryan on how the autocomplete should work as presented to the user.

Comment 4

[Lenny]

(In reply to comment #3)
> (In reply to comment #2)
> > Gary, dupe forward to Bug 486501?  --  edit an address after autocomplete and
> > autocomplete reselects the first choice
> 
> I'm not sure myself -- this bug doesn't seem a 1-for-1 duplicate.
> 
> cc Bryan on how the autocomplete should work as presented to the user.

I am running the nightly, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5pre) Gecko/20091015 Shredder/3.0pre, and here is what I am seeing.

if you begin to enter an address, as long as it matches the text displays black, but when it becomes a new address it shows as red. If you tab from the To: field when the text is red, it is saved as is/wysiwyg. If you merely backspace, leaving the text as black/still matching - then it will autocomplete when you tab off the To: field.
The issue being, email requires a valid address to send. How can a partial of a valid address still be valid? The suggestion being you fat fingered the keyboard, backed up to fix your entry - in my experience if you key in enough chars to create a new address, then the text shows as red and it will be used. If it does not come out to be new/unique - then autocomplete fills it in. In the case of Johns VS Johnson - sending to [e-mail] rather than [e-mail] - if jjohnson is entered first, then if you don't complete and address to jjohn - without @place.com - it can't be delivered.
The issue being, the autocomplete is doing what it should, but it is not what the user intended. As long as the partial address entered matches for autocomplete, autocomplete will do it's job. I think it is up to the user to know when the address is the same or different - they are the one hitting the send button. Len

Comment 5

[James Sleeman]

This issue remains in 3.0.4 and besides being a clear issue regards doing what the user tells you to do, it is a real problem...

  Email address 1: [e-mail]
  Email address 2: [e-mail]

Address 2 not in book.  Address 1 is.  

Start tying in address 2, address 1 auto completes.

Apart from manually adding the address to your address book (I don't want to, nor should I have to do that), there is seems no defined way to coerce thunderbird to send an email to [e-mail] because when I hit delete the autocompleted ".au" thunderbird re-completes it as soon as I defocus the field.

The workaround is to ad a space after the .com, but this is entirely unintuitive.

When I delete something, I want it to stay deleted.

Comment 6

[James Sleeman]

bug 533109 is a dup of this