If a user opens the bookmarks sidebar, they can drag and drop a bookmark into the top level folder. This places the bookmark at the same level as the "Bookmarks Toolbar", "Bookmarks Menu", and "Unfiled Bookmarks" folders. Users should not be able to do this. Note: In the Bookmarks Organizer, this drag and drop action will fail. It only works in sidebar. Found in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b2pre) Gecko/2007112004 Minefield/3.0b2pre
Still happen with latest nightly builds.
Why is that bad? The bookmarks menu is longer the "top lever" folder in there.
Mano i agree with Henrik, imho we shouldn't allow users to put folders into All Bookmarks, what's the use for that? All bookmarks should be the root to separate Bookmarks by type, and we could in future add other meta-folders like smart bookmarks or livemark collection... For archiving bookmarks we already have unfiled folder. And i'm not sure that bookmarks under all bookmarks are exported / backup at all
Mano as Marco already said, we have a nice and clean way of storing folders/bookmarks in given meta-folders. One for the Toolbar, the Bookmarks menu and Unfiled Bookmarks. If you allow storing bookmarks under All Bookmarks it will be (IMO) nontransparent for the user and the database will be scattered. All folders users need we already have.
I think that if we allow it to be writable, "All Bookmarks" will become yet another "garbage dump" (as Faaborg has referred to the bookmarks menu in Fx2).
Are there potential problems interacting with other portions of the bookmarking code (in terms of searching for or otherwise referencing this as a location for bookmarks) or API here? Blocking for now, since I agree with comment 5. I think a nicer way to do this would be for us to redirect drags that go to the top level to end up in the "Unfiled Bookmarks" folder.
related bug 415125
fyi - it's also possible to create a new sub-folder directly inside of the all bookmarks folder. It can't be done from the tree view but it can be done by selecting all bookmarks and then right-clicking in the right-pane to choose new folder. Personally I like having this option available, however, I thought I should point that out somewhere.
It would be useful to have an "Bookmark archive", where bookmarks are not shown in any toolbar and/or menu (this is different than unfiled bookmarks, which is for new bookmarks)
All Bookmarks should be read-only.
Created attachment 310129 [details] [diff] [review] fix make All Bookmarks read-only.
Comment on attachment 310129 [details] [diff] [review] fix r=mano
Checking in browser/components/places/content/utils.js; /cvsroot/mozilla/browser/components/places/content/utils.js,v <-- utils.js new revision: 1.127; previous revision: 1.126 done
(In reply to comment #8) > fyi - it's also possible to create a new sub-folder directly inside of the all > bookmarks folder. It can't be done from the tree view but it can be done by > selecting all bookmarks and then right-clicking in the right-pane to choose new > folder. > > Personally I like having this option available, however, I thought I should > point that out somewhere. > Yes, I agree it'd be nice to have a more customizable default view. However, that can't happen until we find a way to do that without allowing the "special" folders to get mucked up. Safest for now to resolve as we did in this bug. We can work in Fx3.next to get this more flexible.
This is not fixed. I run a test with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b5pre) Gecko Minefield/3.0b5pre ID:2008031923 and I'm still able to place bookmarks directly under "All Bookmarks". Steps I did: 1. Open "Unfiled Bookmarks" 2. D&D a bookmark somewhere under the last bookmark (empty area) => Bookmark is placed at top level 3. D&D a bookmark between "Bookmarks Toolbar" and "Bookmarks Menu" => Bookmark is placed at top level
Did you try with a new or a pre-existing profile? This fix affects new profiles only.
Ok, than this is working with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b5pre) Gecko Minefield/3.0b5pre ID:2008031923. Lately there were a lot of checkins which only works with a new profile or places.sqlite. All testers already running a beta version will be affected even with a final release version of Firefox 3. All these will probably produce a lot of bug reports in the future.
(In reply to comment #16) > Did you try with a new or a pre-existing profile? This fix affects new profiles > only. David, should such things be added to SUMO? I think it would be helpful. At least it should be shown as notes for beta testers, and what they have to do to get places working properly.
I'm not sure if it's needed, as the only way to move a bookmark to the top folder is through the sidebar, and the bookmark doesn't disappear after the drop. Not sure how we would frame this. "Some bookmarks only accessible via the sidebar," with the solution of creating a new profile?
(In reply to comment #19) > drop. Not sure how we would frame this. "Some bookmarks only accessible via the > sidebar," with the solution of creating a new profile? After talking with David on IRC there was made the decision to create a new page with information for beta users. All bugs which were fixed and require a fresh places.sqlite should be taken into account.
Backed out in bug 425141.
(In reply to comment #9) > It would be useful to have an "Bookmark archive", where bookmarks are not shown > in any toolbar and/or menu (this is different than unfiled bookmarks, which is > for new bookmarks) > I think the workflow will be different depending on the user. I use Unsorted Bookmarks for this purpose. You could easily make an extension to do this.
Created attachment 313635 [details] [diff] [review] fix v2 safer, saner.
(In reply to comment #22) > (In reply to comment #9) > > It would be useful to have an "Bookmark archive", where bookmarks are not shown > > in any toolbar and/or menu (this is different than unfiled bookmarks, which is > > for new bookmarks) > > > > I think the workflow will be different depending on the user. I use Unsorted > Bookmarks for this purpose. Is there negation in queries? If so, tacking on TAG=/!="archive" (or whatever) would seem a fairly intuitive, complete solution, without needing extra top-level folders. Save a few queries, as they reveal their usefulness, and Bob's your uncle, as a friend of mine delights in saying. User experience/interface awaits some attention ATM, o'course. Sorry for any excessive off-topicality.
Created attachment 313899 [details] [diff] [review] wip read-only nodes handled properly with this patch. however, on drag-over, child-nodes of read-only nodes are not properly highlighted as drop-targets.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5 I tried to re-organize my bookmarks by dragging and dropping two folders that appeared mixed in among accumulated bookmarks in the "Bookmarks Menu" folder and they ended up inserted as sub-folders of one of my existing folders already defined under the "Bookmarks Menu". It took me a couple of days and reading some of this bug report to figure out where the folders had disappeared to. This is very annoying.
Created attachment 316619 [details] [diff] [review] fix ok, to sum up the changes: - make All Bookmarks read-only - use the correct drop target row in the canDrop chain (tree -> treeView -> draghelper) - always call canDrop in onDragOver - fix the treeview canDrop to allow dropping *on* non-read-only child containers of read-only containers (eg: the toolbar shortcut in All Bookmarks)
Comment on attachment 316619 [details] [diff] [review] fix r=mano
Comment on attachment 316619 [details] [diff] [review] fix a1.9=beltzner
i think you should bump up the left pane version since that patch has already been checked in (and we have users with not readonly AllBookmarks folder). unless you're not about doing other changes to those folders in another blocker.
Created attachment 317056 [details] [diff] [review] fix w/ bumped left pane version number carrying over r+a
Checking in browser/components/places/content/tree.xml; /cvsroot/mozilla/browser/components/places/content/tree.xml,v <-- tree.xml new revision: 1.113; previous revision: 1.112 done Checking in browser/components/places/content/treeView.js; /cvsroot/mozilla/browser/components/places/content/treeView.js,v <-- treeView.js new revision: 1.66; previous revision: 1.65 done Checking in browser/components/places/content/utils.js; /cvsroot/mozilla/browser/components/places/content/utils.js,v <-- utils.js new revision: 1.138; previous revision: 1.137 done
verified with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008042408 Minefield/3.0pre
Test case https://litmus.mozilla.org/show_test.cgi?searchType=by_id&id=6080 has been updated to verify this test case for regression testing.
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv