Open
Bug 387598
Opened 17 years ago
Updated 2 years ago
save and restore contents of bfcache
Categories
(Firefox :: Session Restore, enhancement)
Firefox
Session Restore
Tracking
()
NEW
People
(Reporter: myk, Unassigned)
References
Details
(Keywords: helpwanted)
It would be useful for session restore to save and restore the contents of the bfcache, i.e. the current state of the DOM, including modifications that have been made to it, plus the current state of the JS context.
Then AJAX-heavy pages, as well as those that make simple DOM modifications and/or store state in JS variables (like Bugzilla's "Attachment Details" page when the "Edit Attachment as Comment" button has been pressed), can be restored to their previous state without losing context and user-entered data.
Comment 1•17 years ago
|
||
I think that would be way too much data for a crash recovery feature to store.
Comment 2•17 years ago
|
||
We should rather make sure that we correctly restore sessionStorage (bug 339445) and then let AJAX-heavy pages decide themselves what state they want preserved. Suggesting WONTFIX for Jesse's reason.
Whiteboard: [wontfix?]
Comment 3•16 years ago
|
||
That'd be way too much data to write to disk every 10 seconds. -> WONTFIX
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
Whiteboard: [wontfix?]
Comment 4•16 years ago
|
||
> then let AJAX-heavy pages decide themselves what state they want preserved
That's suboptimal, because it requires pages to opt-in to session restore. Many won't care, which means the overall user experience is not as good as it could be.
But I can understand that dumping the full state of the page to the disk every 10 seconds is indeed an overkill.
I filed a meta bug to track the cases, fixing which can bring us closer to the ideal of restoring the exact state of the page - bug 450465.
Blocks: 450465
Comment 5•16 years ago
|
||
Well, you'd only have to write the net-changed state from those 10 seconds, necessarily. WONTFIX means "we prefer not saving bfcache to saving it, inherently, without regard for quality of implementation"; it's quite a tall bar. Filesystem techniques manage to save incrementally through good use of buffering and data, which makes me suspect that the theoretically-small set of changes that would need to be captured, given the initial page already being in the cache would be quite achievable in an async manner.
Not to say that you should work on it, Simon, but that we shouldn't reject the entire capability space completely, as WONTFIX would seem to.
No longer blocks: 450465
Comment 6•16 years ago
|
||
(In reply to comment #5)
Yeah, you're right: patches are welcome ;-)
The plan would thus be:
1. Use the bfcache code for serializing the currently visible pages.
2. Make sure that we have a hasChanged flag to allow incremental saving.
3. Ideally we could also just write out what's actually changed.
4. Have a way for re-loading such a saved dump.
5. For performance reasons, have a pref for limiting the maximum amount of data being written out per 10s and in total (think thumb drives and network drives).
6. Consider doing this only for pages using JavaScript (unless non-dynamic pages only have a neglectable perf impact).
7. (optional) Have users complain that we still don't get plug-ins restored correctly . ;-)
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Reporter | ||
Comment 7•16 years ago
|
||
We might also use the idle service to detect good times to save more data.
Updated•16 years ago
|
Keywords: helpwanted
Updated•16 years ago
|
Status: REOPENED → NEW
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•