The logic for determining the Content object for the undo based on the supplied 'undo' and 'undoafter' URL parameters looks like it's already in ContentHandler::getUndoContent(). EditPage calls through the stub in WikiPage, while ApiEditPage calls ContentHandler directly.

But note that the logic for undoing edits via the web UI ends with displaying the edit form with the undo content loaded (or not, if there's a "merge" conflict), so this probably depends on T174033: Refactor EditPage to allow multiple slots to be edited atomically [MCR].

Perhaps free form editing can be dropped from the undo function completely.

That sounds like a "torches and pitchforks" type of change.

EditPage will already have to deal with not-editing slots that aren't directly editable, all this would mean is the not-editing carrying forward the Content object from ContentHandler::getUndoContent() instead of inheriting the slot. We'll probably need to do something similar anyway for when someone edits an old revision rather than the current one.

When the undo operation spans multiple slots, free form editing should be disabled.

Same.

As a baseline, undo operations could just be denied of they would affect any slots other than the main slot.

That's probably the most straightforward approach until T174033 is done. Although the Commons editor community might consider that a blocker to SDC deployment.

When you are undoing past edits (ie. the "new" end of the undo range is not the current edit), the undo operation creates a content (array of contents, post-MCR) that does not exist on disk. That content needs to be presented to the user and then saved. Currently, EditPage just displays that content in the edit form; adding support for undo-without-edit would be nontrivial work, while multi-slot editing gives you multi-slot undo for free. (OTOH maybe we need undo-without-edit anyway if some slots don't support editing but support undo?)

maybe we need undo-without-edit anyway if some slots don't support editing but support undo?

Yes. This is already the case for SDC. MediaInfo does not support direct editing. Wikibase has its own implementation of edit=undo, which just shows a diff (no content view). But that also only works with the main slot.

I note there's no reason the edit form with the undo content would have to actually be editable for any particular field or having the raw content of that field being displayed to the user, as long as the preview and show changes functions work sensibly. In the extreme case, an "undo without edit" could have all fields' content as <input type="hidden"> or as data stored in the session server-side.

an "undo without edit" could have all fields' content as <input type="hidden"> or as data stored in the session server-side.

No need for even that, all data is already stored on the server side.

Change 447099 had a related patch set uploaded (by Anomie; owner: Anomie):
[mediawiki/core@master] MCR: Add temporary web UI mcrundo action

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

Should this still block T194750: Deploy Structured Data on Commons baseline , or is T200216: Make undo work with SDC by showing a UI to confirm undo without allowing an edit sufficient?

In T189808#4531474, @Jdforrester-WMF wrote:

Should this still block T194750: Deploy Structured Data on Commons baseline , or is T200216: Make undo work with SDC by showing a UI to confirm undo without allowing an edit sufficient?

Thanks for catching that! It should not block T194750: Deploy Structured Data on Commons baseline .

In T189808#4532284, @CCicalese_WMF wrote:

Thanks for catching that! It should not block T194750: Deploy Structured Data on Commons baseline .

I think we went back and forth on this a few times, and ended up pulling it into phase 2. We can drop it again, but it'S nearly finished anyway.

The latest decision, on July 23, was to pull it back out of phase 2 again.

It's not clear to me what this task is about. It mostly seems to describe T200216: Make undo work with SDC by showing a UI to confirm undo without allowing an edit (which got merged). Is it about doing the same thing from within EditPage (or whatever it gets refactored to), without the redirect hack?

The task was originally a combination of "make undo fully work, including editing of directly-editable slots" and the hack for SDC that was eventually split into T200216, plus some musing on the feasibility of fundamentally changing how undo works that I'm sure would not fly with our on-wiki editor communities.

I'm going to rewrite it to reflect only the bit that wasn't split out, and remove the aforementioned musing.