Thunderbird doesn't support RFC-2369 based Reply-To-List

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?

Created an attachment (id=192713)
Adds mailnews.clobber_list_reply pref to turn Reply All into Reply To List

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)

(From update of attachment 379240)
This part seems to be working fine now!

A few tiny nits, and you'll have to get sr for the mailnews/ bits too.

>+ <xul:menuseparator anonid="hdrReplyAllSubButtonSep" />

Drop the space before />

>+ let numAddresses = hdrParser.parseHeadersWithArray(uniqueRecipients, {}, {},
>+ {});

The 80 char limit isn't quite this strict, i think. Or move more than one of the {}s to the next line too.

>+
>+ // If I've been bcc-ed, then add 1 to the number of addresses to compensate.
>+ if (imBcced)
>+ numAddresses++
>+
>+ // By default, ReplyAll if there is more than 1 person to reply to.
>+ let showReplyAll = numAddresses > 1;
>+
>+ // And ReplyToList if there is a List-Post header.
>+ let showReplyList = currentHeaderData['list-post'];

Prefer to use " instead of ' when it's not needed to use '.
Here and later on.

>+ // But, if we're in a news folder, we should default to the Reply button.
>+ if (isNewsURI(msgHdr.folder.URI))

Should probably to the same for feeds (check msgHdr.folder.type == "rss")

>+
>+ // If it's a news message, show the ReplyAll sub-button and separator.
>+ if (isNewsURI(msgHdr.folder.URI))
>+ {
>+ replyAllSubButton.hidden = false;
>+ replyAllSubButtonSep.hidden = false;
>+ }
>+ else
>+ {
>+ // otherwise, hide them.
>+ replyAllSubButton.hidden = true;
>+ replyAllSubButtonSep.hidden = true;
>+ }
>+}

Comment placement isn't consistent here. Move the "// If it's..." inside the if clause

r=mkmelin with that

