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

[Jan Claeys]

Thunderbird doesn't support RFC-2369 based Reply-To-List and because of that people use Reply-To-All is a substitute. This causes people to get double copies of the same mail which can be annoying (resulting in mailing list flamewars etc. ;-) ).

The Thunderbird 3.0 branch has a fix for this, but that's not very useful (it will be at least a year before it gets released). Recently someone who wrote an extension that uses the fix also made a patch for the 1.5 and 2.0 branches though, so I think we should include this into edgy (and maybe later to dapper backports/updates?). Provided the patch doesn't break other things of course...

http://open.nit.ca/wiki/index.php?page=ReplyToListThunderbirdExtension

[Sol-formerly-netscape (sol-formerly-netscape)]

Moving to future milestone.

[Akkana Peck (akkzilla)]

Adding helpwanted since it's milestone future.

[Matt-nightrealms (matt-nightrealms)]

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

[Planb (planb)]

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.

[Mbabcock-mozilla (mbabcock-mozilla)]

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

[Mbabcock-mozilla (mbabcock-mozilla)]

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

[Ben-bucksch (ben-bucksch)]

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

[Ben-bucksch (ben-bucksch)]

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.

[Ben-bucksch (ben-bucksch)]

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.

[Julius Schwartzenberg (jschwart)]

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

[Michael R. Bernstein (webmaven)]

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

[Jg-jguk (jg-jguk)]

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

[Christian Biesinger (cbiesinger)]

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

[Ajschult (ajschult)]

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

[Michael R. Bernstein (webmaven)]

<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.

[Nobody-spamhole (nobody-spamhole)]

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!

[Nobody-spamhole (nobody-spamhole)]

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

[Jonasj-qio (jonasj-qio)]

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

[Davidpjames (davidpjames)]

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.

[Bugz-sussexheights (bugz-sussexheights)]

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

[Mscott-mozilla (mscott-mozilla)]

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

[Pdundas-bfsec (pdundas-bfsec)]

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

[Ben-bucksch (ben-bucksch)]

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

[Åsmund Steen Skjæveland (aasmunds)]

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?

[Matthew-mxtelecom (matthew-mxtelecom)]

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.

[Toralf-procaptura (toralf-procaptura)]

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.)

[Moz-bugzilla (moz-bugzilla)]

