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:
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).
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.
Change 413249 had a related patch set uploaded (by Esanders; owner: Esanders):
[VisualEditor/VisualEditor@master] Use sessionStorage to auto-save
Change 413249 merged by jenkins-bot:
[VisualEditor/VisualEditor@master] Use sessionStorage to auto-save
Change 413266 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (1a0bc9981)
Change 413273 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/VisualEditor@master] Use session storage to auto-save
Change 413266 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (1a0bc9981)
Change 413273 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Use session storage to auto-save
I have 4 potential follow up questions/issues
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.
- This might have to be noted / listed in the cookie policy ?
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. :-)
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."
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 ?
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 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.
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.
In the mean time, my testing unearthed two workarounds you can use so that your edits are not "recovered" when they shouldn't be:
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),
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: Support questions are handled on https://www.mediawiki.org/wiki/VisualEditor/Feedback , not here.
@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.
@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?
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.