I notice that in some cases (not always!) my OpenFL app has a bug in Android System WebView. When I touch to TextField - android keyboard does not appear. In mobile browser there is no such problem. Only in Android System WebView. But it used by many other apps (social networks, messengers, game aggregators, etc) and it is matter for me!
I test it with different versions of Android System WebView (including Dev) - same result.
I find that all stuff about it is in \HaxeToolkit\haxe\lib\lime\8,2,2\src\lime_internal\backend\html5\HTML5Window.hx
I see strange things as set inputType = “password” for Android only and other.
Can anyone explain is it actual approach with text input in html target? Or it has outdated solutions?
I try to modify HTML5Window.hx but no result.
It is simple to reproduce. Just create TextField in main class:
var input = new TextField();
input.type = TextFieldType.INPUT;
input.border = true;
input.text = "";
var format = new TextFormat();
format.size = 24;
format.font = "Sans";
format.color = 0x101010;
input.defaultTextFormat = format;
input.needsSoftKeyboard = true;
input.x = 10;
input.y = 10;
input.width = 200;
input.height = 30;
stage.addChild(input);
On the HTML5 target, we basically create an invisible <input> element, give it focus, and listen for its “input” event.
However, in Android web browsers, the <input> element behaves differently than browsers on other operating systems. At least for languages like English and others that use Latin characters. On Android, the <input> element always behaves as if the user is using an IME (Input Method Editor), like it would with other languages like (for instance) Japanese. Browsers on other operating systems don’t do that. Setting the input.type = "password" on Android seems to force it to behave more like the browsers on other operating systems. It’s definitely a bit of a hack, though.
Regardless, this hack/workaround should not prevent the soft keyboard from appearing. A keyboard should still appear when you are entering a password in an HTML form.
There’s a define, lime_enable_html5_ime, that you could try to disable our hack/workaround. I don’t think that it will help with the soft keyboard appearing, but maybe I’m wrong. If it does work, the keyboard input may be a little buggy. I tried to implement better IME behavior than we had before, but, as I recall, it’s still not perfect.
I understand about lime_enable_html5_ime but for me no difference for input.type
With “password” type my password manager app and my keyboard app try to save it:) So it can seem buggy for players) But it is not as important as absence of a keyboard!
I don’t understand why in chromium based android browsers all works fine and only in Android System Webview no… May be it implement a defense mechanism against invisible inputs?)
Why don’t you export it as an android app instead ? Last time I tried it worked but it took me some time to figure out the right setup, but it works and it works great.
Based on some Stack Overflow questions that I just found, this is not something that necessarily affects OpenFL only when using the Android system WebView. It can also affect even regular HTML forms apps that don’t use Canvas or WebGL at all.
It looks like there are some good answers with multiple workarounds that you can try (assuming that you have control over the code that creates the WebView).
If you have the ability to test your content in the WebView without deploying to users, you could try loading a different, simple HTML page with an <input> and test if it has the same issue.
<input> works
Only after I focused it - OpenFL TextField starts working too.
Seems there is a problem in lime.
May be lime can create a visible input in place and sizes as a TextField above canvas?
The simplest way to test it - open url in Telegram (it uses Android System WebView).
