Closed Bug 30861 Opened 24 years ago Closed 23 years ago

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

Categories

(Core :: XUL, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
mozilla0.9.7

People

(Reporter: deanis74, Assigned: deanis74)

References

Details

(Keywords: polish)

Attachments

(1 file, 3 obsolete files)

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
confirmed. i would imagine that hovering over the triangle widget with a drag item would immediately open the folder as well.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → M18
Move to M21 target milestone.
Target Milestone: M18 → M21
Making a note for me to look into this sometime.  No promises, though.
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.

you are correct and that is bug 36873, a separate issue.
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
Assignee: slamm → ben
How hard is this?  It's one of those things people really expect from a UI these
days.
Keywords: mozilla1.0, polish
Netscape Nav Triage Team: adding German to the cc list to comment on whether 
this is a beta bug
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.
iirc both windows and macos have spring loading for folder trees.
3s for explorer [ie5.5w2k].
You got it, timeless.
update summary to reflect feature request. 
Summary: Drag of bookmark to a closed folder should expand the folder → [RFE] Springloaded folders in bookmarks
this will become an outliner issue and isn't really bookmarks specific. 
Nonetheless -> Future
Status: NEW → ASSIGNED
Target Milestone: --- → Future
*** Bug 89920 has been marked as a duplicate of this bug. ***
*** Bug 90137 has been marked as a duplicate of this bug. ***
Updating summary from "[RFE] Springloaded folders in bookmarks" to "[RFE]
Springloaded folders" as per Ben's comment.
Summary: [RFE] Springloaded folders in bookmarks → [RFE] Springloaded folders
*** Bug 101446 has been marked as a duplicate of this bug. ***
Summary: [RFE] Springloaded folders → [RFE] Springloaded folders (drag-hover over bookmark folder should expand folder)
*** Bug 46807 has been marked as a duplicate of this bug. ***
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.
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?
Dean: converting bookmarks to use outliner is bug 73508.  There's also a 
metabug for replacing trees with outliners throughout Mozilla (bug 73948).
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? 
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().
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.

Hmmm... my patch does this so you have to drag over the twisty itself.  It
should probably be the twisty or the folder.
The twisty, the folder icon or the folder name please!
Attached patch take 2 (obsolete) — Splinter Review
Attachment #50678 - Attachment is obsolete: true
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?
Keywords: patch, review
Hyatt, Ben, Hewitt, anyone... any comments?
*** Bug 103552 has been marked as a duplicate of this bug. ***
*** Bug 104004 has been marked as a duplicate of this bug. ***
Paul Chen is now taking Bookmarks bugs. For your convenience, you can filter 
email notifications caused by this by searching for 'ilikegoats'.

Assignee: ben → pchen
Status: ASSIGNED → NEW
This bug isn't specific to bookmarks, it's an outliner enhancements.  Over to
hyatt (or should that be hewitt?).
Assignee: pchen → hyatt
Component: Bookmarks → XP Toolkit/Widgets
QA Contact: claudius → jrgm
sr=hyatt, but please change 

if ( expr )

to

if (expr)
Argh.  Can I just hand-edit the patch to make those changes?  My tree's really 
messed right now.
Comment on attachment 50837 [details] [diff] [review]
take 2

Forget it, I've re-pulled half my tree.  New patch coming shortly.
Attachment #50837 - Attachment is obsolete: true
New patch, updated against latest version of trunk files and remove extra spaces
as requested by hyatt.  Need an r=, please.
Assignee: hyatt → dean_tessman
Comment on attachment 55435 [details] [diff] [review]
cvs diff -u /mozilla/layout/xul/base/src/outliner/src

r=hewitt
Attachment #55435 - Flags: review+
Hyatt, can I get some sr-loving on my new patch before it becomes out of date?
Status: NEW → ASSIGNED
Targetting for next milestone.
Target Milestone: Future → mozilla0.9.7
Comment on attachment 55435 [details] [diff] [review]
cvs diff -u /mozilla/layout/xul/base/src/outliner/src

sr=ben@netscape.com.
Attachment #55435 - Flags: superreview+
Comment on attachment 55435 [details] [diff] [review]
cvs diff -u /mozilla/layout/xul/base/src/outliner/src

new patch coming with slightly better logic.
Attachment #55435 - Attachment is obsolete: true
Attached patch new patchSplinter Review
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.
Attachment #57741 - Flags: review+
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?
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?
checked in
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
nice enhancement dean!
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.
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?
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.
"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.
> 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?
OK, I've also filed a bug on the "3 subfolders deep not auto-opening" issue -
bug 114638
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.
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?
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,...)
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
Why?  Because you didn't read any of the comments in this bug, obviously.  You
want bug 100479.
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...  :-)
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.
This really should also be implemented for the Personal bookmarks toolbar.
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.
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.
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 ;)
This RFE has been fixed.  Please continue UI discussions in the newsgroup or
file new RFEs.
[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.
Severity: normal → enhancement
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: