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

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)?

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.

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

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

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

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.

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

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 ;)

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

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

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.

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

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

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

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

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

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

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

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

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

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.