201898 - Too Easy to accidently drag Toolbar Bookmark folders

Status: RESOLVED FIXED

(Camino Graveyard :: Toolbars & Menus, defect)

Description

[Brian Zappia]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4a) Gecko/20030327 Chimera/0.7+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4a) Gecko/20030327 Chimera/0.7+

I make extensive use of toolbar bookmark folders.  Since I began using 7.0+
builds of Camino, I have accidently dropped one folder into another about a
dozen times when all I wanted to do was access a bookmark in the dropdown menu
from the folder.  I use a trackpad which tends to make this sort of thing more
likely.  I don't know what has changed since 7.0, but this did not happen prior
to that.

Reproducible: Sometimes

Steps to Reproduce:

Comment 1

[Chris Casciano]

related to bug 171852. being able to drag things out of the folder would remedy
this as a "bug" as well but I didn't see that filed on first glance.

dunno what else would remedy this

Comment 2

[Kathleen :Brade]

-->pinkerton

Comment 3

[Mike Pinkerton (not reading bugmail)]

-> simon for fix before 1.0

Comment 4

[Jasper]

Could this bug be confirmed then?

Comment 5

[Chris Casciano]

sure

Comment 6

[Simon Fraser [no longer active]]

Our toolbar folder drag and drop code behaves very similarly to Safari's: do you
have the same problems there?

Comment 7

[Jasper]

The nasty thing with the Camino code is that when you grab the folder and
slightly move it to the right, over either a bookmark or a folder before the
folder turns grey, it will move/snap all the way to right side of the toolbar.
Camino also alows it's user to drop a folder in a folder which may is also
nasty. It regularly hapens to me that in a hurry I drop a folder inside another
while atually wanted to open a bookmark in the fisrt folder. Safari doesn't alwo
users to drop folders inside folders in the bookmarks bar.

Camino also does allows a user to drop a folder inside a tab or the tab bar,
letting us think something is going to happen, which is nasty to (in the new
bookmarsk syetem code by david he lets you drop a folder from the toolbar on the
tab bar which even worse opens all those bookmarks in that folder).

My best guess is that the bookmarks toolbar should behave as much as a regular
toolbar as it ever can and that also includes having those arrow when the items
overflow. And allowing only drag and drop for simple rearangement a la safari.

Comment 8

[Kenneth Lu]

Simon, here's how Camino's current implementation differs from (and is inferior
to) Safari's.  (I also suggest a compromise below that would make it better than
Safari's.)


One key difference is that Safari has the down-arrow next to folders which has
different behavior from the folder name.

If you drag a folder's name, it rearranges the folder, and you have hold or
single-click to drop the menu down.

However, if you drag on the ARROW icon, Safari IMMEDIATELY drops the content
menu down, as in the older Camino behavior.  Thus, the user at least as an
option for immediate content access.

With bookmark toolbar folders, I imagine users want to access the contents the
vast majority of the time and only want to rearrange rarely, so content access
should be the priority, I think.

Even in Safari, rearranging is easier than content access, and I think that's
wrong, (I prefer the old days when only command-dragging would rearrange) but at
least you CAN get immediate content access with the arrow icon.


Suggested compromise:

Camino, unlike Safari, displays a folder icon.  Why not use that?  I suggest: 
Dragging the folder ICON rearranges, but dragging on the NAME immediately drops
down the contents as if it were a normal menu.

That would be even better than Safari, imho.

One possible objection is that users might expect the same behavior for names
and their icons, but there is precedent in the case of window titlebar proxy
icons and address bar proxy icons for icons having different behavior from their
names, so I think this will be fine if we just think of those icons as proxy icons.


P.S.: I considered a comparison to Dock folder icon behavior.  They also
prioritize rearranging over content access, but again, there's an alternative: 
You can right/control-click folder icons in the Dock and get immediate access
that way.  Camino has other stuff it puts in the contextual menu though, so it
can't really use this.

Comment 9

[Kenneth Lu]

I've recently noticed another manifestation of this bug... which may or may not
count as a new bug:

1) Click on a folder in the bookmarks toolbar.  This will pull down a menu.

2) Click down in the body of the window (not in the menu) and drag.  Note that
although the mousedown is happening nowhere near the folder, the folder icon is
being dragged.  What should happen is that the drag should either have no
effect, or it should be affecting the content of the window (selecting text, for
instance).

What often happens is that I click on a folder to pull down a menu, then,
deciding not to use it after all, I click elsewhere to cancel... But when I'm
using my trackpad, I often accidentally drag a little, and this causes me to
unintentionally drag the folder icon... into the window.. thus opening all the
folder's bookmarks as tabs in the current window... which clobbers any tabs I
already have open.

Comment 10

[Jasper]

Might I note that Camino pops on me if I accidentaly drop a folder with a lot of
bookmarks on the page view area. Or at least it will load some of the tabs and
then I get the pizza weel which then then makes Camino pop.

Comment 11

[Jasper]

