Group actions on collapsed threads

RESOLVED FIXED in Thunderbird 3.0b3

Status

enhancement
RESOLVED FIXED
11 years ago
6 years ago

People

(Reporter: fred.jen, Assigned: Bienvenu)

Tracking

(Depends on 1 bug, Blocks 1 bug)

Trunk
Thunderbird 3.0b3
Dependency tree / graph
Bug Flags:
blocking-thunderbird3 -
wanted-thunderbird3 +
wanted1.8.1.x -
in-litmus +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [testplan])

Attachments

(2 attachments, 12 obsolete attachments)

1014 bytes, patch
Bienvenu
: review-
Details | Diff | Splinter Review
52.44 KB, patch
standard8
: review+
Details | Diff | Splinter Review
Posted patch group actions - v1 (obsolete) — Splinter Review
When a thread is collapsed and an action like move/copy/delete/tag/mark are
performed on the message, all the messages under that collapsed message should
undergo similar action automatically.

I introduced this possibility for move/copy/delete. I am very interested in hints, as this is my first c++-patch and I am still very fresh.
FWIW, several of the deps of bug 236849 would be resolved by fixing this.
Assignee: nobody → fred.jen
Posted patch group actions - v2 (obsolete) — Splinter Review
It is possible to
- delete
- mark
- copy
- junk/unjunk
The "mark message as read" is hidden if you click a collapsed thread
The GetCollapsedThreadByIndex is scriptable via xpcom.
I want to use finish the work now for tags, but the tag functions are part of
mailWindowOverlay.js.
So I have to do the work in javascript. There i can't use all tree functions
and have to write code to look for the children. IMHO I have to do the same as
for CopyMessages, but no more in c++ but in js. And I am not sure how to do it
in an intelligent way. I don't think that I should create new scriptable
routines for the js-part (someone would have done it before me if it would be
necessary). So I am wondering about the right approach to the work in the js
routines like RemoveAllTags.

If the patch looks strange, I did it with copy paste in another comm-central
clone and it seems non-trivial to work with mercurial
Attachment #331573 - Attachment is obsolete: true
Fred, you will want to request review for the patch. See
 http://www.mozilla.org/mailnews/review.html and
               http://www.mozilla.org/mailnews/review-mail.html
               http://developer.mozilla.org/en/Getting_your_patch_in_the_tree

probably also want to request "ui-review"
Summary: Group actions on threads → Group actions on collapsed threads
Attachment #332050 - Flags: review?(bienvenu)
For me this patch requires something like bug 454829 to be implemented.  Right now we're displaying the first message of the thread when a collapsed thread is selected.  I can't see an easy way to indicate to a person that their actions (delete, mark, etc.) will take place on the entire thread and not just the message we are displaying.

Also for user who are upgrading and expecting the previous behavior may need a transitional dialog or something.  However I do feel like the visual change suggested in bug 454829 could be enough of a difference that people would expect a different behavior from older versions.
Depends on: 454829
I think this patch will be done before something like bug 454829 is done, so we might need a transitional warning dialog w/ a don't ask me again checkbox while we transition to the full solution.

Fred, thanks for the patch! Some style comments first:

