Page MenuHomePhabricator

Ask whether to recover, not whether to discard
Closed, ResolvedPublicFeature

Description

More than once it happened to me that Edit Recovery recovered an edit to a template or article that I previously abandoned – without being explicit that anything was recovered. This is not the expected behavior, thus reporting as a bug. Software like Libre Office will ask you if you want to recover an edit that had not been ended cleanly, and so should ER.
It's a helpful feature, but can make more damage that I'd ever want. This behavior was too annoying and, sadly, I had to disable ER.

A few more similar reports at the bottom of https://meta.wikimedia.org/wiki/Special:Permalink/26741000

Derived Requirement

Ensure that the Edit Recovery (ER) feature explicitly prompts the user when attempting to recover an unsaved or abandoned edit, asking for confirmation before proceeding with the recovery. The user should be informed that an edit was recovered, and given the option to either continue editing or discard the recovery.

BDD

Feature: Edit Recovery User Prompt

Scenario: Prompt user when Edit Recovery attempts to recover an unsaved or abandoned edit

Given the user is editing a template or article in the wikitext source editor
And the user previously abandoned an edit
When Edit Recovery restores the abandoned edit
Then the system should display a prompt notifying the user about the recovered edit
And the system should give the user the option to continue with the recovered edit or discard it
Test Steps

Test Case 1: Ensure Edit Recovery Prompts User for Confirmation Before Restoring Abandoned Edits

  1. Begin editing a template or article on Wikipedia.
  2. Abandon the edit without saving and close the editing window.
  3. Reopen the editing window to trigger Edit Recovery.
  4. ✅❓❌⬜ AC1: Confirm that the system provides an option for the user to either continue with the recovered edit or discard it.
  5. ✅❓❌⬜ AC2: Confirm that if the user chooses to discard, the recovery is abandoned and editing begins with a clean slate.

QA Results - BETA

ACStatusDetails
1T364664#10219535
2T364664#10219535

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

@Ponor to help us better understand your need, could you please update a screenshot or two of the experience you've documented, and what you'd expect to happen?

MusikAnimal changed the subtype of this task from "Bug Report" to "Feature Request".Aug 28 2024, 6:43 PM

without being explicit that anything was recovered

So you're saying the popup never showed? If so, that is a bug. Ideally you could share repro steps. I've not heard of this specific problem, and the linked discussion doesn't seem to complain about it, either. Related: T354392

The task otherwise is asking for Edit Recovery to prompt whether to restore, rather than do so and prompt to discard. That makes it a feature request, as the latter behaviour is by design.

@MusikAnimal: I've spoken to @JWheeler-WMF and I'm hoping his team will care of this behavior.
Yes, it's by design, but the design decision is, arguably, flawed. Most, if not all software asks whether to restore.

The popup does show, but if you scrolled down for some reason (say, to make the edit area fully visible/centered), you won't see the popup.

The popup does show, but if you scrolled down for some reason (say, to make the edit area fully visible/centered), you won't see the popup.

Bubble notifications like the one used in Edit Recovery should stay visible when scrolling. If it doesn't, that's an issue separate from Edit Recovery.

Anyway, I'm not refuting what this task is asking, just clarifying that it isn't a bug. I think we did "prompt to discard" because it's consistent with other edit recovery tools used in MediaWiki, such as those provided by VisualEditor and DiscussionTools.

DiscussionTools is different. You're not editing someone else's work but your unfinished/unsent message.

Can't remember the last time VisualEditor restored anything for me. I remember that working in 2020/2021 or so, but not recently.

Maybe Edit Recovery only needs a more obvious notification, like a true popup modal window that blocks the view, something similar to Edit summary modal window?
And it should also tell people which version it's restoring (date and time, and if any other edits have been saved since then). @JWheeler-WMF?

I'm not quite sure how the "show changes" feature should work in the ask-to-recover flow. It feels slightly odd to see the normal changes view showing changes that aren't actually in the edit box, so it might be better to only have restore and discard buttons in the notification.

