I think this happens for autoresolved edit conflicts with wikitext editor, too.

Yeah, I'm pretty sure this is "VE and WT work the same, but it's odd…".

I can confirm that I saw this bug in the wikitext editor, so I would suggest removing the VisualEditor tag. I would also say that, for the people experiencing this bug, it's not "low" priority, it's quite disruptive.

This is still the case in wikitext editor, but the behavior in visual editor (even for wikitext diffs) has changed: we show changes compared to the revision you started editing, rather than to the article's most recent revision. This happened in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/VisualEditor/+/418698 (2018).

@Esanders

I think this will handle conflicts very slightly differently. The old API didn't pass the oldid, and so showed you exactly the diff you would generate if you saved, for example it would show the force merge if the conflict is with yourself. This API call explicitly passes an oldid, so will always show the difference between the page you loaded and the content you typed.

@matmarex

I think the new behavior is actually an improvement, in particular in case of automatically resolved edit conflicts. The previous behavior compared your text to the latest revision of the page, no matter at what revision you started editing. The proposed behavior compares your text to the revision you started editing.

For example, let's say I start editing a page, in the meantime someone edits and saves a change to a different part of the page, then I try to save/review my changes. The diff will show me undoing their changes, even though upon saving they will actually be automerged.

I guess ideally we would displaying the automerged diff, but I'm not sure if that's possible, and it could be confusing in some cases ("why did this line I didn't touch change?"). The behavior proposed here is definitely better than the current one.