30861 - [RFE] Springloaded folders (drag-hover over bookmark folder should expand folder)

Status: RESOLVED FIXED

(Core :: XUL, enhancement, P3)

Description

[:deanis74]

I searched and searched and couldn't find a bug for this, so here it is.  When 
I'm managing bookmarks, either in Manage Bookmarks or the Bookmarks sidebar 
panel, I can drag-and-drop bookmarks all over the place, which is great.  But 
the limitation with this is with dragging a bookmark to a closed folder.

Expected Results: After a short delay (1 second?) while holding the bookmark 
over the folder, the folder expands and I can then drag the bookmark to wherever 
I want it to be.

Actual Resules: The only choice that I have is to drop the bookmark on the 
closed folder, and the bookmark is made the last item in the folder.

Build:2000030516

Comment 1

[Claudius Gayle]

confirmed. i would imagine that hovering over the triangle widget with a drag item would immediately open the folder as well.

Comment 2

[don]

Move to M21 target milestone.

Comment 3

[:deanis74]

Making a note for me to look into this sometime.  No promises, though.

Comment 4

[karlheg]

Also (M18) when you:

create three folders like:

One
 Two
Three

... then open One, as shown, and drag Three and drop it onto One.

What's wrong is that Three is not displayed until you close One then reopen it.

Comment 5

[Claudius Gayle]

you are correct and that is bug 36873, a separate issue.

Comment 6

[Blake Ross]

Reassigning 79 Bookmarks bugs to Ben.  I was told this was going to be done 
shortly about two months ago, but it clearly hasn't been.  I think that's long 
enough for all these bugs to remain assigned to nobody.

Feel free to filter all this spam into the trashcan by looking for this string 
in the message body: ducksgoquack

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

How hard is this?  It's one of those things people really expect from a UI these
days.

Comment 8

[Marcia Knous [:marcia]]

Netscape Nav Triage Team: adding German to the cc list to comment on whether 
this is a beta bug

Comment 9

[ratman]

not to be a total downer, but neither windows 95/98/2k/me nor mac os does this
with their tree programs.  suggest invalid, or enhancement at best.

Comment 10

[timeless]

iirc both windows and macos have spring loading for folder trees.
3s for explorer [ie5.5w2k].

Comment 11

[:deanis74]

You got it, timeless.

Comment 12

[Ben Goodger (use ben at mozilla dot org for email)]

update summary to reflect feature request. 

Comment 13

[Ben Goodger (use ben at mozilla dot org for email)]

this will become an outliner issue and isn't really bookmarks specific. 
Nonetheless -> Future

Comment 14

[Chris Lyon]

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

Comment 15

[Oliver Klee]

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

Comment 16

[Oliver Klee]

Updating summary from "[RFE] Springloaded folders in bookmarks" to "[RFE]
Springloaded folders" as per Ben's comment.

Comment 17

[Chris Lyon]

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

Comment 18

[Jesse Ruderman]

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

Comment 19

[Jesse Ruderman]

Copying my comment from bug 46807:

Outlook Express's version of this feature tries to make all of the subfolders 
visible by automatically scrolling the folder pane when it expands the folder.  
I don't like that part of OE's implementation because it often causes me to 
move a message to a subfolder of the folder I'm trying to drop it on.

Comment 20

[:deanis74]

The bookmarks window and sidebar still use trees.  If, as Ben says, this is a
general outliner issue, those need to be changed to use outliner before
spring-loading will work for those folders.  Is there a bug filed for that
conversion?

Comment 21

[Jesse Ruderman]

Dean: converting bookmarks to use outliner is bug 73508.  There's also a 
metabug for replacing trees with outliners throughout Mozilla (bug 73948).

Comment 22

[Peter Lairo]

For long bookmark lists (likely when opening subfolders), moving the dragged
curser to the top or bottom of the bookmarks list should scrool the list down or
up to access bookmarks beyond the visible screen.

