According to this spec, when the state of the composition context is updated, a compositionupdate event is fired, followed by beforeinput and input. Furthermore, none of those events is cancelable. However, according to the UI Events spec, beforeinput fires first and can be canceled, and if not canceled, the compositionupdate and input events are fired. If beforeinput is canceled, then, the composition state would presumably go back to the previous state.
Taking a look at what browsers actually do, it seems like Chromium follows UI Events's order of events, but canceling beforeinput in a composition context does nothing. Firefox and WebKit (tested on Epiphany / GNOME Web) follow this spec, except that WebKit also seems to implement #134.
I wanted to confirm that this has been considered and that the UI Events spec is known to be wrong on this point before trying to update it.
According to this spec, when the state of the composition context is updated, a
compositionupdateevent is fired, followed bybeforeinputandinput. Furthermore, none of those events is cancelable. However, according to the UI Events spec,beforeinputfires first and can be canceled, and if not canceled, thecompositionupdateandinputevents are fired. Ifbeforeinputis canceled, then, the composition state would presumably go back to the previous state.Taking a look at what browsers actually do, it seems like Chromium follows UI Events's order of events, but canceling
beforeinputin a composition context does nothing. Firefox and WebKit (tested on Epiphany / GNOME Web) follow this spec, except that WebKit also seems to implement #134.I wanted to confirm that this has been considered and that the UI Events spec is known to be wrong on this point before trying to update it.