I’ve done a lot of digging and debugging since the bug was reported and more today. In total, hours already sunk into this issue.
A summary of what’s happening is basically Gboard “being clever” (or maybe just being dumb) and doing manipulations directly to the TextInput element that’s shared from within DOM of the browser/webview, without the browser being able to properly trigger/react to events. On top of this, it’s sometimes disobeying
event.preventDefault(), which is impossible to deal with.
I’ve consulted a few other open source contenteditable based editors and the solutions people came up were mostly:
- Attempting to analyze the patterns of events that Gboard does emit (that’s different that what ever other soft-keyboards usually do) and try to account for them. Probably the easiest to start with but there are many many edge cases that Gboard just doesn’t behave itself, and it’s very difficult to account for.
- Give up and build a completely different workaround where the app continuously diff the DOM for changes and try to interpret those changes. For example, if we find a newline character (or a
<br>) inserted, interpret that as pressing ENTER. That does solve it for the general case, but it feels really unnecessary and complex, just to fix Gboard.
In my debugging, here is what I observed Gboard do in response to your two bugs:
- When pressing ENTER, if it believes there is a word after the cursor, wait some time, and auto-correct the word after. The key here is the waiting. Dynalist performs the item splitting the moment you finish pressing the ENTER key, we then set the cursor position to the beginning of the new item. Gboard waits until the splitting is over, recognizes that we’re focused on a different input, but somehow doesn’t seem to use the new cursor position (0), then performs auto-correct which inserts the word somewhere after.
- When auto-correcting with ENTER, insert a newline character instead of firing the ENTER key event. When pressing ENTER doesn’t auto-correct, it does fire the event properly.
I’m surprised that nobody else seems to have raised this issue. I’m fairly confident it’s been problematic since the release of Dynalist, so I guess most people must have thought it’s an issue with the keyboard, or maybe it’s not as common for most people’s usage patterns. Perhaps people aren’t bothered much by it? Heck I use GBoard myself and haven’t noticed it before your post.
At this point, I don’t think sinking any more time into this issue is worth it. I don’t see any solution other than completely rewriting the entire way we interact with the contenteditable element, as well as interpret keyboard events.