17796 - Reply, Reply All, Forward, and Next should be dual menubuttons (dropdown, drop-down)

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P2)

Description

[Phil Peterson]

In 4.x, we had toolbar buttons for Reply and Reply All, which we have in mozilla
right now. However, 4.x also has a menu under each button which has choices
about who you want to reply to. We need to bring that design over into mozilla.

Not sure how this fits with the round toolbar buttons. cc'ing german.

Comment 1

[german]

we are working on those Received proposed XUL syntax from hyatt. Probably will
be small white rectangle on lower right corner, while target area for this
specific arrow area would span a full-height portion of the right side of the
button. Getting back to this back a soon as we have a good looking proposal up
and running.

Comment 2

[selmer (gone)]

Syncing priority with marketing.  Moving to P2 to connote "In" for beta2.

Comment 3

[scottputterman]

I can take this.  If the backend is working, I can make the frontend menus 
appear.

Comment 4

[esther]

Note: Bug 35742 was logged for these menus missing as well as the Forward button 
missing menu.  I will close that bug and add the forward button missing menu to 
this one.  If anyone disagrees please state that in this bug and reopen 35742.

Adding: Forward toolbar button missing menu choices.

Comment 5

[esther]

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

Comment 6

[scottputterman]

I really don't see this as a feature so I'm removing it.  Moving to M17.

Comment 7

[scottputterman]

moving to future milestone.

Comment 8

[Ben Bucksch (:BenB)]

FUTURE???

"Reply to sender" is a basic and frequent action for news clients. Currently, we
have neither a (menu under a) button nor a menu item for that. We need both. (We
even have "Print Preview" in the button menu, a function 4.x lived without.)
Should be fairly easy to implement.

It's also a GNKSA MUST:
<quote src="http://www.xs4all.nl/~js/gnksa/gnksa.txt">
2)  Provide clear, separate commands for new posting, followup, and
    e-mail reply
</quote>

nsbeta2

Comment 9

[scottputterman]

I agree we need it in the menu items. But we felt we could live without it in 
the buttons.

Comment 10

[Jay Patel [:jay]]

Putting on [nsbeta2-] radar. Not critical to beta2. 

Comment 11

[Ben Bucksch (:BenB)]

assuming this is no feature as putterman said, nominating for nsbeta3.

Comment 12

[Ben Bucksch (:BenB)]

