IssueTracker

In EditText first event closes the keyboard and second handles back navigation. In Compose, first closes the keyboard, on second text field loses the focus, third handles back navigation.

I checked a bit the code and found that we consume the key event when we move the focus. If I always return false in this lambda, the behavior becomes similar to EditText.

So we probably shouldn't consume events with keyCode=KEYCODE_BACK.

The behavior can be useful in some situation if it could be controlled and not be the default :-)

Re-assigning to Ralston for a proper fix.

Thanks for the very quick turnaround time on this. Very appreciated.

Which version did this fix land into? It seems it's not fixed in compose 1.0.0-rc02.

This change won't make it to 1.0 release

I'm not sure, what is expected behaviour for android?

In compose, when screen opens with a TextField, it's not becoming focused, but using xml EditText it does.

After the fix, will the TextField resign focus after first back button tap, or focus just won't prevent back button from working when keyboard is hidden?

For me the first case seems preferable, but still I'm not sure why in xml EditText it's focused but keyboard not shown. I haven't worked with xml much.

In case anyone is looking for a solution until this fix is released, check out my answer: https://stackoverflow.com/a/68420874/3585796, will be glad to see a less tricky way to do it.

If the keyboard(IME) is open, the back key dismisses the keyboard.

Otherwise, the back key moves focus to the parent. In most cases you don't have a parent, but consider this example:

Row(Modifier.focusable()) {
   Box(Modifier.focusable()) {
   }   
}

If the box is focused, then clicking back will move focus to the Row.

In compose, we have a top level focusable modifier that is not visible to the user. In this example, setContent has a focusable modifier (That we use internally to control focus, and TextField has it's own focusable modifier:

setContent {
    TextField()
}

Now, when the text field is focused, the keyboard is shown. Clicking back once would hide the keyboard, clicking back the second time would clear focus from the text field, and clicking back the third time would send the back key to the activity and exit the app.

This bug fixes this issue where you needed 3 back presses to clear focus. Now on the second back press, instead of moving focus to the root focus modifier (which the user can't see), we send it to the activity so that the app can exit.

With this fix you would still need two back presses. Dismissing the keyboard does not clear focus. This is by design, and is consistent with the Classic view system. It allows the user to dismiss the keyboard, but still continue typing on the keyboard without the user having to hit tab multiple times to re-focus on the TextField that was previously focused.

The fix did not make it to v1.0.1 either. Can we expect it in any 1.0.x release soon or will it be exclusive to 1.1.x releases?

You can use compose 1.1.0-alpha03, the fix is included there. Not sure if there is anything unstable compared to 1.0.2, you need to test that.

Also, if you are as unhappy as I am with the fact that the focus stays with TextField after the keyboard disappears, take a look at this solution

Dismissing the keyboard does not clear focus. This is by design, and is consistent with the Classic view system. It allows the user to dismiss the keyboard, but still continue typing on the keyboard without the user having to hit tab multiple times to re-focus on the TextField that was previously focused.

How can the user continue typing after they have closed the keyboard?

How can the user continue typing after they have closed the keyboard?

They can use a hardware keyboard. I do this all the time during development using tools like scrcpy, for instance, or there can be an actual hardware keyboard connected to the device running your app.

it may be cool for development, but in real life I believe 99% of people don't use external keyboard with a phone, so it's quite strange to leave the focus for such a rare case.

I think the focus should not disappear only if there's some external device connected.

There are still Android phones with physical keyboards. Hardware keyboards are also used with tablets, and laptop-style devices (Chromebooks for instance). Finally, the hardware keyboard may be an accessibility input device.

And would it be possible to check if there is a hardware keyboard? I assume that the vast majority of devices only uses the onscreen keyboard and for these, after closing the keyboard it doesn it make any sense to keep the cursor blinking.