Changes have been made in Git (master):

commit e4c6ee8061723eba23d61809b9f975bed813aafc
Author: Michael J Rubinsky <mrubinsk@horde.org>
Date:   Thu Jan 26 17:30:14 2012 -0500

     Don't attempt to iterate matches if we don't have any.

     Fixes Bug: 10904

  framework/Core/js/autocomplete.js |   18 ++++++++++--------
  1 files changed, 10 insertions(+), 8 deletions(-)

http://git.horde.org/horde-git/-/commit/e4c6ee8061723eba23d61809b9f975bed813aafc

Changes have been made in Git (refs/heads/develop):

commit e9b27cee7c1a98e44dd07180f3286a2454d54b38
Author: Michael J Rubinsky <mrubinsk@horde.org>
Date:   Thu Jan 26 17:30:14 2012 -0500

     Don't attempt to iterate matches if we don't have any.

     Fixes Bug: 10904

  framework/Core/js/autocomplete.js |   18 ++++++++++--------
  1 files changed, 10 insertions(+), 8 deletions(-)
http://git.horde.org/horde-git/-/commit/e9b27cee7c1a98e44dd07180f3286a2454d54b38

Changes have been made in Git (refs/heads/develop):

commit e4c6ee8061723eba23d61809b9f975bed813aafc
Author: Michael J Rubinsky <mrubinsk@horde.org>
Date:   Thu Jan 26 17:30:14 2012 -0500

     Don't attempt to iterate matches if we don't have any.

     Fixes Bug: 10904

  framework/Core/js/autocomplete.js |   18 ++++++++++--------
  1 files changed, 10 insertions(+), 8 deletions(-)
http://git.horde.org/horde-git/-/commit/e4c6ee8061723eba23d61809b9f975bed813aafc

Changes have been made in Git (refs/heads/master):

commit e9b27cee7c1a98e44dd07180f3286a2454d54b38
Author: Michael J Rubinsky <mrubinsk@horde.org>
Date:   Thu Jan 26 17:30:14 2012 -0500

     Don't attempt to iterate matches if we don't have any.

     Fixes Bug: 10904

  framework/Core/js/autocomplete.js |   18 ++++++++++--------
  1 files changed, 10 insertions(+), 8 deletions(-)
http://git.horde.org/horde-git/-/commit/e9b27cee7c1a98e44dd07180f3286a2454d54b38

Looking at the code though, it looks like the filtering is also done 
elsewhere, at least for the non-ajax case. There is some other stuff 
that doesn't look right also - l can take a look when I get back 
tonight or Wednesday.

IIUC the matching done in that code snippit is to both apply the 
strong styling to the typed search terms (which won't be in the 
displayed text in the case the OP describes) and also to filter the 
choices when we are not using AJAX or the backend doesn't support 
searching.

Mike, is there a reason that we match them one more time against the 
search string? Maybe to work with sources that don't support searching 
but return everything, like the preference backend? Or is this not 
happening anymore anyway?

If Turba is configured to search LDAP attributes that are not a part 
of the displayed contact information, address auto-completion in the 
compose window fails.

For example, if I have Turba configured to search a 'nickname' 
attribute, but the contact string is of the form "Firstname Lastname 
<email@addess>", and I search for text that only exists in the 
nickname, auto-completion will fail. This applies to searches with 
many results, if one of them fits the above criteria. So, if I search 
for 'Bob', and that string is in someone's nickname attribute only 
(their first name is 'Robert'), no auto-completion results will be 
shown at all.

I believe this problem is in horde/js/autocomplete.js starting on line 
119. in the code that highlights the part of each auto-completion 
result that matches the text you've typed so far. If what I've typed 
does not appear in one of the elements in the array 'choices', 
n.match(re) returns nothing, and calling each() on it on line 123 
results in an error. If I change the code to use an empty array when 
n.match(re) fails, auto-completion works as I would expect:

-                n.match(re).each(function(m) {
+                var matches = n.match(re);
+
+                if (matches == null) {
+                        matches = new Array();
+                }
+
+                matches.each(function(m) {