Closed Bug 323364 Opened 19 years ago Closed 16 years ago

Address autocomplete fails to toplist matches-on-nickname when matches-on-name are available

Categories

(Thunderbird :: Message Compose Window, defect)

x86
Windows 2000
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 325458

People

(Reporter: spamluvr, Assigned: mscott)

Details

(Keywords: regression)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

Address autocomplete fails to list nickname matches first (if at all) when older address book entries match by e-mail address or name.

Under Tb 1.0.7 the top results in address autocomplete were nickname matches, regardless of when the entry was made.

Under Tb 1.5 nickname matches are given equal relevance as matches by name or e-mail address (which is incorrect) and so whichever entry is oldest is listed first.

Reproducible: Always

Steps to Reproduce:
1. Create a new profile.

2. Open the Address Book and create an entry as follows:
First Name: Paul
Last Name: Paper
Nickname: (leave blank)
E-mail Address: paul@paper.com

3. Create another new Address Book entry as follows:
First Name: Foo
Last Name: Bar
Nickname: p
E-mail Address: foo@bar.com

4. Close the Address Book and click the "Write" button to compose a new message.

5. Type the letter "p" in the To: field.
Actual Results:  
The "Paul Paper" address is the only address presented.

Expected Results:  
The "Foo Bar" address is listed as the first match, Paul Paper listed second.

This may be related to bug 201933.

Note that if you delete the address book entries and create them in the reverse order, the "Foo Bar" address is listed and not the Paul Paper address.
(In reply to comment #0)
> Under Tb 1.0.7 the top results in address autocomplete were nickname matches,
> regardless of when the entry was made.
> 
> Under Tb 1.5 nickname matches are given equal relevance as matches by name or
> e-mail address (which is incorrect) and so whichever entry is oldest is listed
> first.

Under 1.5, the sort order is supposed to be different: it was changed to 
list most-frequently-used addresses first -- bug 276632.

I can reproduce this problem, with 1.5 and 1.6a1-0105.  Moz 1.0 does not 
behave the same.  You may be right about bug 201933, altho that bug was filed long before the fix for 276632 was checked in.

One additional symptom I note: if I follow your steps to reproduce, then clear the "paul paper" match and enter "foo" to get the desired address, that works 
of course.  But then, when I open another compose window and type "p", I get only a match on "Foo Bar" -- the "Paul Paper" entry doesn't appear in the 
list.

If I then follow the "p" with an "a", "Paul Paper" appears -- and I can send 
to that address, open *another* compose window, and "p" matches, only, on Paul Paper.  This behavior makes me think the glitch is related to the change for most-frequently-used (most-recently?).

I'm going to resummarize the bug according to what I see as the problem.  
Regarding the ordering: you should first review bug 276632, bug 67055, 
bug 64662, bug 302935 (and maybe some others I'm missing); then, if you think that nicknames should get precedence over actual names, open a separate bug (as an enhancement) for that.
Severity: major → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
OS: Windows XP → Windows 2000
Summary: Address autocomplete fails to give nickname matches preference → Address autocomplete fails to list matches-on-nickname when matches-on-name are available
Version: unspecified → Trunk
I would definitely vote for nicknames taking precedence over frequently used names for autocomplete - the behaviour is very unintuitive without this.

BTW: I just posted this as a bug comment to 322900 as I found that bug first (apologies for that).
The behavior of showing a single name where two should match is bug 318992, for which a patch is imminent (bug 314047).  The failure to use nicknames will, I think, be addressed at bug 201933 -- David Bienvenu told me that he thought it was a problem, and one worth fixing.
Thanks for the update, much appreciated.
QA Contact: message-compose
is this working? or am I mistaken?
I'm pretty sure the nickname functionality was removed for auto-complete - is it possible it's autocompleting on the name or e-mail address?
(In reply to comment #6)
> I'm pretty sure the nickname functionality was removed for auto-complete - is
> it possible it's autocompleting on the name or e-mail address?

No. WFM TB version 3.0a2pre (2008061103) and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008061702 SeaMonkey/2.0a1pre (bug 201933)

typing zzname in compose with the following AB entries, autocomplete presents both in the results

fname   nick    email
zzname  <null>  x@y
nowhere zzname  y@x
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
How do I assign all of my 1000 votes to this problem? I'm surprised at how few people managed to locate this place to complain that nicknames are ignored when addressing mail in the editor.

This bug is about 4 years old. What programming language do I need to learn to fix it myself? I haven't worked as a programmer in 20 years but it can't be too hard to test for the "nickname" first and use it before "last name", "first name", "email address", etc.
Hi Pat,

thanks for commenting and you're right!
However, note that comments on closed bugs tend to not get attention.

(In reply to Pat Drummond from comment #8)
> How do I assign all of my 1000 votes to this problem? I'm surprised at how
> few people managed to locate this place to complain that nicknames are
> ignored when addressing mail in the editor.

Well, I guess it's because this bug has been closed in error, and you have already commented (long ago) on the duplicate Bug 325458 Comment 3. I've adjusted the summary of that bug to make it easier to find in bugzilla searches:

Bug 325458 - Recipient Autocomplete: Nickname does not get highest precedence for matching address book entries, for searchphrase==nickname [To, CC, addressing field/area, toplisted, priority, results]

> This bug is about 4 years old. What programming language do I need to learn
> to fix it myself? I haven't worked as a programmer in 20 years but it can't
> be too hard to test for the "nickname" first and use it before "last name",
> "first name", "email address", etc.

Oh, you are more than welcome to provide a patch! :) Thunderbird is under volunteer maintenance, so we really need people who take things into their own hands. The programming language in this case is JavaScript, which is plain English and pretty straightforward, and I've provided a starting points in code, see Bug 325458 Comment 49 ff.

Generally speaking, let's be careful with such judgements unless we know more exactly what we're talking about. But still, no doubt this can be fixed with reasonable effort and must be fixed, and I've done my best to push for that fix to happen.
Wayne, you probably closed this wfm based on current summary, but unfortunately there's mismatch between summary and user story. User story wins, which makes this a dupe of bug 325458.

(In reply to Wayne Mery (:wsmwk) from comment #7)
> (In reply to comment #6)
> > I'm pretty sure the nickname functionality was removed for auto-complete - is
> > it possible it's autocompleting on the name or e-mail address?
> 
> No. WFM TB version 3.0a2pre (2008061103) and Mozilla/5.0 (Windows; U;
> Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008061702 SeaMonkey/2.0a1pre (bug
> 201933)
> 
> typing zzname in compose with the following AB entries, autocomplete
> presents both in the results
> 
> fname   nick    email
> zzname  <null>  x@y
> nowhere zzname  y@x
Resolution: WORKSFORME → DUPLICATE
Summary: Address autocomplete fails to list matches-on-nickname when matches-on-name are available → Address autocomplete fails to toplist matches-on-nickname when matches-on-name are available
You need to log in before you can comment on or make changes to this bug.