shistory.dll gets loaded through xpconnect calls made from script that executes when navigator.xul's onload event handler fires. Can we move the script that causes this dll to get loaded to another place so that this dll doesn't get loaded before the browser window comes up?

Will look in to it. Session history is created when BrowserAppCore's window is created and initialised. I'm not sure if we can do it after it comes up, 'coz we want to add the start page to session History too. What seems to be the problem currently?

We want to load as few dlls as possible during startup before the browser window shows up. Right now, dll loading accounts for more than 50% of the time to start up mozilla.

Move to M20 target milestone.

waterson: is there a meta bug this should be linked to? thanks, Vishy

nav triage team: Marking nsbeta1+

Not confident that this can make it to mozilla 0.9 (which I believe is the date for nsbeta1).

cc'ing people in Nav team .... Looking at the way, browser starts up, SH is initialised in BrowserAppCore::ReinitializeContentWindow() which gets called from navigator.js's Startup(). The start-up page is also loaded from here by directly accessing the docshell for the content area, see navigator.js's loaduri(). we need SH in place before the start page is loaded so that the startup page can be added to SH too. If we could load the start page after the browser window chrome is displayed, and route the startpage load thro' BrowserAppcore OR whatever replaces it, instead of calling directly to the docshell, we can delay the load of SH too. I think by doing small rearrangement of code in navigator.js, this can be easily achieved. One of the goals of the Nav team was to get rid of OR replace BrowserAppcore. Is it still the case? According to waterson's email yesterday SHistory.dll takes about 50 msec to load. It would be nice to save that time during startup.

well, we want to get rid of as much of the appcore as possible.. the irony is that mSessionHistory is never actually used in nsBrowserInstance! cc'ing jag to see if he knows more... I have a feeling we can just whack this.

I've got a patch lying around for that change somewhere, let me dig a little :-) alecf, mSessionHistory actually is used. At startup, it's nsnull, so a new session history object is created, stored in mSessionHistory, and set on the docShell... Then when a theme switch occurs it is read from mSessionHistory and set on the newly created docShell. The funny thing is though that this is also happening from nsFrameFrame, if I recall correctly, so this code here can probably go away (even though the code in nsFrameFrame is, necessarily, evil). Anyway, let me see what I can come up with as far as setting it the first time from Startup goes.

I agree with jag. During a theme switch, SH used to get re-instated to the new docshell in nsBrowserInstance::ReinitializeContentWindow(). But this function is not called anymore.So, Back, forward does not work well after a theme switch. I have a bug on that. For this bug however, I would like BrowserInstance to hold on to mSessionHistory.

I've got one too (bug 68662). I know what's caused it (me!) and I've got a possible solution (back me out) and another one (listen to stylesheet changes and re-init from JS). I currently have a hack which puts back proper support in BrowserInstance and adds support to navigator.js where needed, but it's ugly. Anyway, the session history should be stored and set from http://lxr.mozilla.org/seamonkey/source/layout/html/document/src/nsFrameFrame.cpp#470 and http://lxr.mozilla.org/seamonkey/source/layout/html/document/src/nsFrameFrame.cpp#899 (yet another ugly hack), so I think they can be removed from BrowserInstance.

Except of course that someone needs to set it the very first time. Okay, let me stop talking and come up with a patch. However, what happens when session history isn't set? How would this influence the page cycler? It looks to me like we could set the session history right before http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/navigator.js#474, which still means we can move it down from http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/navigator.js#434 and delay loading it slightly.

See http://bugzilla.mozilla.org/showattachment.cgi?attach_id=25740 in bug 68662.

jag: Your patch is 1) moving the code in ReinitializeContentWindow() to JS and the 2) evil hack in nsFrameFrame.cpp seems to put it back after a theme switch. However 1) still happens before the window shows up at startup, thereby contributing to startup time. I want to initialize SH after the browser window shows up and load startpage after that. Is there some kind of listener or broadcaster that navigator.js can hook up to, so that we know when the window is up and showing and we can initialise SH then.

Yeah, alecf and I discussed this and we came up with the following: 1) make GetSessionHistory in nsDocShell lazily instantiate session history (instead of us having to explicitely set it) 2) replace |if (startPage) loadURI(startPage);| with |if (startPage) setTimeout(loadURI, 0, startPage);|. That moves the actual loadURI out of onload so the window will continue and display.

Please don't make docshell generically create Session history. This makes anyone who creates a docshell automagically get a history object. We do not want that. For embedding purposes, we want to keep the boundaries separate. Neither do we want a nsFrameFrame.cpp type hack in docshell. Instead, extending your idea on SetTimeOut(....), something like the following can be done... startup() { // Existing code, with out any SH creation setTimeOut(LoadStartpage, 0, startpage); } LoadStartPage(startpage) { 1) Check if the browser has a SH object 2) If not create it 3) Call Loaduri(startpage); } I'm still not sure if this will happen after the browser shows up. Can someone comment on that.

Well, I've tested the setTimeout yesterday and it looked to me like the window first shows, before starting the page load, as opposed to without the patch where the window would show up while loading the page. In some very unscientific stop-watch timings done on this 233MHz 64MB RAM the total time till the page finishes loading remains the same, but the window appears one or two seconds. sooner. radha: why would step 1 be necessary? That code should only be called from the timer started in Startup(). alecf: so instead of doing true lazy instantiation, I like radha's suggestion above. Just always create and set it from the LoadStartPage. radha, alecf: so we'll end up with something line: function Startup() { // other stuff setTimeout(finishInit, 0, startPage); } function finishInit(aStartPage) // LoadStartPage? { 1) create session history object and set it on the docshell 2) if (aStartPage) loadURI(startPage); }

