Page MenuHomePhabricator

Users are requesting a "Cancel and exit without saving" option
Open, MediumPublic

Description

In the last couple of months, I've seen about half a dozen requests for the 'cancel' button to be returned (yes, the same Cancel button that almost no one was using when it was present). These requests are usually from new editors.

The toolbar is cluttered, and redesigning it (e.g., so that it can be zoomed in without eating half the screen) is probably not going to result in such dramatic space saving that this almost-unused button would be worthwhile. However, what about an escape clause under the Help menu, or next to the "Switch to source" item in the Page options menu?

Related Objects

Event Timeline

Whatamidoing-WMF raised the priority of this task from to Needs Triage.
Whatamidoing-WMF updated the task description. (Show Details)
Ryasmeen triaged this task as Medium priority.Jan 15 2015, 2:12 AM
Ryasmeen set Security to None.

I can confirm, that new users have issues leaving the edit mode. Couldn't we just have an option to turn on/off the cancel button?

I don't think that an option will help.

I think the "unsaved changes hav been automatically recovered" feature makes it more important to have an obvious way to safely abort/cancel an edit. Previously there was no consequence to how you aborted/cancelled (and there are many ways to do it) but now there is. If you "exit" the wrong way, you created "unsaved changes" that will reappear later and cause unintended problems.

We’ve had an ongoing “let’s see if we can turn the Save button into a dropdown” task, and if we did this is another thing it’d be convenient to drop in there.

We've also talked about adding it to one of the existing menus, e.g., in the Help menu next to "Read the user guide" and "Leave feedback about this software".

I've been a few times now in this situation where unwanted changes were recovered.

Maybe it would make more sense to place this "cancel" button in context, just below the message: "Your changes have been recovered" => "Abandon/reload etc".?

I've been a few times now in this situation where unwanted changes were recovered.

Maybe it would make more sense to place this "cancel" button in context, just below the message: "Your changes have been recovered" => "Abandon/reload etc".?

This would be fantastic. Several times I've navigated away from the edit page to "cancel" the edit, only for the editor to put them back in when I attempt to edit the page again. I don't always get the "save or discard" prompt when leaving the page, so the editor defaults to putting my unwanted edits back. A way to discard or abandon the changes when I reopen a page for editing would be very helpful. Especially since Ctrl Z only remembers how to undo unsaved changes from the current session (and not the previous unsaved one). I've had to resort to showing a diff of the current changes in order to undo them manually, then make my changes.

While there is no explicit button to reliably discard your changes, you can still do it by pressing Escape on your keyboard, or by clicking on the "Read" tab.

Especially since Ctrl Z only remembers how to undo unsaved changes from the current session (and not the previous unsaved one).

You should definitely be able to undo the restored unsaved changes. Maybe you ran into the issue described in T202730: Auto-save should preserve undo stack, not just complete history? If you can describe how to reproduce this bug, we can (probably) fix it.

Ok, so I managed to pin down why the editor save box doesn't show up sometimes. When editing a non-talk page, clicking the tab for that page triggers the editor save box (e.g. "read" tab on an article, "project page" tab on project namespace, etc.), but clicking anything that would change the URL (talk page, main page, your user page, etc.) triggers the browser's unsaved changes prompt (so no ability to discard).

Conversely, when editing a talk page, clicking the talk page tab doesn't trigger the editor save box, but the browser's unsaved changes prompt, just like clicking away would. Maybe this should be changed so clicking the talk page tab works the same as the main tab does when editing. Using Esc works reliably to produce the editor save box in all cases (thanks for mentioning that).

As far as the undo stack not being preserved issue, I've found that the full history is actually preserved, but for some reason, after a few Ctrl+Zs, the editor stops responding to my Ctrl+Z until I spam it several more times. Then it continues to back up through the history. Weird, but it seems to work. I don't think it's lag or anything, since undo works immediately from the current editing session, over dozens of changes.

We’ve had an ongoing “let’s see if we can turn the Save button into a dropdown” task, and if we did this is another thing it’d be convenient to drop in there.

For reference, that's T153306: Have Show preview and Review your changes more directly accessible in the New Wikitext Editor.

We've talked about this task for about 30 seconds in the planning meeting today, and @Esanders reminded me of a different possible solution for the specific use case of discarding your autosaved edits: changing the notification popup about restored edit to have a button to discard it.

I've proposed something similar a while ago when we were working on T190077 (we used a different solution there in the end, but if we use the notification bar here, we could align that one to be the same).

I've made a quick mockup of the "notification bar" now, with a "Discard" button:

image.png (476×1 px, 81 KB)

For reference, this is the current successful autosave notification:

image.png (476×1 px, 80 KB)

And the current modal dialog when page with autosaved changes was edited in the meantime:

image.png (476×1 px, 79 KB)