Thunderbird hangs for 10secs when auto-completing address

[Christian González]

Binary package hint: mozilla-thunderbird

This bug seems to be very old, but somehow I didn't find it in Launchpad - forgive me if it's a dupe.

When composing a new mail, I start typing a few letters into the address bar of the Thunderbird composer windows, and TB tries to autocomplete it from the address book.
The drop-down menu appears, giving me the possibilities that start with the letters I typed, BUT - Thunderbird hangs (compiz darkens the window) for approx. 10 seconds - then it gets itself up again and processes complete normally, no errors, no wrong behaviour - and the address book searches are correct.

First I thought it was the prefs.js, see
http://kb.mozillazine.org/Long_time_to_open_address_book

Funny thing is, that I NEVER had used Thunderbird 1.5 before - but I had about 50 lines with that "nonascii" in it.
I deleted them, and gone was the problem, for a few days.
TB worked normally.

Then the problem reoccurred.
Now my prefs.js is clean, and it still has the problem.
It might have something to do with LDAP search as well - I first thought it has to do with that: I have a LDAP server on a openVPN network which is not always connected - and I thought the delay was a network timeout when TB searches for the LDAP and doesn't find it.
But I now disabled the LDAP address search in Thunderbird, and the problem remains.

Also see here:
http://forums.mozillazine.org/viewtopic.php?f=39&t=499016&p=2648760

[Zug-treno (zug-treno)]

Related to Core bug 259095?

[Rmeden (rmeden)]

nope.. that bug refers to specifying a search order for multiple address books.

This is about treating an inaccessable LDAP server as offline.

[Imipak-gmail (imipak-gmail)]

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2) Gecko/20070220 Firefox/2.0.0.2
Build Identifier:

Thunderbird freezes for 30 seconds, presumably doing lookups for auto-complete against Active Directory, whenever I type unrecognised names in the message recipient text box. Names that have been used before do not cause the freeze. This is having a major effect on usability.

Reproducible: Always

Steps to Reproduce:
1. Configure LDAP to point at Active Directory LDAP server
2. Start composing a new email
3. Type recipient name that has not been previously seen by T'bird, causing a lookup against the configured LDAP directory

Actual Results:
Thunderbird freezes for 20-30-40 seconds.

Expected Results:
Name auto-completes whilst you are typing. (Name lookups in MS Outlook are much, much, much quicker.)

I'm using Linux (Mandriva 2007); I haven't checked whether the Windows version behaves the same way.

[Standard8 (mbanner)]

Just to be clear: have you checked if the delay happens when you TB is configured not to use the LDAP directory for autocomplete?

What happens if you go into the address book and do a quick search on the LDAP directory there - is that still slow?

[Imipak-gmail (imipak-gmail)]

Just to confirm that the same version of Thunderbird (1.5.0.10), on the same physical machine, works as expected when I reboot it into Windows.

Mark: No, I haven't tested either of those scenarios - I'll follow-up tomorrow when I'm back in the office.

I should probably have mentioned the version as well: Version 1.5.0.10 (20070221)

I'm somewhat surprised that there's not already a bug filed on this, as I don't remember it ever working properly under Linux - I'd put it down to quirks of our AD, were it not fine under Windows.

[Standard8 (mbanner)]

Possibly related to bug 202858

[Imipak-gmail (imipak-gmail)]

I have tested the scenarios in comment #1:

- when TB is not configured to use LDAP (turned off in the global prefs), local
  searches are fine - no freeze.

- when searching against the AD in Addressbook, there's no UI freeze - there's a short (~1 second) delay then results fill the page (I searched for 'test', and it turns out we have a lot of entities with that in their name in our AD.)

- I also tested using the 'contacts' pane in a compose window; there's no freeze, but I'm not getting results back from the search either.

[Standard8 (mbanner)]

Could you try a Thunderbird 2.0 beta 2 (or rc build if its out yet) and turn on LDAP logging as detailed below:

http://wiki.mozilla.org/MailNews:LDAP_Address_Books#LDAP_Logging

I can't remember if the logging includes timestamps off hand, but it'd be useful if you could attach a log and (if its possible) point out the bit where it is hanging.

