[Epic] VisualEditor: Implement some form of auto-save to help with browser crash recovery and accidental tab closing
Closed, ResolvedPublic40 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

There are a very large number of changes, so older changes are hidden. Show Older Changes

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

Deskana moved this task from TR1: Releases to Backlog on the VisualEditor board.Oct 27 2017, 12:55 PM
cscott added a subscriber: cscott.Jan 26 2018, 6:55 AM

This would be a good use of a general "fork storage" mechanism: the edit-in-progress would get stored as an unmerged fork of the main revision.

This would be a good use of a general "fork storage" mechanism: the edit-in-progress would get stored as an unmerged fork of the main revision.

Cool idea. But what if there is no main revision (creating a new page)?

TBolliger renamed this task from VisualEditor: Implement some form of auto-save to [Epic] VisualEditor: Implement some form of auto-save.Feb 8 2018, 6:45 PM

Change 413249 had a related patch set uploaded (by Esanders; owner: Esanders):
[VisualEditor/VisualEditor@master] Use sessionStorage to auto-save

https://gerrit.wikimedia.org/r/413249

Change 413249 merged by jenkins-bot:
[VisualEditor/VisualEditor@master] Use sessionStorage to auto-save

https://gerrit.wikimedia.org/r/413249

Change 413266 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (1a0bc9981)

https://gerrit.wikimedia.org/r/413266

Change 413273 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/VisualEditor@master] Use session storage to auto-save

https://gerrit.wikimedia.org/r/413273

Change 413266 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (1a0bc9981)

https://gerrit.wikimedia.org/r/413266

Deskana renamed this task from [Epic] VisualEditor: Implement some form of auto-save to [Epic] VisualEditor: Implement some form of auto-save to help with browser crash recovery and accidental tab closing.Feb 22 2018, 5:39 PM
Deskana added a subscriber: Deskana.

Note: the above patches are not intended to be a long-term saving mechanism.

Esanders claimed this task.Feb 24 2018, 4:55 PM

Change 413273 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Use session storage to auto-save

https://gerrit.wikimedia.org/r/413273

Deskana closed this task as Resolved.Mar 6 2018, 1:20 PM

Yeah. There may be bugs or follow-up work, but that can be in different tasks.

TheDJ added a subscriber: TheDJ.EditedMar 9 2018, 9:00 AM

I have 4 potential follow up questions/issues

  • I spotted a problem in that patch.. no try/catch around the session storage access (as with local storage usage, always needed).
  • Session storage doesn't protect against full-on browser crashes I presume ?
  • This might have to be noted / listed in the cookie policy ?
  • We should actively blank this when definitively saving / cancelling. This would prevent the last edit being left in the browser's storage on things like public library computers, which we would like to avoid I think... (also, is there username info in the content being put in session storage ? because that might be a problem in that situation)
  • Session storage doesn't protect against full-on browser crashes I presume ?

I induced a full browser freeze and crash in Chrome, and my edits were successfully recovered. This may not be true in other, or older, browsers.

To my knowledge, there aren't any cookies used for this, so I don't think so.

The other two questions are for engineers, not myself. :-)

TheDJ added a comment.EditedMar 9 2018, 11:41 AM

To my knowledge, there aren't any cookies used for this, so I don't think so.

That's an old policy, but it's about ALL client side storage: "These generally include tracking pixels, JavaScript, and a variety of "locally stored data" technologies, such as cookies and local storage."

TheDJ added a comment.EditedMar 9 2018, 11:46 AM

I just encountered this for the first time and it's already blocking me...

I started writing a reply to a user with a section edit (WE 2017). Then I aborted this (Intentionally because there was a severe edit conflict because I went away for an hour or so before trying to submit). Then I went back to the same section of the new version and my change was recovered, but this caused it to reinsert the very old document. Now I don't know how to get the auto save to ignore my outdated session, so that I can properly comment on the current version of the page .....

Can we decide not to restore if the base revisions of the document are not the same ? Or create some way for me to be in control somehow ?

TheDJ added a comment.Mar 9 2018, 11:55 AM

Also, I note I had predicted and summarised some of such edge cases and considerations as recently as January in related tickets... T184308#3889701 Might be worthwhile to take a quick look at that.

I was under the impression it was going to be optional to restore your edit, like in James's mockup: T57370#2548772.

@Deskana: Do you think we should make a follow-up task to implement James's UI to deal with TheDJs issue (T57370#4037827)?

I just encountered this for the first time and it's already blocking me...

