3 ms·

Question then - what do you use functionally to replace "Escape" in your daily use? As a native English-speaking engineer, the escape button has a history of d

by bbarn 5y ago

Question then - what do you use functionally to replace "Escape" in your daily use? As a native English-speaking engineer, the escape button has a history of doing exactly what you're suggesting it not do going back to the beginning of computing.

int_19h 5y ago
The standard behavior of Esc is to abort the current interaction - which is not the same as closing the dialog. For example, if you have a dialog with a drop-down list, and open that list, Esc should close it, not the whole dialog. In this scenario, the "current interaction" is IME input. The bug is that the page intercepts Esc keypresses intended to be handled by it.
- wccrawford 5y ago
  I haven't checked in a while, but I'm pretty sure the dialog has no idea that the IME is active or not. So the dialog can't handle that situation, and the browser isn't handling it either. The IME/browser should not send escape to the page when canceling an IME selection.
runarberg 5y ago
First of all. Don’t put long forms (i.e. more then a couple of inputs; including checkboxes) in a single dialog modal. Second do listen for keypresses on the dialog it self (not window) so that hitting esc on e.g. the URL bar (or the developer console) has no effect on the dialog it self. And thirdly—as parent states—don’t use deprecated properties and listeners, i.e. use `keydown` and `event.key`. If you follow these three rules feel free to use the esc to close the dialog. I just tested logging `event.key` with hiragana Mozc input device and every keydown while selecting the correct kanji registers as `Process` even cancelling the input with Esc just adds another Process keydown event. I admit it can be frustrating if you double tab Esc accidentally to close the input (second Esc will close the dialog), but that is where rule one comes in, and the accident will only cause the user a minor annoyance.

by bbarn 5y ago

int_19h 5y ago

The standard behavior of Esc is to abort the current interaction - which is not the same as closing the dialog. For example, if you have a dialog with a drop-down list, and open that list, Esc should close it, not the whole dialog. In this scenario, the "current interaction" is IME input. The bug is that the page intercepts Esc keypresses intended to be handled by it.

wccrawford 5y ago
I haven't checked in a while, but I'm pretty sure the dialog has no idea that the IME is active or not. So the dialog can't handle that situation, and the browser isn't handling it either. The IME/browser should not send escape to the page when canceling an IME selection.

runarberg 5y ago

First of all. Don’t put long forms (i.e. more then a couple of inputs; including checkboxes) in a single dialog modal. Second do listen for keypresses on the dialog it self (not window) so that hitting esc on e.g. the URL bar (or the developer console) has no effect on the dialog it self. And thirdly—as parent states—don’t use deprecated properties and listeners, i.e. use `keydown` and `event.key`. If you follow these three rules feel free to use the esc to close the dialog. I just tested logging `event.key` with hiragana Mozc input device and every keydown while selecting the correct kanji registers as `Process` even cancelling the input with Esc just adds another Process keydown event. I admit it can be frustrating if you double tab Esc accidentally to close the input (second Esc will close the dialog), but that is where rule one comes in, and the accident will only cause the user a minor annoyance.