(otherwise I'd yell out loud.)

Comment 13

[timeless]

Composition?? Changing component. I'll try to do this.

Comment 14

[selmer (gone)]

change b3mail to nsbeta3.

Comment 15

[timeless]

Mass accepting.

Comment 16

[Jean-Francois Ducarroz]

Let me know if you need my help...

Comment 17

[timeless]

[e-mail] well, I need someone's help.
The bug does not completely describe nc4.x's behavior:
in Mail, Reply and Reply All are normal buttons
in News, Reply and Reply All are menu buttons
I don't know how to do this. But I think it is the correct thing to do.

Ben, German, mpt, jglick:
Should I emulate nc4's behavior?

Comment 18

[Ben Bucksch (:BenB)]

Personally, I am not happy with 4.x' choices. Details later. But, I think, if 
the functionality is implemented, changing the choices should be trivial. So, 
if you ask me, just go, and we can fine-tune things later.

Comment 19

[scottputterman]

When we were working on 4.x we had the choice of not having the menus for mail 
or being redundant and specifying the default behavior in the menu even if there 
was only one item.

My feeling is that it wouldn't be the worst thing in the world to have menus 
with only one item if this is easier.

Another way to do this would be to have multiple reply buttons and hide them 
depending on whether you are in mail or news.

Another way would be to hide the menu when you are in mail (don't know how hard 
that would be since I've never used one of these buttons yet)

Comment 20

[Matthew T (active 1999-2002)]

In 4.x for Mac, `Reply' and `Reply All' are menubuttons no matter where you are; 
irrelevant menu items are disabled. I think this is much preferable to having 
separate button sets for mail messages and menubuttons for Usenet messages.

Remember, with the Classic skin (and probably other, future, skins), menubuttons 
are actually wider than ordinary buttons; so if the Reply buttons were normal 
buttons in mail and menubuttons in Usenet, they'd jump around on the toolbar when 
you shifted from one to the other. And that would be Bad.

`Reply' menu (button does the usual reply)
------------
to _Sender [Only]  [Ctrl+R if in mail] [the word `Only' included if in Usenet]
to _Group          [Ctrl+R if in Usenet]

`Reply All' menu (button does `Reply to Everyone')
----------------
to Sender and _All Recipients
to Sender and _Group
to _Everyone                   Ctrl+Shift+R

Comment 21

[Ben Bucksch (:BenB)]

I agree with Matthew that we should have menus for mail. I can think of at least
one additional case: Reply to Recipients, but not author. This is very useful
for mailing-lists. Even if we won't include it in the default distribution
(although I hope we will), having a menu for the button makes it much easier to
create such a customized version.

Please do not use the term "sender", but "author". Per RFC822, the "From" header
shows the author(s), while the "Sender" header shows the sender, which can be
different from the author(s).

Comment 22

[Daniel Veditz [:dveditz]]

Adding nsbeta2 keyword to bugs with nsbeta2 triage value in status field so the 
queries don't get screwed up

Comment 23

[lchiang]

If you have a fix, please try to get a review and approval by going through the 
Mozilla review/approval process.

But, not holding Netscape PR3 for, so - per mail triage in response to nsbeta3 
nomination.

Comment 24

[[e-mail]]

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

Comment 25

[[e-mail]]

See bug 65203 for possible XUL (not in diff format cos I don't know how).

Whoever fixes the skins for the mark button needs to do these as well.

Comment 26

[[e-mail]]

Attachment: Patch to make InitMessageMenu use observers instead of menuitems

Comment 27

[[e-mail]]

Attachment: XUL to convert Reply, Forward and Next into dual menubuttons

Comment 28

[scottputterman]

Thanks for looking into this.  I don't have a build to try this out on so my
comments are on what I think the code is doing.

First, it looks like you removed the reply all button and put it in the menu
under the reply button.  I don't like this.  It's very handy to have access to
reply all without having to click on a menu. There are also choices you could
put in a reply all menu as mentioned above. But for the moment if we don't have
them implemented we could at least leave it as a single button.

Second, in terms of coding, InitMessageMenu was meant to handle setting up the
Message menu in the main toolbar.  I don't have any problem with reusing code
but I'd prefer to reuse only the code that matters. Could you break out the code
in InitMessageMenu relating to Reply and create a function called something like
InitReply and have InitMessageMenu call it and then have the button menu call it
as well?  That way we don't have to worry in the future that adding something to
InitMessageMenu unrelated to reply will mess up the reply button.

Comment 29

[Ben Bucksch (:BenB)]

Neil, thanks also from me for looking into it. Feel free to take the bug, if you
want to (I'd ask timeless first, but I think, he would be glad to give it to you).

> But for the moment if we don't have
> them implemented we could at least leave it as a single button.

IIRC, the backend supports exactly the same options as 4.x did in the UI
(unfortunately not more - I'd like to add more options).

Comment 30

[timeless]

this isn't normally part of diff output:
*****CVS exited normally with code 1*****

+                       <menubutton class="menubutton-dual toolbar top" 
id="button-reply" value="&replyButton.label;" tooltip="aTooltip" 
tooltiptext="&replyButton.tooltip;" observes="button_reply" 
oncommand="MsgReplyMessage(event)" oncreate="InitMessageMenu()">

that line is _way_ too long, and you've been doing a good job of repairing that 
sort of problem.   Please aim for 80-100 columns.

yes feel free to take any bug i haven't worked on.

<menuitem value="&replyMsgCmd.label;" ... default="true"/>
...
<menuitem value="&replyNewsgroupCmd.label;" ... default="true"/>

is it safe to mark two items as default? [would it be better to have 
javascript add/remove the default attribute?] shouldn't there be id's for these 
items?

<button ... id="button-delete-disabled" ... disabled="true"/>
<button ... id="button-delete" .../>
I think css should be used for whatever purpose button-delete-disabled serves 
instead of two separate buttons.

<menupopup oncreate="InitMessageMark()" oncommand="event.preventBubble()">
blake goes through xul occasionally to add ;'s after (), please add them.

[e-mail]: thanks for adopting this bug.
i'll gladly r= this work when it's ready. reassigning to [e-mail]
if you need someone to checkin, i can do that too.

Comment 31

[Matthew T (active 1999-2002)]

Correcting summary. If you turn `Reply' and `Reply All' into a single 
menubutton, a hundred thousand mailing list maintainers and jwz will take it in 
turns to torture you.

Comment 32

[[e-mail]]

In reply to [e-mail],
Sorry about the long line.
The two default items never appear at the same time.
The button-delete-disabled was something that crept into the diff by mistake.
In reply to [e-mail],
Sorry that I deleted Reply All by mistake.
Would you like me to remove Reply All from the Reply menubutton menu?
If so, that would leave only one menuitem when replying to mail.
Would you want Reply to convert into a dual menubutton for news only?

Comment 33

[[e-mail]]

Sorry for the spam but I missed a couple of questions:
I can only see one sort of Reply All, didn't Communicator have two?
Also, would you prefer disabled or hidden menuitems?

Comment 34

[scottputterman]

Communicator didn't have button menus when in mail.  They only occurred when in
News.  Reply had To Sender, To Newsgroup. Reply All had To Sender and All
Recipients and To Sender and Newsgroups. 

So, a couple of more comments. I think having the Reply and Forward menus in the
Reply and Forward menu buttons is redundant since the button is going to do that
for you anyway. I think Reply All should be removed from the Reply button menu.
 The main menus hide the news menuitems when in mail.  I think the button menus
should do the same.  I think if possible, the button menus should be disabled
when in mail or they should just be single buttons since there aren't any choices.

Comment 35

[[e-mail]]

[e-mail] wrote:
> Communicator didn't have button menus when in mail.  They only occurred when
> in News.  Reply had To Sender, To Newsgroup. Reply All had To Sender and All
> Recipients and To Sender and Newsgroups.
Is Reply To Sender and Newsgroups available in Mozilla?

> So, a couple of more comments. I think having the Reply and Forward menus in
> the Reply and Forward menu buttons is redundant since the button is going to
> do that for you anyway.
I was copying the style of Mark menu, showing the default action.

> I think Reply All should be removed from the Reply button menu.

> The main menus hide the news menuitems when in mail.  I think the button
> menus should do the same.
Which is why I changed InitMessageMenu to use observers instead of menuitems.

> I think if possible, the button menus should be disabled when in mail or
> they should just be single buttons since there aren't any choices.
This could be a problem because Classic menubuttons are wider than normal.

Comment 36

[scottputterman]

You are right, what I was saying was inconsistent.  But there is redundancy in
the menu items as well. Reply is going to do the same as either Reply To Sender
or Reply To Newsgroup, so we might as well only have those two.  Forward is
going to either being Forward Inline or Forward As Attachment so we might as
well only have those two.

Jean-Francois, do you know about backend support for the different Reply All
options?

Comment 37

[Jean-Francois Ducarroz]

The backend already support the following reply modes:

Reply: reply to the sender from a pop/imap account or to the newsgroup from a
news account

ReplyAll: reply to all mail recipients and newsgroups

ReplyToGroup: reply to the newsgroup only

ReplyToSenderAndGroup: reply to the sender and the newsgroup

all you have to do from the UI is to set the parameter type to one of those
value when you call OpenComposeWindow().

Comment 38

[[e-mail]]

Attachment: Add Reply to Sender and Group to main and context menus

Comment 39

[Matthew T (active 1999-2002)]

Reply
  Reply to Sender Only                [use <menuitem ... default="true"/>]
  Reply to Newsgroup

Reply All
  Reply to Sender and All Recipients  [<menuitem ... default="true"/>]
  .Reply to All Recipients            [disabled until implemented]
  Reply to Sender and Newsgroup

Forward
  Forward                             [<menuitem ... default="true"/>]
  .Redirect                           [disabled until bug 12196 is fixed]
  Edit Message as New
-------------------------
  Forward In-line
  Forward Quoted
  Forward as Attachment

In e-mail, disable the newsgroup-related items -- do not hide them, as that would 
disturb users' familiarity with the contents of the menu, and that would slow 
them down. Similarly, do not disable the menu even when only one item is 
available, as that would slow users down more than it would speed them up.

Comment 40

[Jean-Francois Ducarroz]

few comments:
a)In the Reply menu, when reading a message from a newsgroup account, the
default item should be "Reply to Newsgroup" and not "Reply to Sender Only"

b) do you really need "Reply to All Recipients", for me it's the same than
"Reply All" or "Reply to Sender and All Recipients". This is becoming to
confusing for the user.

c)Forward Quoted has been removed from 6.0 because we have decided we will not
support anymore this kind of feature. How come is back?

d) Please do not disable newsgroups related items when reading message from a
email account. The user still need to be able to "Reply to Newsgroup" or "Reply
to Sender and Newsgroup" if the message has been posted to both a newsgroup and
the user email address.

 

Comment 41

[Ben Bucksch (:BenB)]

> a)In the Reply menu, when reading a message from a newsgroup account, the
> default item should be "Reply to Newsgroup" and not "Reply to Sender Only"

