Page MenuHomePhabricator

Edit conflict automatic resolution can silently produce unexpected results
Open, LowestPublic

Description

EditPage.php has a comment (line 1823):

//Successful merge! Maybe we should tell the user the good news?

which is probably much older than the post-edit notification. IMHO this is a good idea, i.e. when an edit conflict is successfully resolved, the post-edit notification should say something like: "Another user edited the page the same time, but the conflict could successfully be resolved and your edit was saved."

Knowing about resolved edit conflicts can be important: The other change can easily be missed, as the page is marked as visited in your watchlist after your edit. When you add an "I agree" on a talk page, it is important, too, to know when there was an successful edit conflict resolution, as your comment now might refer to an other comment than you meant.

Event Timeline

Schnark raised the priority of this task from to Needs Triage.
Schnark updated the task description. (Show Details)
Schnark changed Security from none to None.
Schnark subscribed.
Aklapper triaged this task as Lowest priority.Dec 8 2014, 11:20 AM

Change 230304 had a related patch set uploaded (by Gerrit Patch Uploader):
Inform author of successful edit conflict resolution

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

I'm afraid this is exposing internals with little benefit. Could we consider closing this as rejected, and remove the suggestion that caused this task to be created from the code?

Nemo_bis subscribed.

Agreed. The proposed use case seems quite fat fetched too: automatic merge definitely fails if a line before the one you edited is changed. We can reconsider the proposal if diffs are provided which caused such unexpected merges.

IMHO at least my first example use case is valid: If a vandal vandalizes one section while you expand another, you're likely to miss his change when your edit is automatically merged. And other users looking at the recent changes will probably not look at the change when a trusted user edited the page just after it, so such vandalism can easily be unnoticed. A note informing you that an automatic merge occurred could prevent that.

Agreed. The proposed use case seems quite fat fetched too: automatic merge definitely fails if a line before the one you edited is changed. We can reconsider the proposal if diffs are provided which caused such unexpected merges.

After a quick search:

This edit was started before the deletion request was amended, but saved later. The user added a comment about this fact, that he agreed only on the original request, and hadn't (and couldn't have) noticed that it had been amended in the meantime.

Another example: Serten commented on GEEZERS comment, but after the automatic merge of SchirmPower's comment it looked like he commented on SchirmPower instead. The automatic merge was probably possible, because Serten added a blank line before his comment, while SchirmPower didn't. This behaviour was reported here, there are some more examples in that report.

Are all the examples about section-editing different sections?

Are all the examples about section-editing different sections?

No, in both examples above the two users edited the same section (in the first example new sections were introduced, so after saving the edits were in different sections, but when the users started editing, they both edited the same section).

Yet another example, only a few days old: first edit, second edit As the first edit changed the title of the section, but the second still has the old title in the summary, you can easily see that this was an automatically resolved edit conflict. In the result this looks like Ireas read Doc Taxon's comment before he left his comment, though in reality he wasn't able to do so, since he commented first.

Automatically resolved edit conflicts that can tamper with the course of a discussion aren't that rare as you seem to assume, so I still think it is a very good idea to inform the user about them, to enable them to move or amend their comment if needed to clarify.

Reopening per "We can reconsider the proposal if diffs are provided which caused such unexpected merges.".

Nemo_bis renamed this task from Inform author of successful edit conflict resolution to Edit conflict automatic resolution can silently produce unexpected results.Nov 28 2015, 3:31 PM
Nemo_bis added subscribers: Nnemo, StudiesWorld.

Reopening per "We can reconsider the proposal if diffs are provided which caused such unexpected merges.".

Would be useful to summarise said examples in the task description, with T118632 diffs as well. If I understand correctly, all the examples are about edits to different sections, which were merged incorrectly.

There ought to be a way to avoid mistaken merges, but as a temporary workaround perhaps we might supplement the postedit notice with a brief note that an edit conflict was resolved and with a link to the final diff?

If I understand correctly, all the examples are about edits to different sections, which were merged incorrectly.

No, the contrary, all the examples are about edits to the same section.

I'm baffled that anyone thinks a merge notice is undesirable?? If the page has changed then I definitely want to know about it. This needs both a notice to the person making the merged save and an edit-merge tag in the history. I'm rather disturbed by the idea that I can unknowingly save a page that I've never seen.

If I may make up a nasty scenario, I write a comment forcefully endorsing the last post by Bob, above. (Which could be in the same section or a different section.) Bob either adds a new comment or rewrites his last comment, posting something seriously abusive. My comment gets silently merged, with a timestamp a day after Bob's abusive comment. (Yes, I semi-regularly start an edit, get sidetracked, and leave the edit window open for absurd lengths of time.)

I'm baffled that anyone thinks a merge notice is undesirable?

Who thinks so? The notice was proposed just two comments ago and nobody objected yet. :)

I think one of us is confused. Maybe it's me?

Who thinks so? The notice was proposed just two comments ago and nobody objected yet. :)

A merge notice was proposed in the original bug description. siebrand suggested rejecting it, then you closed it as rejected. When this was reopened you strangely suggested a notice would be temporary??

My understanding of this bug is that successful, technically correct, merges should alert the user that their edit was merged. In the routine case the editor likely does want to see what his edit got merged with, especially if it's a discussion page. In the worst case a technically correct merge could create a semantic conflict on the page. My "support" at the bottom may refer to an altered topic at the top.

BTW, why is T118632 merged here? That bug appears to be about a non-merge wiping out a previous edit.

Another example was posted in T223433 and it's worth noting here. I'll detail the three edits involved:

  1. 11:01, 4 June 2019 An IP-edit deletes a section.
  2. 11:04, 4 June 2019 An editor restores the content with revert, and moves the section to (presumably) a more standard section-order
  3. 11:05, 4 June 2019 A second editor also reverts the IP-edit

The simultaneous reverts conflict and are silently merged. The result is that the section, and all content in that section, is nonsensically duplicated on the page.

Silently merging conflicts can result in serious damage to a page, it can cause the watchlist to fail to correctly report new edits, it can editors to miss vandalism, it can cause editors to miss critically important messages in a discussion, and worst of all the software can fraudulently cause the editor to change the page in a way that they had no intention of doing and without their knowledge. It could conceivably result in an editor being banned for (apparently) abusive conduct for which they were not responsible. The software would be responsible.

The software needs announce the edit conflict, show the conflicting change(s) to the user, and ask the user whether they still want their edit automatically merged. The merge is only saved after approval.

Removing task assignee due to inactivity, as this open task has been assigned to the same person for more than two years (see the emails sent to the task assignee on Oct27 and Nov23). Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome.
(See https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator.)