Closed
Bug 1256277
Opened 9 years ago
Closed 8 years ago
Tabs reopen if browser is killed shortly after closing tabs
Categories
(Firefox for Android Graveyard :: General, defect)
Firefox for Android Graveyard
General
Tracking
(fennec48+)
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
fennec | 48+ | --- |
People
(Reporter: Margaret, Assigned: JanH)
References
Details
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.
Reporter | ||
Updated•9 years ago
|
Assignee: nobody → margaret.leibovic
tracking-fennec: ? → 48+
Comment 1•9 years ago
|
||
seems similar to bug 1044556
Reporter | ||
Comment 2•9 years ago
|
||
Maybe you can look into this while digging into the session restore code for bug 1044556?
Flags: needinfo?(s.kaspari)
Comment 3•9 years ago
|
||
(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.
Assignee: margaret.leibovic → s.kaspari
Flags: needinfo?(s.kaspari)
Comment 4•9 years ago
|
||
@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? :)
Flags: needinfo?(jh+bugzilla)
Assignee | ||
Comment 5•9 years ago
|
||
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.
Assignee: s.kaspari → jh+bugzilla
Flags: needinfo?(jh+bugzilla)
Assignee | ||
Comment 6•9 years ago
|
||
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
Assignee | ||
Comment 7•9 years ago
|
||
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.
Assignee | ||
Comment 8•8 years ago
|
||
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.
Flags: needinfo?(margaret.leibovic)
Reporter | ||
Comment 9•8 years ago
|
||
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.
Flags: needinfo?(margaret.leibovic)
Assignee | ||
Comment 10•8 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Updated•4 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•