Bug 165004 – The event order of keydown/keyup events and composition events are wrong on macOS

• Status: NEW
• Component: UI Events

[Masayuki Nakano]

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.

[Alexey Proskuryakov]

IIRC this is intentional, to match IE. That consideration may no longer be important.

[Masayuki Nakano]

(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).

[Alexey Proskuryakov]

Windows; I think that IE 6 was the latest at the time.

[Diogo Franco]

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.

[Diogo Franco]

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`.

[Hussam]

This continues to be an issue and workarounds are needed to produce consistent behaviour:

https://github.com/ProseMirror/prosemirror-view/commit/0c54477d91e1eccec617e25cb7e1d402e1529825

[Dorothy Chen]

+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.

[Dorothy Chen]

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.

[Radar WebKit Bug Importer]

<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?

[Karl Dubost]

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