Page MenuHomePhabricator

Non-javascript preview of editing conflict resolution for article and talk pages
Open, Needs TriagePublic13 Estimated Story Points


User Story:
As a user entering an edit conflict
And without javascript
I want to be able to preview the changes I have made
So that I can check if the rendered output with my changes looks as I expected

Acceptance criteria:

  • The user can preview a rendered version of the current state text, including any changes done by the user themselves
  • The user should be able to preview changes to both text and order of comments
  • The user can make additional changes or save and publish changes if they don’t
  • The interface should be usable with keyboard commands
  • The interface should be screenreader compatible


Non JS Article - Preview.png (1×1 px, 655 KB)

Non JS Discussion - Preview.png (1×1 px, 265 KB)

These mocks show what we expect it to look like, but are not intended as 'designs.' Follow conventions of existing preview pages, showing the preview stacked on the editing area. Keep 'Go to editing area' link which jumps down to the editing area on the page. "Show preview" button should remain in action block at bottom, which refreshed page/preview when clicked.

Event Timeline

Lena_WMDE renamed this task from Non-javascript preview of editing conflict resolution for talk pages to Non-javascript preview of editing conflict resolution for article and talk pages.Apr 9 2020, 9:32 AM

Breadcrumb: we remove the "Preview" button here.

Change 593238 had a related patch set uploaded (by Andrew-WMDE; owner: Andrew-WMDE):
[mediawiki/core@master] [POC] EditPage remember isConflict on wpPreview

Change 593245 had a related patch set uploaded (by Andrew-WMDE; owner: Andrew-WMDE):
[mediawiki/extensions/TwoColConflict@master] [POC] No JS preview using EditPage's preview functionality

I see two possible approaches to solving this problem:

My first approach tries to utilize EditPage's built in preview functionality. The first problem with this approach is that the EditPage seems to "forget" that it was in a conflict when previewing. This means our TwoColConflict view is skipped altogether when showing a preview. This patch tries to solve this by having the EditPage remember if it was handling a conflict when the preview button was pressed. However, the patch in it's current state messes with the legacy conflict view. The next issue that came up was preserving any changes the user had made to either side of the columns before/during previewing, this patch rudimentarily tries to address that issue.

My second approach would involve adding the ability to reload the EditPage, e.g. patch. Then similar to the first approach, we would still need preserve any changes or button selections made by the user before/during previewing. However, this time when the user clicks preview, we only reload the EditPage and generate the preview manually in TwoColConflict instead of in EditPage.

Andrew-WMDE moved this task from Doing to Sprint Backlog on the WMDE-QWERTY-Sprint-2020-04-29 board.
Andrew-WMDE added a subscriber: Andrew-WMDE.

I'll start by looking at why EditPage "forgets" about the conflict. If baseRevId is passed through, I don't see why the conflict would disappear.

Preserving the in-progress modifications etc. seems hard, my first instinct is to run the merger and start over from scratch starting with the edited text, and it might be best to reset column selections to "your" side after doing that. Losing edits on the non-accepted side seems like a reasonable loss.

@Lena_WMDE @ecohen Just so you're aware, there are implementation decisions to make around how hard we work to preserve the form exactly as it was after reloading with the preview. I'll try to summarize:

DataHow hard is it to preserve?
Base revision for conflictEasy, and IMO essential.
"Other" revision in conflictMedium. The edit page currently wants to target whatever latest revision is in conflict. If the conflict has disappeared (for example, massive spam like page blanking, that has been reverted in the meantime), we would save the edit rather than reopening a conflict dialog. On the flip side, if we preserve this data then the editor is locked into resolving a specific conflict (which will have disappeared in the page blanking example), and then possibly re-resolving again later. This is a trade-off that we should consider carefully, and has come up a few times already during this project, without us giving a conclusive answer. There are a few things we can do here, it's not necessarily an either-or question.
Edited text in selected columnsEasy and necessary.
Edited text in unselected columnsDifficult. Also interacts with the "other" text above, because retargeting the other side of the conflict will break edited "other" text.
Exact layout of rowsDifficult. Without this, text and gray "copy" boxes might jump around according to how the conflicts have changed.
Column selectionsDifficult. Depends on exactly repeatable row layout, other text staying the same, and so on.

