837205 - Put more space or separator between "delete" and the print preview menu items in the context menu (right-click) or move "delete" to somewhere else.

Status: RESOLVED FIXED

(Thunderbird :: Message Reader UI, enhancement)

Description

[ISHIKAWA, Chiaki]

This is a usability issue.

I am not challenged, but my mouse occasionally behaves funnily,
and just when I thought I pushed "Print Preview" menu, it
may push the delete message menu item IMMEDIATELY below it.

I think having a menu for destruction of an object right next to
a menu item to look at a representation of it is a violation of
UI design to avoid user mistakes.
(Would you put an all reset button right next to a button to navigate a screen?)  

Actually, I hope that the menu is re-designed completely, but
since people are accustomed to the current order for a while now,
I would suggest that a separator (like a horizontal line)
is inserted between the two menu items, but
I would go for inserting a dummy dead (always disabled) menu item simply
to move the two menu items further apart.

I believe there are users who are physically challenged and
don't bother to use print preview button because of the described danger of hitting delete button.

(Once that happens, we either have to push Control-Z, which requires
two finger operation, and even with accessibility keyboard option, may be burdensome, 
or we may go to EDIT->UNDO which is again a large mouse movement, a bother for
physically challenged peopel.)

If someone can suggest which part of the code needs fixing, I can possibly produce a patch.

TIA

Comment 1

[ISHIKAWA, Chiaki]

Follow-up: my mouse and I(my eyes!) are probably challenged.

"Delete Message" is below "Print" menu, and "Print Preview" is above "Print" in context menu (!).

