Android chrome browser needs two CR to respond to ask in WASM

[gchiu]

>> ask ["hello" text!]
hello bye  ;<== need to hit enter twice instead of once as on desktop browsers

== "yes^/^/" 

[hostilefork]

@giuliolunati, do you know why this would be?

[giuliolunati]

@hostilefork no, I don't know...
(that's a replpad-js issue, it isn't?)

[hostilefork]

So this turns out to be just a general basic issue of trying to depend on keydown/keypress/keyup events, which apparently is non-viable on Android in a generic sense.

You can find a lot written about the topic, if you look for "android keycode 229" or "android keydown", but this is a pretty succinct summary:

https://stackoverflow.com/questions/30743490/capture-keys-typed-on-android-virtual-keyboard-using-javascript

See also:

• Gboard input event for Enter is useless
• contentEditable on Android is the absolute worst
• keydown and keyup events do not have proper keyCode (it's always 0)

"The reason - when you press a key - the input is still not guaranteed to be what the user pressed, because of auto suggest and other events that may follow immediately and invalidate the event."

If you use the hacker keyboard or something that is less abstracted, it can send keycodes as if you were typing on a typical keyboard. But the default "Gboard" keyboard is going to be uncooperative here.

I'm looking into workarounds. We may be able to use an <input> element instead of a <span> (but style it to look the same), and there could be distinct events sent to those. We wouldn't get every key as it happened, but we'd see completed words and maybe all the actual Enter events. I'll see if I can get a baseline experience to work.

but longer term...

...the longer problem is that not getting distinct key events will prevent the web console from being able to make its own language-augmented suggestions. I think this means that if you're going to get suggestions on Android you'd have to use a different keyboard.

So we might do some kind of detection and say:

Hello Android user! You are using a keyboard that is not sending distinct key events as they happen to the browser, because it is trying to provide its own autocompletion service. Unless you change your keyboard to an alternative (such as Hacker Keyboard) you will be stuck in a lowest-common-denominator mode we have enabled...

Something like that. But I definitely don't want it to be unusable with the stock keyboard, so I'm looking to see what's possible.

(An insane option would be to write a custom Android keyboard that forked something like Hacker Keyboard and then build the suggestion machinery into that, to communicate with the browser about the code at hand... but. No. Just enumerating the possibilities.)

[hostilefork]

I worked up some heuristics, PLEASE TEST!

It seems to kind-of-sort-of-work--at least on my (old) phone. There are alert dialogs that will come up if it finds something confusing. If you confuse it, remember what you do and reproduce it.