Mobile/SessionRestore

From MozillaWiki
Jump to: navigation, search

Overview

Whenever Firefox is opened after a previous browsing session, certain session behavior will take place depending on how Firefox was killed. Note that the lifecycle of Firefox for Android is very different from that of Firefox on desktop (for a technical overview of the process lifecycle on Android, see http://developer.android.com/guide/components/processes-and-threads.html#Lifecycle).

Firefox can be killed in a number of ways, and the restore behavior for each category is outlined below.

Restore behavior

Killed by the OS

Any time Firefox is moved to the background (pushing the Android home button, receiving a phone call, etc.), Android may decide to kill Firefox to free resources for the newly foregrounded app. How frequently this happens varies on the device and other running apps. In certain situations, particularly when there's multiple CPU-intensive services active, Firefox can even be killed every time it is backgrounded. If Firefox is killed by the OS, tabs will be automatically restored when Firefox is reopened.

Killed manually

Hitting "Force stop" or swiping Firefox from the recently used apps list is considered a close initiated by the user. If you have a task killer active, it is also considered a manual close since we have no way to differentiate task killer kills vs. a user-initiated "Force stop". If Firefox is killed manually, tabs are not automatically restored. Instead, Firefox should load about:home with a list of tabs from last time (some recent discussion about this behavior here: https://bugzilla.mozilla.org/show_bug.cgi?id=801412#c9).

Killed from a crash

If Firefox crashes, it should automatically restore all tabs after it's reopened.

Implementation details

Non-private tabs

During a browsing session, Firefox writes the session data whenever any tabs are changed; opening/closing a tab, going to another page in a tab, or going back/forward in the tab's history are all triggers that result in the session being saved. When a session is saved, the list of open tabs and each history entry within those tabs are iterated, serialized to JSON, and written to sessionstore.js in the profile.

Rather than writing state to the disk, most Android apps usually write state to the activity's bundle in onPause(). However, writing the session to disk guarantees that the session can still be recovered after a crash, whereas the bundle is only alive after the app has been gracefully killed in the background by the OS.

Private tabs

Private browsing tabs, on the other hand, are handled differently. Unlike normal browsing tabs, private tab data is saved to the bundle and is not saved to disk. This means that if Firefox crashes, is force closed, or is killed by a task killer, the private session is lost. This is done by design for privacy reasons.

Frequently asked questions

How can I change the session restore behavior?

If you prefer, you can change Fennec to always restore your tabs regardless of how it was killed. To change this preference, go to Settings > Customize > Tabs. Select "Always restore" if you want your tabs to always reappear after Fennec is killed, or "Don't restore after quitting Fennec" to use the default behavior.

Sometimes when I switch apps, all of my tabs disappear! What's wrong?

Normally, if Firefox is killed in the background, it happens because the system is low on memory (read Restore behavior for more information). However, if Firefox is killed by the OS because of low memory, your tabs should be restored when Firefox is reopened. If your tabs aren't restored, Firefox is likely being killed via some other means.

This problem is usually caused by the presence of a task killer on the device, so try disabling/uninstalling any memory management or task killer app on your device. Also, see http://www.howtogeek.com/127388/htg-explains-why-you-shouldnt-use-a-task-killer-on-android/ for why task killers aren't a good idea.

Known issues

  • Quickly opening and closing Firefox successively can cause session data to be lost (bug 852267)