Able to reproduce the issue on windows 10, Mac 10.12.4 using chrome version 58.0.3029.110  and canary 60.0.3099.0 with the below steps

1. open https://jsfiddle.net/sds0ax4a/ 
2. focus on div
3. type in Japanese language
4. Observed not able type after 2 letters 

This is regression issue broken in M57.Please find the bisect information as below

Narrow Bisect::
Good:: 57.0.2951.0 -- (build revision 438385)
Bad:: 57.0.2952.0  --  (build revision 438707)

Change Log::
https://chromium.googlesource.com/chromium/src/+log/afdef36fb3116c5b6e07a5727bf9ee42e690ed4e..bcd68bcb14206d4f26c5798ed714a0878ac09b28

Note:: Observed the cursor shows at the end of the div for both good and bad builds.

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

Thanks, 

Seems to caused by [1] according to change log in #c3.

changwan@, could you take look?

[1] http://crrev.com/2530843003 Introduce InsertIncrementalTextCommand to respect existing style for composition

Sorry to interrupt you but do you have any idea about when this problem could be solved?
I really appreciate any help you can provide.

Ok, I investigated a bit.

Although yabinh@'s CL somehow uncovered it a bit, but I think a similar problem was there for a long time. There's lots of logic change in yabinh@'s CL that makes partial revert difficult.

On Linux, if you compose "aa",

SetComposition("a")
SetComposition("aa")

Then the second call is incremental but SetEditableSelectionOffsets() returns false because Editor::IsEditable() returns false.

On Android, when you compose "a",

SetComposition("a")

This alone hides keyboard because input type becomes NONE.

When you set selection, e.g. using SetSelectionOffsets(PlainTextRange(7, 7)),
there are two different positions that this can end up.

1) at the end of the read-only DIV
2) after the read-only DIV

But we seem to interpret this as 1) now.

yosin@, would it make sense to add an option for FrameSelection::SetSelection() to prefer editable position in this case? Please advise.

Thanks for investigation, changwang@!

It seems this is caused by well known visible position canonicalization issue 
for cE=false.

yabinh@'s patch makes IME code expose this.

>would it make sense to add an option for FrameSelection::SetSelection() to prefer 
>editable position in this case? Please advise.

We don't want to do so. This issue should be fixed by changing canonicalization to work
well with cE=false.

Lower to Pri-2, since there are workaround, e.g. Move cE=false element outside editable.