+++ This bug was initially created as a clone of Bug #1238728 +++

It's bad enough that autocomplete in compose recipient fields gives different results when the results cache is used, i.e. for slow typing with sufficient pauses vs. very fast typing without pauses, or pasting string - that's bug 1238728, inexplicably neglected. However, things start to get weird when for the non-cache (fast-type or paste) scenario, you cannot even get directly to the result which matches your search, as Thunderbird prefers a non-matching email address as top match and inline suggestion instead.
Fixing this may fix bug 1238728, not sure - definitely related.

The overall UX of this is confusing, illogical (undue influence of implementation), inconsistent, makes users feel not in control, and error-prone - it's easy to end up with an unintended address.

STR

1. Have this card in your AB, and ensure uniqueness:
   Email: foo@primary.com
   Additional Email: foo@additional.com
   All other fields: empty! (to prevent false positives)
2. Compose a new message
3. Copy the string foo@p, and paste (sic!) into recipient autocomplete input
   Note: Pasting is required to prevent artifact effects of bug 1238728!
4. Copy the string foo@a, and paste (sic!) into recipient autocomplete input
5. Compare result sets and top/inline match of 3) and 4) - especially the latter.

Actual result

3. search string foo@p (if pasted!!!) returns:

foo@p >> foo@primary.com
foo@primary.com
foo@additional.com (arguably OK, showing additional address of matching card)

4. search string foo@a (if pasted!!!) returns:

foo@a >> foo@primary.com  <-- this is the bug: non-matching address as top match
foo@primary.com
foo@additional.com

Expected result:

• Don't return non-matching additional email as top match
• Should return direct email address match as top match (for this scenario; not sure how this interacts with other, non-email searches).

4. search string foo@a (if pasted!!!) should return:

foo@a >> foo@primary.com  <-- this is the bug: non-matching address as top match
foo@additional.com
foo@primary.com

** Aceman's analysis from Bug 1238728 Comment 0 **

1.When results are fetched directly from the AB, all returned cards are analyzed and all emails found in them (primary+secondary) are returned as matches (even if one of the emails did not contain the search term).
[EDIT: ...and per this bug, the primary result is always returned as top match, even though it does not contain the search term!]

2.When there are some results in the cache (from previous autocomplete), the new search term is run on the results using a different algorithm, that also takes the email of the result into account. In there, non-matching results are removed. So it can happen only one of the user's emails prevails and the results differ from 1.

Probably what should be done is that if the search input is an email (contains @) and matches the start of the primary/secondary email address, but NOT the other one, then only one of the addresses should be added: https://searchfox.org/comm-central/rev/c880e5a1cfbce281b8836f092e08df167919d32f/mailnews/addrbook/src/AbAutoCompleteSearch.jsm#216,228

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/78db69709ebe
Make compose window add only the email (primary or secondary) that matches the searched string. r=darktrojan

Please request uplift.

Comment on attachment 9229779 [details]
Bug 1709799 - Make compose window add only the email (primary or secondary) that matches the searched string. r=darktrojan

[Approval Request Comment]
Regression caused by (bug #): No bug
User impact if declined: The composition fields for addresses will rank the primary email higher than the secondary even if the secondary is the only one matching
Testing completed (on c-c, etc.): I tested on 91, no problems detected
Risk to taking this patch (and alternatives if risky): Can't think of anything major.

(In reply to Magnus Melin [:mkmelin] from comment #5)

Please request uplift.

I suspect Magnus meant request uplift to beta 91 so the patch could make it into 91.0. But we aren't doing another 91 beta. So this will be in 92 beta, and after that perhaps into 91.0.x in a couple weeks or 91.1.0.

Hmm, so this should already be destined for 92 beta?

Yes, it will be in 92beta - no uplift needed

This also affects 78? Worth the effort to uplift?

I don't think we should uplift anything non crucial to 78 anymore.

Comment on attachment 9229779 [details]
Bug 1709799 - Make compose window add only the email (primary or secondary) that matches the searched string. r=darktrojan

[Triage Comment]
Approved for esr91

Thunderbird 91.0.2:
https://hg.mozilla.org/releases/comm-esr91/rev/7fdc2700c308