Splitting existing item can cause duplicate text

Steps to reproduce

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”).

Video showing the bug: https://streamable.com/ie71w


Android native app (reproed on both OnePlus 5T and Moto G7 Plus). Cannot reproduce on the desktop site or on the native iPhone app.

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.

Maybe we never noticed it before?

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.

Just wanted to give this a bump, as I’m stilling hitting this bug.

1 Like

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.

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.

1 Like

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.

Thanks again for getting to the bottom of this!

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)

Thanks for understanding!

1 Like

@Shida it looks like this is now fixed due to the other gboard fix! Out of curiosity, which approach did you end up using?

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.

1 Like