Am I the only one who find the 4.x buttons for Newsgroups completely confusing?
If I click "Reply All", I usually reply to one person only - the poster. If I
click just "Reply", I reply to a lot of people. I would expect the exact
opposite. But I think, this is offtopic to this bug and I shold bring this up
independantly in the newsgroup instead.

> b) do you really need "Reply to All Recipients", for me it's the same than
> "Reply All" or "Reply to Sender and All Recipients".

There is one important difference: mailinglists.
If I reply to a mailinglist*, I have to manually delete the sender from the
recipients list each time. This item gives exactly what I need.
There a quite a few mailinglists out there. I think, users will thank for that
command. Such an menuitem is not intrusive for newbies at all (although the
sense might not be clear).

* assuming the list doesn't mess with the headers by inserting a Reply-To to the
list, which has the drawback of disallowing replyies to the poster only

> d) Please do not disable newsgroups related items when reading message from a
> email account. The user still need to be able to "Reply to Newsgroup" or
>"Reply to Sender and Newsgroup" if the message has been posted to both a
> newsgroup and the user email address.

Yup.

Comment 42

[[e-mail]]

I'm confused. When I hit Reply to All I only get the sender, I don't get any of
the other recipients (no newsgroup was specified).
As I see it, the possible recipients are:
1) From: (or Reply-To:) only (default for mail) = Reply to Sender
2) Newsgroup: (or Followup-To:) only (default for news) = Reply to Group
3) To: and CC: only = Reply to All Recipients?
4) From: To: and CC: (default for mail?) = Reply to Sender and All Recipients
5) From: and Newsgroup: (default for news?) = Reply to Sender and Group
6) To: CC: and Newsgroup: = Reply to Group and All Recipients?
7) All of the above: = Reply to All? (default?)

