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

RESOLVED FIXED in seamonkey2.0b2

Status

SeaMonkey
MailNews: Message Display
RESOLVED FIXED
18 years ago
8 years ago

People

(Reporter: (not reading, please use seth@sspitzer.org instead), Assigned: Philip Chee)

Tracking

(Blocks: 1 bug)

Trunk
seamonkey2.0b2
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 4 obsolete attachments)

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.

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M15

Comment 1

18 years ago
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)

Comment 2

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

Comment 3

17 years ago
perhaps for an issues meeting?

Updated

17 years ago
Depends on: 33079

Updated

17 years ago
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)

Comment 5

17 years ago
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

Comment 6

17 years ago
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.

Comment 10

17 years ago
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?

Comment 12

17 years ago
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.

Comment 13

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

Comment 14

17 years ago
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.

Comment 15

17 years ago
Marking M20.
Target Milestone: M16 → M20

Updated

17 years ago
No longer depends on: 33079

Updated

17 years ago
Hardware: Macintosh → All

Comment 16

17 years ago
Created attachment 20412 [details] [diff] [review]
Diff to add a menubutton for New Msg

Comment 17

17 years ago
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.

Comment 18

17 years ago
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.

Comment 19

17 years ago
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.

Comment 20

16 years ago
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

Comment 22

16 years ago
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.

Updated

16 years ago
QA Contact: nbaca → olgam

Comment 23

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

Comment 24

16 years ago
> 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.

Comment 25

16 years ago
It is too cumbersome to change that setting to compose one email a different way.
Blocks: 152942

Comment 26

15 years ago
Created attachment 88557 [details] [diff] [review]
Updated patch for pulldown menu for New Msg Button.

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+

Updated

15 years ago
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?

Comment 30

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

Comment 31

14 years ago
*** 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

Updated

12 years ago
Assignee: sspitzer → mail
Priority: P4 → --
QA Contact: olgam → search

Comment 34

8 years ago
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

Comment 35

8 years ago
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

Comment 36

8 years ago
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

Comment 38

8 years ago
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

Comment 39

8 years ago
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

Comment 41

8 years ago
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

Comment 42

8 years ago
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

Updated

8 years ago
Attachment #88557 - Flags: review?(mnyromyr)

Comment 44

8 years ago
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.

Updated

8 years ago
Attachment #88557 - Flags: review?(mnyromyr) → review-

Comment 45

8 years ago
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:-)
(Assignee)

Comment 46

8 years ago
Taking bug.
Assignee: nobody → philip.chee
Status: NEW → ASSIGNED

Comment 47

8 years ago
Note that Lightning already changes that button to a menubutton, I hope that won't be broken by a patch for this.
(Assignee)

Updated

8 years ago
Depends on: 506461
(Assignee)

Comment 48

8 years ago
Created attachment 391045 [details] [diff] [review]
Patch v2.0 Updated to trunk. Fixed Nits.

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

Comment 49

8 years ago
> +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.

Updated

8 years ago
Attachment #391045 - Flags: review?(mnyromyr) → review-

Comment 50

8 years ago
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.
(Assignee)

Comment 51

8 years ago
Created attachment 391846 [details] [diff] [review]
Patch v2.1 Nits fixed.

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

8 years ago
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+
(Assignee)

Updated

8 years ago
Blocks: 507871
(Assignee)

Comment 54

8 years ago
Created attachment 392128 [details] [diff] [review]
Patch v2.2 Final Nits fixed
[Checkin: Comment 55]

>(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+
(Assignee)

Updated

8 years ago
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
(Assignee)

Updated

8 years ago
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
Last Resolved: 8 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.0b2

Comment 56

8 years ago
Is there a Thunderbird equivalent?
You need to log in before you can comment on or make changes to this bug.