Intent to ship: Start to dispatch "keydown" and "keyup" events even if composing (only in Nightly and early Beta)

[Masayuki Nakano]

I'd like to start to dispatch "keydown" and "keyup" events even if
composing, i.e., there is composition string of IME but only on Nightly
and early Beta for now.
https://bugzilla.mozilla.org/show_bug.cgi?id=1446401

This follows other browsers' behavior and conforms to UI Events spec:
https://w3c.github.io/uievents/#event-type-keydown
https://w3c.github.io/uievents/#event-type-keyup
https://w3c.github.io/uievents/#events-composition-key-events

Before this change, I changed EventUtils.synthesizeComposition() and
EventUtils.synthesizeCompositionChange() to dispatch keydown event and
keyup event if you don't specify |key: {}| or |key: null| explicitly.
https://bugzilla.mozilla.org/show_bug.cgi?id=1446253

So, if you write mochitests to test composition events, this new
behavior is tested automatically (e.g., whether the composition is
accidentally committed by a keydown or keyup event handler).


Some additional info:

Gecko's traditional behavior of keyboard/composition/input events are:

1-1: keydown
1-2: compositionstart
1-3: compositionupdate
1-4: input
1-5: compositionupdate
1-6: input
1-7: compositionupdate
1-8: input
1-9: compositionend
1-10: input
1-11: keyup

This becomes:

2-1: keydown
2-2: compositionstart
2-3: compositionupdate
2-4: input
2-5: keyup
2-6: keydown
2-7: compositionupdate
2-8: input
2-9: keyup
2-10: keydown
2-11: compositionupdate
2-12: input
2-13: compositionend
2-14: input
2-15: keyup

If you want to do nothing during composition with keydown/keyup
listeners, you can do it really easily:

foo.addEventListener("keydown", (e) => {
if (e.isComposing) {
return;
}
// Do anything what you want to do.
});

KeyboardEvent.isComposing is set to true if "keydown" and "keyup" events
are fired between "compositionstart" and "compositionend".

And be aware, if keydown and keyup events are already processed by IME,
their keyCode value is set to 229 (KeyboardEvent.DOM_VK_PROCESSKEY) and
their key value is set to "Process". I call those keyboard events as
"marked as processed by IME". So, you cannot retrieve actual key
information with KeyboardEvent.keyCode nor KeyboardEvent.key. However, I
cannot say which "keydown" and "keyup" events in above example are
marked as "processed by IME" because it depends on native IME's behavior
and OS itself. Typically keydown events (including the one immediately
before compositionstart) are marked as "processed by IME", but keyup
events are not marked as "processed by IME". So, except the "keydown"
event immediately before "compositionstart", using
KeyboardEvent.isComposing is really safer.

Finally, please do NOT use "keydown" events and "keyup" events for doing
something what should be done immediately after every character input.
In such purpose, "input" event is the right event because "keydown"
event and "keyup" event may not be fired even after the bug fix. For
example, if the IME is backend of voice input or handwriting system,
Gecko won't fire "keydown" nor "keyup" event unless OS or IME
synthesizes native key events for backward compatibility. And if native
IME completely consumes native key events before Gecko, Gecko won't fire
those events too.

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