[F-hcaley (f-hcaley)]

I am having the same or similar problems with Thunderbird 1.5.0.10 as provided with Fedora Core 6. If I try to use my local AD server for address autocompletion it hangs tbird for about 30 seconds, and never returns anything(moving the composition window during this time smears the window across the main tbird window). If I open the Address Book it works sometimes, but sometimes that hangs too. This doesn't happen if I autocomplete against an OpenLdap server. It doesn't happen on Thunderbird 1.5.0 on Windows against the same AD server.

[F-hcaley (f-hcaley)]

Same LDAP options and credentials on both Windows and Linux, of course.

[Standard8 (mbanner)]

(In reply to comment #6)
> I am having the same or similar problems with Thunderbird 1.5.0.10 as provided
> with Fedora Core 6.

Well it looks like there is a problem, any chance you could try what I suggested in comment 5? Without that (at a minimum) I'm not going to be easily able to reproduce/resolve this issue as I don't have an AD server to play about with.

[F-hcaley (f-hcaley)]

I tried setting the ldap logging variables and running thunderbird 2.0b2. A log file gets created, but nothing ever gets written to it, whether I use address completion or open the Address Book and query the LDAP directories from there.

export NSPR_LOG_MODULES=protocol:5
export NSPR_LOG_FILE=/tmp/ldap.log

./thunderbird &

ldap.log is created, but nothing is written to it.

[Standard8 (mbanner)]

(In reply to comment #9)
> export NSPR_LOG_MODULES=protocol:5

Thanks for trying, that line should be:

export NSPR_LOG_MODULES=ldap:5

Hopefully, that'll get the log working.

[F-hcaley (f-hcaley)]

Created attachment 260626
LDAP log when doing an autocompletion and an address book query to AD

LDAP log from Thunderbird 2.0b2 doing address autocompletion and address book query to an Active Directory server

[F-hcaley (f-hcaley)]

D'oh! Ok, LDAP log now attached.

[Standard8 (mbanner)]

Any chance you could do that without NSPR_LOG_FILE set and tell us between which lines it hangs?

Do you normally enter a password for this connection?

[F-hcaley (f-hcaley)]

Hangs here:
[hughc@joss thunderbird]$ ./thunderbird
158223248[afa57d8]: nsLDAPConnection::Run() entered
2624496[a2caeb0]: nsLDAPOperation::SimpleBind(): called; bindName = 'R&DSERV1\hughc';
2624496[a2caeb0]: pending operation added; total pending operations now = 1
158223248[afa57d8]: pending operation removed; total pending operations now = 0
2624496[a2caeb0]: nsLDAPOperation::SearchExt(): called with aBaseDn = 'dc=hq,dc=aldon,dc=com'; aFilter = '(|(cn=murr**)(mail=murr**)(sn=murr**))', aAttrCounts = 2, aSizeLimit = 100
2624496[a2caeb0]: pending operation added; total pending operations now = 1

[Standard8 (mbanner)]

(In reply to comment #14)
> Hangs here:
> [hughc@joss thunderbird]$ ./thunderbird
> 158223248[afa57d8]: nsLDAPConnection::Run() entered
> 2624496[a2caeb0]: nsLDAPOperation::SimpleBind(): called; bindName =
> 'R&DSERV1\hughc';

Are you sure your bindName is correct, I'd have expected it more along the lines of 'cn=xyz,dc=hq,dc=aldon,dc=com'

[F-hcaley (f-hcaley)]

yes, the bindName is correct. It's a legacy thing, but I think that is not relevant. As I mentioned above, the identical credentials work fine on the Windows version of Thunderbird.

[Huub-n (huub-n)]

I am currently having a 30-sec freeze using 2RC1 (20070326) under Windows, but I am experiencing it because my LDAP server is down. It doesn't matter whether the address is in my local address book or not.

[F-hcaley (f-hcaley)]

There's actually a very similar problem with Evolution when accessing an AD server over LDAP:

http://bugzilla.gnome.org/show_bug.cgi?id=368877

Could both projects be hitting a problem with AD's LDAP implementation?

[9v-boris (9v-boris)]

From a user interface perspective it is most annoying that the LDAP lookup is not asynchronous in relation to the rest of the application. Is there a chance that we see a re-entrant address-lookup (meaning that the user can type in a list of names, and can choose afterwards to select the best match? The message wouldn't be sent until all conflicts are resolved, but the user can work in her/his own pace...
Alternatively would it be possible to cache the LDAP information for the addressbook?

[Gary-rumblingedge (gary-rumblingedge)]

Reporter(s), does this issue still occur in the latest supported 2.0.0.14 / trunk nightlies?

[Christian González (droetker)]

Binary package hint: mozilla-thunderbird

This bug seems to be very old, but somehow I didn't find it in Launchpad - forgive me if it's a dupe.

When composing a new mail, I start typing a few letters into the address bar of the Thunderbird composer windows, and TB tries to autocomplete it from the address book.
The drop-down menu appears, giving me the possibilities that start with the letters I typed, BUT - Thunderbird hangs (compiz darkens the window) for approx. 10 seconds - then it gets itself up again and processes complete normally, no errors, no wrong behaviour - and the address book searches are correct.

First I thought it was the prefs.js, see
http://kb.mozillazine.org/Long_time_to_open_address_book

Funny thing is, that I NEVER had used Thunderbird 1.5 before - but I had about 50 lines with that "nonascii" in it.
I deleted them, and gone was the problem, for a few days.
TB worked normally.

Then the problem reoccurred.
Now my prefs.js is clean, and it still has the problem.
It might have something to do with LDAP search as well - I first thought it has to do with that: I have a LDAP server on a openVPN network which is not always connected - and I thought the delay was a network timeout when TB searches for the LDAP and doesn't find it.
But I now disabled the LDAP address search in Thunderbird, and the problem remains.

Also see here:
http://forums.mozillazine.org/viewtopic.php?f=39&t=499016&p=2648760

[Christian González (droetker)]

I just checked another thing (because I just braught myself to thsi idea) - I not only DISabled the LDAP search in Edit/Preferences/Composition/Addressing - I clicked on "Edit Directories" and deleted the LDAP server out of the config, then disabled LDAP search.

voilla, It workes normal.

This definitely must have something to do with ldap.

[Mephinet (mephinet)]

Hi,
having the same issue, I turned on LDAP debugging and compared the output of
the LDAP query in the compose-mail window to the one in the addressbook.
It looks to me as if the asterisks are misplaced in the former:

compose-mail window:
nsLDAPOperation::SearchExt(): called with aBaseDn = 'DC=lan,DC=apa,DC=at'; aFilter = '(|(cn=patric**)(mail=patric**)(sn=patric**))', aAttrCounts = 2, aSizeLimit = 1000

address book:
nsLDAPOperation::SearchExt(): called with aBaseDn = 'DC=lan,DC=apa,DC=at'; aFilter = '(|(mail=*patricia*)(cn=*patricia*)(givenName=*patricia*)(sn=*patricia*))', aAttrCounts = 64, aSizeLimit = 1000

I don't expect the double-asterisks to be here intentionally, right?
Tested with version 2.0.0.19

[Mephinet (mephinet)]

Digging through MsgComposeCommands.js, I found that the filter string can be customized by setting ldap_2.servers.<NAME>.autoComplete.filterTemplate.
I set it to (|(cn=*%v1*)(mail=*%v1*)(sn=*%v1*)),
now the query is equivalent to the one executed by the address book - but the widget still hangs.
So the double asterisk is not to blame for this behavior.

[Mephinet (mephinet)]

While not solving the underlying issue, this might be a good place to document the work-around, as mentioned in <http://exain.wordpress.com/2008/07/29/thunderbird-active-directory-ldap-lookups-hang-issues/>:
Instead of the standard port 389, specify port 3268, and the freezing is gone.

Successfully tested with Thunderbird 2.0.0.19 on Gentoo Linux against AD on MS Windows Server 2003.

[Micah Gersten (micahg)]

Confirmed in 2.0.0.21.

[Steve Romanow (slestak989)]

Same issue with all ubuntu 9.04 machines I have tried in my office. Same office, winxp tbird does not have this delay, so it appears to be sth with the linux implementation.

On the machine I use most often, 64bit 9.04, 4G or ram. Tbird 2.0.0.23.

LDAP address book is coming from win2k domain controller that is local to this subnet.

This pause is more than 10 seconds in my experience, I see about 30 second delay before I get tbird back.

I have tried adjusting the number of results filter on the advanced tab of Directory Server Properties in TB with no effect.

I see this problem in 3 instances:

1) When I type in the To: field an address that is not present in the LDAP dir, at some point, it will stop accepting input and freeze.
2) When I type in teh To: fiald an address that gets say 4 hits based on the partial string, if I press Tab to go down the list to the 3rd, or use the mouse to select the third, it will freeze.
3) When I choose Compose, Contacts (and get a sidebar address book) and type in the Search For field. If I make a typo and try to backspace, it will freeze. If I do not press backspace and press the blue X to clear the field, no freeze. If I spell the partial name correctly, then I can double click a selection with no freeze.

[Steve Romanow (slestak989)]

As a test, I installed TB 2.0.0.23 on my Crunchbang Linux netbook.

Similar results, strangely, the pause was not as long.

My desktop is a core2 duo with 4G or ram. the Netbook is a Dell mini9 with 2G of ram.

To trip it up on the netbook I did the following:

In the contact search box, enter Der, got two hits on ldap, backspaced once (removing the r) and then received 10 second hang where Tbird was unresponsive.

I wondered if this may be related to my use of Likewise open.

My desktop does use Likewise Open, however, my netbook does not.

[Mander (arwintcher)]

I am experiencing this problem too. As far as I can recall it has only just started in the last few days. Usually when it locks up, the entire system becomes unresponsive for several seconds.

I have tried disabling the LDAP server (a university network, so nearly always on) and it made no difference.

This is Thunderbird 2.0.0.23, whatever is in the Ubuntu Jaunty repository, on a 64 bit system. I have a lot of extensions but no new ones in months.

[Christian González (droetker)]

@Mander did you just "disable" LDAP, or deleted your LDAP servers out of your configuration and then disabled LDAP?
First makes no difference here, the second is a "workaround", the bug does not occur - but I have no LDAP, so no really workaround...

[Steve Romanow (slestak989)]

I have two pcap files saved that show a speedy search hit (with no backspacing), .20 second for the transaction.

the second, in the To field, I typed Step, got a hit on Stephen (which filled in to the field.). I hit backspace 4 files, and got the pause.

In the pcap, at mark .04, the ldap search came back with 4 results for Step...
At mark 30.18 was an ack from the DC
At mark 50.63 is an LDAP abandonRequest

I'm hesitant to post the pcaps (don't really want them in public record on LP) but I will share them with a dev.

