675051 - Load minimal amount of UI at startup

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Benjamin Stover (:stechz)]

To reduce the amount of time to first paint, we can minimize the interface as much as possible and load in the rest of the application after paint.

The prototype actually loads a different XUL page, completely from browser.xul. This idea may not be bad, in that extensions won't typically override it (and specific extensions like Personas still can). All Javascript logic that depends on browser load, UIReady, session restore, etc. will now automatically happen after first paint. It's a very big hammer.

However, this could cause issues with frontend pieces I haven't considered or with other extensions. I had to make a new observer called "browserwindowopened" because domwindowopened is no longer useful for adding event listeners.

Comment 1

[Benjamin Stover (:stechz)]

Attachment: Load minimal amount of UI at startup

Comment 2

[Benjamin Stover (:stechz)]

(The first part of the diff is just for error and console dumping.)

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

I'm not a huge fan of the "browserwindowopened". Why do we want that? to delay the AttachListsners call?

Comment 4

[Benjamin Stover (:stechz)]

Yes. Since the window changes after domwindowopened, any listeners you attach will no longer remain once the browser is loaded.

Better ideas are welcome.

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

Re-attach listeners after the location changes?

Comment 6

[Benjamin Stover (:stechz)]

You'd have to use progress listeners to do that every single time I guess? That sounds much much worse.

Comment 7

[Mark Finkle (:mfinkle) (use needinfo?)]

btw, the patch doesn't have the fakebrowser file

Comment 8

[Benjamin Stover (:stechz)]

Attachment: Load minimal amount of UI at startup

Comment 9

[Mark Finkle (:mfinkle) (use needinfo?)]

I don't see how we can take the "browserwindowopened" change when add-ons and other code could be depending on it.

Comment 10

[Benjamin Stover (:stechz)]

I could also try making a new window instead of loading a new document. I worry this will regress overall time to responsive UI, but that can be tested.

Comment 11

[Wesley Johnston (:wesj)]

I wonder if we could use this when Fennec is started with a url argument. We could have a ui that was nothing more than a browser element that we started loading the page in. When onload fired, we could open the real browser window (in the background?) and move the loaded document inside?

Not sure how well that would work with our current e10s system, or if we'd need to inject panning code? Or if it would just be annoying to users to have a less than complete browser running...

Comment 12

[Kevin Brosnan [Ex-Mozilla]]

Fixed with native.