Make "Input Events Level 1" declare "beforeinput cancelable" of "insertCompositionText" as "Undefined"

[masayuki-nakano]

Level 1 spec declares "insertCompositionText" is not cancelable.
https://rawgit.com/w3c/input-events/v1/index.html#interface-InputEvent-Attributes

However, Level 1 does not have cancelable "insertFromComposition". And Chrome supports Level 1, and Firefox will follow it soon. This means that web apps cannot cancel inserting text only from composition so that I'd like to suggest that only when IME commits composition, Level 1 browsers should make beforeinput whose inputType is "insertCompositionText" cancelable. For doing this, it should be defined as "Undefined".

(Or, adding "insertFromComposition" into Level 1 might be more reasonable.)

[johanneswilm]

Hey @masayuki-nakano ,
yes, the way it should be written, all browsers compliant with level 2 should also automatically always be compliant with level 1. Therefore, it should always be possible to have a "insertFromComposition" inputType and still be compliant with level 1. I think that the way we wrote it, we thought the note "Other specifications may expand on this definition." would cover that case where for example Webkit could take an inputType from level 2 and still be compliant.

If the advice we received on that is incorrect and we need to add it to the level 1 spec as well, I think we need to add "insertFromComposition" to level 1 as well.

@frivoal @marcoscaceres - any comment?

[johanneswilm]

This means that web apps cannot cancel inserting text only from composition

@masayuki-nakano The changes the Chrome team did to level 1 was to make it possible to make all the text insertion events not be cancelable (only formatting changes are cancelable). The idea behind this was, AFAIAA, that given that it was not possible to have composition be cancelable on Chrome on Android, one wanted to make all the text insertion not be cancelable, so that JS editor projects would be forced to write code to undo the last change and then redo it, rather than write editors that only work on desktop computers in Latin script languages.

What you seem to describe is something similar to level 2 - which is what we actually wanted but couldn't do due to this bug on Android.

Given that they made all text insertion on-cancelable in Chrome, also from keyboards, I would be surprised if they would now want to make it cancelable anyway. And if you implement it differently in Firefox rather than use either level 1 or 2, then we are back at square one where JS editor devs need to write browser specific code.

[johanneswilm]

Is there a PR by someone from Mozila on adding this to Input Events, Level 1 somewhere and could we get someone to present the proposal to add this to the spec before it is being moved to CR either at TPAC or one of the Editing Taskforce monthly meetings some time soon?

@annevk @saschanaz @masayuki-nakano @smaug----

[masayuki-nakano]

This means that web apps cannot cancel inserting text only from composition

@masayuki-nakano The changes the Chrome team did to level 1 was to make it possible to make all the text insertion events not be cancelable (only formatting changes are cancelable).

No, on Chrome, I can cancel beforeinput event for insertText, insertReplacementText, deleteContentBackword, deleteContentForward, etc. And it actually prevents built-in editor of Blink to do anything.

The idea behind this was, AFAIAA, that given that it was not possible to have composition be cancelable on Chrome on Android, one wanted to make all the text insertion not be cancelable, so that JS editor projects would be forced to write code to undo the last change and then redo it, rather than write editors that only work on desktop computers in Latin script languages.

Well, I didn't think about Android's IME limitation. However, I'm suggesting about the case only when the composition ends. I.e., in most cases, it won't hit any IME limitation of any platforms, I guess.

Given that they made all text insertion on-cancelable in Chrome, also from keyboards, I would be surprised if they would now want to make it cancelable anyway. And if you implement it differently in Firefox rather than use either level 1 or 2, then we are back at square one where JS editor devs need to write browser specific code.

Yes, therefore, I'd like to here second opinions of other vendors.

[johanneswilm]

@masayuki-nakano The changes the Chrome team did to level 1 was to make it possible to make all the text insertion events not be cancelable (only formatting changes are cancelable).

No, on Chrome, I can cancel beforeinput event for insertText, insertReplacementText, deleteContentBackword, deleteContentForward, etc. And it actually prevents built-in editor of Blink to do anything.

Aha. In that case it seems like Chromium has moved it's implementation closer to level 2. In all of the cases where the Blink implementation matches that of Webkit/level 2, I think we should adjust level 1 to be the same as level 2. The only point with level 1 was that Blink could not implement all of level 2 for technical/internal reasons and so if those reasons are gone, we should make the delta between the two as small as possible by adjusting level 1.

@gked Any idea on who working on this in the Blink codebase who could verify that Chromium has now implemented level 2 for the various input types and that they are cancelable on all platforms?

