261272 - autocomplete of LDAP address appends instead of replacing

Status: RESOLVED FIXED

(MailNews Core :: LDAP Integration, defect)

Description

[A. Sapuntzakis]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3
Build Identifier: Mozilla Thunderbird ver 0.8 (20040913)

When I hit [Enter] or click (focus) on another window after autocomplete has
selected an address (out of Collected or LDAP?), it appends rather than substituting


Reproducible: Sometimes
Steps to Reproduce:
1. create a new email
2. type something that's in the "Collected addresses" (or maybe LDAP)
3. Once autocomplete kicks in, hit [Enter] or click on another window

Actual Results:  
To: foo >> "Jones, Foobar" <[e-mail]>

Expected Results:  
To: "Jones, Foobar" <[e-mail]>

Comment 1

[Mike Cowperthwaite]

*** Bug 261358 has been marked as a duplicate of this bug. ***

Comment 2

[Mike Cowperthwaite]

With TB0.8, Win2K, I don't see this problem with collected addresses, or just 
plain addresses.  Nor do I see this when matching against a nickname, as 
suggested at the dupe.
I don't have an LDAP server to test against.

Comment 3

[Mike Fedyk]

This is a screen shot of what I got from bug 268031 which is a possible dup of
this bug.  Is this what you see on your screen?

http://bugzilla.mozilla.org/attachment.cgi?id=164801&action=view

Marking bug 268031 as a depending on this bug until someone verifies they see
the same thing.

Comment 4

[Bill Sheppard]

I would agree these bugs may well be related, but I think they are distinct.  I
can reproduce both Bug #268031 and this bug, but this one only is LDAP-related
(apparently) while Bug #268031 is also nickname related.

Comment 5

[Mike Cowperthwaite]

