When you say you weren't able to reproduce it, was that just due to not being able to arrange for an edit conflict? Or were the same steps taken without such an error/bug occurring?

I arranged for an edit conflict in my sandbox at en.wiki. Instead of saving, it dumped me to the 2010 wikitext editor to resolve the edit conflict.

I'm wondering if it needs a particular type of edit conflict – new but adjacent lines, for example.

Also, when I do this, I get a really odd diff on the resolve-conflict page (i.e., the page that I didn't see when the bug happened).

The basic process is to have Account A edit section 1 in Browser α and to have Account B edit the same line in section 1 in Browser β. Save one and then save the other. The first save is normal and error-free. The second save triggers the edit-conflict warning. But the diff claims that the first save removed all sections on the page except for section 1:

More of users on cswiki had similar issue, but we also couldn't reproduce it.

Example: https://cs.wikipedia.org/w/index.php?title=Wikipedie:Pod_l%C3%ADpou&diff=14492220&oldid=14492206
As far as I can see, both cases (Whatamidoing and cswiki user) have got "switched from VE" tag and both used NWE, but "2017 WE" tag wasn't added

@Whatamidoing-WMF and @Dvorapa This bug appears only when the edit is in NS_PROJECT or in NS_PROJECT_TALK. I've been able to reproduce this in NS_PROJECT in cswiki. Feel free to try it in https://cs.wikipedia.org/wiki/Wikipedie:P%C3%ADskovi%C5%A1t%C4%9B (public sandbox).

I think I've found another person who was bit by this bug: https://en.wikipedia.org/w/index.php?title=Wikipedia:Administrator_intervention_against_vandalism&curid=1952670&diff=757176998&oldid=757176973

I wonder why the project namespace is the only one affected. I was unable to replicate the problem in the Template namespace using https://en.wikipedia.beta.wmflabs.org/wiki/Template:Sandbox Perhaps it needs an "Add section" button to have this problem? Or perhaps something is strange about the project namespace itself (where the visual mode is enabled on some sites and not on others)?

I found two edits from 27 December 2016 at w:en:WP:BLPN that were marked as "visualeditor-switched", but didn't blank the page. If this is just in the project namespace, and if they're all tagged as visualeditor-switched, then it should be possible to find all of these through RecentChanges: https://en.wikipedia.org/w/index.php?namespace=4&associated=1&tagfilter=visualeditor-switched&days=30&title=Special%3ARecentChanges

Project talk namespace is affected too.

It shouldn't be related to newsectionlink. I wasn't able to reproduce even the link was added by NEWSECTIONLINK and was able to reproduce at page where it wasn't. I also wasn't able to reproduce it at page where it is by default.

Pages (all at cswiki)

• WP:Pískoviště
• Talk:Testovací
• Wikipedista:Martin Urbanec/Pískoviště/1

Was able to reproduce in NS_USER_TALK, diff https://cs.wikipedia.org/w/index.php?title=Diskuse_s_wikipedistou:89.29.20.218&curid=631648&diff=14507460&oldid=14507453.

I'm trying to reproduce it at test.wikipedia.org. Results: When I try to arrange an edit conflict after edit conflict (two edit conflicts was needed, i.e. when you're solving one conflict, make another).

Just a note, the previous cswiki bug wasn't after two conflicts (only one was needed).

All edits after an edit conflict are marked as VisualEditor: switched no matter if this bug was activated. Maybe the switched tag is another bug because without edit conflict switch from NWE to VE cause the edit is marked as VE edit. The switched tag should apply only when switch VE to NWE applied.

This may be related to T154158: Occasionally, visual mode opens instead of wikitext mode since when I get this error visual mode attempts to open and then fails and then pushes me to a "corrupt" preview page. Fx 50+ on both Windows 7 and 10.

Here's a fresh example of this happening in the English Wikipedia: https://en.wikipedia.org/w/index.php?title=Wikipedia:Reliable_sources/Noticeboard&diff=prev&oldid=760684678.

More reports:

@Orf3us at https://no.wikipedia.org/w/index.php?title=Wikipedia:Tinget&diff=prev&oldid=17060434

@BDaniel at https://he.wikipedia.org/w/index.php?title=סיינט_אוגוסטין&diff=19948305&oldid=19948300 and https://he.wikipedia.org/w/index.php?title=סיינט_אוגוסטין&diff=19953388&oldid=19953351

