As it was commented in the patch I proposed for this issue, it seems the position adjustment is being removed, as it's source of interoperability issues.

https://codereview.chromium.org/2674673004/#msg6

Would it be be possible to get some info about the progress of such behavior change ? Is there any issue/bug I should track ?

I don't really understand the logic behind Yosin's comment in https://codereview.chromium.org/2674673004/#msg6 :

> I think we don't need to adjust caret position. Caret should be located at user's specified position.

Showing a caret in a non editable position is certainly not what the user is expecting. Regardless of where the caret ends up being in the DOM sense, from the user's point of view, they're trying to place it where they'll be doing some typing. Showing it at a place where no typing can occur is misleading and confusing.

It isn't hard to find examples in the wild of people trying to address this kind of problem, so I think it is worth fixing in the browser:

* https://github.com/froala/wysiwyg-editor/issues/1175

* https://stackoverflow.com/questions/36871141/how-can-i-fix-caret-issues-in-a-contenteditable-that-contains-non-editable-html

* https://github.com/guardian/scribe/issues/411

* https://stackoverflow.com/questions/18985261/cursor-in-wrong-place-in-contenteditable

@yosin any additional comment on this issue ? I'm willing to implement a fix, but we'd need an agreement on the expected behavior. Additionally, it'd be really useful to know more about the plans of the Blink Editing team regarding this interoperability issues, as you have commented in the CL:

"This is source of incompatibility with Firefox/Edge and we are working
for getting rid of this adjustment now."