Enable fast-startup component for Firefox

RESOLVED FIXED in Firefox 3.7a1

Status

()

RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: dietrich, Assigned: Dolske)

Tracking

({perf})

Trunk
Firefox 3.7a1
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(status1.9.2 beta1-fixed)

Details

(Whiteboard: [nv])

Attachments

(1 attachment, 2 obsolete attachments)

Comment hidden (empty)
(Reporter)

Comment 1

9 years ago
see https://bugzilla.mozilla.org/show_bug.cgi?id=509249#c10 for what needs to be done.
(Reporter)

Updated

9 years ago
Whiteboard: [ts]
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]
(Assignee)

Updated

9 years ago
Assignee: nobody → dolske

Comment 3

9 years ago
Why is it that Firefox doesn't simply use toolkit.defaultChromeURI?  FastStartup.js isn't the only code which references it.

Comment 4

9 years ago
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.

Comment 5

9 years ago
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?

Comment 6

9 years ago
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.
(Assignee)

Comment 8

9 years ago
Created attachment 401351 [details] [diff] [review]
Patch v.1

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).
Attachment #401351 - Flags: review?(vladimir)
(Assignee)

Comment 9

9 years ago
Created attachment 401352 [details] [diff] [review]
Patch v.2

Oops, forgot to fix the package manifest filename.
Attachment #401351 - Attachment is obsolete: true
Attachment #401352 - Flags: review?(vladimir)
Attachment #401351 - Flags: review?(vladimir)
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.
Attachment #401352 - Flags: review?(vladimir)
Attachment #401352 - Flags: review+
Attachment #401352 - Flags: approval1.9.2+
(Assignee)

Comment 11

9 years ago
Created attachment 401359 [details] [diff] [review]
Patch v.3
Attachment #401352 - Attachment is obsolete: true
(Assignee)

Updated

9 years ago
Whiteboard: [ts][nv] → [nv]
(Assignee)

Comment 12

9 years ago
Pushed http://hg.mozilla.org/mozilla-central/rev/be5b1c826993

Pushed to 192: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/cb7990bd183f
Status: NEW → RESOLVED
Last Resolved: 9 years ago
status1.9.2: --- → beta1-fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.7

Comment 13

9 years ago
(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
(Reporter)

Updated

9 years ago
Blocks: 503483
Target Milestone: Firefox 3.7 → Firefox 3.7a1

Comment 14

9 years ago
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?
(Assignee)

Comment 15

9 years ago
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.
You need to log in before you can comment on or make changes to this bug.