in 4.x, on linux and windows, "New Msg" would pop up a sub menu if I clicked and held the button. the sub-menu had two items: "in Plain Text" and "in HTML" this would allow me to force what style of compose I want. talked to hangas about this, and he said that there is not going to be "click and hold" button, but that hyatt has new button, with a sliver or something., that we should be using.

I'm not sure about this. 4.x/Windows doesn't have that extra menu, and if we were going to add one for mozilla, I might rather add a list of identities. We did have the modifier key which reversed your compose-html preference (e.g. if your compose-html preference is TRUE and you press Control-NewMessage, you get a plain text compose window)

Hmm. No comments in here. Does anyone want to debate this before I resolve the bug wontfix?

perhaps for an issues meeting?

we can do this now! ben and hyatt have created the exact widget we need for this. (I think it's <menulist>, but I'll go check)

Syncing with marketing priorities. These are moving to P4 to connote "Cut here first". If you disagree with this priority, please let me know.

move to M16. Not M15 stoppers

er, menulist is not the right widget, but I think the right one for this exists.

menubutton is what you're looking for...

ah, like the back forward button in the browser. yes, that is what I need.

are we going to do this on reply and reply-all as well? If so, are we going to have this for each of the choices for these buttons?

looking at the spec, it doesn't look like any of these "menu buttons" are mentioned. but I'd like to see them as 4.x had them. jglick, comments?

Sorry we didn't get around to fully spec'em yet, but for usability reasons we have slightly added to the behavior compared to 4.x by having a seperate XUL area to the right of the button that expands the additional menu/options. By providing a larger target area as well as more discoverable behavior we hope to remedy the usability problems that plagued the 4.x implementation. As Ben pointed out the proper widget to use is menu button.

I wanted to add that this design replaces the time-out based behavior for popping up menus from toolbar buttons in 4.x.

I don't think we need to do this for M16. It's not really much of a feature since we already have code that makes hitting shift-button click do what Seth wants. So it's just a matter of adding xul which shouldn't be that hard. I suggest that we can move this out.

Marking M20.

This diff 1) Turns the New Msg button into a menubutton with two menuitems (HTML and Plain Text) --> File mailWindowOverlay.xul 2) Adds the two needed js functions --> File mailWindowOverlay.js 3) Adds the two dtd entities --> File messenger.dtd 4) Turns the css for the button into a css for the menubutton (copied from the print menubutton) for the modern skin. 5) Turns the css for the button into a css for the menubutton (copied from the print menubutton) for the classic skin. N.B : I'm not a skin master, so the css changes need to be reviewed BADLY, mainly for the classic skin. (Don't have cvs access to make a real patch, sorry) Tested successfully by walk84@usa.net and myself (hidday@geocities.com). Please give your input, thank you, Fabian.

Suggest wontfix. If you make it a feature of the `New' button, then it should really be a feature of the `Reply' and `Reply All' buttons as well. But they're already going to have pulldown menus for reply to sender/newsgroup/both (bug 17796). I can't believe that anyone is going to switch composition formats often enough that they need visible UI in the toolbar to do it. A modifier key (Shift+click) would be quite enough.

Thanx for saying this 6 monthes later. For your information shift-click already switches between default and opposite of default (in the account pref), but (almost) nobody knows of this. Quite a few people asked for this as well as for the reply/reply all and for the forward and for the next button (bug 59264). Need Info : what is the difference between a pull-down menu and a menubutton? N.B : I didn't ask for this, mail folks did, not like I use extremely often. Fabian.

I agree that nobody knows the modifier key of "New Msg". It is really news to me. I just know it today when I come across this bug!! But I do hope we have a drop down for New Msg to chooce identity like Outlook Express does. Refer to the second comment (from Phil Peterson).

reassign to varada

The "Shift-Click->New Message" trick works well, and it's exactly what I was looking for when searching for related bugs. Can't this just be made a pref for now? I see the options for specifying the format *after* the message is sent, but what if I want to send in plaintext to start with... by default? There is nowhere in the prefs to specify your default message editing format... Add a simple pulldown to choose under Preferences|Mail&Newsgroups|Message Composition ? Or maybe under account settings, one setting per each account. Maybe I want HTML for email at work, plaintext for email at home, and plaintext for news posts.

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

> Or maybe under account settings, one setting per each account. Maybe I want HTML > for email at work, plaintext for email at home, and plaintext for news posts. In Edit > Mail & Newsgroups Account Settings, there's a per account 'Compose Messages in HTML Format' checkbox that fit the bill.

It is too cumbersome to change that setting to compose one email a different way.

Updated patch for pulldown menu for New Msg Button.

