Closed Bug 14824 Opened 21 years ago Closed 18 years ago

[Startup Performance] Defer loading bookmarks until UI has finished loading

Categories

(SeaMonkey :: Bookmarks & History, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED
mozilla0.9.7

People

(Reporter: mozilla, Assigned: paulkchen)

References

Details

Attachments

(3 files, 3 obsolete files)

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.
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: M11
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.
Blocks: 11417
Blocks: 7251
That would be good. Will this ensure that the personal toolbar will just fillin
as we readin the bookmarks...
Yes.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
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.
Status: RESOLVED → VERIFIED
marking verified per engineer's last comments
No longer blocks: 7251
reopening and taking this bug
Status: VERIFIED → REOPENED
Priority: P2 → P1
Resolution: WONTFIX → ---
Target Milestone: M11 → mozilla0.9.7
taking
Status: REOPENED → ASSIGNED
Argh, no, really, taking it this time, sorry for the spam.
Assignee: rjc → pchen
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Component: RDF → Bookmarks
Attachment #56310 - Attachment is obsolete: true
Attachment #56312 - Attachment is obsolete: true
Attachment #56314 - Attachment is obsolete: true
showed diffs to rjc earlier, verbal r=rjc
Attachment #56355 - Flags: review+
Attachment #56356 - Flags: review+
Attachment #56357 - Flags: review+
cool. sr=blake on those.
checked into trunk
Status: ASSIGNED → RESOLVED
Closed: 21 years ago18 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Resolution: 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.
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
We should change that to NS_IF_RELEASE(mInner).
Status: REOPENED → RESOLVED
Closed: 18 years ago18 years ago
Resolution: --- → FIXED
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?
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.