+    } else {
+      nsCOMPtr <nsIMsgThread> threadHdr;
+      nsresult rv = GetThreadContainingIndex(viewIndex, getter_AddRefs(threadHdr));
+      NS_ENSURE_SUCCESS(rv, rv);
+      PRUint32 threadCount;
+      GetThreadCount(key, &threadCount);
+      for (long i = 0; i < threadCount; i++) {
+        nsCOMPtr <nsIMsgDBHdr> msgHdr;

the prevailing braces style is

if (a)
{
  ...
}
else 
{
  ...
}

Also, instead of using "long", you should use PRInt32 to match the rest of the code. And PR_FALSE/PR_TRUE instead of false/true, to match the rest of the code.

Here,

+    PRUint32 flags = m_flags[threadIndex];
+    if (flags & MSG_FLAG_ELIDED) {
+      *aCollapsed = true;
+      return NS_OK;
+    } else {
+      *aCollapsed = false;
+      return NS_OK;
+    }

this can be simply:
*aCollapsed = m_flags[threadIndex] & MSG_FLAG_ELIDED;
reurn NS_OK;

Re the larger question of how to make this work in general, across c++ and js, for all operations, I'm going to look at the code a bit and see if I can figure out a way of doing this nicely.
Posted patch alternate route (obsolete) — Splinter Review
Fred, what do you think of this approach?  It doesn't require changing any js for remove all tags, because I've tweaked nsMsgDBView::GetURIsForSelection to include the collapsed headers.

If we need to, for js callers, we could add a new method to nsIMsgDBView to return the headers that correspond to the selection, which would basically just be a wrapper around nsMsgDBView::GetHeadersFromSelection, except that it would calculate indices and numIndices from the selection, and then call GetHeadersFromSelection.

I think this approach is a bit more general, and does allow us to handle things like quick search db views, which need to be specialized by overriding nsMsgDBView::ListCollapsedChildren, as I've commented in the patch.

Would you be interested in pursuing this feature using this approach as a starting point?

One question would be where to pop up the transitional alert, if we're going to do that. nsMsgDBView::GetHeadersFromSelection would be a candidate.
One last tip about idl:

@@ -325,6 +325,7 @@ interface nsIMsgDBView : nsISupports
 
   nsMsgViewIndex findIndexFromKey(in nsMsgKey aMsgKey, in boolean aExpand);
   void ExpandAndSelectThreadByIndex(in nsMsgViewIndex aIndex, in boolean aAugment);
+  void GetCollapsedThreadByIndex( in nsMsgViewIndex aIndex, out boolean aCollapsed);
 
it would have been easier if you had defined it as follows:

boolean GetIsThreadCollapsedByIndex(in nsMsgViewIndex aIndex);

then, you don't need to create an object in js to get the result back; you can assign a var directly to the function call.
Attachment #332050 - Flags: review?(bienvenu) → review-
Comment on attachment 332050 [details] [diff] [review]
group actions - v2

minusing...
Hi, I will try it, when I have some time. But I do not have a lot of time at the moment. So if someone wants to take this bug, no prob.
David : I applied your patch and it seems to me like it already applying those group actions for moving messages and tagging them. It doesn't work for marking actions, but I am not sure if this is really interesting or rather confusing for the user.
Didn't test conversions to tasks etc until now.
OK, thx, Fred. I'll reassign it to myself, but if you have time and want to add the code to do the transitional alert to my patch, that would be great. I'm swamped with things right now...
Assignee: fred.jen → bienvenu
Severity: normal → enhancement
Blocks: 236849
Duplicate of this bug: 65111
Flags: wanted-thunderbird3+
Target Milestone: --- → Thunderbird 3.0rc1
Duplicating this to bug 65111 hides the fact that this is an 8 year old problem!

If this is fixed I might finally switch from Outlook Express to Thunderbird.  How close is it to fixing?  BUTTONS! (with the "DELETE!" functionality) once tried to address this problem as a plugin.
Could the 31 votes for bug 65111 be transferred to this one, in order to correctly reflect the importance of this issue?
(In reply to comment #13)
> Duplicating this to bug 65111 hides the fact that this is an 8 year old
> problem!
(In reply to comment #14)
> Could the 31 votes for bug 65111 be transferred to this one, in order to
> correctly reflect the importance of this issue?

No it's not possible. Everyone here I think understands both the import and the fact that this is a long standing bug.  The patch is I think mostly if not all shared code so I think there is no doubt SM will get this as well

What is important, is that a) it has a target and b) it is making progress, but which may be stall until after beta 2 wraps up and c) that people help test the changes and/or contribute code.
Some reason, this is not happening for me..What have you tried so far?
Attachment #338402 - Attachment is obsolete: true
Posted patch i think this is the right one (obsolete) — Splinter Review
I think i uploaded the wrong version. this one is right.
Attachment #359008 - Attachment is obsolete: true
David: this works great for collapsed threads, but it seems to me it should act the same for collapsed group views.  IOW, I'm thinking that GetHeadersFromSelection should return the headers of all of the rows implied by the selection, including those hidden behind elided group rows.

Thoughts?
Yes, that makes sense - I can try to add that to my patch.

Should we tie my patch and yours together, i.e., make them dependent on each other, or should I try to add a simple first time alert warning?
my patch won't do anything to mitigate the downside risk of users used to keyboard actions which will now do something new.  So I'd say a first-time alert is a good idea, as long as it's only for existing profiles -- I think that my patch will land before 3 (maybe not b2, but i'm optimistic).
If we select the first message in a collapsed thread, we should expand the thread so that we're actually selecting the message, not the whole thread.
Attachment #359615 - Flags: review?(bienvenu)
> my patch won't do anything to mitigate the downside risk of users used to
> keyboard actions which will now do something new.

