88315 - Mail compose autocomplete fails when more than one match

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect, P2)

Description

[hangas]

When typing in a name into the addressing area of a new message, if the text
entered matches the start of more than one address book entry, hitting Enter
will not choose the first of those address book entries.  I have two address
book entries that matches the string "German", entering "German" shows me both
entries as well as [e-mail], when I hit return it leaves me with the
text "german" on that line with nothing following it.  It should pick the first
email address from the address book.

Comment 1

[hangas]

Marking 0.9.3 and keyword nsBranch

Comment 2

[hangas]

moving to ducarroz based on hewitt's suggestion.  jglick agrees that it would be
best to choose the first name from the address book in this case.

Comment 3

[hangas]

just to be painfully clear, the address that should be selected in this case is
the first match from the address book, not the first match in the dropdown.

Comment 4

[jglick]

Correct.

To clarify, if I have two entries for "German Bauer" in my Address Book, the 
dropdown list may look like:

[e-mail]
[e-mail]
[e-mail]

If user selects Enter/Return, "[e-mail]" should be selected in the 
addressing area, Not [e-mail] (the default domain).

(4.x worked this way. The default domain address was the first displayed in the 
"Addresses Matching..." dialog, but the second match was highlighted by 
default).

Comment 5

[scottputterman]

moving to 0.9.4

Comment 6

[Sheela Ravindran]

reassign->esther

Comment 7

[Jussi-Pekka Mantere]

Adding back nsBranch, adding nsenterprise+.

Comment 8

[Scott MacGregor]

Attachment: the fix

Comment 9

[Scott MacGregor]

re-assigning to me. 

Comment 10

[Joe Hewitt (gone)]

r=hewitt

Comment 11

[Jean-Francois Ducarroz]

Scott, your patch is putting back the behavior we use to do when I first
implemented autocomplete. But I had been asked to change it, see bug 39180.

I think the compromise would be to do inline autocompletion only when we have at
least one exact match or if we don't have an exact match but only only partial
match. Else not inline autocompletion.

Comment 12

[Scott MacGregor]

what are you doing working on vacation JF!! =)

doesn't this bug fix it to match 4.x behavior? I thought 4.x did what my change
does.

Comment 13

[Jean-Francois Ducarroz]

I am not working, I am playing with Mozilla ;-)

I thing, in 4.x, if you have more than a match, we put the multi match string
but we never force the user input to be the first one. I personnaly prefer that
we force the first one as we show as well the full list in the drop down but
then you have bug 39180 which ask for the inverse!

That's why the compromise I proposed should satisfied every body.

Comment 14

[Scott MacGregor]

JF unless I'm misunderstanding....isn't what you are proposing what we do today?
If there's an exact mactch it's used as the default. If there's only one partial
it's used as the default. 

Jennifer, what do you think the behavior should be? This bug or the current
behavior which was done to fix 39180?

Comment 15

[Jean-Francois Ducarroz]

Also, look at bug 93453, we have a smilar discussion about the behavior of
autocomplete.

Comment 16

[Jean-Francois Ducarroz]

...and bug 96667.

Comment 17

[Scott MacGregor]

we'll try to work out the desired behavior we want for the auto complete widget
next week during the .9.5 time frame; however the bug will still be checked into
the branch so leaving the nsEnterprise+ nomination alone. 

Comment 18

[jglick]

ok, this issue has gotten very confusing. :-)

Bug 39180 seems to conflict with this one as JF mentions.

1. If there are no exact matches and the user selects "Enter" take what they 
have typed and add the "@domain". (this currently not working).

I think both bugs agree with this one.

2. If there is one exact match, should autocomplete on the match. Don't show the 
popup menu list.

Both agree.

3. What to do when there is more that one exact match or no exact match but more 
than one partial match and the user selects "enter/return".

a. Don't auto complete from the user input and display the popup 
menu will all the matches.  Once the user makes a selection from the popup menu, 
autocomplete on that item.  If user doesn't select and just chooses 
"enter/return", take what they have typed and add the domain name to the end.

b. Autocomplete on the first entry (not including the default domain item) from 
the user's address books.

Comment 19

[jglick]

Playing with 4.x:
More than One Partial Match:
its seems that option 3a above is more similar to 4.x. 

1. With 4.x I type "glick".
2. It says "multiple matches".
3. Hit Enter/Return, dialog opens and default of "[e-mail]" is the top 
item and highlighted.  Followed by a list of my relatives ;-)
4. Hit Enter/Return and dialog closes and "[e-mail]" is shown in 
addressing area.

Playing with 4.x:
More than One Exact Match:
its seems that option 3b above is more similar to 4.x. 

1. With 4.x I type "jennifer glick".
2. It says "multiple matches".
3. Hit Enter/Return, dialog opens and displays several email addresses for 
Jennifer Glick are displayed. default domain address is at top.  Top default 
domain is not selected though. Second item, first entry of Jennifer Glick in my 
AB is selected.
4. Hit Enter/Return and dialog closes and email address of first Jennifer Glick 
in my AB is shown in addressing area.