(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.

[Mozilla-hireahit (mozilla-hireahit)]

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.

[Christian Weiske (cweiske)]

(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.

[Bugzilla-mozilla-roelschroeven (bugzilla-mozilla-roelschroeven)]

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.

[Tbertels+bugzilla (tbertels+bugzilla)]

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

[Timur Tabi (timur-tabi)]

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.

[Bugzilla-ojkastl (bugzilla-ojkastl)]

> (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"?

[Timur Tabi (timur-tabi)]

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.

[Mnyromyr (mnyromyr)]

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.

[Bugzilla-ojkastl (bugzilla-ojkastl)]

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.

[Toralf-procaptura (toralf-procaptura)]

(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.

[Matthew-mxtelecom (matthew-mxtelecom)]

(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.

[Akkana Peck (akkzilla)]

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).

[Toralf-procaptura (toralf-procaptura)]

(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)

[Tbertels+bugzilla (tbertels+bugzilla)]

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

[Greyed (grey)]

Ok, hitting on a few comments here so bear with me.

1: First and foremost the functionality should be configurable at the folder
level. All discussion about default behavior is all well and good but allowing
the user to change the default to suit their preference is paramount. Folders
simply don't have enough configurability as it stands right now.

2: The reply-to-list should be placed on reply and not reply-to-all. This is
because one is replying... to the list. Not replying to all but only really the
list. As pointed out this mirrors what happens in newsgroups which is what
mailing lists most resemble.

3: Reply-to-sender could be made a drop-down. In fact reply should have a drop
down with reply-to-sender, reply-to-list and reply-to-all which all do just that
regardless of context or the (lack of) presence of other buttons.

4: Shoving said fuctionality onto yet another button is a bad idea. We already
have 2 reply buttons. That's valuable screen-estate that shouldn't be cluttered
(by default) unless the user does the cluttering. Quite frankly I'd kill to
have "delete & next", "delete & previous" and then have delete change to "delete
and close" long before another reply button. Reason being is that I delete far
more mail than to which I send a reply. Often used options get a button and
ideally a shortcut. Less often used options get a drop down. Least used
options get a menu item.

With that in mind what do I personally do most often on mailing lists? Reply,
to the list. Reply, to the sender maybe 1% of the time of Reply, to the list.
Reply to all... never. So I'd be more than happy with an overloaded reply
button which was reply to sender in the absence of mailing list headers, reply
to list with the presence of mailing list headers, allowed me to override the
behavior through a drop-down as needed or, in extreme cases, have the folder set
to a default behavior and override what the context would dictate. With that I
could drop reply-to-all off my button bar, have all the functionality I want in
1 button which did the right thing 99.9% of the time and yet allow me to
intelligently correct it the other .1% of the time. That's something that can't
be said about shoving it into another button or on the reply-to-all button. ;)

[Shriramana Sharma (jamadagni)]

Okay here is my contribution...

First of all I would like to see this fix done very soon! Thanks Matthew!

Now observe the tooltips (on Win XP) of SM Mail (20050813 build) -

"Reply All - Reply to Sender and All Recipients" - that's good.

"Reply - Reply to the message". Wow, can you get more ambiguous (w.r.t the
present topic) than that? It doesn't say that you reply to the original sender.
Just "to the message".

AFAI am concerned, I always think of the Reply button as something which sends
mail back to the from address (unless there's a separate reply-to address
entered by the sender). I think of the Reply All button as something that sends
the mail to all those people involved in the mail I received. And "all those
people involved" is determined by possibly multiple To addresses and CC
addresses as provided by the person who sent the mail I am replying to.

So I think that Reply should be renamed Reply Sndr (hey, if "Get Msgs" is okay,
then why not "Reply Sndr"?) and Reply All should change itself to Reply List
whenever the mail being viewed has a List-Post (or other applicable) header. To
provide for the rare case that a posting to a list also has other To headers or
CC headers, then a drop-down box ("small triangle button") should be provided so
that the user can manually select the original "Reply All" option of the button.

A better idea would be to separate the Reply List button altogether. Somebody
here complained that that will "take up valuable screen real-estate". Honesty, I
have only seven buttons on my toolbar and it takes up less than 50% of my screen
width. So I don't think showing a separate Reply List button is really a
problem. Maybe allow the user to enable it via preferences, like for the Junk
Mail button, Delete button etc.

If it is adjudged that the real-estate problem is really there, then another
option would be to display the Reply-List button only when the mail has a
List-Post (or related) header. This will also draw user attention to the fact
that such an option is separately available.

But a shortcut for this is really important. At least half of the time I use the
keyboard Ctrl+R to reply to mail. Not allowing a shortcut would be a serious
handicap and lose us users.

In summary my preferences and recommendations are:

1. Rename "Reply" to "Reply Sndr".
2. Add a separate "Reply List" button. If needed to save screen space (for what
else I don't understand) then make it disappear when the mail doesn't have the
appropriate headers.
3. Give the "Reply List" button a shortcut.

Lists should be intelligent and use the RFC specification, not munge headers.
Mail clients should be intelligent and use the RFC specification, not force
users to manually enter/edit the to/cc field.

[Toralf-procaptura (toralf-procaptura)]

(In reply to comment #43)
>
>
> A better idea would be to separate the Reply List button altogether. Somebody
> here complained that that will "take up valuable screen real-estate". Honesty, I
> have only seven buttons on my toolbar and it takes up less than 50% of my screen
> width.
Arguably nearly 50% is quite a lot. I want to be able to work with more than one
window at a time.

But it's not so much about the size as such. A good UI should have quick and
direct access to frequently used functionality and nothing else; it shouldn't
have buttons for functions that are hardly ever used laying around getting in
the way - especially in prominent places like the toolbar. With a working "Reply
To List", I wouldn't use reply "Reply All" more than a handful of times every
year, if at all, and with such rare, a toolbar button is quite definitely wrong.
Again, it would only be in my way 99% of the time. In fact, I think even a
dropdown would be a bad idea. Another unncessarily complication, I think.

[Shriramana Sharma (jamadagni)]

(In reply to comment #44)

> Arguably nearly 50% is quite a lot. I want to be able to work with more than one
> window at a time.

OK, then my stand-in suggestion of displaying the icon, perhaps pushing Reply
All out of the way for that, *only* when there exists a valid list header, still
stays.

> But it's not so much about the size as such. A good UI should have quick and
> direct access to frequently used functionality and nothing else; it shouldn't
> have buttons for functions that are hardly ever used laying around getting in
> the way - especially in prominent places like the toolbar. With a working "Reply
> To List", I wouldn't use reply "Reply All" more than a handful of times every
> year, if at all,

Ah, so you recommend the removal of Reply All *in toto*, or at least the
replacement of Reply All by Reply List when such a header exists?

> and with such rare, a toolbar button is quite definitely wrong.

You mean, *two* toolbar buttons for Reply All and Reply List is definitely
wrong, and only one should exist which automatically switches between the two
functions depending on the presence or absence of a header?

> Again, it would only be in my way 99% of the time. In fact, I think even a
> dropdown would be a bad idea. Another unncessarily complication, I think.

Hmm, maybe, but it wouldn't take any real estate. And in the rare cases when a
mail has been sent to a list, but not just to a list? Perhaps to many lists?
Perhaps to a list and one or more persons? One does need a Reply All for that,
but, as you say, it is a rare function and hence doesn't need to be thrown on
the toolbar. It *should* *be there*, however, for those who need it.

[Toralf-procaptura (toralf-procaptura)]

(In reply to comment #45)
Yes.

And I mean that as a reply to most of your questions...

[unused piotr account (piotr-unused)]

(In reply to comment #46)

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

[Bugzilla-mcsmurf (bugzilla-mcsmurf)]

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

[Mscott-mozilla (mscott-mozilla)]

(From update of attachment 192713)
Can this be turned into an extension instead? I'm not too keen on adding a hidden pref to add this somewhat obscure behavior that most users aren't going to know to go set the pref for.

[Bugzilla-ojkastl (bugzilla-ojkastl)]

(In reply to comment #49)
> (From update of attachment 192713 [edit])
> Can this be turned into an extension instead? I'm not too keen on adding a
> hidden pref to add this somewhat obscure behavior that most users aren't going
> to know to go set the pref for.

Im not sure, but this is a functionality most other programs have. So obscure behaviour is quite hard. But maybe there is a "better way" (not meant as an insult to anybody) to solve this than with the hidden pref. Would you like it then?

[Hervé Cauwelier (bug tracking) (debian-oursours)]

(In reply to comment #49)
> (From update of attachment 192713 [edit])
> Can this be turned into an extension instead? I'm not too keen on adding a
> hidden pref to add this somewhat obscure behavior that most users aren't going
> to know to go set the pref for.

Or it's just a checkbox in the account preferences. If we assume people are used to this behaviour from other MUAs, it can even be turned on by default.

[Tbertels+bugzilla (tbertels+bugzilla)]

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

I fully agree with Hervé.
But about the patch, I would prefer to have a new "reply to list" button which would have the behavior described in the comment 25.
See comment 30, comment 31 and comment 33.

[Toralf-procaptura (toralf-procaptura)]

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

This probably also means that the option, if included at all, should be on by default.

[Tbertels+bugzilla (tbertels+bugzilla)]

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

[Kru-tch (kru-tch)]

I would prefer that this NOT be added to the existing reply button functionality. It's bad user interface design and not intutitive. Power users, and lets face it, power users are the ones that predominately need this feature want control.

Either a separate button is required or moving the activation to a preference pane is more desireable than using the existing button to determine the context.

[Toralf-procaptura (toralf-procaptura)]

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

[Tbertels+bugzilla (tbertels+bugzilla)]

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

[Kru-tch (kru-tch)]

In reply to comment #56:

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

[Hervé Cauwelier (bug tracking) (debian-oursours)]

(In reply to comment #58)
> Therefore the premise
> that it should be in the reply button, rather than a specific button isn't
> relefvant as far as I'm concerned.

Indeed, this feature would then be enabled for technical people on technical lists. And I think we are the same who ask for this feature. It won't change a thing for common people on common lists.

[Toralf-procaptura (toralf-procaptura)]

(In reply to comment #58)
> In reply to comment #56:
>
> Actually most of the lists that require this feature tend to be geek lists,
> <ie> Debian user etc. Most of the lists that the majority of endusers use, have
> the reply sent to the list.
Possibly, but isn't that an actually an argument for changing the normal reply button functionality? That way, we guarantee that Reply on a list post will *always* work the way the users are used to for "most lists" today. Differently put, if most lists will send replies to the list, then it is even more likely that users are confused if they ever come across one that will not. And also that an additional "Reply to List" button will be seen as confusing.

It would be a lot better to add a "Private Reply" button as suggested here earlier if extra control is wanted, IMO. This will make sense even for lists that do set Reply-To (it will have to ignore this header, of course.)

And by the way, I consider myself a power-user, but I'm not really that interested in "control" - what I want is first and foremost *some* way to send a message response to the list only, without having to type in or remove adresses, but also consistent "reply" functionality for list messages. I really see no other way of providing that than changing the Reply behaviour. (I'm really not that interested in the "private" reply - I consider it an exception, and don't mind so much adding the address by hand in that case.)

[Andreas Vinsander (andreas-vinsander)]

(In reply to comment #60)

> It would be a lot better to add a "Private Reply" button as suggested here
> earlier if extra control is wanted, IMO. This will make sense even for lists
> that do set Reply-To (it will have to ignore this header, of course.)

Ignoring Reply-To headers aren't the wisest thing to do. I might want to have replies directed towards another adress than the one I'm sending from, that's what the Reply-To is meant for. IMHO lists that tamper with the Reply-To header is somewhat broken.

A separate kbd shortcut and/or button for reply-to-list would be the best option for my use.

[Toralf-procaptura (toralf-procaptura)]

(In reply to comment #61)
>
> Ignoring Reply-To headers aren't the wisest thing to do. I might want to have
> replies directed towards another adress than the one I'm sending from, that's
> what the Reply-To is meant for. IMHO lists that tamper with the Reply-To header
> is somewhat broken.
Depends on how you see it. A list post is precisely one of the cases where I want replies directed towards another address, and that other address is always the list address. Which means the Reply-To rewrite represents 100% correct use of the header. But maybe the client, not the list handler, ought to do it...

Apart from that, a "Private Reply", if implemented, should perhaps not directly ignore Reply-To, but rather search Reply-To, Sender, From... (in that order) until it finds an address different from the list post one.

[Mrsoto (mrsoto)]

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

[Mrsoto (mrsoto)]

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

Kmail has an excellent support to lits, I use Thunderbird from Linux & windows w/the same profile in the same Box. This is the only reason to works w/Tunderbird & lists. Too many years (5!) to solve these BUG.

MS

[Pcmccurdy (pcmccurdy)]

Created an attachment (id=213877)
Adds a Reply-To-List reply mode

This has been driving me crazy for a while, so I've decided to fix it.

As described in comment #8, I've implemented another reply mode. After having read over the bug, it's clear that there are enough different, incompatible opinions on how to do the UI that the only sensible thing to do is make this accessible to extensions, so people can pick their favourite of the mutually-exclusive-yet-still-valid options. The only sensible way to do this that I can see is an extra reply mode.

In fact, my current patch doesn't even implement any UI; for now, I'm just going to add my personally preferred UI in an extension (I want a third UI button and a separate shortcut key, for the record). So to test this, I guess you should hack up the "MsgReplyToAllMessage" function in mailWindowOverlay.js to do a "msgComposeType.ReplyToList" instead of a "msgComposeType.ReplyAll". Or I'll try to get my extension finished up soon, but I might not have time to get to it until Wednesday. The patch should be straight forward though.

A default UI might make sense, as long as extensions can override it, but I wanted to get some comments on what I've got done so far. I also explicitly wanted to avoid any discussions on potential UIs for now - it'd be better to at least get the basic functionality checked in so extensions can play with it, even if Thunderbird doesn't ship with a UI right away.

My solution to getting at the content of exotic headers (as hinted in comment #8) is to get rid of the "optimization" that only sent certain headers out to JavaScript unless the "View All Headers" option was set. When I was first trying to do this as a plain extension, it struck me as incredibly annoying that extensions couldn't get at this data. Perhaps I'm just being naive, but IMHO a mail client that's designed to be extensible should be sure to give this sort of data to extensions. Several extensions (Mnenhy, Enigmail, Display Mail Route, Display Mailing List Header, possibly others) have needed this, and have had to hack around it in one way or another; I can only imagine how many people tried to do interesting things and couldn't because the headers were too hard to get to.

This is my first Mozilla patch, so even though I tried to get it right, I'm sure there are some obvious braindead things littered through my changes. Feel free to point them out, I won't take offense and I really want to get this fixed right. In particular, I had to change an interface in IDL, and I don't know what other changes that implies. Please bear with me if I did something dumb.

[Mozilla (mozilla)]

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

So what's the reason for this? (Please note that I'm not a authorized person to bless such a patch)

[Christian Weiske (cweiske)]

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

[Mozilla (mozilla)]

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

But this has to be an extra bug IMHO.

[Pcmccurdy (pcmccurdy)]

In reply to comment #68:

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

I need to do this here so that my extension can get the List-Post header and tell whether the Reply-To-List will work or not. I suppose I could just add the List-Post header to the list of "blessed" headers, but that seems totally hacky.

If there's another bug about getting rid of this mis-optimization, then I could send another patch to that bug and make this bug depend on it. It just seemed easier to do it all at once.

[Mnyromyr (mnyromyr)]

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

[Pcmccurdy (pcmccurdy)]

Created an attachment (id=214144)
Adds a Reply-To-List reply mode, try 2

> throwing probably lots of useless headers at a UI that
> is already slow enough (on older machines) is just not
> the thing to do.

When you put it that way, it's hard to argue.

Here's a respin of the patch without the controversial header un-hiding. My hacky test method still applies (change ReplyAll to ReplyToList in the JavaScript frontend); it'll be a bit more annoying to write an extension for a proper UI, but I'll just have to deal with that later. At worst I can depend on Mnenhy or Engimail. An official UI could just add List-Post to the list of allowed headers.

[Scott Beamer (angrykeyboarder)]

A reply to list command should not even be necessary unless it's the default.

Every MUA I've used under Linux does this by default, period. Mutt, Sylpheed, Kmail, Evolution.....

I've been rather surprised that oh-so-progressive Mozilla has been so behind on this.

I'm about to abandon Thunderbird for mailing lists and use a better more "standard" (and mailing list friendly, MUA).

[Scott Beamer (angrykeyboarder)]

(In reply to comment #18)
> *** Bug 144914 has been marked as a duplicate of this bug. ***
>

Can it be un-marked? It's not quite a duplicate.

[David Fraser (davidf)]

Re Comment #70:
> - provide a scriptable interface for arbitrary header/value pair requests (no
bug yet, afaik)

Aah, that's exactly what's needed! It seems crazy to be sending this stuff through the UI just because an extension needs it.
When I was trying to look at implementing this bug, I eventually gave up because I couldn't work out how to do that...
There are plenty of comments on Bug 236954 that indicate this too. Maybe we should file a new bug?

[Pcmccurdy (pcmccurdy)]

Created an attachment (id=216290)
Extension to implement a Reply To List UI

I was kind of hoping for more comments on my patch, but I'll grant that my current testing procedure is rather lame. So here's my long-promised extension implementing my vision of a possible Reply To List UI. This should make it easier to evaluate the patch.

The extension's not perfect - in particular, it only works if you have the preview pane enabled - but it's a start. Other comments welcome.

[Pcmccurdy (pcmccurdy)]

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

[Pfeiffer (pfeiffer)]

(In reply to comment #75)
> Created an attachment (id=216290) [edit]
> Extension to implement a Reply To List UI

Not compatible with 1.5 it says...

[Pcmccurdy (pcmccurdy)]

Created an attachment (id=216355)
Reply To List UI Extension, version 0.1.1 (works with patched TB 1.5)

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

Er, well, it isn't. Unless you've hacked my patch into your own self-compiled version of 1.5, which I admit I hadn't anticipated. Here's version "0.1.1" (as opposed to the original "0.1"), which will also install on version 1.5.

To be clear though, the extension absolutely does not work with stock 1.5, or any version of Thunderbird that hasn't been recompiled with my patch.

[Bienvenu (bienvenu)]

(From update of attachment 214144)
looks fine - just a style nit:

+ if (outCString)
+ {
+ mMimeConverter->DecodeMimeHeader(outCString, listPost, charset);
+ }

don't need the braces...and should be

if (!outCString.IsEmpty())

[Pcmccurdy (pcmccurdy)]

Created an attachment (id=217380)
Reply-To-List patch, with style fixes

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

[Sven Mueller (debian-incase)]

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

regards,
Sven

[Pcmccurdy (pcmccurdy)]

(In reply to comment #81)
> I would really like to use your extension if it was possible to do so with a
> stock 1.5 and I have enigmail installed. I'm confused though:
> In one comment, it says that the extension will work either with your patch or
> with enigmail or mnenhy installed. In another comment, it says this is not
> possible without your patch. Which one is true?

Sorry for the confusion. The second statement is true. It is not possible to use my extension without applying my patch to Mozilla's C++ code and rebuilding Thunderbird. You also need to use Enigmail or Mnenhy with that patched Thunderbird.

The comments that confused you were referring to a particular part of my original patch, which had to be removed. This was what reinstated the requirement for Mnenhy or Enigmail.

[Bienvenu (bienvenu)]

last patch checked in, thanks, Peter.

[Le-iota (le-iota)]

(In reply to comment #83)
> last patch checked in, thanks, Peter.

On which braunch is that patch ? 1.7 ? Seamonkey ?

[Jonas-sicking (jonas-sicking)]

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

[Bienvenu (bienvenu)]

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

[Mcow (mcow)]

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

If I'm reading LXR correctly, this was trunk-only -- won't be useable until TB 3.0 unless someone nominates this patch for the 1.8.1 branch.

I'm not sure it matters, tho, since the extension doesn't seem to work even on the trunk. Using TB 3a1-0520, Win2K, the extension installs fine but the Reply To List toolbutton and menu item are not enabled when I select a message with a valid List-Post header.

Note: the disabled toolbutton doesn't display as greyed; but when hovered over, it doesn't show a pushbutton border like the other items. Since the menu item is always greyed, I'm assuming that means the button is disabled as well -- certainly clicking on it does nothing.

[Jan Claeys (janc)]

Thunderbird doesn't support RFC-2369 based Reply-To-List and because of that people use Reply-To-All is a substitute. This causes people to get double copies of the same mail which can be annoying (resulting in mailing list flamewars etc. ;-) ).

The Thunderbird 3.0 branch has a fix for this, but that's not very useful (it will be at least a year before it gets released). Recently someone who wrote an extension that uses the fix also made a patch for the 1.5 and 2.0 branches though, so I think we should include this into edgy (and maybe later to dapper backports/updates?). Provided the patch doesn't break other things of course...

http://open.nit.ca/wiki/index.php?page=ReplyToListThunderbirdExtension

[Jan Claeys (janc)]

I meant "use Reply-To-All _as_ a substitute" of course...

[Mozilla-bugs-janc (mozilla-bugs-janc)]

(In reply to comment #87)
> I'm not sure it matters, tho, since the extension doesn't seem to work even on
> the trunk. Using TB 3a1-0520, Win2K, the extension installs fine but the Reply
> To List toolbutton and menu item are not enabled when I select a message with a
> valid List-Post header.

Did you also install Mheny or Enigmail extension? See http://open.nit.ca/wiki/index.php?page=ReplyToListThunderbirdExtension for more info about that.

[Mcow (mcow)]

(In reply to comment #88)
> Did you also install Mheny or Enigmail extension?

I did not; that must have been the problem. Thanks for the pointer. That page also states that the extension won't work until TB 3.0.

[Mozilla-bugs-janc (mozilla-bugs-janc)]

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

[Felix Miata (mrmazda)]

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

[Tbertels+bugzilla (tbertels+bugzilla)]

(In reply to comment #91)
> Is there any implementation of this function for SM? This bug was filed years
> before TB was invented.

Since the product is Core, the patch works with SeaMonkey and Thunderbird.

[Felix Miata (mrmazda)]

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

[Tbertels+bugzilla (tbertels+bugzilla)]

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

[Felix Miata (mrmazda)]

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

[Tbertels+bugzilla (tbertels+bugzilla)]

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

[Felix Miata (mrmazda)]

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

[Tbertels+bugzilla (tbertels+bugzilla)]

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

[Pcmccurdy (pcmccurdy)]

Sorry, I don't know much of anything about writing Seamonkey extensions, and I don't use it myself so I'm not likely to learn. My C++ patch should apply without any serious problems though, and I'd be more than happy to accept a patch to make the extension work with Seamonkey.

I also don't check my Bugzilla email very often; the main website for the extension is at http://open.nit.ca/wiki/index.php?page=ReplyToListThunderbirdExtension - a comment there is more likely to reach me, if that's what you want.

As for getting the button included by default, that'd be great, but I don't want to get involved with the inevitable bike-shed painting about exactly how it should work. My extension makes it work just how I want, and my patch makes it possible for anyone else (including the main Mozilla developers) to make it work how they want. If my design is desired for mainline Mozilla, then the JavaScript should be simple enough to copy from the extension.

[Mscott-mozilla (mscott-mozilla)]

(From update of attachment 217380)
Have folks been testing this patch with the pref? How has it been working on the trunk builds? I'd like to consider this for the thunderbird 2 / seamonkey branch.

[Tbertels+bugzilla (tbertels+bugzilla)]

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

[Mozilla-hireahit (mozilla-hireahit)]

This might be a stupid question, but why is Mnenhy or Enigmail extension required? Why can't the headers be added to the list of headers available without one of those extensions?

Conversely, what's the point of this patch if it still requires multiple extensions for it to do anything? Couldn't this have been implemented entirely as an extension?

[Scott Beamer (angrykeyboarder)]

This has been driving me nuts. Evolution and Kmail beat Thunderbird hands down when it comes to all things mailing lists.

The problem is, I otherwise like Thunderbird better, so I stick with it.

I'd love to see this patch make it into Edgy, but I fear it's too late at this point.

[Dean Sas (dsas)]

Hmm, the upstream bug should be "fix commited" rather than "fix released"

[Timur Tabi (timur-tabi)]

I want to echo comment #102. I don't think relying on a third-party extension is valid for this bug to be considered "fixed". If anything, it should be marked as "wontfix" with a pointer to the extension.

Also, everyone here is talking about Thunderbird, but I want to see this fix for Seamonkey. After all, it is supposed to be a "Core" bug.

[Ben-bucksch (ben-bucksch)]

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

[Tbertels+bugzilla (tbertels+bugzilla)]

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

[Mrsoto (mrsoto)]

Happy new year,
  This is in my opinion an important feature which Mozilla and any usable mail agent should support. Unfortunately it is going to be 7 years old.

I'm waiting to see it solved to evaluate to return from kmail to thunderbird and share the inbox between several Operating system.

Watch kmail and be inspired. It has reply specific per folder and full list manage options.

Manuel

[Bugzilla-ojkastl (bugzilla-ojkastl)]

I found http://open.nit.ca/wiki/index.php?page=ReplyToListThunderbirdExtension which was recommended to me, and should (for what I have heard) work.

Unforntunately it is a TB-only xpi, missing the installation sript for Seamonkey/Mozilla Suite.

Would it be possible to add that script, to get it working in SM?

[Patrick Cornelissen (patrickcornelissen)]

The debian package for thunderbird has this patch already included.
Plz, do it here too Alexander! :)

[Fabian Zeindl (fabian-xover)]

This has been fixed in Debian unstable and I wanted to know how the status of this bug is? I think thousands of users would be _very_ glad if the had reply-to-list feature in Thunderbird.

[KenSentMe (jeroen-vandenieuwenhof)]

It would be nice to have this feature implemented, especially because most of the official Ubuntu mailinglist don't use the reply-to address, so there's no one-click solution for replying to mailinglists.

[Christian Weiske (cweiske)]

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

[John Vivirito (gnomefreak)]

adding the patch for feisty's thunderbird atm.

[Patrick Cornelissen (patrickcornelissen)]

John Vivirito schrieb:
> adding the patch for feisty's thunderbird atm.
>
Perfect! Thank you I'll test it as soon as it hits the repositories

--
Bye,
 Patrick Cornelissen
 http://www.p-c-software.de
 ICQ:15885533

[Alexander Sack (asac)]

OK,

testing packages for i386 and amd64 are available at http://people.ubuntu.com/~asac/mt-edgy/

[Patrick Cornelissen (patrickcornelissen)]

Alexander Sack schrieb:
> OK,
>
> testing packages for i386 and amd64 are available at
> http://people.ubuntu.com/~asac/mt-edgy/

Well works perfect so far :)

--
Bye,
 Patrick Cornelissen
 http://www.p-c-software.de
 ICQ:15885533

[Patrick Cornelissen (patrickcornelissen)]

Well, the reply to list function works good, but with your package, Alexander, I get the "Do you want to use Mozilla Thunderbird as default mail program" each time I start TB. No matter which option I use and whether I set the remember checkbox or not.

[Alexander Sack (asac)]

ok i see ... apparently the "gnome support" is not properly disabled by default, so if there are gnome packages available during build they might produce this feature. Thanks for the info.

[Fabian Zeindl (fabian-xover)]

Alexander: Can you compile a thunderbird 1.5.0.10 testing package too? ;)

[John Vivirito (gnomefreak)]

I already have builds for 1.5.0.10.2 with the reply to list patch. I will upload them today to my server in a little while.

[Alexander Sack (asac)]

its in feisty:

mozilla-thunderbird (1.5.0.10-0ubuntu1) feisty; urgency=low

  * New upstream security update:
    - CVE-2007-0008, MFSA 2006-06: SSLv2 Client Integer Underflow
      Vulnerability
    - CVE-2007-0009, MFSA 2006-06: SSLv2 Server Stack Overflow
      Vulnerability
    - CVE-2007-0775, CVE-2007-0776, CVE-2007-0777, MFSA 2007-01:
      Crashes with evidence of memory corruption
  * drop patches applied upstream: 90_ppc64-build-fix
  * debian/control: Taking over maintainer field.
  * archives/thunderbird-1.5.0.10-source.tar.bz2: use original
    upstream tarball to build official branding
  * debian/rules: update tarball name; drop code that replace
    official branding with free branding.
  * debian/fhunderbird-branding.tmpl, debian/fhunderbird-icons,
    debian/gen-fhunderbird-branding.sh: remove free branding
    generation.
  * debian/patches/91_replytolist.dpatch: added patch to allow
    reply to list extension (bz#45715)

 -- Alexander Sack <email address hidden> Sat, 3 Mar 2007 14:00:00 +0100

[John Vivirito (gnomefreak)]

This is incuded in feisty already. Fabian. what build were you looking for, Edgy will not receive this patch as its not a security patch.

[Patrick Cornelissen (patrickcornelissen)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexander Sack schrieb:
> its in feisty:
>
> mozilla-thunderbird (1.5.0.10-0ubuntu1) feisty; urgency=low

Thanks!

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF9V8lNOOTf/FLKYsRAi1cAJ97USnvwfxdQT8FUl4HOjjR6N7n4ACcD2/2
dt4p2RxKS7NxVyuCOMaQ/Ic=
=Tex9
-----END PGP SIGNATURE-----

[Fabian Zeindl (fabian-xover)]

Hi, is it then possible to use feisty packages in edgy. I cannot simply install it, because they depend on different libc version etc.

Is it possible to put the patch in edgy-backports?

fabian

[John Vivirito (gnomefreak)]

No dont use feisty packages in edgy. Thunderbird is almost impossiblet o use between versions like using feistys in edgy due to libc6 depends. We are unable to backport firefox and thunderbird as they dont meet the requirments. I will talk to Alexander(our mozilla maintainer) and see if he minds if i build an unofficial build for edgy and post it to my server. but if i do and you use it
1. you will get no support for it since it is unofficial
2. Upgrading thunderbird will not happen correctly. (example: if a security patch comes out for edgys thunderbird you will have to remove mine to install ubuntu;s version.
3. I will not keep up with security builds with the unofficial version.

With that stated let me know if you still want the build.

[Fabian Zeindl (fabian-xover)]

Hm, since feisty is about to be released soon, I guess I don't need it if it's that complicated, but thanks ;)

[Manuel López-Ibáñez (manuellopezibanez)]

(In reply to comment #106)
> I'm waiting to see it solved to evaluate to return from kmail to thunderbird
> and share the inbox between several Operating system.

Now that KDE4 is going to run in Windows and MacOS, it may be possible to do that in kmail. Perhaps they haven't thought about it yet.

[Caillon (caillon)]

(In reply to comment #100)
> (From update of attachment 217380 [details])
> Have folks been testing this patch with the pref? How has it been working on
> the trunk builds? I'd like to consider this for the thunderbird 2 / seamonkey
> branch.

Note to the patch author: this probably means you should simple add the little bit of xul for the button to the patch to get into thunderbird proper instead of having users need to also get the extension. You'd stand a better chance of getting this fixed if it were a complete solution, IMO.

[Tbertels+bugzilla (tbertels+bugzilla)]

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

[Scott Beamer (angrykeyboarder)]

Well, we're in Edgy now and no fix.

What happened?

[Scott Beamer (angrykeyboarder)]

> Well, we're in Edgy now and no fix.
>
> What happened?
>

Correction.

That's "Gutsy"..

[Dean Sas (dsas)]

The fix has been there since Feisty. Did you install the extension linked above?

[John Vivirito (gnomefreak)]

IIRC the there is an upstream bug stating that it worked with pre final 2.0.0.x thunderbird and not after. I havent had a whole lot of time to work on this yet, last time i tested it it failed to work with final 2.0.0.x

[John Vivirito (gnomefreak)]

There will not be an official fix for edgy since it isnt a security fix.

[Fabian Zeindl (fabian-xover)]

It doesn't work in Gutsy, using the above mentioned Extension. The Button is always greyed out.

[Jan Claeys (janc)]

Fabian: did you install the List-extension as well as one of the 2 that it depends on?

[Fabian Zeindl (fabian-xover)]

Yes, I have enigmail installed.

[Fabian Zeindl (fabian-xover)]

Ok, sorry, I just figured out I made a mistake:
Reply-To-List works, but only when you have configured thunderbird to show _all_ headers.
When you select "normal" headers, the button get's greyed out, cause the extension doesn't find the List-Post header anymore.
Apparently Thunderbird makes only the visible headers available to extensions.
I have another extension installed "Display mailinglist headers" which also only works with all headers displayed.

I'm definitely sure, that in Thunderbird 1.5 both extension worked, no matter how the "Show Header"-option is set.

[John Vivirito (gnomefreak)]

I would like everyone that had issues with it to test and give feedback please. Fabian this will not be released for Gutsy, we can only upload security releases for stable releases. We had patched this in Thunderbird so if we have to patch it again than we cant release it and the reply to list extension isnt in our repos.

[John Vivirito (gnomefreak)]

Ok running test on icedove to see if it works there, hopfully it does

[John Vivirito (gnomefreak)]

ok seems tbird 2.0.0.6 and reply-to-list are fine even without showing all headers. Please redownload and install the .xpi again from http://alumnit.ca/wiki/attachments/replytolist-0.2.0.xpi as i got it working without doing anything differnet including using the same profile as i have been.

[Fabian Zeindl (fabian-xover)]

I tested with tbird 2.0.0.6 from ubuntu. I deactivated all my other plugins except enigmail to be sure and get the same result:
when using view->headers->normal headers the button is grey.
It doesn't matter whether you "expand" or "collapse" header in the mail window itself. Just the option in view menu has to be set.

John: Do you use enigmail or mnehy?

fabian

[John Vivirito (gnomefreak)]

enigmail only but that shouldnt effect the reply-to-list. If you are in gutsy can you please upgrade to 2.0.0.8, i enabled show all headers than disabled it to show normal and it still works

[Dean Sas (dsas)]

John it doesn't work here when view normal headers isn't chosen on the versions of thunderbird and the extension you reccomended

[John Vivirito (gnomefreak)]

ok thank you i know why mine works than, now to figure out why its not working for our package.
Ok I will look at this more this week but im gonna spin it tonight without the reply-to-list patch since debina dropped it from icedove and icedove works.

[John Vivirito (gnomefreak)]

Well that wasnt it, i will keep working on this, im a bit busy this week but i should have a day were i can devote to this.

[Fabian Zeindl (fabian-xover)]

I have TBird 2.0.0.8 installed, I just thought it was 2.0.0.6 because the aboutpage says that.
I have contact with the developer of the extension who just released 0.3.0 which features Auto-Update and doesn't need any additional extensions
any more. Unfortunately it crashes for me, I already told him that, but maybe you can try it too?
http://alumnit.ca/wiki/attachments/replytolist-0.3.0.xpi

@Dean: Do you mean it doesn't work when view normal header _isn't_ chosen? So exactly the opposite behaviour of mine?

[Dean Sas (dsas)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Fabian Zeindl wrote:
> @Dean: Do you mean it doesn't work when view normal header _isn't_
> chosen? So exactly the opposite behaviour of mine?

No, I meant identical behaviour to yours.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHJcENeedO8dcp9nYRApCnAJ48DxO9Mq4X9ssGf6NDvj+b5NrOKQCgh3B1
g/ZJnzbQIgmvOTIpfeQBKRA=
=zTps
-----END PGP SIGNATURE-----

[John Vivirito (gnomefreak)]

OK just tested reply to list 3.0 and it works here on a clean profile. heres what i did for test.
mv ~/.mozilla-thunderbird ~/.mozilla-thunderbird.old
run thunderbird set up one account, install extension, add it to tbird panel and so far no issues. No need to change header veiw nothing please try this and tell me if it works
Not sure why yours crashed but that is up to the author/maintainer of the script. Please confirm this works for everyone.

[John Vivirito (gnomefreak)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Fabian Zeindl wrote:
>> > @Dean: Do you mean it doesn't work when view normal header _isn't_
>> > chosen? So exactly the opposite behaviour of mine?
>
> No, I meant identical behaviour to yours.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFHJcENeedO8dcp9nYRApCnAJ48DxO9Mq4X9ssGf6NDvj+b5NrOKQCgh3B1
> g/ZJnzbQIgmvOTIpfeQBKRA=
> =zTps
> -----END PGP SIGNATURE-----
>
> -- Thunderbird doesn't support RFC-2369 based Reply-To-List https://bugs.launchpad.net/bugs/52667 You received this bug notification because you are a direct subscriber of the bug.

It however doesnt work on bugs but that is ok i dont think it is meant
to, but im trying my hand at replying to bugs from email :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHJgfwqig4QTwcPCoRAjq9AJ0R67T6rUylfac7zMzx5tlVTgnfgACfU2Zw
jyNp7DWdQgXC/b20gmB5xio=
=KWqk
-----END PGP SIGNATURE-----

[John Vivirito (gnomefreak)]

It however doesnt work on bugs but that is ok i dont think it is meant
to, but im trying my hand at replying to bugs from email :)

the above should be on my last post but it got caught up in the quote

[Fabian Zeindl (fabian-xover)]

It crashes when using in conjunction with IMAP. With POP everything works, I already told the maintainer about this issue.

[ubuntu-ase (ubuntu-ase)]

we are unable to fix this for edgy, feisty, or gutsy at this time since it
is not a security issue. please let me know what version you are using of
ubuntu and reply to list version. this works on my gutsy and hardy systems i
havent tried it on other systems in a long time.

On Oct 30, 2007 4:56 AM, Fabian Zeindl <email address hidden>
wrote:

> It crashes when using in conjunction with IMAP. With POP everything
> works, I already told the maintainer about this issue.
>
> --
> Thunderbird doesn't support RFC-2369 based Reply-To-List
> https://bugs.launchpad.net/bugs/52667
> You received this bug notification because you are a member of Mozilla
> Bugs, which is the bug contact for Mozilla Thunderbird.
>
> --
> Ubuntu-mozillateam-bugs mailing list
> <email address hidden>
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-mozillateam-bugs
>

[Fabian Zeindl (fabian-xover)]

At the moment it's like this:

- In Thunderbird 1.5 with patch applied and EnigMail installed, ReplyToList works.
- In Thunderbird 2.0 you don't need EnigMail, but:
  * Either you turn on "Show All Headers", then you can use ReplyToList version 2.*
  * or you add "List-Post" to mailnews.headers.extraExpandedHeaders in about:config, then you can too use ReplayToList version 2.*
  * or you can use ReplyToList version 3.0, where don't need to set "Show All Headers" or extraExpandedHeaders, but this version just works with POP and not with IMAP (yet), which is considered a bug and should be fixed sooner or later.

[Bugzilla-babylonsounds (bugzilla-babylonsounds)]

(From update of attachment 217380)
This patch has already been checked in on the 1.8 branch

[John Vivirito (gnomefreak)]

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

[Matěj Cepl (mcepl)]

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

[Gudmund (gudmund-fta)]

(In reply to comment #114)
> -- looking at thunderbird-2.0.0.14 I don't see any Reply to List method
> in any menu, button or whenever else.

That is the bug, or requested enhancement if you wish. I'm currently using this:
http://www.juergen-ernst.de/addons/replytolist.html

I can't remember which parts if the mail header it parses, but it seems to works fine at least as far as I've seen. Haven't tried the above-mentioned back-end patch. I'd rather test a complete build (a bit difficult with betas since I normally use portable apps) if possible.

[John Vivirito (gnomefreak)]

This bug should have been fixed already without using the workaround please reopen if this is a still an issue for you

[John Vivirito (gnomefreak)]

Im not gonna close this yet i left a comment on the upstream bug for a status report.

[Scott Beamer (angrykeyboarder)]

John Vivirito wrote:
> Im not gonna close this yet i left a comment on the upstream bug for a
> status report.
>

That's good, because at least as far as
thunderbird-2.0.0.12+nobinonly-0ubuntu1 is concerned, it's not yet been
fixed.

I was under the impression that a patch from Mozilla wouldn't appear
till Thunderbird 3.0.

So I say, let's go for the Debian patch. :)

[John Vivirito (gnomefreak)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Scott wrote:
| John Vivirito wrote:
|> Im not gonna close this yet i left a comment on the upstream bug for a
|> status report.
|>
|
| That's good, because at least as far as
| thunderbird-2.0.0.12+nobinonly-0ubuntu1 is concerned, it's not yet been
| fixed.
|
| I was under the impression that a patch from Mozilla wouldn't appear
| till Thunderbird 3.0.
|
| So I say, let's go for the Debian patch. :)
|
I'm using thunderbird-2.0.0.14 and it works fine so far. can you please
update your system and try to start it with a clean/new profile and see
if it works. Reason i say new profile is because i tested it and it
failed i installed icedonve from sid and it worked so i went back to our
version and it worked, moved profile and it didnt work. this was when i
was steadily working on that set up.If i need to fix it please let me
know, what version of tb what version of r-t-l extension/addon

- --
Sincerely Yours,
~ John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFILKJGqig4QTwcPCoRAirJAJwM3la6Wa035X01gDcP8/L+eOID9gCfSvw5
nfDeZlMH4cWlu8NrXgZLUu0=
=suC4
-----END PGP SIGNATURE-----

[John Vivirito (gnomefreak)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Scott wrote:
| John Vivirito wrote:
|> Im not gonna close this yet i left a comment on the upstream bug for a
|> status report.
|>
|
| That's good, because at least as far as
| thunderbird-2.0.0.12+nobinonly-0ubuntu1 is concerned, it's not yet been
| fixed.
|
| I was under the impression that a patch from Mozilla wouldn't appear
| till Thunderbird 3.0.
|
| So I say, let's go for the Debian patch. :)
|
Ok i just found out mine stopped working i used it 2 times and i used it
just now and it wont start. I will look at patch and see why it isnt
working sometime next week since this week is UDS, and im busy at home
catching up from last 6 months since i was away most of that time.
If anyone can please test with upstream build just download it unpack it
and run it from within the unpacked dir. I will test this on this end as
well. What version of the addon are you using?

- --
Sincerely Yours,
~ John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFILKbpqig4QTwcPCoRAkNrAJ9yW5XJl8qzcwLGyF0ei3pUuA5mQgCdH0Cq
V9Z8dzHz/o16aBkM93BfvOo=
=yxxN
-----END PGP SIGNATURE-----

[John Vivirito (gnomefreak)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Scott wrote:
| John Vivirito wrote:
|> Im not gonna close this yet i left a comment on the upstream bug for a
|> status report.
|>
|
| That's good, because at least as far as
| thunderbird-2.0.0.12+nobinonly-0ubuntu1 is concerned, it's not yet been
| fixed.
|
| I was under the impression that a patch from Mozilla wouldn't appear
| till Thunderbird 3.0.
|
| So I say, let's go for the Debian patch. :)
|
We patched this and sent patch to Debian and it worked there and not
here as i remember it. Please update to .14 to make sure it doesnt work
on your set up.

- --
Sincerely Yours,
~ John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFILMVvqig4QTwcPCoRAr1PAJ42TT57TGmBj9VkMGfe/kYQJaV1zwCeM0BB
UFloV2o6MxCZw6rM8rhrTdQ=
=g/h3
-----END PGP SIGNATURE-----

[Joshua Cranmer (jcranmer)]

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

[Marco-zehe (marco-zehe)]

Are there any plans to include this in Thunderbird 3? I just got a request from a current Thunderbird 2.0.0.16 user who would really like this feature. He's using mailing lists extensively and also uses the above cited extension, which works fine for him.

I also found myself needing this feature quite a couple of times already, so would welcome it myself!

[Joshua Cranmer (jcranmer)]

All this needs is some UI to be hooked up.

[Bienvenu (bienvenu)]

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

[Bryan Clark (clarkbw)]

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

[Brendan Scott (gobnat)]

What does "always use the ( Reply to List ) as the reply button for mailing
list mail" mean?

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

[Ben-bucksch (ben-bucksch)]

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

[Ben-bucksch (ben-bucksch)]

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

[Matus UHLAR - fantomas (uhlar)]

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

[Bryan Clark (clarkbw)]

(In reply to comment #121)
> What does "always use the ( Reply to List ) as the reply button for mailing
> list mail" mean?

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

[Bugzilla2007 (bugzilla2007)]

In reply to Comment #123
> The obvious UI solution is to have a dropdown in the new "reply..." button.
Rumour has it that Thunderbird development can sometimes be quite resistant against implementing "obvious UI solutions" (like scrollbars on overflowing all-headers), but the good news is that after some 5 years or so, the likelihood of "obvious UI solutions" to be implemented increases dramatically (cf. bug 223132, now fixed!). The RFE to have dropdown reply buttons etc. was filed as early as 1999 in bug 17796, so chances are...

I think having an extra menu on the sender's email link in the header as proposed by Comment #125 is much less intuitive than having all reply options in one single place, namely a dynamic dropdown reply button. I'd suppose it'll be quite confusing for the user finding only the default reply option on the button in the preview header, and having to go somewhere else and use a quite different approach for non-default reply options (context menu of sender etc.). Are there any reasons /against/ having a dropdown reply button (with dynamic default actions, if you so wish)?

[Bryan Clark (clarkbw)]

> Are there any reasons /against/ having a dropdown reply button (with dynamic
> default actions, if you so wish)?

Rumour has it that lots of rhetoric and sarcastic tone make people resistant to reading bug comments. :) But it's certainly possible to have the option available in both places. That would give us a combination of buttons that look something like this.

( reply )

( reply all | v )______
| reply to sender only |
'----------------------'

( reply list | v )________
| reply to all recipients |
| reply to sender only |
'-------------------------'

[Bugzilla2007 (bugzilla2007)]

In reply to comment #127:
> That would give us a combination of [dropdown] buttons that
look something like this.

Don't rush it... ;), but yeah, "something like this [outline above]" looks very good to me. Questions:

a) In which cases, if at all, will I see "reply all" as default?

b) There are different ways of realizing the dropdown functionality. Which of the two would you prefer?

Option 1: (static dropdown menu)
Dropdowns behave like a non-changing menu, i. e. after having executed "reply to sender only" from the first dropdown (as per the previous comment #127), I will still see "reply all | v" as the default option. Users who more often than not want "the other option" as default ("reply to sender"), will cry.

Option 2: (toggle-style/sticky dropdown menu)
Whichever dropdown option I choose, will become the new default option (on the fly) for that type of msg (news message, normal mail with multiple recipients etc.). E.g. after having chosen "reply to sender only", "reply to sender only" will then stick as a default option for say, the next mail I am reading that also has multiple recipients, until I execute "reply all" once again which will then in turn become the default option again. Such behaviour is common in other applications like MS Word, e.g. for setting table borders, colors etc.: whatever you pick from the dropdown becomes your new default for the time being.

Option 2 could make both sorts of users happy:
- those who usually use "reply all" will (usually) get this as their default
- those who usually use "reply to sender" will (usually) get this as their default
Therefore, I am biased in favour of option 2.

But why would people want to have "reply to sender" as their default reply action for mails with multiple recipients? There are many usage scenarios where in spite of multiple recipients, people might (per default) wish to reply to sender only, say leaders of any kind sending out a form or some task to a group of people where answers always go back to the central sender. Always and persistently defaulting to "reply all" in case of multiple recipients might be annoying for such users.

[Bryan Clark (clarkbw)]

Thanks, that's a really good breakdown. In my experience Option 2 seems like a good idea, except that it creates tricky consequences. If you base the "sticky" quality off the type of message or other attributes you really have to communicate to the user that "Newsgroup messages will always reply to sender". Otherwise it can appear to people that we're choosing a default almost randomly; you click on one mail message and it's reply all, one news message and it's reply to sender. Also if a person wanted to reply to sender just once and we changed the default after that one time we're likely to confuse them.

Sadly the simplest method of just defaulting to reply all for multiple recipients is going to allow everyone (even the people who would be annoyed by this behavior) to at least always predict what will happen.

For those who want more "sticky" like behavior I believe all that would be necessary is to understand that need and build the buttons with extensions in mind. Extensions would enable people to customize the button type based off the attributes of the message, it probably isn't too difficult right now... well once we have buttons like that at least.

[Bugzilla2007 (bugzilla2007)]

(In reply to comment #129)

> Sadly the simplest method of just defaulting to reply all for multiple
> recipients is going to allow everyone (even the people who would be annoyed by
> this behavior) to at least always predict what will happen.

I can see your point about predictability. From a best-usability-for-most-users point of view, how did you arrive at your intention to make "Reply to all" the default option for normal mails with multiple recipients (rather than "Reply to sender")? "Reply to sender" for all normal mails and "Reply to List" for all newsgroup messages would still be predictable. Do you have any statistical usage data that supports the choice?

> For those who want more "sticky" like behavior I believe all that would be
> necessary is to understand that need and build the buttons with extensions in
> mind. Extensions would enable people to customize the button type based off
> the attributes of the message, it probably isn't too difficult right now...
> well once we have buttons like that at least.

To have the dropdown buttons (at all) will be a great step ahead and much appreciated. However, translating the above means all that would be necessary to change potentially annoying defaults is that you have to be a programmer and start off from zero by extracting attributes of the message. Not all of us are, and programming the extension that way would involve a lot of (largely redundant) work.

Considering that a possibly large number of users might be impeded by the choice of defaults, perhaps the following proposal would grant all kinds of users more flexibility at a reasonable cost for Mozilla programmers:

Have a configurable defaultoption property (no UI, just about:config) for each type of message, something like:

messagereader.replybuttondropdown.mail.single-recipient.defaultoption
messagereader.replybuttondropdown.mail.multiple-recipient.defaultoption
messagereader.replybuttondropdown.news.defaultoption

For each of these, defaultoption can have (a suitable subset of) the following values:

defaultoption=0 [future use: sticky default as per comment #128, option 2]
defaultoption=1 [Reply to sender]
defaultoption=2 [Reply All]
defaultoption=3 [Reply to List]

Since the currently planned implementation will check for the different types of message anyway (in order to show corresponding defaults for the reply dropdown), the extra bit suggested here is just reading the defaultoption property before setting the default for that type.

Just a thought, and I do appreciate that every extra line of code for any one out of countless feature requests involves investing precious programming time - but maybe it is easier and more future-proof to implement this now rather than later since you are doing conceptual and coding work for the behaviour of the dropdown buttons anyway.

[Olaf-cbk (olaf-cbk)]

Hmm,

Are you not overcomplicating this a bit :)

Why not

1. Reply to "Reply-To"
2. Reply to Sender
3. Reply to List
4. Reply to All

And:

If the message is from message-list then default is 3.
Otherwise the default is 1.

I assume here that the Reply-To is from header "Reply-To", and Sender is from header "From".
Anyway we could omit option 2. and if someone really wants to send to this addres then he could do it manually.

In my opinion things like "sticky" can cause only troubles.
If you really want to add something here, please do it via preferences settings.

[Mkmelin+mozilla (mkmelin+mozilla)]

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

[Matus UHLAR - fantomas (uhlar)]

Just a note: Reply-To-List is logically the same as Reply-To-Group (aka Followup) in newsgroups. I think they should be merged if possible.

And also: in mailing list or newsgroup, the reply-to-list/followup should be the default.

Otherwise, a simple Reply should be default.

If sender wishes to override default reply style in news/lists by using Followup-To (or Mail-Followup-To supported by mutt), the default behaviour should be changed to this one (a config option?), but user should have possibility to ignore that.

[Ivan N. Zlatev (e-contact-i-nz-net)]

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

[Olaf-cbk (olaf-cbk)]

If you don't have time to read our comments why should we bother to read yours?

Anyway:
How would you reply to ALL with this behaviour when you get an e-mail from mailing list? I mean - to list _and_ to other recipients?

This are two different things and I see no possibility to put them together.

[Ivan N. Zlatev (e-contact-i-nz-net)]

(In reply to comment #135)
> If you don't have time to read our comments why should we bother to read yours?
>

There are 32 pages of comments dating from year 2000 and yours are only from 2008. It was plain obvious that I was referring to the older comments. But I guess not obvious enough for you. Anyway moving on.

> Anyway:
> How would you reply to ALL with this behaviour when you get an e-mail from
> mailing list? I mean - to list _and_ to other recipients?
>
> This are two different things and I see no possibility to put them together.

If the mail is coming from a mailing list you should be replying to the mailing list email and not including other recipients unless explicitly requested by them (e.g: "Please CC me I am not subscribed to the list"). At least this is my understanding how mailing lists work and this is how would I expect a Reply To All to work in this case. "All" will mean "All subscribers on this list".

If the mail is not coming from a list then "All" will just "Everyone from To and CC".

[Greyed (grey)]

That would run afoul of Exim-users' (dumb, IMO) policy of CCing people on replies.

All I want to know is, as the previous commenter has said, 137 (counting this one) comments going back 8 years and we're still going over the same discussion over and over. How to implement it. Look, TBird is one of the only mail clients on the unix side of life which doesn't implement it. This has been bicycled to death, people. Quite frankly I don't care HOW it is done, I care that it gets done before another 8 years goes by!

A separate button? Fine!

A drop down? Fine!

Available only with a keypress? Fine!

JUST DO IT ALREADY!

If the TBird devs need to noodle it out look at how KMail, Evolution, mutt, pine, elmo and who knows what other clients do it, figure out the most popular method and implement that! It is readily apparent that whatever choice is made will not appease everyone who is watching and has commented on this bug. What is apparent is that this has to be one of the biggest warts in TBird's entire history and it is high time it is finished and marked closed.

[Adam-hardy (adam-hardy)]

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

[Olaf-cbk (olaf-cbk)]

As you see you would have "expectations" how it should behave.
I have different ;)
I feel that two separate options are better as it is perfectly clear what will be done - you don't have to guess. And they do what they say - All is All, List is List.

As for usability of reply to all in "mailing list context" - I wanted this exactly for the case you have mentioned - to be able to reply to people that are not subscribed.

[Bugzilla2007 (bugzilla2007)]

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

The defaults discussion was triggered by Bryan W Clark's comment #120, linking this bug the new message reader layout. In comment #120 and bug 461098 comment #1 Bryan says the plan is to have a SINGLE reply button in the button bar of new message reader preview pane. The default action triggered by the button will then change dynamically according to the properties/type of the current mail/news. Combining as many as 4 different reply options (as per comment #131) into a SINGLE button certainly requires decisions about the default action, and that's how it started. The subsequent idea was to implement dropdown menu buttons to alleviate gross usability issues for those not happy with the single default reply option. Obviously, the dropdowns still require a single default reply option for each different type of mail/news. Usability thus could be improved by letting the user choose his/her own preferred default reply option for each type.

A lot of the discussion in this bug shows that people's expectations with respect to default reply actions differ a lot. So I'm not sure if I'm overcomplicating things by suggesting a very low-cost solution to make default reply actions customizable (let user set default reply option for different types of mail/news in about:config; my comment #130 - ignore the "sticky" bit).

Maybe some of the "bugfight" in between is in danger of oversimplifying the true complexity of the issue:

1 single new reply button (as envisioned by Bryan for the new message reader's header pane) should handle
2 basic different types of messages (mail, news),
2 additional subsets of messages (list-mail, mail with multiple recipients - see Bryan in bug 461098 comment #1), and
4 different reply options (reply to reply-to, to sender, to list, to all; as listed in comment #131, and basically the same in my comment #130).
Default actions must evaluate at least
8 (i.e. lots of) different relevant headers (reply-to, follow-up-to, list-post, from, to, cc, resent-from, resent-reply-to...), where in terms of reply, some headers (like "reply-to") overwrite others (like "from") but still the user might want to use "the other" header...
Furthermore, since this bug is linked with, but not filed explicitly against the new message reader, we'll need to consider at least
2 different locations for reply button(s): message reader and main toolbar, where the msg header pane real estate is much more limited than the toolbar. Thus the toolbar might continue to have TWO reply buttons where the plan for message reader is to have just ONE (possibly requiring different coding for those buttons).
In addition, people want customization options, e.g. 4 individual buttons for each of the 4 different reply options, and choice as to which buttons are shown.
Finally, add to that a lot of different and sometimes incompatible personal needs and preferences of individual users...

[Greyed (grey)]

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

[Renato S. Yamane (renatoyamane)]

This look like *great*!
I really need it :-)

I'm very frustrated when I need "reply to all" and delete sender e-mail (maintain mail-list address).

This enhancement have a lot of votes. Is there any plan to do it to Thunberbird 3?

I will attach 2 e-mails, in this bug report. Both is sent to same mailing-list, but one is not necessary "reply to al" (is automaticaly reply to Mailing-List), but another is necessary "reply to all" (because when I click in "Reply" - or CTRL+R - message is reply to sender, not to mailing list).

Best regards,
Renato

[Renato S. Yamane (renatoyamane)]

Created an attachment (id=362707)
When you reply this e-mail, message go to the SENDER and not mailing-list

[Renato S. Yamane (renatoyamane)]

Created an attachment (id=362708)
When you reply this e-mail, message go to mailing list (correctly)

[John Vivirito (gnomefreak)]

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

[John Vivirito (gnomefreak)]

Created an attachment (id=362716)
This shows "reply all" in Thunderbird-3.0

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

[Renato S. Yamane (renatoyamane)]

@John,
"Reply all" button always was present in Thunderbird.

This is not the problem.

The big problem is:
- When you is subscribed in some mailing-lists (as Debian, LKML, etc), when you click in "Reply", message will be sent to SENDER (author) and not to Mailing-list.

Messages from @gmail.com ALWAYS is reply to author, and not to mailing-lists.

To reply to mailing-list is necessary:
- Use "Reply to all" + delete SENDER e-mail, OR:
- Use "Reply" + delete SENDER e-mail + Insert mailing-list e-mail.

See my two attachs, both is send to the same mailing-lists, but one works fine (when you use "Reply", message go to mailing-list), but another when you use "Reply" the message go to sender (author).

[John Vivirito (gnomefreak)]

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

[Renato S. Yamane (renatoyamane)]

@John, you don't understand me.
We want that when we select "Reply", message go to mailing-list.
I'm very frustraded need "Reply to all" + delete sender e-mail.

- When you reply this message:
https://bugzilla.mozilla.org/attachment.cgi?id=362708
It go to mailing-list correctly.

- When you reply this message:
https://bugzilla.mozilla.org/attachment.cgi?id=362707
It go to sender/author and not mailing-list (so is necessary use "Reply to all" + delete sender/author e-mail.

Best regards,
Renato

[Blog-tessarakt (blog-tessarakt)]

@Renato: I guess this is quite out of the scope of this bug. The difference between the two messages is probably the "Mail-Followup-To:" header that is only present in one of them (for whatever reason).

This can be handled (better) _when_ TB distinguishes between followup and reply. You should probably file a new bug for your specific problem.

[Matus UHLAR - fantomas (uhlar)]

the 2nd message (https://bugzilla.mozilla.org/attachment.cgi?id=362707)
contains Mail-Followup-To: header that tells the client where shold List-Reply (Followup) go.

Renato, you should always differ between Reply (to author), List-Reply (followup) and Reply-All. There should be possibility to reply to sender, e.g. for off-topic informations.

I kinda wonder why replies to mail with Mail-Followup-To go to sender, while without the header they go to the list. Do you have some extension installed?

[Renato S. Yamane (renatoyamane)]

Created an attachment (id=363826)
Message without follow-up-to header

[Renato S. Yamane (renatoyamane)]

@Jens,
My example show why this bug happening. This is not out of scope.

I attach one more header, without "follow-up-to" and it go to sender when we reply it.

So, we have 3 situations:
- Message with follow-up-to, (that go to sender)
https://bug45715.bugzilla.mozilla.org/attachment.cgi?id=362707

- Message without follow-up-to (that go to mailing list):
https://bug45715.bugzilla.mozilla.org/attachment.cgi?id=362708

- Message without follow-up-to (that go to sender)
https://bugzilla.mozilla.org/attachment.cgi?id=363826

Correct, in all this 3 sitautations need be: Message need go to mailing-list when I reply it. And not to sender.

@Matus,
I don´t have any extension installed.

Best regards,
Renato

[Ben-bucksch (ben-bucksch)]

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

[Bryan Clark (clarkbw)]

In bug 461098 we added a ( reply | v ) button with the reply all menu item as a first step toward this and to help get the styling correct.

In the next, b3, release I'd like to get this button to react to the message being displayed, showing "what we consider to be the best default" as the button face and still having other reasonable actions in the popup menu. Sorry for the huge bug comment.

Here's the set of default / popup menus I have been working with for each situation.

My goals have been this.
* use the correct default button in the appropriate situation
* refer to people / email addresses instead of header types like reply-to, sender
* provide a reasonable set of actions in the popup to balance a confusing list of all possible and an unhelpful list of too few.
* create an easy understanding of what the default action will do (as expectations obviously vary)

single recipient, no reply-to
( reply | v )____________________
 | reply to <email address hidden> |
 '-------------------------------'

single recipient, w/ reply-to
( reply | v )____________________
 | reply to <email address hidden> |
 |-------------------------------|
 | reply to <email address hidden> |
 '-------------------------------'

multiple recipients, no reply-to
( reply all | v )_______________________
 | reply to sender and recipients |
 |--------------------------------------|
 | reply only to <email address hidden> |
 | reply only to recipients (#) |
 '--------------------------------------'

multiple recipients, w/ reply-to
( reply all | v )________________________
 | reply to sender and recipients |
 |--------------------------------------|
 | reply only to <email address hidden> |
 | reply only to <email address hidden> |
 | reply only to recipients (#) |
 '--------------------------------------'

mailing list, no reply-to
( reply list | v )________________________
 | reply to mailing list <email address hidden> |
 |----------------------------------------|
 | reply only to <email address hidden> |
 | reply only to recipients (#) |
 '----------------------------------------'

mailing list, w/ reply-to
( reply list | v )________________________
 | reply to mailing list <email address hidden> |
 |----------------------------------------|
 | reply only to <email address hidden> |
 | reply only to <email address hidden> |
 | reply only to recipients (#) |
 '----------------------------------------'

mailing list, w/ multiple mailing lists
( reply list | v )_________________________
 | reply to mailing list <email address hidden> |
 |-----------------------------------------|
 | reply to mailing list <email address hidden> |
 | reply to mailing list <email address hidden> |
 | reply only to <email address hidden> |
 '-----------------------------------------'

mailing list, w/ multiple mailing lists and other recipients
( reply list | v )_________________________
 | reply to mailing list <email address hidden> |
 |-----------------------------------------|
 | reply to mailing list <email address hidden> |
 | reply only to <email address hidden> |
 | reply only to recipients (#) |
 '-----------------------------------------'

Altern...

[Temp2000 (temp2000)]

> single recipient, w/ reply-to
> ( reply | v )____________________
> | reply to <email address hidden> |
> |-------------------------------|
> | reply to <email address hidden> |
> '-------------------------------'

If the original sender has specified a reply-to address, maybe it would be most polite to default the button to the reply-to address instead of the From address.

[Bryan Clark (clarkbw)]

(In reply to comment #156)
> > single recipient, w/ reply-to
> > ( reply | v )____________________
> > | reply to <email address hidden> |
> > |-------------------------------|
> > | reply to <email address hidden> |
> > '-------------------------------'
>
> If the original sender has specified a reply-to address, maybe it would be most
> polite to default the button to the reply-to address instead of the From
> address.

right! good catch. I hope that was a copy/paste problem. Make that this instead:

single recipient, w/ reply-to
( reply | v )____________________
 | reply to <email address hidden> |
 |-------------------------------|
 | reply to <email address hidden> |
 '-------------------------------'

thanks!

[V+mozbug (v+mozbug)]

I like the expanded menu idea in comment #155. There is a second instance (mailing list) of not making Reply-To the default in cases where it exists. Like Pete, in comment #156, I think that if Reply-To exists, it should be the default.

But I think the list of choices you are offering is great, and expanding them to use the real email address is even better. Dunno from the examples if you are intending to include the "full name" part of the address or only the email address itself. Mozilla generally uses/preserves the whole thing, unlike AOL which drops the "full name" and Outlook, which suppresses/hides the email address wherever possible. I like the Mozilla approach, generally, of showing both, even though it is longer. I do have multiple friends named "Mike", etc., so both are handy to make it clear.

[Blake Winton (bwinton)]

Created an attachment (id=364625)
Reply To List button.

Patch coming soon.

[Blake Winton (bwinton)]

Created an attachment (id=364626)
The email replying only the list.

[Blake Winton (bwinton)]

Created an attachment (id=364629)
The patch.

It's a first cut, and definitely needs some work, but it works, albeit with some unnecessary beeping.

I'll be happy to develop this further, but I figured that having something to play with would at least get this a little bit closer.

Any assistance would also be appreciated, natch.

[Mkmelin+mozilla (mkmelin+mozilla)]

(In reply to comment #155)
Mainly wrt Reply-To addresses: I think having such an amount of choices, so visibly, doesn't help people do the right thing. Most of the time, users should only have to choose "Reply" or "Reply All", (or "Reply to list"). Giving too easy access to other than Reply-To addresses will only lead to wrong choices. Maybe a sub menu of some kind...

Likewise "Followup-To", "Mail-Followup-To", "Mail-Reply-To" and other headers are designed to tell the mail client what to choose for a "Reply"/"Reply-To".

(I also suspect having the e-mail included in the menu item doesn't look good, especially when the address is a bit longer.)

[Renato S. Yamane (renatoyamane)]

You have in mind any plan to do shortcuts to this new buttons?

Maybe this is *crazy* ideal, but:
- Reply: CTRL + r
- Reply to list: CTRL + rr
- Reply to all: CTRL + rrr

[Blake Winton (bwinton)]

It's currently:
- Reply: CTRL + r
- Reply to all: CTRL + SHIFT + r
- Reply to list: CTRL + SHIFT + r
(So the Reply to list shortcut totally doesn't work!)

I'll update the patch to use CTRL + SHIFT + L, so we'll have the following:
- Reply: CTRL + r
- Reply to all: CTRL + SHIFT + r
- Reply to list: CTRL + SHIFT + l
- Forward: CTRL + l

[Renato S. Yamane (renatoyamane)]

Good! Thanks!

[Blake Winton (bwinton)]

Created an attachment (id=364943)
Message menu with new key assignment.

[Blake Winton (bwinton)]

Created an attachment (id=364944)
New patch, with better key bindings.

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

[Bryan Clark (clarkbw)]

(In reply to comment #162)
> (I also suspect having the e-mail included in the menu item doesn't look good,
> especially when the address is a bit longer.)

I had thought there was a max-width that the menu wouldn't go beyond and would then cut off the email addresses when they are long. perhaps also adding an elipsis...?

[V+mozbug (v+mozbug)]

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

[Blake Winton (bwinton)]

Created an attachment (id=365222)
reply all button disabled.

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

[Blake Winton (bwinton)]

Created an attachment (id=365225)
A patch to disable reply all when there's only one address to reply to.

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

[Blake Winton (bwinton)]

Created an attachment (id=365301)
reply all button removed.

[Blake Winton (bwinton)]

Created an attachment (id=365303)
A patch to remove reply all when there's only one address to reply to.

Thinking about this a little more, I'm not sure that this patch is a good idea, since now there's not an easy way to reply to the sender as well as yourself, which is what "Reply All" used to do.

Still, it was good practice for removing the ReplyToList menuitem, which I'll need to do when that feature gets implemented.

[Blake Winton (bwinton)]

Created an attachment (id=365595)
A patch to remove reply all when there's only one address to reply to.

This patch also makes the default button "Reply All" when there's more than one recipient, and puts the "Reply" button in the sub-menu.

It also incorporates several style improvements from DavidA.

[Bryan Clark (clarkbw)]

(From update of attachment 365595)
This is looking really good! The default button change is going to be great.

I wouldn't change the reply button to a regular button though, it makes it resize (at least on win/lin) strangely and I think the effects will be odd. See my Comment #155 for more about that and what a regular reply button looks like.

Beyond that I think we'd be ready for some code reviews.

[Blake Winton (bwinton)]

Created an attachment (id=365962)
A patch to change the default button.

I'm planning on splitting the requested UI in Comment #155 into 3 patches.

This is the first, which changes the default button.
The second will add the Reply-To-List functionality.
The third will add the email addresses to the buttons.

[Bryan Clark (clarkbw)]

(From update of attachment 365962)
this looks good, but has some kind of bug updating the button.

Magnus can you take a look at this?

[Blake Winton (bwinton)]

In the next patch (adding the Reply-To-List feature), I've changed the code to be called from within the OnMsgLoaded function (in mail/base/content/mailWindowOverlay.js), instead of within the nsMsgDBViewCommandUpdater.displayMessageChanged method (in mail/base/content/messageWindow.js) and the updating is looking much smoother and more consistent.

I'll be happy to back-port the fix to patch 1, if you'ld like, Magnus, or I'll clean my debugging statements out of patch 2, and submit it, and you can see how I fixed it in that patch. Let me know which you'ld prefer.

Thanks,
Blake.

[Mkmelin+mozilla (mkmelin+mozilla)]

(From update of attachment 365962)
Yeah, there's some problem with updating the button when changing mails.

I think it's better to just do it all in one patch, especially as if you change entity string you have to bump the names...

>diff -r 7bfd2406b167 mail/base/content/mail3PaneWindowCommands.js
>--- a/mail/base/content/mail3PaneWindowCommands.js Fri Mar 06 14:50:59 2009 +0100
>+++ b/mail/base/content/mail3PaneWindowCommands.js Fri Mar 06 15:01:13 2009 -0500
>@@ -306,10 +306,15 @@
> return false; // else fall thru
> case "cmd_reply":
> case "button_reply":
>+ case "cmd_replyall":
>+ case "button_replyall":
>+ msgHdr = msgHdrForCurrentMessage();

Needs to be declared? (Or maybe it is alreay earlier, either way, not so nice.)

>+ let showReplyAllButton = msgHdr && (msgHdr.recipients.split(",").length > 1 || msgHdr.ccList);

Trailing space, but break the line after ||

>+ UpdateReplyButtons( showReplyAllButton?"replyAll":"reply" );

Here and else where, please skip the spaces after/before "("
(Add spaces around "?" though.)

>+ if ( command == "cmd_replyall" || command == "button_replyall" )
>+ return showReplyAllButton; // else fall through

Remove extra spaces.

>+ let replyAllButton = buttonBox.getButton('hdrReplyAllButton');
>+ let replyButton = buttonBox.getButton('hdrReplyButton');
>+
>+ if (replyAllButton)
>+ replyAllButton.hidden = (buttonsToShow != "replyAll");
>+
>+ if (replyButton)
>+ replyButton.hidden = (buttonsToShow != "reply");

The buttons don't always exist?
Also, please try to be consistent with " and '

[Blake Winton (bwinton)]

Created an attachment (id=366330)
A patch to change the default button, with fixes suggested by mkmelin.

> Yeah, there's some problem with updating the button when changing mails.

Fixed.

> I think it's better to just do it all in one patch, especially as if you
> change entity string you have to bump the names...

Perhaps, although the bit to add the Reply-To-List button is fairly big already, and I'm really enjoying using the functionality without changing the button names, so I think I'm going to keep it as 3 patches.

>>diff -r 7bfd2406b167 mail/base/content/mail3PaneWindowCommands.js
>>+ case "cmd_replyall":
>>+ case "button_replyall":
>>+ msgHdr = msgHdrForCurrentMessage();
> Needs to be declared? (Or maybe it is alreay earlier, either way, not so
> nice.)

The call has been moved into mail/base/content/mailWindowOverlay.js, where the function is defined. (I am still calling it earlier in the file than it's defined, but so is the UpdateJunkButton function, and I'm not sure whether both of those should be moved down below where msgHdrForCurrentMessage has been defined, or whether msgHdrForCurrentMessage should be moved up above those two functions, or if it doesn't matter, as long as they're in the same file. If you would like it to be changed, I'll be happy to change it.)

>>+ let showReplyAllButton = msgHdr &&
>> (msgHdr.recipients.split(",").length > 1 || msgHdr.ccList);
> Trailing space, but break the line after ||

Fixed.

>>+ UpdateReplyButtons( showReplyAllButton?"replyAll":"reply" );
> Here and else where, please skip the spaces after/before "("
> (Add spaces around "?" though.)

Fixed.

>>+ if ( command == "cmd_replyall" || command == "button_replyall" )
>>+ return showReplyAllButton; // else fall through
> Remove extra spaces.

Fixed. Well, deleted, but I'll remove them in the future if I add similar constructs.

>>+ if (replyAllButton)
>>+ replyAllButton.hidden = (buttonsToShow != "replyAll");
>>+ if (replyButton)
>>+ replyButton.hidden = (buttonsToShow != "reply");
> The buttons don't always exist?

Fixed.

> Also, please try to be consistent with " and '

Fixed.

Sorry it took me so long to update the patch, my weekend was busier than I thought it would be.

Thanks,
Blake.

[Mkmelin+mozilla (mkmelin+mozilla)]

(From update of attachment 366330)
There seems to be at least of cases where this doesn't do what it should.
 o newsgroups (all you can do is "reply")
 o lists, and when I'm bcc:ed I think

The only case when "All" shouldn't be needed is when it's addressed exactly to me, no?

>+function UpdateReplyButtons(aUrl)

You don't use the aUrl

>+{
>+ let msgHdr = msgHdrForCurrentMessage();
>+ let showReplyAll = msgHdr && (msgHdr.recipients.split(",").length > 1 ||
>+ msgHdr.ccList);

  let showReplyAll = msgHdr && (msgHdr.recipients.split(",").length > 1 ||
                                msgHdr.ccList);

[Ludovic-mozillamessaging (ludovic-mozillamessaging)]

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

[Bryan Clark (clarkbw)]

(From update of attachment 364944)
removing this review. we can do the keybinding in a (much smaller) separate patch.

[Bryan Clark (clarkbw)]

Blake, I'm guessing you don't have much time for this at this point. I'm adding sid0 to the CC so if that's true sid can take over this patch.

I feel like this piece is pretty necessary so I'm marking it blocking again and targeting b3 even though I know it's too tight so it could slip and block the next release.

[Blake Winton (bwinton)]

Created an attachment (id=376569)
Use the aUrl to handle news and handle when I'm bcc:ed.

Brian, I haven't had a lot of time last month, but this month looks a little more free. Here's the latest patch I have, which seems to fix the problems Magnus mentioned, albeit not in a super-clean way.

Specifically, I don't think this is the best way to tell if a message is sent exactly to me or not, but it seems to work in the cases I've tested, and I couldn't find a better way.

If Sid0 has some time to help me out with some code reviews/questions on IRC, I would love to continue working on it.

(I'm also going to post a patch that adds the reply-to-list button, which is based on this patch, to hopefully get comments on it as well.)

[Blake Winton (bwinton)]

Created an attachment (id=376573)
A patch to add the reply-to-list button, based on top of patch 376569.

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

[Josh Berkus (josh-agliodbs)]

Blake,

Speaking from a user perspective, I really don't care if the message was To me and CC the list or vice-versa. If I understand some of the patch stuff, I think you're making this more complex than it needs to be. If there is a "reply-to-list" header in the message, the reply-to-list button should reply to that address. Regardless of how it arrived in my e-mail. "Reply" should reply to the Sender, or to the "Reply-To" address if one is present.

In fact, I'd recommend against monkeying with default "reply" behavior in the presence of mailing lists. The Kmail crew did this a couple years ago, and the end result was a lot of people (including me) sending mails to the list which we meant to be private; they reverted the changes later. Let's don't repeat the same mistake with Thunderbird: leave it up to the user to whom he wants to reply.

If I've misunderstood the patch, never mind, but please keep the commentary above in case someone decides to get clever later.

[Blake Winton (bwinton)]

(In reply to comment #187)
> The Kmail crew did this a couple years ago, and the
> end result was a lot of people (including me) sending mails to the list which
> we meant to be private; they reverted the changes later. Let's don't repeat
> the same mistake with Thunderbird: leave it up to the user to whom he wants to
> reply.

I think you've slightly misunderstood the patch. The "Reply" button will always only reply to the sender. (Well, or to the Reply-To address, which may point to a list, if the list sets it that way... The point is that I'm not changing that behaviour at all.)

I am adding a "Reply To List" button, and changing which button shows up at the top of the message (which I've been calling the "Default button"), but since you'll be looking at that button when you're clicking it, I think it will be fairly obvious when it changes from "Reply" to "Reply To List". And the keybindings won't change, so Ctrl-R will always reply, and Ctrl-Shift-L will always be reply-to-list, no matter which button is showing as the default.

Does that allay some of your concerns? Would you be up for applying the patch, and testing it out to see if it works for you?

Thanks,
Blake.

[Josh Berkus (josh-agliodbs)]

Blake,

OK, just making sure. I guess I did misunderstand the patch.

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

[Ben-bucksch (ben-bucksch)]

FYI, from what I understood from the patches (please correct me if I'm wrong):
It looks for the List-Post: header (which all mailing lists I checked have, including Mailman), and uses that to decide to show the "reply list" button instead. The other reply variations are still available as drop-down menu, see comment 155 ff for specs. If "reply list" is clicked, the backend code (comment 80) will read the List-Post header and post to the email address given there. This is the entirely correct and perfect behavior (and more than I hoped for), thanks Peter McCurdy and Blake!

Blake: as far as I can see, the code leaves the "reply to list" dropdown menu item (in contrast to the button) always enabled. I think you'll want to disable that, because the backend code then can't do anything meaningful, as it looks for the List-Post header which is not there. I think it falls back to normal reply, but that's then redundant in the UI and irritating result.

[Renato S. Yamane (renatoyamane)]

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

Regards,
Renato

[Mkmelin+mozilla (mkmelin+mozilla)]

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

[Mkmelin+mozilla (mkmelin+mozilla)]

(From update of attachment 376569)
>+function UpdateReplyButtons(aUrl)
>+{
>+ let msgHdr = msgHdrForCurrentMessage();
>+ let showReplyAll = true

Please add trailing ';' - those are missing in quite a few places.

>+ replyAllButton.hidden = (buttonToShow != "replyAll");
>+
>+ debugger;

Remove the debugger

I had the updating issue with only this patch applied too, fwiw.

[David-ascher (david-ascher)]

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

[Mkmelin+mozilla (mkmelin+mozilla)]

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

Davida: that's bug 327713.

[Ben-bucksch (ben-bucksch)]

> when reading news where List-Post is available - like the mozilla newsgroups
> - should give reply to list as default option?

No: If I read the newsgroup, it should show "reply to newsgroup" as default button, and go to newsgroup. I chose to use NNTP, and most likely are not subscribed -> not allowed to post to mailing list. I.e. that would simply be a bug.

[Blake Winton (bwinton)]

(In reply to comment #190)
> Blake: as far as I can see, the code leaves the "reply to list" dropdown menu
> item (in contrast to the button) always enabled. I think you'll want to disable
> that, because the backend code then can't do anything meaningful, as it looks
> for the List-Post header which is not there. I think it falls back to normal
> reply, but that's then redundant in the UI and irritating result.

Yeah, I'll try to add this in tonight, asking in IRC for some pointers on how
to enable/disable menu items.

(In reply to comment #196)
> No: If I read the newsgroup, it should show "reply to newsgroup" as default
> button, and go to newsgroup.

This will be part of patch 3 (add the email addresses to the buttons), if I ever get patches 1 (change the default button) and 2 (add the Reply-To-List functionality) committed.

(In reply to comments #193 and #195)
> Please add trailing ';' - those are missing in quite a few places.

Done.

> Remove the debugger

Done.

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

I've fixed the lines that I added with trailing whitespace/only whitespace. I
have left the lines with trailing whitespace that I didn't touch, to minimize
the diff. I'm happy to do a big patch which cleans up all the trailing
whitespace, but that's a different problem, and should probably go under a
different bug.

> I had the updating issue with only this patch applied too, fwiw.

Cool, that'll make it easier to track down. Is there any more info you can
give that will help me figure out what's going wrong? Steps to reproduce,
maybe?

I'll post a new patch once I've fixed the updating bug and disabled the reply-to-list menu item.

Thanks,
Blake.

[Bryan Clark (clarkbw)]

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

[Mkmelin+mozilla (mkmelin+mozilla)]

Re the whitespace: yeah i only meant for stuff you add/change.

Comment 198 sounds a lot like the updating issue I was talking about.

[Blake Winton (bwinton)]

Created an attachment (id=376945)
Patch fixing the update bug, and cleaning up whitespace and semicolons.

[Blake Winton (bwinton)]

Created an attachment (id=376946)
A patch to add the reply-to-list button, based on top of patch 376945.

I'm currently removing the Reply to List menu option entirely (when it's not appropriate), because I couldn't get it to disable correctly. Any pointers on how to get the disabling working would be welcome, either through email or on IRC.

[David-ascher (david-ascher)]

Blake: Stop searching, I'd say -- I don't think it makes sense to have a disabled reply-to-list for messages that aren't to lists. Disabling should be for things where there are changes that the user can make to enable things, IMO.

[Bryan Clark (clarkbw)]

Yeah, there's no point in having a disabled menu item that cannot (on that message) become enabled though some kind of normal user process.

[John Vivirito (gnomefreak)]

Is the final patch before commiting the patch the following one.
This is the patch at the end of the upload patches to this bug?
https://bug45715.bugzilla.mozilla.org/attachment.cgi?id=376946

[Bugzilla-standard8 (bugzilla-standard8)]

(In reply to comment #204)
> Is the final patch before commiting the patch the following one.
> This is the patch at the end of the upload patches to this bug?

Until the patch has been reviewed and is ready for checkin, we can't say if any patch is the final patch for a bug.

[Blake Winton (bwinton)]

(In reply to comment #205)
> (In reply to comment #204)
> > Is the final patch before commiting the patch the following one.
> > This is the patch at the end of the upload patches to this bug?
>
> Until the patch has been reviewed and is ready for checkin, we can't say if any
> patch is the final patch for a bug.

That's true, although I can say that this isn't the final patch for this bug. I've found and fixed a bug in a message that was cc-ed to me and sent to no-one, but my patch depends on the patch in https://bugzilla.mozilla.org/show_bug.cgi?id=326809#c13 being committed.

So, you can expect at least one new patch from me for this bug, although it only fixes a relatively uncommon case.

[Bryan Clark (clarkbw)]

just to note that I think bug 248681 will need to be next on the list after this bug in order to complete the new circle of reply all life we are entering.

[Blake Winton (bwinton)]

Created an attachment (id=377404)
A patch handling the case where I'm cc:-ed, and no-one is to:-ed.

As mentioned before, this depends on the patch from https://bugzilla.mozilla.org/show_bug.cgi?id=326809#c13 but it definitely fixes the bug I was seeing.

One thing I was unsure about was the correct indentation for the following two statements:
  let hdrParser = Components.classes[
    "@mozilla.org/messenger/headerparser;1"].getService(
    Components.interfaces.nsIMsgHeaderParser);
and:
  let buttonBox = document.getElementById(gCollapsedHeaderViewMode ?
    "collapsedButtonBox" : "expandedButtonBox");

Thanks,
Blake.

[Mkmelin+mozilla (mkmelin+mozilla)]

(From update of attachment 376945)
Assuming this is obsolete.. ?

[Blake Winton (bwinton)]

(In reply to comment #209)
> (From update of attachment 376945 [details])
> Assuming this is obsolete.. ?

Yes. 377404, or one of the later patches, should have obsoleted it. I suppose I forgot to click that checkbox. My apologies.

I have no plans on updating the patches after 377404 and 376946 (other than issues you raise/suggestions you make), so if you're feeling in a reviewing sort of mood, have at it. :)

(Oh, and 376946 which should now be based on top of 377404, instead of 376945.)

Thanks,
Blake.

[Mkmelin+mozilla (mkmelin+mozilla)]

(In reply to comment #208)
> One thing I was unsure about was the correct indentation for the following two
> statements:
> let hdrParser = Components.classes[
> "@mozilla.org/messenger/headerparser;1"].getService(
> Components.interfaces.nsIMsgHeaderParser);

We usually do this (very common case)

let hdrParser = Components.classes["@mozilla.org/messenger/headerparser;1"]
                          .getService(Components.interfaces.nsIMsgHeaderParser);

[Mkmelin+mozilla (mkmelin+mozilla)]

(From update of attachment 377404)
I don't have the updating problem with this, yay!

This shows Reply All as default for news now. Other than that, looks pretty good . You could also fix the indention per previous comment.

[Bryan Clark (clarkbw)]

(From update of attachment 376946)
this looks good. we should probably open a separate bug to get a reply-list icon made instead of reusing the reply-all icon.

[Blake Winton (bwinton)]

Created an attachment (id=378660)
The latest version of the change-default-button patch.

We now show Reply as the default news button, and I've fixed the indentation as above.

[Blake Winton (bwinton)]

Created an attachment (id=378664)
The latest version of the add-reply-button patch, based on top of patch 378660.

This is mainly to rebase on top of the other patch, for a merge without fuzzy matching.

[Mkmelin+mozilla (mkmelin+mozilla)]

Good news and bad news. The good news is it seems to work almost as it should. Problems:
 o i still get the updating problem - even such that with the detailed headers showing things are ok, but when i switch to compact the wrong button gets shown
 o now there is no reply-all at all in news. sorry if i was unclear, i only meant it shouldn't be the default

With this approach the latter point (changing order) seems tricky to do, without another button with the other order... which really makes me wonder if there isn't a better way to do this. So, now we create tree buttons

 Reply Reply All Reply List
                 Reply Reply All
                                   Reply

(or something similar)
... and hide the wrong ones.

Maybe someone has better ideas how this should be done, but it's not elegant at all. Is there a way to only have one button with all elements, only disabling/showing the ones we want, similar to a deck?

[Mkmelin+mozilla (mkmelin+mozilla)]

(From update of attachment 378660)
>+function UpdateReplyButtons(aUrl)
>+{
>+ let msgHdr = msgHdrForCurrentMessage();
>+
>+ let myEmail = getIdentityForHeader(msgHdr).email;
>+ let recipients = msgHdr.recipients + "," + msgHdr.ccList;
>+
>+ // If my email address isn't in the to or cc list, then I've been bcc-ed.
>+ let imBcced = recipients.indexOf(myEmail) == -1;
>+
>+ // Now, let's get the number of unique recipients
>+ let hdrParser = Components.classes["@mozilla.org/messenger/headerparser;1"]
>+ .getService(Components.interfaces.nsIMsgHeaderParser);
>+ let addresses = {};
>+ let names = {};
>+ let fullNames = {};
>+ let uniqueRecipients = hdrParser.removeDuplicateAddresses(recipients, {});
>+ let numAddresses = hdrParser.parseHeadersWithArray(uniqueRecipients, addresses,
>+ names, fullNames);

You can pass in {} without naming the fields here, for the stuff you don't need later, no?

>+ // If we're Bcc:-ed, we should show the ReplyAll button.
>+ let showReplyAll = true;
>+ if (aUrl.scheme == "news")
>+ // If it's news, we should not show the ReplyAll button.
>+ showReplyAll = false;

Per previous comment, we should, only not as default.

[Mkmelin+mozilla (mkmelin+mozilla)]

(From update of attachment 378664)
>- let buttonToShow = showReplyAll ? "replyAll" : "reply";
>+ let showReplyList = aUrl && aUrl.mimeHeaders &&
>+ aUrl.mimeHeaders.extractHeader("List-Post", false);
>+ let buttonToShow = showReplyList ? "replyList" :
>+ showReplyAll ? "replyAll" : "reply";

While it might be correct, this sure is almost unreadable... use an if clause to improve readability?

>+ let replyListCommand = document.getElementById("cmd_replylist");
>+ replyListCommand.disabled = !showReplyList;

I think you're supposed to return true/false for the list commands when they get checked in mail3PaneWindowCommands.js+messageWindow.js isCommandEnabled()

>+ <key id="key_replylist" key="&replyToListMsgCmd.key;" oncommand="goDoCommand('cmd_replylist')" modifiers="accel, shift"/>

Nit: Alignment is off here, though it's a very long line so you can also wrap it and align oncommand with the id on the previous line.

>+ <menuitem id="menu_replyToList" label="&replyToListMsgCmd.label;"
>+ accesskey="&replyToListMsgCmd.accesskey;"
>+ key="key_replylist"
>+ command="cmd_replylist"/>

Nit: Align accesskey with the id on the previous line here too although the surrounding stuff isn't well aligned.

BTW, please submit these too patches as one for the next round, as they will go in together anyway.

[Blake Winton (bwinton)]

Created an attachment (id=379240)
The latest patch, with the previous two merged

(In reply to comment #217)
> i still get the updating problem - even such that with the detailed headers
> showing things are ok, but when i switch to compact the wrong button gets
> shown

That was exactly the clue I needed to fix this. Thank you!

> >+ let addresses = {};
> >+ let names = {};
> >+ let fullNames = {};
> You can pass in {} without naming the fields here, for the stuff you don't
> need later, no?

Fixed.

> >+ if (aUrl.scheme == "news")
> >+ // If it's news, we should not show the ReplyAll button.
> >+ showReplyAll = false;
> Per previous comment, we should, only not as default.

Fixed. We still have three buttons.
Reply Reply All Reply To List
----- --------- -------------
Reply All Reply Reply All
                             Reply

But the "-----" and "Reply All" in the first button get shown for news/hidden otherwise.

(In reply to comment #218)
> >+ let buttonToShow = showReplyList ? "replyList" :
> >+ showReplyAll ? "replyAll" : "reply";
> While it might be correct, this sure is almost unreadable... use an if clause
> to improve readability?

Fixed.

> >+ <key id="key_replylist" key="&replyToListMsgCmd.key;" oncommand="goDoCommand('cmd_replylist')" modifiers="accel, shift"/>
> Nit: Alignment is off here, though it's a very long line so you can also wrap
> it and align oncommand with the id on the previous line.

Fixed. None of the elements around it are split between lines, so I'm leaving this one on one line.

> >+ <menuitem id="menu_replyToList" label="&replyToListMsgCmd.label;"
> >+ accesskey="&replyToListMsgCmd.accesskey;"
> >+ key="key_replylist"
> >+ command="cmd_replylist"/>
> Nit: Align accesskey with the id on the previous line here too although the
> surrounding stuff isn't well aligned.

Fixed, and I've cleaned up the stuff around it, cause I was there.

> BTW, please submit these too patches as one for the next round, as they will go
> in together anyway.

Done, and done.

> >+ let replyListCommand = document.getElementById("cmd_replylist");
> >+ replyListCommand.disabled = !showReplyList;
> I think you're supposed to return true/false for the list commands when they
> get checked in mail3PaneWindowCommands.js+messageWindow.js isCommandEnabled()

I'm going to look into this one, but I wanted to get the latest patch up, to see if there is anything else I can change while I'm fixing that. (Note for me: Check out mail/base/content/mail3PaneWindowCommands.js, line 332-ish.)

Many thanks to dmose who helped me out a lot on IRC this afternoon.

Later,
Blake.

[John Vivirito (gnomefreak)]

Ok there are a few patches i want to testr from upstream so i will patch SM2 for sure and see iif maybe we should add patch to daily TB.
This fix will NOT land in TB2 so can someone please decline the nomnation.

[Mkmelin+mozilla (mkmelin+mozilla)]

(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

[John Vivirito (gnomefreak)]

I'm taking this. This wioll not get fixed in thunderbird-2 nor seamonkey-1.x
I will be adding the test patch to seamonkey-2 sometime in the near future.

[John Vivirito (gnomefreak)]

No need to fix this on our end. the patch is just about ready for commit. I will try to update 2.0 one more time for about a month, depending on if i can see or not.

Thanks for the declines for nominations.

[Blake Winton (bwinton)]

(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.

[Mkmelin+mozilla (mkmelin+mozilla)]

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

[Mkmelin+mozilla (mkmelin+mozilla)]

Note that msgHdr.folder is null for .eml files

[Blake Winton (bwinton)]

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.

[Mkmelin+mozilla (mkmelin+mozilla)]

(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.

[Blake Winton (bwinton)]

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.

[Bienvenu (bienvenu)]

(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());

[John Vivirito (gnomefreak)]

Ok i am updating Seamonkey-2.0 to latest snapshot. If everything goes well great if not i will wait for final patch.
I should have this in PPA for all supported Ubuntu versions by the end of weekend.

[Bienvenu (bienvenu)]

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

[Blake Winton (bwinton)]

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.

[Bugzilla-standard8 (bugzilla-standard8)]

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

[John Vivirito (gnomefreak)]

On 05/28/2009 08:30 AM, John Vivirito wrote:
> Ok i am updating Seamonkey-2.0 to latest snapshot. If everything goes well great if not i will wait for final patch.
> I should have this in PPA for all supported Ubuntu versions by the end of weekend.
>
Seamonkey-2 is failing to build. I might try it in 1.x until i figure
out what failed.

--
Sincerely Yours,
    John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246

"How can i get lost, if i have no where to go"
    -- Metallica from Unforgiven III

[Rimas Kudelis (rq)]

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

[Blake Winton (bwinton)]

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.

[Blake Winton (bwinton)]

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.

[Mkmelin+mozilla (mkmelin+mozilla)]

(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";|

[Blake Winton (bwinton)]

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.

[Mkmelin+mozilla (mkmelin+mozilla)]

(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

[Blake Winton (bwinton)]

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!

[Blake Winton (bwinton)]

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

[Philringnalda (philringnalda)]

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 :)

[Blake Winton (bwinton)]

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.

[Philringnalda (philringnalda)]

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

[Blake Winton (bwinton)]

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

[John Vivirito (gnomefreak)]

There are bugs upstream is working on on the reply-to-list atm and should make it into thunderbird-3.0 but they work in 3.0 testing packages it just that it replies to everyone not just list, that is bad behavour, Its kind oif like spam to reply to everyone on the comment you reply to. I think it sent it to yourself as well.

[Wanderer-fastmail (wanderer-fastmail)]

(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?

[Bryan Clark (clarkbw)]

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.

[Wanderer-fastmail (wanderer-fastmail)]

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.

[Josh Berkus (josh-agliodbs)]

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.

[Blog-tessarakt (blog-tessarakt)]

(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

[Felix Miata (mrmazda)]

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

[Ben-bucksch (ben-bucksch)]

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

[Micah Gersten (micahg)]

Moving to thunderbird package pending release of Thunderbird 3 to Lucid.

[John Vivirito (gnomefreak)]

On 12/13/09 08:03, Micah Gersten wrote:
> Moving to thunderbird package pending release of Thunderbird 3 to Lucid.
>
> ** Changed in: thunderbird
> Milestone: None => 3.0
>
> ** Package changed: mozilla-thunderbird (Ubuntu) => thunderbird (Ubuntu)
>
> ** Changed in: thunderbird (Ubuntu)
> Importance: Undecided => Wishlist
>
I'm not seeing this issue anymore in tbird-2 and tbird-3. I am
wondering if it is the patch we made.

--
Sincerely Yours,
    John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246

"How can i get lost, if i have no where to go"
    -- Metallica from Unforgiven III

[Launchpad Janitor (janitor)]

This bug was fixed in the package thunderbird - 3.0+nobinonly-0ubuntu1

---------------
thunderbird (3.0+nobinonly-0ubuntu1) lucid; urgency=low

  * New Upstream Release 3.0 (THUNDERBIRD_3_0_RELEASE)
    - LP: #50902 - Thunderbird displays useless dialog
    - LP: #52667 - Thunderbird doesn't support RFC-2369
    - LP: #49033 - Doesn't recognize upper case extension (.JPG)
    - LP: #56465 - Per folder column widths
    - LP: #68456 - CTRL-Shift-K bound to 2 functions
    - LP: #79337 - Typo in Server Information for Add Account Wizard
    - LP: #1084 - No scroll on full headers list
    - LP: #62071 - Middle click on scrollbar pastes instead of jumping
    - LP: #119358 - Weak default authentication mode
    - LP: #120672 - No option to empty junk folder with right click
    - LP: #96566 - movemail doesn't work with default privs
    - LP: #122529 - Non-Thunderbird IMAP folders not visible to Thunderbird
    - LP: #241276 - Not able to paste image into thunderbird compose window
    - LP: #244635 - scrollboxes scroll to offset 0 when resized
    - LP: #259387 - "Edit Message as New" broken for eml messages
    - LP: #120281 - Editing a message from the drafts folder leaves line breaks
    - LP: #115484 - Dialogue boxes too large for 1024x768 resolution
    - LP: #320034 - Mail with self referencing headers breaks threading
    - LP: #160794 - shortcuts different in windows and linux
    - LP: #280987 - thunderbird keeps asking a password when working off-line
    - LP: #369150 - Thunderbird splits email addresses with non-ascii characters
                    and a comma in From: field
    - LP: #135066 - Thunderbird doesn't use Ubuntu icon theme
    - LP: #297301 - after authentication error the password is forgotten
    - LP: #487541 - thunderbird-bin crashed with SIGSEGV (AFS filesystem)
    - LP: #485224 - Thunderbird saves double attachment file name endings on
                    FAT32 and NTFS
    - LP: #482496 - When using SCIM ANTHY, autosaving fails, and then get asked
                    about sending in UTF-8

  [ Fabien Tassin <email address hidden> ]
  * Add build-depends on autoconf2.13, autotolls-dev, mozilla-devscripts
    libglib2.0-dev (>= 2.12), libstartup-notification0-dev, libbz2-dev,
    libpixman-1-dev, libdbus-1-dev (>= 1.0.0), libdbus-glib-1-dev (>= 0.60),
    libhal-dev (>= 0.5.8), libasound2-dev, libreadline5-dev | libreadline-dev,
    libkrb5-dev
  * Update build-depends minimums for libx11-dev (>= 2:1.0),
    libgtk2.0-dev (>= 2.12), zlib1g-dev (>= 1:1.2.3), libpng12-dev (>= 1.2.0),
    libjpeg62-dev (>= 6b), libcairo2-dev (>= 0.5.8), libgnome2-dev (>= 2.16),
    libgnomevfs2-dev (>= 1:2.16), libgnomeui-dev (>= 2.16),
    libnss3-dev (>= 3.12.0~1.9b3)
  * Bump standards version to 3.8.0
  * Replace ${Source-Version} by ${binary:Version} in control file
    - update debian/control
  * Bump requirement for system nspr to >= 4.8 since Mozilla bug 492464 landed
  * Bump requirement for system nss to >= 3.12.3 since Mozilla bug 485052 landed
  * Use in-source hunspell when hunspell 1.2 is not available
  * Add conditionnal support for --with-libxul-sdk controlled by
    $(USE_SYSTEM_XUL)
    - update debian/rules
  * Add p...

[Micah Gersten (micahg)]

Fixed in Seamonkey 2.0.4 in Lucid

[Josh Berkus (josh-agliodbs)]

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