Yes, while I am experimenting with print and print preview, sometimes I got distracted and hit delete when a phone rings or something or pointing devices behave unreliably or my hand does :-( 

But my point still stands.

There ought to be separator (and as I mentioned, preferably a large space between
Print and Delete Message).

TIA

Comment 2

[rsx11m]

It's weird anyway to see "Delete" in the same block where "Save As" and the said printing options are located. Thus, adding a separator might be advised for that reason alone already. I'm wondering if "Delete" should be relocated into the "Move/Copy To" block above, but then the jittery-mouse issue would apply to those items (though of less significance as you expect the folder submenu to open for either Move or Copy functions rather than releasing the mouse at that point).

Comment 3

[ISHIKAWA, Chiaki]

(In reply to rsx11m from comment #2)
> It's weird anyway to see "Delete" in the same block where "Save As" and the
> said printing options are located.

Yes, I noticed this several years ago, and I may have voiced it 
in one of the netscape/mozilla newsgroups.

> Thus, adding a separator might be advised
> for that reason alone already. 

It is great to see someone took notice.

> I'm wondering if "Delete" should be relocated
> into the "Move/Copy To" block above, 

Yes, I would go for a re-design of the menu structure, but
if it is too much bother for now, separating the entries wide apart
is a good move.

Anyway, if someone can suggest a file or two where I can tweak the menu structure, I will try to come up with a patch.

This strange menu layout has lived too long.

TIA

Comment 4

[rsx11m]

The message context menu is a bit of a beast as it has all possible entries in a single <menupopup id="mailContext"> element, where the individual visibility of the menuitems is controlled in nsContextMenu.js.

The "mailContext-delete" definition can be found in mailWindowOverlay.xul, and is currently at line #814. If you move it or add a separator, you'll also need to make sure that the logic in nsContextMenu.js switches it along with the menuitem.

Comment 5

[:aceman]

I could do implement this too.
We just need some hints from bwinton if the separator would be acceptable, or we can even shuffle some items around.
For reference, Outlook 2007 has the Delete command next to Move and those two are both separated from the rest of the menu via separators. So it is as rsx11m suggests.
Also in Tb context menu of a folder, the Delete is in a group with New subfolder and Rename.
Maybe the reasoning for Delete to be last item is that it is the least used one in the menu (so saving mouse movement).

Comment 6

[Blake Winton (:bwinton) (:☕️)]

Could I see a screenshot of Outlook 2007, for comparison?

Comment 7

[ISHIKAWA, Chiaki]

While waiting for :aceman to come up with the screenshot from outlook2007 (I searched the web, but was not able to find it easily.),
here is a set of changes that I made to the CURRENT TB 17.0.2 linux version.
Two files were necessary to be modified to put a separator line between
print and delete. I am afraid that the horizontal separator is just
for visual alert, and not quite wide enough for the mouse jitter problem.
I think we need a disabled/dummy entry beneath the separator and above delete menu item.

I am sure Blake and :aceman know these, but I think it is a good
learning topic for a new comer like myself:

Basically, I need to add one entry for a separator in nsContextMenu.js, and
inserted a menuseparator entry in the desired place in mailWindowOverlay.xul.

I tried to see if I could insert a dead/disabled menu item between the separator and delete menu, but failed. They are commented out for now.


 

--- /tmp/nsContextMenu.js-original	2013-02-05 23:46:36.000000000 +0900
+++ /tmp/nsContextMenu.js	2013-02-05 23:47:00.000000000 +0900
@@ -252,7 +252,9 @@ nsContextMenu.prototype = {
         "mailContext-copyMessageUrl", "mailContext-moveMenu",
         "mailContext-copyMenu", "mailContext-moveToFolderAgain",
         "mailContext-tags", "mailContext-mark", "mailContext-saveAs",
-        "mailContext-printpreview", "mailContext-print", "mailContext-delete",
+        "mailContext-printpreview", "mailContext-print", 
+     // "mailContext-NOOP",
+        "mailContext-delete",
         "downloadSelected", "mailContext-reportPhishingURL"
       ];
       for (let i = 0; i < messageTabSpecificItems.length; ++i)
@@ -331,6 +333,9 @@ nsContextMenu.prototype = {
     // moment as we can't print non-message content from the message pane yet.
     this.showItem("mailContext-print", msgModifyItems);
 
+    // TODO/FIXME:
+    // this.showItem("mailContext-NOOP", false);
+
     this.showItem("mailContext-delete",
                   msgModifyItems && (this.isNewsgroup || canMove));
 
@@ -354,6 +359,7 @@ nsContextMenu.prototype = {
       "mailContext-sep-afterTagAddNew", "mailContext-sep-afterTagRemoveAll",
       "mailContext-sep-afterMarkAllRead", "mailContext-sep-afterMarkFlagged",
       "mailContext-sep-afterMarkMenu", "mailContext-sep-edit",
+      "mailContext-sep-delete",
       "mailContext-sep-copy", "mailContext-sep-reportPhishing",
       "mailContext-sep-undo", "mailContext-sep-clipboard",
       "mailContext-spell-suggestions-separator", "mailContext-spell-separator",




--- /tmp/mailWindowOverlay.xul-original	2013-02-05 23:52:10.000000000 +0900
+++ /tmp/mailWindowOverlay.xul	2013-02-05 23:57:11.000000000 +0900
@@ -162,6 +160,9 @@
   <command id="cmd_cut"/>
   <command id="cmd_copy"/>
   <command id="cmd_paste"/>
+
+  <!-- <command id="cmd_noop"/> -->
+
   <command id="cmd_delete"
          valueFolder="&deleteFolderCmd.label;"
          valueFolderAccessKey="&deleteFolderCmd.accesskey;"
@@ -745,6 +746,11 @@
               accesskey="&contextPrint.accesskey;"
               observes="cmd_print"
               command="cmd_print"/>
+    <menuseparator id="mailContext-sep-delete"/>
+
+    <!-- <menuitem id="mailContext-NOOP"
+              command="cmd_noop"/> -->
+
     <menuitem id="mailContext-delete"
               command="cmd_delete"/>
     <menuitem id="downloadSelected"

TIA

Comment 8

[:aceman]

Attachment: Outlook 2007 menu

Attached screenshot of Outlook message context menu. Translated some relevant items.

Comment 9

[:aceman]

I think separator and item reordering should be enough, as a "dead/empty" item is UI that is not used anywhere else.

Comment 10

[Jim Porter (:squib)]

(In reply to :aceman from comment #9)
> I think separator and item reordering should be enough, as a "dead/empty"
> item is UI that is not used anywhere else.

Moving the Delete item up to the group with move/copy makes sense, since that's how we organize things in the (old) Edit menu.

Comment 11

[Blake Winton (:bwinton) (:☕️)]

1) I agree that a dead/empty item would be more confusing and inconsistent than helpful, so let's go with the separator instead.

2) I think it would be nice to see the context menu have a similar order to the AppMenu (that little ≡ button on the top-right), so any proposal should take that menu into account.

3) I would certainly support a re-organization of the context menu.  :)

Thanks,
Blake.

Comment 12

[rsx11m]

Attachment: SeaMonkey context menu

For reference, this is SeaMonkey's context menu in an opened message. Note that they have moved both the "Save As" and the "Delete" items into the "Move/Copy" block, which would retain the issue for which this bug was opened, thus mixing up potentially "Save" and "Delete" (which makes quite a difference).

Thus, just moving "Delete" up to "Move/Copy" seems to be fine, given that "Save" and "Print" go along well. A potential problem may be the "Move/Copy ... again" shortcut function which may appear underneath the items with submenus, thus it may be tricky to entirely avoid the accessibility issue without a separator.

Comment 13

[ISHIKAWA, Chiaki]

Can we do something about this?

Should I reproduce something along the lines in comment 7
without the dead item?

TIA

Comment 14

[ISHIKAWA, Chiaki]

What is the next course of action on this topic?
Any hint, tips, etc.?

TIA

Comment 15

[ISHIKAWA, Chiaki]

Hi,

I would like to revisit this topic.

The problem of hitting the delete button instead of print often happens when
I am about to print a message when I receive a telephone call and
at the sound of the call buzzer, my fingers move a little thus pointing at a slightly
different place, and thinking that I would run off the printing while I talk,
I push the button (and deleting a message, ugh), and
after the phone session is over, go to a printer and not finding the print out,
come back to the desk and then the message is gone.
This has happend, far too often :-(

So what should I do?

I think many agree with a separator alone would be enough and not introduce dead item.

At the same time, there is a school of thought that "Delete" ought to go to 
the block of "move/copy/save as", etc.

I am afraid that the context menu has become very large and not sure what to do.

Anyway, I will 

(In reply to Blake Winton (:bwinton) from comment #11)
   ...
> 
> 2) I think it would be nice to see the context menu have a similar order to
> the AppMenu (that little ≡ button on the top-right), so any proposal should
> take that menu into account.

  I am afraid that todays AppMenu and context menu seem to differ so much,
I am not sure how I can accommodate this angle well enough.


> 3) I would certainly support a re-organization of the context menu.  :)

I will try and post a patch again.

TIA
 
> Thanks,
> Blake.

Comment 16

[ISHIKAWA, Chiaki]

Attachment: Patch. 1st try. Put a separator.

Hi, this is the first attempt to
put a separator in the context menu just above "delete" in
the context menu.

