94540 - Domain auto-complete should work with comma-delimited entries on a single address line

Status: RESOLVED WORKSFORME

Description

[Michael Lee Yohe]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010802
BuildID:    2001080221

If one has to enter six addresses that an email should be delivered to, they
must use much mouse interaction (type address, select second field, type
address, and so on and so forth).  Instead, if I type:

myohe,user1,user2,user3

Mozilla should parse out the addresses into:

To: [e-mail]
To: [e-mail]
To: [e-mail]
To: [e-mail]

This, of course, assumes that user1, user2, and user3's addresses are contained
in the address book.  The behaviour correctly emulates popular email clients
(i.e. Pine, Outlook, etc.) and is a time saver for people who often send mail to
multiple recipients.

Instead, Mozilla treats the field as one big address -

myohe,user1,user2,[e-mail]

(Enh) It would be nice if any single address is not located in the address book,
flag it (highlight it) so that user knows that Mozilla could not match an email
address with the keyword in the field.  This being versus the current appending
of the user's primary domain onto the end of the address.

Reproducible: Always
Steps to Reproduce:
1.  Type in an address (address1)
2.  Type "," (comma)
3.  Type in another address (address2)
4.  Hit [tab] to go to Subject field

Actual Results:  Nothing - address is interpreted as address1,address2@<primary
domain>

Expected Results:  Created two "To:" fields, parsing out the address (comma
delimited) into its natural form (a fully denoted address, pulled from the
address book).

Comment 1

[Christopher Aillon (sabbatical, not receiving bugmail)]

Interesting.  Sounds like a good idea.  marking NEW

Comment 2

[Jo Hermans]

Netscape 4.* worked like this too, I use it all the time. I was surprised that
Mozilla didn't implement it.

Comment 3

[Håkan Waara]

A major flaw in this proposal (albeit it's 4xp-ness) is that the current 
behaviour of autocomplete is that is waits for the user to confirm the action --
 e.g. if you type "Joe", a menu will popup with all the "Joe" matches and 
you'll select one of them -- before actually pasting in the name into the 
recipient textfield.

If you'd type "Joe, John, Peter" with this feature how would this work? You 
can't display three popupmenus at once. Also, you request that the matches 
for "Joe", "John" and "Peter" be inserted into new rows, well you can't do that 
since our autocomplete _waits for the user to confirm the action_ before doing 
anything - which in my opinion is also the expected behaviour.

Maybe you could change your proposal of this feature slightly, because the 
current description simply doesn't match what we *can* or will do with 
autocomplete if we want it to still be usable.

Comment 4

[Michael Lee Yohe]

You state "since our autocomplete _waits for the user to confirm the action_
before doing anything" - this is fine for people who like to click alot.  But
most people don't want to click alot.  Hence, my proposal for which I think I
have given a good example of how it works:

myohe,user1,user2,johndoe expands to:

[e-mail]
[e-mail]
[e-mail]
johndoe (Unknown)

"johndoe" is flagged so that the user knows Mozilla did not properly parse out
the entire string of recipients.  I do not think it's a flaw in the proposal
since the behavior I speak of is generally shared by common, popular email
clients.  Evolution also mimics this behavior.

If it is a problem to adapt this enhancement to the current autocomplete method,
then a configuration option should be added so that users can select the old
click-click-click method, or let Mozilla do the figuring-out-of-things (my
proposal).  The heuristics that Microsoft and Ximian employ seem to cache
frequently-used data in order to determine "Tim" from "Timothy" when "Tim" is
inputted.  A "less-intelligent" method would be to require users to input "Timo"
for Timothy.  If multiple matches are found, Outlook Express/Evolution selects
the most frequently used one (or the first one if none has been selected prior).
 If this isn't corrent - then the user will just have to input more data.

Nonetheless - if you have any more concerns or if I need to better clarify any
ambiguity, just let me know :)

Comment 5

[Eli Rodriguez]

The behavior requested and described by Michael Yohe is the exact way Netscape 
4.7x behaves.  Not having this functionality is preventing me and the rest of 
the company from moving forward with Netscape 6.X or mozilla.  Try it out and 
see if that functionality can be duplicated.  As it is now, it's causing 
frustration with all the clicking one has to do.

Comment 6

[Jean-Francois Ducarroz]

accepting

Comment 7

[Michael Lee Yohe]

Jean-Francois - how's it coming?

Comment 8

[Jean-Francois Ducarroz]

it's wont append until after 1.0

Comment 9

[Michael Lee Yohe]

So this is a post-1.0 "feature"?

Comment 10

[Jean-Francois Ducarroz]

yes but it hasn't been scheduled yet...

Comment 11

[Daniel Veditz [:dveditz]]

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

Comment 12

[Dan LeGate]

I am ONE HUNDRED PERCENT behind this request.

I'm sorry but Håkan Waara's statement that this *can't* be done due to the
nature of it popping up 'with all the "Joe" matches' is strange because
Messenger 4.x behaves exactly this way.  It just stops "offering" suggestions
when the first comma is entered, which is FANTASTIC.  Mozilla's behavior seems
to be a step backwards.

Eli Rodriguez's statement that it will keep his company from moving to
NS6/Mozilla is exactly the same situation at my company, and we are standardized
on Netscape 4.x at our company!  That's an *automatic* 3,000 new users of
Mozilla if this bug is fixed.

I'm VERY surprised this doesn't have more priority as a pre-1.0 feature.

Comment 13

[Eli Rodriguez]

Jean-Francois - How's it coming?  Almost a year's gone by and 1.0 is past and
gone.  I'm itching to change our default browser/messenger across the board to
Mozilla/Netscape 7.X.  So far, I find it does everything we want, except this
one very important part.

Comment 14

[Mike Cowperthwaite]

This bug is virtually the same as bug 94676, except that one is talking about 
semicolon-delimited addresses.  (Commas, incidentally, are legal; semicolons are 
nonstandard.)  Since both bugs are "assigned" I'll let the asignees sort out 
which is a dupe, if either.

Comment 15

[Mike Cowperthwaite]

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

Comment 16

[Mike Cowperthwaite]

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

Comment 17

[Mike Cowperthwaite]

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

Comment 18

[Daniel Wang]

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

Comment 19

[Mike Cowperthwaite]

This feature, as described in comment 0, apparently was implemented sometime 
between Moz 1.6 and 1.7, and is in TB as well.

Comment 20

[Mike Cowperthwaite]

(In reply to comment #19)
> This feature, as described in comment 0, apparently was implemented sometime 
> between Moz 1.6 and 1.7, and is in TB as well.

Altho nobody's complained about this bug's resolution, I should be a little clearer:
As you type, the first address fragment will be autocompleted up until the point a comma is typed.  If the autocomplete actually fills in, typing the comma will erase it; better to type <end> before typing the comma, if the autocompletion provided is the desired one.  If there are multiple matches, using the arrow keys to select one from the list, followed by typing a comma, will accept that entry correctly.

Once the comma is typed, no further autocompletion takes place inline.  After typing Enter or Tab, the addresses are parsed out and each placed in its own address field.  If any of the addresses are partial (no @) that address will be autocompleted with the first valid item in the autocomplete list; this may not be the desired address.