[Chrome] The macOS accent panel places inserted characters far after initial selection

[f1ames]

Extracted from https://github.com/ckeditor/ckeditor5-typing/issues/95 as I found an exact cause and it deserves a separate issue as it is quite different than others.

The issue:

As mentioned in https://github.com/ckeditor/ckeditor5-typing/issues/95#issuecomment-371516735, this issue is caused by the native Chrome bug which moves the selection if some characters are removed from focused text node (while triggered by listening on event like keyup, compostion*, etc).

The issue was reported here - https://bugs.chromium.org/p/chromium/issues/detail?id=820067 and has been partially solved in Chrome 65 (just in time as it was released few day ago) 🎉 However, for this case it still happens (see above report for more detials).

---

The real problem with it, is that usually we may block removing inlineFiller during composition, however in this case keyup is fired before compositionstart (so renderer is unaware of composition which may/will take place) and removes the inlineFiller as character was already inserted, which triggers the native issue moving caret / inserting character in a wrong place.

[f1ames]

It could be solved by inserting/keeping fillers when selection is on element boundary (as mentioned in #4303).

[f1ames]

The native Chrome issue was closed as WontFix, but as mentioned in a previous comment it should be solved by further improvements in fillers managment.

[f1ames]

It is not only case of inline filler unfortunately. When working on #3703 I noticed following behaviour - when some text is inserted or removed from before selection (via CharacterData.insertData/deleteData) in the text node in which composition takes place, the accent character is placed in the offset from selection equal to inserted/deleted characters (it happens only if no accent was selected before text length changes):