639290 - Dataloss: Session Restore looses URLs, windows, tabs when crashing during restore

Status: RESOLVED WORKSFORME

(SeaMonkey :: Session Restore, defect)

Description

[Xuân Baldauf]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20101124 SUSE/2.0.11-0.2.1 SeaMonkey/2.0.11
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20101124 SUSE/2.0.11-0.2.1 SeaMonkey/2.0.11

When using Session Restore extensively (e.g. having 180 web pages open), it is quite likely that, when performin a session restore, the browser takes quite some time (e.g. 30 seconds) to complete the restore. It may also happen that restore takes forewever (due to some other internal bug or due to bugs in plugins). In this case, there is no other means to have a working browser than to kill the browser process.

Upon the second attempt of a session restore, many windows|tabs are lost. This means that the number of windows|tabs is smaller than before the first restore. This means that Session Restore is essentially useless and even harmful, as the user is tricket into being able to have a working style that does not need bookmarks as long as windows are being kept open.

Reproducible: Always

Steps to Reproduce:
1. Open 180 different browser windows to different web pages, some including flash content, some including PDF content.
2. Shutdown the browser gracefully (but ensure that Session Restore) will be active at the next start, or alternatively kill the browser.
3. Restart the browser. If the browser asks whether to run Session Restore, agree.
3. Kill the browser during session restore (that is, depending on your computer's speed, very shortly after the start of running Session Restore).
4. Restart the browser again. Run Session Restore again (or alternatively count the number of web pages offered to be restored).
Actual Results:  
The number of web pages actually restored is smaller than the number of web pages before the first shutdown (or kill) of the browser.

Expected Results:  
The number of web pages actually restored should be equal tothe number of web pages before the first shutdown (or kill) of the browser.

Comment 3

[therube]

As a work-around, you might look into the BarTab extension.
You will need the version 2.1b2.

https://addons.mozilla.org/en-US/firefox/addon/bartab/versions/

Works fine in SeaMonkey.  (It has an "Unload" feature that is not working in SeaMonkey, bug filed, nevertheless, it's awesome! <I have a lot of Session Restore windows too.>)

Comment 4

[Xuân Baldauf]

(In reply to comment #3)
> As a work-around, you might look into the BarTab extension.
> You will need the version 2.1b2.
> 
> https://addons.mozilla.org/en-US/firefox/addon/bartab/versions/
> 
> Works fine in SeaMonkey.  (It has an "Unload" feature that is not working in
> SeaMonkey, bug filed, nevertheless, it's awesome! <I have a lot of Session
> Restore windows too.>)

Well, thank you. However, BarTab only seems to work for tabs, not for windows. Using tabs is no option for me, as I need to switch between different windows (regardless whether they are browser windows or not).

So BarTab does not seem to be usable as a workaround in my case and nobody seems to care about the original bug. :-(

Comment 5

[therube]

(I didn't pick up on the /window/ aspect.)

Wonder if something like browser.sessionstore.max_concurrent_tabs could be extended to affect windows too?  Suppose it would have to be something like, restore no windows/tabs until manually refreshed (as there is no concept of the "current" window, since all 180 would have opened).  Something like that, if it existed, would help in your situation.

Another thought ... If you started in Offline mode?  All 180 would restore, nothing would load (except perhaps if cached), toggle online, then refresh the pages as needed?


(How do you manage 180 windows?  43 sounds like the maximum I've had, & most others would think that is a huge number.)

Comment 6

[Xuân Baldauf]

(In reply to comment #5)
> (I didn't pick up on the /window/ aspect.)
> 
> Wonder if something like browser.sessionstore.max_concurrent_tabs could be
> extended to affect windows too?  Suppose it would have to be something like,
> restore no windows/tabs until manually refreshed (as there is no concept of
> the "current" window, since all 180 would have opened).  Something like
> that, if it existed, would help in your situation.
> 
> Another thought ... If you started in Offline mode?  All 180 would restore,
> nothing would load (except perhaps if cached), toggle online, then refresh
> the pages as needed?
How do I start seamonkey in offline mode after a crash?

> 
> 
> (How do you manage 180 windows?  43 sounds like the maximum I've had, & most
> others would think that is a huge number.)
Well, I do not use tabs (as I think it is better to be able to switch between any pair of windows, regardless which application a window belongs to, than to be forced to have different switching gestures depending on which application the old window and the new window each belong). I think others may have that many tabs open as well. Managing is not that difficult, there is a list of windows (each represented by an icon and maybe some text) and the bottom of the desktop, they are roughly ordered chronologically, working is like adding windows to the stack and removing them if not needed anymore, each new window for a (sub-)topic to be explored.

Comment 7

[therube]

There is an -offline command line parameter.
Maybe that will help?
(Says it only works with Thunderbird, nonetheless works for SeaMonkey 2.0.x too.)

https://developer.mozilla.org/en/Command_Line_Options#-offline

seamonkey -offline

Comment 8

[Phoenix]

Tested with 50 windows, there was no problem with session restore, is this still reproducible with latest build?