I tested this on:
* Safari Technology Preview Release 18 (Safari 10.1, WebKit 12603.1.12)
* Safari Version 10.0.1 (12602.2.14.0.7)
1. Load https://dvcs.w3.org/hg/d4e/raw-file/tip/key-event-test.html
2. Change active keyboard layout to "Hiragana" of Japanese IME
3. Type "a" key of ANSI keyboard layout mapping
event order should be:
This is really different from the spec:
Google Chrome works as expected. Firefox doesn't fire keyup event since it's traditional behavior <https://bugzil.la/354358> but the order is correct.
IIRC this is intentional, to match IE. That consideration may no longer be important.
(In reply to comment #1)
> IIRC this is intentional, to match IE.
Do you mean, it's IE for Mac? Both IE 11 and Edge on Win10 work same as Chromium (i.e., conforming to UI Events).
Windows; I think that IE 6 was the latest at the time.
This is also causing problems when trying to rely on the `isComposing` property of `KeyboardEvent` and `InputEvent`. The Enter key that accepts the IME input will be sent with `isComposing === false`, because Safari is sending events out of order, and `keydown`/`input` are being sent after `compositionend`.
This makes comparing `keyCode === 229` the only reliable way to detect whether IME is being used or not, even though modern APIs are available, because they are giving the wrong results.
See https://www.w3.org/TR/uievents/#events-composition-key-events and https://www.w3.org/TR/uievents/#events-composition-input-events for the spec. It is very specific that the `keydown` event that exits composition _must_ be sent with `isComposing === true`, but Safari sends them with `isComposing === false`.