684878 - Fetch URL while Fennec loads

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, enhancement)

Description

[Ian Bicking (:ianbicking)]

A performance enhancement idea:

When starting Firefox/Fennec via an Intent, you have to wait both for Firefox to start up and for the content to be downloaded.  It would be great if the download could be started immediately so that it was ready immediately once Firefox finished starting up.

Comment 1

[Josh Matthews [:jdm]]

From the newsgroup:

>I guess you could listen on the "command-line-startup" notification, and if
>we have such a command line, you can probably init the IO service and kick
>off the network request.  At least, that's where I would start.

Comment 2

[Alon Zakai (:azakai)]

This makes intuitive sense. Do we have data that indicates how much of a benefit this would give us?

Comment 3

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

The main problem we need to overcome is starting a download using something that is not a <browser> then somehow "attaching" the dowload to a <browser> when the UI appears.

When starting a download, we'd need to handle <img>, <script>, <link> (CSS) and <iframe> sources, so we start downloading them too. I assume we use a loadgroup to keep all these downloads together. It gets complicated though.

We could try downloading the resources to memory cache directly. Then we load the <browser> as normal, but since the memory cache is hot, the "download" fast.

?

Comment 4

[Jason Duell]

> We could try downloading the resources to memory cache directly. Then we load the 
> <browser> as normal, but since the memory cache is hot, the "download" fast.

That ought to work, and even if we just load the initial document that way (and don't try to parse it for subresources and preload those too), it ought to be a win in most cases.  Seems like a reasonable first cut, at least?

Of course we'd need to benchmark it to see if it's actually a win. One important case where it could still suck is if the channel takes a long time to load (because it's either big or loads slowly):  I *think* the memory cache has the same issue as disk in that it will block the 2nd and following readers until the initial read/writer is done writing to cache (Michal/Bjarne: do you know if that's true?).  We could presumably fix that if it's an issue (it's been on our wishlist for a long time).

Re: parsing and loading subresources: if parsing/loading subresources from the raw HTML is tricky for any reason, we could still do DNS prefetch on the hostnames we encounter, so that's another intermediate step.  And/or once we have bug 580104 and bug 679883 necko will automatically resolve subresource hosts and possibly prewarm TCP connections to them in the common case w/o needing to parse any HTML.

Ee: attaching to <browser> directly:  I think unless we block the request for whatever resources it may need to be a "full" request (cookies, auth popup windows, etc), we can't just blindly attach the request to <browser> later.  The "preload to memory cache" fix seems easier to do.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> The main problem we need to overcome is starting a download using something that is not a
> <browser> then somehow "attaching" the dowload to a <browser> when the UI appears.

Yeah, it's a bit of a pain, esp. given extensions that want to mess with all network traffic, no?

I assume the "preload to memory cache" idea is to do the GET before we have all the machinery we need for doing it 'right' and then see whether we get a cache hit when we do it for real?

Comment 6

[Jason Duell]

> I assume the "preload to memory cache" idea is to do the GET before we have
> all the  machinery we need for doing it 'right' and then see whether we get a
> cache hit when we do it for real?

Exactly.

Now that I think about it, we'll probably need cookies to be correct, otherwise we could cache a reply based w/o cookies (ex: "please log in") and AFAIK necko would happily return that from the cache for the later, cookie-enabled load.  But loading the cookie DB is probably a lot faster than waiting for the full browser to be loaded.

Things like basic auth popups are definitely going to require a full environment, though, which is why I think we'll need to do the "prewarm the cache" approach.   I'm not clear on when all the various necko redirect observers, content-sec policies, etc get loaded, so those might be a factor too.

Comment 7

[BMO Automation]

Closing all opened bug in a graveyard component