Page MenuHomePhabricator

Bad interaction between VisualEditor and TwoColConflict
Open, HighPublic3 Estimate Story Points

Description

Steps to reproduce:

  • Enter the edit conflict workflow on beta enwiki.
  • Change content of a conflicting textbox.
  • Publish changes.

Then, the bad stuff happens:

  • Back in the article read view I see a "this page has been restored" notification.
  • The page text looked as expected, it will be the correctly merged and edited content.
  • However, when reentering the edit view, VE asked if I want to restore a previous edit. Allowing the restore resets us to before the conflict workflow, losing the edits saved there—it will have the "your" content that we had when initially publishing changes.

On the bright side, VE correctly restores the original parent revision pointer, so even without making further changes, if you publish this content you'll see the conflict resolution workflow again, this time with your correctly merged content as the "other" edit, and the unedited "your" content starring as itself.

This is really confusing, I think we need to fix it before default deployment. It's curious that no beta users have reported however, maybe we should survey whether they're using Visual Editor or not?

Details

Related Gerrit Patches:
mediawiki/extensions/VisualEditor : masterPurge autosave before submitting merged content

Event Timeline

awight created this task.Thu, Feb 13, 9:13 AM
Restricted Application added a project: TCB-Team. · View Herald TranscriptThu, Feb 13, 9:13 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
awight triaged this task as High priority.Thu, Feb 13, 2:59 PM

This is repeatable. It isn't related to whether I click the save button in the textarea or not. This also happens on production enwiki. I'll update the task description to show the simplified steps.

So, testing without TwoColConflict shows the same ominous "Page restored" notification, however the Visual Editor never tries to "restore changes". In other words, we're breaking the conflict workflow.

I'd appreciate if other editors or devs would try to reproduce as well, to make it less likely that my browser or wiki preferences are causing this.

awight renamed this task from Possible bad interaction between VisualEditor and TwoColConflict to Bad interaction between VisualEditor and TwoColConflict.Thu, Feb 13, 3:05 PM
awight updated the task description. (Show Details)

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.

matmarex added a subscriber: matmarex.EditedMon, Feb 17, 10:20 PM

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.

awight updated the task description. (Show Details)Tue, Feb 18, 9:06 AM

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.

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

awight set the point value for this task to 3.Tue, Feb 18, 1:03 PM