Ah, I see one possible reason for step #1 (nsBrowserInstance currently also creating and setting the session history object). It shouldn't be needed any longer when bug 68662 lands (part of which is necesasry to not create the session history object early).

jag: yes, if this timer is going to go off only during startup and after 68662 lands, step 1) is not required and what you have suggested should work. Should I make these changes after 68662 lands OR you want me to make it?

I could incorporate this into the patch for 68662 and land them together.

this also suggests that we can *probably* delay the initialisation of urlbar history and global history until after the window is displayed. urlbarhistory.dll is primarily used for autocompletion. Adding to the RDF resource happens directly in sessionHistoryUI.js without interfering with the dll. Right now it gets initialised by the autocomplete widget, when the urlbar is created. However the service is not actually used until someone tries to autocomplete a url. May be we can delay the initialisation of this service until then. Have to check with ducarroz. For global history, we use it before startup to figure the last visited page, if the home page is set to lastpage visited. But this can be done thro' Prefs. There is already a pref, "browser.history.last_page_visited" which looks like a unused pref.

New bugs? :-) Though, I'm sure urlbarhistory can be lazily instantiated and set from the autocomplete xbl. Btw, is that dll still needed, or could that be moved into JS (or is JS deemed too slow?)? As to global history and recalling the last visited page, I guess a pref could be used for that, but then the pref should be set (and the prefs flushed??) whenever a page finishes loading. One common pattern is to use that setting so after you crash you can continue right where you left.

I have a way to defer the reading of the global history into memory until the data is actually needed... my patch still needs testing, but I'll attach here in a bit.

I had to special-case about:blank because if you start without a homepage, we load about:blank just so we have something to paint in the content area... Anyway, this allows me to start the browser without a homepage, go use mailnews, and the history DB never gets opened, until you visit your first page. If your history is very large, then this speeds up the appearance of the first window pretty signifigantly. I did more testing, it's looking pretty good. looking for r= from anyone and sr= from waterson? :)

So, if I have a home page, does it still allow a deferred load? What about the link color change on the home page?

yes, everything will work exactly as before - but the reading of history.dat will be delayed until after the window appears. if you have no home page, history.dat will STILL not be loaded until you visit your first page. This also means that if you start mozilla -mail, that history.dat will not be read in..

> yes, everything will work exactly as before - but the reading of history.dat > will be delayed until after the window appears. Right. > if you have no home page, > history.dat will STILL not be loaded until you visit your first page. Hmmm... This would only work if all loadURIs would create a sessionHistory and set it on webNavigation if it doesn't exist yet. Within the browser we can fairly easily guarantee this by putting it in navigator.js' loadURI, but things like x-remote would be in for a surprise. I think it would be far easier to just always create and set the sessionHistory object on webNavigation right after the window shows, like I already suggested a bit up. Changing the summary to reflect the bug morphing :-)

jag: What ever you suggested for SH still stays. history.dat has nothign to do with SH. It is only used by Global History.

Alec, jag, can I give this bug to one of you, since I don't have any patch for this bug?

Sure, I'll take this.

sr=hyatt

r=shaver, with the addition of the requested comment explaining the subtlety of the sessionHistory assignment's execution order WRT the progress-listener registration.

jag you kick ass! off to try this now

sr=alecf this is so great.

that is an updated Global History patch against the latest tree, with some additional error checking and warnings fixes

r=waterson if you still need it.

The patch that was checked in breaks profile switching. Before, I could call CloseDB() when a profile was going away and OpenDB() when the new profile started up and all was well. With this change, a call to CloseDB followed by a call to OpenDB() does not work as expected - instead it causes a crash. See http://lxr.mozilla.org/seamonkey/source/xpfe/components/history/src/nsGlobalHistory.cpp#2097. If this is going to be happen, CloseDB() needs to set that var to nsnull.

ugh, you're right. I'll fix that to set mTable to null.

Mass move to jaggernaut@netscape.com

Actually, I'll just hand this to alecf.

nav triage team: moving nsbeta1+ from status whiteboard to keywords

nav triage team: Need to look into this for startup performance. Marking mozilla0.9.4 and reassigning to pchen

nav triage team: Paul hasn't had time to look at this. Reassigning back to alecf and moving to mozilla1.0.1

can we fix delay reading/loading history DB in the next couple milestones (0.9.6 or 7?)

Taking over bug.

mork.dll : Get loaded after window is visible. Dimished the value of delaying it anymore. Getting history.dat loading faster is being tracked elsewhere. So this aint an issue for startup. shistory.dll: get loaded even before main window visible. That needs to be delayed. I think about:blank is causing it to be loaded. Need to check.

I suspect shistory.dll is getting loaded because we create a session history instance and set that on the browser from the browser's constructor (see browser.xml). This is necessary to pick up the page (which generally isn't about:blank) that gets loaded from navigator.js's startup function.

Deprioritizing startup perf and focusing on footprint. Moving past 1.0

Reassigning to a real person.

I think jag did some work on this last year OR this is already done. The changes have to happen in the navigator in the order in which components are created.

We can't make any changes to navigator without sacrificing functionality. I don't think there is anything else we can do here.