This is the first cut attempt.

I will upload the screen image to show the separator.

More TODO:
 change the layout so that delete is moved to the same group as in
 move, copy, etc.

Comment 17

[ISHIKAWA, Chiaki]

Attachment: To show the added separator.

The separator added as a result of the patch (1st try).

Comment 18

[ISHIKAWA, Chiaki]

Attachment: Message menu in AppMenu does not seem to have "Delete".

(In reply to Blake Winton (:bwinton) from comment #11)
> 1) I agree that a dead/empty item would be more confusing and inconsistent
> than helpful, so let's go with the separator instead.
> 
> 2) I think it would be nice to see the context menu have a similar order to
> the AppMenu (that little ≡ button on the top-right), so any proposal should
> take that menu into account.
> 

> 3) I would certainly support a re-organization of the context menu.  :)
> 

Hmm... I would love to go along with the old menu order to have the
delete grouped together with copy/move.

But, gee, AppMenu does not seem to have a "Delete" for message (?)
So conforming with the AppMenuy completely would not be possible.


> Thanks,
> Blake.

Comment 19

[ISHIKAWA, Chiaki]

Attachment: Where "delete" for a message is available [EDIT] -> Delete, and [Delete] button

Right now, when a message is selected, we can delete it by
 - the [DELETE] button in the message header window,
 - pull down: [EDIT] -> Delete, and
 - the context menu (right click) and hunt for delete at the end of
   long popup.

Now as I look at the issue,
I wonder how many people use this delete in context menu (which has gotten
very long now).

I am tempted to say "Let's get rid of Delete from the context menu. AppMenu does not have it".
This may be the simplest solution, but
there may be users who do use "delete" in context menu.

I will figure out how to move "Delete" in the move/copy group.
But if I cannot figure it out , I will prefer to have the patch (1st try) landed soon in the meantime (and people may have a better alternative design
like removing the "delete" from context menu, say).

TIA

Comment 20

[ISHIKAWA, Chiaki]

Attachment: Message pull down menu (vs AppMenu)

I forgot there is a big "Message" pull down on the tool bar.

Here is the screen short of the "Message" pull down (on the right),
and I copy the AppMenu screen dump to the left for comparison.

Message pull down menu has an extra "Attachments" entry.