Comment 43

[scottputterman]

A couple of comments.

I think Forward should just be:

Forward Inline
Forward As Attachment
---------------------
Edit Message As New
.Redirect (if implemented)

Please don't add these new '.' menu items until we get them working.  Please
also make the disabling work correctly before checking in.  I personally prefer
hiding the news menu items when in mail. I think our mail ui looks even more
cluttered than it already does if we leave them in. I don't think the average
user will be confused because I don't think the average user will be using news.
 If they end up getting disabled, as I said, please make sure that the disabling
works before checking in.

I don't have any problem with all of the different distinctions between the
reply all's but before adding them, please make sure they work.

Comment 44

[Matthew T (active 1999-2002)]

Two corrections to my previous suggestion:
(1) Change `In e-mail' to `When reading a message not posted to any newsgroups'.
    Obviously this confused some people.
(2) Remove `Reply to Sender and Newsgroup' from the `Reply All' menu (`Reply to
    Sender and All Recipients' should include newsgroups if there are any).

ducarroz: Please give the URL of the decision to never implement Forward Quoted. 
Thanks.

putterman: `Forward' is included as an item separate from the three particular 
modes in 4.x, as it represents the default as set in prefs -- Forward in default 
mode is Commandd+K, Forward Inline is Option+Command+K, Forward Quoted is
Shift+Command+K, and Forward as Attachment is Shift+Option+Command+K. But if we 
display the default mode using default="true" (i.e. in bold), then we might not 
need a separate item for it.

My reasoning for including the unimplemented items was to preserve muscle memory 
once the items are implemented -- but then I lost that argument in bug 53800, so 
I don't suppose I'll win it here either.

Comment 45

[scottputterman]

My main reason for not wanting to include unimplemented menu items is that I
remember when we did this at the very beginning and for any organization trying
to do an official release (previously Netscape 6, at some point Mozilla 1.0) it
is a pain to have to go and remove items that don't work. I know this because
I'm the one who had to do this for mail!  So, I'd prefer to just not add them
and make whoever implements the feature, put the UI in.

Comment 46

[jglick]

I agree with Scott.  I prefer hiding the news menu items when in mail. It makes 
the mail UI more cluttered. Average users already have no clue how to use the 
menu buttons. If they aren't needed, they shouldn't be there. I also agree that 
the average user doesn't use news, so having these items in the mail button 
menus but disabled is confusing. ("These items are never enabled, so why are 
they here?). I think having "Forward" in the "Forward" menu button is redundant. 
I don't think "Edit as New" belongs in the "Forward" menu since it really isn't 
a forward action. (It belongs in the "Message" menu but not grouped with Forward 
functions).  What the heck is "Redirect"?  I don't think average people will get 
that one.  We are overloading these menu buttons. They shouldn't have all the 
options in them, that is what the main menus are for. Keep them short and simple 
and only when necessary.  My 2cents.

I would like to see:

MAIL - Forward, and Next have button menus only.
Forward: "Forward" is name of button
Button menu has:  "Inline" and "As Attachment".  Default is behavior of button 
is what is set in prefs.

Next: "Next" is name of button
Button menu has: "Message", "Unread Message", "Flagged Message", "Unread 
Thread".  Default is next "Unread Thread".


NEWS - "Reply", "Reply All", "Forward", "Next" and "Mark" have menu buttons.
Reply: "Reply" is name of button.  Button menu has: "To Sender Only", and "To 
Newsgroup".  Default is "Reply to Newsgroup".

Reply All - "To Sender and All Recipients", "To Sender and Newsgroup" and "Reply 
to All Recipients". Default is "To Sender and Newsgroup".

Forward - Button menu has:  "Inline" and "As Attachment".  Default is behavior 
of button is what is set in prefs.

Next: Button menu has: "Message", "Unread Message", "Flagged Message", "Unread 
Thread".  Default is next "Unread Thread".

Mark: Button menu has: "As Read", "As Unread", "Thread as Read", "All Read" and 
"Flag". Default "As Read" or "As Unread" if already read.

Comment 47

[Phil Peterson]

I like Jennifer's summary, except that the default action of Next should be Next
Unread Message, not Next Unread Thread.

Comment 48

[jglick]

Oops. Yes, you're right.

Comment 49

[timeless]

testcase:
followup-to: m.p.m.frontend
news: n.p.m.ui, n.p.m.xpfe, n.p.m.mailnews
to: [e-mail]
cc: [e-mail]
from: [e-mail]
author: [e-mail]

I don't see any mention of reply to followup-to newsgroup vs reply to all news 
groups.  And since I got so much bugmail from this bug i figured it'd be fun to 
ask.

Comment 50

[Ben Bucksch (:BenB)]

> menu buttons. If they aren't needed, they shouldn't be there.

Agreed, especially since many users might never see a news post. [Let's hope
that this changes :) .]

*But* there are a lot of theoretically possible Reply actions:
We have the recipients groups
- Sender
- Email recipients
- Newsgroup(s) (Followup, if sat)
Each can be included or not. Makes 3^2=9 options for news, 2^2=4 for mail. (Both
including no presat recipients at all, which I sometimes use as a better forward.)

For mail, we should include at least Reply to Sender only ("Reply"), Reply to
Sender and Recipients ("Reply All") and Reply to Recipients only (for
mailinglists, as argued above). This means, we need a menubutton at least for
Reply All in mail.

I agree that there should be no unimplemented menu items. It is a pain for
distributors (debug menus, anyone?). We can comment out the source or create a
UI spec, if we want to save the decision we made.

timeless, if there is a followup-to sat, the newsgroups header should be ignored
completely. (IIRC. John Moreno can give better advise.)

> `Reply to Sender and All Recipients' should include newsgroups if there are
> any).