@AlexMonk-WMF @Jdforrester-WMF This task is in TR0: Interrupt, maybe it should be set as Unbreak now! too; btw it looks like it has got a priority without being assigned to someone actually.

There is a report of this problem happening with current FF and Mint as well.

What we need is a reliable way to reproduce this.

I experienced the problem too. on WP:VP/T I think.

It almost looks like the section editing, diffs against the version that the user started with, instead of the current version. It might very well be an API edit bug, that we are only now seeing because that API is used much more intensely with the new editor now. Just brainstorming.

From the same thread on mw.org: "It just happened again, this time 605 KB ;)
It seems to be, that if I edit a section, get an edit conflict in there, and try to resolve it, the 2017WE thinks the section is the whole page and ditches the rest."

This seems to be true. Plus the edit is tagged as VisualEditor:Switched
everytime. Did somebody notice somebody who was not bitten by this bug when
editing a section with having a conflict?

This means that the Editor try to open the standard conflict resolution
dialog but it autosaves. There isn't any other way when it can switch to
the standard editor.

In T154217#2989329, @TheDJ wrote:

I experienced the problem too. on WP:VP/T I think.

It almost looks like the section editing, diffs against the version that the user started with, instead of the current version. It might very well be an API edit bug, that we are only now seeing because that API is used much more intensely with the new editor now. Just brainstorming.

If it could be an api related problem, calling the APIers so they can give their thoughts on this.

In T154217#2994254, @Urbanecm wrote:

If it could be an api related problem, calling the APIers so they can give their thoughts on this.

It seems much more likely that there's a bug in code that's using the API. When there's an edit conflict that can't be auto-merged, the API just returns an error. No before and after content, no attempted merge, no diff, just an error, as you can see easily enough with this sandbox query. Unless you can provide actual API queries that illustrate the bug, I'm going to assume it's not the API.

From the description, it sounds like whatever non-API code is doing the "after an edit conflict" bit is losing the 'section' parameter despite not expanding the text-being-edited to be the whole page.

User at mw.org says he agrees: "Not that I know any daft thing about API, but your reasoning reads reasonable ;)

I just had an edit conflict while editing the whole page, and it jumped back to the normal editor, and the normal diff-view inside this for edit conflicts. Nothing was lost.

IIRC there was no such thing as the normal diff-view in the normal editor after the edit conflict while I edited just the section."

In T154217#2994851, @Anomie wrote:

It seems much more likely that there's a bug in code that's using the API. When there's an edit conflict that can't be auto-merged, the API just returns an error. No before and after content, no attempted merge, no diff, just an error, as you can see easily enough with this sandbox query. Unless you can provide actual API queries that illustrate the bug, I'm going to assume it's not the API.

From the description, it sounds like whatever non-API code is doing the "after an edit conflict" bit is losing the 'section' parameter despite not expanding the text-being-edited to be the whole page.

Thanks for your input, that is the reason why I called APIers.

Just a random idea. Was this seen in VisualEditor?

New variant on this at WT:V today:

I added a comment to the end of a section on the talk page. It saved, but I got a scary red error message about an "empty server response". It let me dismiss the message and try again. The second time, it saved ...but it had actually saved the first time, so this prompted an edit conflict, which was auto-resolved by blanking the rest of the page.

Steps to reproduce by @Tgr:

• open single section for editing in NEW
• generate mergeable edit conflict (trying and failing to save due to T159295 produces this)
• try to save
• chose "resolve conflict"
• The editor will exit and the text of the page will be replaced by the text of the section.

As far as I can see in ve.init.mw.ArticleTarget.js in the onSaveDialogResolveConflict method (https://phabricator.wikimedia.org/diffusion/EVED/browse/master/modules/ve-mw/init/ve.init.mw.ArticleTarget.js;57d57cdbbfd981eba335130c9696b76e2ae44efd$1179) there is just the section parameter missing when the data is submitted to the action=edit form.
You can see this with edit that do trigger again in this step (as expected) , unlike for edit conflicts in the old editor where the "your text" box contains the whole content even if you edited only one section, in edit conflicts from NWE section edits you just see the content of the section you edited.
If (for whatever reason) submitting to OWE does not trigger an edit conflict again (even though trying to save did trigger one just before), then the missing section parameter will of course cause the rest of the article to be removed.

Change 345473 had a related patch set uploaded (by Esanders):
[mediawiki/extensions/VisualEditor@master] Pass section when resolving conflicts in NWE

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

Thanks for the investigation!

Change 345473 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Pass section when resolving conflicts in NWE

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