Feature summary (what you would like to be able to do and where):
To be able to make edits recover we will need the ability to

1. save while typing,
2. restore when reopening and
3. delete when saving or cancelling.

There will be no UI developed as part of this task.

Acceptance criteria

• Edits to all of a page's edit form fields are stored locally while typing. This should include the normal textarea and summary (which is also the new-section subject), as well as other core fields such as watchlist expiry and those from extensions such as ProofreadPage (which adds two textareas) or FlaggedRevs. It should work with all content models (e.g. CSS and JSON, which can be restored in the same way as wikitext).
• Last saved state of the form fields is restored when a given page is re-opened.
• Stored data is cleared if the page is saved, or editing is cancelled.
• Feature is controlled by a feature flag $wgEnableEditRecovery. Note that this doesn't include clearing data if the feature is enabled and then disabled; that will be done in T341853.

Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):

• As an editor with unsaved changes, I could experience a power outage and I would like my changes to be safe.
• As an editor with unsaved changes, when I open a page that I have previously been editing but haven't saved, I would like my changes to be restored.
• As an editor, if I am editing a page that has been restored and I publish it, then when I return to it after someone else has edited it I don't expect my changes to be restored.
• As an editor, if I am editing a page that has been restored and I cancel, then when I return to it I don't expect my changes to be restored.

Benefits (why should this be implemented?):

• prevention of accidental change loss

Related Conversations
https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2023/Edit-recovery_feature