387598 - save and restore contents of bfcache

Status: NEW

(Firefox :: Session Restore, enhancement)

Description

[Myk Melez [:myk] [@mykmelez]]

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

[Jesse Ruderman]

I think that would be way too much data for a crash recovery feature to store.

Comment 2

[Simon Bünzli]

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.

Comment 3

[Simon Bünzli]

That'd be way too much data to write to disk every 10 seconds. -> WONTFIX

Comment 4

[Nickolay_Ponomarev]

> 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.

Comment 5

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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.

Comment 6

[Simon Bünzli]

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

Comment 7

[Myk Melez [:myk] [@mykmelez]]

We might also use the idle service to detect good times to save more data.