1315881 - compositionend/compositionstart should not be fired for partial-commit

Status: UNCONFIRMED

(Core :: DOM: Events, defect, P5)

Description

[Yohei Yukawa]

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0

Steps to reproduce:
 1. Open https://w3c.github.io/uievents/tools/key-event-viewer.html
 2. Type "とうきょうきょうと"
 3. Hit space key to update the composing text to "[東京]京都" where "[]" indicates the focused segment (clause).
 4. Hit Ctrl+N (if you are using MS-IME key binding) to see that only "東京" is committed. "京都" remains to be in the composing state.

Expected result:
 Only compositionupdate should not be generated at the step 4.

Actual result:
 compositionend/compositionstart pair is generated as if there was a moment where there is no text composition.

Sorry if this is what the spec requires, but I feel that the current behavior is really strange because WM_IME_ENDCOMPOSITION is *not* generated in the step 4.

Additional Information:
 - Reproducible with Google Chrome 56.0.2912.0 (Official Build) canary (64-bit) on Windows 7 SP1
 - Not reproducible with Microsoft Internet Explorer 11.0.9600.18499 on Windows 7 SP1
 - Not reproducible with Microsoft Edge 13.10586 on Windows 10 Anniversary Update

Comment 1

[Yohei Yukawa]

Hmm, this comment seems to be saying that this is indeed what the the spec requires, right?

https://bugs.chromium.org/p/chromium/issues/detail?id=564684#c7
> There are other cases where compositionend can be generated without
> really ending the composition. The naming might be misleading, but
> compositionend means that any text is transited from composition to
> the committed string.
> 
> Some IME allows part of comopsition being ended. For instance, when
> you have a composition string "abcde", users can commit only "ab".
> In this case, "cde" is still in composition mode, but "ab" has ended
> composition.
> 
> I'm not sure how well this is described in the spec nor how well it
> is interoperable though.

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I don't think we should behave so because your expected behavior looks not useful for web apps.

For example, if your STR works as you expected, following events are generated:

1. compositionstart (data: <selected text>)
2. compositionupdate (data: "と" ~ "とうきょうと")
3. input (immediately after #2 for every modification)
4. compositionupdate (data: "東京京都")
5. input
6. compositionupdate (data: "京都")
7. input

So, web apps cannot distinguish without complicated script with following cases:

* "東京京都" is converted to "京都"
* "東京" is partially committed and "京都" is still in composing.

I don't think that each web application can handle partial commit correctly with your expected bhavior. So, I think that firing compositionend/compositionstart is safer, isn't it?

And I think that it's bad behavior for MS-IME for Korean users. MS-IME for Korean does NOT notify apps of each Hangul character commit with WM_ENDCOMPOSITION. Therefore, with your expected behavior, compositionstart will be fired only when you type first character compositionend will be fired only when you type Enter or something. However, both IE 11 and Edge doesn't work so. So, they do something special for Korean TIPs for (perhaps) avoiding some trouble.

Anyway, I think that this should be discussed in spec issue <https://github.com/w3c/uievents/issues>.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I also commented to Chromium's issue.

Comment 4

[Andrew Overholt [:overholt]]

Please update this bug when the spec issue and/or Chromium issue have been resolved. Thanks.

Comment 5

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, 4 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.