[Steve Romanow (slestak989)]

I have included a screenshot of the pcap, I have anonymized my team members personal info.

[Steve Romanow (slestak989)]

Do we want pcaps of communication to the imap server during same time period?

[Steve Romanow (slestak989)]

There is no comm to the imap server until the message is saved or sent.

[Xvolks (marc-denty)]

The behaviour was always here.
I have used the same account for years now and I migrate my account directory from computer to computer.
Before I was under Ubuntu 5.10 to 7.04, then I had to migrate under Windows 2003 Server R2, now I am under Vista64.
If I remember correctly when I migrated from 2003 to vista this issue disappeared some weeks/months, it's now back.

I am in the process of searching an other Mail client, it's too boring...

Here is a sample network process
172.16.0.20 is the LDAP server
172.16.0.121 is my workstation
Thunderbird freeze between packets 12 and 13 regardless of the number of matches found.

10 15.765714 172.16.0.121 172.16.0.20 LDAP searchRequest(23) "dc=gerland2, dc=local" wholeSubtree
11 15.766419 172.16.0.20 172.16.0.121 LDAP searchResRef(23) | searchResRef(23) | searchResRef(23) | searchResDone(23) success [0 results]
12 15.960217 172.16.0.121 172.16.0.20 TCP 15120 > ldap [ACK] Seq=378 Ack=847 Win=16354 Len=0
13 22.025211 172.16.0.121 172.16.0.20 LDAP abandonRequest(23)

