Too Easy to accidently drag Toolbar Bookmark folders

RESOLVED FIXED in Camino0.9

Status

Camino Graveyard
Toolbars & Menus
RESOLVED FIXED
15 years ago
13 years ago

People

(Reporter: Brian Zappia, Assigned: Josh Aas)

Tracking

unspecified
Camino0.9
PowerPC
Mac OS X

Details

Attachments

(1 attachment, 1 obsolete attachment)

2.33 KB, patch
Mike Pinkerton (not reading bugmail)
: superreview+
Details | Diff | Splinter Review
(Reporter)

Description

15 years ago
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

15 years ago
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

15 years ago
-->pinkerton
Assignee: brade → pinkerton
-> simon for fix before 1.0
Assignee: pinkerton → sfraser
Target Milestone: --- → Camino1.0

Comment 4

15 years ago
Could this bug be confirmed then?

Comment 5

15 years ago
sure
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 6

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

Comment 7

15 years ago
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

15 years ago
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

14 years ago
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

14 years ago
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

14 years ago
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

14 years ago
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).
Severity: trivial → normal
Target Milestone: Camino1.0 → Camino0.9

Comment 13

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

Comment 14

13 years ago
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

13 years ago
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

13 years ago
*** Bug 251138 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 17

13 years ago
Created attachment 164505 [details] [diff] [review]
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.
Assignee: sfraser → joshmoz
Status: NEW → ASSIGNED
(Assignee)

Updated

13 years ago
Attachment #164505 - Flags: review?(me)
(Assignee)

Updated

13 years ago
Attachment #164505 - Flags: review?(qa-mozilla)
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.
Attachment #164505 - Flags: review?(qa-mozilla) → review+
Comment on attachment 164505 [details] [diff] [review]
fix the worst part of the problem v1.0

looks good and works as described. r=me@mollyandgeoff.com
Attachment #164505 - Flags: review?(me)
Attachment #164505 - Flags: superreview?(pinkerton)

Comment 20

13 years ago
*** Bug 268775 has been marked as a duplicate of this bug. ***
can you explain to me how this works around the issue? i'm not seeing it.
(Assignee)

Comment 22

13 years ago
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.
(Assignee)

Comment 23

13 years ago
-    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.
> @@ -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 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.
Attachment #164505 - Flags: superreview?(pinkerton) → superreview+
(Assignee)

Comment 26

13 years ago
Created attachment 165874 [details] [diff] [review]
patch v2.0

Please transfer reviews.
Attachment #164505 - Attachment is obsolete: true
(Assignee)

Comment 27

13 years ago
landed patch v2.0 on trunk. close this bug when reviews are transferred and
we've decided if we want this on the branch.
(Assignee)

Comment 28

13 years ago
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 on attachment 165874 [details] [diff] [review]
patch v2.0

sr=pink, yes, we want this on the branch.
Attachment #165874 - Flags: superreview+
(Assignee)

Comment 30

13 years ago
landed on branch
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Blocks: 261393
You need to log in before you can comment on or make changes to this bug.