100608 - [REGRESSION] ldap auto complete fails to show multiple matches when searching through address book first

Status: VERIFIED FIXED

(MailNews Core :: LDAP Integration, defect, P1)

Description

[yulian chang]

20010919 0.9.4 builds on all platforms.

As of 0919 branch builds, aucomplete against polyglot.mcom.com is not working.
It's regression. LDAP autocomplete has been working against polyglot.mcom.com
well through 20010917 0.9.4 builds. 
Back to 20010917 0.9.4 branch builds on all platforms, autocomplete is still
working. The server has no problem!

Settings as following:

Hostname: polyglot.mcom.com
Base DN: o=Airius.com
Port Number: 389

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

Reassigning to srilatha, hoping she's not as completely underwater as I am. 
This is an odd bug, in that I don't think anything LDAP related has yet been
checked into the branch.  Perhaps something prefs related or in the mailnews js?

Comment 2

[Hong Kwon]

This is a regression that must be fixed for the commercial 6.2 release.

Comment 3

[ji]

I think this is a generic problem as I can reproduce with other ldap servers, like
seamonkey.mcom.com, port 389 and base dn: o=mcom.com

Comment 4

[ji]

The one located at polyglot is Directory Server 3.1 and the one located at
seamonkey is Directory Server 4.1.

Comment 5

[yulian chang]

seamonkey.mcom.com works for me on Wins, Linux and MacOS X.

Comment 6

[grega]

marking nsenterprise+

Comment 7

[ji]

After I uncheck "Use Local Address Books" on the Addressing preference window,
both polyglot and seamonkey work for me now.

Comment 8

[Katsuhiko Momoi]

As far as I can tell, non-ASCII LDAP auto-complete has been
broken since sometime between 7/2 and 7/23 on the 0.9.3 trunk.
It was working on 0.9.2 branch. 
So a good guess is that this broke on the 0.9.4 branch when
you moved from 0.9.2ec builds to 0.9.4ec builds -- you just inherited
what was already broken sometime ago on the 0.9.3 trunk.

For example, non-ASCII autocomplete against polyglot does not
work with 9/10/2001 branch build.

> After I uncheck "Use Local Address Books" on the Addressing
> preference window, both polyglot and seamonkey work for me now

But not probably non-ASCII autocomplete.

Comment 9

[Katsuhiko Momoi]

So this bug addresses only the porblem with auto-completion?
And not the non-ASCII autocomplete failure? Maybe ji should file
anothher bug in that case.

Comment 10

[ji]

In my case, non-ASCII auto-complete is working with 09/17 branch build, but not
with today's branch build even with "Use Local Address Book" is unchecked. I'll
file another bug for this.

Comment 11

[ji]

I take back my words, non-ASCII auto-complete is not working with 09/17 branch
build, it only works when typing the pronounciation of username.

Comment 12

[ji]

Below is the steps I used to reproduce the problem when connecting to seamonkey,
which only has ASCII entries:

1. Launch browser with a brand new profile.
2. Select Edit | Preferences, go to Addressing window under Mail and Newsgroup
3. Check on Directory Server and click on Edit Directories, add seamonkey ldap
server with the settings below:
   hostname: seamonkey.mcom.com
   base dn: o=mcom.com
   port: 389
4. Select Tasks | Mail, setup a mail account.
5. Open a new mail compose window.
   In To: field, enter ji, no matching entry comes up.
6. Go back to Addressing preference window, uncheck "Use Local Address Books"
7. Open another mail compose window,
   In To: field, enter ji, a matching like "Xianglan Ji
<[e-mail]>" comes up.

Comment 13

[yulian chang]

This problem is very shaky! My scenario is different from [e-mail]

1. Uncheck Local Address Book
2. and check Directory Server, Polyglot in Prefs|Mail&Newsgroups|Addressing
3. Check Use my global LDAP server preferences for this account in Mail &
Newsgroups Account Settings
4. In New Msg window To: field, 
    enter ji, no matching found.
    enter ji2, matching found: Xianglan Ji <[e-mail]>
    enter sh, all ASCII matching entries are found.
    enter ka, all non-ASCII and ASCII matching entries are found