The idea behind this was, AFAIAA, that given that it was not possible to have composition be cancelable on Chrome on Android, one wanted to make all the text insertion not be cancelable, so that JS editor projects would be forced to write code to undo the last change and then redo it, rather than write editors that only work on desktop computers in Latin script languages.

Well, I didn't think about Android's IME limitation. However, I'm suggesting about the case only when the composition ends. I.e., in most cases, it won't hit any IME limitation of any platforms, I guess.

If I remember correctly, the issue was with partially committed IME strings - what happens if there is a long string in the IME and only part of that is committed to the DOM.

If you can make it work like Webkit/level 2 by using "insertFromComposition", then it would mean that JS editor authors would only have to consider two cases instead of three different cases.

[masayuki-nakano]

React developer said that they also want to handle committing composition with beforeinput events.

I believe that this is important issue and Blink should change the behavior for making web apps possible to handle composition easier. (Then, Firefox will ship beforeinput with the new behavior.)

@gked @garykac ping for this.

[masayuki-nakano]

Ah, if insertFromComposition will be added to Level 1, it might be better to add deleteCompositionText too. Then, WebKit's behavior and the others become almost compatible.

[johanneswilm]

Ping @alexkeng and @snianu. See also w3c/editing#275 . Could we get an answer to whether we can make level 1 get most of what is specified in level 2 thus far?

[snianu]

Any idea on who working on this in the Blink codebase who could verify that Chromium has now implemented level 2 for the various input types and that they are cancelable on all platforms?

@bokand @mustaqahmed @NavidZ Adding few folks from Chrome team who would know more about these changes.

[snianu]

Just to follow-up on this issue. @gked found the change in Chromium that made the beforeInput events cancellable. Here is the thread about this issue: w3c/editing#275.

@masayuki-nakano @johanneswilm Re deleteCompositionText: According to the spec we should fire deleteCompositionText whenever IME is replacing a range during an active composition, but on Safari I see this event getting fired only when a composition is committed and not when the composition state is in-progress and the text is being replaced when a candidate is selected from the candidate window(FF, Chrome & Edge do not fire this event at all). The spec language is pretty clear and we should always fire deleteCompositionText when a text is replacing (that is being composed or committed) an existing range in the DOM. Thoughts?

[johanneswilm]

@snianu In the table it says about deleteCompositionText that it occurs: "delete the current composition string before committing a finalized string to the DOM". The way you describe Safari's behavior sounds to me like it complies with this correctly. The step 5 in the event order you link to also sounds correct - this is only to happen when the IME is about to finish and the change is to be committed permanently to the DOM or if, due to buffer issues, a part of the composition text is committed permanently to the DOM while another part continues in the composition.

Maybe some of the wording should be clarified? But I think Safari is doing the right thing if it does what you describe. The whole point of first removing it (with deleteCompositionText) and then re-adding it (with insertFromComposition) is that it allows JS editors to isolate the DOM changes made by the IME.

[johanneswilm]

FF, Chrome & Edge do not fire this event at all

That is because FF, Chrome & Edge have only implemented level 1 of the spec (and apparently recently Chrome/Edge recently also parts of level 2, except those parts that relate to IME - the deleteCompositionText and insertFromComposition events).

[masayuki-nakano]

Oh, Firefox implemented Leve2 only for the inputType values behind a pref, but I misunderstood the meaning of deleteCompositionText. I thought that it's set when composition is committed with empty string.
https://searchfox.org/mozilla-central/rev/03224522336f60a1a61a87e1fcd4feb0a0315a9b/editor/libeditor/TextEditor.cpp#826-833
https://searchfox.org/mozilla-central/rev/03224522336f60a1a61a87e1fcd4feb0a0315a9b/editor/libeditor/EditAction.h#507-511

Of course, I could change the behavior as Safari does. However, it causes input event fired twice for deleteCompositionText and insertFromComposition. This may break some web apps because some web apps may be sensitive to input events around compositionend. So, I have a concern about changing input event behavior because some web apps may be sensitive to input events around compositionend.

[masayuki-nakano]

And I feel odd for current definition of deleteCompositionText. That says

delete the current composition string before commiting a finalized string to the DOM

This means that only while dispatching beforeinput and input event, the composition string should be removed from the DOM temporarily. Safari, actually does so, but from point of view of Gecko's implementation, it's redundant DOM change since in most cases, same string will be inserted to the DOM again. Why is this required? Why it's not enough canceling insertFromComposition just to remove the commit string?

[masayuki-nakano]

Ah, Safari fires input event for deleteCompositionText, but the spec draft does not define it should be fired. (Perhaps, only when it's not followed by insertFromComposition, it should be fired though.)