Should I file a new bug on that, or can it be handled here? 

Comment 23

[:deanis74]

Patch coming that contains an initial implementation.  We may want to hook up 
an attribute on the outliner as to whether its folders are springloaded or not.

You can test this by dragging a mail message over the twisty of a collapsed 
mail account or mail folder.  You can't try this in bookmarks yet because of 
what I mentioned earlier.

I'm getting a lot of assertions when I drag a message below the tree, but I 
think that these were already there and are coming from somewhere else lower 
down in OnDragOver().

Comment 24

[:deanis74]

Attachment: cvs diff -u mozilla/layout/xul/base/src/outliner/src

Comment 25

[:deanis74]

Jesse: I just left the expanding up to the default way that Outliner does it. 
From playing around with the Mail folder pane, the folder list doesn't
automatically scroll.

Peter: that should be handled by the move of bookmarks to Outliner (bug 73508).
 Try that in the Mail folder pane, it works well for me.

Comment 26

[:deanis74]

Hmmm... my patch does this so you have to drag over the twisty itself.  It
should probably be the twisty or the folder.

Comment 27

[Andrew Thompson]

The twisty, the folder icon or the folder name please!

Comment 28

[:deanis74]

Attachment: take 2

Comment 29

[:deanis74]

This version allows you to drag over any part of the row.  In a threaded 
message pane, that gives you a large target.  (and with less code than the 
first patch!)

Playing around with it a little more, I don't think it's necessary right now to 
have an option on each outliner as to whether its folders are springloaded.  So 
what if you can drag messages to open threads in the message pane?  Maybe I 
want to open a thread on my way to dragging a message to a local folder.  We 
give good feedback with the cursor as to whether the message is droppable or 
not.

Given that opinion, anyone care to review?

Comment 30

[:deanis74]

Hyatt, Ben, Hewitt, anyone... any comments?

Comment 31

[laurel]

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

Comment 32

[:deanis74]

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

Comment 33

[Ben Goodger (use ben at mozilla dot org for email)]

Paul Chen is now taking Bookmarks bugs. For your convenience, you can filter 
email notifications caused by this by searching for 'ilikegoats'.

Comment 34

[:deanis74]

This bug isn't specific to bookmarks, it's an outliner enhancements.  Over to
hyatt (or should that be hewitt?).

Comment 35

[David Hyatt]

sr=hyatt, but please change 

if ( expr )

to

if (expr)

Comment 36

[:deanis74]

Argh.  Can I just hand-edit the patch to make those changes?  My tree's really 
messed right now.

Comment 37

[:deanis74]

Comment on attachment 50837 [details] [diff] [review]
take 2

Forget it, I've re-pulled half my tree.  New patch coming shortly.

Comment 38

[:deanis74]

Attachment: cvs diff -u /mozilla/layout/xul/base/src/outliner/src

Comment 39

[:deanis74]

New patch, updated against latest version of trunk files and remove extra spaces
as requested by hyatt.  Need an r=, please.

Comment 40

[Joe Hewitt (gone)]

Comment on attachment 55435 [details] [diff] [review]
cvs diff -u /mozilla/layout/xul/base/src/outliner/src

r=hewitt

Comment 41

[:deanis74]

Hyatt, can I get some sr-loving on my new patch before it becomes out of date?

Comment 42

[:deanis74]

Targetting for next milestone.

Comment 43

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 55435 [details] [diff] [review]
cvs diff -u /mozilla/layout/xul/base/src/outliner/src

sr=[e-mail].

Comment 44

[:deanis74]

Comment on attachment 55435 [details] [diff] [review]
cvs diff -u /mozilla/layout/xul/base/src/outliner/src

new patch coming with slightly better logic.

Comment 45

[:deanis74]

Attachment: new patch

Logic simplified a little.  Changed