(In reply to comment #4)
> Bug #268031 is also nickname related.

I don't know why you say that, I don't see nickname mentioned at that bug.

Nickname *is* mentioned in bug 261358, duped to this bug because the reported 
symptom was identical.  Leos Literak, were you using an LDAP server when you saw 
the symptom in that bug?

Comment 6

[Bill Sheppard]

I say that Bug #268031 is nickname-related as I only saw it when I typed a
nickname in my address book and then moved to the next field (with tab or enter)
before autocomplete took place.  With further testing I see I can also make that
happen by typing the start of an entry in another (non-LDAP) address book, such
as Collected Addresses, which doesn't have a nickname.  I don't see it happen if
I type the start of an entry which is only present in the LDAP directory,
however; in that case it autocompletes correctly.

Comment 7

[Mike Cowperthwaite]

OK, there's a new dupe that specifies LDAP but shows the same form of the name 
duplication as mentioned at bug 268031.  So we have two forms of reproduction:
This bug's report:

Actual Results:  
To: foo >> "Jones, Foobar" <[e-mail]>

Expected Results:  
To: "Jones, Foobar" <[e-mail]>


Bug 268031 (like bug 272121):
Actual Results:  
Mike Fedyk <[e-mail]> >> Mike Fedyk <[e-mail]>

Expected Results:  
Mike Fedyk <[e-mail]>


I think the "nickname" issue is a red herring; but Bill Sheppard, feel free to 
open a bug specifically for that if you can make it reproduce.  (I can't; and I 
don't have an LDAP server to test with.)

Confirming this bug based on dupes, and adding LDAP to the summary.  Changing 
platform to the least-common denominator Win2K, altho I wouldn't be surprised to 
find this is an All/All bug.

Comment 8

[Mike Cowperthwaite]

*** Bug 268031 has been marked as a duplicate of this bug. ***

Comment 9

[Mike Cowperthwaite]

*** Bug 272121 has been marked as a duplicate of this bug. ***

Comment 10

[Mike Cowperthwaite]

See also bug 103917, which is this is probably a dupe of.

Comment 11

[Doug Wright]

-> Core:MailNews:LDAP Integration

Comment 12

[Angus Davis]

I can reproduce this bug every time.

1. Set configuration to include autocomplete behavior against an LDAP directory.
2. Type in just the last name of an employee in your LDAP directory, and hit
enter before the drop-down appears.
3. Note the bogus response (see
http://www.meer.net/~angus/thunderbird/addr_auto.png for an example)

If you type in "FristName LastName" in step #2, you workaround the bug.

Comment 13

[Mike Cowperthwaite]

*** Bug 281796 has been marked as a duplicate of this bug. ***

Comment 14

[Mike Cowperthwaite]

From the dupe:
 -- Type a partial name in the to:\ field. (You may need to make sure you have 
at least 2 names in the address book that contain what you type - i.e. if you 
have a Mike & a Michele in your address book, type "Mi")
 -- Two entries will appear in the to:\ field (in my example, both Mike & 
Michelle would appear in the to:\ field & the email would go to both of them)
It appears in this format:
Mike <[e-mail]> >> "Michelle" <[e-mail]>
 -- we have noticed that this bug only occurs when you type a 
name that appears both in a personal address book AND an ldap address book.  
For example, if I type "mi" & hit my enter key really fast, it pulls in a name 
from my personal address book & to the right of that puts one from my ldap.  

Comment 15

[Mike Cowperthwaite]

The alleged dupe (comment 13) has been reopened; reporter of that bug stated 
that *this* bug had been experienced with TB 0.8, but that they are no longer 
seeing the symptom with TB 1.0; whereas the behavior described in comment 14 is 
new to 1.0.

Are reporters of this bug still experiencing the problem with 1.0?  Angus 
Davis's comment 12 is the only report since 1.0 was released.

Comment 16

[Craig D. Rice]

Yes, I experience this in version 1.0 (20041206). If a name exists in the
addressbook and in LDAP, it does not resolve properly.

For example, if I type "cdr", hit ENTER a little too fast, I get:

[e-mail] >> Craig D Rice <[e-mail]>

If I delay before hitting ENTER, then I get a list of address I can chose from,
and when I select, it populates the To: field properly.

Comment 17

[Bill Sheppard]

If this is the same bug as 268031 then I definitely still see it.  I can't
reproduce the behavior as defined in this bug originally, which is to say if I
type part of an address and allow it to auto-complete, it formats fine.  If I
type part of an address or a nickname and immediately hit tab or enter then it
autocompletes incorrectly as detailed in bug 268031.

Comment 18

[Misty]

The original report on this bug says AFTER the autocomplete selects an 
address, you hit enter and it pulls up a result like:

To: foo >> "Jones, Foobar" <[e-mail]>

This is a problem my company experienced with 0.8.  This has been resolved 
here since we upgraded.  I don't know if others are still having that problem 
since upgrading, but in my company we have about 2,000 users and I work on the 
email help desk and have not had any calls on it recently.  However, since 
upgrading to 1.0, there's this new problem if you hit enter BEFORE the 
autocomplete makes suggestsions, then it pops 2 names in the to: field (one 
from an address book & one from an ldap).  Thanks for re-opening bug #281796 
for me.

Comment 19

[OstGote!]

*** Bug 270845 has been marked as a duplicate of this bug. ***

Comment 20

[Deb Teale]

I can repeat a problem with the autocompletion in several instances if I have a
Collected addressbook and our LDAP directory.ucalgary.ca.  The result can be
duplicate on one line as reported by others but also two different addresses
(very dangerous) or combination of complete and incomplete address on one line:

Results for da:
Laurie Davison <""\"\"\"\"davison\"\"\"@ucalgary.ca>ary.ca>
Results for dau:
Doug Dau <[e-mail]> >> Doug Dau <[e-mail]>
Results for yip:
Joseph Yip <[e-mail]> >> Jennifer Yip-Choy <[e-mail]>

In the first example above the ary.ca is appended to end of the choice of
[e-mail].
In the last case two different addresses are put on the To: line which has
caused us some grief.

Comment 21

[(not reading, please use [e-mail] instead)]

re-assign to david

Comment 22

[David :Bienvenu]

isn't this a dup of a bug you fixed, Scott?

Comment 23

[Misty]

I think my comment #18 might help shed some light on that a little.  ;o)

Comment 24

[David :Bienvenu]

I can reproduce this every time by typing a string really quickly and then
pressing return or tab as quickly as possible. I'm getting one match from the
local address book and one from the ldap directory, and both are getting put in
the addressing widget. My guess is that this has to do with the synchronous
nature of local address book autocomplete and the async nature of ldap lookups.
It seems that if we exit the address widget before we can populate the dropdown,
and we get matches from multiple sources (local ab and ldap directory), then
both get added. This happens for nicknames or just normal names. I'll poke
around some more with the autocomplete widget to try to figure out what's going on.

Comment 25

[David :Bienvenu]

Attachment: a bunch of diagnostic dump statements, and the fix

I'm saving this for posterity in case I ever need to debug this widget again.

Comment 26

[David :Bienvenu]

Attachment: proposed fix

if we've filled in the default match, set what seems to be the appropriate
member var - mDefaultMatchFilled. This seems to be the obvious thing to do, and
it works, though it took me most of the day to stumble upon it.

Comment 27

[David :Bienvenu]

*** Bug 281796 has been marked as a duplicate of this bug. ***

Comment 28

[Scott MacGregor]

Comment on attachment 184617 [details] [diff] [review]
proposed fix

This seems ok to me. 

You should get Neil's review as well though.

Comment 29

[[e-mail]]

Comment on attachment 184617 [details] [diff] [review]
proposed fix

What you can't see because the patch has insufficient context is the
"this.stopLookup()" that I added for bug 244522. Unfortunately that doesn't
stop anything but asserts in nsLDAPOperation.cpp :-(

Comment 30

[Mike Shaver (:shaver emeritus)]

Comment on attachment 184617 [details] [diff] [review]
proposed fix

a=shaver

Comment 31

[Dan Mosedale (:dmosedale, :dmose)]

*** Bug 103917 has been marked as a duplicate of this bug. ***

Comment 32

[Mike Cowperthwaite]

*** Bug 273019 has been marked as a duplicate of this bug. ***