Intent to stop dispatching "keypress" event for non-printable keys and key combinations in Nightly and early Beta

[Masayuki Nakano]

I'd like to stop dispatching "keypress" event for non-printable keys and
key combinations in the default event group of web content in Nightly
and early Beta for collecting regression reports.
https://bugzilla.mozilla.org/show_bug.cgi?id=1440189

By UI Events, "keypress" event is defined as:
> this event MUST be dispatched when a key is pressed down,
> if and only if that key normally produces a character value.
https://w3c.github.io/uievents/#event-type-keypress

So, non-printable key means:
* Function keys like ArrowLeft, ArrowDown, F1, Home, End, Tab, etc.
* Ctrl + KeyA etc.

Note that Enter key is special. Other browsers' behavior of "keypress"
event for Enter key is not same. However, unmodified Enter,
Shift+Enter, Ctrl+Enter causes any browsers and any platforms.
Therefore, we'll continue to dispatch "keypress" event only for those
key combinations.
https://github.com/w3c/uievents/issues/183

If you're a developer of our UI, please consider to use "keydown" event
listener to handle non-printable keys and key combinations. However,
calling preventDefault() of "keydown" event stops dispatching the
following "keypress" event. Therefore, if you cannot handle even
non-printable keys with "keydown" event since other "keypress" event
listeners in our UI are broken by calling preventDefault(), you can keep
using "keypress" event listeners in the system event group or in chrome
document.

You can add an event listener in the system event group with using
nsIEventListenerService::addSystemEventListener():
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIEventListenerService#addSystemEventListener()

Or, specify group="system" to event handler in XBL like this:
https://searchfox.org/mozilla-central/rev/14d933246211b02f5be21d2e730a57cf087c6606/toolkit/content/widgets/browser.xml#1680

Or, you might be able to use EventTarget.addEventListener() with
{mozSystemGroup: true} as 3rd argument. However, I couldn't fix new
oranges with this approach. So, it works with some condition, but I
don't know about this.


So, I'll keep struggling with regressions of this behavior change.
However, probably, we won't get regression reports for minor UI, e.g.,
running only first time to use something. So, I'd be happy everyone to
check your own UI.

Thanks in advance.

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