I know we had discussed this specific issue before, but one of the issues related to the cursor wrapper that is very apparent on Android is that when you set stored marks during a composition, you don’t see the marks until after the compositions ends. To repro
- Type “Test” without completing the composition
- Hit bold, italic, or underline in the toolbar
- Continue typing
You do not see the styles until after you hit enter (which is essentially what happens all of the time if you just completely disable the mark cursor).
Another issue that we had tackled is that if you dispatch a transaction on compositionstart or compositionend in handleDOMEvents, you end up updating the cursor wrapper (even though it is a meta transaction). This would cause infinite composition loops where the keyboard would spaz out. We had to have getters and setters in place to “lock” the cursor wrapper while we were dispatching a transaction. The easiest way to get around that specific issue is to only update the cursor wrapper when the doc or selection has changed when updating the state.
I’d be happy to file Github issues for those two problems, but the other sets of issues are still a bit tough because most of them have to do with custom key handling. We have a way to map input events to synthetic backspace events and Enter keydowns often work. If you have custom handling on enter and the selection ends up in a spot that then triggers a composition start, Android will get confused when it sees the markcursor. The combination of updating the dom programmatically on keydown and having a composition trigger seems to be the underlying culprit. I’m going to investigate a bit more and try suppressing the markcursor temporarily.
I was able to break it a bit by setting stored marks when hitting enter here https://glitch.com/edit/#!/gleaming-hall?path=index.js:65:29. I wasn’t experiencing the same bugs but you do start experience bad behavior. I’ll try to further pinpoint tomorrow to actually file Github issues.