Mozilla Thunderbird

Bug #956618
Comment #23

Comment 23 for bug 956618

Revision history for this message

In Mozilla Bugzilla #325458, Themoz (themoz) wrote on 2009-12-28:

#23

An earlier commenter said they were a Luddite who only recently upgraded to Thunderbird 3. Count me among the same crowd. I had been using a shareware mail client from roughly 2002.

That client allowed me to address an e-mail by typing a comma-delimited list of nicknames into any of the relevant fields (TO, CC, or BCC). Thunderbird also supports parsing a comma-delimited list of email addresses into multiple entries into its addressing user interface.

Expanding on the example above, assume you have nicknames "wil", "jan", and "bob". You should be able to type "wil,jan,bob" to quickly address a mail to all three. When focus leaves the field, the parser should expand each based on a nickname match, resulting in three entries in the addressing user interface.

The current behavior will break apart the comma-delimited list into three entries, but the nicknames will be retained (that is, the user interface will literally say "To: wil", "To: jan", and "To: bob").

It seems the current addressing design in Thunderbird is to attempt to resolve the address you're typing before you leave the current text field. This explains the "(user input) >> (resolution proposal)" user interface gimmick in the text input field.

I think that hitting tab when a proposed resolution is displayed--even if only momentarily or perhaps as an event that fires prior to losing focus--acts as a user selection of the proposed resolution. The trouble is that parsing of a comma-delimited list is apparently executed after that resolution process. The resolution process finds no match for "wil,jan,bob" and therefore assumes that represents the totality of the desired input and passes the value over to the comma-delimited parser.

I consider nicknames to be a special case of address resolution. As the proponents above have said, at the least nicknames should be treated as the #1 priority in finding a matching address. But I would recommend going further: namely, nickname resolution should occur -after- the comma-delimited parsing of the user's input occurs.

An earlier commenter said they were a Luddite who only recently upgraded to Thunderbird 3.  Count me among the same crowd.  I had been using a shareware mail client from roughly 2002.

That client allowed me to address an e-mail by typing a comma-delimited list of nicknames into any of the relevant fields (TO, CC, or BCC).  Thunderbird also supports parsing a comma-delimited list of email addresses into multiple entries into its addressing user interface.

Expanding on the example above, assume you have nicknames "wil", "jan", and "bob".  You should be able to type "wil,jan,bob" to quickly address a mail to all three.  When focus leaves the field, the parser should expand each based on a nickname match, resulting in three entries in the addressing user interface.

It seems the current addressing design in Thunderbird is to attempt to resolve the address you're typing before you leave the current text field.  This explains the "(user input) >> (resolution proposal)" user interface gimmick in the text input field.

I think that hitting tab when a proposed resolution is displayed--even if only momentarily or perhaps as an event that fires prior to losing focus--acts as a user selection of the proposed resolution.  The trouble is that parsing of a comma-delimited list is apparently executed after that resolution process.  The resolution process finds no match for "wil,jan,bob" and therefore assumes that represents the totality of the desired input and passes the value over to the comma-delimited parser.

I consider nicknames to be a special case of address resolution.  As the proponents above have said, at the least nicknames should be treated as the #1 priority in finding a matching address.  But I would recommend going further: namely, nickname resolution should occur -after- the comma-delimited parsing of the user's input occurs.