1034038 - [Session Restore] Inform the user when Session Restore cannot save the session

Status: NEW

(Firefox :: Session Restore, defect)

Description

[David Teller [:Yoric] - still alive but not very active]

At the moment, several issues can prevent Session Restore from saving the session:
- disk full;
- cannot write to this directory;
- out of memory (we have occurrences of this in the wild);
- internal XHR errors;
- ...

We need a mechanism to inform users that there is a problem.

Comment 1

[David Teller [:Yoric] - still alive but not very active]

Note that either of these errors kind of screams "You should quit Firefox now, before you lose your data."

Comment 2

[Tim Taubert [:ttaubert] (inactive)]

Seems partly like a UX issue... While we can show something while failing to write sessions it would be hard to catch those failures as afaik they can basically occur anywhere. Also, what are we supposed to tell the user? How can they recover from that situation? Is there any value in telling them at all when they can't do anything about it?

(In reply to David Rajchenbach Teller [:Yoric] from comment #1)
> Note that either of these errors kind of screams "You should quit Firefox
> now, before you lose your data."

Sorry but this is nonsense. It would much more interesting to know why they still can use Firefox and load big pages but sessionstore can't work properly anymore. Telling users to restart seems like a really bad and only temporary solution. At the moment we notice they already have lost data.

Comment 3

[David Teller [:Yoric] - still alive but not very active]

Note that I marked this bug as uiwanted.

When we notice, they have lost a few seconds worth of data. If they continue, they may lose hours or days, which is distinctly not cool. See bug 581510 or bug 903621 for real-world examples of OOM. Full hard drive is beyond our control. As for directory or file not being write-accessible, if this happens, this is probably the fault of some external program such as an anti-virus or a backup mechanism.

Comment 4

[Seb A]

(In reply to Tim Taubert [:ttaubert] (away July 7th-18th) from comment #2)
> Seems partly like a UX issue... While we can show something while failing to
> write sessions it would be hard to catch those failures as afaik they can
> basically occur anywhere. Also, what are we supposed to tell the user? How
> can they recover from that situation? Is there any value in telling them at
> all when they can't do anything about it?

Well, restarting Firefox does fix it (in the case of OOM), even when reloading the same session (e.g. by killing the Firefox process and using Crash Recovery), at least for a while. It also gives the user the option of not restoring all their tabs if they no longer require all of them. Simply closing tabs with Firefox in the broken Cannot-save-session state does not make Session Restore resume saving state.

I suggest a pop-up error message saying something like: '
Due to an error, Firefox is not able to save session information.
[Report Error] -> sends a backtrace to some pre-determined bug or bugs (possibly depending on the shape of the backtrace)
[Restart Firefox] [Ignore the problem and continue working]
' (end quote), where [This is a button], the [Report Error] button does not close the dialog. Alternatively, it could be a checkbox.

> (In reply to David Rajchenbach Teller [:Yoric] from comment #1)
> > Note that either of these errors kind of screams "You should quit Firefox
> > now, before you lose your data."
> 
> Sorry but this is nonsense. It would much more interesting to know why they
> still can use Firefox and load big pages but sessionstore can't work
> properly anymore. Telling users to restart seems like a really bad and only
> temporary solution. At the moment we notice they already have lost data.

No, I agree with :Yoric. In most cases, the user would want to restart Firefox if it is an OOM problem. If it is a disk full or permissions problem, they should look into that (and a message saying what the problem (in non-technical terms) in this case would be helpful). If they can do nothing to fix it (e.g. bad permissions set by the Domain Admin) they should press the Ignore button.

Of course, it is still interesting to know why they can still use Firefox... For what it is worth, my sessionstore was not updating today and I could post comments to bugs and load crash reports. I then tried to load a tab I had from a previous session that is js heavy (I presume, given what I know it does) and Firefox crashed.

Comment 5

[David Teller [:Yoric] - still alive but not very active]

Random idea: it might actually be a good idea to crash on OOM.
Note that in case of XHR error, we already crash during shutdown.

Comment 6

[Tim Taubert [:ttaubert] (inactive)]

We're currently working on making more allocations fallible everywhere else, so this doesn't seem like a good idea.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

(Not clear what the needinfo here was for, Tim seems to have it covered.)

Comment 8

[Will Wang [:WillWang]]

Sort as ss-reliability, however could be ss-feature as well.

Comment 9

[John Drinkwater (:beta)]

Found another instance of this, when too many tabs are open Bug 1472470, in that case asking the user to close a few tabs would be more sensible than requesting a restart.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 31 votes.
:dao, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 11

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.