Change 526831 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/VisualEditor@master] [WIP] ve.init.mw.ArticleTarget: Use errorformat=html when saving

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

We should check that the following error scenarios are still handled correctly afterwards. This is probably an incomplete list but I think I've got all the important ones.

1. API response handled by VE – When we want to display a special interface or do special logging, we have custom handling for some errors in VE code.
   • Bad token
     • To reproduce: open VE, then in another browser tab log out and log back in, then attempt saving (note: this is handled transparently by VE, without showing an error message, but you'll see a response with "code":"badtoken" in browser dev tools)
   • Edit conflict
     • To reproduce: open VE, then make an edit to the same page as another user (in another browser or private mode), then make changes in VE in the same place on the page and attempt saving
   • Page was deleted
     • To reproduce: open VE, then delete the page as another user (in another browser or private mode), then attempt saving
   • Aborted by hook
     • Actually no idea how to reproduce this one. Theoretically this would be caused by an extension preventing the edit (like examples below) but without returning error information. I don't know of any such poorly-behaved extensions.
   • Wiki is read-only
     • To reproduce: open VE, then set $wgReadOnly = 'foo bar'; in your LocalSettings.php, then attempt saving
2. API response handled by extension – As above but these error conditions are caused by extension rather than MediaWiki core, and have custom handling in the extension's code. Also, some extensions return API errors in non-standard format.
   • AbuseFilter
   • SpamBlacklist
   • TitleBlacklist
   • ConfirmEdit (CAPTCHA)
3. Generic API error – There are many rare error conditions where we don't do anything special, caused either by extensions or MediaWiki core. For example:
   • TemplateData
     • To reproduce: open a page with <templatedata> tag in VE and edit it to make the JSON invalid
   • Create file redirect while not allowed to upload
     • To reproduce: while anonymous, open a file page and edit it to make it a redirect to another file
   • (there's probably 20+ more and they are all as boring as the previous ones)
4. "Unknown error" – API did not return a response at all.
   • Network failure
     • To reproduce: open VE, then open browser dev tools and in "Network" tab set it to "Offline". Or disconnect your wifi ;)
   • Server fatal error
     • To reproduce: open VE, then add trigger_error("Fatal error", E_USER_ERROR); to the top of the api.php file, then attempt saving

Change 531584 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/TitleBlacklist@master] VE: Update for errorformat=html

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

Change 526831 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] ve.init.mw.ArticleTarget: Use errorformat=html when saving

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

Change 531584 merged by jenkins-bot:
[mediawiki/extensions/TitleBlacklist@master] VE: Update for errorformat=html

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

@matmarex: I only checked two of the cases here. Can we skip QA on this one, it seems like a low priority thing with lots of technical details.

In T229532#5430000, @matmarex wrote:

We should check that the following error scenarios are still handled correctly afterwards. This is probably an incomplete list but I think I've got all the important ones.

1. API response handled by VE – When we want to display a special interface or do special logging, we have custom handling for some errors in VE code.
   • Bad token
     • To reproduce: open VE, then in another browser tab log out and log back in, then attempt saving (note: this is handled transparently by VE, without showing an error message, but you'll see a response with "code":"badtoken" in browser dev tools)

This is what I got:

• Edit conflict
  • To reproduce: open VE, then make an edit to the same page as another user (in another browser or private mode), then make changes in VE in the same place on the page and attempt saving

Test Result:

1. • Page was deleted
     • To reproduce: open VE, then delete the page as another user (in another browser or private mode), then attempt saving
   • Aborted by hook
     • Actually no idea how to reproduce this one. Theoretically this would be caused by an extension preventing the edit (like examples below) but without returning error information. I don't know of any such poorly-behaved extensions.
   • Wiki is read-only
     • To reproduce: open VE, then set $wgReadOnly = 'foo bar'; in your LocalSettings.php, then attempt saving
2. API response handled by extension – As above but these error conditions are caused by extension rather than MediaWiki core, and have custom handling in the extension's code. Also, some extensions return API errors in non-standard format.
   • AbuseFilter
   • SpamBlacklist
   • TitleBlacklist
   • ConfirmEdit (CAPTCHA)
3. Generic API error – There are many rare error conditions where we don't do anything special, caused either by extensions or MediaWiki core. For example:
   • TemplateData
     • To reproduce: open a page with <templatedata> tag in VE and edit it to make the JSON invalid
   • Create file redirect while not allowed to upload
     • To reproduce: while anonymous, open a file page and edit it to make it a redirect to another file
   • (there's probably 20+ more and they are all as boring as the previous ones)
4. "Unknown error" – API did not return a response at all.
   • Network failure
     • To reproduce: open VE, then open browser dev tools and in "Network" tab set it to "Offline". Or disconnect your wifi ;)
   • Server fatal error
     • To reproduce: open VE, then add trigger_error("Fatal error", E_USER_ERROR); to the top of the api.php file, then attempt saving

Sure. I tested it thoroughly myself and I'm confident that it works as expected.