When replying to a mailing list, I have to do replyall (get a compose window with To: sender and CC: list), then delete the sender, then change the list from a cc to a to. The mailer should do that for me, with a reply-to-list command, which would reply to the message's Resent-From header, if any, or its To header, if not. (If there's no Resent-From header, and multiple To headers, then it would probably have to go To all the recipients. Perhaps it should go Cc all the recipients even if there's a Resent-From, and To the Resent-From.) The button could easily be added in JS, and I'd be happy to do that, but getting header information about the current message might be harder (is there any way to do that from JS?) so I'm initially assigning it to JF (expecting it will be a HELPWANTED sort of thing). If you could offer any hints about how to get the header info, it would be much appreciated and I'll try to find time to do the rest.

Moving to future milestone.

Adding helpwanted since it's milestone future.

See http://www.unicom.com/pw/reply-to-harmful.html for some info on this.

Outlook Express for the mac has something similar; it has a Mailing List Manager which allows you to decide what to do with replies to mailing list messages in advance. It's not quite the same thing, but it's very handy.

UI issues w.r.t. offering the user this option are described in bug 17796.

The X-Mailing-List: header also gives details on where to reply to.

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

akk, the reply modes are currently hardcoded in C++ files (at least, they were 2 years ago)- You could just add another mode. The only problem then might be to get the content of an unusal header. As for the actual code, "The way to a messgae" <http://www.bucksch.com/1/projects/mozilla/12306/> might help (the 2 <ul>-<li>s are 2 different ways I found). Maybe, it is of some help. All, another algorithm could be to just "Reply to All Recipients", but not the sender. I.e. send the reply to all in To, cc[, bcc], newsgroups, followup-to, but don't add the contents of From and Sender.

More on why we need this: The one replying currently either has no manually delete the original author from the recipients list or he will annoy him by sending him the same message twice. This is the reason for many mailing lists adding a Reply-To header, which has the other problem that you cannot reply to the original author anymore.

This also wouldn't be a problem if there was a filter action called: change reply-to adress.

Reply-to-list should simply address the reply to the mailing list, as defined in the List-Post field (defined in RFC 2369). http://www.zvon.org/tmRFC/RFC2369/Output/chapter3.html#sub4

Can List-Post: detection be added? There are lots of headers that can be used to solve this problem I believe JG

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

unless you are a driver, you cannot set block (+) flags. you can only request (?) them

<i><blockquote>unless you are a driver, you cannot set block (+) flags. you can only request (?) them</blockquote></i> My apologies, that wasn't clear from the UI. I guess I am now requesting this.

What is the status of this bug? Windows mail clients are really being crippled by the lack of a reply to list button; this is really critical functionality that is missing from most windows clients I've ever run into. Mozilla Thunderbird would do well to implement this, making it one of the few windows clients to catch up with the times. As things stand, mailing lists have been resorting to munging the reply-to header, leading to more limited functionality for all users of mailing lists, even those with more sane mail clients. The argument goes that even though reply-to munging is bad, Windows users don't have appropriate software to deal with it, and we all suffer as a result. If Mozilla Thunderbird were to implement this, the argument that Windows clients can't deal with lists that don't munge reply-to headers will be made moot, and the hundreds of thousands of people that utilize mailing lists stand to benefit. Please revisit this issue!

Also, shouldn't this feature request apply to all hardware on all OSes?

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

Right now we also (in my opinion) botch up replying in Newsgroups as well. Currently, there is no straightforward way to reply only to the poster of a message (you have to hit Reply All, then delete the newsgroup). The Reply button should always reply *only* to the original sender, whether in mail or news. This proposed Reply List button should also act as a Reply Group button for Newsgroups (in the way that Reply currently works). Reply All of course would remain unchanged. This goes for Thunderbird as well of course.

Related forum discussion: http://forums.mozillazine.org/viewtopic.php?t=21703

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

I think David does not describe the correct default behaviour for _news_ _articles_. The default response button (however we label it) for a news article, should always be to honour any "Followup-To:" header present in the article. This can specify followups either via nntp to different newsgroup(s) - usually just one - or via email to the original poster. In the absence of a "Followup-To:" header, "replies" or "followups" should go by default to the original newsgroups. That is how news is "supposed" to work. Anything different may be made readily accessible by different buttons, but should not be the main response suggested by a well-behaved newsreader. What happens if a folder contains a mixture of news articles and email messages (some of which are from mailing lists), is not an easy question to answer... Paul

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

This bug report started five years ago. The lack of a reply-to-list button is and remains the single most annoying misfeature in Thunderbird. Could you please consider upping the priority a bit on this issue?

This is a first draft at providing a solution to this problem. It looks at the headers of the mail being responded to, and if it doesn't see a Mail-Followup-To header (the 'correct' way to achieve Reply To List as I understand it), it checks for a List-Post or X-Mailing-List header. If it finds one, it fakes up a Mail-Followup-To header which is then used as the single recipient when doing a Reply-All. Likewise, in the absence of a Mail-Reply-To header, it tries to second guess based on Reply-To, X-Reply-To, From when doing a straight Reply (think Reply-To-Sender in this instance). If the faked Mail-Followup-To is the same as Reply-To, then a Mail-Reply-To is faked up from X-Reply-To or From respectively. This seems to have the desired effect for most common mailinglist software, at the cost of turning the Reply To and Reply To All buttons silently into Reply To Sender and Reply To List buttons in scenario. I personally think this makes sense, however. This behaviour is enableable through the mailnews.clobber_list_reply preference in user.js.

I like the sound of that. In particular, *not* having yet another "reply" button is a Good Thing, IMO. However, this is perhaps more radical, but maybe you should even assign this list functionality to "Reply" instead of "Reply All"? That would make it symmetric to the newsgroup behaviour, where "Reply" will post to the group, and "Reply All" to the group and the sender of the original newsgroup message (there is no direct way to reply only to the sender, as far as I know.)

(In reply to comment #26) > However, this is perhaps more radical, but maybe you should even assign this > list functionality to "Reply" instead of "Reply All"? I agree with Toralf on this. From "Reply All" you would expect several adressees which is not the case when you are looking for the button to reply simply to the list. Otherwise: NICE GOING, I'm looking forward to having this more intelligent Reply (All) button.

The problem with tying it to the "Reply" button is that you lose the "Reply to poster" functionality which currently exists on lists which don't mangle the Reply-To header but do add a Mail-Followup-To (or other supported) header. Reply-To-All isn't entirely correct either unless you include other addresses in the TO and CC fields, since the message may have been addressed to a mailing list as well as other recipients. I don't think there is any way around a "Reply-to-list" button without losing some current functionality. Whether or not loss of current functionality is acceptable or not is not my decision, but I'm not seeing the issue with another button since the functionality provided is different from any of the current buttons.

(In reply to comment #28) > The problem with tying it to the "Reply" button is that you lose the "Reply to > poster" functionality which currently exists on lists which don't mangle the > Reply-To header but do add a Mail-Followup-To (or other supported) header. The user still can remove the other adresses. As this won't be the majority, we can require that from him.

I'm in favor of having different buttons for different functionality. Reply to list, reply to sender and reply to all are IMO all useful and valid actions. I think providing separate buttons for the three actions does not cause extra confusion; by making clear what the possible actions are, it even decreases possible confusion IMO.

(In reply to comment #30) I fully agree with you.

What's wrong with having a little triangle on the Reply button that displays a pop-up menu with all the different reply options? The menu could contain these options: 1) Reply To All (redundant with the Reply All button, but included for completeness, or for those themes don't have a Reply All button) 2) Reply to "From" 3) Reply to Mailing List. Ok, the wording may not be that great, but it's accurate.