So the text would be something like this:

Recover changes?
You have unsaved changes that can be automatically recovered.
[Note that the page may have changed since you started editing.] (Optional)
[Please review your changes before [publishing|saving].] (Optional)
Recover Discard

So, to show changes it'd be a matter of recovering and then using the normal show changes function.

Thoughts?

Change #1076901 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/core@master] Edit recovery: Ask to recover, not to discard

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

Change #1076901 merged by jenkins-bot:

[mediawiki/core@master] Edit recovery: Ask to recover, not to discard

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

Looks good to me, Samwilson. I mean the dialog.
Yes, the show changes (diff) button should be where it is now, in the Save/summary dialog.
It doesn't hurt to have these two warnings, though the "may have changed" seems more important to me (if you can compare the time of the last live on-wiki revision and the time of the locally saved edit)
Thanks!

Yes, you're right, the "Note that the page may have changed since you started editing" message could perhaps be "…since you last edited it"? The "may have" part is because, although we can see that there are subsequent changes, we're not actually looking to see what the current diff is between those changes is and the current recovery data. So for example, if you start editing and close the tab, then some vandalism is added and reverted, we show that warning even though actually those two intervening edits aren't going to make a difference.

Well, let's see how it feels working with it now for a while, and then keep tweaking things. The switch to ask-to-recover will go out in next week's train.

Change #1077333 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/core@master] Edit Recovery: wrap buttons if their text is long

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

Change #1077333 merged by HMonroy:

[mediawiki/core@master] Edit Recovery: wrap buttons if their text is long

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

@Samwilson Please review the testing results below, thanks!

Test Result - Beta

Status: ❓NMI (Needs More Information)
Environment: Beta
OS: macOS Sonoma 15.0
Browser: Chrome 129
Device: MBA
Emulated Device: NA

Test Artifact(s):

Test Steps

Test Case 1: Ensure Edit Recovery Prompts User for Confirmation Before Restoring Abandoned Edits

  1. Begin editing a template or article on Wikipedia.
  2. Abandon the edit without saving and close the editing window.
  3. Reopen the editing window to trigger Edit Recovery.
  4. ❓ AC1: Confirm that the system provides an option for the user to either continue with the recovered edit or discard it.

Should Source and Visual act differently as seen in the gifs?

Source EditingVisual Editing
2024-10-10_10-53-26.mp4.gif (864×1 px, 1 MB)
2024-10-10_11-44-44.mp4.gif (834×1 px, 1 MB)
  1. ❓ AC2: Confirm that if the user chooses to discard, the recovery is abandoned and editing begins with a clean slate.

For Visual, there is no option to select "discard" since it recovers automatically as seen in the gifs. Source is fine

Source EditingVisual Editing
2024-10-10_11-35-14.mp4.gif (772×1 px, 1 MB)
2024-10-10_11-44-44.mp4.gif (834×1 px, 1 MB)

Possible issues

  1. ❓ Should ER pop up again if you don't select an option and then click "Read" or "View history" and then go back to "Edit" as seen in the gif below? For Visual, Recover appears again when going to "Read" and then back to "Edit".

Source Editing| Visual Editing

2024-10-10_11-39-06.mp4.gif (1×1 px, 2 MB)
2024-10-10_11-52-28.mp4.gif (748×1 px, 1 MB)

Should Source and Visual act differently as seen in the gifs?

Edit Recovery is for source mode, VisualEditor provides its own recovery mechanism, so this task is technically only about source mode. However, it’s of course always good if similar features of different tools align.

Should ER pop up again if you don't select an option and then click "Read" or "View history" and then go back to "Edit" as seen in the gif below?

No. What you're seeing there is correct because it's taking the current unrecovered state of the form to be what you want, and saving that.

And yes, as Tacsipacsi says, VE is out of scope for this task — sorry that I didn't add that to the description!