The issue that makes thi as worse as it is is caused by this:

- open a bm bar folder by clicking on it
- move your mouse around the popedup menu
- now place your mouse uotside of the menu
- click and drag your mouse
-> you will notice that now the folder is dragged into the html view which could
cause some major crash if there are many bm in the folder.

Comment 12

[Stuart Morgan]

Upgrading bug severity and nominating for 0.9.  The accidental losing of a
folder inside another is annoying but minor, but the issue of comments 9-11 is a
real problem. It's a definite bug, and while it's minor in the best case, it's
really bad in the worst case (as Jasper pointed out).

Comment 13

[Stuart Morgan]

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

Comment 14

[Peter Yang]

I actually like having this feature; I use it all the time to open bookmark
folders, and I don't experience the crash that others do (although I don't have
more than 10 bookmarks or so in any of my folders).

My issue is that after all the tabs load successfully (i.e. the HTML has been
rendered but Camino is still waiting on images and etc.), it displays the folder
drag two more times. This means that after all the tabs are processed, if my
mouse is in the HTML area, it will reload all the tabs again... and again.

I can prevent this by moving my mouse up as soon as I drag the folder into the
HTML area.

Comment 15

[ender.mb]

A couple other issues that I don't believe have been mentioned yet:

- it's impossible to drag a folder on the bookmarks toolbar in between two other
folders. It either goes into one of the other folders or to the end of the toolbar.
- (this is more of a nit-pick) the text from dragged bookmarks, folders, and
page proxies switches to Helvetica instead of retaining the font that it has in
the toolbar/tab/etc.

I agree that the issue described in comments 9-11 is very annoying.. I think an
"open in tabs" menu item a la firefox, omniweb, safari, etc. would be a much
better way to get bookmark tabs ;) I think there's another bug for that already
though so I'll stop now.

Comment 16

[Jasper]

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

Comment 17

[Josh Aas]

Attachment: fix the worst part of the problem v1.0

This is a hack that keeps track of what happened before any drag. There doesn't
seem to be a better way to fix this since a click is getting sent to a view its
not on and I don't know why.

Comment 18

[Ludovic Hirlimann [:Usul]]

Comment on attachment 164505 [details] [diff] [review]
fix the worst part of the problem v1.0

Also tested on 10.2.8 without any problems.

Comment 19

[Geoff "temporarily off bugmail" Beier]

Comment on attachment 164505 [details] [diff] [review]
fix the worst part of the problem v1.0

looks good and works as described. r=[e-mail]

Comment 20

[Jasper]

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

Comment 21

[Mike Pinkerton (not reading bugmail)]

can you explain to me how this works around the issue? i'm not seeing it.

Comment 22

[Josh Aas]

Right click on a folder containing some bookmarks in your bookmark bar. Move the
mouse outside of the menu that comes up and click/drag. Even though the menu is
up this will initiate a drag and probably drop the folder into the content area.
It isn't the desired behavior, and people end up accidentially opening all
bookmarks in the folder.

Comment 23

[Josh Aas]

-    DraggableImageAndTextCell* newCell = [[[DraggableImageAndTextCell alloc]
init] autorelease];
+    DraggableImageAndTextCell* newCell = [[DraggableImageAndTextCell alloc] init];
     [newCell setDraggable:YES];
+    [newCell setWraps:YES];
     [self setCell:newCell];
+    [newCell release];

These changes should not be in the patch. I accidentally left them in from when
I was messing with something else.

Comment 24

[Mike Pinkerton (not reading bugmail)]

> @@ -207,6 +211,7 @@
>    NSPopUpButtonCell	*popupCell = [[NSPopUpButtonCell alloc] initTextCell:@""
pullsDown:YES];
>    [popupCell setMenu: popupMenu];
>    [popupCell trackMouse:event inRect:[self bounds] ofView:self untilMouseUp:YES];
> +  lastEventWasMenu = YES;
>    [popupCell release];
>    [bmMenu release];
>    [popupMenu release];

why is this set here? it doesn't seem like it would do anything (set after the
tracking has stopped).

Comment 25

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 164505 [details] [diff] [review]
fix the worst part of the problem v1.0

sr=pink

do you want to land those cell changes that shouldn't be part of this patch?
prolly not for now. also, we should land this on 0.8.2, and in that case, we
don't want those extra cell changes.

put up a new patch and we can xfer over the r's/sr's to it and evaluate it for
082.

Comment 26

[Josh Aas]

Attachment: patch v2.0

Please transfer reviews.

Comment 27

[Josh Aas]

landed patch v2.0 on trunk. close this bug when reviews are transferred and
we've decided if we want this on the branch.

Comment 28

[Josh Aas]

I recommend not landing this on the branch. This code has changed quite a bit
and the fix is not critical in any way. Thoughts so we can close this?

Comment 29

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 165874 [details] [diff] [review]
patch v2.0

sr=pink, yes, we want this on the branch.

Comment 30

[Josh Aas]

landed on branch