In short, saving on client side disallows people from using Wikimedia as a free, persistent storage. If someone uses their sandbox for things unrelated to Wikimedia, admins can see that, delete the page and block the user if the behavior continues. However, if this storage is invisible to everyone else, admins cannot intervene in this way. This speaks in favor of client side storage.

On the other hand, people might want to continue writing on a different device, in which case server side storage is necessary.

If it interests you, I have made a gadget at svwiki that saves the wikitext to localStorage inside a setInterval. The JavaScript is at https://sv.wikipedia.org/wiki/MediaWiki:Gadget-AutoSave.js, the CSS is at https://sv.wikipedia.org/wiki/MediaWiki:Gadget-AutoSave.css and the definition (which includes the dependencies) is at https://sv.wikipedia.org/wiki/MediaWiki:Gadgets-definition. The wikitext can then be reached by clicking on "Saved wikitext" in #p-tb (the toolbox in the sidebar). The oojs-ui dialog includes buttons for:

• selecting the wikitext
• changing the minimum amount of characters that should be saved (which might sound silly at first, but is actually the most important setting because the gadget overwrites the same key in localStorage, and you don't want the gadget to overwrite a large wall of text with an empty or near-empty string)
• changing the time interval between the saves
• removing the saved wikitext.

In T184308#3880408, @Nirmos wrote:

In short, saving on client side disallows people from using Wikimedia as a free, persistent storage. If someone uses their sandbox for things unrelated to Wikimedia, admins can see that, delete the page and block the user if the behavior continues. However, if this storage is invisible to everyone else, admins cannot intervene in this way. This speaks in favor of client side storage.

On the other hand, people might want to continue writing on a different device, in which case server side storage is necessary.

Thank you, @Nirmos, for sharing your gadget! Could be super helpful. :)

In the Wishlist proposal and discussion, the reason for this functionality is to avoid losing work due to technical malfunction, not as a means of saving a work-in-progress edit to complete at a later time. I don't think the use case of continuing writing on a different device is pertinent to this project in its proposed scope.

Hey @DannyH, we need to talk with the Editing and Performance teams about this and download their knowledge before we start a technical investigation.

@Nirmos nice gadget. Please note however that all usage of localStorage should always be wrapped in try catches, and that to read the editor, it's better to use the jquery.textSelection module, as that manages syncing contents when syntaxhighlighting and similar types of programmatic changes to the content of textareas are made.

@kaldari As I spent some time on some of those LocalStorage patches in the past, here is my opinion on some of the issues this ticket might affect:

Use cases:

1. accidentally closing your browser or browser crash (or other form of session loss)
2. got lost in edit conflict resolution and want to try again
3. loss of connection
4. revert to an older intermediate copy of your work
5. save a private copy of your work so you can continue later (aka. Drafts)

Questions:

• Affected products ? VE, Flow, WikiEditor, Wikidata edits, content translation, mobile editor (CX already has autosaving btw.)
• How many page titles to save
• How long to save
• How many versions of a page to save
• Where/when do you restore a version ?
• When do you get rid of stored versions
• Saving an intermediate version to a different page target
• How to prevent abuse of serverside drafts (like making it a file hosting service)

Saving locally was good for recovery, when the browser crashes, dropped connections and user errors. It requires indexeddb or local storage. Sessionstorage won't do as your content is gone after restarting the browser, removing one of the big benefits. You also have limits on the amount of storage (esp. with localStorage) and this basically made it so that you can only save anything for one article at a time. However, local storage and indexeddb have no expiry of any form and are not bound to your user profile. As such they are problem for storing information on public computers.

Saving online stores a lot of content on the serverside, for which we need to deal with privacy policy etc. It's slower, but it's easier to save multiple drafts, to have auto expiry and to recover from whichever browser you want, whenever you want. We also already have edit stashing, with which some technology could potentially be shared ?

I think ideally, you would want to expand on the functionality of auto stash, and add some SessionStorage intermediate layer to deal with potential loss of connection issues (the only reason to do something locally).
Combining these technologies avoids the privacy concerns of local storage and indexeddb, you can have better resilience against connection loss and you enable private but longer term persisted drafts.

Possibly move the client side management of the logic into a ServiceWorker. Oh, and looking into the transactional model of VE changes, is also an interesting.

See optimistic save for more info on edit stashing.

A previous attempt: https://gerrit.wikimedia.org/r/#/c/5130/

Blocked by meeting with the Editing team, scheduled for Wednesday March 7, 2018

SG9tZVBoYWJyaWNhdG9yCk5vIG1lc3NhZ2VzLiBObyBub3RpZmljYXRpb25zLgoKICAgIFNlYXJjaAoKQ3JlYXRlIFRhc2sKTWFuaXBoZXN0ClQxOTcyODEKRml4IGZhaWxpbmcgd2VicmVxdWVzdCBob3VycyAodXBsb2FkIGFuZCB0ZXh0IDIwMTgtMDYtMTQtMTEpCk9wZW4sIE5lZWRzIFRyaWFnZVB1YmxpYwoKICAgIEVkaXQgVGFzawogICAgRWRpdCBSZWxhdGVkIFRhc2tzLi4uCiAgICBFZGl0IFJlbGF0ZWQgT2JqZWN0cy4uLgogICAgUHJvdGVjdCBhcyBzZWN1cml0eSBpc3N1ZQoKICAgIE11dGUgTm90aWZpY2F0aW9ucwogICAgQXdhcmQgVG9rZW4KICAgIEZsYWcgRm9yIExhdGVyCgpFVzZSC3IERpc2NsYWltZXIgtyBDQy1CWS1TQSC3IEdQTApZb3VyIGJyb3dzZXIgdGltZXpvbmUgc2V0dGluZyBkaWZmZXJzIGZyb20gdGhlIHRpbWV6b25lIHNldHRpbmcgaW4geW91ciBwcm9maWxlLCBjbGljayB0byByZWNvbmNpbGUu