--Xvolks

[Nikolay Shopik (shopik)]

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

[Marcus Malcom (malcomm)]

Just an FYI - I just starting having this problem w/ 9.10 (worked perfectly before); however a colleague had this problem w/ previous versions as well.

Aslo, note: I am not having this problem in 3.0. I just upgraded using this method:

http://sourceforge.net/apps/mediawiki/ubuntuzilla

Missing some add-ons, but so far everything is working great.

[Jonas T. (jo-t)]

I can confirm this bug also for Thunderbird 3.0 - on Windows AND on Linux (Ubuntu 9.10, official Mozilla.org Version). This problem seems to be very likely related to LDAP searches at it just disappears if I disable the LDAP directory in TB options.

Its just very annoying, as it happens for EVERY autocompleted mail address - regardless of the autocompletion source (local/ldap).

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

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

[John Vivirito (gnomefreak)]

Can someone seeing this bug look for bug upstream and if you cant find it please file it and drop the link here so we can track it.

[Micah Gersten (micahg)]

This seems to be as good as any bug for this.

[Micah Gersten (micahg)]

Thank you for your bug report. This bug has been reported to the developers of the software.
I'm going to mark it as Triaged and wait for upstream to work on this. Thanks for taking the time to make Ubuntu better! Please report any other issues you may find.

