1256277 - Tabs reopen if browser is killed shortly after closing tabs

Status: RESOLVED WORKSFORME

(Firefox for Android Graveyard :: General, defect)

Description

[:Margaret Leibovic]

I've noticed this for a while, but failed to file it. If I close a bunch of tabs, switch away from Fennec, and then it gets killed in the background, all the tabs reappear when I come back to the browser.

It looks like we're not persisting the session store restate as soon as we should be, although it looks like we do have code to handle this case:
http://mxr.mozilla.org/mozilla-central/source/mobile/android/components/SessionStore.js?force=1#173

We should see if we can reproduce this by force-OOMing the app.

Comment 1

[Kevin Brosnan [Ex-Mozilla]]

seems similar to bug 1044556

Comment 2

[:Margaret Leibovic]

Maybe you can look into this while digging into the session restore code for bug 1044556?

Comment 3

[Sebastian Kaspari (:sebastian; :pocmo)]

(In reply to :Margaret Leibovic from comment #2)
> Maybe you can look into this while digging into the session restore code for
> bug 1044556?

Yeah, sounds like this is in the same area of the code.

Comment 4

[Sebastian Kaspari (:sebastian; :pocmo)]

@Jan: Now that you are an expert on the SessionStore.. do you know what's going on here? Are you interested in picking this up? :)

Comment 5

[Jan Henning [:JanH]]

I haven't looked very closely at the data writing code so far (so far my interest has rather been that the data gets collected in the first place :-) ), but I remember occasionally seeing this behaviour, too. I'm probably going to add a bit of debug logging for bug 1229259, so I might as well take a look at this, too.

Comment 6

[Jan Henning [:JanH]]

I can reproduce this with these steps:
- Have a few tabs open and open the tabs tray
- Press the home button and in the split-second you've got before Firefox disappears into the background swipe a tab away to close it (might need a few tries to get it right, plus the opportunity window you've got might also be device-dependent - my phone is not the very fastest around)
- Once Firefox has disappeared, open the task switcher as fast as possible and swipe Firefox away to kill it
- Relaunch Firefox: If you were successful, the closed tab will in fact reappear as if it had never been closed.

As I'm not sure how representative this is for how this bug is occurring during normal browsing, I'm going to add some extended debug logging for Nightly, but a preliminary analysis of the above STR suggests that
- the TabClose event can take a bit of time to travel around, so it can in fact arrive at the session store after "application-background", which means the call to flushPendingState() won't have any effect because there's no state to flush - yet
- even if more than _interval (10 s by default) has passed since the last write, saveStateDelayed() enforces a minimum delay of 2 s, by which time Firefox might have already been killed, so the save never gets written out

Comment 7

[Jan Henning [:JanH]]

And of course if some state is saved right before or during "application-background", then any tab event arriving immediately afterwards will be subject to almost the full 10 s delay between successive writes, which is more than enough to time for Firefox to get killed during a low memory situation.
I've got a possible patch which improves the situation, but I'd still like to see if anybody can reproduce this once the debug logging from bug 1264717 is enabled before proceeding further.

Comment 8

[Jan Henning [:JanH]]

Margaret, have you been able to catch an instance of this with logging enabled? If not, I'm inclined to just go ahead with my speculative fix.

Comment 9

[:Margaret Leibovic]

I haven't seen this happen recently, and I can't reproduce when trying now.

I'm actually inclined to just close this bug if we're not seeing a problem anymore.

Comment 10

[Jan Henning [:JanH]]

As you wish. If anybody can still see this happening, please reopen, preferably with logs (browser.sessionstore.debug_logging) attached.
As I still believe that there are some improvements that could be made to that area of the session store, I'll incorporate them as part of my work on bug 1190627.