Status Update
Comments
ma...@gmail.com <ma...@gmail.com> #2
Yoinking from triage
ak...@google.com <ak...@google.com>
ya...@gmail.com <ya...@gmail.com> #3
Thanks for taking the time to file this issue!
Would you be able to provide more details about the scene and this error? I tried the following code:
@Preview
@Composable
fun AutofillTextField3() {
var password by remember { mutableStateOf("") }
val focusRequester = remember { FocusRequester() }
LaunchedEffect(Unit) {
focusRequester.requestFocus()
}
Column(Modifier.fillMaxWidth()) {
Text("Enter password")
TextField(
value = password,
onValueChange = { password = it },
modifier = Modifier
.fillMaxWidth()
.focusRequester(focusRequester)
.semantics { contentType = ContentType.Password },
label = { Text("password") },
placeholder = { Text("type your password here") }
)
}
}
but upon the app starting, Autofill displayed the suggestion chips along the keyboard for me. Verified that this is the case for BTF
as well.
Were you specifically using the Password
content type? The only way I was able to reproduce this was if the same code above instead had ContentType.NewUsername
set. In that case, you’re right—when the app starts, no suggestions are displayed. Only long-pressing and triggering autofill from the textbar menu displays the suggestions. I believe that is working as intended (as that is a field marked for new users and thus should not display previously saved data).
Are there any other details in the sample above that are missing?
pa...@gmail.com <pa...@gmail.com> #4
I think what I need to add to clarify is that the password fails to autocomplete when it's on another screen than the username field is. That seems to be the culprit.
I created a minimal example project which demonstrates this and also captured a video of the app running. From it you can see that the autofill chips appear briefly when navigating to the password screen. However, they disappear a moment after when the focus is requested.
Let me know if I can help providing any other information.
jm...@gmail.com <jm...@gmail.com> #5
Ah, I see what you're saying — thanks for the video and code! It seems like there’s two parts to this.
You mean that in a multi-page login, you would expect after selecting a credential chip, Autofill should fill in not only the first “username” on the first screen, but also “password” on the next screen. I believe this is working as intended. On the Compose side, it looks like we’re properly calling the autofill APIs. Looping in Kate from the autofill team to check: Kate, I double checked this with FormGen, and there’s the same behavior
The second part is that even if the password field is not immediately filled, the chips disappear after a second of being displayed. Unfortunately I was not able to reproduce this even running the sample code locally ― but I do notice that clicking the displayed chips on the password page does not autofill. Only after clicking autofill
in the text toolbar does selecting the chip actually invoke autofill. If the focusRequester
is removed from the code, then autofill works fine.
Seems like Compose is still properly sending the requested information over and calling the right APIs. I see that in both instances (in the working version without focusRequester
plus the one without it), Compose is calling notifyViewEntered
for the password screen, and then populateViewStructure
is called. But tapping onto the chip in the version with focusRequester
does not trigger autofill
(whereas it does without focusRequester
). I glanced over the semantic properties we send, and they look identical between both text fields.
I’m attaching some logs for the working version
ri...@gmail.com <ri...@gmail.com> #6
Correct, without focusRequester, tapping into the input field correctly populates the suggestion chips. With the focusRequester in place however, autofill chips appear but are immediately removed as shown on the video (probably due to the requested focus).
Thanks for looking into this.
j....@gmail.com <j....@gmail.com> #7 Restricted
rs...@vcusd.org <rs...@vcusd.org> #8
Thanks
Description
- Build Number: google/panther_beta/panther:14/AP11.231020.016.A1/11113945:user/release-keys
(Note: It is the build when sending this report. For exact build reference, please see the attached bugreport.)
What type of Android issue is this? Calls / Voice / Mobile Network
What steps would let us observe this issue?
1. Recording via the recorder app or the camera (video)
What did you expect to happen?
No static sound
What actually happened?
Static sound
How often has this happened?
Every time
What was the effect of this issue on your device usage, such as lost time or work?
High
Additional comments
I need my phone's microphone to record interviews for my master's degree
Debugging information
Google Play services
com.google.android.gms
Version 234414038 (23.44.14 (190400-580326705))
System App (Updated)
Android System WebView
com.google.android.webview
Version 604519333 (119.0.6045.193)
System App (Updated)
Network operator: F SFR
SIM operator: SFR
Filed by Android Beta Feedback. Version (Updated): 2.39-betterbug.external_20231115_RC02 (DOGFOOD)
To learn more about our feedback process, please visit