702501 - Tab groups can be lost when Firefox crashes or is terminated.

Status: RESOLVED DUPLICATE of bug 637148

(Firefox :: Session Restore, defect)

Description

[Curtis Clauson]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0
Build ID: 20111102223350

Steps to reproduce:

Sometimes Firefox crashes or has to have the process terminated because it will not close on its own (various reasons). If another process, like an installation, then brings up a browser window before you can manually re-open Firefox, it will only have the one tab and the Restore Sessions page will not be displayed (Automated browser invocations are now quite common so this problem is occurring much more often).

When you close that window and open Firefox again, it will have only one tab with your home page and all of your tab groups (session info) will be permanently lost. No Restore Sessions page will be displayed. The sessions backup files that exist during both browser invocations no longer contains the lost session information.

Tab groups are amazingly important to those of us who heavily use our browser between many different projects. We'll have tab groups for each on-going session while we collect the information we need to decide which page URLs must be bookmarked. I regularly have over 15 tab groups with from 10 to 40 tabs at a time. The loss of all of that session tab group information is a tremendous problem.


Actual results:

All tab groups and session information is permanently lost.


Expected results:

The Restore Sessions page should have come up in an additional tab when the automated process brought up the single page, and/or it should have come up when the single-page invocation was closed and Firefox was re-opened.

The session information files should not have lost the last session on the automated invocation.

Additionally, we should be able to use menu items to access and restore the last set of tab groups available. The tab groups should be in an accessible file that we can back up in case Firefox loses track of a lost session.

In short, we should always be able to reclaim a lost session even if Firefox has been opened and closed since the session was lost. In-app session information management functions that allow us to define, edit, and restore one or more session and tab groupings backups should be available. We should be able to define, edit, and restore tab groups either as a whole, a sub-set of groups, or an individual group.

Comment 1

[Curtis Clauson]

A little more thought on the subject has me not liking only having functions for manually creating session backups. A better solution might be to create multiple automated session cache files, the number can be made configurable, where you have the normal session file for the last session and a list of files for previous sessions each of which contain what is different from the next later file. This means that, when a new session is invoked, the current session file is re-named to a new unique name, the last session file is erased, and the last session file will be constantly updated with the differences from the current as changes are made. Any other session file previous to the last does not need to be changed with the exception of when the number of files exceeds the configured count, then the last file would be deleted.

The Restore Session page could then additionally allow you to choose which cached session you want to restore. An in-app function can be added to allow you to restore a cached session from the provided list. This should also include a function to save a cached session to a file and to restore a cached session from a file. The user should be able to easily edit a session file. If it is saved as XML, there should be an session editor app since XML was never designed to normally be edited simply as text (In other words: you can but you shouldn't have to).

This kind of a process would automate normal usage in a configurable fashion while allowing the user to manually expand usage for abnormal situations.

Comment 2

[brunoais]

(In reply to Curtis Clauson from comment #1)
> A better solution might be to create
> multiple automated session cache files, the number can be made configurable,
> where you have the normal session file for the last session and a list of
> files for previous sessions each of which contain what is different from the
> next later file. This means that, when a new session is invoked, the current
> session file is re-named to a new unique name, the last session file is
> erased, and the last session file will be constantly updated with the
> differences from the current as changes are made. Any other session file
> previous to the last does not need to be changed with the exception of when
> the number of files exceeds the configured count, then the last file would
> be deleted.
> 
> The Restore Session page could then additionally allow you to choose which
> cached session you want to restore. An in-app function can be added to allow
> you to restore a cached session from the provided list. 

I like that solution That way we could go back in time without the need of us, users, make backups of sessionrestore.js all the time.

Comment 3

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Curtis, thanks for taking the time to file this and give us your thoughts.

> When you close that window and open Firefox again, it will have only one tab
> with your home page and all of your tab groups (session info) will be
> permanently lost. No Restore Sessions page will be displayed. The sessions
> backup files that exist during both browser invocations no longer contains
> the lost session information.

I took this to be the root problem here so I'm marking this a duplicate of a very similar bug.(In reply to Curtis Clauson from comment #1)

> A little more thought on the subject has me not liking only having functions
> for manually creating session backups. A better solution might be to create
> multiple automated session cache files, the number can be made configurable,
> where you have the normal session file for the last session and a list of
> files for previous sessions each of which contain what is different from the
> next later file. This means that, when a new session is invoked, the current
> session file is re-named to a new unique name, the last session file is
> erased, and the last session file will be constantly updated with the
> differences from the current as changes are made. Any other session file
> previous to the last does not need to be changed with the exception of when
> the number of files exceeds the configured count, then the last file would
> be deleted.

We actually have bug 558425 on file to create multiple backups. A contributor started working on it recently.