if you have a lot of bookmarks, the drop of a bookmark at the bottom of the bookmark sidebar takes a long time




Bookmarks & History
11 years ago
8 years ago


(Reporter: (not reading, please use seth@sspitzer.org instead), Assigned: (not reading, please use seth@sspitzer.org instead))


Firefox 3 alpha7
Bug Flags:
blocking-firefox3 +

Firefox Tracking Flags

(Not tracked)



(1 attachment)

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().
Assignee: nobody → sspitzer
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
apply([object Object],[object Array])@:0
PTV__enumerateObservers("onDrop",[object Array])@chrome://browser/content/places/treeView.js:792
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.
Flags: blocking-firefox3?
Target Milestone: --- → Firefox 3 alpha6
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.

Comment 7

11 years ago
(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! :-)


11 years ago
Flags: blocking-firefox3? → blocking-firefox3+

Comment 8

11 years ago
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.
Target Milestone: Firefox 3 alpha6 → Firefox 3 beta1
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.
Last Resolved: 11 years ago
Resolution: --- → 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.

Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.