Intent to ship: stop dispatching "keypress" events when pressed key (key combination) does not introduce text input

[Masayuki Nakano]

Summary: We'll stop dispatching non-printable "keypress" events.
"non-printable" means that key press or key combination does not
introduce text input without IME. For example, arrow key press, Ctrl+A,
etc.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=968056

Link to standard:
For keys which introduce text input:
https://w3c.github.io/uievents/#legacy-keyboardevent-event-types
For Enter key:
https://github.com/w3c/uievents/issues/183

Platform coverage: All

Estimated or target release: 65

DevTools bug: N/A

Do other browser engines implement this?

Yes, the other browsers use this behavior traditionally, and UI Events
declared the behavior as "standard".

web-platform-tests: N/A due to requiring user input, but we have
mochitests with synthesized events.

This new behavior was enabled in Nightly since 61. This caused breaking
a lot of major web apps. However, all of them have been fixed by the
cooperation of the vendors.

Of course, we may meet other broken web apps especially in intranet.
While we're testing this behavior in Nightly, we used blacklist pref
(dom.keyboardevent.keypress.hack.dispatch_non_printable_keys) to disable
this new behavior only in specific domains. If we'll get broken web
apps even after release, we and users can disable it with using this
blacklist.

Enabling patch has been landed from:
https://bugzilla.mozilla.org/show_bug.cgi?id=1496288
because we need to manage those changes as a set.

--
Masayuki Nakano <masa...@d-toybox.com>
Software Engineer, Mozilla

[Eli Grey]

I think the spec is confusing and not well-reasoned enough to introduce this misnomer. This change will make it so that there are two events with synonymous meaning, and only introduces potential site breakage.

The event is literally called "keypress", not "input". Developers are going to end up using it to track keypresses regardlessly due to the incorrect name. If they want to track input, that's what the "input" event is for.

[Masayuki Nakano]

On 2018/12/01 8:51, Eli Grey via dev-platform wrote:
> I think the spec is confusing and not well-reasoned enough to introduce this misnomer. This change will make it so that there are two events with synonymous meaning, and only introduces potential site breakage.
>
> The event is literally called "keypress", not "input". Developers are going to end up using it to track keypresses regardlessly due to the incorrect name. If they want to track input, that's what the "input" event is for.

"keypress" event was introduced by IE, and UI Events (formerly, called
DOM Level 3 Events) defines the behavior from existing browsers, but
marking them as "legacy".

Under current spec, "keydown" and "keyup" events represent "physical"
event on the input device. "keypress" is "logical" event of text input
from keyboard directly (i.e., not via IME). "input" and "beforeinput"
are similar to "keypress", but they are fired only when an editor has
focus and with any input devices/middle wares.

Currently, I'm working on implementing "beforeinput". It allows all web
apps to stop handling "keypress" in the future and to prevent default
action easier.