Some suggestions:

1) You could make the new behavior ("delete entire thread if collapsed and top msg deleted") some sort of config option, and not have it turned on by default.

2) You could use a different button/command for this: "delete entire thread". This would actually be better, as "Control-D" (or whatever) could delete the entire thread of whatever msg I'm on top of (or have opened), no matter whether the thread is collapsed or not.  (I'm sure those of us who get torrents of threaded bugzilla mail have been in the situation where you start reading a few mgs in a thread, and then want to just blow the whole thread away.  It would be very nice it that only took one keystroke.)
Comment on attachment 359009 [details] [diff] [review]
i think this is the right one

this isn't quite right because it doesn't update the row count on the tree correctly - there's code that knows when you delete the top level message in a thread, the row count doesn't actually change, and that needs to be fixed.

I've gone ahead and written some code to do a warning dialog - we can always rip it out later...
Posted patch wip (obsolete) — Splinter Review
this fixes a bunch of issues with the previous patches, but it doesn't handle threaded cross-folder saved searches - in that case, GetHeadersFromSelection isn't called, though I could probably tweak it to do so...
Attachment #332050 - Attachment is obsolete: true
Attachment #359009 - Attachment is obsolete: true
Flags: wanted1.8.1.x?
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3?
it's not happening for 1.8.1 - we're only putting security fixes and regression fixes in 1.8.1. But I'm pretty sure we'll get this for 3.0
Flags: wanted1.8.1.x?
Flags: wanted1.8.1.x-
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3-
Posted patch more wip (obsolete) — Splinter Review
this works with cross-folder saved searches, and fixes a few other issues with the prev patch. It's almost ready for review.
Attachment #360196 - Attachment is obsolete: true
I'm thinking I might control this behavior with a pref, and default it to applying to the thread as a whole. But that way, SM can chose what it wants, and power users can chose as well. I'm having a hard time not deleting the top level message in a collapsed thread and expecting the next message to get loaded - having something completely different get loaded in the message area will help, no doubt.

An other problem with this patch is that when I reply to a top level message in a collapsed thread, we try to set the replied flag on every message in the thread, so I need some way of being a little more discerning in GetHeadersFromSelection.
Agreed that this behavior makes sense only w/ the right UI change in the message pane.

A pref that can control both the UI and the behavior change makes sense to me.
I've added the controlling pref. Then I started playing with the idea of making GetNumSelected() include the collapsed children - this would disable commands that don't work on multiple selection, and make the num Selected status bar item include the collapsed children. I think it's probably the way to go, but I'm not 100% sure yet...
Comment on attachment 359615 [details] [diff] [review]
tweak to SelectFolderMsgByKey

this should be able to be written as:

