Author: equazcion
Description:
As long as the previewing of edits requires a server query, previews should also check if the proposed edit would produce an edit conflict, and return a notification to be displayed to the user in the rendered preview screen. This should apply for the Show Changes function as well.
Version: unspecified
Severity: enhancement
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T72163 Edit conflicts (tracking) | |||
| Open | Feature | None | T19467 Edit conflict notification on Preview/Show Changes |
Mmm, this could indeed be a nice plus. Would probably want to do a merge test, and only throw up the warning if there is an issue -- at which point one could click for further details. (No sense cluttering up the view with a giant conflict screen while you're still working.)
Warn of other revisions saved during edit-preview (not quite the same thing but similar) apparently got a decent amount of votes on the 2019 Community Wishlist.
Community Tech is working on Real Time Preview for Wikitext which might have relevance for this (especially T294319: Refactor preview front-end into reusable API).
Instead of showing this notification on just previews, it should also be possible to show them "live" – API requests for edit stash are already being sent by the client periodically. If another revision was saved in between, that can be included in ApiStashEdit response which can be surfaced to the user as a pop-up via JS.
I managed to duplicate this with T414954: Check for edit conflicts on page preview.
But that comes from T394016: Check edit constraints on page preview which is a proposal to check all relevant edit constraints on page preview. @SomeRandomDeveloper has got it patched to check the redirect constraint, but it'll also be worth checking other constraints like page size limits and spamlink checks at the same time (full list in T394016). The same methods used there could be used to implement this.
I did ask the question why the code that handles the edit conflict isn't an edit constraint. It seems to do a similar kind of job to the (other) edit constraints. I guess it's suboptimal code organisation stemming from development history, which is a Technical-Debt issue.
This is already implemented in the UI. However, AFAICS, isConflict is only set to true in internalAttemptSave. The checks need to be added to the preview logic, or to another method called before that.