After some discussion, we've decided to only preserve the submitted text, allowing the conflict to change as necessary. We may add a notice informing the editor that funny stuff happened.

thiemowmde added a subscriber: thiemowmde.

@Lena_WMDE: I wonder how this ended in the sprint? If I remember correctly this was discussed a few times over the past months, if not years, see T210501 as well as Main technical questions from back then have not been answered, as far as I'm aware of. The current proof-of-concept patches show the issues (again). I would not have estimated this with 13 points, but something like 50.

I stand with my original recommendation: This is way to hard to implement, and requires us to live with significant technical debt we will never be able to pay back, for a smaller use case (users who need a preview) for a very tiny user group (no-JS users). Let's please not do this. What these user still can do is just force their version to be saved, and then use the page history, diff, and preview to resolve possible reverts they made. These users don't get stuck just because they don't have a preview. This is not a critical feature for these users, as far as I'm concerned.

Change 594421 had a related patch set uploaded (by Awight; owner: Awight):
[mediawiki/extensions/TwoColConflict@master] [POC] Always show preview button, fall through to legacy

Change 594440 had a related patch set uploaded (by Awight; owner: Awight):
[mediawiki/extensions/TwoColConflict@master] [WIP] Server-side preview

Incomplete list of specific issues with this ticket:

  • The way the task description and acceptance criteria are phrased right now, this ticket asks for a flawless implementation with no acceptable compromises. This does not reflect any of the recent discussions and patches.
  • The estimation is 3 months old. It's especially older than T245505 and related tickets, where we learned a lot about the no-JS behavior of submitting and re-creating the conflict resolution screen.
  • A no-JS preview requires us to make a POST request. We learned this will make us run in all the same issues as discussed in T245505. Most notably:
    • We don't know what the entry point for this request should be. Multiple proposals have been made: a new special page, a new hook in EditPage (, a new request parameter that changes the behavior of EditPage (, or reusing our existing validation mechanism (
    • EditPage is a 4800 lines file. It's one of the most essential elements of MediaWiki, as it's responsible for all editing. Even the editing APIs just redirect to this implementation. Changes to this file need careful testing, and still have the potential to break unrelated code paths. It's among, if not the highest ranked "project risk".
    • Most of the proposals so far come with unexpected side-effects, like possibly showing a different conflict when another edit was made in the background in the meantime. Or loosing parts of the state of the resolution form (e.g. edits in some of the textareas).
  • The proposal @Andrew-WMDE created a week ago depends on a change to cores EditPage.
  • With the most recent proposal, there are currently 2 orange message boxes on top of the preview. One talks about multiple textareas. These only exist in the old interface.
  • Our own message "you can help improve this feature" appears below the preview, but above the resolution interface. This placement is unexpected.
  • When clicking "preview", the reloaded conflict screen shows all rows with red error markers, as if nothing is selected. (This might be fixed in the current patch, but needs test coverage.)
  • When selecting the left side before clicking "preview", this row might disappear from the conflict screen. The users unsaved change is lost.
  • Selections get lost.
  • When doing an edit on the left side before clicking "preview", this edit is lost.
  • A fallback to the legacy code path as proposed in means the user can't go back to the resolution screen after clicking "preview".
  • While working on it turned out the talk page special case does make the patch much more complicated than expected.
  • There is a user setting previewonfirst which causes the preview to always been shown. Since the current proposal in intentionally side-steps the existing preview implementation, we might need to re-implement this feature.
  • Same for the previewontop user setting, which changes the position of the preview from top to bottom.
  • The previewonfirst user setting is also affected by a $wgPreviewOnOpenNamespaces server setting. We might need to respect this as well in our implementation.

It might be that most, if not all of these issues can be fixed. We just need to make sure we do this, or document each of these as being acceptable. I suggest to open individual tickets for each issue listed, to make sure we have enough space for said documentation.

Change 593245 abandoned by Andrew-WMDE:
[POC] No JS preview using EditPage's preview functionality

Change 593238 abandoned by Andrew-WMDE:
[POC] EditPage remember isConflict on wpPreview