> (In reply to comment #30) > I fully agree with you. Seconded. @32: best would be to build it "as good as possible" and for more people than which will be using it. I.e. not do a "hack" just cos it is not important enough. Nobody will again work on that if it is done now (A comment could be that it is already implemented). So, add the possibility to add another button to the bar (or that another one turns up once you are in a mailinglist-directory). I would not care about three different buttons. If it is only one button (like Timur said) what would be the "default"?

The default behavior of the single button would be the same behavior as the current "Reply" button. That button would have a drop-down menu with all possible reply options. We could then have the ability for the user to add customized buttons. The user could then add his own reply-type or buttons. The default for all skins would be to have a Reply All button.

Matthew, you're touching code shared by TB and SeaMonkey, so losing functionality for the sake of not having a separate button is just bad. Don't do this. You should really consider a separate or menu button.

What is the default? If you are in a newsgroup, the REPLY-Button answers to the newsgroup. I would take that behaviour also for the mailinglist, because most listmembers do not want CCs to their email, because they get the mails from the list. So if you press the Button, you answer to the list ONLY.

(In reply to comment #36) > What is the default? If you are in a newsgroup, the REPLY-Button answers to the > newsgroup. Exactly. To me it makes more sense to have "newsgroup" than "direct email" behaviour for mailing list messages. (In reply to comment #35) > Matthew, you're touching code shared by TB and SeaMonkey So he's also putting this right for the people who prefer using Mozilla Suite. That makes it even better, I think.

(In reply to comment #35) > Matthew, you're touching code shared by TB and SeaMonkey, so losing > functionality for the sake of not having a separate button is just bad. Don't do > this. I'd prefer to think of the patch as providing a workaround for broken mailing list software which neglect to add sensible Mail-Followup-To: and Mail-Reply-To: headers. Whilst it does stand a risk of culling addresses from the cc fields on a Reply-All, it's no different to the behaviour which mailnews _already_exhibits _ when a mailing list mail has Mail-Followup-To: correctly set. That said, when enabled, i am fully aware that it does change the functionality for both TB and SeaMonkey, and so should not be considered lightly. > You should really consider a separate or menu button. Probably. But this is good enough for my purposes right now. As regards whether Reply should become Reply-To-Sender or Reply-To-List on list mails, I guess the confusion stems from whether the term "Reply-To-All" is short for "Reply-To-All-Possible-Email/News-Addresses" or "Reply-To-All-Possible-People". I personally think that "Reply-To-All" means "Reply-To-All-Possible-People", which implies using the email address common to everyone. And that "Reply" means replying to the single original author of the message. Which means that a Reply-To-All for a mailing list which cc's all the possible addresses only ever encourages crossposting and duplication. This is indeed opposite to the behaviour when in newsgroup mode, which is obviously unintuitive. The most flexible solution would unquestionably be to make the Reply button a dropdown to provide the options of Reply-to-Sender or Reply-to-List depending on your preferences (see also bug 17796). Reply-to-All would then keep in cc-all-possible-addresses mode. Unfortunately I no longer have time to attempt a fullblown solution of this (let alone try to push the required UI changes through Thunderbird & SeaMonkey as a relative stranger). Please feel free to either consider the above patch as a minor extension to the existing Mail-Followup-To: behaviour, or ignore it altogether.

I'm not currently using either the suite or t'bird, but as the original reporter maybe I can comment anyway. I wouldn't ever consider using a mailer that didn't give me an option to reply privately, or which required me to edit headers in order to do so. I do private replies a lot, even in mailing lists, and one of the reasons I stopped using mozilla mail was that I wanted a mailer which allowed me to reply privately even on lists that munge reply-to. It makes a lot more sense to leave the Reply button as a private reply, and replace the Reply All button's default functionality with Reply to List (while keeping Reply to All available as another option in the dropdown button), since Reply All is seldom useful on a mailing list. List replies and private replies are both very common cases and they should both be easy to get to. By putting list-reply on the Reply All button, you maintain the usual sense that that button replies to multiple people, while the Reply button replies to only the sender; the user doesn't have to remember context to figure out which button replies to multiple people. (Yes, I know mozilla reverses this for newsgroups, but there are lots of things wrong with how mozilla handles newsgroups).

(In reply to comment #39) > > > It makes a lot more sense to leave the Reply button as a private reply, and > replace the Reply All button's default functionality with Reply to List (while > keeping Reply to All available as another option in the dropdown button), since > Reply All is seldom useful on a mailing list. Yes, I suppose you are right - it is actually less useful than "Reply". In fact, I'm not even sure I see much point in keeping a 3rd option in a dropdown. However, this also implies that Reply must ignore the Reply-To header when it's set to the list address, which I guess you also said. Doing that does does seem wrong in some ways, though... I guess what I was essentially saying when I suggested assigning list behaviour to the normal "Reply", was that we should not only add extra support for list replies, but also make sure the "reply" functionality is exactly the same for all mailing lists. Users shouldn't have to learn different ways of responding for different lists - which they do today since some lists set Reply-To: and some don't. > [ ... ] (Yes, I know mozilla reverses this for newsgroups, > but there are lots of things wrong with how mozilla handles newsgroups). And the behaviour should also be consistent with the one for newsgroups, of course. So I guess the options are: 1. Assign list reply functionality to the Reply button. 2. Replace Reply All with list reply *and* update Reply so that it ignores Reply-To: <list address> *and* update newsgroup interface to have similar "Reply" and group reply. You have now convinced me that 2) is the best of these - but only if all parts of it are implemented. I'd still prefer 1) over a partial implementation of 2)

(In reply to comment #40) I think too that the solution 2) is the best one. Now, the Reply button should only ignore the Reply-To: header if it's the same as the List-Post: header or so (because in this case, the list has modified the Reply-To: header).

Ok, hitting on a few comments here so bear with me. 1: First and foremost the functionality should be configurable at the folder level. All discussion about default behavior is all well and good but allowing the user to change the default to suit their preference is paramount. Folders simply don't have enough configurability as it stands right now. 2: The reply-to-list should be placed on reply and not reply-to-all. This is because one is replying... to the list. Not replying to all but only really the list. As pointed out this mirrors what happens in newsgroups which is what mailing lists most resemble. 3: Reply-to-sender could be made a drop-down. In fact reply should have a drop down with reply-to-sender, reply-to-list and reply-to-all which all do just that regardless of context or the (lack of) presence of other buttons. 4: Shoving said fuctionality onto yet another button is a bad idea. We already have 2 reply buttons. That's valuable screen-estate that shouldn't be cluttered (by default) unless the user does the cluttering. Quite frankly I'd kill to have "delete & next", "delete & previous" and then have delete change to "delete and close" long before another reply button. Reason being is that I delete far more mail than to which I send a reply. Often used options get a button and ideally a shortcut. Less often used options get a drop down. Least used options get a menu item. With that in mind what do I personally do most often on mailing lists? Reply, to the list. Reply, to the sender maybe 1% of the time of Reply, to the list. Reply to all... never. So I'd be more than happy with an overloaded reply button which was reply to sender in the absence of mailing list headers, reply to list with the presence of mailing list headers, allowed me to override the behavior through a drop-down as needed or, in extreme cases, have the folder set to a default behavior and override what the context would dictate. With that I could drop reply-to-all off my button bar, have all the functionality I want in 1 button which did the right thing 99.9% of the time and yet allow me to intelligently correct it the other .1% of the time. That's something that can't be said about shoving it into another button or on the reply-to-all button. ;)

Okay here is my contribution... First of all I would like to see this fix done very soon! Thanks Matthew! Now observe the tooltips (on Win XP) of SM Mail (20050813 build) - "Reply All - Reply to Sender and All Recipients" - that's good. "Reply - Reply to the message". Wow, can you get more ambiguous (w.r.t the present topic) than that? It doesn't say that you reply to the original sender. Just "to the message". AFAI am concerned, I always think of the Reply button as something which sends mail back to the from address (unless there's a separate reply-to address entered by the sender). I think of the Reply All button as something that sends the mail to all those people involved in the mail I received. And "all those people involved" is determined by possibly multiple To addresses and CC addresses as provided by the person who sent the mail I am replying to. So I think that Reply should be renamed Reply Sndr (hey, if "Get Msgs" is okay, then why not "Reply Sndr"?) and Reply All should change itself to Reply List whenever the mail being viewed has a List-Post (or other applicable) header. To provide for the rare case that a posting to a list also has other To headers or CC headers, then a drop-down box ("small triangle button") should be provided so that the user can manually select the original "Reply All" option of the button. A better idea would be to separate the Reply List button altogether. Somebody here complained that that will "take up valuable screen real-estate". Honesty, I have only seven buttons on my toolbar and it takes up less than 50% of my screen width. So I don't think showing a separate Reply List button is really a problem. Maybe allow the user to enable it via preferences, like for the Junk Mail button, Delete button etc. If it is adjudged that the real-estate problem is really there, then another option would be to display the Reply-List button only when the mail has a List-Post (or related) header. This will also draw user attention to the fact that such an option is separately available. But a shortcut for this is really important. At least half of the time I use the keyboard Ctrl+R to reply to mail. Not allowing a shortcut would be a serious handicap and lose us users. In summary my preferences and recommendations are: 1. Rename "Reply" to "Reply Sndr". 2. Add a separate "Reply List" button. If needed to save screen space (for what else I don't understand) then make it disappear when the mail doesn't have the appropriate headers. 3. Give the "Reply List" button a shortcut. Lists should be intelligent and use the RFC specification, not munge headers. Mail clients should be intelligent and use the RFC specification, not force users to manually enter/edit the to/cc field.

(In reply to comment #43) > > > A better idea would be to separate the Reply List button altogether. Somebody > here complained that that will "take up valuable screen real-estate". Honesty, I > have only seven buttons on my toolbar and it takes up less than 50% of my screen > width. Arguably nearly 50% is quite a lot. I want to be able to work with more than one window at a time. But it's not so much about the size as such. A good UI should have quick and direct access to frequently used functionality and nothing else; it shouldn't have buttons for functions that are hardly ever used laying around getting in the way - especially in prominent places like the toolbar. With a working "Reply To List", I wouldn't use reply "Reply All" more than a handful of times every year, if at all, and with such rare, a toolbar button is quite definitely wrong. Again, it would only be in my way 99% of the time. In fact, I think even a dropdown would be a bad idea. Another unncessarily complication, I think.

(In reply to comment #44) > Arguably nearly 50% is quite a lot. I want to be able to work with more than one > window at a time. OK, then my stand-in suggestion of displaying the icon, perhaps pushing Reply All out of the way for that, *only* when there exists a valid list header, still stays. > But it's not so much about the size as such. A good UI should have quick and > direct access to frequently used functionality and nothing else; it shouldn't > have buttons for functions that are hardly ever used laying around getting in > the way - especially in prominent places like the toolbar. With a working "Reply > To List", I wouldn't use reply "Reply All" more than a handful of times every > year, if at all, Ah, so you recommend the removal of Reply All *in toto*, or at least the replacement of Reply All by Reply List when such a header exists? > and with such rare, a toolbar button is quite definitely wrong. You mean, *two* toolbar buttons for Reply All and Reply List is definitely wrong, and only one should exist which automatically switches between the two functions depending on the presence or absence of a header? > Again, it would only be in my way 99% of the time. In fact, I think even a > dropdown would be a bad idea. Another unncessarily complication, I think. Hmm, maybe, but it wouldn't take any real estate. And in the rare cases when a mail has been sent to a list, but not just to a list? Perhaps to many lists? Perhaps to a list and one or more persons? One does need a Reply All for that, but, as you say, it is a rare function and hence doesn't need to be thrown on the toolbar. It *should* *be there*, however, for those who need it.

(In reply to comment #45) Yes. And I mean that as a reply to most of your questions...

(In reply to comment #46) What's the status of this issue? Do you have plans about any implementation? (I'd love to have a reply-to-list :-)

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

Comment on attachment 192713 [details] [diff] [review] Adds mailnews.clobber_list_reply pref to turn Reply All into Reply To List Can this be turned into an extension instead? I'm not too keen on adding a hidden pref to add this somewhat obscure behavior that most users aren't going to know to go set the pref for.

(In reply to comment #49) > (From update of attachment 192713 [details] [diff] [review] [edit]) > Can this be turned into an extension instead? I'm not too keen on adding a > hidden pref to add this somewhat obscure behavior that most users aren't going > to know to go set the pref for. Im not sure, but this is a functionality most other programs have. So obscure behaviour is quite hard. But maybe there is a "better way" (not meant as an insult to anybody) to solve this than with the hidden pref. Would you like it then?

(In reply to comment #49) > (From update of attachment 192713 [details] [diff] [review] [edit]) > Can this be turned into an extension instead? I'm not too keen on adding a > hidden pref to add this somewhat obscure behavior that most users aren't going > to know to go set the pref for. Or it's just a checkbox in the account preferences. If we assume people are used to this behaviour from other MUAs, it can even be turned on by default.

(In reply to comment #51) > (In reply to comment #49) > > (From update of attachment 192713 [details] [diff] [review] [edit] [edit]) > > Can this be turned into an extension instead? I'm not too keen on adding a > > hidden pref to add this somewhat obscure behavior that most users aren't going > > to know to go set the pref for. > > Or it's just a checkbox in the account preferences. If we assume people are > used to this behaviour from other MUAs, it can even be turned on by default. > I fully agree with Hervé. But about the patch, I would prefer to have a new "reply to list" button which would have the behavior described in the comment 25. See comment 30, comment 31 and comment 33.

> I fully agree with Hervé. > But about the patch, I would prefer to have a new "reply to list" button which > would have the behavior described in the comment 25. > See comment 30, comment 31 and comment 33. I've said it before, but I really don't think adding yet another button would be good. I think we should basically have one reply button that just does the right thing in any context; I don't want to have to worry about choosing different buttons for different types of emails. And the right way of replying to a list post, is to reply to the list, IMO. This probably also means that the option, if included at all, should be on by default.

(In reply to comment #53) > I've said it before, but I really don't think adding yet another button would > be good. I think we should basically have one reply button that just does the > right thing in any context; I don't want to have to worry about choosing > different buttons for different types of emails. And the right way of replying > to a list post, is to reply to the list, IMO. > > This probably also means that the option, if included at all, should be on by > default. > In fact, and after some reflection, I prefer like you to have the reply button changing its behavior when a mailing-list is detected, but the only problem is that it removes the possibility to answer only to the sender. So it would be fine to have an additional "private reply" button activated when the reply button doesn't reply to the "from:" address.

I would prefer that this NOT be added to the existing reply button functionality. It's bad user interface design and not intutitive. Power users, and lets face it, power users are the ones that predominately need this feature want control. Either a separate button is required or moving the activation to a preference pane is more desireable than using the existing button to determine the context.

(In reply to comment #55) > I would prefer that this NOT be added to the existing reply button > functionality. It's bad user interface design and not intutitive. Power users, > and lets face it, power users are the ones that predominately need this feature > want control. I disagree. Lots of non-power users subscribe to mailing list. They should be given the opportunity to always reply the correct way using the same button and not having to think about how the headers are set up for the particular list (or non-list message) they are dealing with at one particular time.

(In reply to comment #55 and comment #56) So modifying the behavior of the reply button with an option set by default would be the best way to do it.

In reply to comment #56: Actually most of the lists that require this feature tend to be geek lists, <ie> Debian user etc. Most of the lists that the majority of endusers use, have the reply sent to the list. So it is very much a power user feature. Can you give an example of a list that's non technical that has the reply-to set to the user rather than the list ? I can't think of any offhand, and I'm quite confident you'll find such e-mail lists in the minority. Therefore the premise that it should be in the reply button, rather than a specific button isn't relefvant as far as I'm concerned.

(In reply to comment #58) > Therefore the premise > that it should be in the reply button, rather than a specific button isn't > relefvant as far as I'm concerned. Indeed, this feature would then be enabled for technical people on technical lists. And I think we are the same who ask for this feature. It won't change a thing for common people on common lists.

(In reply to comment #58) > In reply to comment #56: > > Actually most of the lists that require this feature tend to be geek lists, > <ie> Debian user etc. Most of the lists that the majority of endusers use, have > the reply sent to the list. Possibly, but isn't that an actually an argument for changing the normal reply button functionality? That way, we guarantee that Reply on a list post will *always* work the way the users are used to for "most lists" today. Differently put, if most lists will send replies to the list, then it is even more likely that users are confused if they ever come across one that will not. And also that an additional "Reply to List" button will be seen as confusing. It would be a lot better to add a "Private Reply" button as suggested here earlier if extra control is wanted, IMO. This will make sense even for lists that do set Reply-To (it will have to ignore this header, of course.) And by the way, I consider myself a power-user, but I'm not really that interested in "control" - what I want is first and foremost *some* way to send a message response to the list only, without having to type in or remove adresses, but also consistent "reply" functionality for list messages. I really see no other way of providing that than changing the Reply behaviour. (I'm really not that interested in the "private" reply - I consider it an exception, and don't mind so much adding the address by hand in that case.)

(In reply to comment #60) > It would be a lot better to add a "Private Reply" button as suggested here > earlier if extra control is wanted, IMO. This will make sense even for lists > that do set Reply-To (it will have to ignore this header, of course.) Ignoring Reply-To headers aren't the wisest thing to do. I might want to have replies directed towards another adress than the one I'm sending from, that's what the Reply-To is meant for. IMHO lists that tamper with the Reply-To header is somewhat broken. A separate kbd shortcut and/or button for reply-to-list would be the best option for my use.

(In reply to comment #61) > > Ignoring Reply-To headers aren't the wisest thing to do. I might want to have > replies directed towards another adress than the one I'm sending from, that's > what the Reply-To is meant for. IMHO lists that tamper with the Reply-To header > is somewhat broken. Depends on how you see it. A list post is precisely one of the cases where I want replies directed towards another address, and that other address is always the list address. Which means the Reply-To rewrite represents 100% correct use of the header. But maybe the client, not the list handler, ought to do it... Apart from that, a "Private Reply", if implemented, should perhaps not directly ignore Reply-To, but rather search Reply-To, Sender, From... (in that order) until it finds an address different from the list post one.

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

(In reply to comment #4) > Outlook Express for the mac has something similar; it has a Mailing List > Manager > which allows you to decide what to do with replies to mailing list messages in > advance. > > It's not quite the same thing, but it's very handy. > Kmail has an excellent support to lits, I use Thunderbird from Linux & windows w/the same profile in the same Box. This is the only reason to works w/Tunderbird & lists. Too many years (5!) to solve these BUG. MS

This has been driving me crazy for a while, so I've decided to fix it. As described in comment #8, I've implemented another reply mode. After having read over the bug, it's clear that there are enough different, incompatible opinions on how to do the UI that the only sensible thing to do is make this accessible to extensions, so people can pick their favourite of the mutually-exclusive-yet-still-valid options. The only sensible way to do this that I can see is an extra reply mode. In fact, my current patch doesn't even implement any UI; for now, I'm just going to add my personally preferred UI in an extension (I want a third UI button and a separate shortcut key, for the record). So to test this, I guess you should hack up the "MsgReplyToAllMessage" function in mailWindowOverlay.js to do a "msgComposeType.ReplyToList" instead of a "msgComposeType.ReplyAll". Or I'll try to get my extension finished up soon, but I might not have time to get to it until Wednesday. The patch should be straight forward though. A default UI might make sense, as long as extensions can override it, but I wanted to get some comments on what I've got done so far. I also explicitly wanted to avoid any discussions on potential UIs for now - it'd be better to at least get the basic functionality checked in so extensions can play with it, even if Thunderbird doesn't ship with a UI right away. My solution to getting at the content of exotic headers (as hinted in comment #8) is to get rid of the "optimization" that only sent certain headers out to JavaScript unless the "View All Headers" option was set. When I was first trying to do this as a plain extension, it struck me as incredibly annoying that extensions couldn't get at this data. Perhaps I'm just being naive, but IMHO a mail client that's designed to be extensible should be sure to give this sort of data to extensions. Several extensions (Mnenhy, Enigmail, Display Mail Route, Display Mailing List Header, possibly others) have needed this, and have had to hack around it in one way or another; I can only imagine how many people tried to do interesting things and couldn't because the headers were too hard to get to. This is my first Mozilla patch, so even though I tried to get it right, I'm sure there are some obvious braindead things littered through my changes. Feel free to point them out, I won't take offense and I really want to get this fixed right. In particular, I had to change an interface in IDL, and I don't know what other changes that implies. Please bear with me if I did something dumb.

Comment on attachment 213877 [details] [diff] [review] Adds a Reply-To-List reply mode >diff -u -p -r1.84 nsMimeHtmlEmitter.cpp >--- mailnews/mime/emitters/src/nsMimeHtmlEmitter.cpp 16 Sep 2005 15:20:25 -0000 1.84 >+++ mailnews/mime/emitters/src/nsMimeHtmlEmitter.cpp 3 Mar 2006 07:56:32 -0000 >@@ -179,22 +179,6 @@ nsresult nsMimeHtmlDisplayEmitter::Broad > > const char * headerValue = headerInfo->value; > >- // optimization: if we aren't in view all header view mode, we only show a small set of the total # of headers. >- // don't waste time sending those out to the UI since the UI is going to ignore them anyway. >- if (aHeaderMode != VIEW_ALL_HEADERS && (mFormat != nsMimeOutput::nsMimeMessageFilterSniffer)) >- { >- if (nsCRT::strcasecmp("to", headerInfo->name) && nsCRT::strcasecmp("from", headerInfo->name) && >- nsCRT::strcasecmp("cc", headerInfo->name) && nsCRT::strcasecmp("newsgroups", headerInfo->name) && >- nsCRT::strcasecmp("bcc", headerInfo->name) && nsCRT::strcasecmp("followup-to", headerInfo->name) && >- nsCRT::strcasecmp("reply-to", headerInfo->name) && nsCRT::strcasecmp("subject", headerInfo->name) && >- nsCRT::strcasecmp("organization", headerInfo->name) && nsCRT::strcasecmp("user-agent", headerInfo->name) && >- nsCRT::strcasecmp("content-base", headerInfo->name) && nsCRT::strcasecmp("sender", headerInfo->name) && >- nsCRT::strcasecmp("date", headerInfo->name) && nsCRT::strcasecmp("x-mailer", headerInfo->name) && >- nsCRT::strcasecmp("content-type", headerInfo->name) && nsCRT::strcasecmp("message-id", headerInfo->name) && >- nsCRT::strcasecmp("x-newsreader", headerInfo->name) && nsCRT::strcasecmp("x-mimeole", headerInfo->name)) >- continue; >- } >- So what's the reason for this? (Please note that I'm not a authorized person to bless such a patch)

> So what's the reason for this? That code is the reason that the extensions need to hack around the problem of not getting all headers they need.

(In reply to comment #67) > > So what's the reason for this? > That code is the reason that the extensions need to hack around the problem of > not getting all headers they need. But this has to be an extra bug IMHO.

In reply to comment #68: > > > So what's the reason for this? > > That code is the reason that the extensions need to hack around the problem of > > not getting all headers they need. > > But this has to be an extra bug IMHO. I need to do this here so that my extension can get the List-Post header and tell whether the Reply-To-List will work or not. I suppose I could just add the List-Post header to the list of "blessed" headers, but that seems totally hacky. If there's another bug about getting rid of this mis-optimization, then I could send another patch to that bug and make this bug depend on it. It just seemed easier to do it all at once.

Comment on attachment 213877 [details] [diff] [review] Adds a Reply-To-List reply mode Peter, throwing probably lots of useless headers at a UI that is already slow enough (on older machines) is just not the thing to do. The underlying issue of not getting certain headers when not sending all (which I had to work around in Mnenhy, as you already observed) has two obvious solutions: - make the backend listen to more detailed prefs regarding the headers to send (-> that's bug 236954) - provide a scriptable interface for arbitrary header/value pair requests (no bug yet, afaik)

> throwing probably lots of useless headers at a UI that > is already slow enough (on older machines) is just not > the thing to do. When you put it that way, it's hard to argue. Here's a respin of the patch without the controversial header un-hiding. My hacky test method still applies (change ReplyAll to ReplyToList in the JavaScript frontend); it'll be a bit more annoying to write an extension for a proper UI, but I'll just have to deal with that later. At worst I can depend on Mnenhy or Engimail. An official UI could just add List-Post to the list of allowed headers.

A reply to list command should not even be necessary unless it's the default. Every MUA I've used under Linux does this by default, period. Mutt, Sylpheed, Kmail, Evolution..... I've been rather surprised that oh-so-progressive Mozilla has been so behind on this. I'm about to abandon Thunderbird for mailing lists and use a better more "standard" (and mailing list friendly, MUA).

(In reply to comment #18) > *** Bug 144914 has been marked as a duplicate of this bug. *** > Can it be un-marked? It's not quite a duplicate.

Re Comment #70: > - provide a scriptable interface for arbitrary header/value pair requests (no bug yet, afaik) Aah, that's exactly what's needed! It seems crazy to be sending this stuff through the UI just because an extension needs it. When I was trying to look at implementing this bug, I eventually gave up because I couldn't work out how to do that... There are plenty of comments on Bug 236954 that indicate this too. Maybe we should file a new bug?

I was kind of hoping for more comments on my patch, but I'll grant that my current testing procedure is rather lame. So here's my long-promised extension implementing my vision of a possible Reply To List UI. This should make it easier to evaluate the patch. The extension's not perfect - in particular, it only works if you have the preview pane enabled - but it's a start. Other comments welcome.

Also, the extension will only work if you either use the original version of my patch (213877), or install Enigmail or Mnenhy.

(In reply to comment #75) > Created an attachment (id=216290) [edit] > Extension to implement a Reply To List UI Not compatible with 1.5 it says...

(In reply to comment #77) > (In reply to comment #75) > > Created an attachment (id=216290) [edit] > > Extension to implement a Reply To List UI > > Not compatible with 1.5 it says... Er, well, it isn't. Unless you've hacked my patch into your own self-compiled version of 1.5, which I admit I hadn't anticipated. Here's version "0.1.1" (as opposed to the original "0.1"), which will also install on version 1.5. To be clear though, the extension absolutely does not work with stock 1.5, or any version of Thunderbird that hasn't been recompiled with my patch.

Comment on attachment 214144 [details] [diff] [review] Adds a Reply-To-List reply mode, try 2 looks fine - just a style nit: + if (outCString) + { + mMimeConverter->DecodeMimeHeader(outCString, listPost, charset); + } don't need the braces...and should be if (!outCString.IsEmpty())

Here's a hopefully final version, with the aforementioned style fix, as well as most of the comments from the JST auto-review (there's still a few slightly long lines, but they're not out of place and would be uglier to fix than to leave be).

I would really like to use your extension if it was possible to do so with a stock 1.5 and I have enigmail installed. I'm confused though: In one comment, it says that the extension will work either with your patch or with enigmail or mnenhy installed. In another comment, it says this is not possible without your patch. Which one is true? I simply don't have the knowledge/means to compile my own version with your patch (on windows in this particular case though I also use thunderbird on Linux, but the situation is similar except that I would know how to compile a patches 1.5 there). regards, Sven

(In reply to comment #81) > I would really like to use your extension if it was possible to do so with a > stock 1.5 and I have enigmail installed. I'm confused though: > In one comment, it says that the extension will work either with your patch or > with enigmail or mnenhy installed. In another comment, it says this is not > possible without your patch. Which one is true? Sorry for the confusion. The second statement is true. It is not possible to use my extension without applying my patch to Mozilla's C++ code and rebuilding Thunderbird. You also need to use Enigmail or Mnenhy with that patched Thunderbird. The comments that confused you were referring to a particular part of my original patch, which had to be removed. This was what reinstated the requirement for Mnenhy or Enigmail.

last patch checked in, thanks, Peter.

(In reply to comment #83) > last patch checked in, thanks, Peter. On which braunch is that patch ? 1.7 ? Seamonkey ?

Checkin for this bug may have caused a 15% increase in number of allocations on balsa. See bug 333173.

not likely :-) I doubt balsa even exercises this code.

(In reply to comment #84) > > last patch checked in, thanks, Peter. > > On which braunch is that patch ? 1.7 ? Seamonkey ? If I'm reading LXR correctly, this was trunk-only -- won't be useable until TB 3.0 unless someone nominates this patch for the 1.8.1 branch. I'm not sure it matters, tho, since the extension doesn't seem to work even on the trunk. Using TB 3a1-0520, Win2K, the extension installs fine but the Reply To List toolbutton and menu item are not enabled when I select a message with a valid List-Post header. Note: the disabled toolbutton doesn't display as greyed; but when hovered over, it doesn't show a pushbutton border like the other items. Since the menu item is always greyed, I'm assuming that means the button is disabled as well -- certainly clicking on it does nothing.

(In reply to comment #87) > I'm not sure it matters, tho, since the extension doesn't seem to work even on > the trunk. Using TB 3a1-0520, Win2K, the extension installs fine but the Reply > To List toolbutton and menu item are not enabled when I select a message with a > valid List-Post header. Did you also install Mheny or Enigmail extension? See http://open.nit.ca/wiki/index.php?page=ReplyToListThunderbirdExtension for more info about that.

(In reply to comment #88) > Did you also install Mheny or Enigmail extension? I did not; that must have been the problem. Thanks for the pointer. That page also states that the extension won't work until TB 3.0.

(In reply to comment #89) He has patches for it to work in older firefox versions too, but that requires you to compile your own firefox (unless the Mozilla.org folks apply this patch...).

Is there any implementation of this function for SM? This bug was filed years before TB was invented.

(In reply to comment #91) > Is there any implementation of this function for SM? This bug was filed years > before TB was invented. Since the product is Core, the patch works with SeaMonkey and Thunderbird.

What I meant by implementation is actually being able to use the function. I can find no reply-to-list function in SM, nor any extension to add reply-to-list function to SM. How do I use this function?

The patch will be included in Seamonkey 1.5, but it doesn't provide any user interface, so an extension is also needeed to add the button (see the link provided in comment #88).

I don't see anything about SeaMonkey in comment 88 or the URL it links to, and thus still need an answer to comment 91 & comment 93.

The linked page is about Thunderbird, but the extension is probably also compatible with SeaMonkey, the only problem is that SeaMonkey still lacks of an extension manager and that the extension doesn't contain an installation script, but the extension manager support is planned for SeaMonkey. Anyway, you need a patched version of SeaMonkey (or the future gecko 1.9 based version).

I tested this supposed fix in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060717 SeaMonkey/1.5a, so I don't need to be told which SeaMonkey I need, only how to use the function requested by this 6 year old bug that is supposedly fixed but fails to provide the requested function in the base product originally filed against. The original bug requested a reply-to-list button, not a reply-to-list button to be optionally provided by some non-existent extension. That means this bug as described in comment 0 and the summary is not fixed. All other modern email clients apparently include this function by default, apparently including mutt, pegasus, kmail and evolution, and probably even outhouse and outbreak excess, leaving Mozilla to be constantly berated by mailing list spam from list users of those other apps ired by Mozilla users who either substitute reply-all for this missing function, or forward to the list an original reply mistakenly sent privately.

Well, I agree that this bug should be reopened to add a button, which isn't very difficult. In the mean time, you can add an install script (taken from a SM extension) to the extension from the link and then use it with SM 1.5a.

Sorry, I don't know much of anything about writing Seamonkey extensions, and I don't use it myself so I'm not likely to learn. My C++ patch should apply without any serious problems though, and I'd be more than happy to accept a patch to make the extension work with Seamonkey. I also don't check my Bugzilla email very often; the main website for the extension is at http://open.nit.ca/wiki/index.php?page=ReplyToListThunderbirdExtension - a comment there is more likely to reach me, if that's what you want. As for getting the button included by default, that'd be great, but I don't want to get involved with the inevitable bike-shed painting about exactly how it should work. My extension makes it work just how I want, and my patch makes it possible for anyone else (including the main Mozilla developers) to make it work how they want. If my design is desired for mainline Mozilla, then the JavaScript should be simple enough to copy from the extension.

Comment on attachment 217380 [details] [diff] [review] [checked in] Reply-To-List backend patch, with style fixes Have folks been testing this patch with the pref? How has it been working on the trunk builds? I'd like to consider this for the thunderbird 2 / seamonkey branch.

(In reply to comment #100) It works, but as said we need either the Mnenhy or Enigmail extension installed and the ReplyToList extension. But about the button, I think that it would be better to automatically transform the Reply button to a ReplyToList button and adding a small arrow (like for the print button) which would allow to just "Reply To" (and possibly remember this behavior).

This might be a stupid question, but why is Mnenhy or Enigmail extension required? Why can't the headers be added to the list of headers available without one of those extensions? Conversely, what's the point of this patch if it still requires multiple extensions for it to do anything? Couldn't this have been implemented entirely as an extension?

I want to echo comment #102. I don't think relying on a third-party extension is valid for this bug to be considered "fixed". If anything, it should be marked as "wontfix" with a pointer to the extension. Also, everyone here is talking about Thunderbird, but I want to see this fix for Seamonkey. After all, it is supposed to be a "Core" bug.

Sorry for the spam, but I'd also like to see this in the default build, because of the large confusion mailing lists cause *particularly* for new users, and the problems that causes for everybody. I think the age-old reply-to debate http://www.unicom.com/pw/reply-to-harmful.html (already mentioned in comment 3) alone is good enough reason to fix this. I'm suggesting that it appears on the main toolbar in that case: One button for reply to Author only, one for Reply to List (details open).

Reopening since the bug itself isn't fixed, as it has been stated multiple times.

Happy new year, This is in my opinion an important feature which Mozilla and any usable mail agent should support. Unfortunately it is going to be 7 years old. I'm waiting to see it solved to evaluate to return from kmail to thunderbird and share the inbox between several Operating system. Watch kmail and be inspired. It has reply specific per folder and full list manage options. Manuel

I found http://open.nit.ca/wiki/index.php?page=ReplyToListThunderbirdExtension which was recommended to me, and should (for what I have heard) work. Unforntunately it is a TB-only xpi, missing the installation sript for Seamonkey/Mozilla Suite. Would it be possible to add that script, to get it working in SM?

I have created a replyToList extension that works with an unpatched (=normal) version of thunderbird: http://cweiske.de/misc_extensions.htm#replyToList

(In reply to comment #106) > I'm waiting to see it solved to evaluate to return from kmail to thunderbird > and share the inbox between several Operating system. Now that KDE4 is going to run in Windows and MacOS, it may be possible to do that in kmail. Perhaps they haven't thought about it yet.

(In reply to comment #100) > (From update of attachment 217380 [details] [diff] [review]) > Have folks been testing this patch with the pref? How has it been working on > the trunk builds? I'd like to consider this for the thunderbird 2 / seamonkey > branch. Note to the patch author: this probably means you should simple add the little bit of xul for the button to the patch to get into thunderbird proper instead of having users need to also get the extension. You'd stand a better chance of getting this fixed if it were a complete solution, IMO.

Adding bug 364807 as a dependency since this one can't rely on extensions to work.

Comment on attachment 217380 [details] [diff] [review] [checked in] Reply-To-List backend patch, with style fixes This patch has already been checked in on the 1.8 branch

What is the status of this bug for thunderbird 2.0, I am unable to reproduce this in Thunderbird-2.0 but i would rather hear it works or doesnt work.

I would be glad if somebody could explain me how is this bug supposed to be fixed -- looking at thunderbird-2.0.0.14 I don't see any Reply to List method in any menu, button or whenever else.

(In reply to comment #114) > -- looking at thunderbird-2.0.0.14 I don't see any Reply to List method > in any menu, button or whenever else. That is the bug, or requested enhancement if you wish. I'm currently using this: http://www.juergen-ernst.de/addons/replytolist.html I can't remember which parts if the mail header it parses, but it seems to works fine at least as far as I've seen. Haven't tried the above-mentioned back-end patch. I'd rather test a complete build (a bit difficult with betas since I normally use portable apps) if possible.

Are there any plans to include this in Thunderbird 3? I just got a request from a current Thunderbird 2.0.0.16 user who would really like this feature. He's using mailing lists extensively and also uses the above cited extension, which works fine for him. I also found myself needing this feature quite a couple of times already, so would welcome it myself!

All this needs is some UI to be hooked up.

not a blocking bug, but this would be very nice to have, if someone steps up and does it.

Adding this to blocking bug 456814 as the tentative plan for the new message reader is to always use the ( Reply to List ) as the reply button for mailing list mail.

What does "always use the ( Reply to List ) as the reply button for mailing list mail" mean? If you're proposing that the "reply" button do anything other than reply (to individual) then I think it's a bad idea. The point is to have a separate button called "Reply to List" which people press when they want to reply to list.

I think it's fine that the "Reply" button for mailing lists goes to the list. (Many lists set the Reply-To header to achieve that, see above.) I do agree that it's critical to differentiate between "Reply to Author only" and "Reply to All/List".

The obvious UI solution is to have a dropdown in the new "reply..." button.

dropdown, with the list (or wherever mail-followup-to: header points to) as the default

(In reply to comment #121) > What does "always use the ( Reply to List ) as the reply button for mailing > list mail" mean? In the new message layout we're showing reply buttons on the message itself (please see linked bug). When you receive a message from a mailing list the reply button will be a (reply to list) button instead of a regular reply button. If you wanted to reply to the individual sender only then you'd use the popup menu off the sender's email address which will have a "Reply to Sender" option.

In reply to Comment #123 > The obvious UI solution is to have a dropdown in the new "reply..." button. Rumour has it that Thunderbird development can sometimes be quite resistant against implementing "obvious UI solutions" (like scrollbars on overflowing all-headers), but the good news is that after some 5 years or so, the likelihood of "obvious UI solutions" to be implemented increases dramatically (cf. bug 223132, now fixed!). The RFE to have dropdown reply buttons etc. was filed as early as 1999 in bug 17796, so chances are... I think having an extra menu on the sender's email link in the header as proposed by Comment #125 is much less intuitive than having all reply options in one single place, namely a dynamic dropdown reply button. I'd suppose it'll be quite confusing for the user finding only the default reply option on the button in the preview header, and having to go somewhere else and use a quite different approach for non-default reply options (context menu of sender etc.). Are there any reasons /against/ having a dropdown reply button (with dynamic default actions, if you so wish)?

> Are there any reasons /against/ having a dropdown reply button (with dynamic > default actions, if you so wish)? Rumour has it that lots of rhetoric and sarcastic tone make people resistant to reading bug comments. :) But it's certainly possible to have the option available in both places. That would give us a combination of buttons that look something like this. ( reply ) ( reply all | v )______ | reply to sender only | '----------------------' ( reply list | v )________ | reply to all recipients | | reply to sender only | '-------------------------'

In reply to comment #127: > That would give us a combination of [dropdown] buttons that look something like this. Don't rush it... ;), but yeah, "something like this [outline above]" looks very good to me. Questions: a) In which cases, if at all, will I see "reply all" as default? b) There are different ways of realizing the dropdown functionality. Which of the two would you prefer? Option 1: (static dropdown menu) Dropdowns behave like a non-changing menu, i. e. after having executed "reply to sender only" from the first dropdown (as per the previous comment #127), I will still see "reply all | v" as the default option. Users who more often than not want "the other option" as default ("reply to sender"), will cry. Option 2: (toggle-style/sticky dropdown menu) Whichever dropdown option I choose, will become the new default option (on the fly) for that type of msg (news message, normal mail with multiple recipients etc.). E.g. after having chosen "reply to sender only", "reply to sender only" will then stick as a default option for say, the next mail I am reading that also has multiple recipients, until I execute "reply all" once again which will then in turn become the default option again. Such behaviour is common in other applications like MS Word, e.g. for setting table borders, colors etc.: whatever you pick from the dropdown becomes your new default for the time being. Option 2 could make both sorts of users happy: - those who usually use "reply all" will (usually) get this as their default - those who usually use "reply to sender" will (usually) get this as their default Therefore, I am biased in favour of option 2. But why would people want to have "reply to sender" as their default reply action for mails with multiple recipients? There are many usage scenarios where in spite of multiple recipients, people might (per default) wish to reply to sender only, say leaders of any kind sending out a form or some task to a group of people where answers always go back to the central sender. Always and persistently defaulting to "reply all" in case of multiple recipients might be annoying for such users.

Thanks, that's a really good breakdown. In my experience Option 2 seems like a good idea, except that it creates tricky consequences. If you base the "sticky" quality off the type of message or other attributes you really have to communicate to the user that "Newsgroup messages will always reply to sender". Otherwise it can appear to people that we're choosing a default almost randomly; you click on one mail message and it's reply all, one news message and it's reply to sender. Also if a person wanted to reply to sender just once and we changed the default after that one time we're likely to confuse them. Sadly the simplest method of just defaulting to reply all for multiple recipients is going to allow everyone (even the people who would be annoyed by this behavior) to at least always predict what will happen. For those who want more "sticky" like behavior I believe all that would be necessary is to understand that need and build the buttons with extensions in mind. Extensions would enable people to customize the button type based off the attributes of the message, it probably isn't too difficult right now... well once we have buttons like that at least.

(In reply to comment #129) > Sadly the simplest method of just defaulting to reply all for multiple > recipients is going to allow everyone (even the people who would be annoyed by > this behavior) to at least always predict what will happen. I can see your point about predictability. From a best-usability-for-most-users point of view, how did you arrive at your intention to make "Reply to all" the default option for normal mails with multiple recipients (rather than "Reply to sender")? "Reply to sender" for all normal mails and "Reply to List" for all newsgroup messages would still be predictable. Do you have any statistical usage data that supports the choice? > For those who want more "sticky" like behavior I believe all that would be > necessary is to understand that need and build the buttons with extensions in > mind. Extensions would enable people to customize the button type based off > the attributes of the message, it probably isn't too difficult right now... > well once we have buttons like that at least. To have the dropdown buttons (at all) will be a great step ahead and much appreciated. However, translating the above means all that would be necessary to change potentially annoying defaults is that you have to be a programmer and start off from zero by extracting attributes of the message. Not all of us are, and programming the extension that way would involve a lot of (largely redundant) work. Considering that a possibly large number of users might be impeded by the choice of defaults, perhaps the following proposal would grant all kinds of users more flexibility at a reasonable cost for Mozilla programmers: Have a configurable defaultoption property (no UI, just about:config) for each type of message, something like: messagereader.replybuttondropdown.mail.single-recipient.defaultoption messagereader.replybuttondropdown.mail.multiple-recipient.defaultoption messagereader.replybuttondropdown.news.defaultoption For each of these, defaultoption can have (a suitable subset of) the following values: defaultoption=0 [future use: sticky default as per comment #128, option 2] defaultoption=1 [Reply to sender] defaultoption=2 [Reply All] defaultoption=3 [Reply to List] Since the currently planned implementation will check for the different types of message anyway (in order to show corresponding defaults for the reply dropdown), the extra bit suggested here is just reading the defaultoption property before setting the default for that type. Just a thought, and I do appreciate that every extra line of code for any one out of countless feature requests involves investing precious programming time - but maybe it is easier and more future-proof to implement this now rather than later since you are doing conceptual and coding work for the behaviour of the dropdown buttons anyway.

Hmm, Are you not overcomplicating this a bit :) Why not 1. Reply to "Reply-To" 2. Reply to Sender 3. Reply to List 4. Reply to All And: If the message is from message-list then default is 3. Otherwise the default is 1. I assume here that the Reply-To is from header "Reply-To", and Sender is from header "From". Anyway we could omit option 2. and if someone really wants to send to this addres then he could do it manually. In my opinion things like "sticky" can cause only troubles. If you really want to add something here, please do it via preferences settings.

I agree with comment 131. (Except 1. and 2. are just "reply", per rfcs.) I'm not sure why this became a discussion about defaulting to a certain reply type. At least for me, I do need to choose those on a per message basis - there is no "default".

Just a note: Reply-To-List is logically the same as Reply-To-Group (aka Followup) in newsgroups. I think they should be merged if possible. And also: in mailing list or newsgroup, the reply-to-list/followup should be the default. Otherwise, a simple Reply should be default. If sender wishes to override default reply style in news/lists by using Followup-To (or Mail-Followup-To supported by mutt), the default behaviour should be changed to this one (a config option?), but user should have possibility to ignore that.

Please pardon me if this has already been mentioned before (no time to read all 133 comments), but can't we just have Reply and Reply To All, where the Reply To All button will be smart enough to detect Mailing List/Newsgroup Headers and act as "Reply to List" if they are present, else as Reply To All. That way there is no need to add extra clutter to the GUI.

If you don't have time to read our comments why should we bother to read yours? Anyway: How would you reply to ALL with this behaviour when you get an e-mail from mailing list? I mean - to list _and_ to other recipients? This are two different things and I see no possibility to put them together.

(In reply to comment #135) > If you don't have time to read our comments why should we bother to read yours? > There are 32 pages of comments dating from year 2000 and yours are only from 2008. It was plain obvious that I was referring to the older comments. But I guess not obvious enough for you. Anyway moving on. > Anyway: > How would you reply to ALL with this behaviour when you get an e-mail from > mailing list? I mean - to list _and_ to other recipients? > > This are two different things and I see no possibility to put them together. If the mail is coming from a mailing list you should be replying to the mailing list email and not including other recipients unless explicitly requested by them (e.g: "Please CC me I am not subscribed to the list"). At least this is my understanding how mailing lists work and this is how would I expect a Reply To All to work in this case. "All" will mean "All subscribers on this list". If the mail is not coming from a list then "All" will just "Everyone from To and CC".

That would run afoul of Exim-users' (dumb, IMO) policy of CCing people on replies. All I want to know is, as the previous commenter has said, 137 (counting this one) comments going back 8 years and we're still going over the same discussion over and over. How to implement it. Look, TBird is one of the only mail clients on the unix side of life which doesn't implement it. This has been bicycled to death, people. Quite frankly I don't care HOW it is done, I care that it gets done before another 8 years goes by! A separate button? Fine! A drop down? Fine! Available only with a keypress? Fine! JUST DO IT ALREADY! If the TBird devs need to noodle it out look at how KMail, Evolution, mutt, pine, elmo and who knows what other clients do it, figure out the most popular method and implement that! It is readily apparent that whatever choice is made will not appease everyone who is watching and has commented on this bug. What is apparent is that this has to be one of the biggest warts in TBird's entire history and it is high time it is finished and marked closed.

I think the forums would be a better place for all of this discussion. I think it's inappropriate to have so many comments anyway, especially when they start becoming like a flame war (and repetitive). Maybe we should coin a new term, something like 'bugfight', to describe such a long, disagreeable and bad tempered commentary on a single issue.

As you see you would have "expectations" how it should behave. I have different ;) I feel that two separate options are better as it is perfectly clear what will be done - you don't have to guess. And they do what they say - All is All, List is List. As for usability of reply to all in "mailing list context" - I wanted this exactly for the case you have mentioned - to be able to reply to people that are not subscribed.

In reply to comment # 132 by Magnus Melin > I agree with comment 131. (Except 1. and 2. are just "reply", per rfcs.) > I'm not sure why this became a discussion about defaulting to a certain reply > type. At least for me, I do need to choose those on a per message basis - > there is no "default". The defaults discussion was triggered by Bryan W Clark's comment #120, linking this bug the new message reader layout. In comment #120 and bug 461098 comment #1 Bryan says the plan is to have a SINGLE reply button in the button bar of new message reader preview pane. The default action triggered by the button will then change dynamically according to the properties/type of the current mail/news. Combining as many as 4 different reply options (as per comment #131) into a SINGLE button certainly requires decisions about the default action, and that's how it started. The subsequent idea was to implement dropdown menu buttons to alleviate gross usability issues for those not happy with the single default reply option. Obviously, the dropdowns still require a single default reply option for each different type of mail/news. Usability thus could be improved by letting the user choose his/her own preferred default reply option for each type. A lot of the discussion in this bug shows that people's expectations with respect to default reply actions differ a lot. So I'm not sure if I'm overcomplicating things by suggesting a very low-cost solution to make default reply actions customizable (let user set default reply option for different types of mail/news in about:config; my comment #130 - ignore the "sticky" bit). Maybe some of the "bugfight" in between is in danger of oversimplifying the true complexity of the issue: 1 single new reply button (as envisioned by Bryan for the new message reader's header pane) should handle 2 basic different types of messages (mail, news), 2 additional subsets of messages (list-mail, mail with multiple recipients - see Bryan in bug 461098 comment #1), and 4 different reply options (reply to reply-to, to sender, to list, to all; as listed in comment #131, and basically the same in my comment #130). Default actions must evaluate at least 8 (i.e. lots of) different relevant headers (reply-to, follow-up-to, list-post, from, to, cc, resent-from, resent-reply-to...), where in terms of reply, some headers (like "reply-to") overwrite others (like "from") but still the user might want to use "the other" header... Furthermore, since this bug is linked with, but not filed explicitly against the new message reader, we'll need to consider at least 2 different locations for reply button(s): message reader and main toolbar, where the msg header pane real estate is much more limited than the toolbar. Thus the toolbar might continue to have TWO reply buttons where the plan for message reader is to have just ONE (possibly requiring different coding for those buttons). In addition, people want customization options, e.g. 4 individual buttons for each of the 4 different reply options, and choice as to which buttons are shown. Finally, add to that a lot of different and sometimes incompatible personal needs and preferences of individual users, ranging from "anything beyond 2 reply options is clutter" to "how about sticky reply options"... (forget about that idea of mine, predictability wins). Having said which, finding the "right" solution, or any solution for that sake, to problems of this sort must be very much like squaring the circle... so maybe we should be more understanding even if things do take a little longer (no sarcasm this time, just plain compassion! :)). @Bryan: good luck and we trust you can do it: square the circle!!

Why put the configuration in about:config? Folder-level configuration is not used nearly enough and this screams for folder-level configuration. I filter all my various foo-users mailing lists into separate folders. I often want to reply in those folders to reply-to-list unless otherwise specified. So make the configuration per-folder (with an about:config global, something I wish threading had) along with an option to auto-detect (via scanning list-post, et al) or manually setting. This is how KMail, Claws and mutt all do it. Make the non-default selectable by a dropdown on the button.

This look like *great*! I really need it :-) I'm very frustrated when I need "reply to all" and delete sender e-mail (maintain mail-list address). This enhancement have a lot of votes. Is there any plan to do it to Thunberbird 3? I will attach 2 e-mails, in this bug report. Both is sent to same mailing-list, but one is not necessary "reply to al" (is automaticaly reply to Mailing-List), but another is necessary "reply to all" (because when I click in "Reply" - or CTRL+R - message is reply to sender, not to mailing list). Best regards, Renato

I have the choice in Thunderbird-3.0 following is a screenshot, i have no plugs/addons except enigmail

Attached screen shot showing the reply all button in Thunderbird-3.0-b1

@John, "Reply all" button always was present in Thunderbird. This is not the problem. The big problem is: - When you is subscribed in some mailing-lists (as Debian, LKML, etc), when you click in "Reply", message will be sent to SENDER (author) and not to Mailing-list. Messages from @gmail.com ALWAYS is reply to author, and not to mailing-lists. To reply to mailing-list is necessary: - Use "Reply to all" + delete SENDER e-mail, OR: - Use "Reply" + delete SENDER e-mail + Insert mailing-list e-mail. See my two attachs, both is send to the same mailing-lists, but one works fine (when you use "Reply", message go to mailing-list), but another when you use "Reply" the message go to sender (author).

When i use reply all (using Mozilla mailing lists) it wants to send to user, mailing list, and newsgroup. Normally i remove user since he will read it in the list.

@John, you don't understand me. We want that when we select "Reply", message go to mailing-list. I'm very frustraded need "Reply to all" + delete sender e-mail. - When you reply this message: https://bugzilla.mozilla.org/attachment.cgi?id=362708 It go to mailing-list correctly. - When you reply this message: https://bugzilla.mozilla.org/attachment.cgi?id=362707 It go to sender/author and not mailing-list (so is necessary use "Reply to all" + delete sender/author e-mail. Best regards, Renato

@Renato: I guess this is quite out of the scope of this bug. The difference between the two messages is probably the "Mail-Followup-To:" header that is only present in one of them (for whatever reason). This can be handled (better) _when_ TB distinguishes between followup and reply. You should probably file a new bug for your specific problem.

the 2nd message (https://bugzilla.mozilla.org/attachment.cgi?id=362707) contains Mail-Followup-To: header that tells the client where shold List-Reply (Followup) go. Renato, you should always differ between Reply (to author), List-Reply (followup) and Reply-All. There should be possibility to reply to sender, e.g. for off-topic informations. I kinda wonder why replies to mail with Mail-Followup-To go to sender, while without the header they go to the list. Do you have some extension installed?

@Jens, My example show why this bug happening. This is not out of scope. I attach one more header, without "follow-up-to" and it go to sender when we reply it. So, we have 3 situations: - Message with follow-up-to, (that go to sender) https://bug45715.bugzilla.mozilla.org/attachment.cgi?id=362707 - Message without follow-up-to (that go to mailing list): https://bug45715.bugzilla.mozilla.org/attachment.cgi?id=362708 - Message without follow-up-to (that go to sender) https://bugzilla.mozilla.org/attachment.cgi?id=363826 Correct, in all this 3 sitautations need be: Message need go to mailing-list when I reply it. And not to sender. @Matus, I don´t have any extension installed. Best regards, Renato

Renato, this bug entry is not about a bug, but about a new feature. This feature is fairly well understood by the programmers, and the main question is the UI, which needs to be discussed with our UI czar, and somebody stepping up to implement it. So, please just wait, thanks.

In bug 461098 we added a ( reply | v ) button with the reply all menu item as a first step toward this and to help get the styling correct. In the next, b3, release I'd like to get this button to react to the message being displayed, showing "what we consider to be the best default" as the button face and still having other reasonable actions in the popup menu. Sorry for the huge bug comment. Here's the set of default / popup menus I have been working with for each situation. My goals have been this. * use the correct default button in the appropriate situation * refer to people / email addresses instead of header types like reply-to, sender * provide a reasonable set of actions in the popup to balance a confusing list of all possible and an unhelpful list of too few. * create an easy understanding of what the default action will do (as expectations obviously vary) single recipient, no reply-to ( reply | v )____________________ | reply to sender@example.com | '-------------------------------' single recipient, w/ reply-to ( reply | v )____________________ | reply to sender@example.com | |-------------------------------| | reply to reply-to@example.com | '-------------------------------' multiple recipients, no reply-to ( reply all | v )_______________________ | reply to sender and recipients | |--------------------------------------| | reply only to sender@example.com | | reply only to recipients (#) | '--------------------------------------' multiple recipients, w/ reply-to ( reply all | v )________________________ | reply to sender and recipients | |--------------------------------------| | reply only to sender@example.com | | reply only to reply-to@example.com | | reply only to recipients (#) | '--------------------------------------' mailing list, no reply-to ( reply list | v )________________________ | reply to mailing list list@example.com | |----------------------------------------| | reply only to sender@example.com | | reply only to recipients (#) | '----------------------------------------' mailing list, w/ reply-to ( reply list | v )________________________ | reply to mailing list list@example.com | |----------------------------------------| | reply only to sender@example.com | | reply only to reply-to@example.com | | reply only to recipients (#) | '----------------------------------------' mailing list, w/ multiple mailing lists ( reply list | v )_________________________ | reply to mailing list list1@example.com | |-----------------------------------------| | reply to mailing list list2@example.com | | reply to mailing list list3@example.com | | reply only to sender@example.com | '-----------------------------------------' mailing list, w/ multiple mailing lists and other recipients ( reply list | v )_________________________ | reply to mailing list list1@example.com | |-----------------------------------------| | reply to mailing list list2@example.com | | reply only to sender@example.com | | reply only to recipients (#) | '-----------------------------------------' Alternate attempt To explain why I made some of the choices made above, here's one of my simple original alternate attempts. ( reply all | v )________ | reply to sender | | reply to reply-to | | reply to mailing list | '-----------------------' Here's why I changed from this model. When using just the "sender" or "reply-to" we force an understanding of email headers on to people who might not understand the difference. Instead, by using people or addresses as the identifiers we can allow people to choose what they feel is correct. I don't think this is ideal, ideally we'd have a richer widget that could capture both pieces of information in a way that makes sense. Perhaps it's possible to use a rich list widget in a popup menu? This design assumes the constraint of a regular menu. The first item in the list is always the default action, with a separator to the other actions. I think Magnus brought up something to this effect in the other bug. I think this will help teach people who are unsure of what our default actions are and allows us a great space to explain what the default action is doing. After seeing the full default menu item users who were untrusting of what the short version of "reply list" or "reply all" might learn by seeing it written out. First reply button even has a drop down. This was done so that there wasn't a possibly confusing case where a person sees a reply with no options. People tend to relate these events to the people that are sending the mail. One person could set a reply-to and your mother might not. When your mother mails you you only get the one option to reply. I want to avoid that "it's not a dual button sometimes" scenario and just always be a dual button. Avoid the what to default to discussion for now, for several reasons. For one it's really easy to change a default, spending days discussing what it should be means that just picking one is not the right solution. When you're down to arguing default choices you need to broaden your scope of the problem and figure out a new solution, choosing default should be relatively easy when the rest of the system is healthy. Second is that we have a lot of other things to discuss, how to improve the layout of the menu. Can we have a better popup that allows for a better display of information than a regular menu popup? How do we best limit the size of the menu when displaying email addresses? Reply All vs. Reply is a common default battle and trust me that I understand the consequences of this default choice either way. While you're debating this in your head, try to mix in that the answer is not in picking one or the other, but changing the entire system of interactions such that the default is less relevant; less of a fork in the road. bug 248681 is an excellent part of the broader scope of the problem. Reply All vs. Reply starts with how the messages is presented to the user in the list, how the message is displayed in the reader, how they choose to reply, and how they compose that reply. Improvements in those areas changes the default choice from a fork in the road to a simple road sign.

> single recipient, w/ reply-to > ( reply | v )____________________ > | reply to sender@example.com | > |-------------------------------| > | reply to reply-to@example.com | > '-------------------------------' If the original sender has specified a reply-to address, maybe it would be most polite to default the button to the reply-to address instead of the From address.

(In reply to comment #156) > > single recipient, w/ reply-to > > ( reply | v )____________________ > > | reply to sender@example.com | > > |-------------------------------| > > | reply to reply-to@example.com | > > '-------------------------------' > > If the original sender has specified a reply-to address, maybe it would be most > polite to default the button to the reply-to address instead of the From > address. right! good catch. I hope that was a copy/paste problem. Make that this instead: single recipient, w/ reply-to ( reply | v )____________________ | reply to reply-to@example.com | |-------------------------------| | reply to sender@example.com | '-------------------------------' thanks!

I like the expanded menu idea in comment #155. There is a second instance (mailing list) of not making Reply-To the default in cases where it exists. Like Pete, in comment #156, I think that if Reply-To exists, it should be the default. But I think the list of choices you are offering is great, and expanding them to use the real email address is even better. Dunno from the examples if you are intending to include the "full name" part of the address or only the email address itself. Mozilla generally uses/preserves the whole thing, unlike AOL which drops the "full name" and Outlook, which suppresses/hides the email address wherever possible. I like the Mozilla approach, generally, of showing both, even though it is longer. I do have multiple friends named "Mike", etc., so both are handy to make it clear.

Patch coming soon.

It's a first cut, and definitely needs some work, but it works, albeit with some unnecessary beeping. I'll be happy to develop this further, but I figured that having something to play with would at least get this a little bit closer. Any assistance would also be appreciated, natch.

(In reply to comment #155) Mainly wrt Reply-To addresses: I think having such an amount of choices, so visibly, doesn't help people do the right thing. Most of the time, users should only have to choose "Reply" or "Reply All", (or "Reply to list"). Giving too easy access to other than Reply-To addresses will only lead to wrong choices. Maybe a sub menu of some kind... Likewise "Followup-To", "Mail-Followup-To", "Mail-Reply-To" and other headers are designed to tell the mail client what to choose for a "Reply"/"Reply-To". (I also suspect having the e-mail included in the menu item doesn't look good, especially when the address is a bit longer.)

You have in mind any plan to do shortcuts to this new buttons? Maybe this is *crazy* ideal, but: - Reply: CTRL + r - Reply to list: CTRL + rr - Reply to all: CTRL + rrr

It's currently: - Reply: CTRL + r - Reply to all: CTRL + SHIFT + r - Reply to list: CTRL + SHIFT + r (So the Reply to list shortcut totally doesn't work!) I'll update the patch to use CTRL + SHIFT + L, so we'll have the following: - Reply: CTRL + r - Reply to all: CTRL + SHIFT + r - Reply to list: CTRL + SHIFT + l - Forward: CTRL + l

Good! Thanks!

Just like the previous patch, but with accel+shift+l as the key combo, so that you can actually get to the feature from the keyboard. :)

(In reply to comment #162) > (I also suspect having the e-mail included in the menu item doesn't look good, > especially when the address is a bit longer.) I had thought there was a max-width that the menu wouldn't go beyond and would then cut off the email addresses when they are long. perhaps also adding an elipsis...?

I hope comment #168 is suggesting that as a work-around to when a menu entry gets wider than the screen, not as something that would prevent menus from getting the full width email address in any case where it would actually fit.

A view of the changes introcuced by an upcoming, separate, small patch to disable the reply all button (and menu item) if there is only one address in the recipients and nothing in the ccList.

It doesn't depend on my other patch, and it's small, so I'm hoping to work out the UI details on this, and then just do the same thing for the Reply To List feature.

Thinking about this a little more, I'm not sure that this patch is a good idea, since now there's not an easy way to reply to the sender as well as yourself, which is what "Reply All" used to do. Still, it was good practice for removing the ReplyToList menuitem, which I'll need to do when that feature gets implemented.

This patch also makes the default button "Reply All" when there's more than one recipient, and puts the "Reply" button in the sub-menu. It also incorporates several style improvements from DavidA.

Comment on attachment 365595 [details] [diff] [review] A patch to remove reply all when there's only one address to reply to. This is looking really good! The default button change is going to be great. I wouldn't change the reply button to a regular button though, it makes it resize (at least on win/lin) strangely and I think the effects will be odd. See my Comment #155 for more about that and what a regular reply button looks like. Beyond that I think we'd be ready for some code reviews.

I'm planning on splitting the requested UI in Comment #155 into 3 patches. This is the first, which changes the default button. The second will add the Reply-To-List functionality. The third will add the email addresses to the buttons.

Comment on attachment 365962 [details] [diff] [review] A patch to change the default button. this looks good, but has some kind of bug updating the button. Magnus can you take a look at this?

In the next patch (adding the Reply-To-List feature), I've changed the code to be called from within the OnMsgLoaded function (in mail/base/content/mailWindowOverlay.js), instead of within the nsMsgDBViewCommandUpdater.displayMessageChanged method (in mail/base/content/messageWindow.js) and the updating is looking much smoother and more consistent. I'll be happy to back-port the fix to patch 1, if you'ld like, Magnus, or I'll clean my debugging statements out of patch 2, and submit it, and you can see how I fixed it in that patch. Let me know which you'ld prefer. Thanks, Blake.

Comment on attachment 365962 [details] [diff] [review] A patch to change the default button. Yeah, there's some problem with updating the button when changing mails. I think it's better to just do it all in one patch, especially as if you change entity string you have to bump the names... >diff -r 7bfd2406b167 mail/base/content/mail3PaneWindowCommands.js >--- a/mail/base/content/mail3PaneWindowCommands.js Fri Mar 06 14:50:59 2009 +0100 >+++ b/mail/base/content/mail3PaneWindowCommands.js Fri Mar 06 15:01:13 2009 -0500 >@@ -306,10 +306,15 @@ > return false; // else fall thru > case "cmd_reply": > case "button_reply": >+ case "cmd_replyall": >+ case "button_replyall": >+ msgHdr = msgHdrForCurrentMessage(); Needs to be declared? (Or maybe it is alreay earlier, either way, not so nice.) >+ let showReplyAllButton = msgHdr && (msgHdr.recipients.split(",").length > 1 || msgHdr.ccList); Trailing space, but break the line after || >+ UpdateReplyButtons( showReplyAllButton?"replyAll":"reply" ); Here and else where, please skip the spaces after/before "(" (Add spaces around "?" though.) >+ if ( command == "cmd_replyall" || command == "button_replyall" ) >+ return showReplyAllButton; // else fall through Remove extra spaces. >+ let replyAllButton = buttonBox.getButton('hdrReplyAllButton'); >+ let replyButton = buttonBox.getButton('hdrReplyButton'); >+ >+ if (replyAllButton) >+ replyAllButton.hidden = (buttonsToShow != "replyAll"); >+ >+ if (replyButton) >+ replyButton.hidden = (buttonsToShow != "reply"); The buttons don't always exist? Also, please try to be consistent with " and '

> Yeah, there's some problem with updating the button when changing mails. Fixed. > I think it's better to just do it all in one patch, especially as if you > change entity string you have to bump the names... Perhaps, although the bit to add the Reply-To-List button is fairly big already, and I'm really enjoying using the functionality without changing the button names, so I think I'm going to keep it as 3 patches. >>diff -r 7bfd2406b167 mail/base/content/mail3PaneWindowCommands.js >>+ case "cmd_replyall": >>+ case "button_replyall": >>+ msgHdr = msgHdrForCurrentMessage(); > Needs to be declared? (Or maybe it is alreay earlier, either way, not so > nice.) The call has been moved into mail/base/content/mailWindowOverlay.js, where the function is defined. (I am still calling it earlier in the file than it's defined, but so is the UpdateJunkButton function, and I'm not sure whether both of those should be moved down below where msgHdrForCurrentMessage has been defined, or whether msgHdrForCurrentMessage should be moved up above those two functions, or if it doesn't matter, as long as they're in the same file. If you would like it to be changed, I'll be happy to change it.) >>+ let showReplyAllButton = msgHdr && >> (msgHdr.recipients.split(",").length > 1 || msgHdr.ccList); > Trailing space, but break the line after || Fixed. >>+ UpdateReplyButtons( showReplyAllButton?"replyAll":"reply" ); > Here and else where, please skip the spaces after/before "(" > (Add spaces around "?" though.) Fixed. >>+ if ( command == "cmd_replyall" || command == "button_replyall" ) >>+ return showReplyAllButton; // else fall through > Remove extra spaces. Fixed. Well, deleted, but I'll remove them in the future if I add similar constructs. >>+ if (replyAllButton) >>+ replyAllButton.hidden = (buttonsToShow != "replyAll"); >>+ if (replyButton) >>+ replyButton.hidden = (buttonsToShow != "reply"); > The buttons don't always exist? Fixed. > Also, please try to be consistent with " and ' Fixed. Sorry it took me so long to update the patch, my weekend was busier than I thought it would be. Thanks, Blake.

Comment on attachment 366330 [details] [diff] [review] A patch to change the default button, with fixes suggested by mkmelin. There seems to be at least of cases where this doesn't do what it should. o newsgroups (all you can do is "reply") o lists, and when I'm bcc:ed I think The only case when "All" shouldn't be needed is when it's addressed exactly to me, no? >+function UpdateReplyButtons(aUrl) You don't use the aUrl >+{ >+ let msgHdr = msgHdrForCurrentMessage(); >+ let showReplyAll = msgHdr && (msgHdr.recipients.split(",").length > 1 || >+ msgHdr.ccList); let showReplyAll = msgHdr && (msgHdr.recipients.split(",").length > 1 || msgHdr.ccList);

Comment on attachment 364944 [details] [diff] [review] New patch, with better key bindings. removing this review. we can do the keybinding in a (much smaller) separate patch.

Blake, I'm guessing you don't have much time for this at this point. I'm adding sid0 to the CC so if that's true sid can take over this patch. I feel like this piece is pretty necessary so I'm marking it blocking again and targeting b3 even though I know it's too tight so it could slip and block the next release.

Brian, I haven't had a lot of time last month, but this month looks a little more free. Here's the latest patch I have, which seems to fix the problems Magnus mentioned, albeit not in a super-clean way. Specifically, I don't think this is the best way to tell if a message is sent exactly to me or not, but it seems to work in the cases I've tested, and I couldn't find a better way. If Sid0 has some time to help me out with some code reviews/questions on IRC, I would love to continue working on it. (I'm also going to post a patch that adds the reply-to-list button, which is based on this patch, to hopefully get comments on it as well.)

Let me know if you want some screenshots for the ui-review.

Blake, Speaking from a user perspective, I really don't care if the message was To me and CC the list or vice-versa. If I understand some of the patch stuff, I think you're making this more complex than it needs to be. If there is a "reply-to-list" header in the message, the reply-to-list button should reply to that address. Regardless of how it arrived in my e-mail. "Reply" should reply to the Sender, or to the "Reply-To" address if one is present. In fact, I'd recommend against monkeying with default "reply" behavior in the presence of mailing lists. The Kmail crew did this a couple years ago, and the end result was a lot of people (including me) sending mails to the list which we meant to be private; they reverted the changes later. Let's don't repeat the same mistake with Thunderbird: leave it up to the user to whom he wants to reply. If I've misunderstood the patch, never mind, but please keep the commentary above in case someone decides to get clever later.

(In reply to comment #187) > The Kmail crew did this a couple years ago, and the > end result was a lot of people (including me) sending mails to the list which > we meant to be private; they reverted the changes later. Let's don't repeat > the same mistake with Thunderbird: leave it up to the user to whom he wants to > reply. I think you've slightly misunderstood the patch. The "Reply" button will always only reply to the sender. (Well, or to the Reply-To address, which may point to a list, if the list sets it that way... The point is that I'm not changing that behaviour at all.) I am adding a "Reply To List" button, and changing which button shows up at the top of the message (which I've been calling the "Default button"), but since you'll be looking at that button when you're clicking it, I think it will be fairly obvious when it changes from "Reply" to "Reply To List". And the keybindings won't change, so Ctrl-R will always reply, and Ctrl-Shift-L will always be reply-to-list, no matter which button is showing as the default. Does that allay some of your concerns? Would you be up for applying the patch, and testing it out to see if it works for you? Thanks, Blake.

Blake, OK, just making sure. I guess I did misunderstand the patch. I'm on Mac these days, and have never built Mozilla from source on Mac before (let alone Thunderbird). I can certainly take a stab at it, but no promised that I'll be able to supply useful feedback. Results later.

FYI, from what I understood from the patches (please correct me if I'm wrong): It looks for the List-Post: header (which all mailing lists I checked have, including Mailman), and uses that to decide to show the "reply list" button instead. The other reply variations are still available as drop-down menu, see comment 155 ff for specs. If "reply list" is clicked, the backend code (comment 80) will read the List-Post header and post to the email address given there. This is the entirely correct and perfect behavior (and more than I hoped for), thanks Peter McCurdy and Blake! Blake: as far as I can see, the code leaves the "reply to list" dropdown menu item (in contrast to the button) always enabled. I think you'll want to disable that, because the backend code then can't do anything meaningful, as it looks for the List-Post header which is not there. I think it falls back to normal reply, but that's then redundant in the UI and irritating result.

This feature is one of great news that I'm waiting for. Thanks for developers that is working on it. Regards, Renato

Some issues: o still some updating issue, get locked into the latest reply mode especially in the expanded headers mode going from account to account o when reading news where List-Post is available - like the mozilla newsgroups - should give reply to list as default option? o "reply to list" when my address isn't in the to/cc addresses replies to sender, not List-Post (or to)

Comment on attachment 376569 [details] [diff] [review] Use the aUrl to handle news and handle when I'm bcc:ed. >+function UpdateReplyButtons(aUrl) >+{ >+ let msgHdr = msgHdrForCurrentMessage(); >+ let showReplyAll = true Please add trailing ';' - those are missing in quite a few places. >+ replyAllButton.hidden = (buttonToShow != "replyAll"); >+ >+ debugger; Remove the debugger I had the updating issue with only this patch applied too, fwiw.

This is maybe already taken care of, but I'd love it if the reply functionality when dealing w/ lists could detect which of my identities to use to reply. from looking at the source of some messages, it seems that the Delivered-To: header could be useful.

And there's also a lot of trailing whitespace (+ lines with only whitespace that should be empty.) Davida: that's bug 327713.

> when reading news where List-Post is available - like the mozilla newsgroups > - should give reply to list as default option? No: If I read the newsgroup, it should show "reply to newsgroup" as default button, and go to newsgroup. I chose to use NNTP, and most likely are not subscribed -> not allowed to post to mailing list. I.e. that would simply be a bug.

(In reply to comment #190) > Blake: as far as I can see, the code leaves the "reply to list" dropdown menu > item (in contrast to the button) always enabled. I think you'll want to disable > that, because the backend code then can't do anything meaningful, as it looks > for the List-Post header which is not there. I think it falls back to normal > reply, but that's then redundant in the UI and irritating result. Yeah, I'll try to add this in tonight, asking in IRC for some pointers on how to enable/disable menu items. (In reply to comment #196) > No: If I read the newsgroup, it should show "reply to newsgroup" as default > button, and go to newsgroup. This will be part of patch 3 (add the email addresses to the buttons), if I ever get patches 1 (change the default button) and 2 (add the Reply-To-List functionality) committed. (In reply to comments #193 and #195) > Please add trailing ';' - those are missing in quite a few places. Done. > Remove the debugger Done. > And there's also a lot of trailing whitespace (+ lines with only whitespace > that should be empty.) I've fixed the lines that I added with trailing whitespace/only whitespace. I have left the lines with trailing whitespace that I didn't touch, to minimize the diff. I'm happy to do a big patch which cleans up all the trailing whitespace, but that's a different problem, and should probably go under a different bug. > I had the updating issue with only this patch applied too, fwiw. Cool, that'll make it easier to track down. Is there any more info you can give that will help me figure out what's going wrong? Steps to reproduce, maybe? I'll post a new patch once I've fixed the updating bug and disabled the reply-to-list menu item. Thanks, Blake.

I tried this out for a while today and it looks good, my only complaint was that it seemed to think that all messages were reply all even if it was a direct message between me and another person.

Re the whitespace: yeah i only meant for stuff you add/change. Comment 198 sounds a lot like the updating issue I was talking about.