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)
Firefox
Session Restore
Tracking
()
NEW
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.
Comment 1•7 years ago
|
||
+1, this'd be a great feature, not just after restarts, but after a - * forbid - crash too.
Updated•7 years ago
|
Priority: -- → P2
Reporter | ||
Comment 2•6 years 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?
Comment 3•6 years ago
|
||
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.
Blocks: fission-history
Comment 4•4 years ago
|
||
Not a blocker for fission-history
No longer blocks: fission-history
Depends on: fission-history
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•