331817 - nickname should supercede ldap in autocomplete

Status: RESOLVED INCOMPLETE

(Thunderbird :: Message Compose Window, defect)

Description

[Daniel Wagner]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050926 Firefox/1.0.7
Build Identifier: version 1.0.7 (20051011)

I have configured myself to access a pretty large LDAP server, so pretty much any short string has a match.  I also had set up earlier a couple of very short nicknames for people I write to a lot.

Entering one of these nicknames in the address bar of a composition window (then "tabbing out" to the subject bar) sends mail to the first match from LDAP, when it ought to recognize my custom-made nicknames.

Reproducible: Always

Steps to Reproduce:
1. Create a contact with a nickname that also generates an LDAP match.  (working nickname is "foo")
2. Click "Write": focus automatically goes to "To:"
3. Enter "foo"

Actual Results:  
The nickname "foo" is expanded to the contact information for the person in your address book, then appended with the email address of the LDAP match:
"Foo B. Lastname <[e-mail]> >> Bazz R. Fooname" <[e-mail]>

Expected Results:  
The nickname "foo" should be expanded to the contact information for the person in the address book, then kept that way:
"Foo B. Lastname" <[e-mail]>

This is actually two bad things in one.  The worst and more important error is that e-mail gets sent to the wrong person, and that person is given a (possibly confidential) name and contact information.  Simultaneously, a new entry is created in Collected Addresses that begins with the wrong name, but goes to the wrong address!

Possibly related to bug 201933 for the suite.

Comment 1

[Mike Cowperthwaite]

Which version of Thunderbird is this bug reported against?

Nicknames stopped being used between 1.0 and 1.5, as I noted at 
bug 201933 comment 7.  The problem of the LDAP completion causing unexpected completion strings, such as you describe, has been reported before -- 
bug 261272 and its several dupes -- but that was fixed for TB 1.5.

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Reporter, does this issue still occur in the latest supported 2.0.0.x / Shredder trunk nightlies?

(1.5.0.x is now end-of-life, and the latest supported 2.0.0.x is 2.0.0.16)

Comment 3

[Joshua Cranmer [:jcranmer]]

RESO INCO per lack of response to last comment. If you feel this change was made in error, please respond to this bug with your reasons why.