Closed Bug 529584 Opened 10 years ago Closed 6 years ago

Composition's address autocomplete fails to match domain part of email address (which works in AB quicksearch) - should use ".contains" for matching card fields (*foo bar*) [autocompletion]

Categories

(Thunderbird :: Address Book, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 27.0

People

(Reporter: bugzilla, Assigned: aceman)

References

(Blocks 1 open bug)

Details

(Keywords: relnote, ux-consistency, ux-efficiency, Whiteboard: [Important: Read comments 88 and 92 before commenting!][relnote: twin bug 558931][tb31features])

Attachments

(1 file, 6 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Build Identifier: Thunderbird 3.0 RC1 (but also TB2)

When starting to type an address in the To/CC fields, the email autocompletion should suggest addresses with matching domain names (excluding final extension .com .net .org, etc.)

Example: in the To field, if I start to type "xyz", autocompletion should suggest the address "abc@xyz.net" stored in my address book. At the moment, it doesn't.

More below.

Reproducible: Always

Steps to Reproduce:
1. Create three contacts in your address book: 
- "abc@xyz.net"
- "xyz@abc.net"
- "efg@hij.xyz"

2. Create a new email. Start typing "xyz" in the To field.



Actual Results:  
TB suggests only the second address, "xyz@abc.net".

Expected Results:  
- TB should suggest the first two addresses "abc@xyz.net" and "xyz@abc.net".
- In my opinion, it should NOT suggest the last one "efg@hij.xyz", otherwise starting to type "com" would match an incredible number of addresses, which makes the autocompletion useless.
Yes, this has been annoying me for quite a long time.

Why do we have different search algorithms for searching the adress book and autocompletion at all(which is also searching the address book)??
Typing xyz *will* find the contact in the address book (e.g. contacts sidebar).
They should be the same.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Is this the same thing? ... I have a contact where the two emails are set to 
  somebody@cdwg.com
  cdwg   
(yes, only cdwg) and when I type in cdwg in compose it only offers me cdwg, "somebody@cdwg.com" is not offered

is bug 558931 the same?

Is this bug a regression?
Duplicate of this bug: 836839
Depends on: 558931
I can also confirm this bug, with same situation as Wayne mentioned.
Is this bug still active? If so, can I get this assigned to me for a school project?
Sure!
Assignee: nobody → jcd_reyes89
OS: Windows XP → All
Hardware: x86 → All
Whiteboard: [school project]
(In reply to Wayne Mery (:wsmwk) from comment #2)
> Is this the same thing? ... I have a contact where the two emails are set to 
>   somebody@cdwg.com
>   cdwg   
> (yes, only cdwg) and when I type in cdwg in compose it only offers me cdwg,
> "somebody@cdwg.com" is not offered

That's this bug.

> is bug 558931 the same?

This bug 529584 here (about failing to match domains) is a small subset of more comprehensive bug 558931, which covers matching inner parts / second words anywhere in the full email address (and whatever fields we might currently be searching), like explained in Bug 558931 Comment 6 and Bug 558931 Comment 16.

> Is this bug a regression?

I think not.
But address book currently has better search algorithm, albeit it could still be improved:
Imo, ideal search algorith for address autocomplete should work like quickfilter for messages:

Searching for  mo com
should find    mozilla.com,
i.e. we should treat two search words as an AND search, i.e. not as a single string as we do now.

Given that JC & Co want to work on this, we should probably define the specs for both bugs more clearly. E.g. imo it's wrong to exclude TLDs (domain endings) from search as suggested by comment 0 (there's a number of arguments in favor of including TLDs, but I don't have time now).
Blocks: 558931
No longer depends on: 558931
We've been messing with the file "nsAbAutoCompleteSearch.js", but to no avail. I'll just upload a patch to show my attempts. Are we looking in the wrong file, or the wrong methods?
Attached file Changes to nsAbAutoCompleteSearch.js (obsolete) —
Mike, can you assist with these questions?

1) For composition's address autocomplete, is this the right file to change? (and how can we find the right file?)
http://mxr.mozilla.org/comm-central/source/mailnews/addrbook/src/nsAbAutoCompleteSearch.js

2) Is there any way of preventing a normal local installation of TB from using precompiled versions of .js files found in omni.ja\jsloader\resource\gre\components ? (More below)

(In reply to JC Reyes from comment #8)
> We've been messing with the file "nsAbAutoCompleteSearch.js", but to no
> avail. I'll just upload a patch to show my attempts. Are we looking in the
> wrong file, or the wrong methods?

JC, can you confirm that you're working on this file
http://mxr.mozilla.org/comm-central/source/mailnews/addrbook/src/nsAbAutoCompleteSearch.js

Personally, I don't know how to verify if this is the right file used by composition's autocomplete or not (but afasics, I believe it is).

JC, are you using build environment?
https://developer.mozilla.org/en-US/docs/Simple_Thunderbird_build

Looking at your patch, I think you're trying to tweak files in your local installation, i.e. tweaking omni.ja. Personally, I also do that (since I'm not building), but it is generally not recommended.

Assuming that we're working on the right file (which needs verification), I've tried to add an alert('hello world') at the spot you tweaked, and tweak my local omni.ja. I'm not getting errors, nor the alert. Conclusion: Might still be the right file, but this way of tweaking doesn't work for some reason.

I suspect the reason is a caching mechanism involving precompiled versions of javascript files. If you unzip omni.ja into a folder named omni, note that you'll find *two* files named nsAbAutoCompleteSearch.js:

a) omni\components\nsAbAutoCompleteSearch.js (17KB)
b) omni\jsloader\resource\gre\components\nsAbAutoCompleteSearch.js (15KB)

b) looks like a precompiled version of a). So I think a) is ignored at runtime, and only b) is used. Deleting b) didn't work for me (no autocomplete at all). Command line flag -purgecaches (1) didn't work for me either; I haven't tried MOZ_PURGE_CACHES environment variable yet. Documentation also points to bug 531886 - but finding the relevant information between 121 comments is kinda hard.

I think your best bet is to try building Thunderbird with your changes in a proper build environment, or wait for somebody with more insight to comment.

(1) https://developer.mozilla.org/en-US/docs/Setting_up_extension_development_environment#Development_command_flags
Flags: needinfo?(mconley)
Comment on attachment 744047 [details]
Changes to nsAbAutoCompleteSearch.js

