Open Bug 1400578 Opened 7 years ago Updated 2 years ago

Save form data for previous session history entries

Categories

(Firefox :: Session Restore, enhancement, P2)

enhancement

Tracking

()

People

(Reporter: JanH, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

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
(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?
Depends on: 1438026
This will probably be handled by my rewrite of SessionHistory I am doing in bug 1438272, as the state will become easier to serialize and move into the parent process.

Not a blocker for fission-history

No longer blocks: fission-history
Depends on: fission-history
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.