Comment 182 for bug 52667

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