Not reproduce the issue on Chrome 57.0.2951.0-Win7, 57.0.2946.0/Ubuntu14.04

Upstreamed b\33678130

I've filed https://bugs.chromium.org/p/chromium/issues/detail?id=675009#, which is the root cause of this issue (and is independent of Google Docs).

This seems not a dup to issue 675009, as the issue 675009 can repro in M56 while this issue cannot.

M57 9003.0.0 is last known good and 9004.0.0 is bad (repros this issue).

Bisecting the root cause cl: https://chromium.googlesource.com/chromium/src/+log/56.0.2923.0..57.0.2925.0?pretty=fuller&n=10000

Bisected and the cl https://codereview.chromium.org/2493703002/ is the cause.

Reassign to yabinh@ for appropriate fix.

We produce selectionchange event after a message loop, so it should not be relevant.  Did yabinh@'s CL also cause input(beforeinput) and compositionend event order change? If so, it is possible that Docs isn't handling them correctly.

As issue addressed by that patch  http://crbug.com/663944  was theoretical, how about reverting?

Reply to comment 10:
Checked https://cdn.rawgit.com/w3c/uievents/gh-pages/tools/key-event-viewer.html with clank. It seems that the event order is expected. Here is the event list. (Note that there is no selectionchange listener in the above html.)

1. input 'a':
keydown, compositionstart, compositionupdate, input, keyup
2. then input 'b':
keydown, compositionupdate, input, keyup
3. then input space:
compositionupdate, textinput, input, compositionend,keyup
keydown, textinput, input, keyup
4. then press backspace to delete the space:
keydown, input, keyup
5. press backspace again to delete 'b':
keydown, compositionupdate, input, keyup
6. press backspace again to delete the remaining 'a':
keydown, input, compositionupdate, textinput, compositionend, keyup

Re #10, the bisect was done based on the same Document, so it is unlikely caused by Google Docs code.

Re #12, this issue doesn't repro for Chinese Pinyin IME but only repros on Korean IME because Korean IME has a special behavior:
1) pressing 'l' will generate composition text 'ㅣ'
2) pressing 'k' will finish composition 'ㅣ' and generate a new composition text 'ㅏ'
Can you please verify the event order with/without your cl?
Thanks!

I checked the event on Android. Here is the result:

When inputting 'ㅣ' on https://cdn.rawgit.com/w3c/uievents/gh-pages/tools/key-event-viewer.html:
 1) For Chrome Canary 57.0.2951.0 or before, the result is:
keydown, compositionstart, compositionupdate, input, keyup, keydown, keyup
 2) For Chrome Canary 57.0.2952.0 or after, the result is:
keydown, compositionstart, compositionupdate, input, keyup, keydown, [compositionupdate, input,] keyup

The additional compositionupdate & input is caused by additional call of setComposingText("ㅣ"). I think it might be root cause to this issue.

But it might be a different bug. I reverted my CL, but still got additional events. Besides, 2951 was released on Dec 14th, while my CL was landed on Nov 18th.

Yabin, this issue is ChromeOS-specific, so this would need to be investigated on a ChromeOS device, not Android.  shuchen@, we don't have a ChromeOS setup, so is there a way we could simulate the ChromeOS Korean IME on Linux?  Or, does this affect Korean IME on any other platform?

Anyway, because this seems time-consuming to investigate and M57 branch point is coming up tomorrow, I have a revert up at https://codereview.chromium.org/2644623003

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/53003b5bb24d266ac78adf0623b2dd07c1ac6e9f

commit 53003b5bb24d266ac78adf0623b2dd07c1ac6e9f
Author: aelias <aelias@chromium.org>
Date: Thu Jan 19 01:38:43 2017

Revert 'Make "compositionend" event fired after setting caret position'

This reverts http://crrev.com/2493703002, which was bisected to cause Google
Docs Korean IME  issue 674295 .  Note the revert is unclean in that the
structural changes to InputMethodControllerTest are preserved (only the
new tests are deleted) and a new updateStyleAndLayoutIgnorePendingStylesheets
was needed because of changes since the original landing.

TBR=yosin@chromium.org
BUG= 674295 , 663944 

Review-Url: https://codereview.chromium.org/2644623003
Cr-Commit-Position: refs/heads/master@{#444593}

[modify] https://crrev.com/53003b5bb24d266ac78adf0623b2dd07c1ac6e9f/third_party/WebKit/Source/core/editing/InputMethodController.cpp
[modify] https://crrev.com/53003b5bb24d266ac78adf0623b2dd07c1ac6e9f/third_party/WebKit/Source/core/editing/InputMethodControllerTest.cpp

Re #15, you can use http://www.chromium.org/chromium-os/how-tos-and-troubleshooting/building-chromium-browser.
Make sure you build your Chromium binary with flags "buildtype=Offical" & "branding=Chrome".

Not reproduce the issue on CrOS 9202.1.0/Chrome 57.0.2987.6 - Paine, Reks. 
KO IME works properly on Google docs.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-57; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-57 label, otherwise remove Merge-TBD label. Thanks.

No action needed, r444593 made it in before M57 branch cut (r444943).