Re: [w3c/uievents] Event order between "compositionend" and "input" (#202)

Sorry for the delays responding on that issue.  I've been finishing other things up and am just now starting to be able to spend more time on UIEvents.

To summarize my understanding:
* Some web apps want to be able to ignore the intermediate `input` events generated during composition, but they want the final `input` event (effectively, they want to consider the composition as a single input action).
* Currently this requires that the web dev listen to `compositionend` to know that the previous `input` event was the final one.
* Proposal is to make this easier for devs by setting `isComposing` to false for this final `input` event (just for the last one before `compositionend`).
* Possible concern: for web apps that want to distinguish between a final `Enter` that ends composition and one that adds a newline.

Regarding that last concern, I just tested this on Chrome Win and Mac with Korean and Japanese IMEs and noticed the following events after pressing `Enter` to accept the composition:
* Japanese:
   * Chrome Win/Mac sends `keydown` / `beforeinput` / `c-update` / `input` / `c-end` / `keyup` to close the composition
      * The `inputType` for the `input` event is `insertCompositionText`
   * Firefox Windows sends `c-end` / `input` / `keyup` to close the composition. (`inputType` is not set)
   * Edge Windows sends only `c-end` to close the composition. (`inputType` is not set)
* Korean:
   * Chrome Win/Mac sends `c-update` / `input` / `c-end` to close the composition and follows it with `keydown` / `keypress` / `beforeinput` / `input` / `keyup` for the `Enter` key to add a newline
      * The first `inputType` is `insertCompositionText`
   * The second `inputType` is `insertParagraph`
   * Firefox Windows sends `c-end` / `input` followed by `keydown` / `keypress` / `input` / `keyup`. (`inputType` is not set)
   * Edge Windows sends `c-end` followed up `keydown` / `keypress` / `input` / `keyup`. (`inputType` is not set)
* Note: tested using https://w3c.github.io/uievents/tools/key-event-viewer-ce.html

So (from this limited testing), I don't think there's a problem with distinguishing the final `Enter` of a composition from the newline (esp. when `inputType` is set).

As for the proposal, other than it makes the spec description more complex, I don't see serious problems with it. But I also don't have a sense of how serious the original problem is.

The tradeoff we're making is between:
* Making the spec's description more complex: "`isComposing` is set when composing, EXCEPT when..." (ugh)
* Making things slightly harder for devs who need to ignore `input` events during composition (since they have to add an event handler for `compositionend`).

But it doesn't seem (to me) like it's very common to need to distinguish between input events that are inside or outside composition. The vast majority of devs won't care. The one case I can think of where someone might want to do this is for devs writing rich text editors, but I don't consider it a problem if they have to write a bit more code to get things done - they're probably handling `compositionend` already.

Unless there's a real dev need to fix this, I'd rather keep the definition for `isComposing` simple.

> Note that while every composition only has one compositionstart event, it may have several compositionend events.

I was wondering where this came from (it's not in the UIEvents spec) and finally found it as a non-normative note in Input Events spec (in Step 5) (https://www.w3.org/TR/input-events-2/).

AIUI, that is wrong. `compositionstart` and `compositionend` are supposed to be matching pairs. I'm not aware of any situation where there should be multiple `compositionend` events in a single composition session.

The UIEvents spec says (https://www.w3.org/TR/uievents/#events-compositionevents):
> Conceptually, a composition session consists of one compositionstart event, one or more compositionupdate events, and one compositionend event, with the value of the data attribute persisting between each stage of this event chain during each session.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/uievents/issues/202#issuecomment-411238163