When using the InputRules plugin and any handleTextInput features, the end user will see the character they typed into the editor for a moment before it is changed or removed. It feels clunky, like there is a performance issue, even though there is not.
Could we change the timeout in DOMChange's constructor from 20ms to 0? This eliminates the jitter on Chrome and Firefox (haven’t tested anywhere else). I could put together a PR for the change, though it is a 1 character difference, maybe a PR is overkill?
The timeout exists because Android browsers will often fire a jumble of composition and input events in quick succession, and we only want to read the actual DOM after they’ve all occurred (updating the DOM when there’s still events pending leads to weird effects). But it might be possible to remove it in cases that don’t involve composition (I think the composition events tend to fire first, so just looking at the first event could be enough). If you can make this change and do some testing (specifically, on Chrome Android, see whether swipe-typing with Google Keyboard and pressing enter while in a composition still do the right thing), I’d be interested in a pull request.
I would love to, but I don’t have an Android device. Is anyone set up for Android development willing to help out with this one?
Would a PR that allows this to be set through options be acceptable? Then the developer can do device checking (probably shouldn’t be in PM) and set this timeout to 0 for desktop browsers.
This patch should help a lot with this. I’m not entirely sure yet whether it will cause any problems in practice — I’m going to release it today and we’ll see.