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:
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
-> simon for fix before 1.0
Could this bug be confirmed then?
Our toolbar folder drag and drop code behaves very similarly to Safari's: do you have the same problems there?
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.
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.
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.
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.
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.
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).
*** Bug 248334 has been marked as a duplicate of this bug. ***
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.
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.
*** Bug 251138 has been marked as a duplicate of this bug. ***
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.
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 on attachment 164505 [details] [diff] [review] fix the worst part of the problem v1.0 looks good and works as described. firstname.lastname@example.org
*** 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.
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.
- 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.
Created attachment 165874 [details] [diff] [review] patch v2.0 Please transfer reviews.
landed patch v2.0 on trunk. close this bug when reviews are transferred and we've decided if we want this on the branch.
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.
landed on branch