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: email@example.com To: firstname.lastname@example.org To: email@example.com To: firstname.lastname@example.org 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,email@example.com (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).
Interesting. Sounds like a good idea. marking NEW
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Domain auto-completion does not work with delimited address entries on a single address line → Domain auto-complete should work with comma-delimited entries on a single address line
Netscape 4.* worked like this too, I use it all the time. I was surprised that Mozilla didn't implement it.
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.
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: firstname.lastname@example.org email@example.com firstname.lastname@example.org 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 :)
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.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Jean-Francois - how's it coming?
it's wont append until after 1.0
So this is a post-1.0 "feature"?
yes but it hasn't been scheduled yet...
*** Bug 145221 has been marked as a duplicate of this bug. ***
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.
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.
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.
*** Bug 144305 has been marked as a duplicate of this bug. ***
*** Bug 179126 has been marked as a duplicate of this bug. ***
*** Bug 144598 has been marked as a duplicate of this bug. ***
*** Bug 153360 has been marked as a duplicate of this bug. ***
This feature, as described in comment 0, apparently was implemented sometime between Moz 1.6 and 1.7, and is in TB as well.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME
(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.
You need to log in before you can comment on or make changes to this bug.