RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Description of problem:
evolution UI blocks for several seconds after the at sign '@' is typed for the first time into recipients fields of new message.

I've got two auto-completion "accounts" set up: caldav and ldap. I tried to disable one of them at time but no apparent change of behaviour happened so I can't tell if any of them is the culprit or if the behaviour is reproducible regardless of the account type.

Version-Release number of selected component (if applicable):
evolution-2.32.3-1.el6.x86_64

How reproducible:
always

Steps to Reproduce:
1. have auto-completion configured
2. type an email address fluently
3.

Actual results:
once you type '@' character, evo UI stops responding for a while for few seconds, if you continue typing without feedback, few shorter blocks will follow.
All the characters entered while the UI doesn't respond will be printed once the UI starts responding again.

Expected results:
Evolution UI never blocks, any IO should be performed in a separate thread.
Optimally user should be notified somehow (in this case by appearing of drop-down menu with a spinning wheel)

Additional info:

Created attachment 758179 [details]
evolution backtrace

Created attachment 758192 [details]
e-addressbook-factory backtrace

It looks that evo blocks on getting information from WebDAV addressbook. If the function names are to be trusted to describe what happens, main thread of evolution is getting synchronously autocompletion data from addressbook from main thread...

I'm moving this to eds, because the issue is there. Evolution only tries to create a new book view, a DBus object, which should be pretty quick, but because of the addressbook factory being stuck and waiting on the end of a previous book view object from the webdav book, it cannot respond. A solution (and a good rule) is to not block factory's UI for a long/unpredictable time.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-1540.html