5. Check Local Address Book in Prefs|Mail&Newsgroups|Addressing
6. in the same Msg window, everything works just fine. all non-ASCII and ASCII
matching entries are found for ji.

Both results from 20010919 branch and trunk builds are consistent.


       

Comment 14

[yulian chang]

With seamonkey.mcom.com, I got the same result as [e-mail]

From the Local Address Book check/uncheck point of view, seems polyglot behaves
opposite to seamonkey.

Comment 15

[Katsuhiko Momoi]

Something in prefrences might be causing differences 
you hear mentioned in this bug report. For exmaple, I 
used the 9/19/2001 Win32 0.9.4 branch build with 2 
different profiles with both the PAB and DS search 
options turned on.

With one profile, I got some succes with some of the
entries against seamonkey or polyglot DS.

But with another profile, I think I have complete
success in matching against seamonkey or polyglot.

So it seems important to distinguish what profiles
you are using when reporting on this problem.

I have a few questions about preferenecs:

1. In the successful profile, I see something like the
   following as the ldap URL:

user_pref("ldap_2.servers.Seamonkey2.uri",
"ldap://seamonkey.mcom.com:389/o=mcom.com??sub");

but in the one I had a problem with I see:

user_pref("ldap_2.servers.Seamonkey2.uri",
"ldap://seamonkey.mcom.com:389/o=mcom.com??sub?(objectclass=*)");


What difference if any this specificaiton of sub-tree
will make?

2. In some earlier profiles, I see

pref("ldap_2.autoComplete.skipDirectoryIfLocalMatchFound", false);

but in recent builds, the default setting in 
.../defaults/mailnews.js file, the value for the above
is set to "true".

What is correct value when both options are checked off. 
I suspect that it is "false". But then why is the default 
"true"?

Comment 16

[Srilatha Moturi]

I think the cause of this bug is mscott's checkin for  bug 99222. 
The minResultsforpoup is set to 3 when personal addressbook is checked and
to 0 if it is not. 
When personal addressbook is checked and if ldap search returns more than 1 
result everything should be fine, but if it returns only one result that's when 
e do not see any results.

mscott, hewitt, need your help on this.

Comment 17

[Dan Mosedale (:dmosedale, :dmose)]