if (m_flags[viewIndex] & nsMsgMessageFlags::Elided)
  ToggleOpenState(viewIndex);
Posted patch more wip (obsolete) — Splinter Review
this changes GetNumSelected to included msgs in collapsed threads, and adds a pref to turn off this behavior.
Attachment #360431 - Attachment is obsolete: true
At least on OS X, the warning dialog that shows up needs wording changes, as it repeats the same question twice, and I'm not sure the question makes sense to all.  Also, I suspect that if we have a pref we can set w/ a dialog and a [] don't ask me again, then we need UI to unset it.
Duplicate of this bug: 481611
Attachment #359615 - Flags: review?(bienvenu) → review-
Comment on attachment 359615 [details] [diff] [review]
tweak to SelectFolderMsgByKey

minusing based on prev comment - I'll try to roll my suggestion into the patch I'm working on.
Duplicate of this bug: 473714
Please don’t forget add notice to mailnews\base\public\nsIMsgDBView.idl.
I expected that numSelected returns number of selected messages in msgDbView, not just number of selected messages in first selection range (mozilla\layout\xul\base\src\tree\src\nsTreeSelection.cpp).
Posted patch proposed fix (obsolete) — Splinter Review
This patch makes it so various operations like *, junk, etc, apply to messages in collapsed threads. I've also changed the confirmation about applying actions to messages in collapsed threads to just delete, and I'm interested in what davida and clarkbw think about that, and the strings I used - maybe that confirmation will go away completely because selecting a collapsed thread will have such a different display. But there are still cases like users who have the message pane collapsed away, etc.

I've also changed the pref name to be more descriptivie...
Attachment #363437 - Attachment is obsolete: true
What's the test plan on this?
(In reply to comment #39)
> What's the test plan on this?

I was going to say the first thing to do would be to fix the existing automated tests not to break w/ this change, but they don't seem to exercise this code.

I think we need a couple sets of tests, one with the "apply to msgs in collapsed threads" pref set to true, and one with it false. Both will need to set the warn on delete pref to false, if we keep that pref. Each test will need to populate a threaded view, and apply a set of commands to the top-level message in a collapsed thread and verify that the commands were applied to all the messages in the collapsed thread, or not, based on the pref. In both these tests, we're really interested in seeing if each command is handled correctly - we don't need a complicated data set of messages.

We also need to test saved searches across multiple folders to make sure that selections that span folders are handled correctly, and partitioned into their separate folders.

The QA mini-test plan would be essentially the same.
Whiteboard: [testplan]
Suggested test plan:

2 threads of 4 messages each.

Collapsed Thread feature ON
Selected and deleted:Expected action

One collapsed thread: Thread deleted
Two collapsed theads: Two threads deleted 
One collapsed thread, top message in open thread:Collapsed thread deleted, top message deleted in open thread, 3 remaining
Top message in two open threads: Selected messages deleted, no more, 3 left in each

Collapsed Thread feature OFF
One collapsed thread: exposed (top) message deleted (3 left)
Two collapsed threads: each exposed (top) message deleted (3 left in each thread)
One collapsed thread, top message in open thread: exposed (top) message deleted and top message deleted in open thread
Top message in two open threads: Selected messages deleted, no more.
Posted patch proposed fix (obsolete) — Splinter Review
If the pref "mail.operate_on_msgs_in_collapsed_threads" is set (w/ patch, defaults to true with TB, false with SM), if the user selects a collapsed thread, we include the messages in the collapsed thread in any command the user picks. For delete, we warn the user, with a checkbox to turn off the warning, though I hope to get rid of this warning once we land Davida's selection summary patch.

I had to change a bunch of code that dealt with view indices to deal with msg hdrs instead (in particular, the junk processing code), and that had a bit of a ripple effect. I also cleaned up some indentation.
Attachment #376322 - Attachment is obsolete: true
Attachment #376806 - Flags: superreview?(neil)
Attachment #376806 - Flags: review?(bugzilla)
Comment on attachment 376806 [details] [diff] [review]
proposed fix

We seem to have a maze of twisty thread expanding methods, all different...
[weak pun intended]

>+pref("mail.operate_on_msgs_in_collapsed_threads", true);
What about a) the other prefs b) default value in mailnews.js?

