I don't think there's any good way to support tab autoexpansion on all 
of the various expand_names-created fields at the moment. The whole 
thing is a bit of a mess, though, and it'd be good to clean it up 
further.



I'm going to mark this ticket as resolved since the bug is gone. 
Further enhancements certainly aren't ruled out though.

I'm not dropping addresses anymore.



I'm still a little unclear on what the "right" behavior of Tab Auto 
Expand is.  If I type a unique name, I can tab autoexpand as many 
times as I want in a field.



If I Expand Names, I can use tab autoexpansion in the CC and BCC 
fields, but not in the To field anymore.



So unique name?  Tab autoexpansion continues to work in field.   
Ambiguous name?  It wont' work anymore..  Is that right?

This should be fixed now; please test since I wasn't seeing each 
variant of this. Here's the FRAMEWORK_3 version of the patch:



http://cvs.horde.org/diff.php/imp/compose.php?r1=2.800.2.24&r2=2.800.2.25&ty=u

I see it now too, using a different test case:



1. Enter "won't be found", "unique".

2. Hit Expand Names

3. Watch the nonexistant one disappear.

I can reproduce this.

I am unable to reproduce this with both HEAD and FRAMEWORK_3. Kevin, 
any chance you can try the latest FRAMEWORK_3 code, or alternately get 
me a test account and access to your Horde install?

Also, the wording on the drop-down menu of addresses returned from the 
Expand Names execution has caused more than a few chuckles here (no 
offense to Chuck ;)



Instead of: "Please select or edit right next:", how about "Click to 
select address or edit entry to the right -->".  Wordier, but much 
more clear.  Maybe "Click to select, or modify entry to the right:" ??

Probably exists in HEAD too, since the code for expanding names in 
4.0.3 is a MFH.  For our installation, address expansion is set to 
search our LDAP directory server (name and email) and localsql (name 
and email).



The following general test case should trigger the bug:



1)  Compose a new message.

2)   In the To: field, enter three or more addresses.  Make sure that 
at least two of the entries are unique enough so that they would 
return an email address, and the third is ambigious

3)  Expand Names

4)  Select the ambigous address from the list



The bug is between steps three and four - essentially, one or more of 
the good addresses is lost altogether.



For a specific example:



Compose message.  In To:, enter Unique Name1, Unique Name2, Ambigous.   
Hit Tab, to autoexpand (not strictly necessary but this is the process 
our users are accustomed to).  Click the Expand Names icon.  Either 
Unique Name 1, or Unique Name 2 will expand to an email address, but 
one of the unique names will disappear.  The Ambigous name will 
generate a drop down of all matches.







If in the above test case scenario, you use Unique Name1, Unique 
Name2, Bogus-Name-that-matches-nothing, the resulting error message is 
somewhat confusing.  Instead of returning a message that states 
"Please resolve ambigious or invalid messages", if the # of matching 
addresses is zero, return "No entries were found that match your 
search criteria" or something to that effect.



As an aside, suppose I do the above, and end up with the one good 
address, and a disappeared good address.  I also have a line with my 
Bogus-Name-that-matches-nothing entry.  Suppose I see that I had a 
typo and I change that line to be Good-Name-that-matches-something.  I 
want to tab-auto-expand to expand that name.  I have to first click 
outside the form, then back in the portion of the To: form where the 
previously bad address was and then Tab works.  Do I need to do that 
to reset the tab autoexpansion?  Is it a limitation of 
javascript/forms, or IMP bug?