Page MenuHomePhabricator

Do not overwrite edits when conflicting with self
Open, Needs TriagePublic


Currently, MediaWiki will ignore conflicts between edits of the same user, causing previous edits to be overwritten, if there were no edits by other users since the edit's base revision (and the current edit is not a section edit). The relevant code is at;56ade0650d492e01d2689dc918e7db3d56d18147$1997

This behavior seems undesirable: If I have the same page open in two tabs for some reason, and edit in both (possibly after hours or days), the second edit will undo the first edit, unless someone else has edited in the meantime. There seems to be no documented justification for this.

Originally, conflict detection would be disabled if the current user was the creator of the edit's base revision, no matter if other users edited. This behavior can be found the first revision of MediaWiki on record in git, Lee Daniel Crocker's "Initial revision" from 2003:;d82c14fb4fbac288b42ca5918b0a72f33ecb1e69$419

Later, brion changed this so merging would work on section edits, but conflicts on whole page edits would still overwrite:

In 2008, Aaron added a check that made sure the current user was the only one to edit after the base revision:

This was rather tricky to track down, since the method was moved from Article to EditPage and then later to Revison (by me).

But the big question is: WHY do we do that? It seems like we are going out of our way to do the wrong thing in an edge case. Am I missing some obvious benefit of this?


Related Gerrit Patches:

Event Timeline

daniel created this task.Sep 12 2017, 8:14 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 12 2017, 8:14 PM

Historical justification, as per Brion on IRC:

[22:20] <brion> So
[22:20] <brion> Back in the day if you used the edit form and saved
[22:21] <brion> And then clicked back and made a further change and save again
[22:21] <brion> It would edit conflict
[22:21] <brion> I think this was a hack for that
[22:21] <brion> But yeah if it fucks you up it's... not pretty
[22:21] <DanielK_WMDE> ah... that would work because "back" took you back to a text field that still had the modified text, which you could then adjust?
[22:22] <DanielK_WMDE
> this was before tabbed browsing, yes?
[22:22] <DanielK_WMDE__> this seems to be doing more harm then good...
[22:22] <brion> Yeah Netscape 4 days
[22:22] <brion> It may be... Unwise now.

I'd be OK with changing this, but it'll likely have some fallout with editing tools relying on this behaviour.

Change 377813 had a related patch set uploaded (by Daniel Kinzler; owner: Daniel Kinzler):
[mediawiki/core@master] Do not ignore edit conflicts with oneself.

I remember suffering silly self-conflicts. An additional issue is that ~~~~ magic expansion almost ensures that there will be a conflict, even if it could otherwise be automatically resolved.

aaron explained it quite well on

It's not strange at all to notice a typo in what you wrote just after pressing Save (ie. while it is connecting with the server). So what do you do? You press Esc to stop it hoping that you were fast enough. Most probably, you weren't (it was saved), and your amended edit will be a self-conflict.

That seems more common than editing the same article on two different tabs without noticing. Maybe we should try to detect if it was from the same or a different tab?

Related tasks: T2275 T3150

I just recently accidentally overwrote my own changes when using two tabs. I think it would be better to ask confirmation before overwriting on these cases rather than doing it silently.

If we still want to cover the "back button" use case, I think we should try and detect that situation on the client side.

A bit of JS could set a flag in the form just before it is submitted for saving, so the form knows the contents of the text field have already been saved. It can then warn and offer to load the latest version into the editor when the edit field gets focus again.

With JS disabled, you'd get a conflict if you edit the same paragraph again. With JS on, you would be able to do the same thing you do now, with one extra click, and without the danger of accidentally reverting yourself.

Tagging for TechCom review. Would be great to move this forwards somehow.

tstarling moved this task from Inbox to Backlog on the TechCom board.Jul 18 2018, 8:37 PM

Change 377813 abandoned by Daniel Kinzler:
Do not ignore edit conflicts with oneself.