Bugzilla

> Posted file tab7.txt

The browser is indeed being killed before we've even had a chance to flush the current session state to disk in response to Firefox being backgrounded (because the task switcher is brought into the foreground).
Indeed the same thing can be reproduced with desktop Firefox if you kill/crash the browser immediately after closing some tabs, though admittedly on desktop operating systems closing the browser by killing it isn't supposed to be a common operation, whereas on Android it can happen more commonly for better or for worse.

Given that we don't want to thrash the disk either by writing every little change separately, I'm not sure there's a good solution here, though, especially one that doesn't involve more invasive changes with a corresponding risk of regressions.

Maybe we could unconditionally trigger the state saving [during onSaveInstanceState](https://dxr.mozilla.org/mozilla-central/rev/e7e658ec1e98c3868b98195c2ee4b9fe3842172e/mobile/android/base/java/org/mozilla/gecko/GeckoApp.java#649) instead of waiting for [onApplicationBackground](https://dxr.mozilla.org/mozilla-central/rev/e7e658ec1e98c3868b98195c2ee4b9fe3842172e/mobile/android/base/java/org/mozilla/gecko/GeckoApplication.java#202), which might give us a little more time to try writing the session before the user manages to kill us, but I need to think a little more about whether that change might be safe to do...

Otherwise, the least invasive workaround would be making the "Quit" menu item in our main menu permanently visible again [1] in order to give us a chance to properly save the current state of the browsing session before shutting down if users quit Firefox via the "Quit" button instead of effectively killing us straightaway.

[1] [At the moment](https://dxr.mozilla.org/mozilla-central/rev/e7e658ec1e98c3868b98195c2ee4b9fe3842172e/mobile/android/base/java/org/mozilla/gecko/BrowserApp.java#3253-3260) this menu item is only shown under a limited amount of circumstances, the likely most common of which would be having one or more of the "Clear data on shutdown" options active.

(In reply to Eliza Balazs from comment #5)
> Posted file tab7.txt

The browser is indeed being killed before we've even had a chance to flush the current session state to disk in response to Firefox being backgrounded (because the task switcher is brought into the foreground).
Indeed the same thing can be reproduced with desktop Firefox if you kill/crash the browser immediately after closing some tabs, though admittedly on desktop operating systems closing the browser by killing it isn't supposed to be a common operation, whereas on Android it can happen more commonly for better or for worse.

Given that we don't want to thrash the disk either by writing every little change separately, I'm not sure there's a good solution here, though, especially one that doesn't involve more invasive changes with a corresponding risk of regressions.

Maybe we could unconditionally trigger the state saving [during onSaveInstanceState](https://dxr.mozilla.org/mozilla-central/rev/e7e658ec1e98c3868b98195c2ee4b9fe3842172e/mobile/android/base/java/org/mozilla/gecko/GeckoApp.java#649) instead of waiting for [onApplicationBackground](https://dxr.mozilla.org/mozilla-central/rev/e7e658ec1e98c3868b98195c2ee4b9fe3842172e/mobile/android/base/java/org/mozilla/gecko/GeckoApplication.java#202), which might give us a little more time to try writing the session before the user manages to kill us, but I need to think a little more about whether that change might be safe to do...

Otherwise, the least invasive workaround would be making the "Quit" menu item in our main menu permanently visible again [1] in order to give us a chance to properly save the current state of the browsing session before shutting down if users quit Firefox via the "Quit" button instead of effectively killing us straightaway.

[1] [At the moment](https://dxr.mozilla.org/mozilla-central/rev/e7e658ec1e98c3868b98195c2ee4b9fe3842172e/mobile/android/base/java/org/mozilla/gecko/BrowserApp.java#3253-3260) this menu item is only shown under a limited amount of circumstances, the likely most common of which would be having one or more of the "Clear data on shutdown" options active.