Bug: Recipient autocomplete in compose does not find third and further email addresses of contacts: only "SecondEmail" in mail.addr_book.autocompletequery.format* and mail.addr_book.quicksearchquery.format*
Status: NEW
Priority: --
Created: 2022-08-01 21:32:51+00:00
Resolved: 2023-12-15 15:54:27+00:00

Recipient autocomplete (as well as AB quicksearch) does not find any third and further email addresses of contacts, because we only search "SecondEmail" in `mail.addr_book.autocompletequery.format*` and `mail.addr_book.quicksearchquery.format*`. Imo that's a pretty serious UX fail for a basic scenario.
- obviously violates **ux-consistency**: it's confusing and unexpected that searching for parts of an email address (localpart or domain) will work for the 1st and 2nd email address, but not for 3rd+ email addresses, where it may pull a blank.
- classic case of **ux-implementation-level**:
  >  interfaces should not be organized around the underlying implementation and technology in ways that are illogical, or require the user to have access to additional information that is not found in the interface itself.
- **ux-error-prevention**: can mislead the user to think that the address they were directly searching for does not exist in contacts.

**STR**

- Create contact with three email addresses:
  - first.john@example.com
  - second.john@example.com
  - third.john@example.com
- In compose window, type the following search words into `To` input field, and check autocomplete results:
  - `first` or `first.john`
  - `second` or `second.john`
  - `third` or `third.john`

**Actual**

- `first`...: autocompleting first.john@example.com succeeds (OK).
- `second`...: autocompleting second.john@example.com succeeds (OK).
- **`third`...: autocompleting third.john@example.com FAILS (this bug).**

**Expected**

- searching for third and further email addresses directly should succeed, both for recipient autocomplete and AB quick search. E.g. `third`... should return third.john@example.com

**Considerations:**

- We (Aceman and I, on Thunderbird Summit, Toronto 2014) have **created these prefs for a reason, to provide users with more control over these crucial searches**. Depending on their data layout, searching for too many or too few fields can break their scenarios (see also: custom fields, Bug 1776129). Different users have different needs, also in the enterprise.
- This interacts with the old search backbones.
- This may be non-trivial to fix.

---

`mail.addr_book.autocompletequery.format` = (or(DisplayName,c,@V)(FirstName,c,@V)(LastName,c,@V)(NickName,c,@V)(PrimaryEmail,c,@V)(SecondEmail,c,@V)(and(IsMailList,=,TRUE)(Notes,c,@V)))

`mail.addr_book.autocompletequery.format.phonetic` = (or(DisplayName,c,@V)(FirstName,c,@V)(LastName,c,@V)(NickName,c,@V)(PrimaryEmail,c,@V)(SecondEmail,c,@V)(and(IsMailList,=,TRUE)(Notes,c,@V))(PhoneticFirstName,c,@V)(PhoneticLastName,c,@V))

`mail.addr_book.quicksearchquery.format` = (or(DisplayName,c,@V)(FirstName,c,@V)(LastName,c,@V)(NickName,c,@V)(PrimaryEmail,c,@V)(SecondEmail,c,@V)(and(IsMailList,=,TRUE)(Notes,c,@V))(Company,c,@V)(Department,c,@V)(JobTitle,c,@V)(WebPage1,c,@V)(WebPage2,c,@V))

`mail.addr_book.quicksearchquery.format.phonetic` = (or(DisplayName,c,@V)(FirstName,c,@V)(LastName,c,@V)(NickName,c,@V)(PrimaryEmail,c,@V)(SecondEmail,c,@V)(and(IsMailList,=,TRUE)(Notes,c,@V))(Company,c,@V)(Department,c,@V)(JobTitle,c,@V)(WebPage1,c,@V)(WebPage2,c,@V)(PhoneticFirstName,c,@V)(PhoneticLastName,c,@V))