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.