>-  NS_ASSERTION(numSelected == selection.Length(), "selected indices is not equal to num of msg selected!!!");
Going to resolve bug 436361? Or maybe I'm thinking of another bug. Wayne Mery might remember the one I'm thinking of.

>     *next = ToNewCString(tmpUri);
>-    if (!*next) return NS_ERROR_OUT_OF_MEMORY;
>+    if (!*next)
>+      return NS_ERROR_OUT_OF_MEMORY;
[Side note: this return leaks the succesfully created strings]

>+    for (nsMsgViewIndex index = 0; index < (nsMsgViewIndex) numIndices; index++)
>+      mIndicesToNoteChange.AppendElement(indices[index]);
mIndicesToNoteChange.AppendElements(indices, numIndices);
[I think that this happens somewhere else in the patch too.]

>+  if (command == nsMsgViewCommandType::markThreadRead)
>+  {
>+      for (PRInt32 index = 0; index < numIndices; index++)
>+        SetThreadOfMsgReadByIndex(indices[index], imapUids, PR_TRUE);
>+  }
Nit: odd indentation

>+      if (thisIsImapFolder && command != nsMsgViewCommandType::markThreadRead)
Marking threads read has already been special-cased.

>+        rv = SetMsgHdrJunkStatus(junkPlugin.get(), msgHdr,
>+                               nsIJunkMailPlugin::JUNK);
Indentation nit. (Also for ::GOOD)

>+     if (!buttonPressed)
>+     {
>+       if (!alwaysAsk)
>+         prefBranch->SetBoolPref(warnPref, PR_FALSE);
>+     }
>+     else
>+     {
>+       messageArray->Clear();
>+       return NS_ERROR_FAILURE;
>+     }
Ugh. First, messageArray clears itself when you release its last reference. Then, you've got a reversed else-after-return. Finally, do you really want clicking on Cancel to throw an exception?

>+        msgHdr->GetMessageKey(&msgKey);
>+        imapUids[i] = msgKey;
Nit: msgHdr->GetMessageKey(&imapUids[i]);

>+nsMsgDBView::GetNumSelected(PRUint32 *aNumSelected)
I hope we don't have code depending on this.