So many inconsistencies. This is getting out of hands for a mere mortal user to fix :-(

Anyway, if there is no strong objection, at least, I will move "Delete" in context menu to "copy/move" group since
having "delete" next to printing menu items is a recipe for disaster.

Comment 21

[Richard Marti (:Paenglab)]

Attachment: AppMenuDelete.png

The AppMenu has the delete entry in Edit menu.

Comment 22

[ISHIKAWA, Chiaki]

(In reply to Richard Marti (:Paenglab) from comment #21)
> Created attachment 8504317 [details]
> AppMenuDelete.png
> 
> The AppMenu has the delete entry in Edit menu.

Thank you for the info. So AppMenu and Edit pull down is consistent in this regard.

It seems that Context-Menu is INCONSISTENT in the sense it has DELETE entry which
AppMenu, and Edit pull down do not.
But, of course, "Context" when one selects a message should show actions that are pertinent
to messages and so having "Delete" may be a good thing. But the position is 
not well human-engineered, anyway.

It seems that completely agreeing with AppMenu (which is a general menu)
is impossible. Moving "Delete" to Copy/Move group in context-menu
seems a sane option although AppMenu doesn't have it there.

TIA

Comment 23

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 8504287 [details] [diff] [review]
Patch. 1st try. Put a separator.

This seems fine, but I would also like to review the patch where you re-order the menu items so that they make more sense, and so I'm going to mark this as r-.  (But again, not because it's a bad patch!  Only because I want to make sure we don't check this one in.  :)

Thanks!

Comment 24

[ISHIKAWA, Chiaki]

Attachment: Patch to move "delete" in context menu to copy/move group.

The first try to move "delete" in context menu to the "copy/move" group in the same context menu.

Screenshot follows.

Comment 25

[ISHIKAWA, Chiaki]

Attachment: With the patch, it is moved to a better place. (Screen Image)

With the patch just posted, the "delete" menu item is moved up
to "copy/move" group area.

So far, so good.

As for testing, a seeming random bug crept in (maybe not due to my patch.)
More in another comment.

Comment 26

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 8506236 [details] [diff] [review]
Patch to move "delete" in context menu to copy/move group.

Review of attachment 8506236 [details] [diff] [review]:
-----------------------------------------------------------------

Other than the comment below, I like it!  Thank you for the patch!

::: mail/base/content/nsContextMenu.js
@@ +264,2 @@
>          "downloadSelected", "mailContext-reportPhishingURL"
>        ];

Since the changes in this file are just adding newlines, I'ld rather not make them in this patch.  Could you please back out the changes to this file?

Comment 27

[ISHIKAWA, Chiaki]

(Sorry for this VERY lengthy post. It took me a long time to figure
out what happened.)

Please find the changed context menu screen dump and
the patch to change the menu like this,
which I uploaded a few minutes ago.

I thought simple movement of the menu entry was just that.

So I began testing.
The first few tries worked just fine.
I thought I would make sure to refresh the source before reporting.

*HOWEVER*, now I get assertion failure when I tried removing a message :-(
SOMETIMES it WORKS, but other times it ends up in a crash due to
MOZ_ASSERT();

OTOH, I am not sure if the error IS related to MY patch or NOT: 
my observation is based on the fact as follows:

Observation-1. The current C-C TB may not be in good shape.  (I
refreshed the source file about 48 hours ago or so.)

For whatever the reason, unless I put the missing declaration for
seemingly very important variables (which JS interpreter complained
about loudly during execution) as follows, I could not even get to the
initial window with my DEBUG BUILD of C-C TB since the refresh.  TB
seemed to get hung without showing the screen completely, but only
showed white rectangle and panes without filling in the tool menus,
etc. I hit keys on the keyboard, moved mouse, no response. Very
strange.)  So there may be OTHER bugs lurking around.

# HG changeset patch
# Parent 06b9b65bc27918092c72521e692593661a2c1783
# User ISHIKAWA, Chiaki <[e-mail]>
add three missing declarations

diff --git a/mail/base/content/mail3PaneWindowCommands.js b/mail/base/content/mail3PaneWindowCommands.js
--- a/mail/base/content/mail3PaneWindowCommands.js
+++ b/mail/base/content/mail3PaneWindowCommands.js
@@ -7,16 +7,20 @@
  * consisting of folder pane, thread pane and message pane.
  */

 Components.utils.import("resource:///modules/mailServices.js");
 Components.utils.import("resource:///modules/MailUtils.js");
 Components.utils.import("resource://gre/modules/Services.jsm");
 Components.utils.import("resource://gre/modules/PluralForm.jsm");

+var  gFolderDisplay;		// missing declaration as of Oct, 2014
+var  MailOfflineMgr;		// ditto
+var  accountManager;		// ditto
+
 // Controller object for folder pane
 var FolderPaneController =
 {
   supportsCommand: function(command)
   {
     switch ( command )
     {
       case "cmd_delete":

Observation-2. 

The test which crashed due to MOZ_ASSERT() namely
"test_selection_last_message_deleted" in my local test run |make
mozmill| (I explain below) seems to generate TEST-UNEXPECTED-FAILURE
lately in mozilla's try server for other people's compile jobs 
(of course, without my patch to move the "delete" menu entry)
according to TBPL.

For example, I quote the few lines from a job I find in the listing:
https://tbpl.mozilla.org/php/getParsedLog.php?id=50328822&tree=Thunderbird-Trunk&full=1

--- begin quote ---
TEST-UNEXPECTED-FAIL | /builds/slave/test/build/mozmill/folder-display/test-selection.js | test-selection.js::test_selection_extension
TEST-START | /builds/slave/test/build/mozmill/folder-display/test-selection.js | test_selection_last_message_deleted
Test Failure: aController.dbView.selection is null
--- end quote

The symptom is different (I get a crash eventually inside the test)
whereas the above says aController.dbView.selection is null.  That can
be explained easily: I declared the three undeclared variables which
the JS interpreter complained and so maybe the point at which the test
program gave up and return a test failure status is different.

Still, crashing in C++ source code is not good :-(
We should make the code more robust (but that would be a different
bug, I am hoping).

Anyway the following is the crash I get and I am not sure
if it is due to my patch or some random M-C change beyond my control.
(That this seems to have started in the last few days was an
unfortunate coincidence.)

Assertion failure: mTopRowIndex == mozilla::clamped(mTopRowIndex, 0, maxTopRowIndex), at /REF-COMM-CENTRAL/comm-central/mozilla/layout/xul/tree/nsTreeBodyFrame.cpp:4091

The code is below. I have no idea what this routine is doing, etc.

nsresult
nsTreeBodyFrame::ScrollInternal(const ScrollParts& aParts, int32_t aRow)
{
  if (!mView) {
    return NS_OK;
  }
  int32_t maxTopRowIndex = std::max(0, mRowCount - mPageLength);
  MOZ_ASSERT(mTopRowIndex == mozilla::clamped(mTopRowIndex, 0, maxTopRowIndex));

  aRow = mozilla::clamped(aRow, 0, maxTopRowIndex);
  if (aRow == mTopRowIndex) {
    return NS_OK;
  }
  mTopRowIndex = aRow;
  Invalidate();
  PostScrollEvent();
  return NS_OK;
}



(Also, during |make mozmill| at least, I saw a crash due to the same
MOZ_ASSERT(). So this error is for real.)

Crash Traceback-1:

Traceback from crash when I manually tried to delete a message from
the moved context menu (tidied up by fix- fix_linux_stack.py script)

[20263] WARNING: no db, and no message header: file /REF-COMM-CENTRAL/comm-central/mailnews/local/src/nsMsgBrkMBoxStore.cpp, line 787
JavaScript strict warning: resource:///modules/activity/moveCopy.js, line 129: ReferenceError: reference to undefined property this.lastMessage.sourceFolder
morkFactory::OpenOldFile called with
	<</home/ishikawa/.thunderbird/u1ku1i3y.default/Mail/localhost/Trash.msf>>
IsSummaryFileValid: being called for
	<</home/ishikawa/.thunderbird/u1ku1i3y.default/Mail/localhost/Trash>>
IsSummaryFileValid: falling through and return NS_OK: folderSize =901, fileSize=8109, numUnreadMessages=0
Assertion failure: mTopRowIndex == mozilla::clamped(mTopRowIndex, 0, maxTopRowIndex), at /REF-COMM-CENTRAL/comm-central/mozilla/layout/xul/tree/nsTreeBodyFrame.cpp:4091
#01: nsTreeBodyFrame::ScrollToRow(int) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/xul/tree/nsTreeBodyFrame.cpp:4051)
#02: nsSliderFrame::AttributeChanged(int, nsIAtom*, int) (/REF-OBJ-DIR/objdir-tb3/layout/xul/../../dist/include/nsCOMPtr.h:816)
#03: mozilla::RestyleManager::AttributeChanged(mozilla::dom::Element*, int, nsIAtom*, int) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/base/RestyleManager.cpp:1145)
#04: PresShell::AttributeChanged(nsIDocument*, mozilla::dom::Element*, int, nsIAtom*, int) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/base/nsPresShell.cpp:4423)
#05: nsNodeUtils::AttributeChanged(mozilla::dom::Element*, int, nsIAtom*, int) (/REF-COMM-CENTRAL/comm-central/mozilla/content/base/src/nsNodeUtils.cpp:110)
#06: mozilla::dom::Element::SetAttrAndNotify(int, nsIAtom*, nsIAtom*, nsAttrValue const&, nsAttrValue&, unsigned char, bool, bool, bool) (/REF-COMM-CENTRAL/comm-central/mozilla/content/base/src/Element.cpp:2092)
#07: mozilla::dom::Element::SetAttr(int, nsIAtom*, nsIAtom*, nsAString_internal const&, bool) (/REF-COMM-CENTRAL/comm-central/mozilla/content/base/src/Element.cpp:1959)
#08: nsXBLPrototypeBinding::AttributeChanged(nsIAtom*, int, bool, nsIContent*, nsIContent*, bool) (/REF-OBJ-DIR/objdir-tb3/dom/xbl/../../dist/include/nsIContent.h:329)
#09: nsXBLBinding::AttributeChanged(nsIAtom*, int, bool, bool) (/REF-COMM-CENTRAL/comm-central/mozilla/dom/xbl/nsXBLBinding.cpp:601)
#10: mozilla::dom::Element::SetAttrAndNotify(int, nsIAtom*, nsIAtom*, nsAttrValue const&, nsAttrValue&, unsigned char, bool, bool, bool) (/REF-COMM-CENTRAL/comm-central/mozilla/content/base/src/Element.cpp:2061)
#11: mozilla::dom::Element::SetAttr(int, nsIAtom*, nsIAtom*, nsAString_internal const&, bool) (/REF-COMM-CENTRAL/comm-central/mozilla/content/base/src/Element.cpp:1959)
#12: nsTreeBodyFrame::InvalidateScrollbars(nsTreeBodyFrame::ScrollParts const&, nsWeakFrame&) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/xul/tree/nsTreeBodyFrame.cpp:975)
#13: nsTreeBodyFrame::FullScrollbarsUpdate(bool) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/xul/tree/nsTreeBodyFrame.cpp:4680)
#14: nsTreeBodyFrame::RowCountChanged(int, int) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/xul/tree/nsTreeBodyFrame.cpp:1886)
#15: nsMsgDBView::NoteChange(unsigned int, int, int) (/REF-COMM-CENTRAL/comm-central/mailnews/base/src/nsMsgDBView.cpp:6199)
#16: nsMsgDBView::OnDeleteCompleted(bool) (/REF-COMM-CENTRAL/comm-central/mailnews/base/src/nsMsgDBView.cpp:7353)
#17: NS_InvokeByIndex (/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/reflect/xptcall/md/unix/xptcinvoke_x86_64_unix.cpp:166)
#18: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNative.cpp:1747)
#19: XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1247)
#20: js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/jscntxtinlines.h:232)
#21: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:481)
#22: Interpret(JSContext*, js::RunState&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:2546)
#23: js::RunScript(JSContext*, js::RunState&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:431)
#24: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:500)
#25: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:537)
#26: JS_CallFunctionValue(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/jsapi.cpp:5024)
#27: nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) (/REF-OBJ-DIR/objdir-tb3/js/xpconnect/src/../../../dist/include/jsapi.h:1577)
#28: PrepareAndDispatch (/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/reflect/xptcall/md/unix/xptcstubs_x86_64_linux.cpp:124)
#29: SharedStub (xptcstubs_x86_64_linux.cpp:?)

Program /REF-OBJ-DIR/objdir-tb3/dist/bin/thunderbird (pid = 20263) received signal 11.
Stack:
#01: __restore_rt (sigaction.c:?)
#02: nsTreeBodyFrame::ScrollInternal(nsTreeBodyFrame::ScrollParts const&, int) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/xul/tree/nsTreeBodyFrame.cpp:4091 (discriminator 1))
#03: nsTreeBodyFrame::ScrollToRow(int) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/xul/tree/nsTreeBodyFrame.cpp:4051)
#04: nsSliderFrame::AttributeChanged(int, nsIAtom*, int) (/REF-OBJ-DIR/objdir-tb3/layout/xul/../../dist/include/nsCOMPtr.h:816)
#05: mozilla::RestyleManager::AttributeChanged(mozilla::dom::Element*, int, nsIAtom*, int) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/base/RestyleManager.cpp:1145)
#06: PresShell::AttributeChanged(nsIDocument*, mozilla::dom::Element*, int, nsIAtom*, int) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/base/nsPresShell.cpp:4423)
#07: nsNodeUtils::AttributeChanged(mozilla::dom::Element*, int, nsIAtom*, int) (/REF-COMM-CENTRAL/comm-central/mozilla/content/base/src/nsNodeUtils.cpp:110)
#08: mozilla::dom::Element::SetAttrAndNotify(int, nsIAtom*, nsIAtom*, nsAttrValue const&, nsAttrValue&, unsigned char, bool, bool, bool) (/REF-COMM-CENTRAL/comm-central/mozilla/content/base/src/Element.cpp:2092)
#09: mozilla::dom::Element::SetAttr(int, nsIAtom*, nsIAtom*, nsAString_internal const&, bool) (/REF-COMM-CENTRAL/comm-central/mozilla/content/base/src/Element.cpp:1959)
#10: nsXBLPrototypeBinding::AttributeChanged(nsIAtom*, int, bool, nsIContent*, nsIContent*, bool) (/REF-OBJ-DIR/objdir-tb3/dom/xbl/../../dist/include/nsIContent.h:329)
#11: nsXBLBinding::AttributeChanged(nsIAtom*, int, bool, bool) (/REF-COMM-CENTRAL/comm-central/mozilla/dom/xbl/nsXBLBinding.cpp:601)
#12: mozilla::dom::Element::SetAttrAndNotify(int, nsIAtom*, nsIAtom*, nsAttrValue const&, nsAttrValue&, unsigned char, bool, bool, bool) (/REF-COMM-CENTRAL/comm-central/mozilla/content/base/src/Element.cpp:2061)
#13: mozilla::dom::Element::SetAttr(int, nsIAtom*, nsIAtom*, nsAString_internal const&, bool) (/REF-COMM-CENTRAL/comm-central/mozilla/content/base/src/Element.cpp:1959)
#14: nsTreeBodyFrame::InvalidateScrollbars(nsTreeBodyFrame::ScrollParts const&, nsWeakFrame&) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/xul/tree/nsTreeBodyFrame.cpp:975)
#15: nsTreeBodyFrame::FullScrollbarsUpdate(bool) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/xul/tree/nsTreeBodyFrame.cpp:4680)
#16: nsTreeBodyFrame::RowCountChanged(int, int) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/xul/tree/nsTreeBodyFrame.cpp:1886)
#17: nsMsgDBView::NoteChange(unsigned int, int, int) (/REF-COMM-CENTRAL/comm-central/mailnews/base/src/nsMsgDBView.cpp:6199)
#18: nsMsgDBView::OnDeleteCompleted(bool) (/REF-COMM-CENTRAL/comm-central/mailnews/base/src/nsMsgDBView.cpp:7353)
#19: NS_InvokeByIndex (/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/reflect/xptcall/md/unix/xptcinvoke_x86_64_unix.cpp:166)
#20: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNative.cpp:1747)
#21: XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1247)
#22: js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/jscntxtinlines.h:232)
#23: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:481)
#24: Interpret(JSContext*, js::RunState&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:2546)
#25: js::RunScript(JSContext*, js::RunState&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:431)
#26: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:500)
#27: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:537)
#28: JS_CallFunctionValue(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/jsapi.cpp:5024)
#29: nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) (/REF-OBJ-DIR/objdir-tb3/js/xpconnect/src/../../../dist/include/jsapi.h:1577)
#30: PrepareAndDispatch (/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/reflect/xptcall/md/unix/xptcstubs_x86_64_linux.cpp:124)
#31: SharedStub (xptcstubs_x86_64_linux.cpp:?)
Sleeping for 300 seconds.
Type 'gdb /REF-OBJ-DIR/objdir-tb3/dist/bin/thunderbird 20263' to attach your debugger to this thread.
^C
ishikawa@ip030:/home/ishikawa$


Crash traceback-2:

Crash from |make mozmill| test:
The test is test_selection_last_message_deleted (this sounds very
likely the action which triggered crash when I manually deleted the message.)

TEST-START | /REF-COMM-CENTRAL/comm-central/mail/test/mozmill/folder-display/test-selection.js | test_selection_last_message_deleted
Step Pass: {"function": "Controller.keypress()"}
Assertion failure: mTopRowIndex == mozilla::clamped(mTopRowIndex, 0, maxTopRowIndex), at /REF-COMM-CENTRAL/comm-central/mozilla/layout/xul/tree/nsTreeBodyFrame.cpp:4091
#01: nsTreeBodyFrame::ScrollToRow(int) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/xul/tree/nsTreeBodyFrame.cpp:4051)
#02: nsSliderFrame::AttributeChanged(int, nsIAtom*, int) (/REF-OBJ-DIR/objdir-tb3/layout/xul/../../dist/include/nsCOMPtr.h:816)
#03: mozilla::RestyleManager::AttributeChanged(mozilla::dom::Element*, int, nsIAtom*, int) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/base/RestyleManager.cpp:1145)
#04: PresShell::AttributeChanged(nsIDocument*, mozilla::dom::Element*, int, nsIAtom*, int) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/base/nsPresShell.cpp:4423)
#05: nsNodeUtils::AttributeChanged(mozilla::dom::Element*, int, nsIAtom*, int) (/REF-COMM-CENTRAL/comm-central/mozilla/content/base/src/nsNodeUtils.cpp:110)
#06: mozilla::dom::Element::SetAttrAndNotify(int, nsIAtom*, nsIAtom*, nsAttrValue const&, nsAttrValue&, unsigned char, bool, bool, bool) (/REF-COMM-CENTRAL/comm-central/mozilla/content/base/src/Element.cpp:2092)
#07: mozilla::dom::Element::SetAttr(int, nsIAtom*, nsIAtom*, nsAString_internal const&, bool) (/REF-COMM-CENTRAL/comm-central/mozilla/content/base/src/Element.cpp:1959)
#08: nsXBLPrototypeBinding::AttributeChanged(nsIAtom*, int, bool, nsIContent*, nsIContent*, bool) (/REF-OBJ-DIR/objdir-tb3/dom/xbl/../../dist/include/nsIContent.h:329)
#09: nsXBLBinding::AttributeChanged(nsIAtom*, int, bool, bool) (/REF-COMM-CENTRAL/comm-central/mozilla/dom/xbl/nsXBLBinding.cpp:601)
#10: mozilla::dom::Element::SetAttrAndNotify(int, nsIAtom*, nsIAtom*, nsAttrValue const&, nsAttrValue&, unsigned char, bool, bool, bool) (/REF-COMM-CENTRAL/comm-central/mozilla/content/base/src/Element.cpp:2061)
#11: mozilla::dom::Element::SetAttr(int, nsIAtom*, nsIAtom*, nsAString_internal const&, bool) (/REF-COMM-CENTRAL/comm-central/mozilla/content/base/src/Element.cpp:1959)
#12: nsTreeBodyFrame::InvalidateScrollbars(nsTreeBodyFrame::ScrollParts const&, nsWeakFrame&) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/xul/tree/nsTreeBodyFrame.cpp:975)
#13: nsTreeBodyFrame::FullScrollbarsUpdate(bool) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/xul/tree/nsTreeBodyFrame.cpp:4680)
#14: nsTreeBodyFrame::RowCountChanged(int, int) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/xul/tree/nsTreeBodyFrame.cpp:1886)
#15: nsMsgDBView::NoteChange(unsigned int, int, int) (/REF-COMM-CENTRAL/comm-central/mailnews/base/src/nsMsgDBView.cpp:6199)
#16: nsMsgDBView::OnDeleteCompleted(bool) (/REF-COMM-CENTRAL/comm-central/mailnews/base/src/nsMsgDBView.cpp:7353)
#17: NS_InvokeByIndex (/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/reflect/xptcall/md/unix/xptcinvoke_x86_64_unix.cpp:166)
#18: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNative.cpp:1747)
#19: XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1247)
#20: js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/jscntxtinlines.h:232)
#21: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:481)
#22: Interpret(JSContext*, js::RunState&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:2546)
#23: js::RunScript(JSContext*, js::RunState&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:431)
#24: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:500)
#25: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:537)
#26: js::jit::DoCallFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICCall_Fallback*, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/jit/BaselineIC.cpp:8658)
#27: ??? (???:???)

Program ../../dist/bin/thunderbird (pid = 21695) received signal 11.
Stack:
#01: __restore_rt (sigaction.c:?)
#02: nsTreeBodyFrame::ScrollInternal(nsTreeBodyFrame::ScrollParts const&, int) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/xul/tree/nsTreeBodyFrame.cpp:4091 (discriminator 1))
#03: nsTreeBodyFrame::ScrollToRow(int) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/xul/tree/nsTreeBodyFrame.cpp:4051)
#04: nsSliderFrame::AttributeChanged(int, nsIAtom*, int) (/REF-OBJ-DIR/objdir-tb3/layout/xul/../../dist/include/nsCOMPtr.h:816)
#05: mozilla::RestyleManager::AttributeChanged(mozilla::dom::Element*, int, nsIAtom*, int) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/base/RestyleManager.cpp:1145)
#06: PresShell::AttributeChanged(nsIDocument*, mozilla::dom::Element*, int, nsIAtom*, int) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/base/nsPresShell.cpp:4423)
#07: nsNodeUtils::AttributeChanged(mozilla::dom::Element*, int, nsIAtom*, int) (/REF-COMM-CENTRAL/comm-central/mozilla/content/base/src/nsNodeUtils.cpp:110)
#08: mozilla::dom::Element::SetAttrAndNotify(int, nsIAtom*, nsIAtom*, nsAttrValue const&, nsAttrValue&, unsigned char, bool, bool, bool) (/REF-COMM-CENTRAL/comm-central/mozilla/content/base/src/Element.cpp:2092)
#09: mozilla::dom::Element::SetAttr(int, nsIAtom*, nsIAtom*, nsAString_internal const&, bool) (/REF-COMM-CENTRAL/comm-central/mozilla/content/base/src/Element.cpp:1959)
#10: nsXBLPrototypeBinding::AttributeChanged(nsIAtom*, int, bool, nsIContent*, nsIContent*, bool) (/REF-OBJ-DIR/objdir-tb3/dom/xbl/../../dist/include/nsIContent.h:329)
#11: nsXBLBinding::AttributeChanged(nsIAtom*, int, bool, bool) (/REF-COMM-CENTRAL/comm-central/mozilla/dom/xbl/nsXBLBinding.cpp:601)
#12: mozilla::dom::Element::SetAttrAndNotify(int, nsIAtom*, nsIAtom*, nsAttrValue const&, nsAttrValue&, unsigned char, bool, bool, bool) (/REF-COMM-CENTRAL/comm-central/mozilla/content/base/src/Element.cpp:2061)
#13: mozilla::dom::Element::SetAttr(int, nsIAtom*, nsIAtom*, nsAString_internal const&, bool) (/REF-COMM-CENTRAL/comm-central/mozilla/content/base/src/Element.cpp:1959)
#14: nsTreeBodyFrame::InvalidateScrollbars(nsTreeBodyFrame::ScrollParts const&, nsWeakFrame&) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/xul/tree/nsTreeBodyFrame.cpp:975)
#15: nsTreeBodyFrame::FullScrollbarsUpdate(bool) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/xul/tree/nsTreeBodyFrame.cpp:4680)
#16: nsTreeBodyFrame::RowCountChanged(int, int) (/REF-COMM-CENTRAL/comm-central/mozilla/layout/xul/tree/nsTreeBodyFrame.cpp:1886)
#17: nsMsgDBView::NoteChange(unsigned int, int, int) (/REF-COMM-CENTRAL/comm-central/mailnews/base/src/nsMsgDBView.cpp:6199)
#18: nsMsgDBView::OnDeleteCompleted(bool) (/REF-COMM-CENTRAL/comm-central/mailnews/base/src/nsMsgDBView.cpp:7353)
#19: NS_InvokeByIndex (/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/reflect/xptcall/md/unix/xptcinvoke_x86_64_unix.cpp:166)
#20: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNative.cpp:1747)
#21: XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) (/REF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1247)
#22: js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/jscntxtinlines.h:232)
#23: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:481)
#24: Interpret(JSContext*, js::RunState&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:2546)
#25: js::RunScript(JSContext*, js::RunState&) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:431)
#26: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:500)
#27: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:537)
#28: js::jit::DoCallFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICCall_Fallback*, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) (/REF-COMM-CENTRAL/comm-central/mozilla/js/src/jit/BaselineIC.cpp:8658)
#29: ??? (???:???)
Sleeping for 300 seconds.
Type 'gdb ../../dist/bin/thunderbird 21695' to attach your debugger to this thread.
Done sleeping...
self.timeout = 600.0

Timeout: bridge.execFunction("e71527a8-5543-11e4-9283-0800279cc9e6", bridge.registry["{36620c28-2f5a-4882-b579-a3f95281e478}"]["runTestDirectory"], ["/REF-COMM-CENTRAL/comm-central/mail/test/mozmill/folder-display"])

TEST-UNEXPECTED-FAIL | Disconnect Error: Application unexpectedly closed
self.timeout = 600.0

So basically, we have the similar traceback.

Until this crash is fixed (hopefully caused by a recent change in M-C
tree code?), I can't say that the patch proposed in this bugzilla is
the correct one, for sure :-(

BTW, People would ask what gdb shows at the point where the crash
occured: I tried to attach gdb as suggested by the crash message.

Unfortunately, for some reason, after the binary file layout change of
MOZ_OBJ/mozilla/dist/bin -> MOZ_OBJ/dist/bin 

and the like [since early this summer?], I could not get gdb to work,
I am afraid.

I think it may have have something to do with my using -gsplit-dwarf
to compile TB, and gdb may not find the correct (SEPARATE) debug
symbol files, etc. It used to work before the layout change, I think.
I am tweaking the .gdbinit to refer to proper directories to look for
debug symbols and dynamic libraries, etc., but no success yet.

What is more troubling with gdb is as follows.

I thought, why not run thunderbird under gdb in the first place?
Why not indeed.
What I get when I try running gdb by invoking thunderbird
directly is this.

$ gdb /REF-OBJ-DIR/objdir-tb3/dist/bin/thunderbird-bin
GNU gdb (GDB) 7.7.50.20140610-cvs
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /REF-OBJ-DIR/objdir-tb3/dist/bin/thunderbird-bin...done.
(gdb) run
Starting program: /REF-OBJ-DIR/objdir-tb3/dist/bin/thunderbird-bin
Cannot exec /REF-OBJ-DIR/objdir-tb3/dist/bin/thunderbird-bin -c exec /REF-OBJ-DIR/objdir-tb3/dist/bin/thunderbird-bin .
Error: Argument list too long
During startup program exited with code 127.
(gdb) quit


Huh? Note the "Error: Argument list too long" message.  
It used to be that I could simply run thunderbird this way.

Maintaining TB seems to get harder every week...

TIA

Comment 28

[ISHIKAWA, Chiaki]

Attachment: Patch to move delete to copy/move group. carrying over r=bwinton

Comment 29

[ISHIKAWA, Chiaki]

(In reply to ISHIKAWA, Chiaki from comment #28)
> Created attachment 8507633 [details] [diff] [review]
> Patch to move delete to copy/move group. carrying over r=bwinton


I have uploaded the patch that incorporated the comment.
(I touched the extra file when I thought I needed to touch many files.
It turned out that for this simple change, .xul alone had to be changed.)

After struggling to figure out what went wrong with the compilation and run-time failure,
I am fairly confident that the crash I saw is NOT due to my little change discussed here
(it ought to be obvious from the file being touched, but I had no choice but to run
|make mozmill| and xpcshell-tests just to be sure.)
So I am confident that the patch is fine.

TIA

Comment 30

[ISHIKAWA, Chiaki]

Attachment: Patch to move delete to copy/move group. carrying over r=bwinton+

Hi, 
I put the comment line in the patch into one single line, and edited the attachment description by adding a "+" at the end, and put need-checkin keyword.
(Obsoleted the two previous patches to make it easy for the committer, I hope.)

TIA

Comment 31

[:aceman]

So hopefully nobody will misclick Delete instead of Copy again. But that could be a lot less used action than Print.

Comment 32

[aleth [:aleth]]

https://hg.mozilla.org/comm-central/rev/09d259c61558

Comment 33

[ISHIKAWA, Chiaki]

(In reply to :aceman from comment #31)
> So hopefully nobody will misclick Delete instead of Copy again. But that
> could be a lot less used action than Print.

Hi,
I see you point here.
Hopefully, if THAT becomes a problem, someone will come up with a nicer UI.