I started writing a reply to a user with a section edit (WE 2017). Then I aborted this (Intentionally because there was a severe edit conflict because I went away for an hour or so before trying to submit). Then I went back to the same section of the new version and my change was recovered, but this caused it to reinsert the very old document. Now I don't know how to get the auto save to ignore my outdated session, so that I can properly comment on the current version of the page .....

Can we decide not to restore if the base revisions of the document are not the same ? Or create some way for me to be in control somehow ?

I encountered the same problem when trying to recover from T189079. It definitely seems like it needs to be addressed.

I experienced a similar issue recently when I was testing something else. I made a few changes in the 2017 wikitext editor, abandoned my edit, and when I came back to the page my edit was "recovered" which wasn't helpful. I'll file a task for this.

@Deskana: Do you think we should make a follow-up task to implement James's UI to deal with TheDJs issue (T57370#4037827)?

I'd prefer the software do the right thing (i.e. not "recovering" edits that were intentionally abandoned) rather than shifting the burden of the decision onto the user. If that's not possible for whatever technical reason, asking the user would be an acceptable backup option.

I filed T189576: [Epic] Do not "recover" edits that were intentionally abandoned (in the visual and 2017 wikitext editors)

In the mean time, my testing unearthed two workarounds you can use so that your edits are not "recovered" when they shouldn't be:

  1. Close the tab you were using, and edit the same page in a new tab.
  2. Click "Read" to close the editor.

An edit is considered intentionally abandoned if you click 'Read' or 'Article' (T189380 not yet deployed). If you close the tab, reload or navigate away in any other way we have no opportunity to delete. It would not be correct to only recover if the version IDs match, as on popular articles that will happen all the time. We should expect core's merge/conflict code to handle that in the same way it would if you just had the tab open for a long time.

Given that people are getting confused about when they have actually "abandoned" their edit, we may want to ask the user.

Note that one of the use cases for this is for when mobile devices automatically unload background tabs, so having the editor prompt you to recover every time you switch tabs could be annoying.

Perhaps a middle ground would be to prompt the user only if the document IDs don't match. In the common case where the document IDs do match we continue to recover silently, and if the user wants to undo they can press undo (as history is preserved),

TheDJ added a comment.Mar 13 2018, 1:44 PM

Perhaps a middle ground would be to prompt the user only if the document IDs don't match. In the common case where the document IDs do match we continue to recover silently, and if the user wants to undo they can press undo (as history is preserved),

This seems like a good idea to me.

In the common case where the document IDs do match we continue to recover silently, ...

Nice point, but ... only if the user actually does know that there is a feature known as "autosave" and it recovers their edits" silently in some cases. What I'm trying to say is, this might become a misfeature if there are possibilities that we might recover the edits it when we shouldn't have AND we don't let the user know that we recover edits silently!

I guess we should at least show a fade away notice when we recover the edits thus letting the user know about the feature.

Report from VisualEditor/Feedback:
Whenever I switch from VE to the source editor, and then switch back to VE, it literally deletes the changes I made with the source editor, and then it gives me a ridiculous message saying the following:
"Changes recovered Your unsaved changes have been automatically recovered."
Well, thanks, but how do I get rid of this? Now I can't use VE properly anymore.

Alsee added a comment.Mar 14 2018, 2:45 PM

@Aklapper are you kidding? This is clearly a serious bug in the new code, and it directly relates to the discussion in the previous dozen comments.

Report from VisualEditor/Feedback:
Whenever I switch from VE to the source editor, and then switch back to VE, it literally deletes the changes I made with the source editor, and then it gives me a ridiculous message saying the following:
"Changes recovered Your unsaved changes have been automatically recovered."
Well, thanks, but how do I get rid of this? Now I can't use VE properly anymore.

T189381.

Alsee added a comment.Mar 14 2018, 3:23 PM

@Deskana ah good. I posted the info here when I couldn't find any mention or task of the 'switching editors' issue. Should the new task be added to the Related Objects task graph?

Nice point, but ... only if the user actually does know that there is a feature known as "autosave" and it recovers their edits" silently in some cases. What I'm trying to say is, this might become a misfeature if there are possibilities that we might recover the edits it when we shouldn't have AND we don't let the user know that we recover edits silently!

I guess we should at least show a fade away notice when we recover the edits thus letting the user know about the feature.

Sorry, when I said "silently" I meant without a modal dialog. We will always show at least the notification when edits are recovered. This is an improvement on the current wikitext editor where the browser can automatically recover the state of the textarea without telling the user.