> PRBool nsMsgDBView::NonDummyMsgSelected(nsMsgViewIndex * indices, PRInt32 numIndices)
> {
>   for (nsMsgViewIndex index = 0; index < (nsMsgViewIndex) numIndices; index++)
>   {
>     PRUint32 flags = m_flags[indices[index]];
>-    if (!(flags & MSG_VIEW_FLAG_DUMMY))
>+    // We now treat having a collapsed dummy message selected as if
>+    // the whole group was selected so we can apply commands to the group.
Don't you need to check the pref first?
(In reply to comment #43)

> 
> >+pref("mail.operate_on_msgs_in_collapsed_threads", true);
> What about a) the other prefs b) default value in mailnews.js?

oops, forgot to include mailnews.js in the diffs. I didn't want to pollute mailnews.js and all-thunderbird.js with the other pref since I think it might go away, but I can always add it and remove it later.

> 
> >+     if (!buttonPressed)
> >+     {
> >+       if (!alwaysAsk)
> >+         prefBranch->SetBoolPref(warnPref, PR_FALSE);
> >+     }
> >+     else
> >+     {
> >+       messageArray->Clear();
> >+       return NS_ERROR_FAILURE;
> >+     }
> Ugh. First, messageArray clears itself when you release its last reference.
> Then, you've got a reversed else-after-return. Finally, do you really want
> clicking on Cancel to throw an exception?

duh, I moved this code from a lower level method where those things made more sense. But I think I do need to return an error so the caller knows the delete didn't start. 


> 
> > PRBool nsMsgDBView::NonDummyMsgSelected(nsMsgViewIndex * indices, PRInt32 numIndices)
> > {
> >   for (nsMsgViewIndex index = 0; index < (nsMsgViewIndex) numIndices; index++)
> >   {
> >     PRUint32 flags = m_flags[indices[index]];
> >-    if (!(flags & MSG_VIEW_FLAG_DUMMY))
> >+    // We now treat having a collapsed dummy message selected as if
> >+    // the whole group was selected so we can apply commands to the group.
> Don't you need to check the pref first?

Could be - I'll check.
Posted patch address Neil's comments (obsolete) — Splinter Review
this addresses Neil's comments, mostly, and adds a little bit more cleanup that fell out of them.
Attachment #376806 - Attachment is obsolete: true
Attachment #377683 - Flags: superreview?(neil)
Attachment #377683 - Flags: review?(bugzilla)
Attachment #376806 - Flags: superreview?(neil)
Attachment #376806 - Flags: review?(bugzilla)
sorry for the churn.
Attachment #377683 - Attachment is obsolete: true
Attachment #377685 - Flags: superreview?(neil)
Attachment #377685 - Flags: review?(bugzilla)
Attachment #377683 - Flags: superreview?(neil)
Attachment #377683 - Flags: review?(bugzilla)
Attachment #377685 - Flags: superreview?(neil) → superreview+
Whiteboard: [testplan] → [testplan] [needs review from standard8]
Comment on attachment 377685 [details] [diff] [review]
oops, didn't save mailnews.js before generating diff

General nit: no space between nsCOMPtr and <

>+// this method would need to be overridden by the various view classes
>+// that have different kinds of threads. For example, in a 

nit: Sentences start with capitals.

>-      messageArray->AppendElement(msgHdr, PR_FALSE);
>+      rv = messageArray->AppendElement(msgHdr, PR_FALSE);
>+      if (NS_SUCCEEDED(rv) && viewIndexFlags & nsMsgMessageFlags::Elided &&
>+          includeCollapsedMsgs && viewIndexFlags & MSG_VIEW_FLAG_HASCHILDREN &&
>+          m_viewFlags & nsMsgViewFlagsType::kThreadedDisplay)

given includeCollapsedMsgs is the significant go-no-go for this if statement, I think it should be listed first or just after NS_SUCCEEDED.

>+  if (numIndices != numMsgs)
>+  {
>+    const char *warnPref = "mail.warn_on_collapsed_thread_operation";
>+    PRBool shouldWarn = PR_FALSE;
>+    nsCOMPtr<nsIPrefBranch> prefBranch(do_GetService(NS_PREFSERVICE_CONTRACTID, &rv));
>+    NS_ENSURE_SUCCESS(rv, rv);
>+
>+    prefBranch->GetBoolPref(warnPref, &shouldWarn);
>+   if (shouldWarn)
>+   {
>+     nsCOMPtr<nsIPrompt> dialog;
>+

nit: indentation wrong in this section.

>+     dialogTitle.Adopt(GetString(NS_LITERAL_STRING("applyToCollapsedMsgsTitle").get()));
>+     confirmString.Adopt(GetString(NS_LITERAL_STRING("applyToCollapsedMsgs").get()));
>+     checkboxText.Adopt(GetString(NS_LITERAL_STRING("applyToCollapsedAlwaysAskCheckbox").get()));
>+     buttonApplyNowText.Adopt(GetString(NS_LITERAL_STRING("applyNowButton").get()));

These strings are missing from this patch.

>+    nsIMsgFolder *curFolder = m_uniqueFoldersSelected[folderIndex];
>+    nsCOMPtr<nsIMutableArray> msgHdrsForOneFolder(do_CreateInstance(NS_ARRAY_CONTRACTID));

I know this is just moved code, but we should be checking it for success.

This seems to be working well, but I'd just like to see it again with the strings in place.
Attachment #377685 - Flags: review?(bugzilla) → review-
I haven't included suite strings because SM can do that if they decide to turn this on...
Attachment #377685 - Attachment is obsolete: true
Attachment #378608 - Flags: review?(bugzilla)
Comment on attachment 378608 [details] [diff] [review]
fix addressing comments, and including strings

>+++ b/mail/locales/en-US/chrome/messenger/messenger.properties
>@@ -484,6 +484,11 @@ headerFieldYou=You
> # The what's new tab title, shown on version update
> whatsNew=What's New
> 
>+applyToCollapsedMsgsTitle=Confirm Delete of Messages in Collapsed Thread(s)
>+applyToCollapsedMsgs=Warning - this will delete messages in collapsed thread(s)
>+applyToCollapsedAlwaysAskCheckbox=Always ask me before deleting messages in collapsed threads
>+applyNowButton=Apply
>+

SeaMonkey needs these as well (should someone flip the pref), please apply to suite/locales/en-US/chrome/mailnews/messenger.properties as well.

r=Standard8 with that fixed.
Attachment #378608 - Flags: review?(bugzilla) → review+
This seems like something we should have tests for. I guess some of it could be done at unit test level, however having litmus tests with a plan similar to comment 41 would be a good first step.
Flags: in-litmus?
Whiteboard: [testplan] [needs review from standard8] → [testplan]
Target Milestone: Thunderbird 3.0rc1 → Thunderbird 3.0b3
(In reply to comment #1)
> FWIW, several of the deps of bug 236849 would be resolved by fixing this.

Joshua can you go thru the list and close those that need be ?
fix checked in - on we go to bug 454829
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Can't we get some plural love instead of strings like "Thread(s)" here?
(In reply to comment #41)
> Suggested test plan:
> 
> 2 threads of 4 messages each.
> 
> Collapsed Thread feature ON
> Selected and deleted:Expected action
> 
> One collapsed thread: Thread deleted

https://litmus.mozilla.org/show_test.cgi?id=7729

> Two collapsed theads: Two threads deleted 


https://litmus.mozilla.org/show_test.cgi?id=7730

> One collapsed thread, top message in open thread:Collapsed thread deleted, top
> message deleted in open thread, 3 remaining



https://litmus.mozilla.org/show_test.cgi?id=7731

> Top message in two open threads: Selected messages deleted, no more, 3 left in
> each


https://litmus.mozilla.org/show_test.cgi?id=7732

> Collapsed Thread feature OFF
> One collapsed thread: exposed (top) message deleted (3 left)


https://litmus.mozilla.org/show_test.cgi?id=7734

> Two collapsed threads: each exposed (top) message deleted (3 left in each
> thread)

https://litmus.mozilla.org/show_test.cgi?id=7735

> One collapsed thread, top message in open thread: exposed (top) message deleted
> and top message deleted in open thread


https://litmus.mozilla.org/show_test.cgi?id=7736

> Top message in two open threads: Selected messages deleted, no more.

https://litmus.mozilla.org/show_test.cgi?id=7737
Flags: in-litmus? → in-litmus+
Depends on: 495665
No longer depends on: 495665
Depends on: 496045
Depends on: 500216
Duplicate of this bug: 214111
I see this bug again in Thunderbird 17.0.8 (and earlier probably). I have to  expand the thread and select all the emails to be able to apply any action on all the thread (instead of being able to collapse it and delete/move it). 

This issue has been going on for 12 years, I see from bug 65111.
I'd add my 0.02. Select thread should be available also from filters. At this time, by filter one can only delete a message, but not an entire thread.
You need to log in before you can comment on or make changes to this bug.