[Bug] On Android Chromium, pressing newline after header1/2/3 causes editor to lose focus

[Parasrah]

Describe the bug
On mobile, after using markdown to create a header, hitting <return> to create a newline closes the keyboard

To Reproduce

1. Open docs
2. Create a new document
3. Insert keys: #<space>Test<return>

Expected behavior

An h1 is created, the cursor is on a new line, and the keyboard is still open

Actual Behavior

An h1 is created, the cursor is on a new line, the keyboard is closed

System Information (please complete the following information):

• Device: Pixel 5
• OS: Android 11
• Browser: Brave Browser
• Browser Version: 1.26.67, Chromium 91.0.4472.114
• Browser Extensions: Built-in brave ad-blocker (disabled)
• Do you have any DNS-based content/ad-blockers? No
• Are you on a managed network? Wireguard VPN

[johnozbay]

Hi there,

Thanks a lot for reporting this!
We're investigating what might be causing this, and we'll fix this up right away!

Will keep this thread posted once I know more,

Best,
J

[johnozbay]

Thanks once again for filing this and for your patience!
Thanks to this we've actually discovered that iOS has some strange keyboard bugs with its on-screen keyboards, and how it reports keys to websites / apps. See my comment about this here in #77. (p.s. we fixed those bugs, and will soon close that thread, so let's consolidate all markdown bugs here in this thread from now on)

Seems like creating headers using markdown is now broken badly in general (on both iOS and Android) and we're working on fixes for these as we speak.

Basically the issue seems to be that every mobile OS's software keyboard acts differently / report keystrokes/text-input differently.

– i.e. GBoard sends entire words once you select an autocorrect recommendation from the list... it sends the whole word, all its characters, all at the same time [acts almost like pasting], whereas other keyboards send letter-by-letter.

So if you were to try and do key-by-key / letter-by-letter shortcut detection,
and let's say wanted to watch for something like # header to trigger H1, on iOS you'd get :

#
#
# h
# he
# hea
# head
# heade
# header

with GBoard you'd get :
#
#
# header

and may cause our markdown shortcut detector to miss things. And due to the fact that each android vendor has its own software keyboard (🤦🏻‍♂️) there's no easy way for us to meaningfully detect / code exceptions like "on android do this, on iOS do this" etc... + since on both OSes you can use external keyboards, and there's no way for apps / websites to detect which keyboard is in use, we'll need a more generalized approach.

We're now trying to come up with a smarter and more generalized strategy to handle these, and hope to have fixes out for this soon! Let me know if you discover more markdown edge-case scenarios in this thread – and we'll try to address all as quickly as humanly possible!

Apologies for the inconveniences!

Best,
J

[Parasrah]

Thanks so much for the update, and my apologies as I totally missed that other thread in my search

– i.e. GBoard sends entire words once you select an autocorrect recommendation from the list... it sends the whole word, all its characters, all at the same time [acts almost like pasting], whereas other keyboards send letter-by-letter.

I do use gboard, although I may be misunderstanding because I rarely use auto-correct when creating a header. When I write:

#

Cryptee shifts over to the h1 formatting, which is great, but when I then write in my word and hit <ret> it closes the keyboard.

Of course I might well just be misunderstanding your response and you understand the problem

[johnozbay]

Hey there!
My apologies for explaining badly – what I meant to say was that there seems to be an incompatibility between our markdown shortcut detector and soft-keyboards on all operating systems in general. And I've reason to believe the specific issue you're experiencing has to do with the way our markdown shortcut detection works right now.

So we're going to have to re-do some of the groundwork to make sure this works as expected on all OSes, and all types of different keyboards. Chances are this will mean re-writing / updating some or all of our markdown shortcut detector. We're looking into fixing this and many other markdown shortcut related issues this week, and will keep you posted once I find out more. 👍🏻

In the meantime, if you run into other similar issues, and happen to have an extra minute, shoot them my way here! It'll help us prepare even stronger test cases!

[johnozbay]

Hi there,
Just wanted to give a quick update – 
It seems like we can reproduce this bug even without markdown, (simply by toggling H1 / H2 etc using the editor tools)
So looks like this isn't related to markdown after-all.

Just to be 100% sure, could you confirm this is also the case with your device as well?

[Parasrah]

You are indeed correct, I just tested this on my phone and can confirm it also doesn't work with the editor tools

[johnozbay]

Thanks for bearing with this, I've got some funky news.

Looks like this is an Android-predictive-keyboard bug.
Turns out keyboards like GBoard etc don't actually update cursor position when you press "return/newline" and only update it when you press the next character. So when you press "return/newline", what happens is that the system moves its virtual cursor to where the newline would be, but doesn't report it to the webpage. 🤦🏻‍♂️ To phrase this differently, predictive/auto-corrective keyboards don't move the cursor on newline characters on Android now 🤦🏻‍♂️🤦🏻‍♂️🤦🏻‍♂️

We didn't catch it in our tests, since our tests didn't use GBoard or alike predictive keyboards.

And looks like we're not the only ones who got hit by this sudden change.
We've been digging through, and found some others who got hit by the same change.

OneNote, Workflowy, CKEditor, Quill, possibly another one : wasabeef/richeditor-android#257 etc etc

Since we can't really detect the specific brand of keyboard or type of keyboard our users are using, what we'll do instead on android is to watch for "enter" key events (since we're not getting any \n characters until you type one more letter), and move the cursor after 30ms if selection hasn't moved +1 already. What this means is that on Android pressing newline will be ~30ms delayed, not the end of the world, but it's a really really ugly hack.

How does this relate to this bug John? you might rightfully ask.
While typing out a header, pressing "newline/return" adds a "newline" character, then formats the new line as a paragraph. If the cursor doesn't move, or the newline isn't there yet (because GBoard didn't actually add it in) then you get an out-of-range error, because there's no newline to format.

Now that we know what's up, we're working on a fix, and building extensive test cases to make sure things work as expected.

Thanks for standing by while we address this nightmare of a situation gboard / chromium introduced.

Best,
J

[johnozbay]

Small update.

The problem does not happen with alternative keyboards, but those do not always use IME composition. It seems that after the event.keyCode === 229, there is no following keydown event with the newline. Normal <textarea> tags do not suffer from this problem.

---

Seems like this has been around for a while now.
Found the bug filed in Google's Issue Tracker for GBoard here :
https://issuetracker.google.com/issues/177757645 (requires a google account login)
and here's the bug filed in Chromium :
https://bugs.chromium.org/p/chromium/issues/detail?id=1161227

---

We're going to try our best to compensate for this, but given that it's a keyboard-specific bug, it's going to be a hacky fix. Stay tuned for more fun updates 😂. 🤦🏻‍♂️