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 <masayuki@d-toybox.com> Software Engineer, Mozilla

We're now testing this fix in Nightly with a site blocklist (see bug[1]) that excludes google.com sites. Our goal is to determine web compatibility outside of Google apps. Please file bugs that block bug 1440189 <https://bugzilla.mozilla.org/show_bug.cgi?id=1440189> if you see breakage in Nightly. Thanks! --Jet [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1440189 <https://bugzilla.mozilla.org/show_bug.cgi?id=1440189> On Mon, Mar 19, 2018 at 2:04 AM, Masayuki Nakano <masayuki@d-toybox.com> wrote: > 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 <masayuki@d-toybox.com> > Software Engineer, Mozilla > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform >