41171 - window State Saving

Status: RESOLVED WORKSFORME

(SeaMonkey :: UI Design, enhancement)

Description

[Jeremy M. Dolan]

I think it would be very handy to be able to save Mozilla's state between runs.

What does this mean? Saving state means we would save the current open windows
list of mozilla. If I quit with 2 browsers windows open, a mail window open, and
a manage bookmarks window open, when I restart, those are all reopened. The
current URL of the browser windows are stored as well, which is the most
important enhancment state saving would bring. Geometry for each window should
also be preserved.

Implementation Idea: If user has turned on state saving, when user quits, create
a new folder in the bookmarks file named 'Current State'. When starting the
browser, if this folder exsists, load all of its bookmarks, and delete it.

The option to turn this on in Preferences could be a radio under Appearance:

When Mozilla starts up,
 (*) Open...
     [X] Navigator
     [X] Mozilla Mail
     [ ] Composer
 ( ) Restore previous state

Comment 1

[Jesse Ruderman]

I posted a series of bugs several months ago with a similar goal:

bug 33328  NEW        Fut  [RFE] dump all urls to clipboard or text file  
bug 33334  RESO WONT  M20  [RFE] Hyperlink URLs in text/plain and *.txt  
bug 33335  VERI DUPL  ---  [RFE] Allow user to "open all links" from page

Text files have the advantage of being more portable and easier to work with, 
but saving the entire state allows you to save things such as partially-filled-
in forms and scroll positions.

One question about your rfe: do you reload the page from the server before 
filling in the forms, or do you load the page from the cache?  What if the page 
tells you not to cache it (something likely to show up on a page with forms 
that requires you to log in in order to reach it)?

Comment 2

[Matthew T (active 1999-2002)]

Ideally, if you close a window (or quit Mozilla) after changing non-trivial form 
data in a page (or even after a reproducable series of DOM changes?), Mozilla 
should ask you if you want to save changes to the page -- just as it would for 
Composer or for an e-mail message. (Well, in many such cases it *will* be an
e-mail message, on a Webmail account.) When you restarted, this page would be 
opened from cache, even where the page's own caching information said not to. 
Maybe we'd offer password-based encryption of the saved page?

If Mozilla crashed, however, when it restarted it should probably show a generic 
page (see bug 28586) until the user clicked `Reload', at which time the page 
would be opened from cache as before. Clicking `Reload' for a second time would 
actually reload the page from the server.

In both these cases, `cache' should refer not to the normal disk cache, but to a 
special cache (of unlimited, but usually very small, size) which is specifically 
for holding files between sessions. That way the behavior wouldn't change 
depending on whether or not the normal disk cache had been cleared or had zero 
size or whatever.

Hmmm, this needs a more thorough spec ...

CCing Pete Collins -- this would almost certainly be an offshoot of 
Alphanumerica's Crash Recovery.

Comment 3

[Pete Collins (MDG)]

As Matthew said, i have already started with an initial implementation.

Attaching diffs and files to be added for a unix build.

Would love to see this land in M17.

pete

Comment 4

[Pete Collins (MDG)]

Attachment: DIFFS

Comment 5

[Pete Collins (MDG)]

Attachment: JS File crash.js

Comment 6

[Pete Collins (MDG)]

Attachment: io.js I already had this lib file reviewed by Brendan and DougT, I will check it in to the tree for M17

Comment 7

[Chris McAfee]

m18 to get this looked at soon since we have patches & stuff.

Comment 8

[Pete Collins (MDG)]

this bug http://bugzilla.mozilla.org/show_bug.cgi?id=36810

i think will solve this bug. You might want to mark this one as a dupe.

pete

Comment 9

[Claudius Gayle]

I'd like to hold this open for now as this bug calls for some very specific state saving things(urls, geometry,and a simple pref) 
that I'd like to see, and until I see the actual implementation for bug 36810 I won't know if those are actually covered.

Comment 10

[Blake Ross]

Reassigning 79 Bookmarks bugs to Ben.  I was told this was going to be done 
shortly about two months ago, but it clearly hasn't been.  I think that's long 
enough for all these bugs to remain assigned to nobody.

Feel free to filter all this spam into the trashcan by looking for this string 
in the message body: ducksgoquack

Comment 11

[Ben Goodger (use ben at mozilla dot org for email)]

I favour the approach suggested by the reporter in this bug better than that
offered by the patches attached.

1) A toplevel menu in Navigator is inappropriate
2) State saving should not be linked to 'crashes,' rather, just be something
that you can enable (and global history should be fixed not to die when a crash
happens).
3) Your patch appears to add merge conflicts and non localizable text ;)

Comment 12

[Matthew T (active 1999-2002)]

[Not Bookmarks, --> XP Apps. Keeping Claudius as QA since he's actively 
interested in the bug.]

Comment 13

[Paul Chen]

nav triage team:

Would be very nice to have, but don't think we have time in beta1. Marking 
nsbeta1-

Comment 14

[sairuh (rarely reading bugmail)]

spam: over to File Handling. haven't changed the current owners, but i did take
qa contact for the nonce. pls do retriage/reassign if needed.

Comment 15

[Jesse Ruderman]

See also bug 102130, a similar rfe specific to tabbed-browsing mode.

Comment 16

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 17

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 18

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 19

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 20

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 21

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 22

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 23

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420

Comment 24

[Karsten Düsterloh]

This is covered by our "Session Restore" feature.
Browser parts are already working, hence marking this WFM.
MailNews/other windows still to come, but in different bugs.