Status

--
enhancement
RESOLVED WORKSFORME
19 years ago
2 years ago

People

(Reporter: jmd, Unassigned)

Tracking

({helpwanted})

Trunk
helpwanted

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

19 years ago
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

19 years ago
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

19 years ago
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

19 years ago
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

19 years ago
Created attachment 9870 [details]
DIFFS

Comment 5

19 years ago
Created attachment 9871 [details] [diff] [review]
JS File crash.js

Comment 6

19 years ago
Created attachment 9872 [details]
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

18 years ago
m18 to get this looked at soon since we have patches & stuff.
Target Milestone: --- → M18

Comment 8

18 years ago
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

18 years ago
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

18 years ago
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
Assignee: slamm → ben
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 ;)
Status: NEW → ASSIGNED
Target Milestone: M18 → Future

Comment 12

18 years ago
[Not Bookmarks, --> XP Apps. Keeping Claudius as QA since he's actively 
interested in the bug.]
Component: Bookmarks → XP Apps

Comment 13

18 years ago
nav triage team:

Would be very nice to have, but don't think we have time in beta1. Marking 
nsbeta1-
Keywords: nsbeta1-
Keywords: helpwanted
Priority: P3 → P4
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.
Component: XP Apps → File Handling
QA Contact: claudius → sairuh

Comment 15

17 years ago
See also bug 102130, a similar rfe specific to tabbed-browsing mode.
QA Contact: sairuh → petersen

Updated

16 years ago
Component: File Handling → XP Apps: GUI Features
Summary: [RFE] State Saving → window State Saving
Product: Core → Mozilla Application Suite
Assignee: bugs → nobody
Status: ASSIGNED → NEW
Priority: P4 → --
QA Contact: chrispetersen → guifeatures
Target Milestone: Future → ---

Updated

10 years ago
Component: XP Apps: GUI Features → UI Design

Comment 16

9 years ago
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
Status: NEW → UNCONFIRMED

Comment 17

9 years ago
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

9 years ago
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

9 years ago
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

9 years ago
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

9 years ago
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

9 years ago
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

9 years ago
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
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → EXPIRED

Comment 24

8 years ago
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.
Resolution: EXPIRED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.