So here's a test case: assuming you don't have Wolf Blitzer in your personal or
collected addressbook, point your browser to the corporate directory (be sure
that you're using a base DN of dc=com and a scope of subtree).  Then type "Wolf
Blitz" in the address widget.  Nothing will pop up, but a look at the NSPR ldap
autocomplete logs shows that the server did return a match.  What's happening, I
think, is that the local addressbooks autocomplete session is returning the
"default match" of @netscape.com; the LDAP session is returning the match from
the server, and making the total number of results 2.  In the addressing widget
overlay, minResultsForPopup is set to 3.

Comment 18

[Srilatha Moturi]

Reassiging this to mscott since I am not familiar with the autocomplete widget 
code.

Comment 19

[Scott MacGregor]

are we sure we aren't talking about 2 bugs here? Why is it this works for Kat on
one profile but not on another? Why is that on one profile he gets one ldap
search query:

user_pref("ldap_2.servers.Seamonkey2.uri",
"ldap://seamonkey.mcom.com:389/o=mcom.com??sub");

and on another profile he gets a different query:
user_pref("ldap_2.servers.Seamonkey2.uri",
"ldap://seamonkey.mcom.com:389/o=mcom.com??sub?(objectclass=*)");

and the difference means the difference between a working match and a missing match.

Also, according to the original report, the claim is that auto complete for non
ascii characters hasn't been working since July 23rd. 

The change to the auto complete widget to not show a popup if we have only one
exact match was made last week. So clearly that couldn't have caused the
problems with auto complete over non ascii characters.

Comment 20

[Katsuhiko Momoi]

I think I can clarify some of the issues mscott rasied above.

> Why is it this works for Kat on one profile but not on 
> another? Why is that on one profile he gets one ldap 
> search query:

Reading Srilatha's comments above struck a bell. 
My 2 profiles have 2 different sets of Adbook & Collecetd
Adbook entires.

The one that succeeds has many entries -- 56 in PAB and
700 in Collected Address Book. This means if I type in
"j", I get at minimum several results back. This is the
profile I have been using for some time and has many
accumulated AdBook entries.

The other one was created last night just for testing purposes.
It contains only 2 PAB items and maybe 2-3 Collected AdBook
entries. If I type "j", I only get one match from Adbook 
& DS sevrer combined, i.e. just 1 entry from the DS Seamonkey
DS server. This fits the explanation provided above by Srilatha.

> and the difference means the difference between a 
> working match and a missing match.

These 2 ldap URLs may not be the key factors in this
problem. I don't why these 2 types of LDAP URLs exist but
it would be easy enough to check on the 2nd profile by
using larger size Personal Adbook and Collected Adbook
and see if that would solve the problem. If so, the URL
differences would not be relevant for this bug.

> Also, according to the original report, the claim is 
> that auto complete for non ascii characters hasn't 
> been working since July 23rd. 

Right. That is why ji filed a separate Bug 100645, which 
already has a proposed fix.

So this bug should address only one problem, i.e. the
failure of auto-completion under certain circumstances
as mentioned by Srilatha above.

Comment 21

[Srilatha Moturi]

he following two prefs are the same.
user_pref("ldap_2.servers.Seamonkey2.uri",
"ldap://seamonkey.mcom.com:389/o=mcom.com??sub");

user_pref("ldap_2.servers.Seamonkey2.uri",
"ldap://seamonkey.mcom.com:389/o=mcom.com??sub?(objectclass=*)");

since (objectclass=*) is the default filter.

pref("ldap_2.autoComplete.skipDirectoryIfLocalMatchFound", false);
This preference is not being used at all anywhere in the code.  and we do not 
really skip directory if there is a match in the local addressbook.

There is a bug for autocompletion not working for non-ascii characters. 100645 
and there is a fix which i am going to checkin tonight.

Mscott, with today's build, autocompletion did not work if  "Use Local Address 
Books" is checked
I removed the code you checked in my local tree and autocompletion worked.

Comment 22

[Scott MacGregor]

thanks for the explanations everyone. I understand the problem now. Fix coming.
Although I did notice an annoying usability issue with LDAP auto complete. I'll
see if I can fix that too. If you don't have any matches in your address book
but you have one match in your LDAP directory you get the popup with the address
w/ default domain pre selected. *doh*. We should just show the directory match
directly or at the very least that should be the first match selected.

Comment 23

[Scott MacGregor]

Attachment: the fix

Comment 24

[Scott MacGregor]

Since searching over LDAP doesn't automatically insert an addess with the
default domain, if we get 2 or more matches, we should show the popup. In the
local address book search case we wait for 3 or more because we always insert
the default domain so we don't want to show the popup until we have 2 more matches.

This patch hooks into the JS which installs an LDAP session on an auto complete
widget. At that time, tweak the auto complete preference for the minimum # of
results before we show the popup.

Comment 25

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

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

sr=sspitzer

Comment 26

[Joe Hewitt (gone)]

r=hewitt

Comment 27

[Scott MacGregor]

Attachment: reduced patch

Comment 28

[Joe Hewitt (gone)]

Comment on attachment 50219 [details] [diff] [review]
reduced patch

r=hewitt

Comment 29

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

Comment on attachment 50219 [details] [diff] [review]
reduced patch

sr=sspitzer

Comment 30

[Jaime Rodriguez, Jr.]

check it in - PDT+

Comment 31

[Scott MacGregor]

fixed on the branch too.

Comment 32

[yulian chang]

Verified with 20010924 branch builds on Wins, Linux and Mac 9.2