Is this buffer synchronization between keyboard app and Blink?

Google Doc native app doesn't use webview. So probably this is not a chrome / webview issue.

I, too, suspect that this is a Google keyboard issue, especially so if this has to do with the timing. There is a known race condition in a list of Google Keyboard apps which recently got fixed: b/27193048 (Google internal).

But if this is indeed a webview issue, probably the recent IME redesign might have fixed it.
On Chromium, you could try this by going to 'about:flags' and enable 'Run IME on its own thread' flag.

ryanacheu@gmail.com,
Could you check if you could reproduce the same issue with another well-known keyboard app?

I mentioned Google Docs since chromium (in Java/C++ code) could probably use whatever workaround they use (I know it doesn't use a webview).

It also appears in SwiftKey, and Swype, but not Go Keyboard or Samsung's Keyboard.

The 'Run IME on its own thread' flag puts it into the same state as Google Docs where it's good as long as you don't do the action too quickly, much better though!

Thanks for the quick turnaround. And thanks for testing with development version of chrome.

This is a generic conflict handling problem. The previous version of chrome / webview is just bad at conflict resolution. The renderer will think it's A, B, C while browser will think the order is A, C, B, and weird things happen.

Do you still think chromium should call updateSelection more often in this case?
Since there is no other way to provide the conflict information to the input method app,
we just finish the currently composed text. Keyboard apps should be able to handle the conflict signal, but may not be able to do so in some cases.

By the way, one more question. Do you see the exact same issue with the flag on / off with the mentioned keyboards (when there is a problem) when you type fast enough? Or was there any difference in the results when you tested?

My suggestion of calling updateSelection more often was because I noticed the keyboard doesn't know where the cursor is. I put some logging in the keyboard and noticed that the issue was occurring when the keyboard tried to re-enter the suggestions for the previous word and called setComposingRegion with the wrong cursor position.

Every keypress was incrementing where the keyboard thought the cursor is, and chrome never sent an update to the keyboard telling it that the cursor position was actually at N-2 because one of the returns actually deleted a bullet, not added a newline. I tried a quick change in chromium to try to make it send the updateSelection more often so that it knew the correct cursor position, and that worked, but it caused text to randomly duplicate sometimes (race condition?). I figured you guys would know how to fix it better :)

Looking at the keyboard logcat for the webview with the flag on, the same thing happens now, but then updateSelection is called shortly afterwards with the correct selection/composition position. If I press the backspaces quickly, it seems like this update doesn't reach in time and it gets into a bad state.

For you last question, the behavior with the flag on, but issuing the commands quickly, is the same as the behavior with the flags off but issuing the commands at a normal or slow pace.

Ok, I had a chance to look at this today, and it seems that there is a complicated bug in Google Keyboard. Here is the sequence that leads to such a condition:

1. When typing enter key twice to exit the list mode, we keep updating the selection changes. However, the second enter key was used only for exiting the list mode, resulting in 'one new line' in the text. We update selection again in this situation, but Android's InputMethodManager internally ignores selection update when it's exactly the same as the previous update. So Google Keyboard does not seem to understand that the second enter key has been handled.

2. When typing AA and a space, Google Keyboard still thinks that editor
should supposedly have two new lines and AA and then a space. Now pressing backspace will trigger setComposingRegion() but it tries to set the region from the second A and the space because it internally keeps an incorrect state.

Latest version of Chrome does not seem to have this problem (with or without IME thread option turned on) with Google Keyboard. It seems to me that Google Keyboard tries to correct the state after its first trial only for the latest version.

I think Google Keyboard (and all the other keyboards) may need to handle silent selection update better.

Filed b/27781317 for internal tracking of the issue for Google Keyboard.

Yes that's the same conclusion I came to when I investigated this bug (wrong keyboard state when you have diff # of characters than a plaintext doc).

I can still reliably reproduce the bug in the latest Chrome Dev build on the play store using the steps in the video.

If it's helpful, we fixed this in our webview based native app by calculating the correct position in JS and calling InputConnectionWrapper#setSelection whenever we think the internal keyboard state will get out of sync by passing a message to native.

Re #10, I'm afraid that it will end up in a race condition when you type quickly. Also, please note that setSelection() will not help the situation when we migrate to IME thread approach.

BTW, is this one of the reasons why Quora overrides WebView#onCreateInputConnection()? Are there some other workarounds?

It can lead to a race condition, but it's preferred since users naturally pause after hitting enter (I also haven't been able to trigger it by exiting lists, only by holding delete while deleting lists with multiple indent levels).

This is currently the only workaround, we previously had others for older Android versions. We switched to using Crosswalk (a Chromium fork) for the editor recently to reach better consistency across versions.