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).
Turns out it was a simple fix. The issue was that preventDefault() was being called on all touch events, which prevented the WebView from ever receiving focus. As a result, calling input.focus() had no effect, and the virtual keyboard wouldn’t appear — particularly on Android within a WebView.
The solution: don’t block the very first touch on the canvas — let the browser handle it so the WebView can receive focus. After that, you can safely resume calling preventDefault() as usual.
Here’s the minimal patch:
replace following in HTML5Window.hx
private function handleTouchEvent(event:TouchEvent):Void
{
if (event.cancelable) event.preventDefault();
...
with this:
private function handleTouchEvent(event:TouchEvent):Void
{
static var isTouchStartEventInited:Bool = false;
static var isTouchEndEventInited:Bool = false;
if (event.cancelable) {
if ((!isTouchStartEventInited && event.type == "touchstart") ||
(!isTouchEndEventInited && event.type == "touchend")) {
// allow WebView to receive focus on first touch
if (event.type == "touchstart") isTouchStartEventInited = true;
if (event.type == "touchend") isTouchEndEventInited = true;
} else {
event.preventDefault();
}
}
Side effect: the first tap may cause a brief flicker, since the browser’s default behavior is not suppressed. But in return, the virtual keyboard starts working reliably.
I could open a PR for this, but honestly — my last PR, which fixed a real production issue, has been sitting untouched for over six months. I’m just not motivated to submit another one that no one seems to care about.
I’m sorry that it takes us so long to review PRs. All contributors, including the leadership team, work on OpenFL in our free time. Unfortunately, that means that it can take a very long time to get something merged. It’s certainly not that we don’t care. If only I could work on this project full-time and give PRs and things the resources that they deserve.
Thanks for the honest response — I totally understand how things work in open source, especially when a project is maintained in people’s free time. I don’t take it personally, but as a contributor, it can feel a bit frustrating when real, production-tested fixes go unnoticed for months.
That said, we’ve built a fairly large project on top of OpenFL, and naturally we’re starting to worry a bit about its long-term stability. If OpenFL were to ever stop evolving entirely, we likely wouldn’t have the resources to maintain our own fork and keep up with changes in runtime environments — and that’s a risk that’s hard to ignore.
This isn’t a complaint at all — just something we’re genuinely thinking about.
