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.

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.

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

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

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.

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

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

moving to future milestone.

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

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

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

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

(otherwise I'd yell out loud.)

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

change b3mail to nsbeta3.

Mass accepting.

Let me know if you need my help...

ducarroz@netscape.com 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?

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.

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)

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

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

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

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.

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

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.

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.

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

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. neil@parkwaycc.co.uk: thanks for adopting this bug. i'll gladly r= this work when it's ready. reassigning to neil@parkwaycc.co.uk if you need someone to checkin, i can do that too.

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.

In reply to timeless@mac.com, 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 mpt@mailandnews.com, 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?

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?

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.

putterman@netscape.com 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.

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?

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

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.

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.

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

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

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.

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.

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.

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.

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

Oops. Yes, you're right.

testcase: followup-to: m.p.m.frontend news: n.p.m.ui, n.p.m.xpfe, n.p.m.mailnews to: confusion-gateway@mozilla.org cc: confusion-ui@netscape.com from: self@self.com author: author@here.tv 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.

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

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

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.

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

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?

Please don't add new dump()s.

> Couldn't you use Edit Message As New for [Redirect]? Short answer: No. For a long answer, please ask in the other bug.

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

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?

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.

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

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

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.

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

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

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.

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.

I'm not convinced we need this.

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

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.

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

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

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.

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.

s/intereted/interested

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

Comment on attachment 114907 [details] [diff] [review] Updated for bit death All comments appreciated. P.S. No screenshot yet :-(

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.

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.

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

As requested by stephend.

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.

Aaaaahhhh, finally!!! Thanks for doing this!

Also fixed the default menuitems for all four menubuttons.

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

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

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

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

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

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 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 <neil@parkwaycc.co.uk> 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 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.)

Sorry, bug 508250 might be a dupe ...

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

Karsten (or Neil), is this not fixed?

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

See bug 498448 for the options offered in the buttons.