86258 - If selection is inside branch, collapsing branch should select parent

Status: RESOLVED WORKSFORME

(Core :: XUL, defect)

Description

[Justin H.]

When collapsing a threaded view, and one of the items down in the thread 
is selected, the top item in the thread should become active.  For instance, in 
mail/news when reading down a thread and you use the triangle to collapse the 
thread, whichever post you collapsed the thread from should become selected and 
active.

Sorry, but it's a comfort thing for me.  Besides, this is how all tree view or 
threaded views have acted on all platforms that I've seen. :-)

Note:  this applies to the list of components in the prefs panels, too.

Comment 1

[Keyser Sose]

Marking NEW.

Comment 2

[Matthew T (active 1999-2002)]

4.x for Mac doesn't select the parent message -- it clears the newly-hidden
selection, which blanks the message pane (mildly annoying). Windows Explorer
behaves as you describe -- the parent item is selected. And the Mac OS Finder
clears the selection, and does not select the parent item.

The suggested behavior has the potential for dataloss: if I select multiple
messages prior to deleting them, one of which is inside an expanded thread, and
then I collapse the thread (perhaps as an alternative to scrolling to find the
next message I want to select), then I'll inadvertently end up deleting the
whole thread.

So, I think this should only apply if the selection is entirely inside a
collapsed branch. If one or more items outside the branch are selected, the
items inside the branch should be removed from the selection. (The blanking of
the message pane does not apply in that case, as it will already be blank.)

--> XP Toolkit/Widgets: Trees.

Comment 3

[Justin H.]

You touched on one of the (many) spots I don't have experience with.  Perhaps
I'm thinking of the 4.x prefs panel when thinking about that platform.

When you talk about deleting a thread accidentally, I assume you mean in Mail
view, not in News?  If so, is there a way to exclude Mail accounts specifically
from this behaviour?  Unless I'm missing something, that's the only place this
sort of data loss can occur.  Besides, the Trash folder is there to reduce the
chances of data loss in that case.  I don't know if I'm indulging in wrong
thinking here, or not, so I'd appreciate any comments. 

As for the finder on Mac, isn't that a slightly different situation?  It's a
single frame view.  Updating the current selection isn't as important.  Kind of
nit-picky, I know, but it makes a difference, IMO.

Comment 4

[Jesse Ruderman]

*** Bug 70163 has been marked as a duplicate of this bug. ***

Comment 5

[Jan Varga [:janv]]

I think I fixed this long time ago.
Could someone verify ?

Comment 6

[John Levon]

This seems to work, but there is some strange behaviour concerning
the message filtering "View unread only": closing a thread with a selected
item that is about to disappear from the list, because it's been read, will
not select the head item, iff there is another "outside item" selected.

Linux trunk from a couple of days ago.

e.g. :

A
\--B
\--D
C

All are unread.

Select C, then use Control-click to select B. Now close A. A and C will be
selected. Re-open A. Remember A and B should be still unread, and A and C
are still selected. Now click on B, then control-select C, and collapse
A. C will still be selected, but /A will not be/

Now select D only, and collapse A. A will be selected.

Again, this is with View->Messages->Unread.

This is probably another bug though ... know which one ?

Comment 7

[Jan Varga [:janv]]

bah, I have no idea about this one.
File a new bug if there is no such bug already filed.

Comment 8

[John Levon]

bug 151611