Keyboard focus not restored to last element on app resume

[goffioul]

Bug Report

Problem

When resuming a cordova app, the keyboard focus is moved instead of being restored to the last focused element.

What is expected to happen?

When the cordova app is paused and there was a focused element in the webview content, one expect the focus to be restored to that element when the app is resumed.

What does actually happen?

The focus is moved to the first element in the page that has a non-negative tabIndex, otherwise to the document body (ignoring the elements with negative tabIndex).

Information

This behavior has been introduced with this commit: https://github.com/apache/cordova-android/commit/c2cafb4b45fcbb307a113828dfc9f723f8a6433b

Command or Code

• Create a new cordova app and add android platform.
• Add the following to div.class element in www/index.html:

<div id="focusable1" tabIndex="0">I am focusable</div>
<div id="focusable2" tabIndex="0">I am also focusable</div>
<input type="text">

• Add the following to www/css/index.css:

#focusable1:focus { background: yellow; }
#focusable2:focus { background: red; }

• Add the following to app.receivedEvents method in www/js/index.js:

document.getElementById('focusable1').focus();

• Compile and install the app
• On app launch, the first focusable element should have the focus, with yellow background
• Using mouse or keyboard, focus the second element, with red background
• Using adb, launch another app, e.g. adb shell am start com.android.settings/.Settings
• Resume cordova app, e.g. quit settings using the BACK button

Focus will be restored to the first element, with yellow background. If using tabIndex="-1" instead for the focusable elements, focus will be moved to the input element.

Version information

[email protected]

Checklist

• [X] I searched for existing GitHub issues
• [X] I updated all Cordova tooling to most recent version
• [X] I included all the necessary information above

[janpio]

(Great issue description! 💕 )

Looking at the commit (from 2014!) that added this behavior, it seems to have been added to fix a specific problem. Do you have a suggestion what should be done to fix the bug you reported? Should the code that resets the focus just be removed? Or are there other proper ways to handle this? "Manually" maybe?

[goffioul]

I should have added to my description that removing the call to requestFocus() fixes the problem for me. I'm testing this on an AMLogic set-top box with S905X chipset, running Android-7.1.2. Removing the call works for me, but I guess this will reintroduce the problem for the device it was added in the first place. Although I fail to see the use case for the Galaxy Note 3, as I guess it's a touch device, I don't get why there would be a keyboard focus problem. Maybe it was also related to the Android version used on such device at the time.

Maybe a more conservative approach could be to surround the call to requestFocus() with a condition that checks the device where the problem occurs.

[janpio]

https://issues.apache.org/jira/browse/CB-7172 gives some context on what was fixed back then:

I have application which open image selector using Camera plugin. After I select image, and execution passed again to my application it does not respond to any user actions.

Not sure what we should make of that though :/

[dpogue]

Maybe we can check if the view hasFocus() before trying to focus it? Theoretically if the webview has focus and is a child of the decorView, then hasFocus() should return true and we can skip calling requestFocus().

[goffioul]

@dpogue I can confirm that checking with this.getWindow().getDecorView().hasFocus() before requesting focus also fixes the problem for me.

[goffioul]

Any chance to have this looked at in the near future?