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

https://gerrit.wikimedia.org/r/593238

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

https://gerrit.wikimedia.org/r/593245

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.

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

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.

@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 https://gerrit.wikimedia.org/r/478223. 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

https://gerrit.wikimedia.org/r/594421

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

https://gerrit.wikimedia.org/r/594440

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 (https://gerrit.wikimedia.org/r/559116), a new request parameter that changes the behavior of EditPage (https://gerrit.wikimedia.org/r/593245), or reusing our existing validation mechanism (https://gerrit.wikimedia.org/r/594440).
  • 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 https://gerrit.wikimedia.org/r/593245 @Andrew-WMDE created a week ago depends on a change to cores EditPage.
• With the most recent proposal https://gerrit.wikimedia.org/r/594440, 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 https://gerrit.wikimedia.org/r/594421 means the user can't go back to the resolution screen after clicking "preview".
• While working on https://gerrit.wikimedia.org/r/594440 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 https://gerrit.wikimedia.org/r/594440 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

https://gerrit.wikimedia.org/r/593245

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

https://gerrit.wikimedia.org/r/593238