Please stop using keypress event to handle non-printable keys

[Masayuki Nakano]

Hello, everyone.

Please stop using keypress event for handling non-printable keys in new
code when you write new code and new automated tests. Firefox will stop
dispatching keypress events for non-printable keys for conforming to UI
Events and struggling with web compatibility. (non-printable key means
key combination which won't cause inputting character, e.g., arrow keys,
backspace key and Ctrl (and/or Alt) - "A" key, etc.)

You can perhaps just use keydown event instead. KeyboardEvent.key and
KeyboardEvent.keyCode of non-printable key events are always same.
Difference between keydown event and keypress event is
KeyboardEvent.charCode of printable keys (and Ctrl/Alt + printable
keys). So, when you need to use only key or keyCode, please use keydown
event. Otherwise, when you need to use charCode, please keep using
keypress event.

Background:

We need to fix bug 968056 (*1) for web-compat issues.

Currently, Firefox dispatches keypress events for any keys except
modifier keys. This is traditional behavior from Netscape Navigator.
However, this is now invalid behavior from a point of view of standards
(*2).

I'm going to start to work on the bug from next week. However, this
requires to rewrite too many keypress event handlers in our internal
code and our automated tests. So, please stop using keypress event when
you want to handle non-printable keys at least in new code.

Thanks in advance.

1: https://bugzilla.mozilla.org/show_bug.cgi?id=968056
2: https://w3c.github.io/uievents/#legacy-keyboardevent-event-types

--
Masayuki Nakano <masa...@d-toybox.com>
Software Engineer, Mozilla
_______________________________________________
firefox-dev mailing list
firef...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev

[Nicholas Alexander]

On Wed, Jan 17, 2018 at 6:34 PM, Masayuki Nakano <masa...@d-toybox.com> wrote:

Hello, everyone.

Please stop using keypress event for handling non-printable keys in new code when you write new code and new automated tests. Firefox will stop dispatching keypress events for non-printable keys for conforming to UI Events and struggling with web compatibility. (non-printable key means key combination which won't cause inputting character, e.g., arrow keys, backspace key and Ctrl (and/or Alt) - "A" key, etc.)

You can perhaps just use keydown event instead. KeyboardEvent.key and KeyboardEvent.keyCode of non-printable key events are always same. Difference between keydown event and keypress event is KeyboardEvent.charCode of printable keys (and Ctrl/Alt + printable keys).  So, when you need to use only key or keyCode, please use keydown event.  Otherwise, when you need to use charCode, please keep using keypress event.

Background:

We need to fix bug 968056 (*1) for web-compat issues.

Currently, Firefox dispatches keypress events for any keys except modifier keys. This is traditional behavior from Netscape Navigator. However, this is now invalid behavior from a point of view of standards (*2).

I'm going to start to work on the bug from next week. However, this requires to rewrite too many keypress event handlers in our internal code and our automated tests.  So, please stop using keypress event when you want to handle non-printable keys at least in new code.

Could someone who is knowledgeable about ES lint comment on whether it is possible to leverage ES lint to draw a line in the sand, at least on the JavaScript side of the house?

Nick

[Gijs Kruitbosch]

On 18/01/2018 16:56, Nicholas Alexander wrote:
> On Wed, Jan 17, 2018 at 6:34 PM, Masayuki Nakano
> <masa...@d-toybox.com <mailto:masa...@d-toybox.com>> wrote:
>
> Please stop using keypress event for handling non-printable keys
> in new code when you write new code and new automated tests.
>
>

> Could someone who is knowledgeable about ES lint comment on whether it
> is possible to leverage ES lint to draw a line in the sand, at least
> on the JavaScript side of the house?

Yes, that should be possible, and from the sounds of it that might be a
good idea. It would likely require adding exceptions for the current set
of users though, and I don't know if that set is so huge now that that
would be prohibitively annoying to do. :-)

Gijs

[Mark Banner]

On 18/01/2018 16:56, Nicholas Alexander wrote:

On Wed, Jan 17, 2018 at 6:34 PM, Masayuki Nakano <masa...@d-toybox.com> wrote:

Hello, everyone.

Please stop using keypress event for handling non-printable keys in new code when you write new code and new automated tests. Firefox will stop dispatching keypress events for non-printable keys for conforming to UI Events and struggling with web compatibility. (non-printable key means key combination which won't cause inputting character, e.g., arrow keys, backspace key and Ctrl (and/or Alt) - "A" key, etc.)

Could someone who is knowledgeable about ES lint comment on whether it is possible to leverage ES lint to draw a line in the sand, at least on the JavaScript side of the house?

If I understand correctly, Masayuki is asking that we stop doing things like `document.addEventListener("keypress", detectKeyEvent);` when expecting a non-printable key. If so, that isn't going to be possible unless keypress is being banned completely.

The problem is we'd need to do analysis of the listener function and what's happening inside it, and that would be too complicated for us to handle in ESLint.

We can do things like ban the use of a particular function, or a function with specific parameters quite easily, but once we need to start looking into actual details, then it tends to be too difficult.

Mark

[Gijs Kruitbosch]

Ah, yeah, I missed the 'figure out whether we care about non-printable
keys' bit. On the other hand, I doubt we really use lots of keypress
listeners for printable characters in frontend JS? By the sounds of it,
all types of shortcuts are basically non-printable, and the only things
that would be printable would be actual text input. Apart from maybe the
urlbar or searchbar (where I'd still expect us to use 'input' events
rather than 'keypress'), I somewhat doubt we have loads of those
handlers... so it might be worth having a (temporary?) eslint rule that
warned for keypress listener additions and adding comments to the ones
that we need for printable keys in the rare cases where that happens.

~ Gijs