User Agent: Mozilla/5.0 (Windows NT 5.1; rv:32.0) Gecko/20100101 Firefox/32.0 Build ID: 20140911151253 Steps to reproduce: In Thunderbird type in an address "andrew c", looking for Andrew Corletto Actual results: Thunderbird returns "Andrew McLeay <andrew@hillsbookeepingservices.com.au>", the way wrong address Expected results: it should have returned "Andrew Corletto <Andrew Corletto@minterellison.com>" The autocomplete will not pick up the address from my "collected addresses" folder

error in expected results: it should be "Andrew Corletto <Andrew.Corletto@minterellison.com>" autocomplete will not ignore the "dot" between the names, and it should!

Yes, TB31 searches for "Andrew" and "C" separately. Bug 970456 will partly fix this. But prioritizing the contact that matches the whole search string ("Andrew C") can be then built on top of the infrastructure from that bug. Thomas will know if this isn't already filed somewhere.

See bug 1067681 "Create MetaSearch rank order via Prefs for Address Autocomplete" . . . . . . which suggests a coding backbone that gives options to those who generally seek searches that rank higher ("Andrew" and "C") versus those hoping for ("Andrew C") at the top of the list. This particular example may not highlight large, distinguished user population sets, but it does show off another example of the utility of the suggestion in Bug 1067681.

(In reply to :aceman from comment #2) > Yes, TB31 searches for "Andrew" and "C" separately. Bug 970456 will partly > fix this. > But prioritizing the contact that matches the whole search string ("Andrew > C") can be then built on top of the infrastructure from that bug. > > Thomas will know if this isn't already filed somewhere. I think that Bug 970456 will actually fix that: We will still search for each word separately to find all matching results, BUT for ordering results (scoring), from my reading of the patch, we compare against the *full search string* there (not just against each search word). But we should verify with Magnus if that's actually the case. Selected lines from patch attachment 8485391 [details] [diff] [review]: + * @param aSearchString - user given search string + * @retrun a score; a lower score is better than a higher one + _getScore: function(aAddress, aSearchString) { + let idx = aAddress.indexOf(aSearchString); + return idx; So search words "Andrew C" will score 0 against a result beginning with that string, Andrew Corletto <Andrew Corletto(at)minterellison.com>, and lowest score will then get toplisted according to the scoring logic. I understand that result will actually be toplisted regardless of popularityIndex, which will be partly disabled by that patch. I'm still not sure how that affects things, but well, we have to try.

Same behaviour after the yesterdays update to v.31.1.1

Bug 970456 has fixed this problem as described in comment 0 for most practical purposes. Potential further improvements to the details would need clean starts in new RFEs, e.g. - search for "Andrew c" should not only find, but also toplist based on email address which is similar, but not identical to search word, e.g. having dot-separator between names: "Andy <andrew.corlettto(at)asdf.com>" This will often be covered if exact matching display name is provided; otherwise might be tried in a new bug with critical eye on performance. - double match on one contact, e.g. "Andrew" in display name AND email address, might be considered for higher rank: "Andrew Corlettto <andrew.corlettto(at)asdf.com>" Again, that would be for a new bug to try. There's probably no limit to sophistication. I suspect auto-adaptive "frecency" algorithm as in FF will fly better for most users in the long run.

Oh, for the avoidance of doubt, the fix for Bug 970456 has not yet landed in current release version of TB, as Mark requested a bit of baking time. Stay tuned, we'll release this asap.