Change Details

Discovered [[ https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/MobileFrontend/+/453131/3/resources/mobile.editor.overlay/EditorOverlay.js@626 | in code-review ]] for T197499, the error handling for the mobile wikitext editor does not produce the correct error messages when an edit conflict occurs. Instead it produces a generic error message "Error, edit was not saved". //This ticket also encompasses cleaning up the code for the remaining error scenarios so that they can be better managed in the future. // Note: There are separate issues with T202460. These should not be included as part of this task. === Steps to Reproduce (i.e. create an edit conflict) # Open a mobile test page, such as [[ https://en.m.wikipedia.beta.wmflabs.org/wiki/Math | betawiki Math ]] in two tabs # In both tabs, open the mobile editor # In one tab, save an edit # In the other tab, try to save the edit. === Expected Results - The first edit should save successfully (which it does). - The second edit should produce an edit conflict (which it does), and warn the user with the `mobile-frontend-editor-error-conflict` message. (i.e. "Error, another user has edited this page."), which it doesn't. === Actual Results - The first edit saves successfully - The second edit produces the generic HTTP error message instead of the error-conflict message. - NOTE: currently, NO message is visible because the toast-message fail to render properly in the overlay, after T197499, a red error box should be seen. === Environments Observed - Local, beta-wiki === Testing Environment for QA - beta cluster == Acceptance crtieria [] Move all logic relating to error classification inside the error handler for this.gateway.save from EditorOverlay into EditorGateway. EditorOverlay should simply print the error. [] Fix error handling for edit conflicts [] Any errors are displayed inside the editor itself, above the preview like so: {F25199953} [] There is currently an eslint-ignore-line for no-restricted-properties - this should be removed as part of the changes here. [] Add unit tests for error handling === Developer notes - fixing the issue and adding tests is the most important thing here. Don't spend too much time refactoring the code. - The edit-conflict scenario falls through to the `fail` handler in [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/MobileFrontend/+/refs/heads/master/resources/mobile.editor.api/EditorGateway.js#252 | EditorGateway.js#252 ]] even though it produces a 200 response. - That failure is passed to the fail handler in [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/MobileFrontend/+/refs/heads/master/resources/mobile.editor.overlay/EditorOverlay.js?autodive=0%2F#590 | EditorOverlay.js#590 ]] (which expects three parameters, but is only given one 🧐). === Here be dragons 🐉 - there are many nested conditionals in the error handling, across both EditorGateway.js and EditorOverlay.js - The responsibilities between which errors are handled in EditorGateway.js and EditorOverlay.js are mixed. - there are no tests for the edit-conflict scenario. - The Deferred's `.fail`s should be switched to Promise compliant `.catch`s. (in the code as well as in tests). = QA steps == read only Open the mobile editor. While open, ask a developer to enable ``` $wgReadOnly = 'This wiki is currently being upgraded to a newer software version.'; ``` [] Does the read only message show when you try to save your edit? == edit conflict Open the editor in 2 tabs In the 2nd tab make an edit and save. In the 1st tab made an edit and save In the 1st tab an error should show. It should make clear there has been an "edit conflict" == http Open the editor Disable your internet connection Save. The error message should be generic. == captcha Try to create a new page on staging as an anonymous user. Doing so should trigger the display of a captcha: {F25205818} It should be possible to type in the captcha and save (note: only if you can decipher it! you may need to try several times...)

