Closed Bug 1517795 Opened 6 years ago Closed 4 years ago

Fennec: when cold starting, could load page from local cache rather than from network, like Chromium

Categories

(Firefox for Android Graveyard :: General, enhancement, P5)

57 Branch
enhancement

Tracking

(firefox67 wontfix, firefox68 affected)

RESOLVED INCOMPLETE
Tracking Status
firefox67 --- wontfix
firefox68 --- affected

People

(Reporter: mark.paxman99, Unassigned)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_1) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0.1 Safari/605.1.15 Steps to reproduce: When Chromium Android cold starts, I think it does a network connectivity check but then it loads the last page from its local cache rather than from the network. When Fennec cold starts, I think it loads the last page from the network, not from the local cache. Chromium's behavior has some advantages:- - the user gets back exactly the page view she had when last using the browser, i.e. the outcome is the same whether the browser just went into the background but remained in memory, or was killed by Android and relaunched from cold. - the cold start process is really really fast even on a slow-ish phone. The latter difference is pronounced particularly on poor mobile data connections. If I use Fennec for a while, then task switch to do other stuff, then task switch back to Fennec, if Fennec got killed by Android there is much delay while Fennec grinds its gears and re-downloads the page from the network. It can take >10 seconds. By contrast Chromium goes zoom:- page loaded in a couple of seconds. Of course the Chromium version of the page might be old.... Could Fennec and/or GeckoView do this? [ this is probably a duplicate or something you've already considered and rejected, fine, sorry for taking up time :) ]

As far as I know, restoring session history already preferentially uses the cache and in fact there is a bug complaining about the opposite problem (bug 706970).
My guess would be that the problem is probably rather that our caching strategy is somewhat less than optimal and/or our cache size is simply too small (although of course especially on mobile devices there are limits as to how big we want to grow our cache).
I'm saying this also because of my experience with using the offline tabs feature [1] - frequently the only result is that attempting to (re)load even a recently (!) used page [2] only results in a "server not found" error.

On the other hand, even if we had a perfectly filled cache, I've got no idea to what extent a sessions restore currently might still attempt to revalidate cache entries or something like that, which would then of course introduce a dependency on the performance of the network connection.

Regarding Chrome, as far as I can tell their attempts to completely serialise a tab's state to disk [3] (and then preferentially restore that - the equivalent would be us storing the bfcache on disk) never got anywhere, so at least it seems that that cannot be the explanation.

[1] On Release, "browser.tabs.useCache" needs to be manually set because we never got to the bottom of some issues with our network state detection code [4], where for some people the browser would often claim to be offline and load pages from cache even though a network connection was definitively available.
[2] Perhaps even a page that was still loaded until moments ago and now only has to be reloaded because the page was discarded (or Firefox completely killed) due to memory pressure.
[3] https://docs.google.com/document/d/1ghw2ZigcduvaK5hlxo5rxIHo2H0FCBYHv6L-eJsetUI
[4] Either there's some bug in our code, or possibly even the Android APIs are buggy - in the latter case, that might explain why I've seen some references to Chrome now doing its own network detection by attempting to connect to some known server instead of purely relying on the OS.

Hi Jan, thanks for the detailed reply, I really appreciate it.

I have been playing today and I think you are completely right:- Fennec does (usually?) load from cache, but it is perhaps less aggressive / consistent than Chrome(ium).

The main conclusion I have come to is that I am not going to learn much about this issue (if it exists) just by killing & restarting Fennec :) It would need a deep dive by someone clever.

Anyway I'm very keen to speed up Fennec/GV cold start, I find it very tedious to use Fennec on an entry level phone. But perhaps this bug is a red herring or a minor issue.

So maybe close this bug as "worksforme"???? Up to you.

Type: defect → enhancement
Priority: -- → P5
We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → INCOMPLETE
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.