Using 2000-06-13-08 on NT 1. Kimberly Bradway is in my Collected Address Book. 2. Open a compose window 3. Type "kim br" in the addressing widget, no match 4. Type "kimberly br" in the addressing widget, now it matches Seems like we need to do substring matches on the first word, in addition to the last word. In 4.x, we called this the "Chris Yeh" problem, since he was in LDAP as "Christopher Yeh"
Add 4xp and nsbeta3 keywords
Keywords: 4xp, nsbeta3
Maybe you should list options which match the whole string first, and options which match only one of the words (e.g. `Kit Fr' to match `Christopher Francis') after that? Or maybe list options which match any of the words only if there are no matches which match the whole string.
Personally, I wouldn't want either of those options. I want an alphabetical list of hits matching the pattern (kim* br*). A segmented list of matches would be confusing to me (non-sorted would look like a bug) and deciding to show some matches but not others defeats the purpose of the autocomplete picker (which is to unambiguously choose the right recipient based on all possible matches)
No longer blocks: 42796
adding myself to the cc list.
Mail Triage is marking [nsbeta3-]
Target Milestone: M18 → Future
Changing qa assign to myself.
QA Contact: esther → pmock
Add mail3 keyword
*** Bug 62225 has been marked as a duplicate of this bug. ***
marking nsbeta1+ and moving to mozilla0.8
Keywords: nsbeta3 → nsbeta1
Priority: P3 → P2
Whiteboard: [nsbeta3-] → [nsbeta1+]
Target Milestone: Future → mozilla0.8
In 4.x, if I type "Kim Brad" in the adressing field, I get back "Kim@netscape.com, Brad@netscape.com <No match found>. This despite the fact I have an entry for Kimberly Bradway in my address book. However, 4.x is able to find her if I type "Brad" but not 6.x. However, as 6.x is not able to autocomplete several email addresses on the same line (input), It should be possible to try to match any partial words as described by Phil. We should try to do the following matches for a dual word input: <xxx> <nnn> 1) <xxx> <nnn> against the display name (last name + first name) Already done by 6.0 2) <xxx> <nnn> against the nick name.Already done by 6.0 3) <xxx> <nnn> against the email address. Already done by 6.0 4) <xxx> against last name and <nnn> against first name 5) <xxx> against first name and <nnn> against last name And for a one word input: <xxx> 1) <xxx> against display name, 6.0 does that 2) <xxx> against nick name, 6.0 does that 3) <xxx> against email address, 6.0 does that 4) <xxx> against fist name 5) <xxx> against last name (just in case it's different than the display name)
> In 4.x, if I type "Kim Brad" in the adressing field, I get back > "Kim@netscape.com, Brad@netscape.com <No match found>. This despite the fact I > have an entry for Kimberly Bradway in my address book. I guess 4.x uses a different matching pattern for local AB entries, vs. LDAP entries. I'm pretty sure "Kim Brad" will match for LDAP autocomplete. > We should try to do the following matches for a dual word input: <xxx> <nnn> Sounds very complete. One thing perhaps to keep in mind is that an LDAP filter string which expresses that logic will be pretty complex.
Ok, I have implemented the whole logic I'have described earlier. Now I am looking at sorting the result but I don't know on which criteria to do it? matches are shown as: [firstName] [lastName] <[email address]> any preference for the sort?
Whiteboard: [nsbeta1+] → [nsbeta1+] Fix in hand
it's hard to tell until I use it, but I think I like the idea of it being sorted by the first name. Only because normally when I autocomplete, I start typing the first name and so that's how I'd be looking for it in the list.
Sorting by last name would only make sense in those cultures where the surname is the last name (e.g. the US and most European cultures). Sorting by first name would make sense everywhere (because it's obvious alphabetical order, same as for the other uses of auto-complete in Mozilla). No it should not be a pref. (Just in case anyone suggests that.)
I've just check in the new algo that solve the initial problem reported in this bug. I'll open a new bug for the sorting issue.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Bug 64662 has been filed. Please use it for further discussion about sorting the autocomplete result and add yourself in the cc list if you are interested. Thanks
Win32 (2001-02-20-09 mtrunk) This problem is fixed as originally reported.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.