No, this is different. Maybe s/Recipients/Email Recipients/, if you want to make
the UI clearer.

> NEWS - "Reply", "Reply All", "Forward", "Next" and "Mark" have menu buttons.
> Reply: "Reply" is name of button.  Button menu has: "To Sender Only", and "To
> Newsgroup".  Default is "Reply to Newsgroup".
> Reply All - "To Sender and All Recipients", "To Sender and Newsgroup" and
> "Reply to All Recipients". Default is "To Sender and Newsgroup".

I disagree. (Jen,) please check out the thread on .mail-news I opened for that
discussion.

Comment 51

[Ben Bucksch (:BenB)]

> What the heck is "Redirect"?  I don't think average people will get that one.

Bug 12916. Very useful (even for average business users) and often-requested
feature.

Comment 52

[[e-mail]]

Attachment: XUL patch to convert next to a dual menubutton

Comment 53

[[e-mail]]

Attachment: XUL and JS to turn forward into a dual menubutton

Comment 54

[[e-mail]]

How does the following scheme for swapping buttons sound to you?
* The mail toolbar will have an attribute named server set by JS
* The buttons may have an attribute for each server
Example:
<button id="button-delete" class="server ..." news="hide".../>
<menubutton id="button-mark" class="server ..." hidden="true" news="show"...>
toolbar[server="news"] .server[news="hide"] { display: none; }
toolbar[server="news"] .server[hidden="true"][news="show"] { display: block; }
Or would I be better of hiding and showing each button manually in JS?


Ben Bucksch wrote:
>> What the heck is "Redirect"?  I don't think average people will get that one.
> Bug 12916. Very useful (even for average business users) and often-requested
> feature.
Couldn't you use Edit Message As New for this? Perhaps if you called it Resend
Message instead? All you need do is copy the reply address (or from address if
no reply address given) as the reply address of the new message. Drafts and
Templates should not have a from address as this should be set when the message
is actually sent but you can always delete the reply address.

Comment 55

[[e-mail] (gone - use [e-mail] instead)]

Adding patch keyword, and nominating for nsbeta1, since we have patches attached.

Comment 56

[scottputterman]

marking nsbeta1-. acceptance for nsbeta1 isn't necessary for contributions from
non-Netscape developers.  Neil, could you give a description of what the button
menus are going to look like with your patches for those who can't read XUL and
JS?  Jennifer, mpt, and others, when that's posted could you say whether you
agree with the changes?  Jean-Francois when consensus is reached on this, could
you review it?

Comment 57

[Blake Ross]

Please don't add new dump()s.

Comment 58

[Ben Bucksch (:BenB)]

> Couldn't you use Edit Message As New for [Redirect]?

Short answer: No. For a long answer, please ask in the other bug.

Comment 59

[[e-mail]]

