User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040614 Firefox/0.9 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040614 Firefox/0.9 The Apple Mail.app has the ability to toggle "Reply" and "Reply to All" while composing a reply message. More detailed, you read a message sent to multiple addresses and click the reply button. A Message Composition window is opened with the sender's e-mail address in the To: field. In the Message Composition window there is a button that says "Reply to All". If the user clicks Reply to All, other recipients listed in the To: or CC: fields are added to the current message composition window exactly as if the user had origonally clicked "Reply to All" instead of "Reply". The "Reply to All" button should now be changed to simply "Reply" and if it is clicked again the extra To: and CC: recipients are removed as if the user had origonally clicked "Reply". Mac OS X's Mail.app has this feature and I think it's incredibly slick. I've found that I often hastily click "Reply" type a long message and then realize I really wanted to reply to all, then I have to select all text, close the window, click reply to all then paste the text and go back to my insertion point. It would be great to elimate the extra steps involved. Reproducible: Always Steps to Reproduce: 1. Click reply on a message sent to several addresses Actual Results: there is no ability to toggle "Reply" and "Reply to All" Expected Results: A button to toggle "Reply" and "Reply to All"

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

This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/

This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.

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

Let's reopen this one... sorry for the dupe in #346813.

This would be a useful feature to have.

Confirming RFE.

I would add what I pointed on Bug 464363 When you reply to a mail sent to multiple destinations you probably forget to click on Send to all and you just click on Send, losing all the addresses in the CC list. We should alert (in a non-intrusive way) the user that maybe he wants to Reply All instead of just Reply to the sender. A message like: "The mail you are replying was sent to other people too, do you want to reply all?" in the compose window that let you select if you want to reply all or not would be great. From my point of view this is an usability improvement.

I don't think this warrants a pop-up every time (and if people want a pop-up, that sounds more like extension material, not something that should be built in to Thunderbird). However, having the button, as in Mail.app, would be very useful.

I think it would be far less intrusive to let the user change their reply/reply-all setting during the composition process, by means of a button or other UI element on the compose form that does not require the user to click through every time they reply to a message. The proposed UI mockup would impose an unnecessary inconvenience.

Agreed.

So maybe we could add that button to the compose window and light it (bold or whatever) when you are replying to a multiple destinations email. It would be a non-intrusive way to tell the user "Ey, maybe you want to use me ;)"

Comment on attachment 347836 [details] Proposed UI mockup Marking obsolete as this proposal would be seriously annoying.

There's no click-through requirement for info bars, and there's even a "don't annoy me again" button in the mockup. I think I disagree about one being too intrusive -- how often do you reply to only some recipients, such that making it explicit this way would hurt? I enjoyed a bit of reply-all fail with gmail yesterday and being able to switch reply modes didn't help :) That said, the info bar as such doesn't have the flexibility of toggling modes, nor being able to switch without being explicitly warned, so it doesn't quite fulfill this bug's proposal... Here's gmail's ui, for reference. What does applemail's look like?

This image is broken into three sections. The first section shows the main Mail window. When viewing messages here, there is both a "Reply" and "Reply All" button. The second section shows the Compose window after having clicked "Reply". There is a "Reply All" button. The third section shows the Compose window after having clicked "Reply All". There is a "Reply" button. Clicking either the "Reply" or "Reply All" button in the Compose window will toggle the mode. Clicking "Reply All" will add all recipients to the CC field. Clicking "Reply" removes all recipients from the CC field. This behavior only takes place when the message is actually replying. New messages do not show the "Reply"/"Reply All" nor "Chat" buttons.

We could use background coloration of the address fields to indicate which ones were originally from a reply or a reply-to action, and that might help alert the user as to what is going on. If we decide against this, we should at least make sure that the information is available to extension writers who might want to add such functionality.

I'm not sure right now how to best represent this in the current compose window but a toggle at compose time is a needed piece of the solution to this complicated problem of reply/reply-all

