Oh wow, we're actually working inside an HTML fragment of EditPage. The first problem is that EditPage is sending itself an oldid parameter, which shows the incorrect "restoring page" notification.

Too bad, T245244: Conflict resolution process ends with incorrect "This page has been restored" doesn't solve the Visual Editor restore issue. I'll unlink as a subtask.

Note that we should leave the content to restore in VE, that's a nice safety fallback, but after a successful resolution it should be purged from storage.

I am unable to reproduce the VisualEditor restore changes bug locally.

Found one clue, in ve.init.mw.ArticleTargetLoader.js we test that response.oldid != wgCurRevisionId, and if true we try to restore an old edit. I'm not sure how to correct this yet, but pretty sure this is the source of our problem.

I can reproduce, this is a VE bug.

VE clears its autosave state when switching to the old wikitext editor (ve.init.mw.ArticleTarget.js#L2232). The conflict resolution screen is basically a special case of the old wikitext editor, but we incorrectly don't clear in this case (ve.init.mw.ArticleTarget.js#L1030). The same code should be added there.

I was surprised that this bug doesn't occur with TwoColConflict is not enabled. Apparently we also clear autosave whenever the old wikitext editor is loaded by any means (ve.init.mw.DesktopArticleTarget.init.js#L1251), but this code doesn't run when TwoColConflict is active (ve.init.mw.DesktopArticleTarget.init.js#L1012).

(Feel free to submit a patch, otherwise I'll write one in a few days)

@matmarex Thank you for the notes, that's an enormous help! I'll take a pass at fixing today, and will post here whether or not I succeed.

IMO, it's useful to have the autosaved content available until the conflict merge is completed, so I'll see if I can postpone clearing until after the merged revision is commited.

In T245119#5892067, @awight wrote:

IMO, it's useful to have the autosaved content available until the conflict merge is completed, so I'll see if I can postpone clearing until after the merged revision is commited.

@matmarex It looks like transactionality will be a problem. VE triggers a submit action, then presumably we lose control at some unknown point, without receiving confirmation that the revision was saved. I can write a patch to purge autosave before submitting, which will be fine in ~99.9% of cases, but I worry that the 0.1% are people with unreliable connections or browsers, who will benefit most from having the autosaved content available in case the save never completes. Either way, I'll upload an overly optimistic patch for review.

Change 572824 had a related patch set uploaded (by Awight; owner: Awight):
[mediawiki/extensions/VisualEditor@master] Purge autosave before submitting merged content

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

Change 572824 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Purge autosave before submitting merged content

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

Note: VisualEditor on the Beta cluster is broken right now, so we failed to demo this today. I suggest a demo on Adams computer.