We should fire 'beforeinput' after 'compositionupdate'

[chong-z]

Copied from https://github.com/w3c/uievents/issues/66#issuecomment-268070654 as it's more InputEvent related.

Proposal We should fire 'beforeinput' after 'compositionupdate', e.g.

*'compositionupdate'
*'beforeinput'`
-update DOM now-
'input'`

Reasoning

1. Previously we want to fire 'beforeinput' before 'compositionupdate' because IE/Edge has a different behavior, but IIRC @gked mentioned that it was a bug and will be fixed. (@gked can you help confirm?)
2. If IE/Edge could update the behavior then it makes more sense to fire 'beforeinput' immediately before DOM update as required by spec:

   A user agent MUST dispatch this event when the DOM is about to be updated.

@whsieh Safari Technology Preview is firing 'beforeinput' after 'compositionupdate', just want to confirm: Is Safari going to ship with this order?

[whsieh]

+@rniwa

I'm just catching up to the discussion at https://github.com/w3c/uievents/issues/66, but if I understand correctly, the original reason for wanting to fire 'beforeinput' before 'compositionupdate' is because IE/Edge has this behavior, however @gked mentioned that it was a bug in Edge and will be fixed, since firing compositionupdate and then beforeinput better matches wording in the spec because beforeinput should be dispatched immediately before DOM changes.

If we confirm that this is the case, we will go with this order; otherwise, if this issue is serious enough, we can pursue a fix ASAP.

[johanneswilm]

@choniong What I can tell, on Android/Chrome, the beforeinput is fired before the compositionupdate. Is this on purpose? I had understood the discussion here that you proposed to do it the other way round and there not being any opposition to this order.

[johanneswilm]

@choniong I still agree with your proposal, but noticing that just this little part of the event order is also defined in the ui-events spec, I changed to that order until we figure out where the event order shoudl live.

@garykac What do you think? For level 2, we need the event order of the entire composition process as it relates to input/beforeinput. Is this something you would want to put into ui-events, or would you prefer for this to live here?

[masayuki-nakano]

I like better to dispatch compositionupdate before beforeinput because Gecko handles composition string modification after dispatching compositionupdate (technically, we dispatch text event which is not in any standards and we'd like to stop dispatching it, though. The text event follows compositionupdate and Gecko's editor listens to only text event and modifies the DOM tree). Of course, we can change the behavior although it requires a lot of changes. However, inserting compositionupdate between beforeinput and input sounds odd because I've heard that beforeinput and input should be fired as pairs as far as possible immediately before and after editor modifies the DOM tree.

And there is another reason. Currently, keypress event is fired before beforeinput. So, for consistency with it, I'd like to dispatch compositionupdate before beforeinput since I don't want to create different path in implementation of event dispatcher.

[masayuki-nakano]

Well, Chrome dispatches beforeinput -> compositionupdate -> input. However, Safari dispatches compositionupdate -> beforeinput -> input. So, anyway we'll hit a backward compatibility issue...

[masayuki-nakano]

(FYI: Perhaps, due to mainly this issue, Firefox will start to support Input Events Level 1. Chrome also supports only Level 1 so that we don't need to take the risk of unstable part of Level 2.)

[johanneswilm]

What is the "unstable" part of level 2? Level 1 is not something terrible useful to anyone. It is just an arbitrarily limited version of level 2 that we needed to create because it turned out Chrome on Android had some inherent issues that made it difficult for them to ship level 2.

The result is unfortunately, as you can see, that noone is really using the event so far because Chrome still isn't implementing level 2. For the past two years there has been no counter proposal to level 2 either.

[johanneswilm]

I don't think this issue should have anything to say for whether one is implementing level 1 or level 2. Either way, it will be either Chrome or Safari that is in non-compliance with level 1. So the "unstable" part lies in the beforeinput event itself, which is level 1.

[masayuki-nakano]

What is the "unstable" part of level 2?

Around composition events, please check what I filed in this weekend. I wait finial decision for each of them. And if final decisions will make us redesign our editor again, we need to put of to implement beforeinput until we rewrite our implementation.

The result is unfortunately, as you can see, that noone is really using the event so far because Chrome still isn't implementing level 2. For the past two years there has been no counter proposal to level 2 either.

I have a question. The most difference between Level 1 and Level 2 is around IME composition. Is that so important for web apps? I mean, even with Level 2, I think that web apps cannot handle IME composition so deeply (e.g., web apps cannot retrieve each clause range in composition string). What do web apps want to do with Level 2 during composition?

[masayuki-nakano]

I don't think this issue should have anything to say for whether one is implementing level 1 or level 2.

Only Level 2 defines the relation between beforeinput, input, compositionupdate and compositionend. And basically, we'd like to follow Chrome's behavior if it makes more sense than other browsers'. However, in this case, I feel that Safari's behavior make more sense, but Chrome and draft of Input Events Level 2 are different from that...

[johanneswilm]

@masayuki-nakano No, that's level 1 just as much as level 2. There is no extra instability in level 2. See https://github.com/w3c/input-events/issues/86#issuecomment-437656682

[johanneswilm]

@masayuki-nakano It is in ui-events, which applies to both level 1 and 2: https://www.w3.org/TR/uievents/#events-composition-input-events

[masayuki-nakano]

@masayuki-nakano It is in ui-events, which applies to both level 1 and 2: https://www.w3.org/TR/uievents/#events-composition-input-events

Wow, really sad...

[masayuki-nakano]

@johanneswilm anyway, what's the state of this issue? At least, I'd like to know that Chrome and Safari developers would love to which event order.

[johanneswilm]

Because event order is in ui-events, it is somewhat out of my control. @garykac knows more about the state of ui-events. @NavidZ and @whsieh can tell you about the Chrome and Safari implementations.

[masayuki-nakano]

@garykac, @NavidZ and @whsieh: I'm waiting you thoughts about this event order issue. There are related issue of UI Events (keypress vs. beforeinput): https://github.com/w3c/uievents/issues/220

I think that keypress should be fired before beforeinput event for compatibility with existing browsers. Then, dispatching compositionupdate before beforeinput is better for the consistency between keypress and compositionupdate.

[rniwa]

FWIW, WebKit/Safari seems to fire beforeinput after compositonupdate already, and that matches our implementation as far as I can tell.

[masayuki-nakano]

Sounds really nice! Firefox will follow Safari's behavior because it's better for consistency with keypress event case and we don't need to redesign our internal code. (Although, this is not final decision for shipping it.)

[garykac]

I've started working on a more formal algorithmic description of uievent ordering. My current draft is in

https://docs.google.com/document/d/1LJQvjEmWZGzVgZnofpvdkxMj1hEnLniD72XD4DLJWx4/edit?usp=sharing

where I currently use the proposed compositionupdate -> beforeinput ordering.

More generally though, a larger goal is to find the appropriate separation between UIEvents and Input Events specs so that (at a high level) UIEvents defines the event ordering while the details of the beforeinput and input events are in Input Events. This will require adding "hooks" from UIEvents into Inpuit Events, but (once it's done) it should make it easier for Input Events to adopt a more algorithmic style as well.