Comment on attachment 88557 [details] [diff] [review] Updated patch for pulldown menu for New Msg Button. Instead of having two JS functions (MsgNewMessage & NewMessage) to create a new message window, you should consolidate them into one. Also, did you check with jeniffer if it was ok to do this UI change? and what about reply and forward button, do we want also to be able to select the mode?

taking all of varada's bugs.

I think to have an optional drop-down menu for the compose, reply, and forward buttons (like for the forward/back buttons) to choose between plaintext and html would be user-friendly, since hardly a user is aware of the shift-click method. It would not clutter the UI but give a hint that this feature exists. It will *not* clash with the identities list, since this is taken care of through the "from" menu in the compose window, no? There is a potential clash of conflict as some users might want the forward button to dynamically offer the option to choose between inline and attachment. So if *someone* (I am not mentioning names here) would come up with a patch, would it have a chance to get checked in from th UI design POV?

http://bugzilla.mozilla.org/show_bug.cgi?id=167588 is very similar

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

Suggest WONTFIX. I don't see the problem. Always use plain text :) No, seriously, I agree with mpt in comment 18.

There already is an RFE (bug 140800) to dynamically switch between plaintext/HTML compose when you're in the message compose window. That's the way Outlook Express does it, and I personally find that very helpful. It would also remove the need to add extra UI to the Compose/Reply/Forward buttons, which are overloaded enough. I suggest WONTFIXing this bug, and focussing on bug 140800.

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

