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) STR: 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 Expected Result: event order should be: 1. keydown 2. compositionstart 3. compositionupdate 4. input 5. keyup Actual Result: 1. compositionstart 2. compositionupdate 3. input 4. keydown 5. keyup This is really different from the spec: https://w3c.github.io/uievents/#events-composition-key-events 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`.
This continues to be an issue and workarounds are needed to produce consistent behaviour: https://github.com/ProseMirror/prosemirror-view/commit/0c54477d91e1eccec617e25cb7e1d402e1529825
+1, this is causing problems when trying to use keyboard shortcuts that use diacritic keys which trigger composition events (e.g. ^ on an AZERTY keyboard). > 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. This workaround doesn't seem ideal anymore either, since event.keyCode (and event.which) are marked as deprecated.
Sorry to jump back in here so soon - I should add some more color to my previous comment about the product impact. This is currently broken on production figma.com. We will try to find a palatable workaround, but even then we'd like to be able to remove that workaround once this bug is fixed.
<rdar://problem/92796965>
This question was raised in 2016, and I am still troubled by it in 2023. Is it really difficult to move keyDown Event before compositionEnd Event?
Created attachment 470455 [details] rendering in safari, firefox, chrome tested in Safari Technology Preview 190 19619.1.5.5.2 Firefox Nightly 125.0a1 12524.3.12 Google Chrome Canary 125.0.6370.0 6370.0