Closed Bug 511984 Opened 12 years ago Closed 12 years ago
Enable fast-startup component for Firefox
No description provided.
see https://bugzilla.mozilla.org/show_bug.cgi?id=509249#c10 for what needs to be done.
This isn't really general [ts], because we don't want to do this on all platforms. This is a specific fix on platforms with currently exceptionally long startup time, like Windows CE. Two things need to be done: 1) The patch uses toolkit.defaultChromeURI, which isn't present in firefox. It should use browser.chromeURL, but that won't work since that's "chrome://browser/content/", and the actual window is "chrome://browser/content/browser.xul". So the easiest thing to do would be to check for defaultChromeURI, if it's not set/present, then check for browser.chromeURI... if it's present, then use "chrome://browser/content/browser.xul". Or we can fix chromeURL to have the full URL. 2) The faststart pieces need to be added to the packaging manifest.
Whiteboard: [ts] → [ts][nv]
Why is it that Firefox doesn't simply use toolkit.defaultChromeURI? FastStartup.js isn't the only code which references it.
Wait, why are you using .defaultChromeURI *or* browser.chromeURL? Neither is meant to be a general solution to anything. If you want to do "the normal thing that an application does on startup" you should dispatch a commandline with no arguments.
That -is- how dispatching command-lines works, but we use the chromeURI information to detect the opening of top-level DOM windows. Is there a better way?
We can probably just ditch all the browser chrome URI checking entirely.
That's not a bad idea; we can probably just look at the number of visible open windows.
I checked with some debug output to confirm that the hidden window wasn't causing problems... It wasn't. When launching Firefox (with the faststart process already running), the observer only sees 1 domwindowopened notification, for the real Firefox window. (FYI: this is on top of a whitespace only patch to convert DOS line endings in toolkit/components/faststart).
Oops, forgot to fix the package manifest filename.
Comment on attachment 401352 [details] [diff] [review] Patch v.2 Looks good, can you make the _browserWindowCount-- only happen if _browserWindowCount is > 0 though? Dont' want it going below 0 in case some windows get opened before we start listening to window open/close. With that, approved for 1.9.2 as well.
(In reply to comment #10) > (From update of attachment 401352 [details] [diff] [review]) > Looks good, can you make the _browserWindowCount-- only happen if > _browserWindowCount is > 0 though? Dont' want it going below 0 in case some > windows get opened before we start listening to window open/close. With that, > approved for 1.9.2 as well. Why should this be necessary? We're initialized and listening well before the browser's first window is ever built, even in the case where we're started without -faststart-hidden
Target Milestone: Firefox 3.7 → Firefox 3.7a1
Out of curiosity (sorry for the very very late add'l drive-by), why is so much of this wrapped in add'l #ifdef WINCE guards? Can't we just control whether this is on or off by fixing the mozconfigs for whichever platform? Why restrict to only WINCE?
The copious #ifdef WINCE guards are there just because the focus on getting this working was, AFAIK, entirely for WinCE/WinMo. So it serves as a warning for someone trying to blindly flip this on for OS/2 or whatever that they should probably do some investigation and testing first.
Component: Build Config → General
Product: Firefox → Firefox Build System
Target Milestone: Firefox 3.7a1 → mozilla3.7a1
You need to log in before you can comment on or make changes to this bug.