(In reply to comment #36) > If you can confirm that this report still applies to current SeaMonkey 2.x > nightly builds, please set it back to the NEW state along with a comment on how > you reproduced it on what Build ID, or if it's an enhancement request, why it's Still present in: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090614 Shredder/3.0b3pre Marking NEW.

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

(In reply to comment #39) > If you can confirm that this report still applies to current SeaMonkey 2.x > nightly builds, please set it back to the NEW state along with a comment on how > you reproduced it on what Build ID, or if it's an enhancement request, why it's > still worth implementing and in what way. Still present in: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090614 Shredder/3.0b3pre Marking NEW.

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

Still present in: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090614 Shredder/3.0b3pre Marking NEW. Again.

Comment on attachment 88557 [details] [diff] [review] Updated patch for pulldown menu for New Msg Button. patches without a review request are useless, directing to SeaMonkey MailNews owner.

Comment on attachment 88557 [details] [diff] [review] Updated patch for pulldown menu for New Msg Button. First of all, this patch doesn't apply anymore. MailNews may be a slow river, but not _that_ ropy... ;-) Some structural nits, nonetheless: >Index: content/mailWindowOverlay.js >=================================================================== >+function NewMessage(format) The new functionality should be integrated into the old MsgNewMessage function. Furthermore, for extended bonus points, the menuitem of the current default setting should be marked with default=true. Philip, maybe you're interested? O:-)

Taking bug.

Note that Lightning already changes that button to a menubutton, I hope that won't be broken by a patch for this.

Updated patch to trunk. Plus ported the relevant bits from Thunderbird Bug 416666 (Clean up Thunderbird's global scope a bit).

> +function ComposeMsgByType(aCompType, aEvent) { Thunderbird uses camelcase i.e. composeMsgByType() but since this is an internal helper function I understand that the MailNews peers don't care about Thunderbird compatibility here.

Comment on attachment 391045 [details] [diff] [review] Patch v2.0 Updated to trunk. Fixed Nits. No functional problems, just some stylish nitpicking... >diff --git a/suite/locales/en-US/chrome/mailnews/messenger.dtd b/suite/locales/en-US/chrome/mailnews/messenger.dtd >+<!ENTITY newPlainTextMessageCmd.label "Compose in PlainText"> All other places in MailNews I found are using the spelling "Plain Text", so this menuitem should do as well. >diff --git a/suite/mailnews/mailWindowOverlay.js b/suite/mailnews/mailWindowOverlay.js >+/** >+ * Calls the ComposeMessage function with the desired type, and proper default Are you sure about the comma? >+function ComposeMsgByType(aCompType, aEvent) { Please use curly-braces-on-their-own-line style. >+ var format = (aEvent && aEvent.shiftKey) ? >+ msgComposeFormat.OppositeOfDefault : >+ msgComposeFormat.Default; I'd say it's permissible to ignore the 80 column limit here. Or drag OppositeOfDefault behind the ? and align the : under the ?, with Default following. > function MsgNewMessage(event) Should be aEvent since you're rewriting the function anyway. >+ var mode = event ? event.target.getAttribute("mode") : null; var mode = event && event.target.getAttribute("mode"); > function MsgReplySender(event) > function MsgReplyGroup(event) > function MsgReplyToAllRecipients(event) > function MsgReplyToSenderAndGroup(event) Should be aEvent since you're rewriting these functions anyway.

>>diff --git a/suite/locales/en-US/chrome/mailnews/messenger.dtd b/suite/locales/en-US/chrome/mailnews/messenger.dtd >>+<!ENTITY newPlainTextMessageCmd.label "Compose in PlainText"> > > All other places in MailNews I found are using the spelling "Plain Text", so > this menuitem should do as well. Fixed. >>diff --git a/suite/mailnews/mailWindowOverlay.js b/suite/mailnews/mailWindowOverlay.js >>+/** >>+ * Calls the ComposeMessage function with the desired type, and proper default > > Are you sure about the comma? Removed. >>+function ComposeMsgByType(aCompType, aEvent) { > > Please use curly-braces-on-their-own-line style. Fixed. >>+ var format = (aEvent && aEvent.shiftKey) ? >>+ msgComposeFormat.OppositeOfDefault : >>+ msgComposeFormat.Default; > > I'd say it's permissible to ignore the 80 column limit here. > Or drag OppositeOfDefault behind the ? and align the : under the ?, with > Default following. Since there are some really long lines already in the file I've put this all on one line. >> function MsgNewMessage(event) > > Should be aEvent since you're rewriting the function anyway. Fixed. >>+ var mode = event ? event.target.getAttribute("mode") : null; > > var mode = event && event.target.getAttribute("mode"); Fixed. >> function MsgReplySender(event) >> function MsgReplyGroup(event) >> function MsgReplyToAllRecipients(event) >> function MsgReplyToSenderAndGroup(event) > > Should be aEvent since you're rewriting these functions anyway. Fixed.

Comment on attachment 391846 [details] [diff] [review] Patch v2.1 Nits fixed. Cool. :)

Comment on attachment 391846 [details] [diff] [review] Patch v2.1 Nits fixed. >+ Nit: line isn't really empty ;-) >+function MsgNewMessage(aEvent) >+{ >+ var mode = aEvent && aEvent.target.getAttribute("mode"); >+ if (mode) >+ ComposeMessage(msgComposeType.New, >+ msgComposeFormat[mode], >+ GetFirstSelectedMsgFolder(), >+ GetSelectedMessages()); >+ else >+ ComposeMsgByType(msgComposeType.New, aEvent); >+} I think this is confusing. Rather than splitting the work between ComposeMessage and ComposeMsgByType I would just compute the appropriate format in all possible cases and call ComposeMessge directly. >+ <menuitem label="&newHTMLMessageCmd.label;" >+ accesskey="&newHTMLMessageCmd.accesskey;" >+ mode="HTML"/> >+ <menuitem label="&newPlainTextMessageCmd.label;" >+ accesskey="&newPlainTextMessageCmd.accesskey;" >+ mode="PlainText"/> Nit: Followup needed to "highlight" the default action. (All the other menubuttons do; Get Messages seems to be the the oddity, but then it applies to the current folder while the menu actually lists accounts.)

>(From update of attachment 391846 [details] [diff] [review]) >>+ > Nit: line isn't really empty ;-) Fixed. >>+function MsgNewMessage(aEvent) >>+{ >>+ var mode = aEvent && aEvent.target.getAttribute("mode"); >>+ if (mode) >>+ ComposeMessage(msgComposeType.New, >>+ msgComposeFormat[mode], >>+ GetFirstSelectedMsgFolder(), >>+ GetSelectedMessages()); >>+ else >>+ ComposeMsgByType(msgComposeType.New, aEvent); >>+} > I think this is confusing. Rather than splitting the work between > ComposeMessage and ComposeMsgByType I would just compute the appropriate format > in all possible cases and call ComposeMessge directly. Fixed. >>+ <menuitem label="&newHTMLMessageCmd.label;" >>+ accesskey="&newHTMLMessageCmd.accesskey;" >>+ mode="HTML"/> >>+ <menuitem label="&newPlainTextMessageCmd.label;" >>+ accesskey="&newPlainTextMessageCmd.accesskey;" >>+ mode="PlainText"/> > Nit: Followup needed to "highlight" the default action. (All the other > menubuttons do; Get Messages seems to be the the oddity, but then it applies to > the current folder while the menu actually lists accounts.) Filed Bug 507871

Comment on attachment 392128 [details] [diff] [review] Patch v2.2 Final Nits fixed [Checkin: Comment 55] http://hg.mozilla.org/comm-central/rev/a781976a9815

Is there a Thunderbird equivalent?