Order of keydown relative to compositionstart

[dandclark]

In a blink-dev thread discussing shipping EditContext, there was an issue raised about the keydown event preceding compositionstart. This order could be problematic if a key event that was intended for the IME is instead processed first by the application in the keydown event.

If this is a problem, the event order could be changed for EditContext. However it seems less confusing in the long run if the event order is consistent between contenteditable and EditContext editing hosts; changing only one could just confuse the situation further.

The spec has keydown coming first: https://w3c.github.io/uievents/#events-composition-key-events. Chromium and Firefox follow this order, while Safari fires compositionstart first. When keydown comes before compositionstart, Firefox sets Event.key to "Process", which I don't see in the spec.

Is there evidence that this is a problem that editors have to work around today? If so, we should consider making a spec change in https://w3c.github.io/uievents/#events-composition-key-events and coordinating between browsers to change this in lockstep to minimize risk of interoperability issues.

If there is not evidence that this is causing pain for developers then the change might not be worth the compatibility risk.

A related discussion was #202 but that does not mention keydown specifically.

[fwadnjar]

#360

[dandclark]

Labeling this to discuss during the next Web Editing WG call (or if there are still uievents calls happening and anyone reading this has the details, please let me know).