Blake Ross wrote:
> Please don't add new dump()s.
Sorry, I just cut and pasted from MsgForwardMessage :-)

attach_id=22654 and attach_id=22656 convert the reply, forward and next buttons
into dual menubuttons. However a) reply all is moved onto the reply menubutton
b) the reply popup calls InitMessageMenu which it shouldn't.

attach_id=22866 is a starting point for converting the Reply All button.

attach_id=22975 converts the Next button only into a menubutton. The options
are: Next, Next Unread (default), Next Flagged, separator, Next Unread Thread.

attach_id=22979 converts the Forward button only into a menubutton. The options
are: Forward As Inline and Forward As Attachment. The default action is set by
the pref. However I forgot to localize them :-(

Comment 60

[[e-mail]]

So what's the consensus on the Reply button?
1) A button and a menubutton that a swapped by JS á la Delete and Mark
2) A dual menubutton that always opens even if only one option á la Back
3) A menu with a button so that the menu can be independently disabled?

Comment 61

[Akkana Peck]

I haven't looked at the patches yet, but one issue related to these is that in
the current build,  if I hover over "Reply", the tooltip is "Reply to Sender
Only", but if I click it, I get a window that's replying to the newsgroup. 
There should be a button that really does a Reply to Sender Only (that's the
most frequent type of reply I do in a newsgroup), but aside from that, the
tooltip lying about the function of the button is clearly a bug.  It doesn't
seem worth filing a separate bug on that since the fix for this bug will
probably change the UI anyway.

Comment 62

[[e-mail]]

Well I've got a vote from Gervase Markham asking for the 4.0 for Windows style.

Comment 63

[Michael T. Babcock]

It would be nice to bring over the MUTT functionality of "Reply to list" for
replying to mailing lists that don't munge reply-to headers.  This is
retrievable from the mailing list headers, and should only be presented if
appropriate (don't offer "reply to list" if replying to a message without the
appropriate mailing list header).

PS. I can't believe a bug opened in 1999 is still marked as "new".

Comment 64

[Akkana Peck]

IMO, Reply-to-list is one of the few things that mutt doesn't do as well as pine
(pine figures out the list from the headers, mutt requires that you predefine
all your lists in your .muttrc).  But either way would be better than nothing,
and that RFE is already filed as bug 45715.

Comment 65

[Michael T. Babcock]

My comments on replying to mailinst lists is described in bug 74347 which is a
dup of bug 45715.

Comment 66

[Garth Wallace]

12699 and 76449 should be removed from the "blocked" list. This itself isn't a 
GNKSA issue (which says nothing about dual menubuttons), providing separate 
commands for reply, followup, and posting is. That's covered by 95623--this 
blocks 95623, but anything that fixes 95623 would satisfy the relevant GNKSA 
requirement even if something other than dual menubuttons is used in the UI.

If anybody objects, speak now or forever hold your peace...

Comment 67

[[e-mail]]

Attachment: All new patch

This patch converts Reply, Forward and Next into dual menubuttons.
Reply is only a dual button when reading news; when reading mail it is normal.

Comment 68

[jglick]

Its this something we still want? Originally, we thought, 4.x parity, gotta have 
it, but after not having them all this time, I think I prefer the toolbar as it 
is now. Its simple and clean, performing the default actions. Additional actions 
are available in the menus. I think all the added dropdown arrows will clutter 
the toolbar, and the gain for most users is probably minimal.

Comment 69

[kmurray1115]

I'm not convinced we need this.

Comment 70

[Ben Bucksch (:BenB)]

I am very much convinced that we need this. If nothing else, it is a GNKSA
rquirement to clearly separate Reply by email and Followup to newsgroup (without
ccing per email), preferably with a standard wording (not "Reply All").

Also, this bug is a pre-requirement for bug 45715. That bug would help
mailing-list discussion *a lot*. See
<http://bugzilla.mozilla.org/show_bug.cgi?id=45715#c9>.

Comment 71

[kmurray1115]

