Closed Bug 1068570 Opened 5 years ago Closed 5 years ago

address book's recipient autocomplete throws up (toplists/prioritizes) "wrong" contact

Categories

(Thunderbird :: Message Compose Window, enhancement)

31 Branch
x86
Windows XP
enhancement
Not set

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 970456

People

(Reporter: dalkeith, Unassigned)

Details

(Whiteboard: [consider followup bugs per Comment 6])

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.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Depends on: 970456
Ever confirmed: true
Flags: needinfo?(bugzilla2007)
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.
Flags: needinfo?(bugzilla2007)
Same behaviour after the yesterdays update to v.31.1.1
Blocks: 1069826
Component: Untriaged → Message Compose Window
No longer blocks: 1069826
See Also: → 1069826
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.
Status: NEW → RESOLVED
Closed: 5 years ago
No longer depends on: 970456
Resolution: --- → DUPLICATE
See Also: 1069826
Summary: address book autocomplete throws up wrong contact → address book's recipient autocomplete throws up (toplists/prioritizes) "wrong" contact
Duplicate of bug: 970456
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.
Whiteboard: [consider followup bugs per Comment 6]
You need to log in before you can comment on or make changes to this bug.