`insertCompositionText` (and `isComposing`) cannot tell the input event accompanied by compositionEnd from the other WIP IME input events

[tats-u]

1. Enable Japanese IME
2. Type s
3. Type i
4. Press Space to convert and get e.g. "詩"
5. Change the candidate to another one, e.g. "市"
6. Press Enter to Commit

You get the completely same kind of input events in 2–6 where:

• isComposing is true
• inputType is insertCompositionText

A different type should be assigned to 6.
How can we notice the end of composition without combining with compositionEnd?

• isComposing in onInput is true even when it is the finish of the IME composition / No onInput whose isComposing is false is triggered when you complete IME composition uievents#394
• Event order between "compositionend" and "input" uievents#202

Another approach (adding additional property to InputEvent):

• Add new property to InputEvent to determine whether the text being input by IME has just been confirmed without help of compositionend uievents#403

[smaug----]

@masayuki-nakano

[tats-u]

Another approach is to append a new additional property to inputEvent.

[johanneswilm]

@tats-u Explain a bit more - what would that property hold? Preferably with an example of what would happen during a composition sequence that has both partial commits and a full final commit.

[tats-u]

@johanneswilm Something like isConfirmed.
false only in 2–5. true otherwide (including when you input or delete some text without help of IME).

[tats-u]

Chrome's example (s i → し → 市 → 死 → Confirm)

It should be false in 5, 11 ,17 , and 23. However it should be true in 29.

[tats-u]

I created a new issue related to it to uievents.
You might as well choose one and close the other.

[johanneswilm]

@tats-u Let's keep the discussion here. The other spec is maintained by other people and is not discussed at the Editing WG meetings.

It should be false in 5, 11 ,17 , and 23. However it should be true in 29.

What should it be in 28?

[tats-u]

onBeforeInput? I have not used it yet and in the first place I do not know when we should use this event instead of onInput. In my opinion true is preferred but I am not so sure.

[johanneswilm]

Oh, ok. @tats-u try to read the spec so that we are all on the same page and so that we are sure that the thing you are asking for is not already covered in some other way so that we don't spend a lot of time reading through and trying to understand your proposal if it is already covered or doesn't fit the overall model.

Very briefly: beforeInput comes before the DOM change and input comes after the DOM change. A lot of beforeInput events can be cancelled, which means that the browser will then not do the DOM change and there will not be an input event. Some beforeInput events cannot be cancelled (related to composition), which means the DOM change will take place under all circumstances. In that case, the beforeInput event can be used in order to note what the DOM looked like before the DOM change took place.

The new EditContext API can be used instead of contenteditable in order to get around the issue of these non-cancellable beforeInput.

[tats-u]

https://w3c.github.io/uievents/#events-compositionevents only says "A user agent MUST dispatch this event when the DOM is about to be updated."

In that case, the beforeInput event can be used in order to note what the DOM looked like before the DOM change took place.

It does not seem to be concerned with my suggested isConfirmed; it can continue to stick to the existing isComposing. isConfirmed can be simply defined as "!isComposing || [the key input that triggered the event will also trigger compositionend]" if we define isConfirmed there as true.

The new EditContext API can be used instead of contenteditable in order to get around the issue of these non-cancellable beforeInput.

It is "too much" for casual usage (e.g. single simple text field).

[johanneswilm]

In that case, the beforeInput event can be used in order to note what the DOM looked like before the DOM change took place.

It does not seem to be concerned with my suggested isConfirmed; it can continue to stick to the existing isComposing.

So are you saying that in your example, the beforeInput event in 28 should have the isConfirmed set to false? Or should it be true?

isConfirmed can be simply defined as "!isComposing || [the key input that triggered the event will also trigger compositionend]" if we define isConfirmed there as true.

Are you saying that isConfirmed should be equal to false in all cases unless it is the (beforeInput/)input event that is the last during a composition that commits the final text to the DOM?

What is the reason why we cannot just make isComposing false for that last event?

What do we do when the IME commits only a partial string to the DOM permanently while the composition continues in the remaining part of the string?

The new EditContext API can be used instead of contenteditable in order to get around the issue of these non-cancellable beforeInput.

It is "too much" for casual usage (e.g. single simple text field).

Right, but once implemented by other browsers, someone could create a JavaScript library that uses this, which then in turn can be used by "casual" JavaScript developers.

[tats-u]

So are you saying that in your example, the beforeInput event in 28 should have the isConfirmed set to false? Or should it be true?

Probably true but I am not sure.

What is the reason why we cannot just make isComposing false for that last event?

Is it not a breaking change that may break existing applications?

What do we do when the IME commits only a partial string to the DOM permanently while the composition continues in the remaining part of the string?

↑Partially committed "日本語" first and then commited "大好き" (Chrome / onKeyDown is filtered out)

I do not know about onBeforeInput in 78.

Also, I have just found that input/beforeinput is not fired in Chromium (fired in Firefox) if you leave focus when you trying to input some text using IME.

Right, but once implemented by other browsers, someone could create a JavaScript library that uses this, which then in turn can be used by "casual" JavaScript developers.

A lack of such libraries should not prevent developers from adopting newly-created UI frameworks (UI frameworks = e.g. React).

[masayuki-nakano]

This is a dup of w3c/uievents#202

The isConfirmed is an opposite property of isComposing. So I think it's redundant. And changing inputType value could cause breaking some web apps.

FYI: Firefox is now dispatches 2 input events around compositionend against a real web-compat issue. One is immediately before compositionend with isComposing=true. Then, the other is immediately after compositionend with isComposing=false. This approach breaks the 1on1 relation between beforeinput and input, but works in the wild for now.