Page MenuHomePhabricator

VisualEditor should use errorformat=html and maybe drop some of our custom error messages in favor of default ones
Closed, ResolvedPublic

Description

VisualEditor should use errorformat=html and maybe drop some of our custom error messages in favor of default ones.

We have messages like 'visualeditor-saveerror-titleblacklist' or 'visualeditor-saveerror-hookaborted' which are worse than the ones seen in the normal editor, and the API can return the good ones if we ask for them.

Details

Related Gerrit Patches:
mediawiki/extensions/TitleBlacklist : masterVE: Update for errorformat=html
mediawiki/extensions/VisualEditor : masterve.init.mw.ArticleTarget: Use errorformat=html when saving

Event Timeline

matmarex created this task.Aug 1 2019, 2:52 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 1 2019, 2:52 AM

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

matmarex claimed this task.Aug 8 2019, 8:23 PM
matmarex added a comment.EditedAug 22 2019, 12:16 AM

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 moved this task from Inbox to Low Priority on the Editing QA board.Sep 9 2019, 10:59 PM

@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.

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:

    • 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
  1. 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)
  2. 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)
  3. "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
matmarex edited projects, added Skipped QA; removed Editing QA.

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

ppelberg closed this task as Resolved.Oct 23 2019, 1:07 AM
Restricted Application added a project: User-Ryasmeen. · View Herald TranscriptOct 23 2019, 1:08 AM