Need UI hint in record pane for LDAP directories



MailNews: Address Book & Contacts
16 years ago
6 years ago


(Reporter: kmurray1115, Unassigned)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [adt3][ue3])



16 years ago
Not sure if this is the way we did it in 4.x, but if you are in the Address Book
and select an LDAP directory in the directory/AB pane, the records pane should
display something to give the user the hint that they need to (in the case of an
LDAP directory) type in some search terms in the quick search field. The reason
this becomes important is due to the fact that we auto load local address books
when they are selected in the directory pane, but it's obviously not prudent to
do so for large directories.

We may want to include some text in the record pane such as:
"Type a search term to display records in this directory"

(This is obviously not the correct wording.)

The wording does not need to apply to local address books either, as we will
always go ahead and load the local records and not need to display the text hint.

Comment 1

16 years ago
I agree this is a good idea. 4.x didn't display anything (just blank).

Robin, can you suggest appropriate wording?

"Enter a name or email address in the text field above."

Comment 2

16 years ago
This is a great suggestion. Suggested text: "To search for matching entries,
type a name or email address in the field above."

Comment 3

16 years ago
Much better. :-)


16 years ago
Blocks: 156960


16 years ago
Keywords: nsbeta1
Whiteboard: [ue3]


16 years ago
QA Contact: nbaca → gchan

Comment 4

16 years ago
Mail triage team: nsbeta1+/adt3
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [ue3] → [adt3][ue3]

Comment 5

16 years ago
Assignee: racham → shliang


15 years ago
Target Milestone: --- → mozilla1.4beta
Product: Browser → Seamonkey
Assignee: shliang → mail
QA Contact: grylchan → addressbook
Target Milestone: mozilla1.4beta → ---

Comment 6

9 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 7

9 years ago
This still happen in Thunderbird 3 RC2 (Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv: Gecko/20091130 Thunderbird/3.0) and in Thunderbird (20090812).

SeaMonkey 2.0 Contacts Manager is based in Thunderbird 2 or 3, no?, very probably the problem persists (I cannot tested now in SeaMonkey).

It's possible re-assign the product to 'MailNews Core'?

What is needed to change the state to CONFIRMED?


Bug 523364 related or dupe.


I propose another solution, like in the addon 'Contacts Sidebar' (currently only for TB2,, only works with the sidebar, not with the address book window -but should do the same-), do ever a default search looking for all the contacts until the limit set by the configuration property 'ldap_2.servers.My_LDAP_Server.maxHits' (to avoid performance problems with large directories, and the user can decide the limit in the Directory Properties Window -the UI for this already exists!-), and taking care with the problem of duplicates described in Bug 462792 (it exists a temporary unconfirmed fix, see Comment#11 by Hunter Perrin, that clear the previously results before do a new search).
You need to log in before you can comment on or make changes to this bug.