Since the patch is ready, I think it's fine to get it in and see if it's
beneficial. However, if it introduces more complexity to the buttons in mail,
(which if I understood the previous comments correctly, it shouldn't) then we'll
take a look at it further.

Comment 72

[Olga]

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

Comment 73

[Jo Hermans]

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

Comment 74

[Don Erway]

So, a year has gone by, and still not released in the main?

Having a button and drop down menu for "get messages" seems of questionable
value, (since what is wrong with always doing "get all" in email").

But having a 1 click way to forward inline or forward as attachment is really
needed.

Comment 75

[(not reading, please use [e-mail] instead)]

talking to neil, he intends to complete this (maybe during 1.4?)

neil mentioned that a theme owner could hide it (using css), so I'm ok with him
doing this.

if other distributors (like Netscape) aren't intereted, they can easily disable
it in their versions of modern / classic.

Comment 76

[(not reading, please use [e-mail] instead)]

s/intereted/interested

Comment 77

[[e-mail]]

Attachment: Updated for bit death

FYI bit death is like bitrot but more severe :-)

Comment 78

[[e-mail]]

Comment on attachment 114907 [details] [diff] [review]
Updated for bit death

All comments appreciated.

P.S. No screenshot yet :-(

Comment 79

[Ben Bucksch (:BenB)]

wow, that's a lot of changes for adding 2 items :(

s/Group/Newsgroup/ (in code and UI)

See above for why I think that Reply to Newsgroup should be on the Reply All
button, not Reply button.

Comment 80

[Vidar Haarr (not reading bugmail)]

Re: comment 74.
> But having a 1 click way to forward inline or
> forward as attachment is really needed.

No it isn't. Always forward inline.
And if you want to forward as attachment, open the compose window, and drag the
messages that you want to attach from the mail-window into the header-part of
the compose window.

There, the messages are attached.

Comment 81

[Julian Hall]

>Always forward inline.

Why?  Forward inline loses information from the headers of the message you are
sending, and can also damage formatting in some unusual cases that aren't
handled correctly by the editor.  Also presenting the content of the forwarded
message in the editor tempts users to edit that content, which really should not
be done unless the content is quoted[1].  Forward as attachment is generally the
better option, so I have it set as my default, and recommend it as default for
everyone else too.

>And if you want to forward as attachment, open the compose window, and drag
>the messages that you want to attach from the mail-window into the header-part
>of the compose window.
>
>There, the messages are attached.

That operation is more difficult than most users are willing to perform.  Drag &
drop of items from a list is non-intuitive and most people will not realise they
can do it.  Also, what about people forwarding a message from the message view
window, rather than the mailbox window...?  It could be difficult for them to go
back and find the message they need.

--
[1]:  I'm sure there used to be a 'forward inline quoted' option, but it seems
to have disappeared... what happened to that?  I note it's mentioned in Comment
#39, so it almost certainly isn't my imagination.

Comment 82

[[e-mail]]

Attachment: Updated again

As requested by stephend.

Comment 83

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Reply menu - screenshot

Comment 84

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Reply all - screenshot

Comment 85

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Forward button menu - screenshot

Comment 86

[Stephen Donner [:stephend] Not actively reading bugmail]

I'm not sure I've covered everything, but here's a preliminary UI gander:

* Modern theme - drop arrow widget is too close to the right arrow graphic
(theme bug, outside scope of this bug)
* All themes - The issue(s) Akkana pointed out in comment 61 still apply - IE,
when in a newsgroup, the tooltip for the Reply All button states 'Reply to
sender and all recipients', when it should read 'Reply to sender and newsgroup'.
* All themes - 'group' by itself in the UI should be renamed into newsgroup for
consistency's sake.
* All themes - Reply to Sender and Group (from the Reply All button) is in bold,
as is Reply to Newsgroup (from the Reply button).  Both Forward and Next's
default actions of Inline and Unread Message respectively, aren't bolded. 
Should they be?

Additional feedback/testing welcome.
 

Comment 87

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Aaaaahhhh, finally!!! Thanks for doing this!

Comment 88

[[e-mail]]

Attachment: Fixed tooltip

Also fixed the default menuitems for all four menubuttons.

Comment 89

[David :Bienvenu]

+  if (event && event.shiftKey)
+    ComposeMessage(msgComposeType.ReplyToSenderAndGroup,
msgComposeFormat.OppositeOfDefault, loadedFolder, messageArray);
+  else
+    ComposeMessage(msgComposeType.ReplyToSenderAndGroup,
msgComposeFormat.Default, loadedFolder, messageArray);
+}

you'll generate less js with a '?' operator here and just a single call to
ComposeMessage. Other than that, it looks OK, though it is an awful lot of
changes. It does more than just add the newsgroup stuff, however.

Comment 90

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Patch which addresses David's review comment.

This patch incorporates a few changes:

* Changed declarations of 'replyall' usages to be interCaps, eg. var replyAll
(further changes coming after this lands to change the IDs of the buttons, keys
and cmds)
* Whitespace cleanup of if() style to be if ()
* Cleaned up various comments through mailWindowOverlay.js
* Changed 'group' into 'newsgroup'

Comment 91

[Stephen Donner [:stephend] Not actively reading bugmail]

Comment on attachment 138197 [details] [diff] [review]
Patch which addresses David's review comment.

Unfortunately I won't have a tree in a few days, and I've tested this quite
well on Windows 2000.  David, can you r/sr this when you get a chance?	Thanks.

Comment 92

[Christian Eyrich]

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

Comment 93

[Stephen Donner [:stephend] Not actively reading bugmail]

David/Scott, is this something we want for Seamonkey?

Comment 94

[Jason House]

I see what appears to be a lot of past activity, plenty of attachments and even
patches to do this feature... and somehow it all stopped.  When will this likely
make its way into mozilla?  The screen shots look great to me :)

