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
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.
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>.
I also commented to Chromium's issue.
Please update this bug when the spec issue and/or Chromium issue have been resolved. Thanks.
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.