I find myself wanting this many times every single day. Since I suspect I'm not uncommon in that regard, and since it should be easy, I think it makes sense for this to block. Perhaps it also wants some sort of visual affordance to aid in discoverability. I believe davida had suggested "r", which sounds like a fine choice to me.

Yes! I find myself looking at the button, pressing cmd-r and then... big sigh... i don't get the reply I was expecting. 'r' seems like a reasonable second choice. My ideal case would be that we figure out a way to gracefully swap out the ctrl-r keybinding with our 'default reply' action. However if we did that and didn't have a fool proof plan I fear the damage we could cause.

(In reply to comment #1) > > My ideal case would be that we figure out a way to gracefully swap out the > ctrl-r keybinding with our 'default reply' action. Can you elaborate on what you mean by this?

I don't think it's going to be possible to do this well, I'm just whining. But an example of a (not so good) transition could be something like: - on first use of TB3 - * person views a message w/ a reply all or reply list default * person presses cmd-r * TB shows a dialog saying cmd-r now chooses the 'default reply' ** The dialog gives an option for the person to continue with this or revert back to the old behavior

Ok, so this morning I created an extension to do this. Source Code: http://hg.mozilla.org/users/clarkbw_gnome.org/the-real-reply Here is the released extension for download. http://hg.mozilla.org/users/clarkbw_gnome.org/the-real-reply/raw-file/tip/release/therealreply.xpi Here is your pseudo code for what this does. init() { document.getElement("reply_key").setAttribute("oncommand", "myReply"); } myReply() { for each ( reply_button in buttonbox ) { if ( ! reply_button.hidden ) reply_button.click(); } } In other words, I hijack the reply key code and stuff in my own function. In my own function I find the reply button that isn't hidden and send it the click event.

I'm going to submit that extension for review in the add-ons. I don't think this should block 3.0 as we can easily work around the solution for people who want this change. I don't like giving this the single 'r' key as it is already used (mark thread read) and doesn't feel like a good solution. 'Shift-r' was proposed as an alternative but we've been generally using the shift version as a reverse of the original key command (started by the 'j' junk command); also "shift-r" feels like a hack to grab a button and not a solution.

Is this extension, or a change incorporating it, going to be in the 3.0 release? I do very much like the behavior you described in comment 155 on bug 45715, although I disagree with at least one of the defaults, but I don't want to have to use the mouse to get the reply behavior I expect. This extension, or a comparable change, looks like it would fix that issue. (However, I can't presently test the extension to confirm that, as I'm running a 2.0 version of Thunderbird.)

With a little more tweaking I was able to finish my add-on against the new header buttons. I've put it up in the AMO site now for others to use. https://addons.mozilla.org/en-US/thunderbird/addon/15029 Currently the add-on is in experimental mode so you'll need to log-in to download it. Once this add-on goes public you should be able to search for it and install it from the Add-on manager via Tools -> Add-ons. There is very little UI to this add-on it simple alters the (Ctrl-R or Cmd-R) keyboard shortcut to activate the reply button you are seeing in the header instead of the (possibly) hidden reply to sender button.

I shouldn't be the assignee for these bugs. Filter against clarkbfilter to delete all these from your emails.