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))

Was this fixed by bug 1777156, maybe?

(In reply to Alessandro Castellani [:aleca] from comment #1)

Was this fixed by bug 1777156, maybe?

No, bug 1777156 / D152834 does not fix the prefs mentioned in comment 0 which control autocomplete and AB searches (incl. contacts sidebar).

Seems like there is very little to salvage from those prefs. The names do not match the data to that high of a degree anymore. We may want to just wontfix this. The number of users who had managed to find and edit such prefs are going to be very very few.

I don't think we support the "Phonetic" variation of anything right?
The current vCard specs don't support Phonetic data, and for what I was able to find that type of data can be added as "X-CUSTOM". Maybe in the future we should do it, but not for now.

I agree with Thomas for this specific issue.
We should offer control to users on what type of query parameters should be included in the AB search.
We can definitely do something nice with a very simple UI to have a list of "Include during search" toggable options.

This is a non-trivial scope of work that will need to be defined and organized properly.
Maybe as a first we can remove those phonetic prefs as a simple clean up.

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

Seems like there is very little to salvage from those prefs. The names do not match the data to that high of a degree anymore. We may want to just wontfix this. The number of users who had managed to find and edit such prefs are going to be very very few.

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

Seems like there is very little to salvage from those prefs. The names do not match the data to that high of a degree anymore. We may want to just wontfix this. The number of users who had managed to find and edit such prefs are going to be very very few.

There's no way we could just wontfix this bug. It's not just about the prefs. It's also about a significant and covert UX fail where our default search algorithm is pretty unpredictable and inconsistent after the implementation was broken by the new address book (see comment 0 for details on ux-principles involved). It now depends on the order of email addresses in a contact whether direct searches for parts of an email address succeed or not. No rhyme or reason for that.

But apart from fixing the UX fail, as Aleca said in comment 4, we also want to continue supporting the pref because things like Custom1-4 fields or Notes are totally useless if they cannot be searched, but which fields should be searched or not is really a matter of scenario and data structure - different users, different needs. Enterprise which keeps massive notes on a contact may want to exclude notes from search. Others may need to search exactly that data to find the needle in the haystack.

Again, arguing that the search prefs are a little-used or little-needed feature as long as we we are not exposing nor documenting them in any way is a self-fulfilling prophesy of little value. Counting users also has very limited value because if we remove/break every feature which is only used by a small percentage of users, we may lose a lot of users depending on how important those features are to them. Breaking potential enterprise use cases is worse, and we are not always seeing all of their users. Imho, supporting different users with different needs is key to maintain and expand our userbase.