autocomplete multiple addresses on the same address line here are the steps to reproduce the scenario where this fix would come in handy: 1) start composing a new mesage 2) type in "s", autocomplete to "Seth Spitzer <sspitzer@mozilla.com>" 3) hit return 4) click on the first line, put a "," and start typing "s" again. expected results: second "s" after the "," autocompletes to "Seth Spitzer <sspitzer@mozilla.com>" actual results: entire line turns red (as in there is no autocomplete result).

The implementer of this feature may wish to consider the discussion of details at bug 395606.

I think this would be good to do. Most web mails even manage autocomplete several addresses on a row. Our current addressing widget is a bit old fashioned, and I'm not surprised if many new users find it confusing to have to have every address on a row of it's own. (Or that's what the UI implies, comma separating them works fine if one try of course.) A multi row text area for the addresses would be nice too (if not implied by the above).

Xref 479997

I've noticed major a difference in behavior between the 2.0 and 3.0 versions: - On current 2.0 releases, you can enter multiple addresses "ab,cd,ef" into a single line; they will turn red and don't autocomplete right away, but when hitting Enter they *do* autocomplete with each entry on a single line. - With 3.0 builds, entering "ab,cd,ef" won't autocomplete them either and turns the line to red, when hitting Enter they expand onto one line each *but* will stay red and do *not* autocomplete. This may be a separate regression but seems to fit into the scope of this bug.

I've split off comment #7 as bug 528503 per feedback from Wayne.

Started a crowdfunding campaign for this: http://www.freedomsponsors.org/core/issue/144/autocomplete-multiple-addresses-on-the-same-address-line

Note that bug 528503 is similar, but not a duplicate (different steps, different per comment 7, comment 8).

Actually, I'm not sure how this bug and bug 528503 would interact, they might be incompatible. I have doubts on bug 528503 unless it's full match for unique nicks.

Autocompletion of comma-separated addresses starts getting ignored here (starting point in code): http://mxr.mozilla.org/comm-central/source/mailnews/addrbook/src/nsAbAutoCompleteSearch.js#351

That was apparently introduced with bug 370306 attachment 325961 [details] [diff] [review] but checked in on 2008-06-20, thus quite a bit *after* the bug here was filed. Were you thinking of bug 528503 rather as the likely regression of that patch?

(In reply to rsx11m from comment #17) > That was apparently introduced with bug 370306 attachment 325961 [details] [diff] [review] > [details] [diff] [review] but checked in on 2008-06-20, thus quite a bit > *after* the bug here was filed. Were you thinking of bug 528503 rather as > the likely regression of that patch? Just saw the ignore-comma stuff and wanted to dump a reference as a starting point in code. If that particular code causes this bug or bug 528503, I don't know.

A test would be to verify in 3.0b1 vs. 3.0b2; if that's the regression range we'd have a possible candidate for either bug.

This is very useful. The current behavior is quite annoying. When I input the second address starting with a comma, the first one turns red, and there is no auto-completion anymore. Is there any development on this issue? Or a workaround?

I searched for and found this bug after experiencing the slow autocomplete bug 1151520, posting comments there, and receiving suggestions that I find a better forum for comma-separated list complaints. After some searching, this bug seems to be a spot-on match, or at least the oldest report of comma delimited list problems that I've been able to find. If I had discovered this report earlier, I wouldn't have wasted time finding that comma delimited lists were last working reasonably in versions 2.x. I'm cross-referencing bug 1151520 here as it seems likely that that bug and perhaps quite a few others would not exist absent this 9 year old regression. It turns out that I noticed regression 1151520 before I noticed this regression. In my defense, though, I think my failure is due to my switch to Thunderbird from Microsoft Outlook that took place after this regression occurred. I think that I just stopped using comma, or semicolon, separated lists once I discovered that Thunderbird did not support them. My guess is that I assumed then that Thunderbird had never supported delimited lists and just accepted the limitation because of various more painful Microsoft limitations. One last item of note is that it seems from the age of this regression that Thunderbird is not being as actively maintained as I had thought. My mental model was that as an official Mozilla project, Thunderbird would have at least several semi-professional/expert-amateur maintainers. My feeling now is that that is not the case and perhaps Thunderbird maintenance is now largely up to the coding-skilled portion of the user base. Sort of the "if I want this fixed, I'll do it myself mentality". So is that the case, does Thunderbird welcome user generated patches?

(In reply to Paul Ausbeck from comment #21) > One last item of note is that it seems from the age of this regression that > Thunderbird is not being as actively maintained as I had thought. I believe this is a new feature request, not a regression. Regardless I wouldn't necessarily relate how long bugs have been open with how maintained the product is. There might be many reasons a bug has been open a long time (e.g. it's a hard bug to fix, it's a feature that isn't used often, etc.). > My mental > model was that as an official Mozilla project, Thunderbird would have at > least several semi-professional/expert-amateur maintainers. My feeling now > is that that is not the case and perhaps Thunderbird maintenance is now > largely up to the coding-skilled portion of the user base. I don't believe you mean it this way, but this could be seen as belittling the current volunteers who are helping to maintain Thunderbird. Many of us *are* professional software engineers (or in related fields). Thunderbird does *not* received any direct support from Mozilla anymore, however, so all work is done by volunteers. > Sort of the "if I > want this fixed, I'll do it myself mentality". So is that the case, does > Thunderbird welcome user generated patches? Of course! Thunderbird has always accepted user generated patches, this is the spirit of open source!

(In reply to Patrick Cloke [:clokep] from comment #22) > (In reply to Paul Ausbeck from comment #21) >> My mental >> model was that as an official Mozilla project, Thunderbird would have at >> least several semi-professional/expert-amateur maintainers. My feeling now >> is that that is not the case and perhaps Thunderbird maintenance is now >> largely up to the coding-skilled portion of the user base. > I don't believe you mean it this way, I don't it was meant that way either, it was more just said without having a good grasp of the history involved. > Thunderbird does *not* received any direct support from Mozilla anymore, Depends on what you mean by 'direct support' I guess. If you mean actual programming/coding of strictly Thunderbird bugs/features, then yeah, sadly, it hasn't, and not for a long time now - many years if I'm not mistaken. > however, so all work is done by volunteers. But Thunderbird does still get substantial support from Mozilla in the way of infrastructure support, and that is much appreciated. >> So is that the case, does Thunderbird welcome user generated patches? > Of course! Thunderbird has always accepted user generated patches, this is > the spirit of open source! And I'd add, in Thunderbird's case, is the difference between life or death! ;)

I want to apologize for my previous wording. As was subsequently commented, I did not, do not, have a good grasp of the history.

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #16) > Autocompletion of comma-separated addresses starts getting ignored here > (starting point in code): > > http://mxr.mozilla.org/comm-central/source/mailnews/addrbook/src/ > nsAbAutoCompleteSearch.js#351 Indeed when reading the code, it is explicitly documented: // If the search string isn't value, or contains a comma, or the user + // hasn't enabled autocomplete, then just return no matches / or the + // result ignored. + // The comma check is so that we don't autocomplete against the user + // entering multiple addresses. Is there a rationale why we don't autocomplete when a comma is typed. I can think of some programmatic reasons, but I don't know quite enough to say definitively. And if for a architectural reason (the way we sort and iterate through arrays, for example), we cannot autocomplete, I would say what we do instead is confusing. Because we actually mark the addresses as misspelled, which is unfortunate. It would be better just to convert this to a tab/new line if we cannot fix what is clearly a regression, and not an rfe.

I think MRC compose bringks a solution: https://addons.mozilla.org/en-US/thunderbird/addon/mrc-compose/ A discussion is ongoing here about a similar topic: https://bugzilla.mozilla.org/show_bug.cgi?id=440377