Discovered [[ https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/MobileFrontend/+/453131/3/resources/mobile.editor.overlay/EditorOverlay.js@626 | in code-review ]] for T197499, the error handling for the mobile wikitext editor does not produce the correct error messages when an edit conflict occurs. Instead it produces a generic error message "Error, edit was not saved". This [[ https://gerrit.wikimedia.org/r/455895 | has since ]] been fixed, but the code still has problems that relate use of Deferreds and separation of concerns between EditorOverlay and EditorGateway. //This ticket also encompasses cleaning up the code for the remaining error scenarios so that they can be better managed in the future. // Note: There are separate issues with T202460. These should not be included as part of this task. === Steps to Reproduce (i.e. create an edit conflict) # Open a mobile test page, such as [[ https://en.m.wikipedia.beta.wmflabs.org/wiki/Math | betawiki Math ]] in two tabs # In both tabs, open the mobile editor # In one tab, save an edit # In the other tab, try to save the edit. === Expected Results - The first edit should save successfully (which it does). - The second edit should produce an edit conflict (which it does), and warn the user with the `mobile-frontend-editor-error-conflict` message. (i.e. "Error, another user has edited this page."), which it doesn't. === Actual Results - The first edit saves successfully - The second edit produces the generic HTTP error message instead of the error-conflict message. - NOTE: currently, NO message is visible because the toast-message fail to render properly in the overlay, after T197499, a red error box should be seen. === Environments Observed - Local, beta-wiki === Testing Environment for QA - beta cluster == Acceptance crtieria [] Move all logic relating to error classification inside the error handler for this.gateway.save from EditorOverlay into EditorGateway. EditorOverlay should simply print the error. [x] Fix error handling for edit conflicts [x] Any errors are displayed inside the editor itself, above the preview like so: {F25199953} [] There is currently an eslint-ignore-line for no-restricted-properties - this should be removed as part of the changes here. [] Add unit tests for error handling === Developer notes - fixing the issue and adding tests is the most important thing here. Don't spend too much time refactoring the code. - The edit-conflict scenario falls through to the `fail` handler in [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/MobileFrontend/+/refs/heads/master/resources/mobile.editor.api/EditorGateway.js#252 | EditorGateway.js#252 ]] even though it produces a 200 response. - That failure is passed to the fail handler in [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/MobileFrontend/+/refs/heads/master/resources/mobile.editor.overlay/EditorOverlay.js?autodive=0%2F#590 | EditorOverlay.js#590 ]] (which expects three parameters, but is only given one 🧐). === Here be dragons 🐉 - there are many nested conditionals in the error handling, across both EditorGateway.js and EditorOverlay.js - The responsibilities between which errors are handled in EditorGateway.js and EditorOverlay.js are mixed. - there are no tests for the edit-conflict scenario. - The Deferred's `.fail`s should be switched to Promise compliant `.catch`s. (in the code as well as in tests). = QA steps == read only Open the mobile editor. While open, ask a developer to enable ``` $wgReadOnly = 'This wiki is currently being upgraded to a newer software version.'; ``` [] Does the read only message show when you try to save your edit? == edit conflict Open the editor in 2 tabs In the 2nd tab make an edit and save. In the 1st tab made an edit and save In the 1st tab an error should show. It should make clear there has been an "edit conflict" == http Open the editor Disable your internet connection Save. The error message should be generic. == captcha Try to create a new page on staging as an anonymous user. Doing so should trigger the display of a captcha: {F25205818} It should be possible to type in the captcha and save (note: only if you can decipher it! you may need to try several times...)

Discovered [[ https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/MobileFrontend/+/453131/3/resources/mobile.editor.overlay/EditorOverlay.js@626 | in code-review ]] for T197499, the error handling for the mobile wikitext editor does not produce the correct error messages when an edit conflict occurs. Instead it produces a generic error message "Error, edit was not saved". This [[ https://gerrit.wikimedia.org/r/455895 | has since ]] been fixed, but the code still has problems that relate use of Deferreds and separation of concerns between EditorOverlay and EditorGateway. //This ticket also encompasses cleaning up the code for the remaining error scenarios so that they can be better managed in the future. // Note: There are separate issues with T202460. These should not be included as part of this task. === Steps to Reproduce (i.e. create an edit conflict) # Open a mobile test page, such as [[ https://en.m.wikipedia.beta.wmflabs.org/wiki/Math | betawiki Math ]] in two tabs # In both tabs, open the mobile editor # In one tab, save an edit # In the other tab, try to save the edit. === Expected Results - The first edit should save successfully (which it does). - The second edit should produce an edit conflict (which it does), and warn the user with the `mobile-frontend-editor-error-conflict` message. (i.e. "Error, another user has edited this page."), which it doesn't. === Actual Results - The first edit saves successfully - The second edit produces the generic HTTP error message instead of the error-conflict message. - NOTE: currently, NO message is visible because the toast-message fail to render properly in the overlay, after T197499, a red error box should be seen. === Environments Observed - Local, beta-wiki === Testing Environment for QA - beta cluster == Acceptance crtieria [] Move all logic relating to error classification inside the error handler for this.gateway.save from EditorOverlay into EditorGateway. EditorOverlay should simply print the error. [x] Fix error handling for edit conflicts [x] Any errors are displayed inside the editor itself, above the preview like so: {F25199953} [] There is currently an eslint-ignore-line for no-restricted-properties - this should be removed as part of the changes here. [] Add unit tests for error handling === Developer notes - fixing the issue and adding tests is the most important thing here. Don't spend too much time refactoring the code. - The edit-conflict scenario falls through to the `fail` handler in [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/MobileFrontend/+/refs/heads/master/resources/mobile.editor.api/EditorGateway.js#252 | EditorGateway.js#252 ]] even though it produces a 200 response. - That failure is passed to the fail handler in [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/MobileFrontend/+/refs/heads/master/resources/mobile.editor.overlay/EditorOverlay.js?autodive=0%2F#590 | EditorOverlay.js#590 ]] (which expects three parameters, but is only given one 🧐). === Here be dragons 🐉 - there are many nested conditionals in the error handling, across both EditorGateway.js and EditorOverlay.js - The responsibilities between which errors are handled in EditorGateway.js and EditorOverlay.js are mixed. - there are no tests for the edit-conflict scenario. - The Deferred's `.fail`s should be switched to Promise compliant `.catch`s. (in the code as well as in tests). = QA steps == read only Open the mobile editor. While open, ask a developer to enable ``` $wgReadOnly = 'This wiki is currently being upgraded to a newer software version.'; ``` [] Does the read only message show when you try to save your edit? == edit conflict Open the editor in 2 tabs In the 2nd tab make an edit and save. In the 1st tab made an edit and save In the 1st tab an error should show. It should make clear there has been an "edit conflict" == http Open the editor Disable your internet connection Save. The error message should be generic. == captcha Try to create a new page on staging as an anonymous user. Doing so should trigger the display of a captcha: {F25205818} It should be possible to type in the captcha and save (note: only if you can decipher it! you may need to try several times...)