It seems like Apple's UI isn't entirely unreasonable, as long as one has the button text labels enabled. When the text labels aren't there (as per the screenshots in comment 19), I find the UI fairly non-obvious.

Assigning this to bwinton as he is fixing our reply / reply all issues one interaction at a time. Lets work on some solutions to this. Because our default has changed to a reply all button when appropriate I think having this toggle will likely be especially important for people transitioning. I think we have two goals, remind the person how many people they are replying to and offer a way to switch between reply all and reply. The reminder is important because we're defaulting people to reply all and we want to avoid having them embarrass themselves. I'm thinking of a notification bar like reminder. The problem with this reminder is that we know when people see something like this all the time they tend to ignore it and then it loses its value for when it would be truly important. I think this might be possible to overcome by removing the notification after a certain timeout. Removing the notification will give it an automatic bit of attention, however if our buttons were in the notification they would be gone after the timeout. I'll post up a mockup of the notification bar in a minute. I'd love to hear other ideas or comments.

please ignore the text an button of this info bar. I was mostly testing if I could style it to fit flat in the area. This is a mockup of the reminder area where I think we could give people a double heads up when they are replying to all. We should probably only show this notification if the message came from hitting the default reply all button; though it might be useful otherwise as well. I don't think having our only toggle in the notification is going to make sense. I think we should remove the notification after a little while and if the person selected reply and then wanted to reply all this notification would not be around. Better text for this might be something like: "This message is replying to $X people" With a button that says: ( Reply only to sender@example.com ) Where we do a max-width limit of the button to make sure the email address doesn't give us a ridiculously large button. As for the reply all / reply toggle we could probably try something in the toolbar to achieve this but I haven't played around with that just yet.

I'm warm (but not hot) to the UI mockup, but have no further suggestions for improving it at this time. However, I think that if we go the notification bar route, the bar should always be present unless the user disables it. Perhaps we could change the background to yellow when the user is replying to multiple recipients, and leave it gray when replying to one. That would help get people's attention even after they've seen it a hundred times, and would provide a consistent place for the Reply-one/Relpy-all toggle. Unless, of course, the user disables the bar, in which case I don't know what would happen to the button.

