And I think the logs need to be examined to see if any other articles have been affected by the publishing of an aborted VE edits after other edits, as they will need to have the edits manually merged.

I made some changes but then realised that the changes involved the wrong URL so I backed out of the edit by clicking Article. It asked the Leave/Stay question and I said Leave.
I cannot abort a VE edit! because if I do, I can never use the VE again on that article untiI I publish it!

Clicking 'article' navigates you off the page, which means you don't have the chance to delete you auto-saved changes (no JS is executed after the stay/leave system dialog). We could probably add some bindings to the 'Article' button, but there will always be ways for people to leave the editor without discarding their changes.

Currently if you use the 'Read' tab or press 'esc' you will get a local dialog to discard your changes, and they will be removed form auto-save.

So I tracked down the right URL and then source-edited the article

We need to add some code to the 2010 editor to invalidate VE's autosave.

it will not operate in "edit conflict" situation (i.e. where the aborted edit does not apply to the last version of the article)

Auto-save just recovers the state of the document when you loaded, and your subsequent changes, so it should behave no differently than a regular edit conflict.

Article tab issue: T189380
2010WTE switch issue: T189381

The VE happily saved it and there was no edit conflict. And yes I had just overwritten my previous two source edits.

This appears to be happening independently of the auto-save feature. Filed as T189387.

Edit: Actually I think this is just because you conflicted with yourself, from the edit API documentation: "Note: Edit conflicts will be ignored if you are conflicting with the current user."

With the the other two issues fixed I think that should address all the concerns here.

When I train with the VE, it is a common question "how do I get out of this edit and start over".

I tell them to click Article as in the past both of these have worked for me and have worked identically. The advantage of Article over Read is that Article is in a very predictable place on the screen (left of the tool bar) whereas Read is not as it positions itself relative to the screen width. This is a particular problem when I am supporting new users remotely (note that I do support of new people not just here in Queensland but also through the USA Public Library network). It is much easier to say "click on the Article tab, top left next to the Wikipedia Globe" than attempt to explain where Read is likely to be.

However, they often respond with "that's not obvious" because expect to find some kind of Cancel/Exit button on the tool bar as an alternative to the Publish button (this is probably because of the way other tools like Microsoft Word works). And I can't blame them for saying that because semantically you are thinking "I want to terminate this edit without publishing", not "I want to read the article". It would be much better if we had the Cancel/Edit button with a clear semantics.

It seems to be affecting people elsewhere as well.

(Also wonder how related T189402 is)

Another issue about VE showing older version of page reported at https://www.mediawiki.org/wiki/Topic:U96jvxbu5yyjb67g
Similar complain as the discussion Erica linked to.

In T189337#4040760, @Kerry_Raymond wrote:

However, they often respond with "that's not obvious" because expect to find some kind of Cancel/Exit button on the tool bar as an alternative to the Publish button (this is probably because of the way other tools like Microsoft Word works).

There is a task asking for this, T85470: Users are requesting a "Cancel and exit without saving" option.

In T189337#4040440, @Esanders wrote:

Article tab issue: T189380
2010WTE switch issue: T189381

In T189337#4040581, @Esanders wrote:

With [these] two issues fixed I think that should address all the concerns here.

@Esanders Do you think this is resolved then? Patch https://gerrit.wikimedia.org/r/#/c/419169/ looks like it might have been related to this task?

I think so - that patch relates to something discussed on the original autosave task, that we should file a separate bug for.