Open Bug 933472 Opened 11 years ago Updated 2 years ago

Provide a configuration option to allow "Reply All" behavior of moving "To" recipients to "Cc" field again

Categories

(Thunderbird :: Message Compose Window, defect)

Product:
Thunderbird
Component:
Message Compose Window
Type:
defect

Tracking

(Not tracked)

Status:
REOPENED

People

(Reporter: jpbarrios, Unassigned)

References

(
URL
)

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36 Steps to reproduce: Hi there, I've been a Thunderbird user for years and really liked the way "Reply All" used to work up until last week when it was changed (VER 24.01 and VER 24.1.0). I think that when you receive an email having you and other people in the TO field the reply should be addressed ONLY TO the sender and CC'ed to the others just like TB would do in all its previous versions. I really dislike this behavior in Outlook for instance but at least in Outlook you can easily select the whole string of addresses and cut it out of TO and paste it into CC. However, with TB this is hard to do because the addresses are one by line so changing TO to CC must be done in a per address basis which can be pretty time consuming. I agree with the RFC2822 cited above. I find that normally when replying to an email I'm normally addressing the sender and not directly the other people the sender put in the TO field. Of course the others should be aware of my response, which is why they should be in the CC field, but in most cases I'm replying TO the sender and not TO every person. So, these days after the change I find that more than 90% of the time I want to switch people to CC or I just don't bother with it but just keep repeating the name of the person I'm writing *TO* to make clear I'm talking to that person and not necessarily to every one who is in the TO field. Anyway, please make this configurable in the config editor or somewhere if you can. I don't mind if the old behavior is no longer the default one, but it should be available for those who prefer it. Thank you, Juan Pablo.
Confirming as a follow-up bug to bug 250187. Some users want it this way, others the other way, so that's asking for a configuration option. Personally, I find myself much more frequently now having to change the To/Cc lists than before to adjust whom I'm primarily addressing and who are the secondary recipients. Nothing filed on that so far, thus not a duplicate. There are posts on both MozillaZine and GetSatisfaction on this change.
Blocks: 250187
Status: UNCONFIRMED → NEW
Component: Untriaged → Composition
Ever confirmed: true
OS: Windows 7 → All
Product: Thunderbird → MailNews Core
Hardware: x86_64 → All
Summary: Change in "Reply All" behavior when replying to emails with multiple address in "TO" field. → Provide a configuration option to allow "Reply All" behavior of moving "To" recipients to "Cc" field again
Version: 24 → Trunk
Well, the main reason it's not configurable was that for To/Cc to be able to be treated differently ALL recipients need to keep the original semantics, OR, *manually* change it to a more appropriate scheme. If some people configure it to not keep the original semantics, it all breaks down to being one big blob where you don't have semantics at all. Of course there are situations where you would like it to work differently, but the point is, the original sender should set it appropriately, and that setting must be kept by default, or all is lost. Yes, bug 440377 makes things harder than it should be... BTW, this is not "Outlook only behaviour", GMail, Hotmail/Live and many other does the same thing, so it's really what people expect, and by configuring a default to be different you're just annoying people. For the above reasons, i'd suggest this is wontfix.
(In reply to Magnus Melin from comment #2) > Well, the main reason it's not configurable was that for To/Cc to be able to > be treated differently ALL recipients need to keep the original semantics, > OR, *manually* change it to a more appropriate scheme. Thinking of a likely real-world use case, let's assume that the boss sends a message to his 20 employees and for the record to his secretary. Each employee would be in the "To" list while the secretary is on the "Cc" line. If an employee replies, he would likely intend to primarily address the boss, with an FYI to everybody else. This was the default behavior before, now he'd have to change 20 entries manually to "Cc" to accomplish that (and yes, bug 440377 might simplify that). Thinking further, the same example serves as a use case for the bug 250187 behavior. Assuming that another employee replies to the reply of the first one, that first employee would be in the "To" list and everybody else in the "Cc" list. In this case though you'd only have to switch the field for the boss from "Cc" to "To" in order to get his attention as well, as desired. A third employee may want to reply to the second one, but retain the boss and first employee as primary recipients as well, etc. Thus, strictly speaking, there is no standardized way how to do that in all cases. Ideally the sender should be able to pick for each reply-all action individually if he wants to address the whole "To" crowd or just the original sender, then adjusting the list of "To" and "Cc" recipients as desired.
Like I said, of course there are cases you'd want to have it cc instead, and making that easy would be bug 440377 - which I would like fixed for other reasons too. It all depends on what the mail was about, it may just as well be part of a conversation where To would be the more appropriate thing.
Magnus, please don't forget that TB worked for at least 10 years the other way (that's the time I've been a TB user), putting everyone in CC except for the person who wrote the email you're replying to. If this behavior would be inappropriate or would annoy people as you said before I just wonder why the bug #250187 only had 8 votes in almost the decade it was open. It seems not so many people were annoyed at the way TB had always behaved until now, and I guess that if the previous behavior would make so little sense as you seem to think it wouldn't have lasted so long. I agree that dealing with the bug #440377 would make it easier to deal with this, but the fact still remains that TB would always behave certain way and that was changed without users clearly asking for it, and without giving the option to those who like the past behavior to still have it nor without any workaround to allow users to easily switch addresses from TO to CC. I personally find myself very frequently now replying to people who didn't write to me in the first place, which pretty much collides with the concept of "replying."
Does anyone have an idea when this will get fixed. It's driving me nuts. I receive emails with 20 people in the "to" list and then it takes me a while to replace all of the "to"s with "CC"s.. Help!
I agree the sudden change of this behavior introduced problems for those of us that have used TB for quite a while. Introducing a config option would be ideal.
I agree this is a very annoying change after 10 plus years of using TB. (In reply to Magnus Melin from comment #2) > BTW, this is not "Outlook only behaviour", GMail, Hotmail/Live and many > other does the same thing, so it's really what people expect, and by > configuring a default to be different you're just annoying people. > > For the above reasons, i'd suggest this is wontfix. I may misunderstand this comment, but this is not how GMail works for me. If I hit reply all, only the original sender is put in the To field. This makes TB an outlier in this approach to reply-all. Another problem with this new approach. I use the QuickText extension to make quick replies. QT has a variable for the To field, which allows for quick addressing of an email. Now, with this change, all the people in the email TO field are added to the address field. Very annoying indeed.
One more vote from me. I agree with Juan Pablo. The sudden change of this behaviour is causing many problems in my organization too. I confirm that GMail handles reply-to properly, as Tlon wrote, ie. the same way that Thunderbird did it for years until the last change. I understand that there are people that may want to use the current behaviour but it's very important to make it configurable. Regarding bug 440377: This is not a solution for the current issue. It might make some actions easier of course, but people (including me) are lazy and when they think of replying (especially being used to the old behaviour) just don't thing of rearranging the entire To/CC list. They hit "Reply all", type their message and hit "Send". And it currently ends with a lot of messages that should be addressed to a single person, but are in fact addressed to a wide group instead. Not how To/CC fields should be used in e-mails. Thanks Pawel
Vote from me, and I'm downgrading until this is fixed. The feature request in bug 250187 should not have changed the default behavior, and at a minimum should not have been implemented without a configuration option. It's probably too late to revert that change however. More baffled users here: https://groups.google.com/forum/#!topic/mozilla.support.thunderbird/eMowHG709-U
"Outlook-only behavior" is an accurate description. Between Apple and Google, around 60% of the email clients in use today follow the old behavior. Only Outlook and Outlook.com seem to use the new behavior. The old behavior matches the convention proposed in RFC 2822: > If a reply is sent to a message > that has destination fields, it is often desirable to send a copy of > the reply to all of the recipients of the message, in addition to the > author. When such a reply is formed, addresses in the "To:" and > "Cc:" fields of the original message MAY appear in the "Cc:" field of > the reply, since these are normally secondary recipients of the > reply.
You may want to read that again. "MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item."
Re comment #11: I want the "normal" capability as described in the quoted fragment of RFC 2822. I do indeed receive broadcast messages. If these are of the form where replies should be sent with all recipients in the To: header line, I receive them from some form of listserv as described at <http://en.wikipedia.org/wiki/Listserve>. I can then reply to the list name at that listserv for all recipients to be in the To: header line. I believe that is how the Mozilla mailing lists cited at <http://www.mozilla.org/about/forums/> operate.
Magnus, I agree that MAY means things are optional in the context of RFCs. However, the RFC does not propose any other behaviors, and the majority of email clients in use today follow the behavior that the RFC describes. Outlook and Eudora are the only ones I'm aware of that do not. Since almost nobody requested that the behavior be changed (8 votes for bug 250187 in 9 years vs 12 so far for the old behavior), the onus should probably be on those wanting the Outlook behavior to justify changing the default (rather than adding a new option, per the original bugzilla request). So far I have seen no compelling justification.
I don't think this should be considered a bug. If original Ccs are kept, then new CCs can't be distinguished. That could a be a serious problem, since one would want to know which person(s) has (have) been brought into the discussion at this point.
(In reply to Rod L from comment #10) > Vote from me, and I'm downgrading until this is fixed. Unfortunately I had to downgrade to 17.0.8 (couldn't find a v18 o v19 non beta) as well for two reasons: 1- After seeing the amount of open Bugs and the amount of Bugs that are submitted each day I'm not sure how optimistic we can be about this being addressed soon and it's really really annoying. I couldn't stand it anymore. 2- The last update (last week's one) messed up the threads preview, it just stops working after a short while and I use that feature a lot. Just to get this off my chest even though I won't change anything, obviously; but I want to say that it's pretty annoying to have such frequent updates with apparently no changes and new bugs being added in each build. As I said above, the amount of new bugs being submitted periodically on this site is shocking. I think the fact that Mozilla dropped Thunderbird is finally taking its toll and this very good email client is starting to fall apart and it seems now the TB project is "no man's land" with a bunch of uncoordinated efforts from many willing contributors but with no clear objective as to where it's going. Also it seems single individuals or very few people can make decisions that impact lots of users and this is being done quite irresponsibly without taking into account their consequences for the long established userbase.
(In reply to Magnus Melin from comment #2) > Well, the main reason it's not configurable was that for To/Cc to be able to > be treated differently ALL recipients need to keep the original semantics, > OR, *manually* change it to a more appropriate scheme. If some people > configure it to not keep the original semantics, it all breaks down to being > one big blob where you don't have semantics at all. The semantics many use is simple - there is "always" one sender, so I am replying to that one sender. Not the other recipients of the original message - those haven't sent me anything, so there is nothing to reply to. They are not the primary recipients of my reply. But I may want to keep them informed. I understand that your organization may be used to something different, though. It's just how you feel about being in "To" versus "CC". My understanding is that when I'm in "To", I need to react to that e-mail. > Of course there are situations where you would like it to work differently, > but the point is, the original sender should set it appropriately, and that > setting must be kept by default, or all is lost. Well as others have said if it was so severe as you indicate why do you think Thunderbird has so many users? Probably most were satisfied with the way it used to work. > Yes, bug 440377 makes things harder than it should be... Great if you can get that fixed. > BTW, this is not "Outlook only behaviour", GMail, Hotmail/Live and many > other does the same thing, so it's really what people expect, and by > configuring a default to be different you're just annoying people. GMail acually uses the "old" behavior. Go figure. I wouldn't be surprised if it was just Microsoft and Eudora (trying to attract Microsoft users), and now Thunderbird, using the "new" behavior.
Mozilla-based applications are advertised as standards-compliant. In this case, RFC 5322 is the closest thing there is to a standard. Per the cited URI, I read RFC 5322 Section 3.6.3. To me, that clearly indicates the To: list should move to the Cc: list on a reply. Thus, I request that the Composition component of mail-news core be made standards-compliant or at least have a user-oriented option for standards-compliance.
I hope to come back and see TB has gone back to putting all of the other To: on the Cc: line, or receive an email to that effect...but I won't hold my breath.
The prior "reply all" behavior is how all mail clients that I have used over the last 30 years have worked, including all versions of various UNIX and Mac clients (mail, mailx, elm, pine, Eudora, Groupwise, Netscape mail and of course all but the most recent versions of TB). And for all the good reasons that Juan Pablo, et. al. have described. Please fix this regression.
FWIW, the To: <original sender>, Cc: <rest of recipients> behavior is a common practice on LKML and many (most?) other development lists as well -- typically the original sender seeks input from multiple people, but their replies are directed to the original sender, with the remaining recipients on CC. Using Thunderbird for LKML email has thus become a bit tedious :-(.
Instead of an option for the behavior of "Reply-to-All", how about providing two functionalities: the previous "Reply-to-All-Cc" in addition to the new "Reply-to-All-preserve" ? I would personally prefer to: - restore the previous "Reply-to-All" with its original shortcut - call the new one "Reply-to-All-To" or "Reply-to-All-preserve" and assign it Ctrl+Shift+A
I don't think two modes are called for. I think bug 440377 would help a lot, but if we must, a hidden pref would the thing to do.
Depends on: tb-pills
The one-line-per-type redesign would still leave you with having to cut-and-paste addresses around manually, easy to screw the list up in this way. It sure would be nice being able to distinguish between the two use cases on the fly while replying (given that there /are/ cases where you need one behavior or the other), but a global pref to pick one of them based on the most frequently encountered case may make already most people happy.
Another vote to bring back the old behaviour (i.e. To -> Cc on reply-to-all) in *some* form, for all the good reasons already stated. Of course the new behaviour "shouldn't" have been made the default, but I guess that's history now. Hidden pref would be great.
(In reply to Per Hedeland from comment #25) > Hidden pref would be great. It would be acceptable but definitely not great. End-users should have a user-oriented way to select the option.
(In reply to David E. Ross from comment #26) > (In reply to Per Hedeland from comment #25) > > Hidden pref would be great. > > It would be acceptable but definitely not great. End-users should have a > user-oriented way to select the option. Well, I'm obviously only stating my own opinion. If I were developing TB, I would agree with you, but I'm only a mostly satisfied and grateful user. As such, *for me*, a hidden pref would be great compared with the current state (i.e. "no way *at all*") - and I would never presume to state what is "acceptable" for a piece of freely available software to which I haven't contributed anything.
https://addons.mozilla.org/en-US/thunderbird/addon/reply-to-all-as-cc/ seems as nice enough workaround. It's always funny finding workarounds for fixes that work intentionally unintuitively.
Thank you for your hint, Kubek. This add-on seems to do it's job well. I believe it's the patch for all the people missing the old TB behaviour.
Another vote to say that this really seems to be a regression in behaviour and should be fixed. I think it's rather disappointing to see TB adopting Outlook behaviours.
Thanks for the tip re the add-on, it works for me. It's truly odd that we need an add-on to restore behaviour that was normal for more than a decade (not to mention traditional unix mail clients before that), but at least the architecture is open enough that there's a way to fix the fixes.
Windows 7 (x64) Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 Running in Safe Mode, I do not see this problem when the other addresses were in the CC: list. I received an E-mail that was also sent to three other individuals. The message was NOT sent with To: to all four of us. Instead, the message had only my own address in the To: list; the other three were in the CC: list. With Reply to All, the three from the original message's CC: list went into the reply's CC: list. Yes, I know my situation is not the same as the complaint in this bug report. However, I think this comment might help to narrow the search for a fix.
Another thanks for the tip re the add-on, and a metoo for the comment that it is strange that we need an add-on to restore the earlier behaviour. There is a glitch in the add-on though, in that if you reply to a message where you are the sender (yeah I enjoy talking to myself:-), you end up with all Cc and yourself missing in the recipient list. And although I can see that changing this behaviour back to what it used to be, i.e. another non-backwards-compatible change to fix the earlier one, is troublesome, and I (per earlier comments) personally don't think it is reasonable to demand such a change, I find the complete lack of comments from the developers on this issue disturbing. (I don't know if the sole "defender" of the new behaviour, "Magnus Melin", is a developer, but he hasn't offered any reasonable motivation for the change IMHO.) Either "We carefully considered the implications and decided that it was for the best" or "We made a mistake, sorry about that" would be fine, but the total silence gives the impression that there is no-one at the helm anymore - if you want a change in fundamental behaviour, with no other motivation than "I prefer it", and provide a patch, it goes straight into the code base without consideration. This certainly makes me doubt whether continued use of TB is a good idea. About standards compliance: It is true that the MAY in RFC 5322 indicates optional behaviour - but the current behaviour doesn't even have a MAY, i.e. there is *no* basis in the standard for it. If you choose to not implement that MAY, the only remaining option in 5322 is to *only* include the original sender(s) as recipients (which actually is another MAY), i.e. the classical "reply to sender" behaviour (which is still available in TB). It is unfortunate that 5322 doesn't specifically discuss the "reply to sender" vs "reply to all" behaviour, but the RFCs typically only specify the "on the wire" behaviour, leaving the behaviour of applications as "implementation dependent". Bottom line is still that the earlier behaviour complied with what the standard says, while the current one does not.
Re: comment #28 Note that an extension can only be considered a temporary work-around and not a final fix. Until this is fixed in the "vanilla" Thunderbird, we remain at risk that subsequent Thunderbird changes will break the extension. We should not have to rely on the extension's developer repeatedly updating the extension.
Thanks from me too for pointing out the useful "Reply to All as Cc" add-on.
(In reply to kubek-93 from comment #28) > https://addons.mozilla.org/en-US/thunderbird/addon/reply-to-all-as-cc/ seems > as nice enough workaround. It's always funny finding workarounds for fixes > that work intentionally unintuitively. Thank you, kubek-93, for the pointer and to ClearCode Inc. for creating this add-on. It's unfortunate that we have to rely on this route for basic behavior that so many users relied upon, given that add-ons remain difficult to find and prone to breakage or abandonment. Having a hidden preference setting would at least take care of the latter, but having a discoverable option or separate commands would address all three. My greatest frustration, though, remains with those who rationalize decisions without investigating both the pros and cons of the options, and those who naively believe that everyone should work the way they do. Tools should help users complete their tasks in the way that works best for them, not try to force all users into a single mold.
I am sorry for all those who didn't like the change. I am one of those who wanted (I am pretty sure I like it this way, so no need to argue). I also think that it is better to have two buttons/options so that people can choose on the fly what to do. And everybody is happy. But, I am really typing this message to point another great add-on for those complaining about editing the To: and Cc: fields: "MRC Compose" - Provides 3 standards fields (TO, CC, BCC) with autocomplete to Thunderbird's compose pane. I wouldn't use Thunderbird without it!
I struggle with the new Reply All behavior since version 24.1. It always took a long time to convert the To: recipients into CC:. Sometime I have to do it for 50 recipients, which is a very long process. Thanks for the suggested "MRC Compose" addon which allow to do a quicker conversion... but I really preferred the Thunderbird recipient management... So bad they did not include an about:config parameter to alter the Thunderbird behavior.
(In reply to Per Hedeland from comment #33) > About standards compliance: It is true that the MAY in RFC 5322 indicates > optional behaviour - but the current behaviour doesn't even have a MAY, i.e. > there is *no* basis in the standard for it. If you choose to not implement > that MAY, the only remaining option in 5322 is to *only* include the > original sender(s) as recipients (which actually is another MAY), i.e. the > classical "reply to sender" behaviour (which is still available in TB). It > is unfortunate that 5322 doesn't specifically discuss the "reply to sender" > vs "reply to all" behaviour, but the RFCs typically only specify the "on the > wire" behaviour, leaving the behaviour of applications as "implementation > dependent". Bottom line is still that the earlier behaviour complied with > what the standard says, while the current one does not. Yes, that's how I read it as well. Nearly all of my daily email communication is affected by this, and it's a pain to manually have to change To recipients to CC every time you hit Reply All. The add-on works (not really in TB 60, but that was possible to patch), but shouldn't be needed.

With bug 440377 landed on daily, is now possible to copy and paste all the addresses at once from a recipient field to another.
This is not valid anymore.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME

(In reply to Alessandro Castellani (:aleca) (PTO to 17th Jan 2020, sporadically reading bugmail) from comment #40)

With bug 440377 landed on daily, is now possible to copy and paste all the addresses at once from a recipient field to another.
This is not valid anymore.

I'm sorry, but could you please elaborate on how "possible to copy and paste all the addresses at once from a recipient field to another" makes the problem `Provide a configuration option to allow "Reply All" behavior of moving "To" recipients to "Cc" field again' invalid? Modifying the set of To/Cc recipients was always possible, making it less cumbersome does not make the bad default behavior of "reply all" go away. The ask here is to at least provide a config option to make "reply all" behave as most users expect - i.e. having only the sender in To, and the other recipients in Cc. If such an option has been provided, please describe what it is - I certainly can't infer it from https://bugzilla.mozilla.org/show_bug.cgi?id=440377 . If not, this bug remains valid.

...having only the sender in To, and the other recipients in Cc.

My bad, I misinterpreted the issue from reading the old comments.
I arrived to the wrong conclusion that this request was originally created because of the extremely cumbersome workflow of changing multiple recipients from To to Cc.

I never noticed how other email clients handle this, would you be able to confirm this approach in other clients?

Magnus, what do you think about this request?

Flags: needinfo?(mkmelin+mozilla)
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

I think I commented enough above. Wouldn't change current behaviour but possibly there could be some option to do this for one-offs. Now sure what that would be. Maybe a context menu in the pills area.

Flags: needinfo?(mkmelin+mozilla)

That's surprising. You changed the behavior once, why not change it again? Or do you fear breaking workflows for some people?
"One offs"? People have clearly explained that the requested behavior applies to what they expect all the time, and that TB had used to do this for a decade, and that the RFC supports the idea. And that there are many other e-mail clients that have always behaved that way. And.... but I give up :) I already switched to another tool.

Curious if there is any update? The previous/preferred behavior was reintroduced/solved by this add on:

https://addons.thunderbird.net/en-US/thunderbird/addon/reply-to-all-as-cc/
https://github.com/clear-code/reply-to-all-as-cc

But the add on no longer works with the current version of Thunderbird (68.4.1).

Component: Composition → Message Compose Window
Product: MailNews Core → Thunderbird

Re: comment #34

The prophecy has been fulfilled.
The issue has been ignored until the workaround no longer works.
What now?

I'll take this and take care of adding a pref allowing users to choose the behavior.

Assignee: nobody → alessandro
Severity: normal → S3

Removing assignment as this will be the focus for after 115

Assignee: alessandro → nobody
You need to log in before you can comment on or make changes to this bug.