Able to reproduce the issue on windows 7, Linux Ubuntu 14.04 and Mac 10.12.2 using chrome version 56.0.2924.87 and canary 58.0.3011.0.

This is regression issue broken in M56.Please find the bisect information as below
Narrow Bisect::
Good :: 56.0.2924.26 --  (build revision   433059)
Bad:: 56.0.2924.27  -- (build revsision  433059)

Unable to provide tool bisect as the good and bad builds are from branch builds.hence providing manual CL from the omahaproxy

Change Log::
https://chromium.googlesource.com/chromium/src/+log/56.0.2924.26..56.0.2924.27?pretty=fuller&n=10000

Unable to find the exact suspect from the above CL.Could any one from dev team please look into this issue.

Thanks,

Maybe this:
https://chromium.googlesource.com/chromium/src/+/57e20116f082592d8f4b101e9c76a70911982455

You can reproduce following simple html:

<input value="keep inputting here with IME" id="input"/>
<script>
setInterval(function() {
    input.value = "foo";
}, 2000);
</script>

The IME state shuould be reset.

We may need to call TextInputManager::ImeCancelComposition from the renderer process.
Assigned to changwan

Hi Chrome team, whats the status of this? This is a serious user input regression bug which causes data entry errors for our customers.

Targeting M-59. I'm on it.

Hmm... Actually, I think this was caused by SetComposition()'s return value change caused by https://codereview.chromium.org/2529803002, which is in the regression range. As long as SetComposition() returns false, we call ImeCancelComposition to the browser in RenderWidget::OnImeSetComposition().
I'm not the original author of the CL although I merged it.

yoichio@, do you have a cycle to handle this? I have other issues to target M59.

Reverting my suspicious CL(https://codereview.chromium.org/2529803002) didn't fix this
 though we can't revert the CL which fixes other P1.

Anyway, I investigate.

Manually bisected again
https://chromium.googlesource.com/chromium/src/+log/286c2ce88f848617aff81090e9cc41afdf5de7e5..b66eb61f525f914b1b478b56e7b4792db7b4c4e5

Maybe https://chromium.googlesource.com/chromium/src/+/50a098f28262dca3de4fa9ff3b26f7a14f5d582a ?
"Remove logic to reset input method more than needed by changwan"

Though Android IME apps reset its state if selection changes,
 many desktop IMEs don't so we need to care.

Although it may seem subtle, there are two different issues being discussed here:

1) https://jsfiddle.net/8v9usxts/6/
which I suspected was caused by return value change of SetComposition()

2) The example in #3.
whose support I intentionally removed in https://codereview.chromium.org/2370663002/
and being tracked in issue 681519.

And I think that's why the bisect ranges from #0 and #11 are different.

In any case, I need to polish up the composition cancellation workflow for issue 681519, so I'll look into this more. Thanks.

We should revive IME reset callback from Blink like that:
https://codereview.chromium.org/2828093003/

It's hard to agree that #14 is the right way to go because it's

1) Not complete: partial change in composition does not necessarily restart input.
2) Not sound: selection outside composition is technically valid on Android.
(see https://developer.android.com/reference/android/view/inputmethod/InputConnection.html#setComposingText(java.lang.CharSequence, int))

I'm thinking of observing composition range, while scoping out IME initiated changes.

Hmm.. I found a similar issue for Android, although it's an artificial one.

If you try to capitalize alphabets for the composition, Samsung keyboard reacts to the change somewhat terribly. And Google Keyboard does the same if you type fast.

http://jsbin.com/quvojawufi/edit?html,output

Lower to Pri-3, since a sample in #c1 should be done in composition event handler
instead of keyup event.

We should discuss this with w3c editing-tf to determine right behavior.