Confirm
350
edits
Changes
Session restore behavior in Firefox for Android
==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 tabs after it's reopened. If it crashes again, tabs are not automatically restored, and we load about:home with a list of tabs from last time; this is done to prevent a crash loop.
==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 security reasons.
==Frequently asked questions==
===How can I change the session restore behavior?===
There's currently no way to change the session restore behavior outlined above, but preferences for configuring session restore will be added soon ({{bug|801412}}).
===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|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}})
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 tabs after it's reopened. If it crashes again, tabs are not automatically restored, and we load about:home with a list of tabs from last time; this is done to prevent a crash loop.
==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 security reasons.
==Frequently asked questions==
===How can I change the session restore behavior?===
There's currently no way to change the session restore behavior outlined above, but preferences for configuring session restore will be added soon ({{bug|801412}}).
===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|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}})
