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.
