Save form data for previous session history entries

NEW
Unassigned

Status

()

Firefox
Session Restore
P2
normal
4 months ago
7 days ago

People

(Reporter: JanH, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 months ago
At the moment, form data is saved only for the current page. So if you fill out a form, click a link and then go back, the form data is restored, but if you click the link and then close the tab/Firefox, after restoring the tab and going back, the form data isn't restored any more.

Unless I'm mistaken, form data for anything other than the currently loaded/displayed session history entry is kept within the PresState, so the idea would be to serialise (and later restore) that data similar to what was done in bug 1265818 for scroll positions.
The tricky bit is that within the PresState, the corresponding data is saved as a rather generic nsISupports-Pointer (https://dxr.mozilla.org/mozilla-central/rev/6be5c7d30d2def62a762ac187252eba626b23a92/layout/base/nsPresState.h#126), so I'm not sure how straightforward (de)serialising that data will be.
+1, this'd be a great feature, not just after restarts, but after a - * forbid - crash too.
Priority: -- → P2
(Reporter)

Comment 2

7 days ago
(In reply to Jan Henning [:JanH] from comment #0)
> The tricky bit is that within the PresState, the corresponding data is saved
> as a rather generic nsISupports-Pointer
> (https://dxr.mozilla.org/mozilla-central/rev/
> 6be5c7d30d2def62a762ac187252eba626b23a92/layout/base/nsPresState.h#126), so
> I'm not sure how straightforward (de)serialising that data will be.

I'm not actively working on this at the moment, but I did look a bit further at some point and the amount of different elements/classes that actually save some state here wasn't overly large. So one possible strategy might be to make those elements serializable and then switch out nsISupports for nsISerializable?
You need to log in before you can comment on or make changes to this bug.