Piotrek Koszuliński

> Looking at some comments, I'd say that we should make it more precise from the day one by blocking changing only a certain container's content. Although... I can imagine...

> @Reinmar, yes it blocks the entire rendering. Blocking only the container (or part of it) in which the composition takes place may help to solve some cases with OT,...

BTW, we can also improve how the text nodes are updated. In https://github.com/w3c/editing/issues/149 I commented that: > Touching the same text node (by using methods like CharacterData.replaceContent()) doesn't break the...

Final words – I guess we know a bit more about the scope and complexity of this problem now. It looks to me that it may be a killer issue...

> 3. and 4. This is more general issue: It is impossible to navigate with arrow keys inside accent panel. After pressing left arrow last accent is inserted. After pressing...

> The general issue is that accent (´) is removed when typed on non-collapsed selection. May be that our dirty unsafe key hack fails here :(

I can see that the arrow keys break text input again. I think that this is the same issue as with what you described previously – that in e.g. Safari...

> As for #861 (comment) - while navigating with arrow keys inside balloon panel the selection changes so the renderer updates it (_updateSelection) which breaks composition. > Introducing e.g. blocking...

> I was also able to check how it works with replaceData. The replaceData does not break the composition only if the replaced part of text does not include the...

But do you think that it may be any performance issue if we use diffing only on strings which we know that got changed? This only affects typing and other...