81695 - selected entry in autocompletion box doesn't hold the value

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Address Book & Contacts, defect, P2)

Description

[yulian chang]

The selected entry in autocompletion box doesn't hold the value
in the compose window when the the focus moves to the second 
addressee.

1. In compose window, type in "yu"
2. a list of matching entries displays in the autocompletion box
3. click one of them, for example, [e-mail]
4. "[e-mail]" is now displayed in the first entry of 
address area in the compose window
5. click on the second entry of addressee
6. "[e-mail]" in the first entry becomes "[e-mail]"

Comment 1

[yulian chang]

It finally displays whatever you type in. Doesn't honor the selection.

Comment 2

[Brian Nesse (gone)]

wfm on MacOS 2001052115. However, when I clicked in the 2nd address field and
started typing I got a popup that had a scrollbar, but no visible elements.

Comment 3

[Srilatha Moturi]

Brian there is another bug on that. bug# 78771

Comment 4

[Jeff Hooker]

Win98SE | N6.1 PR 0 (build id: 2001052204) | Prefs: Local (checked) | NSCP LDAP 
(checked) | Do not look as LDAP if in local (checked)

WFM with the above platform/settings ... however, the following occurs:

1. in compose window, type in "yu"
2. a list of matching entries displays in the autocompletion box
3. click [e-mail]
4. "[e-mail]" is now displayed in the first entry of 
address area in the compose window
5. click on the second entry of addressee
6. "[e-mail]" in the first entry holds "[e-mail]"
7. in second entry of address area, type in "je"
8. blank entries display in the autocompletion box; scroll down menu appears but 
with blank / hidden entries
9. unable to add additional addresses from local or nscp ldap directories

Comment 5

[Srilatha Moturi]

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

Comment 6

[Srilatha Moturi]

The following code is from nsAbAutoCompleteSession.cpp:
561             {
562               status = nsIAutoCompleteStatus::matchFound;
563               if (addedDefaultItem)
564               {
565                 if (nbrOfItems > 2)
566                   results->SetDefaultItemIndex(-1);
567                 else
568                   results->SetDefaultItemIndex(nbrOfItems == 2 ? 1 : 0);
569               }
570               else
571                 results->SetDefaultItemIndex(nbrOfItems > 1 ? -1 : 0);
572             }
573         }

Setting the defaultItemIndex to either 1 or 0 is causing this problem. Setting 
this to -1 would fix it. Since I am not familiar with this code I am not sure if  
I can do this.
ccing ducarroz for input.

Comment 7

[Srilatha Moturi]

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

Comment 8

[Srilatha Moturi]

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

Comment 9

[Dan Mosedale (:dmosedale, :dmose)]

One possible solution to this would be to associate any default value with the
XBL autocomplete widget itself rather than the individual autocomplete sessions.
 hewitt/ducarroz/alecf: any thoughts on this?

Comment 10

[Dan Mosedale (:dmosedale, :dmose)]

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

Comment 11

[scottputterman]

I'll add my opinion that this is pretty scary and that if we're going to have
ldap autocompletion in 0.9.1 we should fix this in 0.9.1.  It's very easy to
reproduce and will lead to messages sent to the wrong people.

Comment 12

[Jean-Francois Ducarroz]

What I am seeing is that the problem occurs only when we have both addressbook
and ldap autocomplete enable. My guess is that we are doing something wrong when
we merge the result form both sources. I don't think it's anything to do with
the default selection, the user should be able to select whatever he wants
disregard the default item. Let me take a look...

Comment 13

[Joe Hewitt (gone)]

This is mine.

Comment 14

[Joe Hewitt (gone)]

I'm able to reproduce with the original steps, I'm pretty sure this is an XBL
problem.

Comment 15

[marina]

i filed the bug # 84391 where it is reproducable when your address is not in
Collected Addresses: in case it is not there the autocompletion is not
happening; when you do have the address in CA the match is found and remembered

Comment 16

[Jean-Francois Ducarroz]

the problem is in autocomplete.xml in the function finishAutoComplete. If we
have a default item, we always use it!!!

Comment 17

[Jean-Francois Ducarroz]

This problem occurs also when you have only one source!

Comment 18

[Jean-Francois Ducarroz]

Joe, why in finishAutoComplete do you set the texbox value to the default search
result? you should take whatever the user has selected!

Comment 19

[Hong Kwon]

adding dataloss and nsbeta1 keywoards from 84503

Comment 20

[Joe Hewitt (gone)]

Attachment: patch to fix

Comment 21

[Jean-Francois Ducarroz]

I've just finished to test the patch. Works great. R=ducarroz

Comment 22

[yulian chang]

I notice that there's work around for this problem for now.
Append a space behind the selected name then press Enter. This way will hold.

1. Bring up a new Msg window and type in a name 
2. Select a name which comes from LDAP directory
3. press space
4. press enter
5. it hold well on all platforms

Comment 23

[scottputterman]

per PDT, putting in 0.9.1 and adding hitchhiker to status whiteboard in case of
respin. It doesn't go in if there isn't one. we need a super review.

Comment 24

[Dan Mosedale (:dmosedale, :dmose)]

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

Comment 25

[Simon Fraser [no longer active]]

sr=sfraser

Comment 26

[Asa Dotzler [:asa]]

a= [e-mail] for checkin to the trunk.
(on behalf of drivers) 

Comment 27

[Dan Mosedale (:dmosedale, :dmose)]

Patch checked into the trunk.

Comment 28

[Jean-Francois Ducarroz]

looks like this patch cause a regression!

In message compose, when I type a nickname like "jfd", the widget correctly
autocomplete to "jfd >> Jean-Francois Ducarroz<[e-mail]>" but when
I either press return or tab or set the focus in another area, the field is not
cleaned up anymore, it should become "Jean-Francois
Ducarroz<[e-mail]>"! This could cause some send problem. Joe, can
you take a look at it?

Comment 29

[Joe Hewitt (gone)]

thanks for landing the patch, dmose.

fixed.

Comment 30

[Joe Hewitt (gone)]

Oh crap. regression indeed.  I'll fix that and open a separate bug for it in a
segundo.

Comment 31

[Srilatha Moturi]

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

Comment 32

[Srilatha Moturi]

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

Comment 33

[yulian chang]

Verified with trunk builds on winds, Linux and MacOS.

Comment 34

[Dan Mosedale (:dmosedale, :dmose)]

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