722409 - Force "cold start" after Fennec is not used for a long time

Status: RESOLVED DUPLICATE of bug 718240

(Firefox for Android Graveyard :: General, defect, P3)

Description

[Lucas Rocha (:lucasr)]

This means that we shouldn't restore session on startup if Fennec is not used after a long time. It should feel like a fresh start with no restored tabs.

Comment 1

[Lucas Rocha (:lucasr)]

Attachment: Force "cold start" after Fennec is not used for a long time

Comment 2

[Lucas Rocha (:lucasr)]

This patch implements the "cold startup" behaviour described above using the existing infrastructure used in Gecko. Session expiration is the same for both Java and Gecko. After saved session expires and you start fennec, it will not automatically restore all tabs but will list of tabs in about:home instead.

Comment 3

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

Madhava, Ian: Do we want this for final release? How big of an issue is this?

Comment 4

[Brian Nicholson (:bnicholson)]

Lucas, did you make that diagram that shows the different startup cases depending on the bundle state? That might be useful to show to Madhava/Ian to help them decide. Since they didn't join our meeting we had about this, I'll try to summarize session restore here:

A session restore will occur after any unclean quit. This includes the following scenarios:
1) Fennec actually crashes
2) The user does a Force Quit
3) The phone is rebooted
4) Fennec has been put in the background (e.g., after the user pushed the home button) and terminated by Android because it's out of memory (aka OOM kill)

A session restore will *not* occur for clean quits; that is, whenever the user chooses menu > Quit.

IMO, session restore is most valuable for case #4. We may be OOM-killed at any time while in the background, and this process is transparent to the user. Sometimes, putting Fennec in the background and restoring it will keep it in memory, whereas others, putting Fennec in the background will OOM kill it, and restoring it actually causes Fennec to load again.

OOM kills can be fairly common, especially on lower end phones. Session restore allows us to resume Fennec and restore the tabs as if Fennec had never actually been killed. Without session restore, something like this could happen: the user pushes home, opens another app for a minute, and goes back to Fennec, and their tabs are gone because Fennec was OOM-killed.

A potential problem with forcing a cold start after X hours of Fennec being killed is that that Fennec may have simply been killed by OOM. If X hours have passed and the user is resuming Fennec, whether their tabs will shown will be non-deterministic. For example, consider this scenario:
1) The user has a set of tabs open
2) The user clicks home to put Fennec in the background
3) Fennec sits in the background for X hours (e.g., the user receives a long phone call, plays a game, uses GPS to go somewhere, etc.)
4) The user reopens Fennec

We may (or may not!) have been OOM-killed at #3. So in one instance, the user may go to step #4 and have all of their tabs still sitting there (non-OOM-killed case); in another instance, the user may go to step #4 and is simply landed at about:home with no other tabs open (OOM-killed case).

Comment 5

[Brian Nicholson (:bnicholson)]

Also see bug 718240.

Comment 6

[Ian Barlow (:ibarlow)]

I talked to Mark about this, and it seems that as long as we're allowing access to your tabs from last time from the start page, we should be ok to force a cold start after "x" hours. 

Also, Brian thanks very much for your explanation, that was super helpful. Your description of a maybe-or-maybe-not OOM kill that could send a user into two possible scenarios, while not ideal, is still something we'll have solved for with the "tabs from last time list" on the start page.

Comment 7

[Brian Nicholson (:bnicholson)]

Comment on attachment 592829 [details] [diff] [review]
Force "cold start" after Fennec is not used for a long time

Session restore has changed quite a bit since this patch, so I'm putting feedback- until we're sure this still works with the latest codebase. Also, a point Mark made awhile back was that this breaks the sessionstore prefs (e.g., browser.sessionstore.resume_from_crash and browser.sessionstore.max_resumed_crashes). Can we still handle those, or do we not care?

Comment 9

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

Comment on attachment 592829 [details] [diff] [review]
Force "cold start" after Fennec is not used for a long time

I'm going to r- for now since we are in the middle of getting our session restore process better defined. A few things that come to mind:
* Do we want OOM to be affected by the timeout?
* I think we always want "tabs from last time" to appear.

Comment 10

[Brian Nicholson (:bnicholson)]

The purpose of this bug is to create a Java-side timeout for the restore, which we're doing in bug 718240, so marking this as a dupe.