The infobar mockup seems to me to miss the key point. In the vast majority of cases (can Reply-To be multivalued?), the difference will be between one person and multiple people. So you are looking for a $X being 1 or some other figure. That's not much difference to notice. Instead, how about: All N recipients of the original message will get this reply. [Reply Only To Sender] Only the original sender will get this reply. [Include Other Recipients] These start with different text, and the buttons are clear about what's going on. Also, the two infobars should be different colours. IMO, the second one (you aren't replying to everyone in the conversation) should be a more attention-grabbing colour than the first. Perhaps the first grey and the second infobar-yellow? Later, it would be really great to have proper list header support, and have: The entire list will get this reply. [Reply Only To Sender] Only the original sender will get this reply. [Reply To List] Gerv

The behaviour of the "Reply All" and "Reply to List" buttons appears to have changed in the last nightly update (Gecko/20090616 Shredder/3.0b3pre). Now, if you click on an email message with only a single recipient, the "reply all" button is greyed out. Similarly, if the email is from a list, the "Reply to List" button is greyed out. Can the previous behaviour be re-instated, please? I.e. regardless of whether Shredder thinks that you shouldn't be able to do a reply-all or reply-to-list on a message, you can still click these buttons and get a meaningful result? The previous behaviour was good from a usability point of view. The current behaviour is not.

(In reply to comment #29) > Similarly, if the email is from a list, the "Reply to List" button is greyed > out. Just to double-check, you meant to say "if the email is _not_ from a list" up there, right? (Cause otherwise it's a bug I should fix.) > regardless of whether > Shredder thinks that you shouldn't be able to do a reply-all or reply-to-list > on a message, you can still click these buttons and get a meaningful result? What result were you expecting when you clicked on reply-to-list or reply-all? Should it be the same as clicking reply, or should something else happen? Thanks, Blake.

> Just to double-check, you meant to say "if the email is _not_ from a list" > up there, right? (Cause otherwise it's a bug I should fix.) yes correct, sorry. %e-typo. > What result were you expecting when you clicked on reply-to-list or reply-all? > Should it be the same as clicking reply, or should something else happen? I would agree it should be the same as clicking "reply", yes. However, for the past couple of days, when you select an email in the mail list pane, TB checks both for multiple recipients and if the email came from a list, and will grey out the "reply all" and "reply to list" buttons if it thinks that there was only a single recipient, or that the email wasn't from a mailing list, respectively. Obviously, when the button is greyed out, you can't click it. I'm using the OS/X client.

(In reply to comment #29) > > Can the previous behaviour be re-instated, please? I.e. regardless of whether > Shredder thinks that you shouldn't be able to do a reply-all or reply-to-list > on a message, you can still click these buttons and get a meaningful result? Please file a separate bug for that; this bug is specifically about the compose window. > The previous behaviour was good from a usability point of view. The current > behaviour is not. Off the top of my head, I can imagine at least one reason why the above statement might well be true; however, it's not clear to me that it necessarily is. It would be helpful in the new bug if you could explain in more detail what has you convinced... Thanks!

(In reply to comment #28) > Instead, how about: > > All N recipients of the original message will get this reply. [Reply Only To > Sender] > Only the original sender will get this reply. [Include Other Recipients] > > These start with different text, and the buttons are clear about what's going > on. Also, the two infobars should be different colours. IMO, the second one > (you aren't replying to everyone in the conversation) should be a more > attention-grabbing colour than the first. Perhaps the first grey and the second > infobar-yellow? I like the idea of a difference in text however I'm not certain yet that we want to show the info bar for anything other than downgrading a reply all to a reply. I think the other cases are useful and perhaps these should be different bugs but I'm most concerned about saving embarrassment right now. With the new buttons we default to open discussion (reply-all, reply-list) now so there are a couple 'embarrassment use cases' I'm most concerned about. 1. List alias e.g. memo-list@example.com When someone sends a message to this alias we default to the reply-all return which sends back to the list and the original sender. There's no detection for an alias other than heuristics but many companies use these group addresses and it's a cause for concern as we are defaulting to open discussion. I'm sure you've seen lots of these where someone replies to the alias and the person with a personal message that shouldn't have gone to the alias. 2. Group discussion via multiple to or cc addresses w/ back channel A discussion between 100 people on a cc list and you want to send a back channel "I can't stand person $X" message. We default to reply-all and you send that back channel message to everyone instead of the original sender. 3. Mailing list back channel message Similar to a group discussion since we default to reply-list when a list is detected a message will first be addressed to the list and not to the sender. 4? BCC'd Another one I think might be interesting to detect at this point is when you were BCC'd on a message since our default is to reply to all the recipients and yet they might not know you were CC'd. --- I've been looking at two goals for this bug. First (and I believe most important) is to reduce embarrassment by reminding people how many people they are sending the message to; this is especially important because of our new defaults. The other secondary goal is to help people toggle between the different types of replies that were available from the original button. Reducing embarrassment might use the notification bar with text as you suggested to help people step out of the open discussion. Toggling between the different possible reply types might use a simple combo chooser located somewhere in the compose window. They don't have to be the same UI point, thought they could be if it makes the most sense.

I have an alternate set of mockups to try for the toggle situation. This might also help by giving a new notification space; something I thought of this weekend. Prepare to receive!

here's a tabbed toggle approach. I've taken up the normal address entry space with tabs that specify what type of reply is going to happen. The reply type the compose window was activated with (reply, reply-all, reply-list) would be the tab that is focused by default. Each tab has an 'edit' link in the tab that would open up the "Edit" tab (that needs a better name) populated with the reply type recipient list. So if you were looking at the Reply All tab and clicked edit the Edit tab would be filled with the Reply recipients. And if you clicked edit on the Reply tab the Edit tab would be filled with the reply recipient. This Edit tab is meant to allow people to customize the recipient list beyond the normal lists provided in the tabs. I could have closed the vertical space up for tabs that don't require much text but then clicking on the Edit tab would create a layout change to assume the extra space. So you can see that I added in a protovis graph to show that we could use this space for extensions or interesting facts that might help the person replying. There is a possibility for other options. In general I like the idea that we could present a textual representation of your reply option just like might be included in a notification space (not that I think it would be needed with this tab approach). For a Reply All we could actually show the total numbers and give a statistical overview, something that wasn't possible with the list. Instead of a notification bar we could use the extra space acquired to let people know that they are replying to everyone with links to change to the reply-to-sender-only tab instead. I have another mockup to show what the Edit tab would look like when chosen from the Reply All tab. coming next... If you were composing a new message these tabs would not show at all and you would only see the address entry area. There might be other similar ways to use a deck that covers the addressing area instead of using tabs but the tabs seem to provide the exact mechanism needed for the right interactions.

here's the edit tab. This is basically to show that we continue to use the same addressing widget underneath. We've only covered it with tabs that insert the right addresses into the widget automatically. When someone goes into the Edit / Manual tab everything functions as it would normally now.

I don't think you need a separate Edit tab. Make "Reply All" editable, and if you start editing, the text changes to "Reply Some" or similar. If you do keep it this way, it needs a better name - "Edit" is too generic". It might be easier to grok if it weren't the leftmost tab, as one reads them left to right. Presumably "Reply List" won't be there if the original was not a mailing list message? I'm not sure what it means to say "Only 10% of replies to David Ascher were like this one." 10% of all replies? 10% of your replies? What about context? Surely 99% of replies in private conversations will be like this one, but only 5% of replies to mailing list messages... Gerv

We could try inserting the addressing widget under each tab after you click edit. I felt like that might complicate the implementation and some of the interactions. If we make it swap from Reply All into an "edit mode" then we'll need a way for people to get back to that original state via an option to "return to original reply all". Blake suggested "Custom" for a tab name yesterday and I think it might work as a better title than "Edit". One interaction that isn't clear is that I assume that the Custom tab is pre-filled from whatever tab list you came from last. If you were looking at the reply-list tab and clicked "Custom" you'd see the reply-list entry in the addressing fields. If you selected each tab one after the other the last tab you looked at before you saw the custom tab would pre-fill it. Once you edit the custom tab I think we need to require a specific 'edit' click interaction to change the custom fields such that work isn't lost by changing tabs but there is a way to reset the custom. Right! The reply list, like any of the other tabs (reply all), would only be available if it was possible; just like the buttons in the header. Hmm, I should have left the graphic out of the mockup. The only talking point I wanted for it was to show that we could do other things than just list email addresses. A simple text only example of how to do the Reply All better could be that we should the first ~10 contact names but mostly use summary analysis. _____________ --------| Reply All |------------------------ This is a reply to everyone. recipient1, recipient2, recipient3, ... N recipients total <a>Reply only to <sender@example.com>?</a> --------------------------------------------- I really need to do a real mockup of that to get the message across clearer but those are the basic elements; mostly summary information and less listing of every email address.

Tabs for this seems confusing to me. And complex, especially compared to the very simple proposal to just have a button to toggle - https://bug248681.bugzilla.mozilla.org/attachment.cgi?id=349420

Given that these are effectively just toggles with help text (which, in theory, one might expect to feel fairly simple), can you elaborate at all on that feeling and what might be triggering it?

It's just a mockup of course, but the confusion is that from https://bug248681.bugzilla.mozilla.org/attachment.cgi?id=384554 i couldn't tell which action i'm actually taking since "Edit" is on the same level as the actions.

Or well, they aren't actions but help text, but there you go... ;)

The thing about tabs is that people see them as ways of fitting more stuff into a small space - but things don't get deactivated just because you can't see them. My Firefox preferences don't reset if I switch to another tab before clicking commit. Switching tabs is almost always an activity with no side-effects. Therefore, saying that who the message gets sent to is affected by which tab I have selected when I click "send" seems wrong. I think Custom is a better name. But I don't think it should be pre-filled from the last tab you selected; that's even more tab-non-idempotency. It should start with everyone possible, and allow you to remove people with one click per person. Why would you ever want to start with the one guy who sent it, and add back the other CCs by typing them in? Or have I misunderstood? I'd still like a subtle hint of what type of reply it is, using the background colour of the compose window. White for normal, pale yellow for reply all, and pale blue for reply-to-list or something like that. Then I wouldn't need to scan the header to work out what Thunderbird had chosen for me. Gerv

I also got a bit confused by the tabs. In the gmail screenshot in #18, the send and composition controls are inside the tabs, while the tabs are at the same level in the mockup in #36, so I thought all of the actions would happen once you hit send. Desinging Interaces [1] lists some possible controls on p 210 for selecting one of N items, where N is small. I'm not handy with text mockups, so I did them on paper. From top to bottom: Radio buttons Pro: all choices visible Con: High Space consumption Dropdown list Pro: low space consumption Con: only one choice visible at a time. Icon toogle Pro: low on space and all visible Con: Can be cryptic and hard to understand. 1. http://www.amazon.com/Designing-Interfaces-Patterns-Effective-Interaction/dp/0596008031/ref=sr_1_1?ie=UTF8&s=books&qid=1245931476&sr=8-1

(In reply to comment #43) > Switching tabs is almost always an activity with no > side-effects. Therefore, saying that who the message gets sent to is affected > by which tab I have selected when I click "send" seems wrong. That makes sense. What about this: You need to click Reply, Reply All, or Reply To List to get to the compose screen in the first place. Custom could then be pre-filled from whichever option you selected, and maintain its state no matter which tab you click on. Does that sound reasonable? > the last tab you selected; that's even more tab-non-idempotency. It should > start with everyone possible, and allow you to remove people with one click > per > person. Why would you ever want to start with the one guy who sent it, and add > back the other CCs by typing them in? Or have I misunderstood? That would be another good option. > I'd still like a subtle hint of what type of reply it is, using the background > colour of the compose window. White for normal, pale yellow for reply all, and > pale blue for reply-to-list or something like that. Then I wouldn't need to > scan the header to work out what Thunderbird had chosen for me. Sounds neat. Subtle, and I worry that it might conflict with the other colours, but definitely neat. :)

Blake: your suggestion doesn't seem to me to fix the no-side-effects problem. AIUI, you are still proposing that if when the Reply tab is chosen when Send is clicked, the message will go to one person, whereas if the Reply All tab is chosen when Send is clicked, it will go to multiple people. I think less is more. Let's cut it down to the two most likely scenarios in each case, and provide a toggle between the two. The user can always edit the existing visible list if they want something custom. Message to one recipient: no UI, does Reply Sender Message to multiple recipients: default Reply All excluding self, button to toggle to Reply Sender Message to list: default to Reply List button to toggle to Reply Sender Message to list and others: default to Reply List, button to toggle to Reply All. (If they want Reply to Sender, they can edit the list manually.) Hitting a toggle just adds or removes the relevant people from/to the existing editable addressee widgets. If we tweaked the background colour, then we could just have a standard toolbar button with a tooltip to explain it. If we don't tweak the background colour, I agree we need more prominence, so it would probably have to be on an infobar. Gerv

(In reply to comment #43) > The thing about tabs is that people see them as ways of fitting more stuff into > a small space - but things don't get deactivated just because you can't see > them. My Firefox preferences don't reset if I switch to another tab before > clicking commit. Switching tabs is almost always an activity with no > side-effects. Therefore, saying that who the message gets sent to is affected > by which tab I have selected when I click "send" seems wrong. Since the "send" button is on one of the tabs rather than outside of tabs it makes some sense that the tab caption also applies to one of the tabs. The problem with tabs is that there is no clear and non-confusing way to add editing - perhaps the tab or radio would automatically change to "Custom recipient list" when you type something in one of the address fields. > > I think Custom is a better name. But I don't think it should be pre-filled from > the last tab you selected; that's even more tab-non-idempotency. It should Not if editing the addressing fields automagically creates and changes to the "Custom" tab. > start with everyone possible, and allow you to remove people with one click per > person. Why would you ever want to start with the one guy who sent it, and add > back the other CCs by typing them in? Or have I misunderstood? Perhaps you want to reply to the sender (or one of the other 100 guys which were CCd) and another person that was not in the original CC list. How do you do that if you start with a list of 100 and have to click 99 times to get almost where you wanted to be? > > I'd still like a subtle hint of what type of reply it is, using the background > colour of the compose window. White for normal, pale yellow for reply all, and > pale blue for reply-to-list or something like that. Then I wouldn't need to > scan the header to work out what Thunderbird had chosen for me. How would that work with theming? I already have almost invisible addresses in Thunderbird because they are blue and my GTK background is blue-green. (In reply to comment #44) > Created an attachment (id=385083) [details] > examples of different controls > > I also got a bit confused by the tabs. In the gmail screenshot in #18, the send Gmail is primarily confusing because the reply controls are inline inside the message thread and are not prominent enough. This way you are typing something inside a box in the middle of a long page which has on yet another place the information what you are actually doing. Thunderbird reduces confusion by opening a new compose window for each reply that has all controls always in the same place so it's easily visible in what state they are. > > From top to bottom: > Radio buttons > Pro: all choices visible Con: High Space consumption This is pretty much the same as tabs. > > Dropdown list > Pro: low space consumption Con: only one choice visible at a time. Con: confusing - cryptic non-obvious selection. > > Icon toogle > Pro: low on space and all visible Con: Can be cryptic and hard to understand. I for myself can say that I had no problem understanding the Apple Mail interface which duplicates the Reply/Reply All buttons from the message view in the message composition window. If the message composition window was the only thing you ever see it might have been hard to understand but to get in one you had to click one of those buttons already so you know what they are doing. Context is important. The other pro is that the buttons do not occupy additional space - the toolbar is already there. (In reply to comment #45) > (In reply to comment #43) > > Switching tabs is almost always an activity with no > > side-effects. Therefore, saying that who the message gets sent to is affected > > by which tab I have selected when I click "send" seems wrong. > > That makes sense. What about this: > You need to click Reply, Reply All, or Reply To List to get to the compose > screen in the first place. > Custom could then be pre-filled from whichever option you selected, and > maintain its state no matter which tab you click on. > > Does that sound reasonable? No, not at all. This takes us back to the situation this bug report was trying to resolve. You click the wrong button, type some text, and there is no way back.

(I'm setting the priority to P5 for now, because we don't have a clear UI for it, and so I can't really do much work on it. I'll re-up the priority once there's a UI that we all can agree on (or at least live with ;).)

The latest UI suggestion (via IRC) for this was really good both for usage and because it has an easy example to point everyone to. This is modeled after the Firefox Privacy prefs that are in nightlies and maybe 3.5? The basic design is a combobox option that shows the current reply mode you are in, one of Reply, Reply All, Reply List, and Custom Recipients with a text representation for each of the reply modes and the current address editor for the custom mode. = Reply All Mode = ( Reply All | v ) You are replying to all *20* of the participants in this conversation. jen@example.com, joe@example.com, ... = Reply List Mode = ( Reply List | v ) You are replying to this conversation via the mailing list. list@example.com = Reply Mode = ( Reply | v ) You are replying only to the original sender of this conversation. jen@example.com = Custom Recipients Mode = ( this would just display the current address table populated from the mode that opened the window ) A lot of time can be spent on exactly what to say and show in the text area representation corresponding to each reply mode. I just whipped those up in a couple minutes to demonstrate. However I think this idea is solid. It uses the right control (unlike the tabs) to give a firm understanding of what option is selected. The custom recipients option here doesn't have to handle odd modes of what tab the person came from, likely it would just always show mode that opened the window. Additional options could be explored to optimize switching to reply and then customizing that.

Like it, but can we de-word it a bit? ( Replying To All Participants | v ) fred@bedrock.com, bill@bedrock.com *, wilma@bedrock.com, ... ( Replying to List | v ) Flintstones List <flintstones-list@bedrock.com> (Replying to Sender | v ) Barney Rubble <barney@bedrock.com> (Customize Recipients ... | v ) To: fred@bedrock.com CC: wilma@bedrock.com BCC: betty@bedrock.com Gerv

In that case, I'm making it the P1 of my TB3-wanted list. (Which I figure comes after all the TB3-blocking bugs, but there aren't a lot of those.)

That gives a blank startup pane so it's hard to "see" what's planned (but i guess you might have known that).

Still not production ready, but perhaps more interesting to look at. :) Thanks, Blake.

In the previous driver meeting we had talked about having the backend only parts of this bug block. The UI will take a bit of work to get right but we will have to continue that in an add-on. However that add-on is not really possible to work on the until we get the backend code landed. I'm marking this as a P3 blocker though, which means only 1 hour past release, so if we can't get to this by then we'll just have to wait until 3.1

The WIP patch will introduce one new string and we have only 6 days until the l10n cutoff date. This is not acceptable so late in the release cycle. I'm therefore re-nominating this bug with the clear recommendation to deny blocking status for 3.0 and move this feature to 3.1.

Indeed, the WIP patch does not block Thunderbird 3.0. However, the backend-only part of it does. See comment 55. I agree that it's confusing to track these in the same bug; if you prefer to split them apart, feel free.

I'm pretty sure I'm doing some things wrong here, but it's a start. Any comments welcome, particularly about these lines near the end: ConvertRawBytesToUTF16(_compFields->GetAllReply(), charset.get(), replyCompValue); nsAutoString undupedCc; ConvertRawBytesToUTF16(resultStr.get(), charset.get(), undupedCc); replyCompValue += undupedCc; _compFields->SetAllReply(replyCompValue); _compFields->SetCc(resultStr.get()); Thanks, Blake.

Comment on attachment 409134 [details] [diff] [review] A first cut at the back-end patch. Okay, I'll request r/sr, and see if I can get some comments that way. ;) Thanks, Blake.

Comment on attachment 409134 [details] [diff] [review] A first cut at the back-end patch. Thanks to very nimble footwork, I've avoided being a mailnews/ peer.

Comment on attachment 409134 [details] [diff] [review] A first cut at the back-end patch. this code doesn't comma separate the undupedCc from the original replyCompValue,which it needs to do if replyCompValue is not empty. ConvertRawBytesToUTF16(resultStr.get(), charset.get(), undupedCc); replyCompValue += undupedCc; _compFields->SetAllReply(replyCompValue);

I looked at the rest of the patch, and I'm running with it at the moment. It seesm fine, but you might want to audit the rest of it for the ',' issue (it does seem to be handled in other places).

I've gone through the uses of +=, and changed them to use Append, then I went through the uses of Append, and made sure I was checking the isEmpty and adding the ", " where appropriate. Then I figured out what I was actually trying to do with the duplicate address checking, and so I implemented that. I think. Finally, replying to news doesn't really do the right thing, but I'm not sure whether we care about that for the blocking part of this patch or not. Thanks, Blake.

Comment on attachment 409445 [details] [diff] [review] The previous patch, with bienvenu's nits fixed, and duplicate addresses checked for. >+ /** >+ * Addresses for the other forms of reply. >+ **/ nit: only one star on the last line. >+ if (! mailFollowupTo.IsEmpty()) >+ { // handle Mail-Followup-To (http://cr.yp.to/proto/replyto.html) >+ compFields->SetAllReply(mailFollowupTo); nit: please put the comment on the new line (several places). > if (type == nsIMsgCompType::ReplyAll) > { >- mHeaders->ExtractHeader(HEADER_TO, PR_TRUE, getter_Copies(outCString)); >- ConvertRawBytesToUTF16(outCString, charset.get(), recipient); >- mHeaders->ExtractHeader(HEADER_CC, PR_TRUE, getter_Copies(outCString)); >- ConvertRawBytesToUTF16(outCString, charset.get(), cc); >- > // preserve BCC for the reply-to-self case >- mHeaders->ExtractHeader(HEADER_BCC, PR_TRUE, getter_Copies(outCString)); > if (!outCString.IsEmpty()) > { > nsAutoString bcc; > ConvertRawBytesToUTF16(outCString, charset.get(), bcc); > compFields->SetBcc(bcc); > } Did you really mean to remove the HEADER_BCC line? Without it, outCString would be set to the HEADER_MAIL_FOLLOWUP_TO value. > if (! mailFollowupTo.IsEmpty()) > { // handle Mail-Followup-To (http://cr.yp.to/proto/replyto.html) > compFields->SetTo(mailFollowupTo); > } > else > { // default behaviour for messages without Mail-Followup-To > if (!recipient.IsEmpty() && !cc.IsEmpty()) > recipient.AppendLiteral(", "); This looks like it is going to be doing something it has already done...

(In reply to comment #64) > >+ **/ > nit: only one star on the last line. Fixed. > >+ { // handle Mail-Followup-To (http://cr.yp.to/proto/replyto.html) > nit: please put the comment on the new line (several places). Fixed. > > // preserve BCC for the reply-to-self case > >- mHeaders->ExtractHeader(HEADER_BCC, PR_TRUE, getter_Copies(outCString)); > Did you really mean to remove the HEADER_BCC line? Without it, outCString > would be set to the HEADER_MAIL_FOLLOWUP_TO value. Nope. Good catch. Fixed. > > { // default behaviour for messages without Mail-Followup-To > This looks like it is going to be doing something it has already done... Fixed. Thanks, Blake.

Comment on attachment 409949 [details] [diff] [review] The previous patch, with Standard8's nits fixed. Neil seems kinda busy, and is going on vacation soon, so I'm going to re-assign this to Bienvenu.

Comment on attachment 409949 [details] [diff] [review] The previous patch, with Standard8's nits fixed. Do you really need the if check here? + if (!replyCompValue.IsEmpty()) + compFields->SetAllReply(replyCompValue);

(In reply to comment #67) > (From update of attachment 409949 [details] [diff] [review]) > Do you really need the if check here? > + if (!replyCompValue.IsEmpty()) > + compFields->SetAllReply(replyCompValue); I think so, if there's a message with no To, From, or Cc, but I might want to move the check down to after we check for duplicates (so that we don't have a reply which just contained our identity ending up as the empty string). Actually, in that case, probably not. I'll remove it. Thanks, Blake.

Backend patch committed as: http://hg.mozilla.org/releases/comm-1.9.1/rev/7b68edce5121 http://hg.mozilla.org/comm-central/rev/5f3fdf45a99f And with that in, I'm going to mark this as closed, and take dmose's suggestion from comment #57 to split the front-end work off to 525070, since tracking these in the same bug is, indeed, confusing. Later, Blake.