Description

The logic responsible for parsing errors for the mobile editor lacks tests and is spread across both EditorOverlay.js and EditorGateway.js.This ticket encompasses cleaning up the code for all editing error scenarios so that they can be better managed in the future.

Developer notes (Here be dragons 🐉)

The edit-conflict scenario falls through to the fail handler in EditorGateway.js#252 even though it produces a 200 response.

That failure is passed to the fail handler in EditorOverlay.js#590 (which expects three parameters, but is only given one 🧐).

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 .fails should be switched to Promise compliant .catchs. (in the code as well as in tests).

Acceptance criteria (done)

Fix error handling for edit conflicts

Any errors are displayed inside the editor itself, above the preview like so:

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.

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

QA steps (reproduce the following editing error scenarios)

read only error

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 error

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 error

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:

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

The error handling now works thanks to Piotr, but the code still needs love. I'd like us to attempt another estimation. I'm struggling to work how to split this up but if I do hopefully a conversation will tell me how.

Coming back to this task, I'm having trouble understanding the scope. I've submitted the above patch, but I suspect there's more to this task then doing just that... @Jdrewniak could you revise this task to make "error handler " less ambigious?

It looks like the scope of this task has expanded from "Wikitext editor error handling broken for edit-conflicts" to "everything wrong with edit error-handling on mobile". I'll see if I can track down the work already done in this area and break this up into smaller tasks.

The error parsing logic is now separated into a parseSaveError.js file, no longer mixed in EditorOverlay.js, hurra!

Unit tests have been improved.

Deferred .fails have been replaced with .rejects.

The bugs with conflict errors have been resolved

The only outstanding work I can see here is the stuff that's already in-progress and further increasing the test coverage by writing tests for the edit conflict scenario (maybe other scenario too? I'm not sure how fully covered they are..)