Page MenuHomePhabricator

Escape key inside the main editor should cancel VE mode and return to action=view
Closed, ResolvedPublic

Description

Author: gigs

Description:
I see that a cancel button has been added, which is an improvement, but the escape key should also cancel edit mode.


Version: unspecified
Severity: enhancement

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 1:52 AM
bzimport set Reference to bz50868.

The escape key is used by browsers to defocus (blur) currently focused form element. Reusing it for this would be really annoying.

gigs wrote:

What browsers? Not Chrome or Firefox. I don't have IE here to test with, but I doubt it does it either.

http://www.w3schools.com/jquery/tryit.asp?filename=tryjquery_event_blur_alert

Opera does that; it's useful enough that I expected other browsers to behave similarly. IE8 resets the value to the default (for both inputs and textareas). And Firefox apparently doesn't do anything, like you said.

gigs wrote:

OK, but my next question is: What form fields are people going to be interacting with when in the main Visualeditor? The only form field I see is the search box.

I think this isn't a bad idea, though I'm a little troubled if this causes unexpected behaviour for users of some browsers.

On macs, cancel is usually cmd-.

Wouldn't mind having that in VE.

I'd like to note that really this should only happen iff someone is exclusively in edit mode. IOW, if someone has opened the template inspector, close that. Link inspector, close that - so on and so forth.

gigs wrote:

Agreed, that's how I envisioned it.

Clarify title so it's clear we all agree.

Yes, pressing escape when in a dialog should close that level of the dialog (if more than one) or the dialog if it's at the top level of the dialog. If a change was confirmed then it should remain when closed, if a change was unconfirmed it should be cancelled.

With no dialogs open, escape should exit VE but should ask for confirmation before doing so if there are unsaved changes. That dialog should have keyboard actions such that enter confirms you want to leave and escape indicates that you don't want to leave and take you back to the VE. This will stop people losing work if they hit esc accidentally or too many times.

I'm a bit worried about this. What if I'm in a template dialog and accidentally press Esc twice/too long? If this triggered the "Do you really wnt to exit?" confirmation, it might be okay. However, I suspect that this might not have the ultimate effect that was intended.

(In reply to WhatamIdoing from comment #11)

I'm a bit worried about this. What if I'm in a template dialog and
accidentally press Esc twice/too long? If this triggered the "Do you really
wnt to exit?" confirmation, it might be okay. However, I suspect that this
might not have the ultimate effect that was intended.

Comment 10 asks for the unsaved changes warning to be shown. If we do that, I think it'll be fine. Pressing escape while a dialog is open will dismiss that dialog with a safe action (the cancel/never mind action). So if you press escape again when the unsaved changes warning is visible, that'll dismiss the warning with the safe action, which is "never mind, I want to continue editing". So if you press Esc a bunch of times or hold it too long, you'll end up in a loop of the unsaved changes warning appearing and being dismissed.

Change 175868 had a related patch set uploaded (by Alex Monk):
Dialog: Only handle escape events when open

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

Patch-For-Review

Change 175869 had a related patch set uploaded (by Alex Monk):
Cancel VE when escape key pressed

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

Patch-For-Review

Change 175868 merged by jenkins-bot:
Dialog: Only handle escape events when open

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

Change 175869 merged by jenkins-bot:
Cancel VE when escape key pressed

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

Resolution is determined by QA for features and bugs.

Resolution is determined by QA for features and bugs.

Huh?

Jdforrester-WMF renamed this task from VisualEditor: Escape key (and on Macs additionally ⌘-. ) inside the main editor should cancel VE mode and return to action=view to Escape key inside the main editor should cancel VE mode and return to action=view.Dec 3 2014, 6:24 PM
Jdforrester-WMF closed this task as Resolved.

Verified in betalabs. Escape key will bring a warning message box 'Are you sure?'

The discussion above makes sense and I think the <escape> key feature as currently implemented is probably helpful to some people. But as a user who heavily uses <esc> to get out of "insert ..." dialogs and so on, it's alternately scary and annoying that a hitting (any) key too many times threatens to cancel my changes without saving.

I'm not sure what improvements to suggest. On second thought... There doesn't seem to be a Cancel button, which makes it arch-surprising that a keyboard shortcut would do so. What about changing the behavior of <esc> to "Save Changes" instead? This seems consistent and friendly.

It is a somewhat traumatic experience when you press Esc too hard in a dialog (or try to use Esc to cancel text selection etc) and VE shows a helpful "would you like me to irrecoverably throw away the result of your last three hours of work? Y/N" dialog. It's probably not easy to confirm by accident but it's still a pretty bad feeling. Has this been through any user testing at all?

Alex42 reopened this task as Open.EditedFeb 18 2022, 9:45 AM
Alex42 subscribed.

This feature worked as expected until now. The last time i remember it working correctly is a few month ago.

But now it is broken and no dialog "Are you sure?" is shown any more, when pressing Esc key once. Yesterday i lost a hour of work.

Tested in main view of VisualEditor on fr-, de- and en-wiki with Firefox 97.0 (64-Bit) on Win10.

See also this disussion: en-wiki:User_talk:Nick_Moyes#ESC_key_in_VisualEditor

@Alex42 Thanks for reporting this. I filed a separate task about it: T302096: Escape key instantly closes VE and discards changes with no confirmation. This task is from almost 9 years ago, and the cause of the new problem is almost certainly not related.