653949 - Starting Firefox after it is killed in the background can result in loss of session

Status: RESOLVED INVALID

(Firefox for Android Graveyard :: General, defect)

Description

[CoJaBo]

User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: 4.0.1

When Firefox is not running, starting it from another app (e.g. link in Gmail)
will load only that page, not providing access to the "tabs from last time" page
to restore the last session.

A closely related issue is that Firefox will not always automatically restore
tabs when it has been idle and unloaded, i.e. instead of restoring them automatically, just goes to the "tabs from last time" page.

Firefox mobile as of 4.0.1 unloads itself far more frequently than 4.0 (nearly every time it is switched away from- I am not sure if this is itself a bug),
making this data loss a much more frequent occurrence.

Reproducible: Always

Steps to Reproduce:
1. Open some tabs
2. Exit Firefox (using exit addon, reboot phone, kill it, or wait a while and Firefox exits itself)
3. Open a link from another app, such as an email in Gmail or news feed reader.

Actual Results:  
The page is loaded as the sole tab.

Expected Results:  
The page should loaded as the foreground tab, with the restore session tab still present. (If Firefox was unloaded automatically, the prior tabs should load automatically as background tabs)

I've marked this critical, as losing session data every time a link is opened is a rather serious loss of functionality.

Comment 1

[Aaron Train [:aaronmt]]

Hi CoJaBo

Thanks for filing this bug. I was able to reproduce this with your steps provided, albeit I am not certain if this is a flaw or an intentionality. It would appear that when external links are opened, there is a focus on solely loading the desired page. One is able to restore all previously opened tabs afterwards by going to about:home (not very obvious unfortunately). Mark, is this deliberate?

Comment 2

[CoJaBo]

The expected scenario is that, unless Firefox is explicitly exited (a function that is itself only implemented by addon), the session is preserved.
Opening a link from another application should not destroy the old session- that is inconsistent both with the behavior of the desktop version and user expectations.

Additionally, Firefox should never return to the "tabs from last time" page when it has just been idle for a while (sometimes as little as a few seconds when switching away to check an email)- it is not generally expected that the browser should "close down" every time it is switched away from, it should simply resume the session where the user left off. I am not sure if this is related to this issue or is in fact bug 645340 (i.e., is it unloading itself intentionally for some - perhaps ill-advised - reason, or is it actually crashing in the background?)

Comment 3

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to comment #2)
> The expected scenario is that, unless Firefox is explicitly exited (a function
> that is itself only implemented by addon), the session is preserved.
> Opening a link from another application should not destroy the old session-
> that is inconsistent both with the behavior of the desktop version and user
> expectations.
To be clear, opening the link from an external app isn't destroying the session. Firefox is getting killed by the OS, most likely be cause that other application needed more resources. So we're restarting from a dead state in this case. 

On my Atrix, which is beefy and thus doesn't run out of resources very often, I don't see this behavior where as I do see it on a nexus one.

> 
> Additionally, Firefox should never return to the "tabs from last time" page
> when it has just been idle for a while (sometimes as little as a few seconds
> when switching away to check an email)- it is not generally expected that the
> browser should "close down" every time it is switched away from, it should
> simply resume the session where the user left off. I am not sure if this is
> related to this issue or is in fact bug 645340 (i.e., is it unloading itself
> intentionally for some - perhaps ill-advised - reason, or is it actually
> crashing in the background?)

Again, I assume we're being killed by the OS to free up resources. The metric we're using for doing a full session restore versus the tabs from last time page is 10 seconds. Not sure if that's tunable or not though.

Comment 4

[CoJaBo]

> To be clear, opening the link from an external app isn't destroying the
> session.
This particular bug is that it _is_ destroying the session. When Firefox is cold-started from an app, regardless of the reason it was exited, the session restore GUI is not presented- the session is, for all intents and purposes, lost (unless you happen to know the URL to the about:home page).

