117954 - Auto-close springloaded folders except the destination folder

Status: VERIFIED FIXED

(Core :: XUL, enhancement)

Description

[Quinn Yost (mythdraug)]

While cleaning up my inbox.  I found muself wishing that after
releasing messages into a folder the tree that had sprung open
would close itself. 

eg.
Before:
 v-Inbox
 |-Sent
 |-Trash
 >-Personal
 >-Work
  

During:
 v-Inbox
 |-Sent
 |-Trash
 >-Personal
 v-Work
 | v-Staff
 | | |-Foo
 | | |-Bar
 | | +-Jones
 | >-Support
 >-Personal


After:
 v-Inbox
 |-Sent
 |-Trash
 >-Personal
 >-Work

Comment 1

[John Morrison]

.

Comment 2

[Jesse Ruderman]

I think it's better to leave the folder open.  If you're dragging several items 
into one folder, it would be annoying if you had to trigger the springload 
feature multiple times.  I don't use mozmail or bookmark manager often, though, 
so I don't know whether that's more common than dragging a single item 
somewhere and then forgetting about it.

Comment 3

[Quinn Yost (mythdraug)]

My personal behavior when cleanig my inbox is to first sort
by sender. Then I select all the messages from that sender
and drag them enmasse to the destination folder.

Keep in mind I'm not advocating closing all your folders,
just the ones that opened on mouseover.

Comment 4

[Pierre Chanial]

I think that all the UI can do should be possibly undone by the UI. 
CC'ing Jan Varga, since he has implemented this feature.

Comment 5

[Jan Varga [:janv]]

Actually not me, but Dean has implemented this feature.

So, you want to be able close containers on mouseover (maybe with ctrl key?)
Or you want outliner to remember all auto opened containers and then close them
after drag session ends ?

Comment 6

[Jan Varga [:janv]]

taking for now

Comment 7

[Quinn Yost (mythdraug)]

I was thinking of the latter case.  Remember all auto opened
containers and then close them after drag session ends

Comment 8

[Quinn Yost (mythdraug)]

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

Comment 9

[Matthew T (active 1999-2002)]

When you drop items in a sprung-open folder, that folder should *not* close by
itself -- both for the reasons given in comment 2, and because that's how native
spring-loaded folders work.

However, *during* the drag, sprung-open folders which you mouse out of should
spring closed again.

--> default owner

Comment 10

[Jan Varga [:janv]]

nominating for Buffy

Comment 11

[[e-mail] (gone - use [e-mail] instead)]

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

Comment 12

[[e-mail] (gone - use [e-mail] instead)]

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

Comment 13

[Paul Wyskoczka]

nsbeta1+/adt2 per the nav triage team.

Comment 14

[Jan Varga [:janv]]

taking

Comment 15

[Jan Varga [:janv]]

Attachment: proposed patch

This patch implements desired behaviour (I hope).
I had to add a new member variable |nsVoidArray mArray| which takes 8 bytes at
minimum.
This array stores indexes of spring loaded folders.
Is there a better solution ?

Comment 16

[:deanis74]

I don't think this should be changed on Windows.  Following the example of
Windows Explorer springloaded folders remain open regardless of whether
something is dropped on them.

Comment 17

[Peter Trudelle]

cc Patrice for UE input

Comment 18

[patrice caire]

I agree with comments #2 and #16. Users might not know/see in which folders
their mail went if the spring loaded folders close automatically. cc Jennifer
for input.

Comment 19

[Jan Varga [:janv]]

>Users might not know/see in which folders their mail went if the spring loaded
folders close automatically

They don't close all automatically, drop folder stays opened.

Comment 20

[jglick]

It could be odd for users to suddenly see their folders close and the folder
pane (for mail) 'jump' as it re-adjusts itself, without them actually having
done something to cause this. Its hard to say without actually seeing it.

The folders that were opened in the hierarchy to where the item was actually
dropped would stay open though, correct? So just folders the user might have
hovered over too long or opened in error (nope, not the folder i want...) would
get closed?

Comment 21

[Jan Varga [:janv]]

>its hard to say without actually seeing it.
I attached a patch to this bug which implements this behaviour.
Maybe Seth could apply it and show you how it works.

>The folders that were opened in the hierarchy to where the item was actually
>dropped would stay open though, correct? So just folders the user might have
>hovered over too long or opened in error (nope, not the folder i want...) would
>get closed?

Right, all automatically opened folders except the drop folder get closed.
I checked the Finder on Mac OS X and it works this way too.

Comment 22

[Jan Varga [:janv]]

Attachment: enhanced patch

