Defer loading bookmarks.html until UI has finished loading. On the Mac, this should shave off another second or so from the perceived startup time... the UI will be displayed, and THEN we'll load in the bookmark file.

Note: to get this to work, nsBookmarkService::Init() is changed to NOT call ReadBookmarks(). Also, in navigator.js, at the end of the Startup() function, add a SetTimeout() function for a half-second or so later (the timer will fire after the UI has finished loading and laying out) which, when it fires, calls ReadBookmarks(). Also had to make a small change to the bookmark's parsing code to recurve on a node's children BEFORE adding the node itself into the graph so that all "containment" issues are resolved properly.

That would be good. Will this ensure that the personal toolbar will just fillin as we readin the bookmarks...

Yes.

Marking this as WONTFIX. A poll of various Mac-heads concluded that they prefer having 100% of the chrome and its contents loaded in before the browser window appears.

marking verified per engineer's last comments

reopening and taking this bug

taking

Argh, no, really, taking it this time, sorry for the spam.

showed diffs to rjc earlier, verbal r=rjc

cool. sr=blake on those.

checked into trunk

question, wouldn't a timeout of 0 still have the same effect (forcing the window to show before loading the bookmarks)?

Paul, just thought of something. This change may have exposed a race condition between when ReadBookmarks() is called via the timer firing from Startup(), and the Bookmarks sidebar panel. You might want to test... and potentially add a ReadBookmarks()s call and ___.rebuild() into the bookmark sidebar panel's onload() function. I'll reopen this bug.

Please change the 100ms timeout to a 0ms timeout. That is sufficient to delay until after the window shows, and prevents us from basically sitting around for 100ms doing nothing.

Leaks are up following this checkin.

yes... it appears that nsBookmarksService::initDataSource(...) is called multiple times... however, mInner is not released (if non-null) so previous instances get leaked :-( -- rick

here's the line... http://lxr.mozilla.org/seamonkey/source/xpfe/components/bookmarks/src/nsBookmarksService.cpp#4141

We should change that to NS_IF_RELEASE(mInner).

leak was fixed in bugzilla 108539, marking fixed

>Please change the 100ms timeout to a 0ms timeout. That is sufficient to delay >until after the window shows, and prevents us from basically sitting around >for 100ms doing nothing. New bug?