>diff --git a/nsAbAutoCompleteSearch1.js b/nsAbAutoCompleteSearch2.js
>index df5342c..8d74350 100644
>--- a/nsAbAutoCompleteSearch1.js
>+++ b/nsAbAutoCompleteSearch2.js
>@@ -183,11 +183,13 @@ nsAbAutoCompleteSearch.prototype = {
>           this._addToResult(commentColumn, directory, card, "", false, result);
>         else {
>           let email = card.primaryEmail;
>-          if (email && email.toLocaleLowerCase().startsWith(fullString))
>+          if (email && (email.toLocaleLowerCase().startsWith(fullString)
>+              || email.toLocaleLowerCase().indexOf(fullString) > -1))

You can drop .startsWith(fullString) bc that case is covered by .indexOf(fullString).
Imo, this is going in the right direction. Caveat: This preserves current fullString logic, i.e. searching for |Doe John| will not find |John Doe|.

>@@ -195,6 +197,49 @@ nsAbAutoCompleteSearch.prototype = {
>   },
> 
>   /**
>+   * Checks whether or not the fullString is contained in the domain(s)
>+   * of an email address.
>+   *
>+   * @param email       The string to be parsed and checked.
>+   * @param fullString  The fulle search string.
>+   * @return            True if the email's domain{s} matches with fullString,
>+   *                    false otherwise.
>+   */
>+  /*_matchesDomain: function _matchesDomain(fullString, email)
>+  {
>+  [...]
>+    return false;
>+  },
>+  */  

This function is out-commented, so it will not be used.
This looks wrong design to me:

With your design (of _matchesDomain function):

If email address is...
somebody@administration.mozilla.com

...only these search expressions will find that address (pipes for visual demarkation only):
|administration| or |mozilla| or |com|

These search words will *not* find that address:
|admin| or |moz| or |co|

I don't think we want to limit domain search to full [sub]domain matches only.
design as in .indexOf() search algorithm above is much better.

>+
>+  /**
>    * Checks a card against the search parameters to see if it should be
>    * included in the result.
>    *
>@@ -321,7 +366,7 @@ nsAbAutoCompleteSearch.prototype = {
>            ((card == result._searchResults[insertPosition].card &&
>              !isPrimaryEmail) ||
>             emailAddress > result._searchResults[insertPosition].value))
>-      ++insertPosition;
>+      ++insertPosition;0

Can you explain this change?
 
>     result._searchResults.splice(insertPosition, 0, {
>       value: emailAddress,
UX flags:

* Composition's adress autocomplete does not match the domain part of an email address, but AB quick search and contacts side bar search do, which violates internal ux-consistency.

* impossibility of finding recipients based on their domain name obviously violates ux-efficiency, lots of use cases where search by domain can be helpful
Summary: Email autocompletion fails to match domain part of address → Composition's address autocomplete fails to match domain part of email address (which works in AB quicksearch) [autocompletion]
Mike, could you also point us to the source code where AB quicksearch currently matches email addresses including their domain part?

JC, given that domain matching works in TB's Address Book (AB), we should also look at that existing source code for inspiration, code consistency, and/or avoiding unnecessary duplication of code (perhaps the same functions can be shared between AB and composition).
(In reply to Thomas D. from comment #13)
> Mike, could you also point us to the source code where AB quicksearch
> currently matches email addresses including their domain part?

Perhaps here:

http://mxr.mozilla.org/comm-central/source/mail/components/addrbook/content/abContactsPanel.js#132

And there's an highly interesting pref involved (Tools > Options > Advanced > General > Config Editor, then search for the pref name):
mail.addr_book.quicksearchquery.format=?(or(PrimaryEmail,c,@V)(DisplayName,c,@V)(FirstName,c,@V)(LastName,c,@V))

So if we're lucky, we could use the same or similar stuff here.
Thanks for the update Thomas! Those edits apart from _searchWithinEmail() and _matchesDomain() are just mistakes, so just ignore them. My partner has the computer with the working TB build. My file is just for jotting down ideas.

The added expression " || email..indexOf()" in _searchWithinEmail() was just a test, just to see if we get different results (which we did not). We were going to refine our logic after finding where in code the emails are checked. Also, thanks for clearing up the specs on what we want to query.

We will look at abContactsPanel.js and try to apply their methods to the omni file.
(In reply to JC Reyes from comment #15)
> Thanks for the update Thomas! Also, thanks for clearing up the specs on what we
> want to query.

Imo, ideally we should use same search algorithm like in Quickfilter bar and Global Search: When user searches for |string1 string2|, we should split the search expression at the spaces and return matches if each of word1 and word2 (independently of each other) are contained anywhere in the pool of target fields, like this:

{(Firstname contains string1) OR (Lastname contains string1) OR
(Displayname contains string1) OR (Email1 contains string1) OR ...}
AND 
{(Firstname contains string2) OR (Lastname contains string2) OR
(Displayname contains string2) OR (Email1 contains string2) OR ...}


More practically:

For a given AB card...

First Name = Anne Mary
Last Name = Miller-Doe
Display Name = Mia (Mozilla Lead Admin)
Email1 = millerdoe.annemary@administration.mozilla.com
Email2 = firstmanager@mozilla.org

...all of the following sample searches should find the card (regardless of capitalization):

Anne Mary
Mary Anne [for FirstName and Email1 field, that's a match in reverse order!]
Doe Miller
Miller Doe
millerdoe
Mia admin
admin mia
Mary Lead [note: cross-field match!]
Miller Lead [note: cross-field match!]
millerdoe Lead [note: cross-field match!]
moz man [note: email2 contains man]
ill man [note: all fields except firstname contain "ill" as a substring]
mia com [note: elegant way of finding Mia's address ending in .com]
mia .com [note: elegant way of finding Mia's address ending in .com]

Again ideally, while we are here, we could consider including some more AB fields in the search - e.g. what's the point of having a nick name field when users can't search on that field?
(In reply to Thomas D. from comment #16)
> Imo, ideally we should use same search algorithm like in Quickfilter bar and
> Global Search:

Where the guiding principle is always the same (and also applies to Google searches):

More search terms, less results (while it doesn't matter where exactly in the result the terms are).

So the idea is to refine your search by adding a few unique strings that you know are found in the target, without caring about the details if they are at the beginning or middle or end of fields, or even cross-field.

TB has used that algorithm successfully for QuickFilter and Global Search:
E.g. you can just enter a part involved email addresses (say Paul) and a unique word from the subject (say France) to nail down that specific mail from Paul's holiday in France.
Thomas, in my Simple Thunderbird build, I don't have this omni folder or omni.ja you spoke of.

I've reworked my algorithm to your specification, since I could not find the existing one in QuickFilter or Global Search. Some people in the IRC have suggested I use the -purgeCache flag for running, but that did not work either.
FWIW, the flag is -purgecaches
Can I get unassigned from this? This bug is out of my league to solve.
Assignee: jcd_reyes89 → nobody
Reyes,
I guess that's ok. Feel free to solve some another bug. :)
Hey, sorry I'm late to the party. Finally have a chance to go through my review flags and needinfo queue...

(In reply to Thomas D. from comment #10)
> Mike, can you assist with these questions?
> 
> 1) For composition's address autocomplete, is this the right file to change?
> (and how can we find the right file?)
> http://mxr.mozilla.org/comm-central/source/mailnews/addrbook/src/
> nsAbAutoCompleteSearch.js

Yes, that is one of the files. The LDAP autocomplete implementation can be found under nsLDAPAutoCompleteSession.cpp, but I believe nsAbAutoCompleteSearch.js is what you need for standard Mork address books.

> 
> 2) Is there any way of preventing a normal local installation of TB from
> using precompiled versions of .js files found in
> omni.ja\jsloader\resource\gre\components ? (More below)
> 

I would not recommend changing omni.ja like this. As you also suggest below, I'd recommend a normal TB build environment. Make your changes, and do an incremental build to test them.

-Mike
Flags: needinfo?(mconley)
Duplicate of this bug: 445175
Attached patch patch (obsolete) — Splinter Review
So would this work?
I intentionally changed to 'contains' only for emails, not First/Last name. In names you probably do not look for partial string in the middle.
Assignee: nobody → acelists
Attachment #744047 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #763233 - Flags: review?(mkmelin+mozilla)
Attachment #763233 - Flags: review?(mconley)
Attachment #763233 - Flags: feedback?(bugzilla2007)
Well, for Display name it would make sense, per bug 558931 comment 16. So if somebody still wants it I could change that.

But please leave multiword logic for bug 558931.
Attached patch patch v2 (obsolete) — Splinter Review
Attachment #763233 - Attachment is obsolete: true
Attachment #763233 - Flags: review?(mkmelin+mozilla)
Attachment #763233 - Flags: review?(mconley)
Attachment #763233 - Flags: feedback?(bugzilla2007)
Attachment #763273 - Flags: review?(mkmelin+mozilla)
Attachment #763273 - Flags: review?(mconley)
Attachment #763273 - Flags: feedback?(bugzilla2007)
In reply to :aceman from comment #24)
> Created attachment 763233 [details] [diff] [review]
> patch

Aceman, thanks for taking this patch, that's great.

> So would this work?

It works a lot better for single-word data than before in that .contains(word1) will now match the domain part of emails, too, because 

("user@gmail.com").contains("gmail")==true

But it will fail even for simple cases e.g. searching for [use gmail] unless we have split multi-word search with the algorithm of comment 16. It also fails for [use mail.com] and I don't see why it should.

> I intentionally changed to 'contains' only for emails, not First/Last name.
> In names you probably do not look for partial string in the middle.

That's a wrong assumption even if you only search for what you consider the "beginning" of names, as proven in numerous examples found in my comments on this bug 529584 (e.g. comment 16) and bug 558931 (e.g. Bug 558931 Comment 47).
It will still fail for a lot of cases because the data structure of name fields is unpredictable with double-word firstnames, double surnames, inverted order or additions in Display name field, e.g.

Aceman (TB coder++, bmo-triage++) <aceman@asdf.com>
Wayne Mery (:wsmwk) <vseerror@asdf.com>
Anne-Marie Bourcier-Surname2 <bourcierannemarie@asdf.com>
Bourcier-Surname2, Anne-Marie <annemariebourcier@asdf.com>

It's much easier to find Wayne searching for ":wsm", but that can only be found in the middle of strings. For double-names, e.g. Surname2 also only found in the middle. And you have no idea what other data people can put even in the First Name or Last Name fields. No reason why we shouldn't find that data efficiently.

(In reply to :aceman from comment #25)
> Well, for Display name it would make sense, per bug 558931 comment 16. So if
> somebody still wants it I could change that.

Me wants.  But it's still not sufficient, we need "split multiword" and "contains/substring" logic in *all* fields for successful matching of anything beyond very simple single-word "First Last" cases and even for those you will not find all your matching contacts with the current algorithms.

And actually, if bug 558931 comment 16 about case of "Display Name" makes sense to you, you have already subscribed to the new logic, because the same applies to any other name fields in exactly the same way.

> But please leave multiword logic for bug 558931.

Aceman would be a cool assignee for that bug, wouldn't he? ;)
Comment on attachment 763273 [details] [diff] [review]
patch v2

># HG changeset patch
># Parent f2135de297c1fc7f84921abd2579cc5e1cd58efe
># User aceman <acelists@atlas.sk>
>Bug 529584 - in composition address autocomplete, match the search string anywhere in the cards email addresses. r?mconley, r?mkmelin

To add clarity for the record, we should add "or displayname" at the end of bug description too

>diff --git a/mailnews/addrbook/src/nsAbAutoCompleteSearch.js b/mailnews/addrbook/src/nsAbAutoCompleteSearch.js
>--- a/mailnews/addrbook/src/nsAbAutoCompleteSearch.js
>+++ b/mailnews/addrbook/src/nsAbAutoCompleteSearch.js
>@@ -156,18 +156,19 @@ nsAbAutoCompleteSearch.prototype = {
>+          if (email && email.toLocaleLowerCase().contains(fullString))

To play safe, I think we should also change to .contains for DisplayName in _checkEntry function, to be consistent, regardless if that function is currently used or not; and there's also emailToUse in that section which needs changing.

http://mxr.mozilla.org/comm-central/source/mailnews/addrbook/src/nsAbAutoCompleteSearch.js#220
220     if (card.displayName.toLocaleLowerCase().startsWith(fullString) ||
221         firstName.startsWith(fullString) ||
222         lastName.startsWith(fullString) ||
223         emailToUse.toLocaleLowerCase().startsWith(fullString))
224       return true;


Did you also change things for LDAP?

e.g.
http://mxr.mozilla.org/comm-central/source/mailnews/addrbook/src/nsAbLDAPAutoCompleteSearch.js#109

---
Broader MXR-search for autocomplete files
http://mxr.mozilla.org/comm-central/find?text=&string=autocomplete
Attachment #763273 - Flags: feedback?(bugzilla2007) → feedback+
Comment on attachment 763273 [details] [diff] [review]
patch v2

Review of attachment 763273 [details] [diff] [review]:
-----------------------------------------------------------------

Nice!

::: mailnews/addrbook/src/nsAbAutoCompleteSearch.js
@@ +165,2 @@
>     *                     addresses to ensure only matching results are added.
> +   *                     This value is already passed in lowercased.

is already -> should be
Attachment #763273 - Flags: review?(mkmelin+mozilla) → feedback+
Whiteboard: [school project]
Pls let's do the only sane thing and add at least "contains fullstring" logic for *all* relevant fields like First Name, Last Name, and Nick now, even if you want to do split-multiword logic later (which is a true loss for search efficiency).

(In reply to :aceman from comment #24)
> Created attachment 763233 [details] [diff] [review]
> patch
> 
> So would this work?
> I intentionally changed to 'contains' only for emails, not First/Last name.
> In names you probably do not look for partial string in the middle.

Aceman accepted that in display names, we should also do contains search, so that's already in the current patch.

Aceman, I think your fears that using "contains fullstring" search for First/Last will yield too many results, or false positives, are unfounded and we are making a big mistake if we don't change this now while we are here so that users can benefit in TB24.

You don't have to trust me for what I'm saying (and I'm 98% sure that there won't be any problems), please try it out yourself, and trust the bug database:

Address book quick search already has "contains" aka substring search algorithm for first name, last name, and display name, as requested here.
* can you please try that search for your usecases and see if it works for you? Any problems?

Quick Filter bar already also has "contains" aka substring search, AND split multiword logic for recipient, sender, and subject. Turn off subject search, and enter some beginnings (or any parts) of names or email addresses that you remember.
* can you please try that search for your usecases and see if it works for you? Any problems?

Lessons from history: For quicksearch, we used to have "contains fullstring", before we evolved to "split multiword" which was deliberately *added* for TB3 because it's just so superiour! I have never heard of any bug reports that AB quicksearch or Quick Filter Bar are returning too many or useless results because of "contains" or "split multiword" logic - have you?

So if it works in AB and quicksearch, why should it not work for autocomplete, where we even have the extra benefit of popularityIndex which will automatically push your favourite addresses to the top?

Furthermore, I don't think there's any reason to justify why we should have different search algorithms in AB quicksearch vs. Recipient Autocomplete. It's just confusing and violating ux-consistency. And it fails for so many everyday cases due to the old "beginsWith" algorithm of current autocomplete...

Please, please, please!!!!!
(In reply to Thomas D. from comment #30)
> Pls let's do the only sane thing and add at least "contains fullstring"
> logic for *all* relevant fields like First Name, Last Name, and Nick now,
> even if you want to do split-multiword logic later (which is a true loss for
> search efficiency).
 
> Address book quick search already has "contains" aka substring search
> algorithm for first name, last name, and display name, as requested here.
> * can you please try that search for your usecases and see if it works for
> you? Any problems?

Actually, for direct comparison, you can use Contacts sidebar - enter the same searchterms in Contacts sidebar and Recipient autocomplete - which one is better in finding things? (But be aware that Contacts sidebar has this unbelievable shortcoming of only searching one addressbook, never all, vs. autocomplete which searches all AB's, so consider that when comparing results).

> Please, please, please!!!!!
Comment on attachment 763273 [details] [diff] [review]
patch v2

I have no problem with that if the reviewers agree with you. Bwinton, mkmelin?
Attachment #763273 - Flags: ui-review?(bwinton)
Comment on attachment 763273 [details] [diff] [review]
patch v2

(Since Mike is already looking at this patch for the review, let's let him do the ui-review, too.  ;)
Attachment #763273 - Flags: ui-review?(bwinton) → ui-review?(mconley)
In Bug 558931 Comment 47, there's yet another explanation why this is required to get not just better results, but *any* results at all for many everyday use cases like double first names etc. Data structure of all those card fields is never fully defined by TB user, often deviating from the simple First Last default set, as they tend to arrive from all sorts of sources e.g. when you reply to messages where the other person defined his display name and that same unstructured display name will be silently added to your own TB address book in unpredictable ways when you send your reply message.

(In reply to Thomas D. from comment #30)
> Pls let's do the only sane thing and add at least "contains fullstring"
> logic for *all* relevant fields like First Name, Last Name, and Nick now,
> even if you want to do split-multiword logic later (which is a true loss for
> search efficiency).
>
> You don't have to trust me for what I'm saying (and I'm 98% sure that there
> won't be any problems), please try it out yourself, and trust the bug
> database:
> 
> Address book quick search already has "contains" aka substring search...
> Quick Filter bar already also has "contains" aka substring search, AND split
> multiword logic for recipient, sender, and subject...

Firefox Awesome Bar is another example, they also mostly use "contains" aka substring search, e.g. for your history, and that one has really been designed to find the needle in the haystack... which works very well for me all the time

> Lessons from history: For quicksearch, we used to have "contains
> fullstring", before we evolved to "split multiword" which was deliberately
> *added* for TB3 because it's just so superiour! I have never heard of any
> bug reports that AB quicksearch or Quick Filter Bar are returning too many
> or useless results because of "contains" or "split multiword" logic - have
> you?
> 
> So if it works in AB and quicksearch, why should it not work for
> autocomplete, where we even have the extra benefit of popularityIndex which
> will automatically push your favourite addresses to the top?
> 
> Furthermore, I don't think there's any reason to justify why we should have
> different search algorithms in AB quicksearch vs. Recipient Autocomplete.
(In reply to Thomas D. from comment #34)
> In Bug 558931 Comment 47, there's yet another explanation why this is
> required to get not just better results, but *any* results at all
>
> (In reply to Thomas D. from comment #30)
> > Address book quick search already has "contains" aka substring search...
> >
> > Quick Filter bar already also has "contains" aka substring search, AND split
> > multiword logic for recipient, sender, and subject...
> 
> Firefox Awesome Bar is another example, they also mostly use "contains" aka
> substring search, e.g. for your history, and that one has really been
> designed to find the needle in the haystack... which works very well for me
> all the time

Sorry, forgot to mention that FF Awesome Bar also has the magic combination os "contains" aka substring search AND "split multiword" logic requested by bug 558931 - so you can easily filter for any combination of random substrings from your history's page titles and urls...

Same for BMO QuickSearch: "contains" aka substring AND "split multiword" logic, so the following search involving random substrings of bug title succeeds to filter this single bug out of 10.000+ TB & Mailnews bugs:

:thun,mail complet fail match

https://bugzilla.mozilla.org/buglist.cgi?quicksearch=%3Athun%2Cmail%20complet%20fail%20match&list_id=6911962

The dataset of TB address books is usually much smaller than that, while the data tends to be more unique

> > Lessons from history: For quicksearch, we used to have "contains
> > fullstring", before we evolved to "split multiword"
(In reply to Thomas D. from comment #28)
> >Bug 529584 - in composition address autocomplete, match the search string anywhere in the cards email addresses. r?mconley, r?mkmelin
> 
> To add clarity for the record, we should add "or displayname" at the end of
> bug description too
OK

> >diff --git a/mailnews/addrbook/src/nsAbAutoCompleteSearch.js b/mailnews/addrbook/src/nsAbAutoCompleteSearch.js
> >--- a/mailnews/addrbook/src/nsAbAutoCompleteSearch.js
> >+++ b/mailnews/addrbook/src/nsAbAutoCompleteSearch.js
> >@@ -156,18 +156,19 @@ nsAbAutoCompleteSearch.prototype = {
> >+          if (email && email.toLocaleLowerCase().contains(fullString))
> 
> To play safe, I think we should also change to .contains for DisplayName in
> _checkEntry function, to be consistent, regardless if that function is
> currently used or not; and there's also emailToUse in that section which
> needs changing.
Ok, thanks.

> Did you also change things for LDAP?
No, I can't touch that because I do not use LDAP so can't test it and also there do not seem to be similar search patterns as in the nsAbAutoCompleteSearch.js .
Attached patch patch v3 (obsolete) — Splinter Review
Fixes nits from Thomas D.

Mconley, if you agree with Thomas to also have First and Last Name be matched via "contains" say so and I update the patch.
Attachment #763273 - Attachment is obsolete: true
Attachment #763273 - Flags: ui-review?(mconley)
Attachment #763273 - Flags: review?(mconley)
Attachment #766313 - Flags: ui-review?(mconley)
Attachment #766313 - Flags: review?(mconley)
(In reply to :aceman from comment #37)
> Created attachment 766313 [details] [diff] [review]
> patch v3
> 
> Fixes nits from Thomas D.
> 
> Mconley, if you agree with Thomas...

...and 9+2 duplicates, and 26 getsatisfaction votes...

> to also have First and Last Name be
> matched via "contains" say so and I update the patch.

(In reply to Wayne Mery (:wsmwk) from comment #50)
> (In reply to Thomas D. from comment #49)
> > Aceman says:
> > > I have no problem with that if the reviewers agree with you. Bwinton,
> > > mkmelin?
> > 
> > 9 duplicates and 20 votes on GS also agree
> 
> An indication of the strength/need of this request is:
> - many of those duplicates are recent bug reports
> - I easily found 3 more GS topics (I tagged them appropriately, but stopped
> searching after finding 3)
> [...]
> And I doubt too many results will be a problem for most people I bet the
> average user has less than 500-1000 contacts ... ldap users being an
> exception.
(In reply to Thomas D. from comment #38)
> ...and 9+2 duplicates, and 26 getsatisfaction votes...
> > to also have First and Last Name be
> > matched via "contains" say so and I update the patch.

That's duplicates and comments of Bug 558931, the "contains" part of which we are suggesting to fix here.

> (In reply to Wayne Mery (:wsmwk) from comment #50)

That's Bug 558931, comment 50

> > (In reply to Thomas D. from comment #49)
> > > Aceman says:
> > > > I have no problem with that if the reviewers agree with you.
> > [...]
> > An indication of the strength/need of this request is:
> > - many of those duplicates are recent bug reports
(In reply to :aceman from comment #37)
> Created attachment 766313 [details] [diff] [review]
> patch v3
> 
> Fixes nits from Thomas D.
> 
> Mconley, if you agree with Thomas to also have First and Last Name be
> matched via "contains" say so and I update the patch.

Yeah, let's give it a shot.
Comment on attachment 766313 [details] [diff] [review]
patch v3

Cancelling review requests until patch is updated.
Attachment #766313 - Flags: ui-review?(mconley)
Attachment #766313 - Flags: review?(mconley)
Blocks: 892640
Aceman, bug 892640 is duplicate of
Bug 118624 - AB quick search should match Nickname field

I think we can just add that here with your patch; as I explained in Bug 892640 Comment 2:

> I don't think that skipping nicknames could be intentional - what's the
> purpose of nicknames when you can't search for them? Aren't nicknames *only*
> for searching/addressing?
> 
> We have several bugs and/or comments requesting to include nickname field
> when searching and autocomplete addressing, and I think it's the obvious
> thing to do with nick names.

FTR:  Bug 118624 currently has 6 duplicates that cover a large time span.

Aceman, perhaps we could even do split multiword search here with your patch?
I imagine it's "just" a matter of splitting on spaces at the right time/spot before feeding things into search algorithms/functions.

Furthermore, there's
Bug 298438 - Address book quick search should search in whole address card
Blocks: 118624, 298438
No longer blocks: 892640
Please do not extend bug requirements like this. All the features you want have their own bugs so let them be fixed there.
Version: unspecified → Trunk
OK, this is a version using .contains() everywhere.

(I am not sure if this affects anything in Seamonkey, but it is in /mailnews so please check it out Ian.)
Attachment #766313 - Attachment is obsolete: true
Attachment #776529 - Flags: review?(mkmelin+mozilla)
Attachment #776529 - Flags: review?(mconley)
Attachment #776529 - Flags: review?(iann_bugzilla)
Attachment #776529 - Flags: feedback?(bugzilla2007)
Comment on attachment 776529 [details] [diff] [review]
patch v4 (obsoleted by identical patch v4.1 with updated comments)

Review of attachment 776529 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me!
Attachment #776529 - Flags: review?(mkmelin+mozilla) → feedback+
Comment on attachment 776529 [details] [diff] [review]
patch v4 (obsoleted by identical patch v4.1 with updated comments)

Thanks aceman for the new patch! Looks good to me. Using "contains" instead of "begins with" is a large improvement over the status quo (although we're still only half-way down the road as we still match against multiple words as fullstring instead of as split multi-word, bug 558931).

># HG changeset patch
># Parent 1e65ee5e592cb87b801cfe192abaf1592e7a7336
># User aceman <acelists@atlas.sk>
>Bug 529584 - in composition address autocomplete, match the search string anywhere in the cards email addresses or display name. r?mconley, r?mkmelin
>

Nit: we're now using "contains" for more fields than just email and display name (but it would be clumsy to list them all because some fields inconsistently only apply to mail lists), so this should be something more generic like

Bug 529584 - In composition address autocomplete, match the search string *anywhere* in the card's fields that we currently search, e.g. email addresses or display name. r?mconley, r?mkmelin

>diff --git a/mailnews/addrbook/src/nsAbAutoCompleteSearch.js b/mailnews/addrbook/src/nsAbAutoCompleteSearch.js
>--- a/mailnews/addrbook/src/nsAbAutoCompleteSearch.js
>+++ b/mailnews/addrbook/src/nsAbAutoCompleteSearch.js
>@@ -156,18 +156,19 @@ nsAbAutoCompleteSearch.prototype = {
>   },
> 
>   /**
>    * Searches for cards in a directory matching against email addresses only.
>    * When matches are found it will add them to the results.
>    *
>    * @param searchQuery  The boolean search query to use.
>    * @param fullString   The full string that is being searched against. This
>-   *                     is used as a "Begins with" check against the email
>+   *                     is used as a "Contains" check against the email
>    *                     addresses to ensure only matching results are added.

Nit: matches were restricted before ("only"), we're expanding the result set ("all", now including domain matches), so this should be:

is used as a "contains" check against the *full* email
addresses to ensure *all* matching results are added.
(highlighting added only for pointing out the change here, remove stars for the real comment)
Attachment #776529 - Flags: feedback?(bugzilla2007) → feedback+
Attachment #776529 - Attachment description: patch v4 → patch v4 (use "contains" to match fullstring against email addresses and other card fields)
Summary: Composition's address autocomplete fails to match domain part of email address (which works in AB quicksearch) [autocompletion] → Composition's address autocomplete fails to match domain part of email address (which works in AB quicksearch) - should use ".contains" for matching card fields [autocompletion]
Iann, Mike, this straightforward little patch is waiting for your review (also  touches code in mailnews). Would be really cool to land this for upcoming TB 24/25 for which I think the merging is tomorrow on Mon, 5th August.

This is a great improvement of autocomplete search algorithm which currently fails to find a lot of expected matches (see e.g. comment 16) because of unnecessary restriction of
"somefield.startsWith(fullstring)", which we have now replaced with
"somefield.contains(fullstring)".

This is required because we can't predict the data structure of fields like Display name, First Name, Last Name, all of which might be filled by user with more than one word, so we've had a lot of bugs that autocomplete fails to find any words or substrings if they don't happen to be exactly at the beginning of those fields in the card.

(In reply to Magnus Melin from comment #45)
> Comment on attachment 776529 [details] [diff] [review]
> patch v4 (use "contains" to match fullstring against email addresses and
> other card fields)
> 
> Review of attachment 776529 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Looks good to me!

Magnus, Mike, patch header has "r?mconley, r?mkmelin", which I'd consider alternatives. Does this really need review from mconley, or could Magnus' review per comment 45 suffice if you make it explicit so that this can land in time? It would be really painful having to wait for this significant enhancement for another year.

Mike, in your comment 40 you gave green light for the UX of this. Could you make this explicit as ui-review+?

Could you also comment on bug 118624 if you see any reason why we search nick name field for autocomplete, but not for AB quicksearch (Bug 118624), which looks like violating ux-consistency?
Flags: needinfo?(mkmelin+mozilla)
Flags: needinfo?(mconley)
Flags: needinfo?(iann_bugzilla)
Comment on attachment 776529 [details] [diff] [review]
patch v4 (obsoleted by identical patch v4.1 with updated comments)

Patch has been updated according to Mike's green-light UX comment 40, so re-requesting ui-review (canceled by comment 41 to wait for patch update).
Attachment #776529 - Flags: ui-review?(mconley)
Mark (mbanner), fyi; would be great to see this land in time for pending TB.next (see comment 47).

This is a great improvement of autocomplete search algorithm which fixes ux-inconsistencies between autocomplete and AB quicksearch by allowing domain search and addressing the "contains" part of Bug 558931 (9 dupes, 26 GS votes). Great value with no strings attached ;)
Attachment #776529 - Flags: review?(iann_bugzilla) → review+
Flags: needinfo?(iann_bugzilla)
I am away from bugzilla for this week. If the time is short, and there are only some comment changes to do (e.g. comment 46) I'd be thankful if Thomas or Suyash did them for me. Thanks.
Mike (mconley), this is urgently waiting for your confirmation (ui-r, r) for landing in time for the merge (today?). It's all ready, agreed and pre-reviewed.

This patch (by aceman) already has:

* your "go-ahead" for "contains" search (which looks like ui-review+)
* review+ from Ian Neal for mailnews
* feedback+ for code from Magnus (mkmelin) in comment 45 (which looks like review+)
* feedback+ from ThomasD

Per my comment 46, and aceman's comment 50, this patch v 4.1 is identical with aceman's patch v. 4 except that 2 comments have been updated.
Attachment #785696 - Flags: ui-review?(mconley)
Attachment #785696 - Flags: review?(mconley)
Attachment #785696 - Flags: feedback?(mkmelin+mozilla)
Comment on attachment 785696 [details] [diff] [review]
patch v4.1 (same as v4, only with updated comments; use "contains" to match fullstring against email addresses and other card fields)

Magnus, kindly forward your feedback+ from identical previous patch, or convert into review+ to complement or perhaps on behalf of mconley's. I'm really concerned that this significant everyday improvement shouldn't miss the deadline... :|
Attachment #785696 - Flags: feedback+
Comment on attachment 776529 [details] [diff] [review]
patch v4 (obsoleted by identical patch v4.1 with updated comments)

Clearing review requests of old patch v4 because there's new identical patch v4.1 with nitfixed comments in attachment 785696 [details] [diff] [review] which is waiting for the same reviews from :mconley

I haven't obsoleted patch 4 with identical code yet to show the existing flags with the right names.
Attachment #776529 - Attachment description: patch v4 (use "contains" to match fullstring against email addresses and other card fields) → patch v4 (obsoleted by identical patch v4.1 with updated comments)
Attachment #776529 - Flags: ui-review?(mconley)
Attachment #776529 - Flags: review?(mconley)
Comment on attachment 785696 [details] [diff] [review]
patch v4.1 (same as v4, only with updated comments; use "contains" to match fullstring against email addresses and other card fields)

Review of attachment 785696 [details] [diff] [review]:
-----------------------------------------------------------------

I'd give this r+ but i don't have official review rights for this as it's in mailnews/
Attachment #785696 - Flags: feedback?(mkmelin+mozilla) → feedback+
Comment on attachment 785696 [details] [diff] [review]
patch v4.1 (same as v4, only with updated comments; use "contains" to match fullstring against email addresses and other card fields)

Review of attachment 785696 [details] [diff] [review]:
-----------------------------------------------------------------

I'm fine with this from inspection. I was on vacation this past weekend, so sorry about the tardiness.
Attachment #785696 - Flags: ui-review?(mconley)
Attachment #785696 - Flags: ui-review+
Attachment #785696 - Flags: review?(mconley)
Attachment #785696 - Flags: review+
Mark (mbanner), this is now ready for checkin as it has all the reviews including ui-r+ from Mike Conley (per Blake's Comment 33) and mailnews r+ from Ian Neal.

*Could you please land this* whereever it needs to land *to be included in the next release version of TB*... *Great value, no strings, no risk* as we are just changing internal "startsWith(fullstring)" matching pattern to "contains(fullstring)" whithout actually touching any other code.

This greatly improves on a major flaw in recipient autocomplete which currently fails to return a great range of expected matches for many scenarios where user data on AB cards involves more than just plain vanilla "John Doe" (who could be "John Paul Miller-Doe"), or search terms like domains or second names which don't happen to occur of the beginning of any fields (e.g. "Paul" or "Doe" to find "John Paul Miller-Doe").

(In reply to Thomas D. from comment #49)
> Mark (mbanner), fyi; would be great to see this land in time for pending
> TB.next (see comment 47).
> 
> This is a great improvement of autocomplete search algorithm which fixes
> ux-inconsistencies between autocomplete and AB quicksearch by allowing
> domain search and addressing the "contains" enhancement part of Bug 558931
>(9 dupes, 26 GS votes). Great value with no strings attached ;)
Flags: needinfo?(mbanner)
Keywords: checkin-needed
I'm hereby requesting that this should be approved for TB24 comm-beta. Please someone with the right powers set the right flags, as I can't.

In addition to the major problems which this fixes per comment 56, here's yet another powerful reason why this should get approval for TB24 comm-beta:

In fact, this bug will go a long way to provide an excellent workaround for TB's current lack of free tagging and grouping of contacts, and to avoid the horrible ux of TB's mailing lists, via using existing nickname field:

- User can add a free sequence of "tags" to nickname field, e.g.
card1, nickname: "work, mozilla, friends, geeks"
card2, nickname: "work, geeks"
card3, nickname: "private, friends"
- With this patch of attachment 785696 [details] [diff] [review], we'll now do a "contains(fullstring)" search on nickname so user can easily filter for single "tags":

Search for... -> will find...
"work" -> card1, card2
"mozilla" -> card1
"friends" -> card1, card3
"geeks" -> card1, card2

After bug 558931 (do split-string instead of fullstring search), users could even use advanced filtering for *combinations* of multiple "tags" in nickname field, like this:

"work geeks" -> card1, card2
"work friends" -> card1
(In reply to Thomas D. from comment #57)
> I'm hereby requesting that this should be approved for TB24 comm-beta.
> Please someone with the right powers set the right flags, as I can't.
> 
> In addition to the major problems which this fixes per comment 56, here's
> yet another powerful reason why this should get approval for TB24 comm-beta:
> 
> In fact, this bug will go a long way to provide an excellent workaround for
> TB's current lack of free tagging and grouping of contacts, and to avoid the
> horrible ux of TB's mailing lists, via using existing nickname field:
> 
> - User can add a free sequence of "tags" to nickname field, e.g.
> card1, nickname: "work, mozilla, friends, geeks"
> card2, nickname: "work, geeks"
> card3, nickname: "private, friends"
> - With this patch of attachment 785696 [details] [diff] [review], we'll
> now do a "contains(fullstring)" search on nickname so user can easily filter
> for single "tags":
> 
> Search for... -> will find...
> "work" -> card1, card2
> "mozilla" -> card1
> "friends" -> card1, card3
> "geeks" -> card1, card2
> 
> After bug 558931 (do split-string instead of fullstring search), users could
> even use advanced filtering for *combinations* of multiple "tags" in
> nickname field, like this:
> 
> "work geeks" -> card1, card2
> "work friends" -> card1
Flags: needinfo?
Whiteboard: [approval-comm-beta TB24?]
Flags: needinfo?(mkmelin+mozilla)
Flags: needinfo?(mconley)
Flags: needinfo?
(In reply to Thomas D. from comment #57)
> In fact, this bug will go a long way to provide an excellent workaround for
> TB's current lack of free tagging and grouping of contacts, and to avoid the
> horrible ux of TB's mailing lists, via using existing nickname field:
> 
> - User can add a free sequence of "tags" to nickname field, e.g.
> card1, nickname: "work, mozilla, friends, geeks"
> card2, nickname: "work, geeks"
> card3, nickname: "private, friends"

To fully exploit that workaround and avoid false positives from other matching fields, you'd probably have to use a unique marker for your tags, e.g. a preceding special character like ":" or "/" or "$":

card1, nickname: ":work, :mozilla, :friends, :geeks" (without quotes)
card2, nickname: ":work, :geeks"
card3, nickname: ":private, :friends"
The flags should currently be approval‑comm‑aurora for tb25, and  	approval‑comm‑beta for tb24
Attachment #776529 - Attachment is obsolete: true
https://hg.mozilla.org/comm-central/rev/d07ffab06a6b
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 26.0
Backed out for xpcshell failures.
https://hg.mozilla.org/comm-central/rev/5c06313e3275

https://tbpl.mozilla.org/php/getParsedLog.php?id=26495322&tree=Thunderbird-Trunk
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: Thunderbird 26.0 → ---
Duplicate of this bug: 864006
Oh yes, I forgot tests :(
(In reply to Thomas D. from comment #57)
> I'm hereby requesting that this should be approved for TB24 comm-beta.
> Please someone with the right powers set the right flags, as I can't.

You can. You should set approval-comm-aurora/approval-comm-beta to '?' on the patch and give a description for the risk profiles. This flags it as requesting approval.

My main concerns would be the fact that this isn't also syncing the ldap case. I'm not quite sure if that's a big issue or not, but I'd want to discuss it with drivers before landing.

At the moment, this still needs completing and landing on trunk, of course.
Flags: needinfo?(mbanner)
(In reply to Mark Banner (:standard8) (afk until 27th Aug) from comment #65)
> (In reply to Thomas D. from comment #57)
> > I'm hereby requesting that this should be approved for TB24 comm-beta.
> > Please someone with the right powers set the right flags, as I can't.
> 
> You can. You should set approval-comm-aurora/approval-comm-beta to '?' on
> the patch and give a description for the risk profiles. This flags it as
> requesting approval.

Thanks, I missed that one as I was looking in the wrong place.

> My main concerns would be the fact that this isn't also syncing the ldap
> case. I'm not quite sure if that's a big issue or not, but I'd want to
> discuss it with drivers before landing.

I'd tend to believe that fixing a big half of this bug (local ABs) is better than status quo because the local address book case probably fixes this for a large majority of users who don't use ldap. Indeed there'll be a slight inconsistency between local ABs and ldap after this fix, but we're not making it worse for ldap users, and perhaps also using ldap vs. local ab is more of an either/or thing so ldap users might not even notice the improvement on the local ab side. Furthermore, in support of landing this as-is, the current failure to return expected results for everyday scenarios of average users looks quite substantial to me, as described in my numerous examples and witnessed by recurring duplicates and gs reports.

> At the moment, this still needs completing and landing on trunk, of course.

Aceman, I read comment 65 as an encouragement that this still has a chance of landing for TB24. Would you be able to address the test issue per your comment 64 that prevents this from landing?
Flags: needinfo?(acelists)
(In reply to Thomas D. from comment #66)
> Aceman, I read comment 65 as an encouragement that this still has a chance
> of landing for TB24. Would you be able to address the test issue per your
> comment 64 that prevents this from landing?

I would like to fix the tests, however the whole xpshell test infrastructure is broken on https://tbpl.mozilla.org/?tree=Thunderbird-Trunk and also on my local machine. So I can't currently work on the patch.
Flags: needinfo?(acelists)
(In reply to :aceman from comment #67)
> I would like to fix the tests, however the whole xpshell test infrastructure
> is broken on https://tbpl.mozilla.org/?tree=Thunderbird-Trunk and also on my
> local machine. So I can't currently work on the patch.

Notwithstanding the fruitful cooperation on this bug, looks as if we ultimately end up in a truly hopeless and discouraging bug fixing experience.
After years of waiting to improve this major flaw as reported in many duplicates of bug 558931 and getsatisfaction, the patch is approved, correct and ready to land, and now apparently it doesn't land on the last mile because some test infrastructure is broken. What a shame for Thunderbird.
It's obvious that existing tests with email addresses will fail for this patch as we are expanding the result set without having updated the tests cases accordingly. But we know exactly what we're doing here which is nothing else than replacing "startsWith" with "contains". Surely that can't possibly break anything. So can't we just land this on comm-beta and ignore the tests (given that the whole test environment is currently broken anyway so we can't fix the test cases)?
Flags: needinfo?(mbanner)
(In reply to Thomas D. from comment #69)
> It's obvious that existing tests with email addresses will fail for this
> patch as we are expanding the result set without having updated the tests
> cases accordingly. But we know exactly what we're doing here which is
> nothing else than replacing "startsWith" with "contains". Surely that can't
> possibly break anything. So can't we just land this on comm-beta and ignore
> the tests (given that the whole test environment is currently broken anyway
> so we can't fix the test cases)?

No, broken tests means that other test failures could be ignored/missed, and gives us risk for landing fixes for regressions. It also means if this does happen to cause a regression (or expose something we hadn't seen before), we'd have no way of knowing it passes.

WRT the test env issues, the Linux ones on trunk are due to being on a too old version of python, which should be fixed soon. comm-beta tests still work, and are now in fact all passing.
Flags: needinfo?(mbanner)
(In reply to Mark Banner (:standard8) from comment #70)
> (In reply to Thomas D. from comment #69)
> No, broken tests means that other test failures could be ignored/missed, and
> gives us risk for landing fixes for regressions. It also means if this does
> happen to cause a regression (or expose something we hadn't seen before),
> we'd have no way of knowing it passes.

I find it amazing that we can live happily for many years with dozens of known critical dataloss bugs, but we get scared of regression risks when we change a small, simple and straightforward query from "startsWith" to "contains" which really can't do any unexpected damage except correctly expanding the result set to include missing results as intended. More so as exactly the same queries used in this patch are already working in Address book and Contacts side bar, so you can even check the effect of including more matching results as we do here.

I'd much prefer an entirely theoretical risk of regression (which could easily be fixed by backing this out again) over the stubborn, unending and highly annoying persistance of a useless search algorithm in a basic everyday scenario as crucial as choosing recipients via autocomplete. Another year is an awful lot of time for such an annoyance which keeps coming up in user reports, e.g. most recently again in bug 565465 comment 7:

> Also it would be of very great help if the auto suggest would not only take
> name starts. Example is berger (Rosenberger, Spielberger etc.) I often
> remember just parts of the names and it would be fantstic to get auto suggest
> also e.g. for the company name xyz@basf.com [if we could just type "basf" to]
> show all from basf.com.

> WRT the test env issues, the Linux ones on trunk are due to being on a too
> old version of python, which should be fixed soon. comm-beta tests still
> work, and are now in fact all passing.

Aceman, if comm-beta tests are working, would it be possible for you to write up some tests for the new "contains" matching style and to remove the old ones?
I understand this might still land on beta if it had tests that pass there.
Flags: needinfo?(acelists)
As I said the whole test infrastructure is broken on my local machine too, for unknown reasons yet. So I would be OK if anybody drops in and fixes the failing tests here if his test environment is working.
Flags: needinfo?(acelists)
Duplicate of this bug: 914102
Please, implement this as soon as possible, I see this bug haas been around for 3 years and requires miniscule change, common guys!
standard8, please review the mailnews test changes.
Attachment #785696 - Attachment is obsolete: true
Attachment #803332 - Flags: review?(mbanner)
Comment on attachment 803332 [details] [diff] [review]
patch v5 - updates tests too

I wonder if mconley would be authorized to review the tests too.
Attachment #803332 - Flags: review?(mconley)
Comment on attachment 803332 [details] [diff] [review]
patch v5 - updates tests too

Review of attachment 803332 [details] [diff] [review]:
-----------------------------------------------------------------

feedback=me, but I'm not a mailnews reviewer.

::: mailnews/addrbook/test/unit/test_nsAbAutoCompleteSearch4.js
@@ +126,5 @@
>  
>    print("Checking Initial Searches");
>  
>    function checkSearch(element, index, array) {
> +    print("Checking " + element);

Do we really want additional console spew? We probably shouldn't be printing anything at all..
Attachment #803332 - Flags: review?(mconley) → feedback+
I think in xpcshell nothing is shown if the test passes. If it fails then the output is shown and it is good to see where it failed.
Comment on attachment 803332 [details] [diff] [review]
patch v5 - updates tests too

Review of attachment 803332 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry for the delay, this looks better. I think the print is fine, it does generally help in debugging tests that loop around testing items in arrays.
Attachment #803332 - Flags: review?(mbanner) → review+
Thanks, let's try to push this again :)
Keywords: checkin-needed
https://hg.mozilla.org/comm-central/rev/96ad3b8c67b7
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [approval-comm-beta TB24?]
Target Milestone: --- → Thunderbird 27.0
Blocks: 325458
Hello,
will this EVER been fixed?
To search inside address book across all fields is vital.
This IS FIXED starting at TB27 so it will be in the stable release of TB31.
But this does not touch which fields are being looked into (that is not the point of this bug as filed). You may also be interested in watching bug 558931.
(In reply to 1manfactory from comment #82)
> Hello, will this EVER be fixed?
> To search inside address book across all fields is vital.

That's bug 298438. Constructive input *why* searching *all* fields is vital for your scenarios might be helpful there (not here).
(In reply to Thomas D. from comment #84)
> (In reply to 1manfactory from comment #82)
> > Hello, will this EVER be fixed?
> > To search inside address book across all fields is vital.
> 
> That's bug 298438. Constructive input *why* searching *all* fields is vital
> for your scenarios might be helpful there (not here).

If you can't answer that yourself you are sure wrong here(!)
See Also: → 556490
Depends on: 970456
(In reply to gwelsh from bug 558931 comment 122)
> (In reply to Thomas D. from bug 558931 comment 109)
> > Comment on attachment 8350970 [details] [diff] [review]
> > Patch v3.2
> > as a result of our cooperative efforts on this bug, we're happy to offer you
> > this patch by Suyash as a Christmas present, designed by popular demand, and
> > covering many real-life usecases which currently fail. This is the logical
> > complement of bug 529584 introducing *foo bar* search which has ui-r+ by
> > :mconley. So here, we just split that up into *foo* AND *bar* for more
> > versatile searching and better result sets.

> this is quite an accomplishment, however I now get loads of unwanted
> suggestions for simple two letter shortcuts I always used every day.

Fwiw, and also explained on bug 972690 comment 2, you're making wrong assumptions about how the code worked before this bug 529584, and still mostly does. TB/SM have never had a reliable feature of "two letter shortcuts bringing up a certain contact topmost of the autocomplete results list", neither before nor after bug 529584. Depending on your particular dataset and use patterns, it might *appear* to work like that if your search word is unique enough and the topmost returned contact has a high popularity index (frequency, i.e. often used by user ever before, even long ago).

Please accept that two-letter shortcuts, due to their shortness, can never be unique enough for efficient search (try two letters on google...), UNLESS combined with assisting algorithms like popularityIndex, frecency, or nicknames. E.g., if you have 10 contacts where *any* of the searched fields begins with the two letters you're searching for, all 10 will show up in results (even without the new "contains" logic). Order is currently determined by popularityIndex, then alphabetical somehow. If your favourite contact shows up topmost, it's most likely due to high popularityIndex (combined with uniqueness in your dataset), but NOT because TB/SM knows any connection between your search "shortcut" and the particular contact.

Again, as explained with more detail in Bug 972690 Comment 2:
1) usefulness of popularityIndex is very limited because it doesn't consider how *recently* you've used that contact, and in its current implementation, it always goes up, but never down.
2) TB/SM do NOT have a frecency algorithm yet (only frequency aka popularity index, but not recency): Bug 382415
3) Nicknames currently only work correctly if they are unique across all searched fields of all contacts, or if desired target contact happens to have higher popularityIndex and/or come first alphabetically. So effectively, nickname design is NOT working in TB/SM, because by design, nicknames are STATIC ALIAS names that should reliably return the desired contact ideally on a 1 on 1 basis, regardless of frecency for that contact: Bug 325458 (actually with a high popularityIndex on getsatisfaction and 27 votes).

So for those who want their single-word "2-letter-shortcuts" to find the needle in the haystack, please campaign for bug 325458 and bug 382415 to be fixed, because they will solve your problem (whereas this bug just exposes those problems a bit more, to fix other much bigger problem where expected results are not found at all).

FTR: This is why we introduced *contains* logic to replace *beginsWith* logic:

1) We definitely want to search 2nd+ words *within fields*, e.g. Firstname="Anne Mary", or Organisation = "Barclays Bank" searching for "Mary" or "Bank" MUST succeed.

2) We also want to search *within words* (cf. Bug 558931 Comment 67):

* in many languages and scenarios, technical word boundaries are not identical with semantic word boundaries:
Donaudampfschifffahrtskapitän (correctly spelled German word consisting of 5 nouns - want to search for captain at the end of the word)
Hausbank (nothing wrong with searching for just "bank")
airmozilla.org (you'd certainly want to find that when searching for "Mozilla")
Obermaier, Mittermaier, Untermaier? (valid surnames, but what was his name again? Just search "maier"; there are more: http://de.wikipedia.org/wiki/Meier_%28Familienname%29)

* greatly helps for scenarios where you don't recall the exact wording or spelling of names, company names, etc, or you want search more widely based on common word part in some fields:
Émile, Emile, Èmile, Êmile, or Emilé? (just search for "mil" and you'll find them all)
Wang Shue? Vang Schuh? Fang Shu? (Don't rember the first letter? Just skip it. Search for "ang")
Ergotherapeut, Physiotherapeut? (almost the same... just look for the "therapist"...)
To be clear: I am 100% in support of fixing bug 325458 and bug 382415 asap, because they will be more exposed for existing users after this bug; and I've done my best to push them forward.
Summary: Composition's address autocomplete fails to match domain part of email address (which works in AB quicksearch) - should use ".contains" for matching card fields [autocompletion] → Composition's address autocomplete fails to match domain part of email address (which works in AB quicksearch) - should use ".contains" for matching card fields (*foo bar*) [autocompletion]
See Also: → 984875
Blocks: 1000775
Mentor: bugzilla2007
Mentor: bugzilla2007
TB24 had "foo bar"* search algorithm, so anything not at the beginning of fields could never be found (including intra-field second words, double names, companies in display names, domains etc.). Worse, adding more search words did not narrow down your search, as we were searching for the exact combined string "foo bar" at the beginning of fields. For more search power and less failures, this bug introduces *foo bar* search algorithm, which as a side effect fixes the domain search issue (because domain is contained in the middle of email field).

It's good to relnote this as we have done, but the real searchpower comes when this is combined with 558931 which introduces incremental *multiword* searches: *foo* AND *bar* search algorithm. With that, users can now type anything they remember about a contact regardless of field data structure, and typing more search words will narrow down the result set rapidly and efficiently. I've provided countless examples on bug 558931, e.g. Bug 558931 Comment 16. Find the feature summary in Bug 558931 Comment 109.

I.e. *both* bugs should be listed in release notes (and it's really worth it to list them both), but if you really want to list only one, imo it should be Bug 558931.
Keywords: relnote
Whiteboard: [tb31features]
Whiteboard: [tb31features] → [tb31features][relnote: twin bug 558931]
Depends on: 984875
See Also: 984875
So If I understand this.......you say this 'bug' is "fixed"  Oh Contraire mes amis!  This is backwards
If I type  eg  'ang' which is the 1st 3 letters of my friends name.......I'm now getting all these other choices that I don't want  !!!!!!!!!

Plus now I'm getting addresses in RED...when they are correct ! :-(

This is both from the last release !
PS  I could understand if one was in a huge database of addresses and had to do a blind search....
but in my case, perhaps others, this 'fix' is unwanted to say the least.......I had to revert back to V2.6  and when doing so lost my Lightning and Google Calendars because of the 'incompatibiltiy '  grrr :-(((  and had to stuggle to get the old versions back.........fortunately, my 'data' was still there !
I've been using since Netscape 2.2 and this is a 'disaster' !

A compromise FIX would be if, eg, If I typed in 'ang', that the 'auto' would bring that spelling up as my 1st choice !!!  That would work :-))))))))))

Please advise ! :-)
(In reply to Matt Miller from comment #89)
> So If I understand this.......you say this 'bug' is "fixed"  Oh Contraire
> mes amis!  This is backwards
> If I type  eg  'ang' which is the 1st 3 letters of my friends name.......I'm
> now getting all these other choices that I don't want  !!!!!!!!!

Hi Matt, thank you for your feedback which is appreciated.

A few annotations to put things into perspective:

1) Notwithstanding appreciation of your concern, for many other users and scenarios, after years of cursing at a disfunctional, unreliable, and unpredictable autocomplete search, they are now finally getting all the choices they WANT and rightly expect in autocomplete results, because of autocomplete twin bugs, bug 529584 and bug 558931. For details why this is good, see Bug 558931 Comment 109.

2) It's true that for short single search words (esp. 1 or 2 characters), depending on popularityIndex of found cards, AB data structure etc. some users might see more ("unexpected") results from "contains" match which they haven't seen before. For all users, new powerful *foo* AND *bar* algorithm now allows to narrow down results and find the needle in the haystack much more efficiently than before; however, depending on your personal search preferences and AB data, you might have to adapt your search patterns or use other features of TB which unfortunately still have their own bugs. E.g. suppose you're looking for "Angus Miller": Simply typing "ang mil" will do the trick with an estimated average probability of 95% or more to find just him without any other tricks. The advantage being for all those who also have "Angus Johnson", "Angela Mustermann", "Angelina Joyful", and "Angie Swift" in their contacts, they can start out naturally with typing "Ang" and, if too many results, type anything else they remember as a second search word (e.g. beginning of surname, or part of email address) to narrow down. That's awesome google style search, and wasn't possible before these twin bugs.

3) For those irrated by different result sets with seemingly different order, per comment 91, we're exploring ways of improving the order of autocomplete results in bug 970456. As I explained there, under the assumption that we do NOT want to break popularityIndex which at least somewhat helps the most frequently used contacts to be toplisted in autocomplete results, imo that bug can only satisfy a very small number of scenarios/contacts (if at all), namely those where popularityIndex is either not yet set (virgin AB) or high AND identical with other cards. For most other cases, that bug can't and won't do anything.

4) The real culprit of the surprising behaviour seen by users like Matt (comment 89, comment 90) is not the twin bugs, but age-old design deficiencies of the current result sorting algorithm: current results are first ordered by popularityIndex, a dull and ever-increasing counter of frequency. Write 1000 emails to "Angelina" in 1999 and none everafter, then 500 emails to "Angus Miller" in 2014, and Thunderbird will stubbornly keep pushing your old friend "Angelina" to the top all the time: That's Bug 382415, we need "frequency + recency" algorithm correlated with your personal search input and which result you pick from there, instead of just card-based frequency. Perhaps some ideas of bug 970456 can somehow go into the weighting/scoring of frecency algorithm. Assuming that you've *recently* communicated with "Angus Miller" more frequently than with "Angelina Joyful", and you always pick "Angus Miller" after typing "Ang", TB should automatically adapt to that use pattern just like FF awesome bar successfully does for URLs (I never type more than 2 or 3 letters to find my favourite URLs from thousands in the history).

5) If you're looking for a stable 1:1 shortcut relationship between your search word ("ang") and exactly one target card ("Angus Miller"), what you really want/need to use is TB's nickname feature (the equivalent of FF's keyword feature, NOT tags). Define "ang" explicitly and uniquely (between all cards of all ABs) in Nickname field of that contact. Typing "ang" would then happily toplist "Angus Miller" everafter each time you type "ang", permanently downgrading Angie, Angelina, and all other friends for that search word. Unfortunately, there's Bug 325458, full nickname matches aren't toplisted, which can still cause your unique nickname to fail (again, the twin bugs are innocent...). As a workaround, ensure total uniqueness of your nickname against all relevant search fields of all cards in all ABs by using truly unique nicknames like "ang#", "aaa", "ami1", "a111" etc., you get the idea (characters like # or combinations not usually found in names and emails are especially helpful here).

6) If you're here to say that autocomplete has become slower by magnitudes with the new algorithm, then rest assured we've fixed that problem in Bug 984875 with a 75% performance increase; at the time of writing this comment, it's fixed on trunk, but I believe this hasn't landed yet in release versions where it's still pending. As a caveat against squarely blaming the twin bugs, again, causal connections cannot always be established from coincidence. The fix was all about code which existed prior to the twin bugs, like poor deduplication algorithms, double loops etc. The impact of this bug 529584 on performance hasn't been systematically measured yet; twin bug 558931 came with a measured performance gain of 33% according to aceman.

> Plus now I'm getting addresses in RED...when they are correct ! :-(

Matt, if you get red with TB 31 where you didn't get red before, pls file a new bug with steps to reproduce.
Personally, I find the current design unfortunate where all addresses not found in AB turn out in red font color as if there was something wrong with them. We could explore better visual feedback in a new bug.
Whiteboard: [tb31features][relnote: twin bug 558931] → [tb31features][relnote: twin bug 558931][read comments 88 and 92 before commenting]
Thomas(In reply to Thomas D. from comment #92)
> suppose you're looking for "Angus Miller": Simply typing "ang mil" will do
> the trick with an estimated average probability of 95% or more to find just

Thomas, thanks a lot for these tips. Exactly as TB should work (and now works!) for the rest of us.
After update of Tb 31, Korean address suggestion is not working in Bug 1058491.
See new Bug 1058583, "Address Book Popularity Index needs to age", and a proposed, simple algorithm

(In reply to Thomas D. from comment #92)
> (In reply to Matt Miller from comment #89)
 
> 3) For those irrated by different result sets with seemingly different
> order, per comment 91, we're exploring ways of improving the order of
> autocomplete results in bug 970456. As I explained there, under the
> assumption that we do NOT want to break popularityIndex which at least
> somewhat helps the most frequently used contacts to be toplisted in
> autocomplete results, imo that bug can only satisfy a very small number of
> scenarios/contacts (if at all), namely those where popularityIndex is either
> not yet set (virgin AB) or high AND identical with other cards. For most
> other cases, that bug can't and won't do anything.
You guys who write the code are all 'genius's' :-)  I'm just a poor humble user.....albeit one who has been around: ( I'm 65, and when in HS wrote code as an IBM outreach program for HS, for an IBM 360 in Machine Language) Anyway.....If there is anyway you can make it so that if one knows eg the 1st 3 letters of a persons last name eg MIL  for Miller, that the Millers are going to appear 1st in the list!  If this could be done, then I'd be smiling ! ! !  As it is right now......I reverted to V24.6 and I don't know if I'll upgrade again without a compelling reason?!
PS  I just realized, that, In my 1st example:   I typed in 'ang' and ' John Caserta' came up as my 1st choice, because, his email address has 'angel' in it ;-) ;-(  This doesn't 'work' for me !  eg showing results because the software is also querying the address :-(
I am having the same problem that Matt is describing.  I apologize, I have tried to read the comments but a lot of it is over my head as I am not a Techie.
Ever since update 31 creating an e-mail has become so frustrating...it should not be so difficult.
My for instance is:  I am trying to send an e-mail to Rita Schroeder and I get the following results (and I do understand why - all 3 have rita in it - but it's driving me nuts)
Gillian Smith <britannia@>
Rita Schroeder <224rita@>
Mary Margarita <marymargarita@>
The only way to finally get it to fill in the address for Rita - I have to type "Rita Sc"
One would think that if I had gotten as far as Rita and a space bar then it would fill in the correct result.  But it seems to be keying in come the e-mail address vs. the Name of the person.
(In reply to Beth from comment #97)
> I am having the same problem that Matt is describing.  I apologize, I have
> tried to read the comments but a lot of it is over my head as I am not a
> Techie.
> Ever since update 31 creating an e-mail has become so frustrating...it
> should not be so difficult.
> My for instance is:  I am trying to send an e-mail to Rita Schroeder and I
> get the following results (and I do understand why - all 3 have rita in it -
> but it's driving me nuts)
> Gillian Smith <britannia@>
> Rita Schroeder <224rita@>
> Mary Margarita <marymargarita@>
> The only way to finally get it to fill in the address for Rita - I have to
> type "Rita Sc"
> One would think that if I had gotten as far as Rita and a space bar then it
> would fill in the correct result.  But it seems to be keying in come the
> e-mail address vs. the Name of the person.

(meant to say keying in from the e-mail)
So, if I understand it correctly... the way auto-complete works now is intentional, not a bug??? Like some others I find it thoroughly and utterly frustrating and irritating.

Using nicknames doesn't work because most of the ones I've set are short, and all Thunderbird will do is look for address book entries with strings that match the nicknames.

Also... all my messages are BCd to one specific address at my own domain. I now find that no matter what address I try to put in the "to" or "cc" field, Thunderbird will always try to enter another instance of my regular BC instead... so if I'm not careful I end up sending messages to myself and myself only.

After a lifetime of using Thunderbird and its predecessors (I've been online since the 1990s) I am now seriously considering looking for an alternative - that's how strongly I feel about this so-called "enhancement".
Okay this is great now! We didn't expect this sort of responses from users when we
were working on bringing these changes in Thunderbird.

Actually believe it or not, the issue is not with the way it works now. This is a desired
behavior and if at all people will try to read through the comments above, they'll find
that most of the powerful searches in the world behave in the similar fashion.
The issue is, people found a way to workaround for the flaw in autocomplete and related
searching ways in Thunderbird so far and *now* those workarounds are failing.

So, yes, I accept this is a change that maybe affecting your addressbook. We are trying to make
it flawless to make it even better but things take time. So everyone will take time to adjust
to the new search behavior concerned here. Bear with us! 

And, apologies if anyone finds my comment somewhat disappointing. It isn't in any manner
written with an intention of that sort. Its just to convey what I have, as a developer, on my mind.
We are working on it for the users, and we are quite excited to see how people like it and
appreciate it. If you find issues, file a bug, let us know. Don't just come up saying you are going
to switch!

Thanks.
Well, reporting a bug is exactly what I came here for (only ever done it once before, many years ago)... and the first thing I find is that what I thought a bug, and which has been driving me insane, is in fact expected behaviour.

It's not working. I type the letter D and the first address it shows is one which hasn't got a single D in it. I type the letter U and the first three addresses that come up don't have a single U in them. How can that be? If I type any letter that's in my default BC address (u and d aren't) it comes up with my default BC address. 

I'm not a developer. I'm just a user - probably a power user. And I have been immensely loyal to Mozilla over the years. At the moment I just feel let down. How can this bugginess (see last paragraphy) possibly be expected behaviour? 

Until a week ago it would never ever have occurred to me to use anything but Thunderbird... but now I'm just tearing my hair out. I know that I could probably solve the problem by going back to an earlier version, but I'm scared that this would break my whole mail set-up (which has become quite complex over the years)

I know this is not what you want to hear, and I'm sorry to be pouring cold water over something that you worked ****... but it's just not working. It's broken. Sorry.
Dear Angelika et al
        I hate to say it under these circumstances, but I'm glad I'm not alone ;-) ;-(
1st Angelika
             I downloaded the prior version V 24.6, and it overwrote the new one with NO Problem !
 :-)))
One thing that wasn't so smooth was for my Google Calendar / Lightning add ons, I had to dig a little to find the older compatible versions !
   I also shut off 'auto-update' ! 

Meanwhile to amplify myself and now Angelika's indisputable logic........... to type in a 'D' and not come up with all the addresses that start with the letter 'D', is 'non functional' to say the very least !
:-((((((((((((((((((
Since only people complaining are usually visible, I want to strongly support recent changes and I am one of the large, but rather quiet, group of users, who are happy with the changes introduced.

Finally, it works as it should and is powerful enough to find all the email addresses I want to actually send emails to!
And your "D" problem stems from the fact that in the past somebody addressed email to that address and included D in the receiver's (that is probably you) name.

I have seen this popping up and yes, it could be handled better, but all the advantages definitely win over any other smaller nuisances such as this.
So the issues that you are having with 'D' and 'U' are the ones we would have tried our
best to help you with. But your responses hit us as if this is just a blunder :)
Firstly, if your addressbook is immensely large you may be hitting performance issues
with single letter searches (this issue is being addressed). Secondly, that's highly
unlikely that if you don't have a 'D' or a 'U' anywhere in the addressbook contact card
and it comes up on typing anything like that. Did you check the contact card and confirmed
that *none* of the fields have a 'D' in them?

Thanks.
The above was in response to Angelika's concerns and we would really like to know about the issues
the user is facing and fix them.

(In reply to Daniel from comment #103)
> Since only people complaining are usually visible, I want to strongly
> support recent changes and I am one of the large, but rather quiet, group of
> users, who are happy with the changes introduced.
Thanks Daniel.
It's absolutely vital in an important, sensitive and emotional matter like this that we listen to each other: Developers must listen to users - but users must also listen to developers!

*****************************************************************************************************
Please before discussing this any further, make sure to follow this instruction from the whiteboard which is seen on top of this bug:

[Important: Read comment 88 and comment 92 before commenting!]

That will also point you to Bug 558931 Comment 109 which explains the motivation for these changes in a nutshell, and I've added countless other examples to show why this is necessary and helpful both on Bug 558931 and here (find them in my comments).
******************************************************************************************************

We never said this is the final stage where we want it to be - it's not, but mostly because of age-old bugs which were there long before this change, but they were hidden before (so possibly users never experienced them) and they are now more exposed (as explained in comment 92). Which is good, as it creates a bigger stimulus to finally fix them, in spite of the limited volunteer manpower we're now working with since Mozilla mostly withdrew their funding for the Thunderbird project. But let's make sure we're placing the blame correctly between old bugs and recent changes.

What we did say is that this is a strategic change which will fix major shortcomings and failures of the existing algorithm *in the long run* because we now offer a much more efficient and powerful search. And as seen can be seen from 13 duplicate reports on the autocomplete twin bugs, a lot of users actually complained about those unbelievable search failures of the old autocomplete algorithm. 

The point being, as with anything "new", this will require a learning curve from users, too, to understand and benefit from the new way of searching. I have provided detailed information and tips how to do that (and work around old problems) in my comment 92.

Here's a story to understand the motivation of what we're doing here, by analogy:

Assume there's an old business which is doing everything on paper without using computers. Everyone is used to that so somehow it seems to work alright, and everyone somehow finds their way between endless piles of papers and claims to know exactly which pile has which information. Only that the rest of the world has changed to computers and works a lot more efficiently, finding all the information a lot faster at their fingertips. One day there's this new visionary boss coming in and starting that unheard-of change to introduce *computers* into our paper-run business. WOW, listen to the screams of employees: "I've never used a computer before!", "We have a photocopier, what do I need a scanner for?", "I know exactly where all my papers are, why should I need a computer to handle my data?", "We've always worked this way, and it worked, so why change?"
And worse, the whole company is actually so rusty that they don't even have enough plugs or suitable desks to run those new computers nicely. Is that a good argument against introducing computers to get started? Or isn't it a good argument to address those other problems, fix plugs and work places, and educate employees about the new way of doing things while being honest about the problems of transition? Well yes, change and transitions are always hard (not only in world politics), but they are inevitable if we want to move on towards those big visions of a better future for everyone...

Finally (as mentioned before), let's also try to look beyond our own limited perspectives:
What works for users of English language, might not work for users of other languages like German, because word structures are different. Complex nouns are usually separate words in English, but single words in German, so the physical word boundaries don't necessarily coincide with semantic word boundaries:
Evening star - Abendstern (combined from Abend + Stern)
Waste disposal plan - Abfallwirtschaftsplan (combined from Abfall + Wirtschaft + Plan)
There's absolutely no reason why searching for any of "Abfall", "Wirtschaft", or "Plan" should fail...
And yes, the same applies to names, too, say dozens of fancy sirnames having "Miller" in them:
http://de.wikipedia.org/wiki/M%C3%BCller_%28Familienname%29
Winkelmüller (Winkel + Müller)
Waidmüller (Waid + Müller)
Riedmüller (Ried + Müller)
Bachmüller, Burgsmüller, Hammermüller, Hasenmüller, Holzmüller, Neumüller, Obermüller, Oismüller, Riedmüller, Stegmüller, Teichmüller, Windmüller, Wolfmüller
So what if I only remember his name was something "...müller"?
Wow, just search for "müller" and find them all, then add a detail like "Win" for "Winkel" to narrow down. Your language doesn't have this problem? Lucky you are..., but it will still help you finding those strange names of your international friends and business partners where you don't remember the exact spelling... Awesome! :)

And even in English, you'll still have the same issue, e.g. with email addresses and domain names:
Foxy <johnmiller1975@airmozillamessaging.com>
Your mileage may vary, but personally I'm truly excited knowing that whatever I happen to remember about that contact will now let me find the person:
Foxy | john | miller | 1975 | air | mozilla | messaging -> all of these succeed for finding Foxy! :)
And if Foxy has another address on gmail,
Foxy <jmxxxx@gmail.com>,
finding the needle in the haystack has never easier than now:
Fox moz -> found Foxy's mozilla address!
Fox gmail -> found Foxy's gmail address!
That is just AWESOME! :)
Whiteboard: [tb31features][relnote: twin bug 558931][read comments 88 and 92 before commenting] → [Important: Read comments 88 and 92 before commenting!][relnote: twin bug 558931][tb31features]
(In reply to Matt Miller from comment #96)
> 1st 3 letters of a persons last name eg MIL  for Miller, that the Millers
> are going to appear 1st in the list!  If this could be done, then I'd be
> smiling ! ! !

Matt, looks like you haven't read my comment 92 before making your comment 96.
See comment 92, 3) -> bug 970456

> PS  I just realized, that, In my 1st example:   I typed in 'ang' and ' John
> Caserta' came up as my 1st choice, because, his email address has 'angel' in
> it ;-) ;-(  This doesn't 'work' for me !  eg showing results because the
> software is also querying the address :-(

We undoubtedly have to search addresses when the whole widget is about adding addresses! :)
In fact, for email addresses like johnangelocaserta@worlddisney.com, it's *especially* useful to search for substrings (angelo, caserta, or disney), because semantic word boundaries don't usually coincide with physical word boundaries! -> comment 92, 1) -> Bug 558931 Comment 109; comment 107.
Dear Thomas et al,
                 I read 92! I cannot deny that others have been complaining, and now have a functionality that they have been craving!  Be that as it may, for myself though, I don't understand why an 'order' of functionality cannot be implemented to have 'exact partial matches' come up 1st ! That's the way it was until this version!  To me, and now some others, that is a must, or you'll risk loosing us!  I have many clients in Outlook, (and many in Thunderbird) ( I'm a small time PC guru), and it just might be my time to switch?  I again Thank You for your wonderful efforts !  PS Here's a thought:  I work in another Program that wants 'exact partial matches' for auto complete! But, there is an option for those that want all 'variations', to use '*' before and after an entry!
(In reply to Matt Miller from comment #109)
> Dear Thomas et al,
>                  I read 92! I cannot deny that others have been complaining,
> and now have a functionality that they have been craving!  Be that as it
> may, for myself though, I don't understand why an 'order' of functionality
> cannot be implemented to have 'exact partial matches' come up 1st !

'Exact partial matches' isn't a good term as all of our matches are exact partial matches. You probably mean "field beginsWith" or "word in field beginsWith" matches. To prevent reintroducing the bugs we've fixed here, we'd need at least the wordwise option, which loses a lot of legitimate results, is tricky to implement, and possible worse in performance than what we have now.

> That's the way it was until this version!

Well, as there only were "beginsWith" matches, it's obvious one of them comes first. But the primary sorting order of results was (and still is) defined by nothing else except popularityIndex, i.e. how often you have ever written to that address or card (which is a poor algorithm, as I explained, and bug filed). So before and after this change, we're NOT just autocompleting what you type in an alphabetical way; and both before and after this change, we've always autocompleted against fields that you do NOT see in the results list (first/last/nickname).

> To me, and now some others, that is a
> must, or you'll risk loosing us!  I have many clients in Outlook, (and many
> in Thunderbird) ( I'm a small time PC guru), and it just might be my time to
> switch?

I don't like the tone, and it's not a threat. This is OSS, you haven't paid for our product, so no obligations, and you're free to leave at any time and enjoy the bugs of competitors. We'll still try our best to improve the software as good as we can under reduced volunteer manpower circumstances.

> I again Thank You for your wonderful efforts !  PS Here's a
> thought:  I work in another Program that wants 'exact partial matches' for
> auto complete! But, there is an option for those that want all 'variations',
> to use '*' before and after an entry!

Such options are certainly worth consideration; however, they are hard to implement and always come with a big and permanent cost in terms of maintenance. I'm actually in favour of exposing the search template so that users can tweak it to their liking using Config Editor in Advanced Options, as is the case for contacts side bar and AB quicksearch:

mail.addr_book.quicksearchquery.format;?(or(NickName,c,@V)(PrimaryEmail,c,@V)(DisplayName,c,@V)(FirstName,c,@V)(LastName,c,@V))

We'd have to completely rewrite big parts of the current algorithm to use and expose that. However, all of these things need time and we can't do them all at once. Plus it can easily impact performance again and we'll get complaints that autocomplete is now too slow...
(In reply to Suyash Agarwal (:sshagarwal) from comment #106)
> The above was in response to Angelika's concerns and we would really like to
> know about the issues
> the user is facing and fix them.
> 

OK, I've got to the bottom of the "D" issue, and have sorted it - the issue was at my end, and I apologise for wasting people's time.

As for the "U" issue... again, I need to apologise, because there IS a U in all of those addresses... it's just that it's in the bit we don't tend to consciously notice. The bit that is at the end of the vast majority of addresses in my address book - .uk!

But this actually shows another flaw in the system... if you're a UK user (or someone with lots of contacts in the UK) then typing "U" will NOT bring up people with the letter U in their name or email address, it will bring up your most frequently-used contacts in the UK. Wouldn't it perhaps make sense to disregard the TLD for the popularity count?
(In reply to Angelika from comment #111)
> OK, I've got to the bottom of the "D" issue, and have sorted it - the issue
> was at my end, and I apologise for wasting people's time.

Thanks. I am glad we were able to find the root cause of the issue you were facing.

> But this actually shows another flaw in the system... if you're a UK user
> (or someone with lots of contacts in the UK) then typing "U" will NOT bring
> up people with the letter U in their name or email address, it will bring up
> your most frequently-used contacts in the UK. Wouldn't it perhaps make sense
> to disregard the TLD for the popularity count?

Ya! This is interesting. Thanks for pointing this out. But instead of lowering its
priority, I think we should just strip that completely isn't it?
Like for all of them, .com, .org etc. But maybe, in case there are multiple contacts
and I'd like to separate them based on location (.uk, .in etc.) so we may need them
so your prioritizing idea works.

Let's see what we need to do.
Flags: needinfo?(acelists)
(In reply to Thomas D. from comment #110)
> (In reply to Matt Miller from comment #109)
> > Dear Thomas et al,
> >                  I read 92! I cannot deny that others have been complaining,
> > and now have a functionality that they have been craving!  Be that as it
> > may, for myself though, I don't understand why an 'order' of functionality
> > cannot be implemented to have 'exact partial matches' come up 1st !
> 
> 'Exact partial matches' isn't a good term as all of our matches are exact
> partial matches. You probably mean "field beginsWith" or "word in field
> beginsWith" matches. To prevent reintroducing the bugs we've fixed here,
> we'd need at least the wordwise option, which loses a lot of legitimate
> results, is tricky to implement, and possible worse in performance than what
> we have now.
> 
> > That's the way it was until this version!
> 
> Well, as there only were "beginsWith" matches, it's obvious one of them
> comes first. But the primary sorting order of results was (and still is)
> defined by nothing else except popularityIndex, i.e. how often you have ever
> written to that address or card (which is a poor algorithm, as I explained,
> and bug filed). So before and after this change, we're NOT just
> autocompleting what you type in an alphabetical way; and both before and
> after this change, we've always autocompleted against fields that you do NOT
> see in the results list (first/last/nickname).
> 
> > To me, and now some others, that is a
> > must, or you'll risk loosing us!  I have many clients in Outlook, (and many
> > in Thunderbird) ( I'm a small time PC guru), and it just might be my time to
> > switch?
> 
> I don't like the tone, and it's not a threat. This is OSS, you haven't paid
> for our product, so no obligations, and you're free to leave at any time and
> enjoy the bugs of competitors. We'll still try our best to improve the
> software as good as we can under reduced volunteer manpower circumstances.
> 
> > I again Thank You for your wonderful efforts !  PS Here's a
> > thought:  I work in another Program that wants 'exact partial matches' for
> > auto complete! But, there is an option for those that want all 'variations',
> > to use '*' before and after an entry!
> 
> Such options are certainly worth consideration; however, they are hard to
> implement and always come with a big and permanent cost in terms of
> maintenance. I'm actually in favour of exposing the search template so that
> users can tweak it to their liking using Config Editor in Advanced Options,
> as is the case for contacts side bar and AB quicksearch:
> 
> mail.addr_book.quicksearchquery.format;?(or(NickName,c,@V)(PrimaryEmail,c,
> @V)(DisplayName,c,@V)(FirstName,c,@V)(LastName,c,@V))
> 
> We'd have to completely rewrite big parts of the current algorithm to use
> and expose that. However, all of these things need time and we can't do them
> all at once. Plus it can easily impact performance again and we'll get
> complaints that autocomplete is now too slow...

Dear Thomas et al
    Well to repeat..
          I'm totally in awe of you and your group for this FREE Product again, going back to Netscape 2.2!
My 'Tone' ?  
       Well you've decided to implement a change to me ( and I don't think you thought this through to those who are, as Daniel said, 'silient') that's unusable!  To repeat I've reverted to V 24.6   I anticipate that my clients that I turned on to TB will be calling me soon enough ! :-(
Those that wanted the increased functionality of Outlook might see me joining them soon enough to my chagrin!  Although  I just fired up Outlook 2007 up, and its 'way' to heavy' for my Atom 1.8 Dual Core Netbook that I'm typing on and does 95% of my work!  And they don't make it 'friendly' to convert a CSV to their Contacts  :-(((((   So I guess I'm not leaving V 24 anytime soon ;-)


BUT to repeat again, if you can impliment a heirarchy , that would put 'field begins with' 1st...then hey, then perhaps thats the 'solution', for me at least ?! :-)
(In reply to Thomas D. from comment #110)
> (In reply to Matt Miller from comment #109)
> > Dear Thomas et al,
> >                  I read 92! I cannot deny that others have been complaining,
> > and now have a functionality that they have been craving!  Be that as it
> > may, for myself though, I don't understand why an 'order' of functionality
> > cannot be implemented to have 'exact partial matches' come up 1st !
> 
> 'Exact partial matches' isn't a good term as all of our matches are exact
> partial matches. You probably mean "field beginsWith" or "word in field
> beginsWith" matches. To prevent reintroducing the bugs we've fixed here,
> we'd need at least the wordwise option, which loses a lot of legitimate
> results, is tricky to implement, and possible worse in performance than what
> we have now.
> 
> > That's the way it was until this version!
> 
> Well, as there only were "beginsWith" matches, it's obvious one of them
> comes first. But the primary sorting order of results was (and still is)
> defined by nothing else except popularityIndex, i.e. how often you have ever
> written to that address or card (which is a poor algorithm, as I explained,
> and bug filed). So before and after this change, we're NOT just
> autocompleting what you type in an alphabetical way; and both before and
> after this change, we've always autocompleted against fields that you do NOT
> see in the results list (first/last/nickname).
> 
> > To me, and now some others, that is a
> > must, or you'll risk loosing us!  I have many clients in Outlook, (and many
> > in Thunderbird) ( I'm a small time PC guru), and it just might be my time to
> > switch?
> 
> I don't like the tone, and it's not a threat. This is OSS, you haven't paid
> for our product, so no obligations, and you're free to leave at any time and
> enjoy the bugs of competitors. We'll still try our best to improve the
> software as good as we can under reduced volunteer manpower circumstances.
> 
> > I again Thank You for your wonderful efforts !  PS Here's a
> > thought:  I work in another Program that wants 'exact partial matches' for
> > auto complete! But, there is an option for those that want all 'variations',
> > to use '*' before and after an entry!
> 
> Such options are certainly worth consideration; however, they are hard to
> implement and always come with a big and permanent cost in terms of
> maintenance. I'm actually in favour of exposing the search template so that
> users can tweak it to their liking using Config Editor in Advanced Options,
> as is the case for contacts side bar and AB quicksearch:
> 
> mail.addr_book.quicksearchquery.format;?(or(NickName,c,@V)(PrimaryEmail,c,
> @V)(DisplayName,c,@V)(FirstName,c,@V)(LastName,c,@V))
> 
> We'd have to completely rewrite big parts of the current algorithm to use
> and expose that. However, all of these things need time and we can't do them
> all at once. Plus it can easily impact performance again and we'll get
> complaints that autocomplete is now too slow...

Dear Thomas et al
    Well to repeat..
          I'm totally in awe of you and your group for this FREE Product again, going back to Netscape 2.2!
My 'Tone' ?  
       Well you've decided to implement a change to me ( and I don't think you thought this through to those who are, as Daniel said, 'silient') that's unusable!  To repeat I've reverted to V 24.6   I anticipate that my clients that I turned on to TB will be calling me soon enough ! :-(
Those that wanted the increased functionality of Outlook might see me joining them soon enough to my chagrin!  Although  I just fired up Outlook 2007 up, and its 'way' to heavy' for my Atom 1.8 Dual Core Netbook that I'm typing on and does 95% of my work!  And they don't make it 'friendly' to convert a CSV to their Contacts  :-(((((   So I guess I'm not leaving V 24 anytime soon ;-)


BUT to repeat again, if you can impliment a heirarchy , that would put 'field begins with' 1st...then hey, then perhaps thats the 'solution', for me at least ?! :-)
PS  In looking at Outlook last night, there is a 'check box' for a search in ones Contacts/Address Book 1. Name Only
2. More Columns
(In reply to Matt Miller from comment #114)
> BUT to repeat again, if you can impliment a heirarchy , that would put
> 'field begins with' 1st...then hey, then perhaps thats the 'solution', for
> me at least ?! :-)

Seems to me that is exactly what bug 970456 is about.
Flags: needinfo?(acelists)
> Foxy <johnmiller1975@airmozillamessaging.com>
> Your mileage may vary, but personally I'm truly excited knowing that
> whatever I happen to remember about that contact will now let me find the
> person:
> Foxy | john | miller | 1975 | air | mozilla | messaging -> all of these
> succeed for finding Foxy! :)
> And if Foxy has another address on gmail,
> Foxy <jmxxxx@gmail.com>,
> finding the needle in the haystack has never easier than now:
> Fox moz -> found Foxy's mozilla address!
> Fox gmail -> found Foxy's gmail address!
> That is just AWESOME! :)

Yep, it's great to have such a versatile search facility... but search and auto-complete are two different things. Why can't you keep them separate - i.e., just have this enhanced search facility in the search box in the address book while returning auto-complete to the way it was? This would enable people to find Foxy easily, without inconveniencing those of us who just want to be able to type the letter K into their "to" field and go straight to Keith or Kevin without having to wade through reams of addresses all ending in .uk.

I think that keeping search and auto-complete separate would probably keep everybody happy.
I see all the complaints just as usability enhancements for the future versions (there should be a small quick release to fix these problems).

I am thinking, maybe some of the functionality could be included in about:config / options, so people can set their preferred way, e.g.:
1) include domains such as .uk for searching
2) start autocomplete after [3rd] letter

etc.
(In reply to Suyash Agarwal (:sshagarwal) from comment #112)
> > But this actually shows another flaw in the system... if you're a UK user
> > (or someone with lots of contacts in the UK) then typing "U" will NOT bring
> > up people with the letter U in their name or email address, it will bring up
> > your most frequently-used contacts in the UK. Wouldn't it perhaps make sense
> > to disregard the TLD for the popularity count?
> 
> Ya! This is interesting. Thanks for pointing this out. But instead of
> lowering its
> priority, I think we should just strip that completely isn't it?
> Like for all of them, .com, .org etc. But maybe, in case there are multiple
> contacts
> and I'd like to separate them based on location (.uk, .in etc.) so we may
> need them
> so your prioritizing idea works.

Stripping last domain part is an interesting idea. Please make a new bug for it :) But it probably needs to be done in the C++ code of AB search engine.
I have TB upgraded to v31.0 and I can only say, that autocomplete mechanism was broken... 
Please tell me - should I open new ticket for it?

Please add to your contacts two emails:
  - ABC <abc@xyz.com>
  - XYZ <info@xyz.com>

Try to write new email and type "xyz" in "To:" or "CC:" field.
Which email should be autocompleted as first?

Actual result:
  - ABC <abc@xyz.com> suggested as first

Expected result:
  - XYZ <info@xyz.com> suggested as first, because humans are writing names more often than usernames or domains

This is real issue for me, because behaviour of autocompleter was not really fixed, but dramatically changed. I'm sending emails to wrong persons now, and to avoid that I must double-check recipients... it's very annoying...
(In reply to :aceman from comment #119)
> (In reply to Suyash Agarwal (:sshagarwal) from comment #112)
> > > But this actually shows another flaw in the system... if you're a UK user
> > > (or someone with lots of contacts in the UK) then typing "U" will NOT bring
> > > up people with the letter U in their name or email address, it will bring up
> > > your most frequently-used contacts in the UK. Wouldn't it perhaps make sense
> > > to disregard the TLD for the popularity count?
> > 
> > Ya! This is interesting. Thanks for pointing this out. But instead of
> > lowering its
> > priority, I think we should just strip that completely isn't it?
> > Like for all of them, .com, .org etc. But maybe, in case there are multiple
> > contacts
> > and I'd like to separate them based on location (.uk, .in etc.) so we may
> > need them
> > so your prioritizing idea works.
> 
> Stripping last domain part is an interesting idea. Please make a new bug for
> it :) But it probably needs to be done in the C++ code of AB search engine.

1) I beg to disagree. Stripping the last domain part is an idea which starts to break all the powerful gains made by this bug. Some want .uk ignored. Others want .org and .com ignored. Oh, I've got so many gmail friends, can't we ignore gmail.com. Back to square one of this bug, domains not searched. Where do we stop?

2) More importantly, such desires imho are still based on a misunderstanding of the current algorithm. Let's be clear (in appreciation of problems currently faced and described by users on this bug):
Autocomplete is currently severely handicapped and especially for one-letter searches, the UX isn't good. However, blaming this bug and gradually or optionally reverting this means barking at the wrong tree. As I explained before and in detail in comment 92 (and I'd really appreciate if EVERYONE, users and developers alike would intensively familiarize themselves with that before discussing further), this bug does indeed increase the number of results in some cases but the real problem is never the number of results but their prioritization (aka ordering). Let me illustrate:

3) Users are somewhat understandably complaining that searching for "u" returns all their .uk addresses AND that stops them from finding their favorite friend "Umberto" which always came first in TB24. Iow, there would be no (or much less of a) problem if "Umberto" would still (again) be returned first, and all the .uk addresses after that, right? But why are .uk addresses toplisted for some users above their friend "Umberto"? It's because the current sorting algorithm (like the old algorithm) still has dull "popularityIndex" as the primary sorting index. So .uk can only come first if they actually have a higher popularity index than "Umberto". If "Umberto" had a higher popularity index, it would still come first, even with new algorithm. Now the point is, we have never changed the sorting algorithm here, we're just expanding the result set for some edge case cases like single-letter searches (we're also radically reducing the result set as soon as you enter a second word). So if sorting or prioritizing doesn't work now, it means it was broken before (NEVER by this bug). So instead of rushing into breaking what we gained here, I strongly recommend that we fix those old bugs first and then take it from there. I believe 99% of user complaints will be gone after that, and everyone will enjoy (more than) the traditional precision for finding your favorites AND the new XXL searchpower we provide here.

4) What is needed for "u" to always reliably return my particular friend "Umberto"?
- For a 100% stable 1:1 relationship between search word and result, existing feature of manually defined "nickname" is needed, which is currently largely broken (unless you define 100% unique nickname not contained in any other AB data, e.g. "uuu" or "u#"): So we must fix Bug 325458.
- For an automatical, dynamic relationship to the same/similar effect, dull popularityIndex must be replaced by smart "frecency" algorithm, which is also aware of what user typed and which result he picked from there. Iow, if after typing "u", user picks "Umberto" a couple of times (frequently AND recently), then TB should learn that pattern and automatically start to toplist "Umberto" (similar concept as in FF URL bar where it works like a charme). So we must fix Bug 382415.

5) Further thoughts and facts:
- TB24/TB31 do NOT sort autocomplete results alphabetically, but first sort is popularityIndex and only thereafter, in case of equal popularity, alphabetical is used.
- So if "u" really returned "Umberto" in TB24, it's because "Umberto" has highest popularityIndex. For all other cases, if you have any other person like "Udo" starting with "u" and more popular than "Umberto", "Udo" wins.
- Even if "Umberto" wins now, over time, if you write to "Udo" more often than "Umberto" (by absolute everlasting counts), "Udo" can still win over "Umberto" (so it's NOT a stable relationship).
- For a lot of scenarios where you have more than one person starting with "u", even the old algorithm is thus pretty much useless because it's NOT based on frequency AND recency of the usage of that contact. Iow, it's not stable and there's a high chance (in the OLD algorithm) that you might never see your desired results. Iow, single-letter searchwords can obviously fail miserably in the *old* algorithm. 
- For users with bigger address books, the *old* algorithm is a complete UX nightmare because they might *never* see their desired results toplisted. Say that company having 30 clients whose name starts with "u". Hoping for a single-letter search like "u" to reliably return only one result (regardless if contains or beginsWith search) is actually an very high and rather unrealistic expectation for most real-life ABs as soon as you have more than a handful addresses, UNLESS you have some way of defining stable or dynamic 1:1 relationships between a particular searchword and the expected single result (see above in this comment for the two bugs which need fixing).

6) Please do not underestimate the design difficulties, the performance implications and the long-run code maintenance costs of offering any optional behaviours for this part of the UI. It's a big burden and it will be really hard to get it right.
*************************************************************************************
7) In view of comment 121 and the needlessly circular nature of this discussion:
Everyone who feels called to propose so-called "simple" solutions to the UX problems experienced in current autocomplete please explain first why you think the bugs listed in comment 92, especially Bug 382415 and Bug 325458, will NOT solve your problem, before making proposals that are ignoring the true nature of the current algorithm, are difficult to get right in terms of UX design and behaviour, and come with a high maintenance burden!
*************************************************************************************
(In reply to Thomas D. from comment #121)
> (In reply to :aceman from comment #119)
> > (In reply to Suyash Agarwal (:sshagarwal) from comment #112)
> > > > But this actually shows another flaw in the system... if you're a UK user
> > > > (or someone with lots of contacts in the UK) then typing "U" will NOT bring
> > > > up people with the letter U in their name or email address, it will bring up
> > > > your most frequently-used contacts in the UK. Wouldn't it perhaps make sense
> > > > to disregard the TLD for the popularity count?
> > > 
> > > Ya! This is interesting. Thanks for pointing this out. But instead of
> > > lowering its
> > > priority, I think we should just strip that completely isn't it?
> > > Like for all of them, .com, .org etc. But maybe, in case there are multiple
> > > contacts
> > > and I'd like to separate them based on location (.uk, .in etc.) so we may
> > > need them
> > > so your prioritizing idea works.
> > 
> > Stripping last domain part is an interesting idea. Please make a new bug for
> > it :) But it probably needs to be done in the C++ code of AB search engine.
> 
> 1) I beg to disagree. Stripping the last domain part is an idea which starts
> to break all the powerful gains made by this bug. Some want .uk ignored.
> Others want .org and .com ignored. Oh, I've got so many gmail friends, can't
> we ignore gmail.com. Back to square one of this bug, domains not searched.
> Where do we stop?

Less philosophically, removing whichever top level domain or domain for whichever locale from being searched for autocompletion will seriously reduce the search power of current autocomplete algorithm and it's based on very weak assumptions for which we have no statistical data at all.

- Even for a small private address book in the UK, who says most addresses are always .uk? Perhaps it's gmail.com instead...
- For both private and enterprise ABs, who says users don't want to search for TLDs? Searching for TLDs can be a highly valuable use case (and again, I've shown that before and can others please refer to such analysis when they suggest otherwise):
* "Jo uk" can easily find my friend "Joanne" on her .uk email address.
* "Jo gm" might efficiently find my same friend "Joanne" on her .gmail.com email address, or my other friend "John" on his .gmail address.
* "Jo .com" might efficiently find my same friend "Joanne Miller" on her "joanne@millersblog.com" address. (iow, TLDs can be excellent and easy for distinguishing several email addresses of one contact).
* "Moz .uk" can easily find all Mozilla employees in .uk - wow, awesome!
etc. etc. the usecases are unlimited...

Finally, can I ask all those one-letter search word fans perhaps to just try two or three letters, and type faster which will skip the one-letter search, and perhaps just add a space and two more unique letters... BANG - "jo gm" or "jo mi gm" might easily return just a SINGLE matching address (john.miller@gmail.com) from your entire 1000 entries AB...
Oh, and if you just want plain alphabetical lookup, consider just using this existing feature:

F9 to show contacts side bar in composition (a miniature AB), then enter your favourite one-letter search-word "u", and get an alphabetical results list sorted by NAME (don't get confused if there's no name specified on the card, it will show email address instead of name, so the first section might be alphabetically sorted by email address instead)...
As a continuation of comment120 I must say, that I have getting more emails which were not addressed to me, but in the case of this fix some other users (using TB31) added accidentally my email to the recipients list. I think that my friends, who made this mistake, are "happy" same as me, Matt from comment96, and others. 

It is not a hate-comment about bad implementation of the new feature (which is very powerful), but about some sort of "backward incompatibility" in UX.  I have only 5 contacts in my address book (yes, exactly 5), and new alghoritm is not working for me, as mentioned in comment120...
Hello 
I'm not sure I understood everything (I do not speak English and I use google translation:-()
I find it sad that you imposed this auto completion on domain names.
And I'm not the only person to think so.
Why not an option for those who want it?
Indeed, a search on "my" will give all the gmail / hotmail addresses !!!
Imagine a book with 100 addresses gmail / hotmail (or more)!
j2m06


*-----------------------------------------*

Bonjour (hello) 


Je ne suis pas sur d'avoir tout compris (je ne parle pas anglais et j'utilise google translation :-(  )
Je trouve désolant que vous imposiez cette auto complétion  sur les noms de domaine .
Et je ne suis pas le seul utilisateur à le penser .
Pourquoi pas une option  pour ceux qui le souhaitent ?
En effet une recherche sur "ma"  va donner toutes les adresses gmail/hotmail  !!!
Imaginez un carnet avec 100 adresses gmail/hotmail  (ou plus) !

J2m06
One slight error in the translation above... "ma" has been translated into "my", it should have been left untranslated.

"a search on "ma" will give all the gmail / hotmail addresses"

And not just Gmail or Hotmail, of course, but anything with "mail" in it. Which is why, as so many of us have said, this is broken and needs fixing.
We assume this problem will be fixed via bug 970456.
(In reply to Angelika from comment #127)One slight error in the translation above... "ma" has been translated into "my", it should have been left untranslated.
Exact:-)
should read "ma" not "my" oups!


(In reply to aceman from comment #128)We assume this problem will be fixed via bug 970456.
I did not understand:-(
sorry . Once corrected the auto completion will no longer take into account domain names?

*-----------------------------------*
Exact :-)
Il fallait lire "ma " et non "mon"  oups!


Désolé.  Je n'ai pas bien compris :-( 
Une fois corrigé l'auto complétion ne prendra plus en compte les noms de domaines ?
(In reply to J2m06 from comment #129)
> (In reply to aceman from comment #128)We assume this problem will be fixed
> via bug 970456.
> I did not understand:-(
> sorry . Once corrected the auto completion will no longer take into account
> domain names?

It will also find matches in the domain name, however from the result set it will show matches that start with "ma" at the top.
So e.g. if today you get:
john@gmail.com
james@hotmail.com
...
mary@france.fr

after bug 970456 you should get:
mary@france.fr
...
john@gmail.com
james@hotmail.com

You probably wanted to find "mary" when you started typing "ma".

So it will not reduce the number of results found, but it will prioritize those that start with the searched string as that is what many users expect.
(In reply to Thomas D. from comment #124)
> Oh, and if you just want plain alphabetical lookup, consider just using this
> existing feature:
> 
> F9 to show contacts side bar in composition (a miniature AB), then enter
> your favourite one-letter search-word "u", and get an alphabetical results
> list sorted by NAME (don't get confused if there's no name specified on the
> card, it will show email address instead of name, so the first section might
> be alphabetically sorted by email address instead)...

Dear Thomas
        At my age 65....with 14 years of Chronic Neuralgia.........I don't wish for 'more steps', but less !!! :-)
For those that need/want more results.......perhaps have them enter more keystrokes, or check boxes !
so.... how do you turn this off????

When I type "an" I want the suggested results to be:

   Ana Lastname <ana.lastname@email.com>
   ...
   ...
   ...
   firstname hernandez <first.hernandez@email.com>

not

   firstname hernandez <first.hernandez@email.com>
   ...
   ...
   ...
   Ana Lastname <ana.lastname@email.com>



Usually I get the name that starts with "AN" as the last result... 

Thank you all for your time.
Yes that is what bug 970456 implements.
From a user perspective, can someone plese guide me on what fields to set in the Address Book to bypass this new search functionality?

I thought it was possible by filling-in a nickname, but apparently I misunderstood.

I've set silly, unique nicknames for each important contact ( only about 100 in the whole AB ) but when when I type 'kermit' TB still goes and searches, even though there are no other kermits.  I have to pause two seconds for TB to autocomplete with the only possible entry.  

My objective is to regain the old functionality of <enter partial name><tab><start typinig subject>.
Autocomplete bug is NOT fixed. When I start to type a recipient's address, I get a prompt that include the address I search for, but not on the top of the list. When I select it and press Enter to add another address, the previously added address gets replaced by some random one.
Has this been changed recently?

Thunderbird has been showing me irrelevant addresses that I haven't used for years instead of showing me the person I am in contact every day when using first few letters.
No, this change was implemented in TB27, i.e. you could get it in TB31 release, long ago. There may be changes in bug 970456 and bug 325458 which could have went (or are planned to go) into TB31 recently.
You need to log in before you can comment on or make changes to this bug.