Create a new item âFoo Barâ. Move cursor before the âBâ in âBarâ and press backspace so it should now read âFooBarâ with the cursor between the two words. Hit enter.
Expected result
It should make the top item contents be âFooâ and create a new item below with contents âBarâ.
Actual result
Top item is âFooâ but bottom item is âBarBarâ (with the cursor after the second âBâ).
I seem to be able to do that too, but for some reason it only does it if you backspace, but not if you move your cursor there afterwards. Feels like a bug with the keyboardâs auto-correct/prompt but Iâm more curious why this only started happening now.
I canât reproduce the bug using the Swiftkey keyboard, so seems like a Gboard issue.
Unfortunately it will be almost impossible to elevate this obscure bug to Google, so it would be great if a workaround fix could be implemented in Dynalist. Deleting the combining space and splitting an item is something I do more often than I realized.
This issue is less of an edge case than I originally thought. It turns out you can trigger it whenever autocorrect is performed on the last entered word before you press âreturn/enterâ. See this screen capture: https://streamable.com/xsmf2
Iâm surprised I havenât hit this earlier, as it seems like a more common way to encounter this bug. You may want to re-prioritize this as it is likely something other people are actually hitting.
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.
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.
Thanks for doing a deep dive on this. Completely understand dropping this; what a mess from Googleâs side. Hopefully they fix this behavior on their end at some point.
Iâm surprised as well that I donât hit this more often. I guess I typically tap on the autocorrect suggestion rather than relying on enter to substitute, so itâs definitely not a big usability issue.
From my research this issue has been here quite a while (that github link is from 2018), so sadly Iâm not very optimistic on a timely fix. (Still hoping they do though)
Gboard emits an âunknownâ keyboard event, so I ended up having to resort to âcompositionendâ which is an event typically used by east asian language input methods like chinese and japanese.
Gboardâs writing fires that event, and if I noticed the event is fired with a newline character, then I do the cleanup of removing the newline character then triggering the usual code for handline enter key.