Comment 95

[Scott MacGregor]

Comment on attachment 138197 [details] [diff] [review]
Patch which addresses David's review comment.

I'm not interested in this for tb. someone else may be for the suite.

Comment 96

[[e-mail]]

Comment on attachment 138197 [details] [diff] [review]
Patch which addresses David's review comment.

Note: I'm not sure that the patch was updated correctly, you may prefer to review the previous patch.

Comment 97

[ncgqprophet]

Any chance this bug can be fixed in Thunderbird as well?
It's extremely annoying to have to keep changing this setting in the options...

Comment 98

[Karsten Düsterloh]

Comment on attachment 138197 [details] [diff] [review]
Patch which addresses David's review comment.

Most of the code changes still apply, some with rather large offsets; I just had to fix some changed context lines to make it apply. Looks good, all in all, just some nits.

>Index: resources/content/commandglue.js
>===================================================================

These changes are already there (and ./patch does apply them wrong anyway).

>Index: resources/content/mail3PaneWindowCommands.js
>===================================================================

No tabs, please, just blanks for indentation.

>Index: resources/content/mailWindowOverlay.js
>===================================================================
>@@ -62,9 +62,9 @@
>      value > 1 in his prefs.js or user.js, but that the value will not
>      change during runtime other than through the MsgBody*() functions below.*/
> 
>-// Disable the new account menu item if the account preference is locked.
>+// Disable the File | New | Account... menu item if the account preference is locked.
> // Two other affected areas are the account central and the account manager
>-// dialog.
>+// dialogs.

Either adhere to the 80 column in both cases or (better) move the "dialogs." to the end of the preceding line.

> function viewRefreshCustomMailViews(aCurrentViewValue)
(etc.)

Should be gone with bug 349991 anyway. ;-)

>+  // Disable the Move menu if we can't delete msgs from the folder.

I think there's space enough to write "messages". ;-)

>+  ComposeMessage(msgComposeType.ReplyToSender, (event && event.shiftKey) ? msgComposeFormat.OppositeOfDefault : msgComposeFormat.Default, loadedFolder, messageArray);

This is already in.

>Index: resources/content/mailWindowOverlay.xul
>===================================================================
>+  Neil Rashbrook <[e-mail]>

Mmh, that'll probably change, no? ;-)

>+    <menuitem id="replySenderAndNewsgroupMainMenu" label="&replyToSenderAndNewsgroupCmd.label;" 
>+      accesskey="&replyToSenderAndNewsgroupCmd.accesskey;"
>+      key="key_replyall"
>+      observes="cmd_replySenderAndGroup"/>
>+    <menuitem id="replyAllRecipientsMainMenu" label="&replyToAllRecipientsCmd.label;" 
>+      accesskey="&replyToAllRecipientsCmd.accesskey;"
>+      observes="cmd_replyAllRecipients"/>

We use 'command' here instead of a mere 'observes' these days.

>Index: resources/content/messageWindow.js
>===================================================================
>+			case "cmd_replySenderAndGroup":
>+			case "cmd_replyAllRecipients":
...
>+			case "cmd_replySenderAndGroup":
>+				MsgReplyToSenderAndGroup(null);
>+				break;
>+			case "cmd_replyAllRecipients":
>+				MsgReplyToAllRecipients(null);
>+				break;

Again, no tabs, please.


r=me with that.

Sorry for the really inexcusable overly long delay. :((

Comment 99

[Karsten Düsterloh]

Comment on attachment 138197 [details] [diff] [review]
Patch which addresses David's review comment.

>Index: resources/content/commandglue.js
>===================================================================
>+  ComposeMessage(msgComposeType.ReplyToAll, (event && event.shiftKey) ? msgComposeFormat.OppositeOfDefault : msgComposeFormat.Default, loadedFolder, messageArray);

JFTR: this has to be "msgComposeType.ReplyAll".
(Already fixed on trunk.)

Comment 100

[Jens Müller (:tessarakt)]

Sorry, bug 508250 might be a dupe ...

Comment 101

[Thomas D. (:thomas8)]

No, bug 508250 can't be a dupe of this one as it is posted against Thunderbird, whereas this bug is against Seamonkey.

Comment 102

[Jens Hatlak (:InvisibleSmiley)]

Karsten (or Neil), is this not fixed?

Comment 103

[[e-mail]]

(In reply to comment #102)
> Karsten (or Neil), is this not fixed?
Yes, I checked it in on the 16th of November 2006...

Comment 104

[Ben Bucksch (:BenB)]

See bug 498448 for the options offered in the buttons.