(In reply to comment #220)
> >+ <xul:menuseparator anonid="hdrReplyAllSubButtonSep" />
> Drop the space before />

Done.

> >+ let numAddresses = hdrParser.parseHeadersWithArray(uniqueRecipients, {}, {},
> >+ {});
> The 80 char limit isn't quite this strict, i think. Or move more than one of
> the {}s to the next line too.

Done.

> >+ let showReplyList = currentHeaderData['list-post'];
> Prefer to use " instead of ' when it's not needed to use '.
> Here and later on.

Done and done.

> >+ // But, if we're in a news folder, we should default to the Reply button.
> >+ if (isNewsURI(msgHdr.folder.URI))
> Should probably to the same for feeds (check msgHdr.folder.type == "rss")

Yeah, that doesn't seem to work.

I tested it, and there was no "type" attribute on msgHdr.folder, and when I looked through http://mxr.mozilla.org/comm-central/source/mailnews/base/public/nsIMsgFolder.idl#71 I didn't see anything that looked useful.

I hoped I could base my calculations off of the URI, but for my RSS feed, it's:
mailbox://nobody@Feeds/Blog-o%21
whereas for my Local Folders, it's
mailbox://nobody@Local%20Folders/Inbox/Admin
So that doesn't seem like a good thing to use.

If there's a way to differentiate RSS feeds from Local Folders, I would love to handle this case in the same way I handle the News case.

> >+ // If it's a news message, show the ReplyAll sub-button and separator.
> >+ // otherwise, hide them.
> Comment placement isn't consistent here. Move the "// If it's..." inside the
> if clause

Done.

> r=mkmelin with that

Thank you! There's a new patch with the changes I could make coming soon.

Later,
Blake.

Mistyped. It should be msgHdr.folder.server.type of course. For news the type is "nntp"

Note that msgHdr.folder is null for .eml files

Created an attachment (id=379741)
The patch with Magnus's suggested changes, and some more.

Magnus, I've added you for a review again because there were some non-trivial changes to the code in mail/base/content/mailWindowOverlay.js, to better handle News and Rss items, and .eml files.

Also, the new feature of hiding the Reply button entirely for Rss items was ui-review+ed by clarkbw over IRC, which is why I'm not asking for another ui-review.

Thanks,
Blake.

(From update of attachment 379741)
>+function getServerType(msgHdr)
>+{
>+ try {
>+ return msgHdr.folder.server.type;
>+ } catch (ex) {

catch on a new line

>+ // This empty catch block needs to be here because, although
>+ // msgHdr.folder will be null for .eml files, it will still throw an
>+ // exception when you try to access it.
>+ }
>+ return null;

But please just do this functionality inline instead of as a function. (And i think it should just say that it throws, not that it's null.)

Otherwise looks good to me.

Created an attachment (id=380027)
The latest version of the patch.

(In reply to comment #225)
> >+ try {
> >+ return msgHdr.folder.server.type;
> >+ } catch (ex) {
> catch on a new line

Done.

> >+ // This empty catch block needs to be here because, although
> >+ // msgHdr.folder will be null for .eml files, it will still throw an
> >+ // exception when you try to access it.
> >+ }
> >+ return null;
>
> But please just do this functionality inline instead of as a function. (And i
> think it should just say that it throws, not that it's null.)

Done, and done. I originally called the function twice, but later got rid of the second call, so I inlined the code.

> Otherwise looks good to me.

Thank you!
Blake.

(From update of attachment 380027)
in general, looks good.

Are you using these?

diff --git a/mailnews/base/public/nsIMsgDBView.idl b/mailnews/base/public/nsIMsgDBView.idl
--- a/mailnews/base/public/nsIMsgDBView.idl
+++ b/mailnews/base/public/nsIMsgDBView.idl
@@ -206,6 +206,9 @@
   const nsMsgViewCommandTypeValue applyFilters = 30;
   const nsMsgViewCommandTypeValue runJunkControls = 31;
   const nsMsgViewCommandTypeValue deleteJunk = 32;
+
+ const nsMsgViewCommandTypeValue replyToAll = 33;
+ const nsMsgViewCommandTypeValue replyToList = 34;
 };

Unless I'm missing a later use of msgURI, I think this:

+ let msgURI = GetLoadedMessage();
+ let msgHdr = messenger.msgHdrFromURI(msgURI);

can just be
+ let msgHdr = messenger.msgHdrFromURI(GetLoadedMessage());

once those questions are answered, this will be sr=me...

Created an attachment (id=380341)
Dare I say, the final version of the patch?

(In reply to comment #227)
> Are you using these?
> + const nsMsgViewCommandTypeValue replyToAll = 33;
> + const nsMsgViewCommandTypeValue replyToList = 34;

Nope. I've removed them.

> Unless I'm missing a later use of msgURI, I think this:
> + let msgURI = GetLoadedMessage();
> + let msgHdr = messenger.msgHdrFromURI(msgURI);
> can just be
> + let msgHdr = messenger.msgHdrFromURI(GetLoadedMessage());

Fixed.

Would one of you or Magnus please commit this when you get a chance?

In the meantime, I'll start working on the enabling/disabling patch.

Thank you,
Blake.

(From update of attachment 380341)
Checked in: http://hg.mozilla.org/comm-central/rev/98a7de404c08

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

Created an attachment (id=382128)
A patch to enable and disable the Reply-* menu options.

I now return true or false for the reply commands when they get checked in mail3PaneWindowCommands.js's and messageWindow.js's isCommandEnabled() method.

Created an attachment (id=382141)
 A patch to enable and disable the Reply-* menu options and toolbar buttons.

Re mail/base/content/msgHdrViewOverlay.js, line 417-418:

I also figured out that I don't need to call UpdateReplyButtons() from messageHeaderSink.onEndHeaders(), because that method calls UpdateMessageHeaders() which calls updateHeaderViews(), which calls UpdateReplyButtons().

I think we can get rid of the call to UpdateJunkButton() in messageHeaderSink.onEndHeaders() as well, for the same reason, but I haven't made that change in this patch.

(From update of attachment 382141)
This seems to work well, however I have a few nits.

Please capitalize the js method names like it's elsewhere in the file/s.

>diff --git a/mail/base/content/mail3PaneWindowCommands.js b/mail/base/content/mail3PaneWindowCommands.js
>--- a/mail/base/content/mail3PaneWindowCommands.js
>+++ b/mail/base/content/mail3PaneWindowCommands.js
>@@ -323,15 +323,25 @@
> goSetMenuValue(command, whichText);
> goSetAccessKey(command, whichText + "AccessKey");
> }
>+ let retval = false;

Mozilla code almost always use rv for that.

> if (GetNumSelectedMessages() > 0)
> {
> if (gDBView)
> {
> gDBView.getCommandStatus(nsMsgViewCommandType.cmdRequiringMsgBody, enabled, checkStatus);
>- return enabled.value;
>+ retval = enabled.value;
> }
> }
>- return false;
>+ if (retval)
>+ {
>+ if (command == "cmd_reply" || command == "button_reply")
>+ retval = isReplyEnabled();
>+ else if (command == "cmd_replyall" || command == "button_replyall")
>+ retval = isReplyAllEnabled();
>+ else if (command == "cmd_replylist" || command == "button_replylist")
>+ retval = isReplyListEnabled();
>+ }

Why aren't these higher up directly after each "case foo:"?

>+ return retval;
> case "cmd_printpreview":
> if ( GetNumSelectedMessages() == 1 && gDBView)
> {
>diff --git a/mail/base/content/mailWindowOverlay.js b/mail/base/content/mailWindowOverlay.js
>--- a/mail/base/content/mailWindowOverlay.js
>+++ b/mail/base/content/mailWindowOverlay.js
>@@ -807,10 +807,45 @@
> junkButtonDeck.selectedIndex = SelectedMessagesAreJunk() ? 1 : 0;
> }
>
>-function UpdateReplyButtons()
>+function getServerType()

Maybe name the method GetCurrentMsgServerType or something more descriptive?

> {
> let msgHdr = messenger.msgHdrFromURI(GetLoadedMessage());
>
>+ let serverType = null;
>+ try
>+ {
>+ serverType = msgHdr.folder.server.type;
>+ }
>+ catch (ex)
>+ {
>+ // This empty catch block needs to be here because msgHdr.folder will
>+ // throw an exception when you try to access it on a .eml file.
>+ }
>+ return serverType
>+}
>+
>+function isReplyEnabled()
>+{
>+ if (getServerType() == "rss")
>+ // If we're in an rss item, we never want to Reply, because there's
>+ // usually no-one useful to reply to.
>+ return false;
>+ return true;
>+}

Could just be |return getServerType() != "rss";|

Created an attachment (id=382384)
Disable menu items, with mkmelin's fixes.

(In reply to comment #234)
> This seems to work well, however I have a few nits.
>
> Please capitalize the js method names like it's elsewhere in the file/s.

Fixed.

> >+++ b/mail/base/content/mail3PaneWindowCommands.js
> >+ let retval = false;
> Mozilla code almost always use rv for that.

Fixed.

> > if (GetNumSelectedMessages() > 0)
> > {
> > if (gDBView)
> > {
> > gDBView.getCommandStatus(nsMsgViewCommandType.cmdRequiringMsgBody, enabled, checkStatus);
> >- return enabled.value;
> >+ retval = enabled.value;
> > }
> > }
> >- return false;
> >+ if (retval)
> >+ {
> >+ if (command == "cmd_reply" || command == "button_reply")
> >+ retval = isReplyEnabled();
> >+ else if (command == "cmd_replyall" || command == "button_replyall")
> >+ retval = isReplyAllEnabled();
> >+ else if (command == "cmd_replylist" || command == "button_replylist")
> >+ retval = isReplyListEnabled();
> >+ }
> Why aren't these higher up directly after each "case foo:"?

Because I only want to check them if
"gDBView.getCommandStatus(nsMsgViewCommandType.cmdRequiringMsgBody,
enabled, checkStatus);" returns true, and I didn't want to repeat the whole
"if (GetNumSelectedMessages() > 0)" block four times. (If there's a better
way to do this, I'ld love to change to it, but I couldn't think of one.)

> >+++ b/mail/base/content/mailWindowOverlay.js
> >@@ -807,10 +807,45 @@
> >+function getServerType()
> Maybe name the method GetCurrentMsgServerType or something more descriptive?

I've changed it to "GetLoadedMsgServerType", since I'm now using
"GetLoadedMsgFolder" (because it was doing the same thing I was).

> >+ if (getServerType() == "rss")
> >+ // If we're in an rss item, we never want to Reply, because there's
> >+ // usually no-one useful to reply to.
> >+ return false;
> >+ return true;
> Could just be |return getServerType() != "rss";|

Fixed.

Thanks,
Blake.

(From update of attachment 382384)
>diff --git a/mail/base/content/mail3PaneWindowCommands.js b/mail/base/content/mail3PaneWindowCommands.js
>--- a/mail/base/content/mail3PaneWindowCommands.js
>+++ b/mail/base/content/mail3PaneWindowCommands.js
>@@ -327,15 +327,25 @@
> goSetMenuValue(command, whichText);
> goSetAccessKey(command, whichText + "AccessKey");
> }
>+ let rv = false;
> if (GetNumSelectedMessages() > 0)
> {
> if (gDBView)
> {
> gDBView.getCommandStatus(nsMsgViewCommandType.cmdRequiringMsgBody, enabled, checkStatus);
>- return enabled.value;
>+ rv = enabled.value;
> }

While you're here, please combine this to one if statement, and then return early if (!enabled.value)

> }
>- return false;
>+ if (rv)
>+ {
>+ if (command == "cmd_reply" || command == "button_reply")
>+ rv = IsReplyEnabled();
>+ else if (command == "cmd_replyall" || command == "button_replyall")
>+ rv = IsReplyAllEnabled();
>+ else if (command == "cmd_replylist" || command == "button_replylist")
>+ rv = IsReplyListEnabled();
>+ }
>+ return rv;

Here too, no need for the rv, just |return IsReplyEnabled();| and so on

Forgot to mention it earlier, but some doxygen documentation for the new methods would be nice. Something along the lines of
/**
 * Get the folder type of the currently selected folder
 * @return the folder type, or null if we don't have a selected folder
 */

r=mkmelin with those

Created an attachment (id=382629)
Disable menu items with further tweaks.

(In reply to comment #236)
> (From update of attachment 382384 [details])
> >+++ b/mail/base/content/mail3PaneWindowCommands.js
> > if (GetNumSelectedMessages() > 0)
> > if (gDBView)
gDBView.getCommandStatus(nsMsgViewCommandType.cmdRequiringMsgBody, enabled, checkStatus);
> >+ rv = enabled.value;
> While you're here, please combine this to one if statement, and then return
> early if (!enabled.value)

Done.

> >+ if (command == "cmd_reply" || command == "button_reply")
> >+ rv = IsReplyEnabled();
> >+ else if (command == "cmd_replyall" || command == "button_replyall")
> >+ rv = IsReplyAllEnabled();
> >+ else if (command == "cmd_replylist" || command == "button_replylist")
> >+ rv = IsReplyListEnabled();
> >+ return rv;
> Here too, no need for the rv, just |return IsReplyEnabled();| and so on

Done.

> Forgot to mention it earlier, but some doxygen documentation for the new
> methods would be nice. Something along the lines of
> /**
> * Get the folder type of the currently selected folder
> * @return the folder type, or null if we don't have a selected folder
> */

Done.

> r=mkmelin with those

Thank you!

Created an attachment (id=382756)
One final patch, with some suggestions from mkmelin over email.

Somebody, probably asuth, bitrotted your patch enough that it fails to apply. Give us a new one, and we'll try to get it in before someone else rots it :)

Created an attachment (id=383284)
An un-bit-rotted version of the previous patch.

It's always nice when I can delete code (to get the server type) because someone else has written it for me. :)

Thanks,
Blake.

(From update of attachment 383284)
http://build.mozillamessaging.com/mercurial/comm-central/rev/8a5b8921a88b

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

(In reply to comment #188)
> 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.

I don't like this behavior.

When I am reading a post to a newsgroup and hit Ctrl-R, the reply is addressed
to the newsgroup. When I am reading a post to a mailing list and hit Ctrl-R, I
normally want the reply to be addressed to the mailing list.

The list of defaults in comment #155 seems fairly sensible (for the most part;
see below). I want to be able to use the same, single keyboard shortcut to
reply to any message and get that default. I would prefer for that shortcut to
be Ctrl-R.

I can understand that other people might not want that behavior, and I can even
see a couple of cases in the comment #155 list which don't match the behavior I
would expect. Would it be possible to have the defaults for each of those
specified situations be configurable in some way? For that matter, would it be
possible to have the keybindings be configurable, so that other people don't
have to have Ctrl-R mean what I want it to?

This bug is fixed so to avoid your comments being lost you should find an open bug with your issue or open a new one. I think you're looking for bug 500229 which was looking into a default reply for the new button.

Thank you; I'll do that. I had considered opening a new bug about this, but it didn't seem appropriate to quote a comment on this bug in a new one. That bug does look like the topic I'm after.

I disagree with Andrew B.

Ctl-R should go to whoever the "Reply-To" on the message is, whether that's a list or an individual.

(In reply to comment #246)
> I disagree with Andrew B.
>
> Ctl-R should go to whoever the "Reply-To" on the message is, whether that's a
> list or an individual.

Obviously, you completely misunderstand what the Reply-To header is for and what it is not for ...

http://www.unicom.com/pw/reply-to-harmful.html

http://woozle.org/~neale/papers/reply-to-still-harmful.html

Good thing the RFCs aren't law: http://marc.merlins.org/netrants/reply-to-useful.html

Guys, this bug is not about the Reply-To: header.

3.1's reply-to-list is working well for me. Great work, guys! Thanks!