This affects sync text input code path. 1. Kotoeri sometimes doesn't process the first keypress in a web page. 2. ATOK sometimes needs to consume a Return key, but it is passed down to a web page anyway (causing bad misbehavior on google.com). This happens because we EditorState is now tracked incorrectly. There is an async message sent with old state, and then a sync message response with new state. But these are delivered out of order, so UI process ends up with an incorrect idea about input state. Yes, the incorrect data has ignoreCompositionSelectionChange set on it, but that's not sufficient for UI side heuristics to work well. rdar://problem/18431952 rdar://problem/18483741
Created attachment 239827 [details] proposed fix
Comment on attachment 239827 [details] proposed fix Any way to regression test this?
It's likely technically possible to test with an API test, as these drive testing from UI process side, however the complexity of such a test scares. More importantly, an API test would only test sync API, which is on its way out. Committed <http://trac.webkit.org/r174708>.