Status Update
Comments
kl...@google.com <kl...@google.com> #2
I wonder if this is the same as
gr...@google.com <gr...@google.com> #3
This is definitely an issue on emulator, but I cannot reproduce on a physical bluetooth keyboard.
For the emulator aspect, we will use
gr...@google.com <gr...@google.com> #4
@reporter can you let us know what keyboard you are using?
If you have time, can you also run something like this to provide more info on the keyboard?
var deviceText by remember { mutableStateOf("Type on keyboard to show device info.") }
val requester = remember { FocusRequester() }
Box(
contentAlignment = Alignment.Center,
modifier = Modifier
.fillMaxSize()
.padding(32.dp)
.onKeyEvent {
deviceText = it.nativeKeyEvent.device.toString()
false
}
.focusRequester(requester)
.focusable()
) {
SelectionContainer {
BasicText(deviceText)
}
}
LaunchedEffect(Unit) {
requester.requestFocus()
}
It should show you some information about the keyboard that is useful for us.
pa...@techbee.at <pa...@techbee.at> #5
Hi, thank you for coming back to this issue! I can still reproduce this problem on the emulator and on a physical device.
So I assume you are mainly interested in the information from deviceText = it.nativeKeyEvent.device.toString()
One observation that I just had (before posting the log entry): I added
.onKeyEvent {
Log.d("onKeyEvent", "nativeKeyEvent.device Vale: ${it.nativeKeyEvent.device}")
false
}
to the modifier of the OutlinedTextField. BUT: The log entry was only written when the focus moved INSIDE the OutlinedTextBox, when I'm inside the text of the OutlinedTextField and then press the arrow up or down, the focus moves to the next input field before/after, but NO log entry is written! It seems like this onKeyEvent is not even triggered in this case. (Just saying that I found it weird, but I guess it might even be an intended behaviour).
1st Scenario: Emulator (API lvl 31) with a physical keyboard connected through USB:
2023-08-22 22:34:36.216 2946-2946 onKeyEvent at.techbee.jtx D nativeKeyEvent.device Vale: Input Device 0: qwerty2
Descriptor: e9ac6dde47cf0ffa91b87f7b85e6f8de0933fc98
Generation: 24
Location: built-in
Keyboard Type: alphabetic
Has Vibrator: false
Has Sensor: false
Has battery: false
Has mic: false
Sources: 0x301 ( keyboard dpad )
The problem occurred, moving the arrow buttons moves to the next/previous input field instead of the next/previous line in the text.
2nd Scenario: Physical device, API lvl 29, Using Samsung Dex on a screen with a physical connected keyboard to the screen, the keyboard is the same as in Scenario 1
2023-08-22 22:49:22.655 8930-8930 onKeyEvent at.techbee.jtx D nativeKeyEvent.device Vale: Input Device 8: DeX keyboard
Descriptor: 04d9b1772be4728accf9a0632dc4a48ad3323835
Generation: 19
Location: external
Keyboard Type: alphabetic
Has Vibrator: false
Has mic: false
Sources: 0x101 ( keyboard )
ATTENTION: To my surprise this actually worked as expected!
3rd Scenario: Physical device, API lvl 29, using a physical bluetooth keyboard
2023-08-22 22:57:52.766 13202-13202 onKeyEvent at.techbee.jtx D nativeKeyEvent.device Vale: Input Device 9: Bluetooth Keyboard
Descriptor: c1e784c976c318bdc5c427bb7adb206b5bddef38
Generation: 24
Location: external
Keyboard Type: alphabetic
Has Vibrator: false
Has mic: false
Sources: 0x1000311 ( keyboard dpad joystick )
AXIS_GENERIC_1: source=0x1000010 min=0.0 max=1.0 flat=0.0 fuzz=0.0 resolution=0.0
AXIS_GENERIC_2: source=0x1000010 min=0.0 max=1.0 flat=0.0 fuzz=0.0 resolution=0.0
Here I had the problem again.
I hope this helps for your further investigation!
gr...@google.com <gr...@google.com> #6
Thanks for the information, SOURCE_KEYBOARD
since the target of said code is mainly for tv remotes where moving focus has higher priority than moving cursor, and hopefully tv remotes aren't classified as keyboard sources. Our previous testing for this worked with physical keyboards because it seems some keyboards match SOURCE_DPAD
and some don't.
I'll reach out to the relevant team to gather the same device information on tv remotes to verify the sources they have.
pa...@gmail.com <pa...@gmail.com> #7
Great, thank you for the update! =)
gr...@google.com <gr...@google.com> #8
Assigning to Halil to look into this for BTF2.
ap...@google.com <ap...@google.com> #9
Branch: androidx-main
commit f22cdff080ac5b0ac8c2efefa3d7daf0b2cd04c8
Author: Halil Ozercan <halilibo@google.com>
Date: Wed May 08 13:26:03 2024
Fix TextField processing of Dpad events
Both the legacy and the new BTF pre-process Dpad directional events to understand whether they are coming from a DPAD device. This is required for TV remotes since directional keys are used to switch focus, instead of carrying the cursor or selection on TVs.
However, the current logic accidentally captures regular hardware keyboards too, causing arrow keys to switch focus instead of manipulate selection.
This fix adopts the Keyboard/DPAD device differentiation logic from the platform by comparing the source of the event directly to the know `InputDevice.SOURCE_KEYBOARD` flag.
Fix: 305087008
Fix: 295666701
Test: gradle :compose:foundation:foundation:cAT
Change-Id: I8af343aa92c208669456bb399c26f9386ec69da5
M compose/foundation/foundation/src/androidInstrumentedTest/kotlin/androidx/compose/foundation/text/input/BasicTextFieldSemanticsTest.kt
M compose/foundation/foundation/src/androidInstrumentedTest/kotlin/androidx/compose/foundation/text/input/TextFieldFocusTest.kt
M compose/foundation/foundation/src/androidInstrumentedTest/kotlin/androidx/compose/foundation/textfield/TextFieldFocusTest.kt
M compose/foundation/foundation/src/androidMain/kotlin/androidx/compose/foundation/text/TextFieldFocusModifier.android.kt
M compose/foundation/foundation/src/androidMain/kotlin/androidx/compose/foundation/text/input/internal/TextFieldKeyEventHandler.android.kt
Description
Jetpack Compose component used: androidx.compose.material3:material3:1.2.0-alpha05 / OutlinedTextField
Android Studio Build:Android Studio Giraffe | 2022.3.1
Kotlin version: 1.8.22
When using an OutlinedTextField(...) with multiple lines with a physical keyboard (e.g. with the PC keyboard and the emulator, but also with a bluetooth keyboard on the phone), the up and down arrow keys do not act as expected.
Basically the up/down arrow keys move the focus to the previous/next input field. This is okay for single line input fields and checkboxes. But when it comes to a TextField with multiple lines, the arrow keys should go up/down one line - only when the first line is reached and the up key is pressed, the focus should change. This is not a specific issue of the current version, but has been an issue for multiple versions now.
There is also a topic on Stackoverflow on this:
The solution only works for BasicTextFields as the OutlinedTextField in Material3 doesn't have the onTextLayout = { } parameter. Anyhow, I believe that moving up/down one line in a multiline TextField should be the defualt behavior without the need of a workaround.
Could you please have a look at this? Thank you!