+    if (mOpenTimer && mOpenTimerRow == newRow) {
+      // already have an active timer for this row - do nothing
+    } else {

to

+    if (!mOpenTimer)

and expanded a couple of the comments.

Comment 46

[:deanis74]

I don't want to push this off for another milestone just because I can't get
that simple logic change super-reviewed.  Can someone help a guy out?

Comment 47

[:deanis74]

Brendan tells me, in bug 94980, that I don't need re-review if there weren't
substantial changes between patches.  The changes were pretty minor, and
timeless gave an r= since he was the one that raised the issue.

To me, that's good enough.  Anyone care to check this in?

Comment 48

[:deanis74]

checked in

Comment 49

[Jan Varga [:janv]]

nice enhancement dean!

Comment 50

[Peter Lairo]

I'm using: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.6+) Gecko/20011210

This is an excellent feature - WOOHOO, YEAH. However, I have noticed some issues
that may require reopening this bug (or filing new ones?):

1. Folder springloads only *two* layers deep. If you have 3+ layers of
subfolders (I have a *lot* of these), you cannot reach them with the current patch.

2. The visual indicator of which folder one is hovering over is an *underline*
below the hovered folder. This gives the impression that the dropped bookmark
will go to where the underline is, and not onto the subfolder that just sprung
open. Of course this may be desired (how else could one place a BM directly
below a subfolder?). but...

3. Similar to 2 - It is not possible to place a BM *above* a hovered folder or BM.

To fix 2 and 3, maybe the placement/sprininging should depend on *where* the
curser is vertically.

- If it is in the *top one-fourth* of a line (BM or folder), then the BM should
be placed *above* the hoverd BM/folder (and the horiz. line should indicate this
by being above that BM/folder).

- If it is in the *center two-fourths* of a line (BM or folder), then the BM
should be placed *inside* the hoverd folder (and there should be *no* horiz. line).

- If it is in the *bottom one-fourth* of a line (BM or folder), then the BM
should be placed *below* the hoverd BM/folder (and the horiz. line should
indicate this by being below that BM/folder).

In all cases, if the hovered object is a folder, it should spring open to allow
placement into the subfolder.

Comment 51

[Tim Powell]

I believe that 1 is described in bug 100479. Actually, I'd say that bug 100479 
is a duplicate of this one. Dean, thanks for the nice enhancement! Can you get 
the nested subfolders to expand automatically, too, please?

Comment 52

[Peter Lairo]

Another important reason this bug is not "fixed" yet:

There are at least 5 dupes that all request that *any* folder (not just
bookmarks in toolbar") open when hovered over. 

These are (at least):
- sidebar bookmarks
- personal toolbar bookmarks
- mail/nes folders when dragging messages

If you decide to reopen (un-dupe) any of the duped bugs, please announce it
here, since many of those reporters were hoping for much more than was fixed here ;)

Therefore, please *reopen* this bug.

Comment 53

[:deanis74]

"Folder springloads only *two* layers deep. If you have 3+ layers of
subfolders (I have a *lot* of these), you cannot reach them with the current patch."

Hrm.  File a new bug against me.

"The visual indicator of which folder one is hovering over is an *underline*
below the hovered folder.  etc."

I didn't change any of the code to do with the visual indicator.  I only care if
the folder's selected.  I think there may already be a bug on the indicator
somewhere.

"There are at least 5 dupes that all request that *any* folder (not just
bookmarks in toolbar") open when hovered over."

This fix applies to outliner, not to bookmarks.  Anything that uses outliner
(folder pane, message thread list, sidebar bookmarks, history, etc.) now has
this functionality.

"Actually, I'd say that bug 100479 is a duplicate of this one."

Nope, 100479 has to do with the personal toolbar and whatever menu-ish things
are used there.  This change was to outliner.

"Can you get the nested subfolders to expand automatically, too, please?"

Meaning that all sub-folders within the folder automatically expand?  Ugh.  That
would be very annoying, and isn't like any tree view I've seen.

Comment 54

[Peter Lairo]

> This fix applies to outliner, not to bookmarks.  Anything that uses outliner
(folder pane, message thread list, sidebar bookmarks, history, etc.) now has
this functionality.

Maybe I am not understanding the obvious, but neither folder pane nor sidebar
bookmarks work on my installation (build 2001-12-10, winNT) :(

If I drag the grippy from the url-bar to tmy "sidebar bookmarks", none of the
folders open up :(

If I drag an e-mail to a closed local folder ("folder pane"?!), it doesn't open
up :(

Am I missing something here?

Comment 55

[Peter Lairo]

OK, I've also filed a bug on the "3 subfolders deep not auto-opening" issue -
bug 114638

Comment 56

[:deanis74]

I missed something when reading your prior comment, Peter.  This won't show up
in 12-10 builds, but look for it in 12-11.

Comment 57

[Martin Poirier]

I just wish the springload would be a little quicker (i.e. reduce the latency
time for the folder to open). Can this be done easily?

Comment 58

[Peter Lairo]

No, quicker opening would cause every folder to open when passing over it. There
needs to be a noticable delay; especially, since all opened folders must later
be *manually* closed.

At most, maybe the opening delay could be reduced by a fraction of what it is
now (1/4, 1/3,...)

Comment 59

[GA]

After review of functionality, why doesn't the auto-expand work on folders
located on personal toolbar??  Personally, I have multi-tiers of bookmark folers
located on Mozilla toolbar.   These folders don't seem to benefit from
auto-expand feature (no I don't use the side-bar).  I'm using bld
#2001121203/wintel. -GA

Comment 60

[:deanis74]

Why?  Because you didn't read any of the comments in this bug, obviously.  You
want bug 100479.

Comment 61

[mike lima]

I think it would be nice if the folder structure returns to the previous stade
after drop.  I mean, you drag over, the folder open, you drop, the folder close.
 It could be even valid for folders inside folders, like in MacOS...  :-)

Comment 62

[Christopher Lam]

Seconded. With a springloaded folder I would expect the folder to "spring" back 
to its original shape, which is what I expected this feature to be.

Still a very nice piece of work, and well thought out (and implemented).

RFE: Spring-close folder back when the mouse button is released.

Comment 63

[Jesse Houwing]

This really should also be implemented for the Personal bookmarks toolbar.

Comment 64

[Andrew Thompson]

2 quick notes:

On mac os, the *last* folder where the message/item is actually dropped remains 
open. All of the intervening folders close (this is assuming we're talking about 
regular folder windows). If you're trying to visualize this on a tree - don't, a 
tree can't do this...

However, I'm not sure that does apply since we're talking about a tree not a set 
of disk folders. In 4.X mailnews on mac os, the folders do not close when the 
drop is made. Actually, I can't think of a "springloaded" tree implementation 
I've used where they do close. (eg, I'm pretty convinced that they don't in MS 
Outlook, but I don't have it on this machine to test). I vote for consistency 
with other apps.

Comment 65

[Nicholas Riley]

On the Mac (8.0-9.2 Finder, sigh), you can press the space bar to
spring open a folder immediately instead of waiting for the hover
delay.  It seems this kind of behavior could be useful here too.
Having a shorter delay is pretty annoying IMHO, because you can often
pause over a folder for quite a while trying to figure out which one
you want to pick.

Comment 66

[Matt Chaput]

Regarding a method for shortcutting the delay: the MacOS spacebar trick is nice,
and Mac people might think to try it, but it's pretty non-obvious functionality.
SLIGHTLY more discoverable is the earlier suggestion that dragging over the
disclosure triangle shortcut the delay. I'd vote for that before the spacebar
(but for both if they can both be done ;)

Comment 67

[:deanis74]

This RFE has been fixed.  Please continue UI discussions in the newsgroup or
file new RFEs.

Comment 68

[Brant Gurganus]

[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.