this patch does the same as the previous one and additionally:
- closes folders after a delay, not immediately (after 1 sec at the moment)
- up/down autoscrolling is now dynamic, you can scroll up faster if you move
the mouse cursor higher and visa versa

Comment 23

[Jan Varga [:janv]]

Attachment: better one

I forgot to check all parent indexes in the hierarchy.

Comment 24

[:deanis74]

Comment on attachment 114880 [details] [diff] [review]
better one

This should not be the behavior on Windows.

Comment 25

[Jan Varga [:janv]]

jag, what do you think ?

Comment 26

[Jan Varga [:janv]]

Attachment: another one

Sigh, idle timers.
This one should work on windows too.

Comment 27

[Brian Ryner (not reading)]

Comment on attachment 114885 [details] [diff] [review]
another one

Maybe it would be better to use nsValueArray, so you don't have to cast back
and forth to pointer types?

Comment 28

[Jan Varga [:janv]]

Attachment: revised patch

Comment 29

[:deanis74]

Comment on attachment 116611 [details] [diff] [review]
revised patch

Where's the #ifndef XP_WIN?

Comment 30

[Jan Varga [:janv]]

Dean, why not on windows ?
Just because "it's not the behaviour on windows", we behave differently in other
places too, so why not ?
Is it your personal feeling or is it really bad from usability point of view ?

Comment 31

[:deanis74]

The place where people most like experience springloaded folders on Windows is
in Explorer.  We should behave like that.  Just because "we're different
elsewhere" doesn't mean we should be different if we can avoid it.

Comment 32

[Quinn Yost (mythdraug)]

While the final behavior has changed from my initial request, I would
still like to see this on Windows.

Comment 33

[jag (Peter Annema)]

I think we should mimic the platform behaviour. Windows (w2k) seems to keep all
sprung-open folders open, Mac OS X only keeps the one open you dropped into and
closes the ones you dragged over (except for the NeXT parallel columns view, it
acts like Windows for that case). What do Gnome and KDE specify for this (if
anything)? If no behaviour is specified, I would go with the Mac (not NeXT)
behaviour.

Comment 34

[Jan Varga [:janv]]

mkaply, do you want this behavior on OS/2 ?
what would be the #ifdef then ?

Comment 35

[Jan Varga [:janv]]

Dean, jag, thanks for your comments
Personally I don't care about windows behavior that much.
I just don't like additional #ifdefs in this code which make it less readable.

Comment 36

[Quinn Yost (mythdraug)]

I know I won't win any popularity votes by suggesting this...

But could this be pref'd with appropriate default settings for
the various platforms rather than a compile-time #ifdef?

Comment 37

[Mike Kaply [:mkaply]]

We wouldn't want this springloading on OS/2.

Comment 38

[Jan Varga [:janv]]

mkaply, you don't want spring loaded folders on OS/2 at all ?
This bug is about auto-closing of spring-loaded folders

Comment 39

[Mike Kaply [:mkaply]]

Sorry, this bug confused me. If by spring loading, you mean open when you drag,
heck yeah we want that.

Auto closing we don't want. That would be way confusing to the user.

Comment 40

[:deanis74]

Jan, if you don't want to ifdef the code you could either use nsILookAndFeel or
platform-specific default prefs.

Comment 41

[Jan Varga [:janv]]

Comment on attachment 116611 [details] [diff] [review]
revised patch

working on a patch that uses the nsILookAndFeel service

Comment 42

[Jan Varga [:janv]]

Attachment: patch that should make happy everyone

ok, so I changed all the code to use the nsILookAndFeel service.
I added these new metrics:
ui.treeOpenDelay = 1000
ui.treeCloseDelay = 1000
ui.treeLazyScrollDelay = 150
ui.treeScrollDelay = 100
ui.treeScrollLinesMax = 3

ui.treeCloseDelay is set to zero on Windows and OS/2, so auto closing is
completly disabled on these platforms.
I haven't checked if there are any platform specific APIs for such settings.
I think that's not important at the moment.

The cool thing about the nsILookAndFeel service is the ability to even override
these settings in prefs.js

Hope this is the last patch for this bug, I want to check it in finally.

Comment 43

[Jan Varga [:janv]]

Attachment: cosmetic changes

Comment 44

[:deanis74]

Thanks, Jan, this looks a lot better to me.

Comment 45

[OOO until Jun 29 - Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 117218 [details] [diff] [review]
cosmetic changes

sr=dmose

Comment 46

[Jan Varga [:janv]]

checked in

FYI, if you want to enable it on Windows, add this to your pref.js:
user_pref("ui.treeCloseDelay", 1000);

Comment 47

[R.K.Aa.]

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

Comment 48

[sairuh (rarely reading bugmail)]

this has been working fine for me using recent builds, so marking verified.