Closed Bug 16908 Opened 25 years ago Closed 15 years ago

[FEATURE]UI: "New Msg" button needs a sub-button (or click and hold), so I can force html or plain text compose

Categories

(SeaMonkey :: MailNews: Message Display, defect)

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
seamonkey2.0b2

People

(Reporter: sspitzer, Assigned: philip.chee)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 4 obsolete files)

Patch v2.2 Final Nits fixed [Checkin: Comment 55]
6.82 KB, patch
philip.chee
: review+
philip.chee
: superreview+
Details | Diff | Splinter Review 
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.
Status: NEW → ASSIGNED
Target Milestone: M15
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?
Depends on: 33079
QA Contact: lchiang → nbaca
Summary: [FEATURE] "New Msg" button needs a sub-button (or click and hold), so I can force html or plain text compose → [FEATURE]UI: "New Msg" button needs a sub-button (or click and hold), so I can force html or plain text compose
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.
Priority: P3 → P4
move to M16.  Not M15 stoppers
Target Milestone: M15 → M16
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.
Target Milestone: M16 → M20
No longer depends on: 33079
Hardware: Macintosh → All
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
Assignee: ducarroz → varada
Status: ASSIGNED → NEW
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.
QA Contact: nbaca → olgam
*** 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.
Attachment #20412 - Attachment is obsolete: true
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?
Attachment #88557 - Flags: needs-work+
Blocks: 154188
taking all of varada's bugs.
Assignee: varada → sspitzer
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?
*** 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.
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Priority: P4 → --
QA Contact: olgam → search
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
Status: NEW → UNCONFIRMED
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.
Status: UNCONFIRMED → 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
Status: NEW → UNCONFIRMED
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.
Status: UNCONFIRMED → 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
Status: NEW → UNCONFIRMED
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
Assignee: mail → nobody
QA Contact: search → message-display
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.
Status: UNCONFIRMED → NEW
Attachment #88557 - Flags: review?(mnyromyr)
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.
Attachment #88557 - Flags: review?(mnyromyr) → review-
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.
Assignee: nobody → philip.chee
Status: NEW → ASSIGNED
Note that Lightning already changes that button to a menubutton, I hope that won't be broken by a patch for this.
Depends on: 506461
Updated patch to trunk. Plus ported the relevant bits from Thunderbird Bug 416666 (Clean up Thunderbird's global scope a bit).
Attachment #88557 - Attachment is obsolete: true
Attachment #391045 - Flags: review?(mnyromyr)
> +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.
Attachment #391045 - Flags: review?(mnyromyr) → review-
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.
Attached patch Patch v2.1 Nits fixed. (obsolete) — — Splinter Review 
>>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.
Attachment #391045 - Attachment is obsolete: true
Attachment #391846 - Flags: superreview?(neil)
Attachment #391846 - Flags: review?(mnyromyr)
Comment on attachment 391846 [details] [diff] [review]
Patch v2.1 Nits fixed.

Cool. :)
Attachment #391846 - Flags: review?(mnyromyr) → review+
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.)
Attachment #391846 - Flags: superreview?(neil) → superreview+
Blocks: 507871
>(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
Attachment #391846 - Attachment is obsolete: true
Attachment #392128 - Flags: superreview+
Attachment #392128 - Flags: review+
Attachment #392128 - Attachment description: Patch v2.2 Final Nits fixed. r=mnyromyr sr=neil → [for checkin] Patch v2.2 Final Nits fixed. r=mnyromyr sr=neil
Keywords: checkin-needed
Comment on attachment 392128 [details] [diff] [review]
Patch v2.2 Final Nits fixed
[Checkin: Comment 55]


http://hg.mozilla.org/comm-central/rev/a781976a9815
Attachment #392128 - Attachment description: [for checkin] Patch v2.2 Final Nits fixed. r=mnyromyr sr=neil → Patch v2.2 Final Nits fixed [Checkin: Comment 55]
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.0b2
Is there a Thunderbird equivalent?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: