5.73 KB, patch
|Details | Diff | Splinter Review|
3.01 KB, patch
|Details | Diff | Splinter Review|
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20051006 Firefox/1.6a1 Open the bookmarks panel. Now drag any tab or url icon from location bar to the panel. The bookmark could be added to any of the folders in the bookmarks list but not to the root (to be shown directly under the bookmarks menu) If attempted through the Add bookmark dialog this is possible and shows up in the panel.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1 ID:2005100618 WFM in this build: 1.9a1_2005100623.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051006 Firefox/1.6a1 WFM on Linux as well
I know this is a trunk bug, however there is some discrepancy on the branch as well which might be related to this bug: dropping links from the content area in the bookmarks sidebar works anywhere below the tree, whereas for dropping urls from the urlbar/tabbar you must be no more than a few pixels below the last visible item. I'm not sure whether you mean this behavior, but if you do this is a usability issue for Firefox 1.5 as well (and probably and easily fixed one, so please request blocking1.8rc1).
(In reply to comment #3) > I know this is a trunk bug, however there is some discrepancy on the branch as > well which might be related to this bug: dropping links from the content area in > the bookmarks sidebar works anywhere below the tree, whereas for dropping urls > from the urlbar/tabbar you must be no more than a few pixels below the last > visible item. I'm not sure whether you mean this behavior, but if you do this is > a usability issue for Firefox 1.5 as well (and probably and easily fixed one, so > please request blocking1.8rc1). oops! There was some mistake on my side in explaining the bug. What is said in comment no. 3 is the actual situation. The user has to "place" the dragged item exactly below or between folders / other items. There is no general 'drag'n'drop' functionality (which is mostly possible over a wide area in the drop-target. This is to be made possible.
Dupe of bug 235243?
Created attachment 198840 [details] [diff] [review] Enable drag&drop for the tree, disable it for the sidebar This patch adds full drag&drop support to the rest of the bookmarks tree. On the other hand, it disables drag&drop for the sidebar, leaving it to its content to do the handling (most sidebar content isn't able to do anything with dropped URLs, so the wrong feedback given might just confuse the user). As far as I can tell, the behavior should be correct, but I'm no drag&drop expert...
Is it too late already for such non-obvious bugs? (In reply to comment #5) > Dupe of bug 235243? No, this one is about the Bookmarks panel/sidebar.
Comment on attachment 198840 [details] [diff] [review] Enable drag&drop for the tree, disable it for the sidebar there's no reason to disable dnd support in the sidebar because its not perfect. If we disable this people will flip, and rightly so.
(In reply to comment #8) > (From update of attachment 198840 [details] [diff] [review] ) > there's no reason to disable dnd support in the sidebar because its not > perfect. If we disable this people will flip, and rightly so. It would obviously not be disabled completely, since right for the bookmarks panel we need it as well. I'd just be disabled for all non-drag&drop aware panels (such as the History panel [where BTW dragging is still supported as you'd expect], the Downloads manager, the Error Console, etc.). My description probably sounded harsher than it was intended. People probably wouldn't even notice, since in the one other panel where drag&drop would make sense (the webpanel) it doesn't work anyway. However, if you don't like the idea at all, would you reconsider the second part of the patch (concerning only bookmarksPanel.xul and bookmarksTree.xml)?
Created attachment 198843 [details] [diff] [review] just completely enable d&d for the bookmarks sidebar
Can someone please explain to me what's broken here and what we're fixing? This bug appears to have morphed into something other than its description...
Not at all. The bug consists in the fact that you can't drop any bookmarks or tabs at the space more than two or three pixels below the last item in the bookmarks tree in the sidebar panel. Since you can drop there links from the content area and since it'd make such a nice big target, I'm enabling this area as such. Now, while trying to fix this, I noticed that the sidebar itself is actually a drop-target for links/text originating from the content area. This might be desirable for the bookmarks sidebar, is however at best confusing for most (if not all) other sidebar panels. Since this would still work for this specific panel, I'd suggest to at the same time switch off the drop-indicator where it doesn't make sense.
check in on trunk: Checking in bookmarksPanel.xul; /cvsroot/mozilla/browser/components/bookmarks/content/bookmarksPanel.xul,v <-- bookmarksPanel.xul new revision: 1.21; previous revision: 1.20 done Checking in bookmarksTree.xml; /cvsroot/mozilla/browser/components/bookmarks/content/bookmarksTree.xml,v <-- bookmarksTree.xml new revision: 1.70; previous revision: 1.69 done
Is this worth checking in on the branch for b2?
Comment on attachment 198843 [details] [diff] [review] just completely enable d&d for the bookmarks sidebar a=mconnor on behalf of drivers
mozilla/browser/components/bookmarks/content/bookmarksPanel.xul 188.8.131.52 mozilla/browser/components/bookmarks/content/bookmarksTree.xml 184.108.40.206