if you have a lot of bookmarks, the drop of a bookmark at the bottom of the bookmark sidebar takes a long time I'm seeing a lot of command updating after the drop, and we are calling getIndexOfNode() which can be expensive. see also bug #368240. note, even with the for bug #368240, this problem exists, because the container allows the drop.

which event triggers command updating here? we could probably use some treeBoxObject batching support.

this particular performance problem is caused by _getInsertionNode in tree.xml we have a helper funtion findFolder() which recursively opens (and closes, if they weren't open before) containers looking for node that matches the itemId we are looking for. If we can assume that the insertion point's itemId will be for a container that is visible in the current view, and therefore we don't have to open the containers to find it, then I've got a patch that makes it so we don't open/close containers, and that fixes this performance problem. if not, another way we might be able to fix this problem is by making the insertion point store the container, and not the container's itemId, since that's what we're looking for with findFolder().

the calls stack to the issue is: _getInsertionIndex([object Object])@chrome://browser/content/places/tree.xml:750 VO__adjustInsertionPoint([object Object])@chrome://browser/content/places/tree.xml:791 VO_onDrop(22,1)@chrome://browser/content/places/tree.xml:862 apply([object Object],[object Array])@:0 PTV__enumerateObservers("onDrop",[object Array])@chrome://browser/content/places/treeView.js:792 PTV_drop(22,1)@chrome://browser/content/places/treeView.js:943 invokeDragSessionWithImage([object XULElement],[object XPCWrappedNative_NoHelper],[object XPCWrappedNative_NoHelper],7,null,0,0,[object MouseEvent])@:0 ([object MouseEvent],[object XULElement])@chrome://global/content/nsDragAndDrop.js:397 onxbldraggesture([object MouseEvent])@chrome://browser/content/places/tree.xml:969 with the bookmarks.html that I'm playing with (thanks jay patel), it takes 11 seconds for _getInsertionIndex() to complete.

another really bad perf bug I'd like to fix by A6, or sooner.

some more detailed steps to reproduce: <sspitzerMsgMe> with jay's profile, or your own: <sspitzerMsgMe> go to the last folder <sspitzerMsgMe> in the right pane <sspitzerMsgMe> make sure all other folders, I hope you have a lot, are closed <sspitzerMsgMe> open the last folder <sspitzerMsgMe> for jay, he has about 20 bookmarks in the last folder <sspitzerMsgMe> move the last bookmark from the last position up a couple. <sspitzerMsgMe> it takes me about 10 seconds <sspitzerMsgMe> after I drop Note, I am using Jay Patel's bookmarks.html.

(In reply to comment #6) > > Note, I am using Jay Patel's bookmarks.html. > If there's any porn in there, it's not mine! :-)

Is the originator of this bug thread talking about the long hang time that occurs when you click on 'Bookmarks' in the 'file edit view bookmarks tools help' menu bar? This has been happening for my firefox with a 500 kb bookmarks file. The hang time (about 5 to 6 seconds) occurs for the first time I click on Bookmarks. Then, after this hang time, it doesn't hang again for the next time I click on Bookmarks.

> Is the originator of this bug thread talking about the long hang time that > occurs when you click on 'Bookmarks' in the 'file edit view bookmarks tools > help' menu bar? I'm talking about a different long hang time. Specifically, the dragging and dropping of a bookmark within the bookmark sidebar or bookmark organizer. See bug #337855 for why the second time is fast. As for why the first time is slow, I'll log a spin of bug (to bug #337855) and cc you.

> I'll log a spin of bug see bug #385036

sliding to beta 1. have a wip patch, so a possible candidate for A6, time permitting.

This is really easy to reproduce with ispiked's bookmarks as well.

The wip patch was never checked in, but I'm am not able to reproduce this anymore with my steps in comment #6 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007071817 Minefield/3.0a7pre. Marking worksforme.

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