Bug 165004

Summary: The event order of keydown/keyup events and composition events are wrong on macOS
Product: WebKit Reporter: Masayuki Nakano <masayuki>
Component: UI EventsAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: 307100890, 709922234, ap, cdumez, dchen, diogomfranco, h.ghazzi, karlcow, megan_gardner, me, rniwa, webkit-bug-importer, wenson_hsieh
Priority: P2 Keywords: BrowserCompat, InRadar
Version: WebKit Nightly Build   
Hardware: Mac   
OS: macOS 10.12   
URL: https://dvcs.w3.org/hg/d4e/raw-file/tip/key-event-test.html
Attachments:
Description Flags
rendering in safari, firefox, chrome none

Description Masayuki Nakano 2016-11-21 00:18:41 PST
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.
Comment 1 Alexey Proskuryakov 2016-11-21 10:49:28 PST
IIRC this is intentional, to match IE. That consideration may no longer be important.
Comment 2 Masayuki Nakano 2016-11-21 22:55:28 PST
(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).
Comment 3 Alexey Proskuryakov 2016-11-23 00:56:02 PST
Windows; I think that IE 6 was the latest at the time.
Comment 4 Diogo Franco 2018-04-22 22:27:55 PDT
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.
Comment 5 Diogo Franco 2018-04-22 22:30:19 PDT
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`.
Comment 6 Hussam 2022-01-18 10:20:32 PST
This continues to be an issue and workarounds are needed to produce consistent behaviour:

https://github.com/ProseMirror/prosemirror-view/commit/0c54477d91e1eccec617e25cb7e1d402e1529825
Comment 7 Dorothy Chen 2022-05-02 08:13:05 PDT
+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.
Comment 8 Dorothy Chen 2022-05-04 07:54:30 PDT
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.
Comment 9 Radar WebKit Bug Importer 2022-05-05 08:36:14 PDT
<rdar://problem/92796965>
Comment 10 307100890 2023-10-15 20:14:05 PDT
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?
Comment 11 Karl Dubost 2024-03-21 01:36:56 PDT
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