Community Tech/Auto-save edits
This is the project page for Auto-save edits in the VisualEditor and 2017 Wikitext editor, the #7 wish in the 2017 Community Wishlist Survey. You can follow this page and get updates as the Community Tech team starts working on this wish.
This page documents a project the Wikimedia Foundation's Community Tech team has worked on or declined in the past. Technical work on this project is complete.
We invite you to join the discussion on the talk page. You may track this project's progress on T57370.
This project aims to protect more edits from loss during browser and computer crashes.
Status
editMarch 7, 2018
editThe mw:Editing team has single-handedly wrapped up this wish. They've done incredible work and we're grateful for that.
The primary ticket (phab:T57370) is closed now and the feature is rolling out this week, expected to land on all Wikipedias by March 9.
How this feature works: If one is editing using VE or 2017 Wikitext Editor and in the middle of an edit the tab is accidentally closed or it crashes or the browser crashes, if the same tab is opened back in the same browser - the edit text will still be available.
The edit data will be available for all of the tabs that lost their edits. When the tab is restored you will get a flash message saying that your changes have been recovered.
This data is stored using SessionStorage in the browser. This is why the edit data cannot be restored on a different browser or device. There is no time limit on how long this data will be available for. The edit is auto-saved every time the user hits space or if there's no activity after a second.
Note that if the user attempts to close the tab and clicks "Discard edits" when prompted to save them, that edit data will be discarded and not retained. This feature is not meant to be used for creating draft edits because the data is saved in the browser and any edit left open for too long will eventually result in an edit conflict when attempted to be saved.
February 21, 2018
editThe Community Tech team will be meeting with the Editing team next week to discuss this project in depth.
January 4, 2018
editOn the VisualEditor, the browser doesn't cache automatically. Can we make something more robust? We could use the parsing team's work to help performance by sending parsing API requests? We might be able to use that for restoration.
There was a WMF server side version of this functionality a few years ago — Extension:Drafts — but it was downvoted for being a potential secret wiki storage which would be a concern for audio or video for copyright violations, but secret text sharing is pretty hard to see the harm. The leading use case for this feature is short term caching that only lasts 5 hours, or a day. This could help deal with copyright violation concerns. The information could get saved in memcache and then purged on save or 5 hours later.
Research to do:
- Client side or server side?
- Is the WMF's Editing team best suited to work on this? (We should talk with them!)
December 13, 2017
editThe team will start investigating this project early in 2018. If you've got suggestions or questions, please write your thoughts on the talk page!
Important links
edit- Wishlist proposal, discussion and votes
- Phabricator tickets tracking the work: T57370
Rationale
editxx
Requirements
editxx
Open questions
editxx