264957 - backspace during address autocomplete should unconditionally delete a typed character

Status: RESOLVED DUPLICATE of bug 239558

(MailNews Core :: Composition, defect)

Description

[Michael Thome]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914 Firefox/0.10.1

(opinion) The current behavior of the delete/backspace key during address
autocomplete is confusing/broken.  IMHO, delete should *always* delete a typed
character - it should never be interpreted as "undo a tentative completion." 
The current behavior is extremely annoying for imperfect touch typists - it is
impossible to correct immediately recognized typos without having to wait for
completion to do it's thing - sometimes a single delete is ok, other times two
is required.

Reproducible: Always
Steps to Reproduce:
1. start composing a message
2. in an address entry box, rapidly type "xy<bs>"
3. in another address entry box, slowly type "xy<bs>"



Actual Results:  
Depending on how fast you type, the first will be end up as "x" and the second
as "xy"

Expected Results:  
Both methods should result in "x" - the same keystrokes should result in the
same output - BS/Del should not be modal in this way.

Marking this as normal priority because if not caught, it can result in
misdirected mail.

Comment 1

[Mike Cowperthwaite]

(In reply to comment #0)
> IMHO, delete should *always* delete a typed
> character - it should never be interpreted as "undo a tentative completion."

Then how should "undo a tentative completion" be handled?  Relying on the <del> 
key instead?  Or maybe disallow removing the tentative completion entirely, 
since that's the string that *will* be used if you delete it and then <tab> off 
the field.

But I do think the expected behavior from backspace at the end of the string is 
reasonable, particularly if it's followed by an update of the tentative 
completion.


> Marking this as normal priority because if not caught, it can result in
> misdirected mail.

The only reason this is true is because tabbing off of the address without the 
proper character deleted restores that same tentative completion string, which 
could be an actual valid address from the AB, or could just be completed with 
the domain name if nothing matches.  Of course, the same is true if <del> is 
used to remove the tentative completion.

However, I'm finding it hard to come up with a case where this is actually a 
problem, except where you're actually relying on autocompletion to behave 
according to memory of previous behavior.

For instance, suppose I have two entries in my book:
  Steve B <[e-mail]>
  Stephanie Q <[e-mail]>

I intend to send mail to Steve, but accidentally type   step   (which completes 
to "stephanie...") -- maybe because I'm about to write *about* Steph.

Realizing my error before I've even seen the autocompletion, I type <bs> to 
eradicate the 'p' but instead eradicate the autocomplete string 
-- relying on, perhaps, previous knowledge that "ste" defaults to "steve..." on 
the completion.  Then I tab off, the string re-completes to "stephanie..." and 
suddenly she finds out what I really think of her.  :)

So, yeah, there's a potential problem here, but it seems to be one that not only 
requires typing without looking, but also on expectations of the autocompletion 
behavior which might not be justifiable.  (For instance, a change in the address 
book entry of one them might change the order in which the two names are 
presented in the list.)

But there's *always* a potential problem if you don't look at the address fields 
before sending the message off.  This really is a minor bug.

Updating severy, platform and product/component.

Comment 2

[Mike Cowperthwaite]

Florian, please use "WorksForMe" rather than "Fixed" unless you can point to a 
specific patch that solved the problem.

Comment 3

[Mike Cowperthwaite]

Sorry, hit the wrong bug there.

Comment 4

[Michael Thome]

Hmmm - I still don't understand what function is served by using BS to ever
clear a tentative completion (which is what prevents BS from keeping consistent
semantics).  As far as I can tell, clearing the completion makes zero impact on
what'll actually happen, it merely makes the putative completion invisible until
you do something else.

Comment 5

[Michael Thome]

Addendum to example.  given the exmple from comment #1:
  Steve B <[e-mail]>
  Stephanie Q <[e-mail]>

What really gets me annoyed is that if you type stev<BS>p you will either have
the desired address ready to enter, or you will need *four* more keystrokes to
fix the miscue: <BS><BS><BS>p (you were probably left with
"stevp[@default.tld]", first BS leaves you with "stevp", second "stev", third
"ste", then "p" adds "step[hanie Q...]")

Comment 6

[Mike Cowperthwaite]

(In reply to comment #4)
> Hmmm - I still don't understand what function is served by using BS to ever
> clear a tentative completion

In an edit field, <bs> deletes a selection, just as <del> does; that's just 
normal behavior which happens to have an additional ramification for this 
particular field.

Comment 7

[Mike Cowperthwaite]

Found a dupe under TB, which refers back MailNews bug 135019.

*** This bug has been marked as a duplicate of 239558 ***