1390124 - macOS: `compositionstart` and `compositionend` events both triggered _after_ composing accented latin character

Status: RESOLVED WONTFIX

(Core :: DOM: UI Events & Focus Handling, defect, P5)

Description

[Dan Burzo]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170628075643

Steps to reproduce:

On macOS:

1. Listen to the `compositionstart` and `compositionend` events on any element that accepts input (contenteditable, textarea, etc.) 
2. Press and hold the "a" key on your keyboard to invoke the Accent Menu in macOS
3. While holding the "a" key, press a numeric key (e.g. "1") to generate an accented letter


Actual results:

Both `compositionstart` and `compositionend` events are fired _after_ pressing the numeric key / finishing the composition.


Expected results:

`compositionstart` should fire when the Accent Menu is invoked (Step 2).

Note: neither Chrome nor Safari currently trigger CompositionEvents for the macOS Accent Menu.

Relevant issue for W3C Editing Task Force: https://github.com/w3c/editing/issues/132

Comment 1

[Dan Burzo]

On second thought, it may be a better idea not to trigger composition events at all for this, and instead fix this as part of supporting the Input Events Level 2 spec? https://w3c.github.io/input-events/

Pressing `a` would trigger beforeinput/input events of inputType=insertText, and composing it to `á` would trigger beforeinput/input events of inputType=insertReplacementText, as currently implemented by Safari.

(You can use this webpage to observe the UI Events triggered by various browsers in response to user input: https://danburzo.github.io/input-methods/ )

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Moving all open keyboard/IME handling bugs to DOM: UI Events & Focus Handling component.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

According to bug 1709152, this incompatibility causes not allowing to cancel input from it from beforeinput event listeners. So, we should fix this.

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Sorry for the spam. I misunderstood this bug report. And I couldn't reproduce this bug at least on Big Sur. Let's mark this as WFM if this is not reproducible on older macOS too.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

compositionstart should fire when the Accent Menu is invoked (Step 2).

Ah, this is impossible because Cocoa does not notify us anything of showing the popup.

And currently, we stop dispatching a set of composition events. And the new behavior is exactly same as Chrome. On Sierra, High Sierra and Mojave, you see events in this order at pressing a numeric key:

1. keydown for the numeric key
2. keyup for the numeric key (without keypress for the numeric key, this means that this key press didn't insert a character directly)
3. beforeinput whose data is the accented character (this is cancelable)
4. input whose data is the accented character

On Catalina and Big Sur, you see the event order as #1 -> #3 -> #4 -> #2. (I.e., beforeinput and input are fired before keyup).

Ideally, at least the keydown event's keyCode should be 229 and key should be Process since it's consumed by the native IME. However, only on Safari, the keycode is set as properly. This could be fixed by bug 1338460 in the future, but I'm not sure whether it's true.

Anyway, this is WONTFIX due to the IME's behavior in the native IME event level.