[Bugzilla-standard8 (bugzilla-standard8)]

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

[Nikolay Shopik (shopik)]

Bug 533656 is describing why this happening. probably we should dupe

[Vseerror (vseerror)]

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

[Marty (marty-supine)]

The behavior described so well in Steve in comment 6 (https://bugs.launchpad.net/thunderbird/+bug/320057/comments/6) is still present in 3.1.9pre

I agree this is an upstream issue but the bug being tracked is only a wishlist request for an LDAP option and does not cover the UI freeze that is core complaint of this bug report.

[Euryalus-0 (euryalus-0)]

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

[Vipul Mathur (vipul)]

The workaround suggested in (https://bugzilla.mozilla.org/show_bug.cgi?id=373167#c23) seems to work for me.

Summary: Replace port 389 with port 3268 in the directory settings.

[9v-boris (9v-boris)]

> Instead of the standard port 389, specify port 3268, and the freezing is
> gone.
- Does not really help if LDAP cannot be reached there. It gets faster but does not look up the entries in my case. This is almost equivalent to deleting the LDAP entry itslf. (this is no workaround, but a shutdown of functionality)
Essentially the UI seems to wait for any response from the LDAP before it times out after 10 s, which is a really bad behavior for user interaction.
Whilst not knowing the code there seems to be a major misconception not to allow for asynchronous searches. -Wondering how successful Google would be if their UI would freeze for 10 s every time anything is typed into their search box.

For us it is a major problem especially when using a laptop that cannot reach an existing Server (e.g. outside a firewall) tbird stalls in mid air.

As a result currenty LDAP lookups in tbird have to be considered as broken, if one does not want to avoid tbird altogether.

[Nathaniel W. Turner (nturner)]

I'm seeing this today in the latest Thunderbird in 12.04 (seems to have started happening to me more often in the past few months, but perhaps that's due to some server-side change.)

It seems worth pointing out that when Thunderbird freezes with the address field drop-down displayed, the entire X session becomes unusable (due to the drop down menu having some kind of global focus?) until Thunderbird "thaws". So one cannot even go do something in another app while waiting for Thunderbird when this happens. Everything grinds to a halt.

(Also note that per the upstream bug, the "workaround" referred to in comment #24 apparently just has the effect of turning off LDAP lookups, so it is not in fact a workaround at all.)

[Nathaniel W. Turner (nturner)]

Moz bug 373167 is closer to the real issue here.

[Nathaniel W. Turner (nturner)]

Ugh, ignore the misleading LP hyperlinking in the previous comment --- that's referring to https://bugzilla.mozilla.org/show_bug.cgi?id=373167 not a LP bug.

[Jonas T. (jo-t)]

In reply to #25: I can confirm this problem/behavior -- the entire X session freezes while the TB address drop-down is frozen.

[Ernst Persson (ernstp)]

This issue is still present in Thunderbird 16. Using port 3268 works here so that was a nice workaround.

[Reinaldo (reinaldoc)]

As Ernst says, changing port from 389 to 3268 works.

[Reinaldo (reinaldoc)]

As Ernst says, changing port from 389 to 3268 works.

[Hugh Caley (hcaley-9)]

Still seeing this problem on Thunderbird 24.6.0 on Linux! changing port still seems to work.

[Vseerror (vseerror)]

Also reported by https://support.mozilla.org/en-US/questions/1007335#answer-602690

Does http://guntramblohm.blogspot.com/2012/01/thunderbird-ldap-search-is-very-slow-on.html help?

[Darryl (dmocek)]

I am seeing this issue always with Thunderbird 31.5.0 and elementary OS 0.3 Freya (64-bit). It doesn't matter if I have 'Address Autocompletion' turned on or off (I tried with all combinations...'Local Address Books' on/off, 'Directory Server' on/off). I'm at the point where I have to click in the body of my newly composed email, enter all addresses I want to send to, and copy and paste them into the address lines one by one.

[Darryl (dmocek)]

I am still seeing a big delay when auto-completing (longer then it used to take), but it's when LDAP is on. The issue reported above with seeing a delay with LDAP off turns out to be a configuration error on my part. There are two places to configure LDAP in Thunderbird. One in the account settings and one in Preferences. I had the 'Use a different LDAP server' option selected which means the settings in Preferences are overridden. So LDAP was on even though it was off in Preferences. With LDAP off, auto-completion occurs right away.

[Mark Solaris (a-mark-8)]

Happens in TB 38.2.0
Port 3268 fixes it, we're lucky it's opened to us.

[Npapadonis (npapadonis)]

I upgraded from the latest stable release to Earlybird release v43.0a2 (2015-10-12). I was experiencing the 15 - 20 second hangs with the stable version and can confirm the issue appears resolved with 43.0a2.

Unsure what recent code change resolves the problems. If anyone knows, suggest it be included for backport to a stable release.

[rtnair (rtnair)]

Issue still persists with Earlybird v43.0a2.
OS: Fedora 22

[David Inman (davei)]

In Thunderbird 38.3.0 I saw very long waits accessing a company ldap of several thousand entries.
In short, while composing a message, characters typed were matched against ldap as they were entered.
Using Wireshark to examine the ldap packets, it was determined that the filter used to collect the
matching entries was of the form '*chars*' where 'chars' are those I had typed into the "To:" line of a
new email. There were three such patterns compared against different fields in ldap. The problem lies
in the very inefficient '*' at each pattern's beginning. For normal use of the ldap completion of an email
address this is a waste. The comparison is too general for the application. Of course if it ran fast enough
I wouldn't be as concerned. In my case, however, it takes some 30 seconds of searching per character I type.

The fix was a line like this in my prefs.js file with Tbird shutdown:
    user_pref("ldap_2.servers.<my_server>.autoComplete.filterTemplate", "(|(cn=%v1*)(mail=%v1*)(sn=%v1*))");

where you replace '<my_server>' with your own. Note that '%v1*' was previously '*%v1*' in each case.
You should find your prefs.js under ~/.thunderbird/...

Now the response to each character in the 'To:' line of an email runs much less than a second, and progressively
faster as more characters are entered. All as it should be.

[D-weber (d-weber)]

Issue persists with 45.5.1 on Windows 7 Professional, seems to happen more often since last auto upgrade. I experience a complete freeze of Thunderbird on a regular basis. I am not sure if it would recover after long enough waiting. I've waited maybe a minute. Longer wait times mean it is faster to restart and rewrite my changes since last auto-save. This is effectively a complete freeze, not a performance issue!

[Vseerror (vseerror)]

other ldap problem reports https://mzl.la/2iOLf22

[Nikolay Shopik (shopik)]

Not sure I can help here, didn't use LDAP for while, but I've remember these UI lock when LDAP is slow, its just LDAP thread locking UI.

[Vseerror (vseerror)]

Jan 2019 Dieter reports " during "normal use", the problem occured again. I am not sure what exactly triggers the behavior, but it does seem to still occur. "

[rns (remotenonsense)]

LDAP c-sdk has been removed in bug 1729862. Please file new bug if this is still a problem.