I think what is also currently confusing is that in current builds the domain 
name is NOT currently being added when I "enter/return".  Also, if the top item 
in the autocomplete list (the default domain item) was shown as highlighted as 
appropriate, it would help users clue in that this is what they will currently 
get if they "enter/return".

Comment 20

[jglick]

OK, how about:

1. More than One Partial Match: Don't autocomplete again an AB entry. Show the 
first item in the dropdown, the <whatuserhastyped@defaultdomain> as highlighted 
so it obvious if they hit return they will get <whatuserhastyped@defaultdomain>.

2. More than One Exact Match: Do autocomplete again AB. Show the first entry 
after default domain entry in the dropdown as selected. User enters/returns 
thats the item they get.

3. If there are no exact matches and the user selects "Enter/return" take what 
they have typed and add the "@domain". (this currently not working).

4. If there is one exact match, should autocomplete on the match. Don't show the 
popup menu list.

That cover everyone?  ;-)

Comment 21

[hangas]

It looks good to me.  Does TAB give the same results as Enter/Return then?  I 
would expect TAB/Enter/Return to be the same for this dialog (but not change the 
browser autocomplete behavior).  Although TAB would bring you then to the subject 
field afterwards where the other two would bring you to the next address line.

Comment 22

[Scott MacGregor]

Just so we are explicitly clear, in case (4), that is a change from the behavior
today. Today if you type in an exact match "Jennifer Glic" and I only have one
entry in my CAB which completes out to [e-mail], we still show the
popup dialog with the default domain and the one exact match. Of course the
exact match is pre selected and just hitting enter or tab automatically selects
it. So we want to hide the popup in this scenario?

Comment 23

[esther]

Just a note about #4.  4.7's behavior was if an exact match happened, no list
was generated (meaning we didn't add the typed text+domain as a possible
selection).  I think people liked that, is it possible to do that.

Comment 24

[Scott MacGregor]

we talked about this today at an issues meeting and we are going to check in the
patch I posted (pending reviews of course) into the trunk. That'll give us all a
chance to play around with the new behavior and determine if we like it or not.
Just so we are clear the patch causes us to pre-select the first match in the
list whenever there are multiple matches (both partial and exact).

Comment 25

[Jean-Francois Ducarroz]

Comment on attachment 46637 [details] [diff] [review]
the fix

R=ducarroz

Comment 26

[Hong Kwon]

per comments, changing to ASSIGNED

Comment 27

[Scott MacGregor]

r=ducarroz
sr=hewitt

This is now checked into the trunk. Please try it out in tomorrow's builds!

Comment 28

[Scott MacGregor]

this usability change to the autocomplete widget was PDT plusse at Friday's PDT
meeting. Making it reflect that reality.

Comment 29

[Scott MacGregor]

Fixed on the branch. 

Comment 30

[Thierry Carrez]

I tried the new autocomplete on BuildID 2001092308 and there is still a problem
when there is a unique match, located on a LDAP directory. The current behaviour
is different from Netscape 4.7X behaviour. Here is the test scenario (already
explained in bug 93453) :

Suppose the following situation : you have address book search and LDAP search
enabled. "[e-mail]" is in our LDAP directory (but not in our address
books). Local domain is scort.com.

I type "de" : address completion proposes two possibilities : "[e-mail]" and
"(LDAP) John Delly <[e-mail]>". But if you use RETURN or TAB,
autocomplete uses [e-mail].

Please note that if you DISABLE address book search, autocomplete correctly uses
 the LDAP match rather than the localhost autocomplete !!

Something must be wrong in the search priorities, but I don't think anyone would
prefer a localhost autocomplete over an LDAP match autocomplete.

Comment 31

[Ninoschka Baca]

Reopening for a problem with an Exact Match scenario with an LDAP entry.

Scenarios (1-4) listed by jglick on 9/6/2001 are working with the exception of
what Thierry Carrez reports on 9/24/2001. If there as an exact match on an LDAP
directory then autocomplete displays:

- [e-mail] (highlighted)
- John Delly <[e-mail]> (LDAP entry which is the exact match)

Press Enter/Return and [e-mail] is selected instead of the LDAP entry.
Interesting that if an exact match is found in a local address book then it
works as expected...it only shows the exact match.

Comment 32

[Scott MacGregor]

please file the ldap issue under a new bug for the next release. It should
probably go to the ldap auto complete folks.

Comment 33

[Thierry Carrez]

New LDAP issue filed as new bug 101498.

Comment 34

[Ninoschka Baca]

Verified Fixed.

Comment 35

[Ninoschka Baca]

Reopening since this still needs to be checked on the trun.

Comment 36

[Ninoschka Baca]

Marking Fixed, adding "vtrunk" to keyword so it is verified on the trunk as well.

Comment 37

[Ninoschka Baca]

Trunk build 2001-11-09: WinMe, Linux RH 7.1, Mac 9.1
All four scenarios are working as expected.