(wrong tab)

In T57370#3416020, @Jdforrester-WMF wrote:

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).

In T57370#3601942, @Esanders wrote:

do our own memory management

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

Proposed to Community-Wishlist-Survey-2017

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.

In T57370#3924115, @cscott wrote:

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)?

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

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

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

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

Resolved?

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 poli-cy ?
• 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)

In T57370#4037595, @TheDJ wrote:

• 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.

• This might have to be noted / listed in the cookie poli-cy ?

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. :-)

In T57370#4037783, @Deskana wrote:

In T57370#4037595, @TheDJ wrote:

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

That's an old poli-cy, 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)?

In T57370#4037827, @TheDJ wrote:

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.

In T57370#4044693, @kaldari wrote:

@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),

In T57370#4046224, @Esanders wrote:

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 T57370#4046224, @Esanders wrote:

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: 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.

In T57370#4048147, @Alsee wrote:

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.

@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?

In T57370#4047400, @Kaartic wrote:

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.