VisualEditor: Implement some form of auto-save
Open, NormalPublic40 Story Points

Description

With wikitext editing, people work around this by writing long articles in word, or relying on browsers remembering form data if it crashes.

Perhaps with local storage we can take periodic snapshots of DM HTML, or even the entire surface state (DM data, IV store, internal list, transaction history etc.) and offer to restore it if the changes went unsaved.

See also:

  • T39992 - Review and deploy Drafts extension to Wikimedia wikis
  • T75241 - Auto-save to increase chances of lost edits recovery

Details

Reference
bz55370

Related Objects

bzimport raised the priority of this task from to High.
bzimport set Reference to bz55370.
Esanders created this task.Oct 6 2013, 3:32 PM

Why not deploy the drafts extension, and add any VE support needed?

(In reply to comment #1)

Why not deploy the drafts extension, and add any VE support needed?

[[mw:Extension:Drafts]], for those unfamiliar.

(In reply to comment #1)

Why not deploy the drafts extension, and add any VE support needed?

Have commented there explaining.

jayvdb added a comment.Oct 9 2013, 1:50 AM

If local storage is going to be seriously considered, with pages being auto-saved, some issues to consider:

How many open VE's can be autosaved? Only saving one VE session makes management very simple, but it is probably sufficient for only a small subset of the editing community.

The local storage limit of 5 MB in most user agents is going to be a problem. Also VE needs to intelligently handle the case where the offline storage is not available or the origin has exceeded its limit. The user needs to know when their session isnt being auto-saved due to client side factors.

Are these autosaved versions going to persist across browser sessions?

If the VE sessions do persist, how will VE determine which VE autosaved versions are no longer needed and can be deleted to allow more VE sessions to be autosaved in the future. Will the user be able to manage which autosaves they no longer need?

  • Bug 52988 has been marked as a duplicate of this bug. ***

See also: Wikitext editor patch for this: https://gerrit.wikimedia.org/r/#/c/5130/

Jdforrester-WMF lowered the priority of this task from High to Normal.Jan 9 2015, 10:55 PM
Elitre added a subscriber: Elitre.Feb 27 2015, 3:54 PM
Jdforrester-WMF edited a custom field.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 21 2015, 6:15 PM
Esanders updated the task description. (Show Details)Oct 27 2015, 2:52 PM
Catrope removed a subscriber: Catrope.Nov 13 2015, 7:18 PM

OK, so, dusting this off, my current proposal is as follows:

  • As you edit, we stash a copy of the edited document whilst you're editing it into indexDB or whatever (locally on your machine); this would apply both to VE and the NWE surfaces.
  • When you save, once we get confirmation back that it's saved we delete from the local machine the in-process edit.
  • On load, if there's a draft for this page which based off the current revision, we prompt you to either resume the edit, or start a fresh edit (and discard the draft), with something looking roughly like:

This means that e.g. if your computer crashes, you lose network/power, or whatever, you can resume edits. It's optional, so if somehow you've made an edit that causes the editor to crash you can avoid re-triggering it (so you're not caught in a loop).

The main downside is that it doesn't let you move computers during an edit (which is not a common issue for users right now, but is a bit of an 'oh well').

If you load and there's a partial edit based on an out-of-date revision it probably isn't possible for us to help out automatically — we can't do an edit merge at that point, as that's a DB/server-side operation, and we can't tell whether or not the edit will save cleanly. Maybe just discard it silently?

I lost some work recently when I accidentally closed the wrong tab. Will your current plan solve that problem?

Krinkle removed a subscriber: Krinkle.Aug 14 2016, 5:37 AM
Ltrlg added a comment.Aug 16 2016, 7:24 PM

@Jdforrester-WMF I have been working on a Confluence wiki with (server-side) auto-save for several months and they have something your current proposal do not include: being able to see a diff before choosing. It is really useful, because I often do not remember what I was doing exactly when I closed the editing page 2 or 3 days before editing again.

@Jdforrester-WMF I have been working on a Confluence wiki with (server-side) auto-save for several months and they have something your current proposal do not include: being able to see a diff before choosing. It is really useful, because I often do not remember what I was doing exactly when I closed the editing page 2 or 3 days before editing again.

Hmm. That's certainly a possibility, but I don't think it's a good idea to try to shoe-horn that into the first version. In particular, I'd rather we had (at least) designs for T105173: HTML diffs of edits for everything (so that users didn't have to know wikitext to understand what they're shown) and possibly T39931: VisualEditor: Highlight changes made since save in some way (e.g. with a text-background?) so users can see what changes they have outstanding as a better, more fluid way of showing that to users as they edit. I've created T143341: When re-starting a local draft, show the user a diff so they know what they're getting into for this idea.

TransactionsHTMLEntire linear model
Initial storageNone. With the caveat that we will have access to the initial document state the user saw at a later date. Could be problematic if user has switched from WT mode. Could instead use HTML storage for initial state, then transactions for changes, but wipes out storage advantage.proportional to article size (~1.7MB for Obama)About twice HTML
Incremental storage~400 bytes to type a single character. Typing a 200 word / 3 sentence paragraph with a few annotations took 60k.Not much more than a few bytes per characterAbout twice HTML
Storage edge casesBlanking whole document / pasting in large sections multiple times will results in really large transactions, more that the initial storage of ‘Entire linear model’None really, just the document length.<<
Undo stackPreservedNot preserved<<
Save performanceVery fast, small JSON.stringifyCan be a few hundred ms for long articles. If waiting for N seconds of user inactivity this may not be a big issue, but in some cases esp slow machines, edit area will become momentarily non-responsive.Fairly fast, large JSON.stringify

The main concern is what happens when we run out of storage. A single document is unlikely to do this, but with multiple documents saved this would be quite common. We would need to do our own memory management to throw away old stashes.

Twice HTML => maybe 3.4MiB for Obama => two unsaved edits and we've over-flowed Firefox's local storage, that sucks quite a bit, which would steer us to Transactions. OTOH, the growth characteristics of Transactions for long edits (the ones where this would be particularly useful) make me a little uncomfortable about whether it'd be better….

Esanders added a comment.EditedJan 27 2017, 4:21 PM

Also the caveat for txs is that we need access to the original document state. That is fine for regular MW edits, but if they're using a restbase stash after switching that may be a problem. In those cases we could either store initial HTML or disable auto-save.

Qgil removed a subscriber: Qgil.Jan 27 2017, 4:37 PM

The main concern is what happens when we run out of storage.

The workaround for local storage limitations is remote storage, with the downsides:

  • slower (potentially several seconds for long articles and slow connections, but it's background and async so meh)
  • doesn't work offline, obviously
  • infrastructure costs of storing all the extra data
  • would probably need user consent

The main concern is what happens when we run out of storage.

The workaround for local storage limitations is remote storage, with the downsides:

  • slower (potentially several seconds for long articles and slow connections, but it's background and async so meh)
  • doesn't work offline, obviously
  • infrastructure costs of storing all the extra data
  • would probably need user consent

The trump concern is legal issues arising from holding server-side information subject to expensive discovery mechanisms, as I understand it (I'm not a lawyer, etc. etc.).

How about we just go ahead with this as-is, persisting last-edit-state so restarting browsers get back to the state before the crash/whatever, and silently fail when the user's machine either has local storage disabled or is full?

Alsee added a subscriber: Alsee.Aug 1 2017, 7:08 PM

Why is this described as a Visual Editor task? Visual Editor is a minor secondary editor, only used for a small percentage of edits. If auto save is implemented, it's certainly reasonable to also implement it in the secondary editor as well (VE).

Why is this described as a Visual Editor task? Visual Editor is a minor secondary editor, only used for a small percentage of edits. If auto save is implemented, it's certainly reasonable to also implement it in the secondary editor as well (VE).

Because it isn't actually possible in the older wikitext editors.

Most modern browsers can preserve text within the older wikitext editors (e.g., if you accidentally click the 'back' button while you're editing, then your changes are usually there if you click the 'forward' button to go back to the editing window), but that they can't do this with VisualEditor (either mode). So, in effect, the team is planning to cover for a limitation in browsers by building this capability internally. If you are interested in this subject, then you may want to read about HTML textareas (used in the older wikitext editors) and ContentEditable (used in online rich-text editors, including VisualEditor).

Alsee added a comment.EditedAug 3 2017, 7:58 AM

Because it isn't actually possible in the older wikitext editors.

My apologies, but I have to question your technical expertise on that point. I find it very difficult to imagine any reason that data-storing javascript could be added to one editor, but couldn't be added to the other.

The community requested this feature. Nearly two-thirds of the people supporting the request use VE for zero percent of their edits. They were quite obviously requesting this feature for the only editor that they use. 85% of supporters use Visual for 8% or less of their edits. They were also quite obviously requesting this feature for substantially-the-only-editor they use. Exactly one person uses Visual for more than half of their edits (57.6%). I'm sure no one objects to implementing autosave in the secondary editor as well.

There is already a task open for this request: T75241

Unless there is some clear reason not to do so, this task should be merged into T75241 as a duplicate.
If there is a desire for separate tasks for the two editors, the first priority work should be on the primary editor. I guess that would make this a subtask of T75241.

Alsee, the 2010 WikiEditor doesn't know whether or not you've typed anything in the editing window yet, and therefore it cannot know whether there are any changes to be saved.

Alsee added a comment.EditedAug 5 2017, 3:03 PM

@Whatamidoing-WMF
I am admittedly stretching the limits of what I know about javascript, but it appears something like

textarea.on('input', ...

solves that issue. I'm unsure, but a little extra code may be needed to catch cut/paste via right click.

Elitre rescinded a token.

(wrong tab)

Samat added a subscriber: Samat.

I am sorry, I wanted to close and merge the other way. I try to fix it.

Samat reopened this task as Open.
Samat added a subscriber: Dvorapa.

silently fail when the user's machine either has local storage disabled or is full?

Well given we will be writing to LocalStorage every time a new edit session is started, this is going to happen often (and we can't rely on the edit session being closed 'gracefully'). It appears that most browsers will throw an exception when storage is exceeded, so if we do our own memory management and keep track of VE save sessions, we can prune the LRU session until their is enough free space. We can also prune sessions older than N minutes/hours so other users can still use LocalStorage (e.g. ResourceLoader).

do our own memory management

...or use someone else's, e.g. https://github.com/monsur/jscache