Closed Bug 214111 Opened 18 years ago Closed 12 years ago

Drag and drop only drags the top message from a collapsed thread


(Thunderbird :: Mail Window Front End, defect, P4)



(Not tracked)

Thunderbird 3.0rc1


(Reporter: ivg2, Unassigned)


(Blocks 1 open bug)


(Keywords: helpwanted)


(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030721 Mozilla Firebird/0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030721 Mozilla Firebird/0.6

Drag and drop (used for move) only drags the top message in a thread, even
when the thread is not expanded. This looks incorrect to me, as I would expect
the entire thread to be dragged. 

Reproducible: Always

Steps to Reproduce:
1.Collapse a thread of messages
2.Drag a thread to a different folder.
3.Only the top message is moved
Target Milestone: --- → After Thunderbird 1.
QA Contact: asa
Blocks: 236849
I'd like to add that I think the "pin" icon for a given thread should add the
thread to an existing selection when clicked upon -- i.e. I have a message
selected, and hold down Ctrl, and click the "pin", but only the top message in
the thread is added to the selection.

If it is clicked to create a new selection, it selects the entire thread.  This
would then be more consistent, ergo.

Not sure if these issues are related, but I'd rather not create another bug for
something in the same vein.
Recommend WontFix.  Drag-and-drop applies to selection.  Selection only applies 
to what you can see -- the thread must be expanded to be selected.  If you want 
the entire thread selected in a single action, click on the thread icon or use 
Edit | Select | Thread (Ctrl-Shift-A).

Comment 2 is about bug 88593, which has been fixed.
OS: Linux → All
Hardware: PC → All
IIRC, gmail has exactly this behavior.  And it certainly seems more intuitive to me.
Closing ancient bug.
Closed: 17 years ago
Resolution: --- → WONTFIX
Why exactly was this closed?
Resolution: WONTFIX → ---
- because it was recommended wontfix
- because it was opened 1.5 years ago, indicating that it's not getting fixed
- because the other few bugs I've ever filed with mozilla have been open
for several years too, and I just don't care anymore. I switched to evolution
a long time ago.

If you want the bug to stay open, then fine.
*** Bug 292749 has been marked as a duplicate of this bug. ***
I just had a try at fixing this, and failed.  Here are my (rambling) notes, for
the record:

This is actually really hard, as the way thread expansion/collapsing works in
nsMsgDBView is to completely remove headers from the threadpane when collapsed
('elided'), and then reinsert them back in when expanded by entirely requerying
the message db. Because nothing above the DAO level knows of the existence of
the collapsed messages, there's no way to maintain them as part of a selection.
There's nowhere to instantiate them if you want to access the messages without
displaying them on the threadpane. So as all selections are done by using
indices of headers on the threadpane, if the messages are collapsed, they simply
don't exist and can't be selected.

The solution to this is to rewrite the thread collapse/expansion code to keep
all message headers loaded at all times, but allow arbitrary ones to be hidden
(so allow non-consecutive threadpane indices). Or rewrite all the selection code
to refer to DB-level DAOs rather than UI-level threadpane indices. This is a
total redesign of how nsTree, nsTreeSelection and nsMsgDBView work, and would be
a major task (as well as lose the memory advantage of only loading expanded
threads on demand). Or a really horrible hack could be done to temporarily
special-case selections of collapsed threads as having negative threadpane
indices or something when doing nsMsgDBView::GetSelectedIndices(). But this ends
up being pretty much just as hard, and infinitely less elegant.

Alternatively, whenever a list of key indices is parsed into a bunch of URIs or
nsMsgHdrs for manipulation within Mozilla in nsMsgDBView (i.e.  for
(nsMsgViewIndex index = 0; index < (nsMsgViewIndex) numIndices; index++) { rv =
m_db->GetMsgHdrForKey(key, getter_AddRefs(msgHdr)); }  or
nsMsgDBView::GetURIsForSelection() ), the additional collapsed messages hidden
behind a given index should be expanded out by calling a variant on
ExpandByIndex(), a bit like this:

    if (m_viewFlags & nsMsgViewFlagsType::kThreadedDisplay) {
      if (m_flags[i] &
        // also snag the URI or keys for the collapsed children of this thread node

        nsCOMPtr <nsIMsgDBHdr> msgHdr;
        nsCOMPtr <nsIMsgThread> pThread;
        m_db->GetMsgHdrForKey(m_keys[index], getter_AddRefs(msgHdr));
        if (msgHdr == nsnull)
          NS_ASSERTION(PR_FALSE, "couldn't find message to expand");
          return NS_MSG_MESSAGE_NOT_FOUND;
        rv = GetThreadContainingMsgHdr(msgHdr, getter_AddRefs(pThread));
        PRUint32 numChildren;
        for (i = 1; i < numChildren; i++)
          nsCOMPtr <nsIMsgDBHdr> msgHdr;
          threadHdr->GetChildHdrAt(i, getter_AddRefs(msgHdr));
          if (msgHdr != nsnull) {
            // add msgHdr

Unfortunately, there are loads of places where a list of viewIndices (indices)
get expanded out into a list of actual messages - at least
GetURIsForSelection(), CopyMessages(), DeleteMessages(), DownloadForOffline(),
ApplyCommandToIndices(), and most importantly GetIndicesForSelection(), which is
called via XPCOM from JS. Whilst a few of these could be hacked like this to
silently expand out threads, the fact that the whole selection model revolves
around rows in the threadpane rather than actual messageids remains.

And so, the workaround is to manually expand collapsed threads to load them up
into the UI and thereby make them selectable before doing any operation on them.
The way you do this is to select the collapsed thread, and hit Ctrl-Shift-A
(Edit: Select: Thread). You can then do any bulk-operation on the thread to your
heart's desire, all for the price of a single key press. Right now, this seems
like an infinitely preferable option to rewriting the entire selection/tree model.
Duplicate of this bug: 378039
QA Contact: front-end
Karsten, this bug should either be wontfix or change to enh, no?
Bryan, dmose, need decision if this is appropriate behavior. If yes, then desirable for TB3
Flags: wanted-thunderbird3?
Attached image thread drag and drop
Yeah, I believe this is the correct behavior.  However we should have some kind of indication to the person that the whole thread is going to move.  Something like this mockup will probably be sufficient for now. 

Create a shadow of the drag target about 3 levels deep.  That should indicate that you're not just moving the individual message, but the thread as a whole.
looks good - addresses what I'm concerned about 
I agree that this change is The Right Thing (TM).  One thing I'm slightly concerned about is that existing users who have years of experience with the current mode will inadvertently delete / move some messages until they get used to this.  But I like the UI Bryan recommends a bunch, and that alleviates my concern somewhat.
Marking as wanted+ for now.  It might even be reasonable to make it block, since it feels like it would be a fairly noticable usability improvement to some relatively basic functionality.  Thoughts?

Matthew, thanks for the implementation notes; those are very helpful.
Flags: wanted-thunderbird3? → wanted-thunderbird3+
FWIW, I think that this behavior is the right thing, but it should also apply to other operations on collapsed threads, in particular delete, "move again", etc.  (not sure what the bug # on that is).

True; we probably need to make all such changes in the same release or risk serious confusion.
For the record, comment #17 is about bug 65111  (7 years old).  
My suggestions kind of tie these bugs together (this one and
Assignee: mscott → nobody
Keywords: uiwanted
Keeping wanted‑thunderbird3+. 
Keywords: uiwantedhelpwanted
Priority: -- → P4
Target Milestone: Future → Thunderbird 3.0rc1
I think some of this and bug 65111 are being picked up in bug 448288 Group actions on collapsed threads. (which doesn't have the "wanted" flag that this bug does)

it would be good to address bug 267618 at the same time - similar issue for "grouped" view
Blocks: 267618
should have been fixed by bug 448288
Closed: 17 years ago12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 448288
No longer blocks: 267618
You need to log in before you can comment on or make changes to this bug.