1367801 - address autocomplete prefers mismatch over exact-match

Status: RESOLVED DUPLICATE of bug 1138033

(Thunderbird :: Untriaged, defect)

Description

[Dan Pernokis]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170518000419

Steps to reproduce:

I have similar recipient addresses like "[e-mail]" and "[e-mail]", where "myname" alphabetically sorts first (on top) of the list.

I try to send to "[e-mail]" and type it in fully.


Actual results:

AutoComplete eventually shows both addresses as I type "name", with "myname" as the first/preferred choice because it is alphabetically first.  It continually shows both as I continue, even to completion ("[e-mail]"), with "myname" still as first option.

When I press enter, thinking (KNOWING) that I've correctly typed the address, I end up with "myname" instead of "name" because it is still the first-choice match.  Problem is I might not notice the substitution and end up sending to the wrong address!

Even if I press a trailing space to explicitly signal the obvious end, AutoComplete still completes with the incorrect ("myname") address.

I *MUST* select from the drop-down list to work around this problem, which would be tedious if I was looking for "a@..." in a very long list of partial matches!  (Short strings match a lot of addresses.)



Expected results:

I realize AutoComplete has to work with what it finds, in the order it finds it.  But...
An EXACT MATCH should take precedence over any partial match by displaying as first option, especially after I've typed the "@" symbol.  

Logic:  There will be no further changes coming to the left side of the entry (unless I backspace or re-click into it, so any partial matches should at least fall down the list (preferred option), or perhaps disappear altogether (clean but not so good).

In this example, I've typed "name@..." and thereby I'm telling AutoComplete I likely don't want "myname@..." to be used.  (But I might, so it would be good to keep it in the list, just not as first choice.)  But if I do type out a full address and a trailing space, that should clinch the deal that I'm done matching.

Running TB 51.1.1 (32), but this has been going on for awhile -- just didn't recognize what was happening. :)

Comment 1

[Jorg K (CEST = GMT+2)]

(In reply to Dan Pernokis from comment #0)
> Running TB 51.1.1 (32), but this has been going on for awhile -- just didn't
> recognize what was happening. :)
Yes, there are a few quirks in autocomplete, and they started much earlier than TB 52. Sadly, it's a difficult area, TB uses a lot of code from the underlying Mozilla platform, and we have very few resources.

There is a bug on file, bug 1138033, which has enraged users a lot, that is, you can't even type "[e-mail]" if "[e-mail]" is already in your address book. The workaround is to type a comma after the name. Can you please try that.

Comment 2

[Dan Pernokis]

At first I couldn't reproduce the problem, which is how this issue remains hidden -- try to repeat and it doesn't.  Turns out it was first time I sent to this particular address and it wasn't yet in the Collected Addresses address book, so AutoComplete worked a little differently, grabbing what was there instead of what I was typing.  I manually deleted the address from Collected, tried again, and got the problem to surface again.

I tried the trailing comma, and that works.  I think trailing space *should* do the same just for logic's sake.

As for [e-mail] (etc), the mismatch is the same, just done in the domain rather than the name.

And thanks, I looked at Bug 1138033 -- it's *EXACTLY* this issue, so I guess *this* bug is "yet another" dup, as some writers there would say. :)  I'll let you flag it where and as you think appropriate, or leave it as a poke to attract more interest.  But I do agree with elevating these bugs to critical if possible, given the ability to inadvertently mis-direct sensitive mail.  (Explains a serious issue here from a few years ago!)

Meanwhile, I will put forth my preference for operation as per my "expected results" above.  Whatever the user types should become the default (or first) choice once keying gets into the domain.  That is, "[e-mail]" will be distinct from "[e-mail]" and "[e-mail]", for example, with all displayed and "[e-mail]" as first default (unless user continues and types the "m", in which case "[e-mail]" drops out).  More likely we'll see "[e-mail]" when intending "[e-mail]" -- "[e-mail]" should become the default -- but it is the same problem from a different view.

Comment 3

[Wayne Mery (:wsmwk)]

There are also https://mzl.la/2vU9bXn