Bug 167880 – WebKit provides a keypress event with wrong which/keyCode/charCode directly after a composition started with ^,´,` completes

• Component: UI Events
• Status: NEW

[Carsten Driesner]

Entering text into a contenteditable=true HTML element by pressing one of the keys ^, ´, ` on the Mac (German keyboard) starts a composition session. If one presses a second key which won't create a single character with the first one (e.g. â), the following keypress event contains the data of the key that started the composition (not the data of the pressed key).

Example:
Use the web page www.danilatos.com/event-test/ExperimentTest.html which records the events that the browser provides if one enter text into a div with contenteditable=true.

1. Set the cursor into the "Editing" field
2. Press ´ which starts the composition
3. Press v which ends the composition
4. Look at the event recorded

You can see the following events (part of the whole event list):
...
keyup 86 (V)
input
DOMSubtreeModified
DOMCharacterDataModified
dom axctually changed
textInput
keypress 180 (´)
keydown 86 (V)
input
DOMSubtreeModified
DOMCharacterDataModified
dom actually changed
DOMSubtreeModified
DOMCharacterDataModified
dom actually changed
textInput
compositionend
...

The issue is related to the keypress event which reports that ´ was entered although V (correctly reported by keydown/keyup) would be correct. The properties which, keyCode, charCode contain the value of the compositionend data property. If one would use ^ to start the composition the following keypress event would contain 94 (^).

[Alexey Proskuryakov]

Thank you for the report!

When you describe the expected behavior, is that something that you observe in other browsers (which ones?), or something that a standard prescribes?

The behavior doesn't seem obviously wrong to me - the '´' character is inserted when V is pressed, and we can't fit two codes in one event.

[Carsten Driesner]

I think there is no single correct solution for this scenario. Chrome and Firefox use different events to report what happens, but the events are consistent.

E.g. Chrome 56.0.2924.87 on Mac reports the following events (this time order is top to bottom)

- keydown 229
- compositionstart
- dom actually changed
- DOMCharacterDataModified
- DMSubtreeModified
- input
- keyup 187
- keydown 229
- textInput
- dom actually changed
- DOMCharacterDataModified
- DOMSubtreeModified
- dom actually changed
- DOMCharacterDataModified
- input
- compositionend, data=´v
- keyup 86

Both entered keys are notified by the "compositionend" event.

For your second  
The '´' character is reported by the "compositionend" event (which is correct as '´' starts a composition) and the following 'v' key by "keydown/keypress/keyup" events. Therefore there should be theoretical no problem to fix this issue, the values of which, charCode, keyCode must be in that case 118 (corresponding to the second key v). I am sure that internally this is less easy and there is a bunch of problems regarding state and so on.

[Alexey Proskuryakov]

Thank you for following up! This does seem like something worth looking into.

To prioritize this, it would help to know if this affects live web sites, and/or if this makes it very hard to implement reasonable editing behavior.

[Radar WebKit Bug Importer]

<rdar://problem/30471317>

[Carsten Driesner]

One of our web-based products (OX Documents) is highly dependent on key/composition events and is hurt by this wrong keypress event.

This website is a presentation of a colleague of me who explains how our product works using key-events.
http://www.slideshare.net/Malte.Timmermann/ox-documents-explained

If you or others want to try the product use "Try now" on https://www.open-xchange.com.

I am involved in browser-based composition for about two years now. I know more applications that are bound to correct key events in a contenteditable=true environment. E.g. look at this long running Chromium issue, where several people from different companies complained about wrong key codes (I think their applications could also see a negative impact by this issue) 
https://bugs.chromium.org/p/chromium/issues/detail?id=118639

[Ahmad Saleem]

Created attachment 461230 [details]
Safari 15.6 matches with Chrome but differs from Firefox

I am not sure on web-spec but related Chrome Bug mentioned in Comment 05 is marked as "RESOLVED WONTFIX". Also test URL in URL field load incorrectly and correct one is - http://www.danilatos.com/event-test/ExperimentTest.html

Please refer to attached screenshot for behavior across all browsers. (If I tested incorrect, please test accordingly). Thanks!