> I assume we're being killed by the OS to free up resources. The metric
> we're using for doing a full session restore versus the tabs from last time
> page is 10 seconds. Not sure if that's tunable or not though.
The wont-stay-running issue is what led me to find this bug. 4.0.0 did not exhibit this behavior to such a profound degree- it would unload if left running in the background for a long time as expected of Android and as all other browsers do, but as of 4.0.1 I cannot even briefly check a text or email without having Firefox reload when I return. I.e., this is a recent issue.

As for the wont-load-tabs-automatically issue, this should be a fairly easy fix- Android has an event that fires when an app is likely to be unloaded. Firefox should store a flag or something in the session to load automatically next time. Considering Firefox lacks an "exit" option, this would probably be every single time... (presumably, an last-booted-time check could be added if it is deemed undesirable to persist this across rebooting the phone). Point being, the browser should hide the fact that it is being unloaded at all by reloading the session automatically- all other Android browsers do this, and it makes a more consistent experience to the user to not be disrupted by internal OS issues.

I can file separate bugs for these two issues if need be?

Comment 5

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

(In reply to comment #3)

> Again, I assume we're being killed by the OS to free up resources. The metric
> we're using for doing a full session restore versus the tabs from last time
> page is 10 seconds. Not sure if that's tunable or not though.

Should be 1 hour:

http://mxr.mozilla.org/mozilla-central/source/mobile/app/mobile.js#141

Comment 6

[Anna (Waverley)]

It seems to me as being the right behavior.
If I quit fennec using the Quit add on, when I open a link from other application, it just opens in a new sole tab. If I open "about:home" I can see the "tabs from last time"

If I kill fennec using the Advanced task manager, when I open a link from other application it opens in a new tab alongside the tabs I had previously killing fennec.

Should I invalidate this bug?

Comment 7

[CoJaBo]

The issue, as I experience it, is that if I leave Fennec for an hour, and later open
a link from another app, all session data is "mysteriously" gone.
In this case, Fennec was never exited and the behavior is very clearly wrong.

I originally proposed that "The page should loaded as the foreground tab, with the restore session tab still present."-
but I now believe a better fix would be to stop Fennec from setting its session resume to a "not running"
state after an arbitrary (1 hour) time limit expires, and instead always auto-reload the session
unless the user had explicitly exited Fennec (which is only do-able from an addon at this time).
If that is done, the current behavior of not loading the "tabs from last time" page
when a link is opened from another app would indeed be perceived as correct (and consistent with the
desktop version), since it would only happen when the user had actually intended to discard the session.

If I need to file a different bug for the "Session not being restored after 1 hour" issue,
you may close this bug and I will do so.

Comment 8

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

(In reply to comment #7)
> The issue, as I experience it, is that if I leave Fennec for an hour, and
> later open
> a link from another app, all session data is "mysteriously" gone.
> In this case, Fennec was never exited and the behavior is very clearly wrong.

This is in fact exactly what Fennec is supposed to do. The "timeout" for sesssion is here:
http://mxr.mozilla.org/mozilla-central/source/mobile/app/mobile.js#141

Notice that after 1 hour (60 minutes) Fennec is designed to "forget" the last session. The reason being that session is for crashes and not normal browsing. If you close fennec and reopen it after a day, do you _really_ want the exact same session you were using the day before? We thought the answer in general is "no", but you can change that preference using about:config to extend the timeout.

Comment 9

[CoJaBo]

If I had closed Fennec, I expect it not to restore the session regardless of time limit.
But note that on the Android platform, which is multi-tasking, switching away from an app is _not_ the same thing as closing it. If I get a long phone call, I expect my session to still be there, as I left it, when I hang up and go back to browsing.
Android, due to memory considerations, unloads apps running in the background sometimes. All apps that need to maintain a session must save and restore it automatically to mask this internal Android OS quirk. All other Android browsers do this, because it is what the user expects- Firefox 4.0 for desktop doesn't exit just because it is minimized and the user went out to lunch, does it? Neither should Fennec.

The problem, it seems, may be that Fennec is using sessions for solely for crash recovery- even though on the Android platform, sessions are also required to allow the application to seamlessly persist in an environment where it is loaded and unloaded dynamically by the OS.

Comment 10

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

Restoring from session is a good idea, unless it's not what you expect. Say I have not used Fennec in a day or so, then I start it up and it loads the 5 tabs I was viewing the last time I had it open. I would not be happy. The time taken to open the old tabs and the potential memory used by those tabs are not what I expect.

Fennec purposefully does not load the old session after 1 hour of non-use. If 1 hour is too short, we can talk about increasing it. I do not think we will remove the timeout altogether.

If you start Fennec and the session is not auto-loaded becasue of the timeout, you can always use the Home page to open all (or some) of the previously open tabs. See "Tabs from last time" on the Home page.

Comment 11

[CoJaBo]

If I left a desktop browser minimized for a year, I don't see why it shouldn't still be there when I come back. Granted, upping the limit to a day by default would cover virtually all normal use cases, I imagine, I just don't get the point of having a limit at all. Note that in practice, the limit is going to be _completely random_- whether or not Fennec actually restores session after an hour/day/whatever is going to depend on the device and what apps were used in the mean time. This is confusing, and may well lead to oodles of "Fennec crashes [doesn't restore session] after I use MemoryHoggingApp v1.0" bugs.

Now if I shut the phone off for the night, I might be confused to see those tabs pop up when I turned it back on. That should be resolvable by checking the last-booted time (should be a way to retrieve this)- if it is different, then don't restore the session automatically.

It would also be nice if the quit addon could be merged into Fennec, that way a user could easily exit whenever they decided they don't want any session saved.

This seems like a better alternative than trying to just guess how long an individual user goes before not wanting their session restored.

Comment 12

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

You are making a big assumption here. Fennec restores the session because Android killed it in the background, not because it was "minimized". If Fennec was not killed in the background, the session comes back exactly as you left it.

Comment 13

[Matt Brubeck (:mbrubeck)]

(In reply to comment #12)
> You are making a big assumption here. Fennec restores the session because
> Android killed it in the background, not because it was "minimized". If
> Fennec was not killed in the background, the session comes back exactly as
> you left it.

I think that's exactly what comment 11 was complaining about - after you put Fennec in the background (more or less like "minimizing" it from a user point of view), whether the session is still there when you return to Fennec depends on whether it's killed in the meantime, which is neither controllable nor predictable.

Comment 14

[Matt Brubeck (:mbrubeck)]

(In reply to comment #8)
> Notice that after 1 hour (60 minutes) Fennec is designed to "forget" the
> last session. The reason being that session is for crashes and not normal
> browsing. If you close fennec and reopen it after a day, do you _really_
> want the exact same session you were using the day before?

Maybe?  Certainly if I'm in the middle of reading a web page and then use Google Navigation to drive somewhere for an hour, I expect to continue reading the same page when I go back to Fennec at the end of the drive.  Navigating to about:home is a workaround, but I don't think it's an ideal one.

Comment 15

[CoJaBo]

This is indeed what I am pointing out- from a user standpoint, switching to another app in Android is analogous to minimizing a desktop app. From a technical standpoint, the Android app must do some extra work because it- unlike a desktop app- might get terminated in the meantime, depending on low-level OS stuff the user shouldn't have to be exposed to.

Again, a browser app must hide the fact that this unpredictable "computer stuff" is going on behind the scenes in order to ensure a consistent and logical user experience. The app should not appear to the user to have been closed, unless the user closed it (or rebooted the phone), period.

Note that the original report and steps to reproduce are quite clearly incorrect now- the request was to make the "tabs from last time" page load alongside a tab opened from another app, which is neither necessary or desirable if Fennec restores its session properly (and thus avoids going to that page when the user expects the browser to still be running).

Because of this, I've submitted bug 656062- this one should be closed as INVALID, and any discussion on this issue should proceed there.