fix keyboard input in mobile browsers

[SuperMaxusa]

Fixes #262 (and probably #1212) by adding input event handler, tested in Chrome and Firefox on Android.

[copy]

Thanks, this looks like a good approach!

We could use some help with testing. I've deployed this version here: https://copy.sh/v86-staging/

Testing on ios: Both versions open the OS keyboard and work fine. The only differences seems to be that the new version scrolls to the top of the screen. This probably needs an e.preventDefault().

It would be nice if we could find a way to "downgrade" to using the input event gracefully, instead of checking the user agent. Maybe something like this:

keydown:
if(e.code === "Unspecified")
{
    // let the input handler run
    return;
}
// call preventDefault here to prevent the input handler
// or, if that is not robust, disable the input handler until the next keyup event

[SuperMaxusa]

The only differences seems to be that the new version scrolls to the top of the screen.

Same on Android, it because phone_keyboard always spawns at the top of page and browser focuses on it while typing.

v86/src/browser/main.js

Lines 2590 to 2592 in a3840e3

	// stop mobile browser from scrolling into view when the keyboard is shown
	phone_keyboard.style.top = document.body.scrollTop + 100 + "px";
	phone_keyboard.style.left = document.body.scrollLeft + 100 + "px";

EDIT: I sketched out a few ideas on how to fix it:

• make a DummyScreenAdapter.update_cursor hook and move phone_keyboard to the current row
• move phone_keyboard to where screen_container was pressed

[SuperMaxusa]

I pushed a fix to prevent screen scrolling and tried to fix keyboard and mouse in graphical OSes (on copy.sh/v86 it always opens the keyboard).

[copy]

Apologies for the delay in reviewing this. I would still like to get this merged, but I'm not sure about the approach. See the comments below.

[copy]

This code looks fragile with the hard-coded font size and adhoc scaling detection. Could we use the graphical mode codepath for this (always moving the element into viewport)?

[SuperMaxusa]

I will return the movement by touch coords.

[copy]

I'm not a fan of mobile detection based on user-agents. It can break under many circumstances, for example if the user uses a bluetooth keyboard, alternative keyboard app or alternative browser.

I wonder if we could instead implement feature detection, e.g.:

• only registering the input event when Unidentified or Process key values are detected
• registering the input event unconditionally, but cancelling it using preventDefault in the other event handlers when Unidentified or Process key values are detected
• any other ideas?

[SuperMaxusa]

• only registering the input event when Unidentified or Process key values are detected

This idea sounds good, but not sure about IME in desktop browsers. (upd: that's only affects non-English layouts)

Downgrading keyup -> input (call return, then go to input) doesn't work in Firefox Mobile for me (it's required for Backspace key).