When we get killed for whatever reasons, we currently don't restore session cookies. Whether this was by intentional design or because we never thought to (re)implement this when/after forking the desktop session store code I don't know, but we might want to revisit this. In view of the fact that on desktop this wasn't entirely uncontroversial (see bug 530594), I'd propose the following behaviour: If tabs are restored automatically (either because the relevant setting is set to "Always restore", or else because we're restarting after an update, crash, ...), session cookies are restored as well. If tabs are not restored automatically, then neither are session cookies. Regarding the "Quit" button, I see a number of possibilities. We could clear session cookies from the session data on shutdown - only if the user has enabled the "Cookies" item from the "Clear private data on exit" menu - additionally when closing open tabs as well - or simply each time the "Quit" button is used.
This makes sense but it doesn't sound terribly high priority to me. I'm going to NI Product to get there thoughts here. JanH, what's the user problem you're describing here? That is, what's the problem with not restoring cookies automatically _at all_? Where have you heard this feedback?
This bug was opened in response to bug 1334967: (In reply to rainbow99984 from bug 1334967 comment #0) > Open any website page with session (login). I tried mostly kite.zerodha.com > switch to other apps,( I use 7 to 10 apps) and open the firefox after some > time 10 minute to 30 minute time frame. > [...] > Actual results: > > the tab appear blank, reload the same page and it happen to lose my session, > I have to re login to work. Also, 1. There are some situations very Firefox restarting doesn't mean that the user actually wanted to exit the current session: The phone or Firefox crashing, a Firefox update or an add-on requesting a restart. 2. I also think that rnewman's reasoning from bug 1219343 comment 23 (when we eventually decided to flip the default tab restore setting to "Always restore") applies here as well: Unlike an explicit "Quit" through the menu, a background kill by the OS is essentially a random occurrence. This also means the whether or not your session cookies are kept when you send Firefox into the background is equally random as well. After being backgrounded, we could equally get killed after five seconds  or after five hours . To give contrasting examples, it's possibly to send Firefox into the background and put your phone in your pocket and when you take it out two hours later (when you don't care about the previous session any more) all your session cookies are still there because the OS just didn't have any need to kill Firefox in order to free up memory. On the other hand it can equally happen that you just switch to another app for a moment in order to look something up/take a photo/write a message/whatever and when you return to Firefox a minute later, it's already been killed off because of a lack of RAM, so suddenly all your session logins etc. are gone. So the behaviour would be more predictable if restoring of session cookies was just tied to the tab restore setting (if you don't care about your tabs, you won't care about your session logins either) and to explicit quitting of the session via the "Quit" button (Quitting that way is a clear user action to terminate the current session, being killed by the low memory killer isn't - not to speak of crashes or updates...).  E.g. on a phone that is short on RAM/with plenty of background services running that take up resources/when the user switches to some other memory hungry app/when Firefox is using relatively much memory after a longer browsing session and is therefore a prime target for the low memory killer...  On a phone with plenty of RAM/if the phone is not actively being used/the media control notification keeps us alive while we're playing some audio...
Component: General → Session Restore
Priority: -- → P3
Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195 Needinfo :susheel if you think this bug should be re-triaged.
Priority: P3 → P5
You need to log in before you can comment on or make changes to this bug.