757918 - Fennec Native does not session restore all background tabs when the app goes into the background

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, defect)

Description

[Justin Lebar (not reading bugmail)]

Attachment: Testcase

We used to do this in XUL Fennec: When the app is backgrounded, we'd session-restore all tabs except the one in the foreground.

We no longer do that, but if we care about Fennec not getting killed when it goes into the background, this is the single best change we can make.

STR:

 * Open attached page.
 * Click the button.  This modifies the dom by writing "DOM modified" to the page.
 * Open some other page in a new, foreground tab.
 * Press <home>
 * Open Fennec.
 * Open tab with attached page.

Actual results: Page says "DOM modified".
Expected results: Page doesn't say "DOM modified".

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

We do not want to drop tabs when going into the background. It's a hoorible UX to have to reload tabs when coming back to Fennec.

In XUL Fennec we would drop inactive tabs _if_ we received a low memory pressure. We don't do that in native. With our faster startup time, we feel it's OK to let Android reclaim the app, and then reload all tabs (loading the active one) when coming back to fennec.

Comment 2

[Justin Lebar (not reading bugmail)]

> In XUL Fennec we would drop inactive tabs _if_ we received a low memory pressure. We 
> don't do that in native.

Yes, but didn't we fire a memory pressure event upon going into the background?

I totally agree it's a pain to reload tabs when coming back to Fennec.  But this trade-off cuts both ways:

If we don't drop background tabs, we're more likely to get killed.  In that case, we have to reload *all* tabs when coming back.  On the other hand, if we do drop background tabs, there's a better chance that, when the user comes back to Fennec, you *won't* have to reload the foreground tab.

Can we agree that if our goal is to avoid reloading pages, that this bug isn't necessarily a bad thing, and in fact might be an improvement?  If so, can we re-open this bug and discuss it further?

Comment 3

[Justin Lebar (not reading bugmail)]

For example, if you think it's really important to keep around some background tabs, we could still unload background tabs that haven't been focused for a long time.

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Justin Lebar [:jlebar] from comment #2)
> > In XUL Fennec we would drop inactive tabs _if_ we received a low memory pressure. We 
> > don't do that in native.
> 
> Yes, but didn't we fire a memory pressure event upon going into the
> background?

We fired two types of memory pressure events in XUL fennec. The one to go into the background:
http://mxr.mozilla.org/mozilla-central/source/widget/android/nsAppShell.cpp#339

Did not free background tabs:
http://mxr.mozilla.org/mozilla-central/source/mobile/xul/chrome/content/browser.js#2642

(In reply to Justin Lebar [:jlebar] from comment #3)
> For example, if you think it's really important to keep around some
> background tabs, we could still unload background tabs that haven't been
> focused for a long time.

This sounds like a feature request we could entertain. I think desktop has the same type of feature request. I don't think we'd tie it to going into the background or low-memory pressure.

File a new bug for this specific feature?

Comment 5

[Justin Lebar (not reading bugmail)]

> We fired two types of memory pressure events in XUL fennec. The one to go into the 
> background did not free background tabs.

I see, thanks for clarifying.

> I think desktop has the same type of feature request.

I explicitly want this to be different from the general "unload old background tabs" bug, which is a minefield.  Our contract on desktop (and, some people feel, on mobile) is that you will never lose data in any tab except by closing the tab or the app.  With our current technologies, it's of course possible to lose data when restoring an unloaded (i.e., session-restored) tab.

I'm talking about unloading tabs while the process is in the background, with the explicit intent of making it less likely that we'll have to re-load the foreground page when Fennec comes back up.  Because like you say, that's a bad user experience.

There's a trade-off between quickly loading all tabs sometimes, and quickly loading the foreground tab more often.  I think it would be useful to explore that trade-off.  Do you agree?

I think that "when Fennec goes into the background, expire any inactive tabs which haven't been viewed in a while" is sufficiently similar to comment 0 that we can usefully discuss that proposal here.  If you disagree, I'd be happy to file a new bug.