event order proposal when inserting replacement text such as text prediction, spell checker, etc.

[siliu1]

writingsuggestions and spellcheck are attributes that control UA-provided writing assistance such as text prediction and spell checker. When user accepts a suggestion/correction, wrong order of events fired might confuse online editors which may produce unexpected results.

Here is a proposal that the order of events when inserting suggestions text:

Order:	Eventtype	inputType
1	beforeinput	insertReplacementText
2	input	insertReplacementText

The beforeinput event is cancelable. If it's cancelled, suggestion insertion should be aborted, and no input event is fired.

Composition events are not necessary therefore shouldn't be fired when inserting suggestions/corrections.

The proposal also applies to other suggestion insertions such as auto-correct, etc.

The issue is also posted in WHATWG: whatwg/html#10337

[johanneswilm]

@siliu1 This makes sense. But is this not what the spec requires already (also for other input types)? Is there an implementation that does not follow this order?

[siliu1]

@johanneswilm I think the focus of this proposal are:

1. Make sure that the inputType of beforeinput and input events are insertReplacementText.
2. Composition events should not be fired.

[johanneswilm]

@siliu1 Point 1 sounds like a potential bug in specific browsers to me (which ones?). This is already specified in the spec.
On point 2 - I don't recall us having specified anywhere that certain input types should NOT have composition events. But I think that's because it should be obvious when no composition takes place and would probably be considered a bug already. Is this happening in some browser engines right now?

[css-meeting-bot]

The Web Editing Working Group just discussed event order proposal when inserting replacement text such as text prediction, spell checker, etc..

The full IRC log of that discussion

<sanketj_> Topic: event order proposal when inserting replacement text such as text prediction, spell checker, etc.
<sanketj_> github: https://github.com//issues/152
<dandclark> sanketj_: This came up when we were implementing writingSuggestions
<dandclark> ...: Edge & Safari, the set of events we fired caused compat issues
<dandclark> ...: Came out of discussion with Marcos where we should be more clear about where events are fired. That's what Siye is trying to do.
<dandclark> ...: Beforeinput, input should be fired
<dandclark> ...: Composition events should not be fired
<dandclark> ...: Problem is not unique to writingSuggestions. There's autocomplete...
<dandclark> ...: Can we have the same pattern for all of them?
<dandclark> johanneswilm: I don't understand what the issue is. The order is specified in UI events
<dandclark> ...: Doesn't specify that there's no composition, but specifies this is not part of a composition
<dandclark> ...: I take that as implying there will be no comp events
<dandclark> sanketj_: May be worth clearing up when a suggestion or correction is accepted, these rules are followed
<dandclark> ...: Not clear if that should be here or in HTML spec
<dandclark> johanneswilm: The order of these events is in UI events spec
<dandclark> ...: I thought that's pretty clear
<dandclark> sanketj_: Does it call out they should be fired when autocomplete, autofill is accepted?
<dandclark> johanneswilm: Probably written in different way.
<dandclark> ...: is part of the issue that Apple didn't implement which events should come out of this?
<dandclark> sanketj_: Easy for bugs to be introduced if this is not specified somewhere
<dandclark> smaug: I think it's clear in spec. *reads spec text*
<dandclark> sanketj_: Does it say these need to be fired when something is accepted?
<dandclark> snianu: When you type in android by default, it goes through composition. When you type in site, if browser supports spellcheck, then <missed>. If you type on virtual keyboard it also shows spelling suggestions. On android every keystroke comes through composition
<dandclark> johanneswilm: But that' smore of an androib bug
<dandclark> s/androib/android
<dandclark> ...: If you have keyboard and it's not communicating that it's spellchecking change, browser has no way of knowing.
<dandclark> sanketj_:For that case that's where inputType comes in, you should get insertReplacementText
<dandclark> sanketj_: The main thing is just we should make it clear that when one of these things are accepted, we should fire these events.
<dandclark> ...: Spec just says insert or replace text. Calls out type.
<dandclark> johanneswilm: Event order is in UI events, no?
<dandclark> sanketj_: Yes
<dandclark> sanketj_: Maybe somewhere in one of these specs, we should make it expicit that when suggestions are expected, these events get fired and composition events do not get fired
<dandclark> johanneswilm: Not against it, slightly afraid it's just due to lack of communication about the change
<dandclark> ...: But we can adjust it if it's not totally clear
<dandclark> ...: Should go into UI events
<dandclark> ...: I would be for having event order in same spec, but given we moved it out for everything else, keyboard typing etc, should be in UI events
<dandclark> ...: Maybe move the issue there, have them add it to spec where it seems reasonable
<dandclark> sanketj_: OK
<dandclark> johanneswilm: So all the event orders are in the same spec
<dandclark> sanketj_: Right. The other benefit is implementation-wise, once this is specced it can be forcing function to create common implementation. Rather than every time you invent one of these things you have to reconsider all this.
<dandclark> johanneswilm: Who will file it with UI events?
<dandclark> sanketj_: I'll follow up with Siye and he will take care of it