Status Update
Comments
an...@google.com <an...@google.com>
wa...@gmail.com <wa...@gmail.com> #2
We have some support in androidx.compose.ui.autofill
Leaving this bug open in case Ralston wants to add more info
wa...@gmail.com <wa...@gmail.com> #3
I found an example
D/Autofill Status: Autofill popup isn't shown because autofill is not available.
Did you set up autofill?
1. Go to Settings > System > Languages&input > Advanced > Autofill Service
2. Pick a service
Did you add an account?
1. Go to Settings > System > Languages&input > Advanced
2. Click on the settings icon next to the Autofill Service
3. Add your account
Is this a bug on your side or do the app developers of these password managers need to change their implementation?
wa...@gmail.com <wa...@gmail.com> #5
wa...@gmail.com <wa...@gmail.com> #6
b9...@gmail.com <b9...@gmail.com> #7
wa...@gmail.com <wa...@gmail.com> #8
I setup this modifier:
@OptIn(ExperimentalComposeUiApi::class)
fun Modifier.autofill(
autofillTypes: List<AutofillType>,
onFill: ((String) -> Unit),
) = composed {
val autofill = LocalAutofill.current
val autofillNode = AutofillNode(onFill = onFill, autofillTypes = autofillTypes)
LocalAutofillTree.current += autofillNode
this.onGloballyPositioned {
autofillNode.boundingBox = it.boundsInWindow()
}.onFocusChanged { focusState ->
autofill?.run {
if (focusState.isFocused) {
requestAutofillForNode(autofillNode)
} else {
cancelAutofillForNode(autofillNode)
}
}
}
}
And use it like this:
val emailState = remember { EmailState() }
Email(
modifier = Modifier.autofill(
autofillTypes = listOf(
AutofillType.Username,
AutofillType.EmailAddress
),
onFill = { emailState.text = it },
),
emailState = emailState,
onImeAction = { onForgotPasswordSubmitted(emailState.text) }
)
With these steps, autofill works for me.
gr...@gmail.com <gr...@gmail.com> #10
Works perfectly fine on the latest stable and alpha versions. Did you check in my second comment if you enabled everything?
os...@gmail.com <os...@gmail.com> #11
I believe so?
I copied the modifier and then used
modifier = Modifier.autofill(
autofillTypes = listOf(
AutofillType.Username,
AutofillType.EmailAddress
),
onFill = { emailState.text = it },
)
on my text field.
wa...@gmail.com <wa...@gmail.com> #12
gr...@gmail.com <gr...@gmail.com> #13
The auto-filling works for me with the latest alpha version, but I'm never presented with the save dialog though.
I am having exactly same problem. Autofill works, but the Save dialog is never shown...
wa...@gmail.com <wa...@gmail.com> #14
Any updates on this? I can't get LastPass to display at all. I can ONLY get the Google Auto-fill service to work
gr...@gmail.com <gr...@gmail.com> #15
Same here, autofill in Jetpack Compose only works with the Google auto-fill service. When picking 1Password as the Auto-fill service in Settings, the debug log prints out:
D/Autofill Status: Autofill popup isn't shown because autofill is not available.
Did you set up autofill?
1. Go to Settings > System > Languages&input > Advanced > Autofill Service
2. Pick a service
Did you add an account?
1. Go to Settings > System > Languages&input > Advanced
2. Click on the settings icon next to the Autofill Service
3. Add your account
wa...@gmail.com <wa...@gmail.com> #16
wa...@gmail.com <wa...@gmail.com> #17
po...@gmail.com <po...@gmail.com> #18
1.3.1 won't dialog prompt to save a password for me but will prompt to autofill for google.
As a workaround, you can wrap the TextInputLayout from a layout file to an AndroidView in compose.
@Composable
fun TextFieldView(
modifier: Modifier = Modifier,
textState: MutableState<String>,
@LayoutRes layoutRes: Int,
textChanged: () -> Unit = {},
) {
AndroidView(
modifier = modifier
.fillMaxWidth(),
factory = { context ->
val layout = LayoutInflater.from(context).inflate(layoutRes, null)
layout.findViewById<TextInputEditText>(R.id.tilET).apply {
doAfterTextChanged {
textState.value = safeText
textChanged.invoke()
}
}
layout
},
update = {
}
)
}
val EditText?.safeText: String get() = this?.editableText?.toString().orEmpty().trim()
<?xml version="1.0" encoding="utf-8"?>
<com.google.android.material.textfield.TextInputLayout
xmlns:android="http://schemas.android.com/apk/res/android"
android:id="@+id/til"
style="@style/TextInput"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:hint="Username">
<com.google.android.material.textfield.TextInputEditText
android:id="@+id/tilET"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:autofillHints="username"
android:imeOptions="actionNext"
android:inputType="textNoSuggestions"
android:selectAllOnFocus="true" />
</com.google.android.material.textfield.TextInputLayout>
<?xml version="1.0" encoding="utf-8"?>
<com.google.android.material.textfield.TextInputLayout
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
android:id="@+id/til"
style="@style/TextInput"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:hint="Password"
app:endIconMode="password_toggle">
<com.google.android.material.textfield.TextInputEditText
android:id="@+id/tilET"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:autofillHints="password"
android:imeOptions="actionDone"
android:inputType="textPassword"
android:selectAllOnFocus="true" />
</com.google.android.material.textfield.TextInputLayout>
oo...@gmail.com <oo...@gmail.com> #19
ch...@gmail.com <ch...@gmail.com> #20
ma...@gmail.com <ma...@gmail.com> #21
I tried using similar to above example. But its not working & following logs are getting printed.
getAutofillClient(): null on super, trying to find activity thread getAutofillClient(): none of the 1 activities on com.xx@8b0a7bc have focus No AutofillClient for com.xx on context com.xxn@8b0a7bc requestHideFillUi(null): anchor = null
Autofill popup isn't shown because autofill is not available. Did you set up autofill?
- Go to Settings > System > Languages&input > Advanced > Autofill Service
- Pick a service
Did you add an account?
- Go to Settings > System > Languages&input > Advanced
- Click on the settings icon next to the Autofill Service
- Add your account
setSessionFinished(): from ACTIVE to FINISHED; autofillableIds=null
Can anyone help
si...@google.com <si...@google.com> #22
Please fix 1password and compose
ch...@gmail.com <ch...@gmail.com> #23
aa...@icloud.com <aa...@icloud.com> #24
Any update? It would be good to fix it asap, please.
ta...@monzo.com <ta...@monzo.com> #25
Any update on this?
It can be overlooked since it is simple but one of the important convenience feature.
ma...@voltasit.com <ma...@voltasit.com> #26
Autofill is currently listed as "In Focus" on our
lu...@gmail.com <lu...@gmail.com> #27
compose bom version: 2023.06.01
AS: Giraffe 2022.3.1
ar...@gmail.com <ar...@gmail.com> #28
ez...@gmail.com <ez...@gmail.com> #29
We are seeing "Contents can't be autofilled" toast message, when user has other password managers that aren't google, such as Samsung Pass
ja...@gmail.com <ja...@gmail.com> #30
Could you please post some updates on this?
- it is one year in the roadmap:
https://developer.android.com/jetpack/androidx/compose-roadmap - one CL abandoned more than a year ago:
https://android-review.googlesource.com/c/platform/frameworks/support/+/2434079 - another CL is getting silent:
https://android-review.googlesource.com/c/platform/frameworks/support/+/3009614
It is sad that almost 3 years after a stable release of Compose there is still no support for Autofill.
ja...@gmail.com <ja...@gmail.com> #31
A quick update here -
We built autofill for 1.7 and found that we need to do some substantial rework of the semantics system before it lands (this is ongoing top priority - aiming for hopefully 1.8).
Turning it on caused a large performance drop app-wide. We're working on fixing that, and then will turn autofill on.
It's currently #1 item on all of prioritization for compose feature work. Will give more update when it's getting closer to landing.
an...@gmail.com <an...@gmail.com> #32
he...@gmail.com <he...@gmail.com> #33
See
ja...@deepl.com <ja...@deepl.com> #34
ma...@memrise.com <ma...@memrise.com> #35
The majority of autofill CLs landed this week. It seems that the next alpha should have this :) 🤞
pr...@gmail.com <pr...@gmail.com> #36
We'd appreciate any feedback on the API shape. If you want to test the APIs, you can turn on the flag by adding ComposeUiFlags.isSemanticAutofillEnabled = true in your onCreate() method before super.onCreate() and add in the latest Snapshot version in your build.gradle file.
Please note that turning on this flag will lead to performance regressions and also know the API shape may be different when we officially release it.
Happy coding!
sa...@gmail.com <sa...@gmail.com> #37
sa...@gmail.com <sa...@gmail.com> #38
#36 are you only currently interested in API shape feedback, or should I be filing issues for non performance related bugs?
[Deleted User] <[Deleted User]> #39
I would love for the api shape to be the way it was with xml - a simple one lime flag
si...@gmail.com <si...@gmail.com> #40
co...@protonmail.com <co...@protonmail.com> #41
I agree. Adoption of the flags was not high. Adoption of this will be lower. Users blame the password manager not the apps that have not implemented the simple flags.
"I would love for the api shape to be the way it was with xml - a simple one lime flag"
co...@protonmail.com <co...@protonmail.com> #42
We are accepting all types of feedback, thank you so much to those who have already submitted! We hear your feedback about having autofill be one line and are working to incorporate that into the final version of Autofill in Compose along with the performance improvements. Unfortunately, we can’t communicate any specific timeframe, but stay tuned and we’ll update you here as soon as we can.
Compose Autofill will not solve the StrictModeUnsafeIntentViolation as this is a known issue that lies with the autofill framework team. We have raised this as an issue with the autofill framework team.
-Meghan
si...@gmail.com <si...@gmail.com> #43
Personally I care less about a 1 liner and more about versatility of the API.
The 1 liner is good if it doesn't limit what can be done.
First and foremost it should be an idiomatic API.
co...@protonmail.com <co...@protonmail.com> #44
With new Compose UI version :
I see a lot of Autofill enhancements
1. The old autofill APIs are deprecated. Use the new semantics-based API instead. (I943ff)
2. Rewrite requestAutofill API to exist outside of autofill manager. (Id1929)
Can you confirm that it fixes the first problem mentioned in the
"One problem is that it only works with the Google autofill service. When using any other service like Microsoft Authenticator or OneKey"
This is something important for us. so please confirm on urgent basis
Thank you
si...@gmail.com <si...@gmail.com> #45
wa...@gmail.com <wa...@gmail.com> #46
Hi Priti,
Thanks for reaching out. The new Autofill APIs were added to 1.8 and you should be able to use them. I tested our demo App and Autofill works with Google Password Manager and LastPass. Can you verify that you try out this sample?
@Composable
fun BasicTextFieldAutofill() {
val autofillManager = LocalAutofillManager.current
Column {
Text(text = "Enter your username and password below.")
BasicTextField(
state = remember { TextFieldState() },
modifier = Modifier.semantics { contentType = ContentType.Username},
)
BasicTextField(
state = remember { TextFieldState() },
modifier = Modifier.semantics { contentType = ContentType.Password },
)
// Submit button
Button(onClick = { autofillManager?.commit() }) { Text("Submit credentials") }
}
}
The entire demo is here:
Source:
Can you try this out and report back if it does not work?
co...@protonmail.com <co...@protonmail.com> #47
#46 Is there some mechanism in autofill to differentiate different login/password combos for the password manager? In my app they can login to different servers they own for different services and I'd like to have some ways for the password manager to only shows the credentials relevant to the current service type.
tr...@gmail.com <tr...@gmail.com> #48
We do not have a way to differentiate/filter credentials within the credential managers.
-Meghan
br...@gmail.com <br...@gmail.com> #49
Please check it out and let me know what you think and let me know if you have any questions
-Meghan
ed...@gmail.com <ed...@gmail.com> #50
#48 Then from the docs how "For example, if a user has already signed into your app through the Chrome browser on their laptop and saved their password through a credential provider, then their credentials are served to them through Autofill." works? Or how does Chrome to tell the password manager the current website he's browsing.
Like in my case the user have saved a password in Chrome for a website with an url, and in my application he configure to connect to that same website and the same url there's really no way from Compose to have that match? All I can offer to the users is that they save again all their login/password for their servers after entering them in my app, and then they will have the list of all entries for every server they add ?
nu...@gmail.com <nu...@gmail.com> #51
#47: Tell us more about your use case. Did this work in a view-based app but doesn't work in Compose? If it did, what are the APIs you used for views?
Is this related to using
#50: This is good feedback. The document meant to point to the fact that if you have stored credentials, you can long press on a textField and then select one of your stored passwords. But it the way it is worded makes it look like there is a way to connect the web version of an app with the android version of the app. That's a good idea. We don't have this right now, but if you file a feature request we can send it over to the autofill team.
pr...@intercom.io <pr...@intercom.io> #52
That use case is specific for a Compose app from start. Will stay with the basic support then.
For the feature request can do if you point me to the proper tracker category.
kl...@google.com <kl...@google.com>
kl...@google.com <kl...@google.com> #53
I am verifying the given code with my team now
Additionally , This is the beta release (1.8.0-beta02) , when we can expect to have a stable release of for androidx.compose.ui:ui-* ?
to...@gmail.com <to...@gmail.com> #54
More information on reporting issues here:
Use this component: Android Public Tracker > App Development > Jetpack (androidx) > Autofill
kl...@google.com <kl...@google.com> #55
ap...@google.com <ap...@google.com> #56
Please let us know if you have any other issues.
-Meghan
ap...@google.com <ap...@google.com> #57
Project: platform/frameworks/support
Branch: androidx-main
Author: Ralston Da Silva <
Link:
Introduce InputText Semantics Property
Expand for full commit details
Introduce InputText Semantics Property
TextFields have an EditableText semantics property which
stores the text value after output transformation. Autofill
needs access to the text value after input transformation
but before output transformation. Adding this semantics
property helps send the right information to the Autofill
service.
Bug: 395911609
Bug: 176949051
Test: Added new tests and updated existing tests
Relnote: "Added a new semantics property InputText that captures
a textfield's value before output transformation is applied."
Change-Id: Iae46a52e7fbb1a3558e897c5afebd125089befbb
Files:
- M
compose/foundation/foundation/src/androidInstrumentedTest/kotlin/androidx/compose/foundation/text/input/BasicTextFieldSemanticsTest.kt
- M
compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/input/internal/CoreTextFieldSemanticsModifier.kt
- M
compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/input/internal/TextFieldDecoratorModifier.kt
- M
compose/ui/ui-test/src/androidInstrumentedTest/kotlin/androidx/compose/ui/test/ErrorMessagesTest.kt
- M
compose/ui/ui-test/src/androidInstrumentedTest/kotlin/androidx/compose/ui/test/FindersTest.kt
- M
compose/ui/ui-test/src/androidInstrumentedTest/kotlin/androidx/compose/ui/test/assertions/AssertText.kt
- M
compose/ui/ui-test/src/commonMain/kotlin/androidx/compose/ui/test/Assertions.kt
- M
compose/ui/ui-test/src/commonMain/kotlin/androidx/compose/ui/test/Filters.kt
- M
compose/ui/ui/api/current.txt
- M
compose/ui/ui/api/restricted_current.txt
- M
compose/ui/ui/bcv/native/current.txt
- M
compose/ui/ui/integration-tests/ui-demos/src/main/java/androidx/compose/ui/demos/UiDemos.kt
- M
compose/ui/ui/integration-tests/ui-demos/src/main/java/androidx/compose/ui/demos/autofill/TextFieldAutofillDemo.kt
- M
compose/ui/ui/src/androidInstrumentedTest/kotlin/androidx/compose/ui/autofill/AndroidAutofillManagerTest.kt
- M
compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/autofill/AndroidAutofillManager.android.kt
- M
compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/semantics/SemanticsProperties.kt
Hash: dee965267730e9b0b1a865a991db3515cdfc4b25
Date: Tue Feb 18 16:11:58 2025
ap...@google.com <ap...@google.com> #58
Tried out the latest sample but I'm unable to get the store password with commit
to work. There is no popup prompted with 1.8.0-beta02. I set the password manager to be the Google Password Manager. Phone is Pixel 8 running Android 15. Is the sample incomplete?
In some scenarios username and/or password may be generated. E.g in our usecase we have a unique number that serves as the account and password, and there is no additional details needed such as email. The user interaction to create an account would be just pressing a button "Create account" that generates a new account. With the current API I what would be the recommended way to implement this? I see there being 2 options:
- Upon successful account creation, set the semantic on a hidden TextField or TextField for login, before navigating away. (Feels it could be likely to race when set the property on a textfield just before navigating away)
- When showing the account number after a successful account creation, set it semantic
NewPassword
and then do aLaunchEffect
to commit. However this breaks the guideline of only calling commit on a button press.
ap...@google.com <ap...@google.com> #59
For the scenario above, it would also be nice to have an options to disable the strong password suggestion. Because as mentioned the user does not get to select their password.
ap...@google.com <ap...@google.com> #60
Edit: I finally made it work. One have to enable the "Offer to save passwords", in Google Password Manager.
Furthermore, you have to have both NewUsername
& NewPassword
content type on two separate fields, and seemingly the user have to interact with both fields in-order to offer the storage of a new login. E.g settings "username" and "password" to be default text in the field and the calling "commit" will not work, nor will it to programmatically modify these strings. An interaction with the view/keyboard has to happen.
I'm looking forward to hear if there is any way of programmatically just offering this, the current flow seems very complex for a lot of usecases.
[Deleted User] <[Deleted User]> #61
Thank you so much for your feedback. What sample specifically were you looking at?
The strong password option is password manager specific so while you may see certain behavior by Google Password Manager another service may give you different results.
When using Google Password Manager, the save dialog will only appear when there is a NewUsername and a NewPassword field. There also does need to be some touch or keyboard/focus input to trigger notifyViewEntered. This is not Compose specific and how its done in views as well.
Let me know if there's anything else!
-Meghan
il...@gmail.com <il...@gmail.com> #62
As a reminder, do not use beta01 and beta02 in any production apps
v....@gmail.com <v....@gmail.com> #63
Hi Meghan! Thanks for the quick reply.
This is the sample I was looking at:
Regarding strong password: I see, I assume it shows this the knowing that it has to provide a password.
When using Google Password Manager, the save dialog will only appear when there is a NewUsername and a NewPassword field.
Is this the case for just Google Password Manager or all apps interacting with the autofill? Could a autofill provider choose to offer to save a Password without any user interaction and just "NewPassword" field?
We have this scenario in with our service. All our users sign up by pressing "Create account" we generate an account number to which they use as their login, users provide no email, username or password. Since the account is a generated value, we'd like to offer to save it in the users password manager so they don't forget it and have a nicer experience when logging in on other devices. I can also imagine other apps having similar solutions or generating the password to the user automatically.
Edit: I found the solution for my scenario, the usecase is not to go by the autofill service in this case, it seems like if you want to save a password w/o user interaction or with the help of the keyboard on should use the CredentialsManager.
Thanks for your reply & help Meghan
David @ MullvadVPN
gu...@googlemail.com <gu...@googlemail.com> #64
I just tried it out. In a single text field it works now. But when I use for example two text fields and on IME action next on the first one I switch the focus to the next field via FocusRequester, the keyboards stays below the first text field and therefore hides the next one.
My assumption would have been that the keyboard would now automatically jump to the next, now focused field.
re...@gmail.com <re...@gmail.com> #65
I guess the problem was partially fixed, tested on version
Here are a few problems:
- The TextField does not get fully visible when using ImeAction (Previous or Next) and focusing in a TextField that is hidden under the keyboard
- The TextField does not get fully visible when the user types on the keyboard.
- Considering the scenario that the TextField was visible when focused, and the user scrolls the screen and start typing while the focused TextField is hidden.
il...@gmail.com <il...@gmail.com> #66
hi...@gmail.com <hi...@gmail.com> #67
I think there is a mistake on the release note of
The release notes say that the behavior of adjustResize
has been improved, but I think this is a mistake for adjustPan
.
According to adjustResize
, but that task still seems to be a
I actually tried it with the accompanist sample, but it only works well with adjustPan
.
Added on 2022/03/02
I just looked at the release notes, and the description is now fixed. Thanks to the person who fixed it.
ap...@google.com <ap...@google.com> #68
Branch: androidx-main
commit 0de2359ab6335c7680e54cdd7b7bae046df9cdae
Author: Zach Klippenstein <klippenstein@google.com>
Date: Tue Feb 22 18:59:29 2022
Update TextFieldsInScrollableDemo to enable toggling setDecorFitsSystemWindows.
Bug:
Bug:
Bug:
Test: manual, since this is just a demo change.
Change-Id: I94deb16188232d8fe2d87b97b27dd3b7f2d36f68
M compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/text/TextFieldsInScrollableDemo.kt
ap...@google.com <ap...@google.com> #69
Branch: androidx-main
commit 30ab5ff0d1840570f5628d9489b47ce118caa4a3
Author: Zach Klippenstein <klippenstein@google.com>
Date: Sat Jan 29 09:36:44 2022
Introduce onFocusBoundsChanged.
Design doc:
Note that this feature does not currently work with AndroidView (
that needs to be wired up in the ui module but this API is needed to fix
an issue in foundation, and I want to leave it as Experimental for now,
and we don't allow cross-module experimental access. When this modifier
is stabilized, it should be moved to UI, and that bug resolved.
Bug:
Bug:
Bug:
Test: Manual via FocusedChildDemo
Test: ./gradlew :compose:f:f:cDAT
Relnote: "Introduced experimental `Modifier.onFocusedBoundsChanged` to allow
observing the bounds of child focusables."
Change-Id: I14283393b5273527ab65f4aa1a2d4383321b0d95
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/Focusable.kt
M compose/foundation/foundation/api/public_plus_experimental_current.txt
M compose/foundation/foundation/api/current.txt
M compose/foundation/foundation/api/restricted_current.txt
A compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/FocusedBounds.kt
A compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/FocusedBoundsDemo.kt
A compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/FocusableBoundsTest.kt
M compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/FoundationDemos.kt
sa...@gmail.com <sa...@gmail.com> #70
<activity android:windowSoftInputMode="adjustResize">
Column(modifier = Modifier.wrapContentHeight().navigationBarsWithImePadding())
pa...@7p-group.com <pa...@7p-group.com> #71
Concerning that workaround:
You can get rid of that hacky delay
with an OnGlobalLayoutListener
which will observe the actual IME rect size and will be triggered when the soft keyboard is fully visible.
A basic example could look like this:
val bringIntoViewRequester = remember { BringIntoViewRequester() }
val scope = rememberCoroutineScope()
val view = LocalView.current
DisposableEffect(view) {
val listener = ViewTreeObserver.OnGlobalLayoutListener {
scope.launch { bringIntoViewRequester.bringIntoView() }
}
view.viewTreeObserver.addOnGlobalLayoutListener(listener)
onDispose { view.viewTreeObserver.removeOnGlobalLayoutListener(listener) }
}
OutlinedTextField(
modifier = Modifier.bringIntoViewRequester(bringIntoViewRequester),
...
)
However additional view logic will be needed for it to work with multiple TextField
s.
¯\_(ツ)_/¯
te...@gmail.com <te...@gmail.com> #72
I'm currently using the following workaround :
@OptIn(ExperimentalFoundationApi::class)
// TODO Remove this workaround once they fix the issue
fun Modifier.bringIntoViewOnFocus(
source: MutableInteractionSource? = null,
extraOffset: Float = 0f,
): Modifier = composed {
var layoutCoordinates by remember { mutableStateOf<LayoutCoordinates?>(null) }
val requester = remember { BringIntoViewRequester() }
val isKeyboardShown = LocalWindowInsets.current.ime.isVisible
val isSourceFocused = source?.collectIsFocusedAsState()?.value ?: false
val focusModifier = when (source) {
null -> {
val scope = rememberCoroutineScope()
Modifier.onFocusEvent { state ->
if (state.isFocused && isKeyboardShown) {
scope.launch {
requester.bringIntoView(layoutCoordinates, extraOffset)
}
}
}
}
else -> Modifier
}
if (isSourceFocused && isKeyboardShown) {
LaunchedEffect(Unit) {
requester.bringIntoView(layoutCoordinates, extraOffset)
}
}
Modifier
.onGloballyPositioned { layoutCoordinates = it }
.bringIntoViewRequester(requester)
.then(focusModifier)
}
@OptIn(ExperimentalFoundationApi::class)
private suspend fun BringIntoViewRequester.bringIntoView(
coordinates: LayoutCoordinates? = null,
offset: Float = 0f,
) {
val position = coordinates?.size?.toSize()?.toRect()
val adjusted = position?.copy(
top = position.top + offset,
bottom = position.bottom + offset
)
bringIntoView(adjusted)
}
You can pass in MutableInteractionSource
or it will default to Modifier.onFocusEvent
+ an extra offset in case the bottom navigation gets in the way. I'm sure it's not the best solution but it seems to work ok.
Usage :
val extraOffset = with(LocalDensity.current) {
BottomHeight.toPx()
}
OutlinedTextField(
value = "test",
onValueChange = { },
modifier = Modifier.bringIntoViewOnFocus(extraOffset = extraOffset),
)
ap...@google.com <ap...@google.com> #73
Branch: androidx-main
commit d9c6260e0ecaab7b33ecda95611d60e3184a0fa4
Author: Zach Klippenstein <klippenstein@google.com>
Date: Mon Jan 31 09:46:32 2022
Make scrollable keep focused view in view when resized.
This is part of the fix for these bugs, another other part is aosp/1964580.
This behavior still doesn't work as expected for lazy lists because the
focused item can be removed due to the resize before it has a chance to
be scrolled into view. Ralston's working on the necessary functionality
to fix this.
Design doc:
Bug:
Bug:
Fixes:
Test: ./gradlew :compose:f:f:cDAT
Relnote: "Scroll modifiers (`Modifier.verticalScroll()`,
`Modifier.horizontalScroll()`, and `Modifier.scrollable()`)
will now scroll to keep the focused composable visible if
the scroll area is resized and the focused composable was
previously visible."
Relnote: "TextFields will now be kept above the keyboard when they are
focused and the keyboard is shown, when inside a non-lazy
scrollable and the soft input mode is `ADJUST_RESIZE`."
Change-Id: I4a485a1c80aa2d500dcd55e916006903ff45da95
A compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/ScrollableFocusableInteractionTest.kt
M compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/FoundationDemos.kt
A compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/ScrollableFocusedChildDemo.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/Scrollable.kt
cr...@gmail.com <cr...@gmail.com> #74
ni...@gmail.com <ni...@gmail.com> #76
I still have issue with 1.2.0-alpha05, ADJUST_PAN and Landscape Orientation :
@Composable
private fun Screen() {
var textValue by remember {
mutableStateOf("")
}
Surface(Modifier.fillMaxSize()) {
Column(
horizontalAlignment = Alignment.CenterHorizontally, verticalArrangement = Arrangement.Center,
modifier = Modifier.fillMaxSize()
) {
Text(
text = "Title",
style = MaterialTheme.typography.h4,
textAlign = TextAlign.Start,
modifier = Modifier
.fillMaxWidth()
.fillMaxHeight(0.3f)
)
Spacer(modifier = Modifier.height(4.dp))
Text(
text = "Text\nTwo line",
style = MaterialTheme.typography.body2,
textAlign = TextAlign.Start,
modifier = Modifier
.fillMaxWidth()
.fillMaxHeight(0.2f)
)
Spacer(modifier = Modifier.height(16.dp))
TextField(
textStyle = MaterialTheme.typography.body2,
value = textValue,
onValueChange = {
textValue = it
},
modifier = Modifier
.fillMaxWidth()
.fillMaxHeight(),
colors = TextFieldDefaults.textFieldColors(
backgroundColor = Color.Blue,
textColor = MaterialTheme.colors.onSurface,
focusedIndicatorColor = MaterialTheme.colors.onSurface,
unfocusedIndicatorColor = Color.Transparent,
cursorColor = MaterialTheme.colors.onSurface
)
)
}
}
}
Click on the TextField and the field will be behind the keyboard. Be sure to force the orientation in landscape :
<activity
android:name=".MainActivity"
android:configChanges="keyboardHidden|uiMode|screenSize|screenLayout|orientation|colorMode|density|fontScale|fontWeightAdjustment|keyboard|layoutDirection|locale|mcc|mnc|navigation|smallestScreenSize|touchscreen"
android:exported="true"
android:label="@string/app_name"
android:launchMode="singleTop"
android:screenOrientation="landscape"
android:theme="@style/Theme.ComposeTextFieldLandscapeTest"
android:windowSoftInputMode="adjustPan">
Is it expected or still a bug ? It works if we adjust a vertical padding on Column (basically if the TextField is small "enough", it will be displayed above the keyboard). Maybe the issue is that the field is too big to be displayed above so it doesn't "scroll" to it ?
I'll push my sample on Github if required.
li...@gmail.com <li...@gmail.com> #77
What is the recommended workaround for this issue? I tried some of the ones posted above but it seems they have limitations and do not always work in my case.
co...@protonmail.com <co...@protonmail.com> #78
The fix should be in for non-lazy column in 1.2.0-alpha06
As per
"TextFields will now be kept above the keyboard when they are focused and the keyboard is shown, when inside a non-lazy scrollable and the soft input mode is ADJUST_RESIZE. (I4a485,
an...@gmail.com <an...@gmail.com> #79
I have this in the manifest:
<activity
android:windowSoftInputMode="adjustResize"
The Composable is inside a non-lazy scrollable like this:
Column(Modifier.verticalScroll(rememberScrollState())) {
OutlinedTextField(.....
Am I missing something else to get it to work?
be...@yescapa.com <be...@yescapa.com> #80
Or it is still required by accompagnist for edge to edge effect.
Am I missing something?
I checked the sample :
compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/text/TextFieldsInScrollableDemo.kt
And it's not working properly neither when setting off decor fits system windows and keyboard to ADJUST_RESIZE.
sl...@gmail.com <sl...@gmail.com> #81
My layout is
==== Header ====
--- scrollable column ---
==== Bottom Bar ====
If I set WindowCompat.setDecorFitsSystemWindows(window, false) then the text field in the scrollable column doesn't stay on screen
If I remove WindowCompat.setDecorFitsSystemWindows(window, false) and have ADJUST_RESIZE then the bottom controls are not covered by the IME
jo...@gmail.com <jo...@gmail.com> #82
ni...@google.com <ni...@google.com> #83
Compose status update: Please update the Status
and Status Summary
fields of this bug! (or Public Status
/Public Status Summary
)
te...@gmail.com <te...@gmail.com> #84
1.2.0-alpha07
works for me even with WindowCompat.setDecorFitsSystemWindows(window, false)
- I'm listening for insets in the activity and adding the ime ones as a bottom padding for the content FrameLayout findViewById(android.R.id.content)
.
My only question is how to specify an extra offset to scroll additionally when keyboard appears? Say you have a bottom navigation that may get in the way or implemented toolbar quick return pattern as the user scrolls and using offset on the scaffold content?
to...@gmail.com <to...@gmail.com> #85
kl...@google.com <kl...@google.com> #86
I can repro the case where adding newlines until the cursor goes below the IME does not cause a scroll, but that's a separate issue so I've filed it as
I can't repro the issue reported in #81. What device/android version/IME are you seeing this with?
ni...@gmail.com <ni...@gmail.com> #87
Should I report #76 in another issue ? it still happens in 1.2.0-alpha07 ; basically the text still goes below the IME if the TextField is too large to be visible entirely in the Rect above the IME. I have a working sample in the comment.
kl...@google.com <kl...@google.com> #88
Isn't that the same as
kl...@google.com <kl...@google.com> #89
Ok I can repro #81 on my Pixel 3 – ADJUST_RESIZE
, not fitting system windows. Will investigate.
kl...@google.com <kl...@google.com> #90
Filed the issue in #81 as
nu...@gmail.com <nu...@gmail.com> #91
Looks like compose won't be usable in production in another next year.
di...@gmail.com <di...@gmail.com> #92
This is unfair. Compose issues are getting worked on, and at a good pace (contrary to many AOSP core bugs).
This one was one of the more complex ones and I guess it was delayed due to priorities which to me seem more or less reasonable.
And Compose is very usable in production, we have already released several rather complex apps which use it extensively.
nu...@gmail.com <nu...@gmail.com> #93
What you doing, when QA, or (which is more scare) customer report that as problem? Tell them about other's p4 priorities on meetaps? Even when there are examples nearby that do not have such problems?
I'm even not talking about dozens of wasted hours to discover that there are no workarounds.
And users see that and treating it as a your bug. All of that lead to reputation loss at best.
We're talking about edittext, one of the basic elements for building a view. And it's problematic. As profesiional, i dont want to build to my customers buildings form crumbling bricks, whose manufacturer says "i fix it... well, maybe after all other things. Not important". I build it from bricks without that problems (because there are many problems other than multiline text editing)
On current stage compose is too fraught with loss of reputation, time and money, when you discover that things, no one which talking about in their "i use compose, and my life became better, hair became thicker, and blablabla" articles. And things gets even worse, when its you who advise command start new project on this. Problems and delays start to scale.
Its just not practical to waste no yourself money/time, no money of people, which paid your fo work and solutions.
di...@gmail.com <di...@gmail.com> #94
All issues we've run into with QA (including this one) were fixable with workarounds. Also Compose devs provide good support/advice on them in kotlinlang's slack #compose channel. And doing workarounds for Compose issues is a lot more easier/pleasant than doing ones for a View-based system.
Anyways, I think this is not the discussion for the issue tracker.
sa...@gmail.com <sa...@gmail.com> #95
it's not production ready at all. also adding workaround is not easy.
If you are using some framework, it should work as expected.
You shouldn't learn internals of that framework and work lots of days to fix issues in framework.
This edit text and keyboard behaviour is a basic thing.
They should have moved it to stable only after fixing such basic issues.
They are hurried up. Some internal politics probably. CameraX is a good example.
They have kept it in beta for a long time. Like that, they should have kept compose in beta until those issues are getting resolved.
sk...@gmail.com <sk...@gmail.com> #96
Powerful tools may come with a bit of a steep learning curve (and to be honest, Compose ain't all that hard), but once that's done, you benefit from amazing possibilities and powers.
Regarding bugs, I don't see how Compose is any more buggy than the View system. As with any complex project, bugs are simply inevitable. It is indeed a new thing, and may still need some work to mature, but that's why there's Compose/View interop.
I use Compose mainly and I barely have to fix anything. If I don't like a default behavior, I don't have to sift through a 1000-line Custom View Java file, but I can simply copy the underlying Composable function, which is usually very simple and easy to understand, and change whatever I want easily.
And yes, I've already produced some rather complex apps with Compose, and actually used it for some weird use cases that I think are simply too hard to be worth it with Views, and yet Compose helped me create them reliably and easily exactly as I wanted (and even more than I wanted) down to individual pixels and even the small nuances in animations, shapes, and behavior, with code that's maintainable, short, and dare I say it, beautiful.
And at the end of the day, if you don't like it, don't use it. Google did not force anyone to use Compose, and all of its hype is well-deserved, aired by the Android Developer community at large.
Anyways, this is not the place to fight over this. If you have anything to help with this specific issue, you're welcome to provide your feedback. Otherwise you can go on Twitter or Reddit and do destructive criticism as much as you please, while developers here are building the next big thing.
kl...@google.com <kl...@google.com> #97
I don't have any updates about fixes yet, but I understand the frustration about this issue and it is definitely being worked on. It's not actually a P4 – the "Priority" field on buganizer is very misleading, it has a very specific internal meaning and interaction with other systems so we don't use it for actual prioritization for compose text issues. Unfortunately, the way we track actual priority is not visible externally.
sa...@gmail.com <sa...@gmail.com> #98
ja...@gmail.com <ja...@gmail.com> #99
sh...@gmail.com <sh...@gmail.com> #100
//Library
implementation("com.google.accompanist:accompanist-insets:0.24.9-beta")
//Add this to your activity In AndroidManifest
android:windowSoftInputMode="stateVisible|adjustResize">
//Just add contentPadding in LazyColumn as -
LazyColumn(
contentPadding = rememberInsetsPaddingValues(
insets = LocalWindowInsets.current.systemBars,
applyTop = true,
applyBottom = true,
)
) {
//TextField and other widgets
}
bl...@gmail.com <bl...@gmail.com> #101
I'm using 1.2.0-beta03
and trying to make this work for a TextField
inside a Row
.
Even while using one of the workarounds, the functionality doesn't work most of the time in landscape mode, and seems to not work in certain cases in portrait mode (perhaps when the keyboard pops up a second or later time and making certain types of edits).
@OptIn(ExperimentalFoundationApi::class, ExperimentalComposeUiApi::class)
@Composable
fun EnterText() {
Row(
modifier = Modifier
.fillMaxWidth(),
verticalAlignment = Alignment.CenterVertically,
horizontalArrangement = Arrangement.Center,
)
{
val relocation = remember { BringIntoViewRequester() }
val scope = rememberCoroutineScope()
var thoughts by rememberSaveable { mutableStateOf("") }
TextField(
value = thoughts,
modifier = Modifier
.weight(1f)
.bringIntoViewRequester(relocation)
.onFocusEvent {
if (it.isFocused) scope.launch { delay(300); relocation.bringIntoView() }
},
label = { Text(text = "Enter text") },
keyboardOptions = KeyboardOptions(keyboardType = KeyboardType.Text),
onValueChange = { newText ->
thoughts = newText
}
)
}
}
xa...@gmail.com <xa...@gmail.com> #102
kl...@google.com <kl...@google.com> #103
Nothing to announce yet, but we are working very actively on this.
ab...@gmail.com <ab...@gmail.com> #104
Please try to fix this on Priority, as going for hit & trial several times with the code and even after that not getting the expected workable solution is frustrating.
he...@gmail.com <he...@gmail.com> #105
wi...@azimo.com <wi...@azimo.com> #106
si...@gmail.com <si...@gmail.com> #107
Read the comment number 40. I use this workaround in production, with about 1M users.
da...@gmail.com <da...@gmail.com> #108
I realized I never posted my workaround for this.
It's actually on an old version of Compose but used to work very reliably
val relocationRequester = remember { RelocationRequester() }
var focused by remember { mutableStateOf(false) }
val ime = LocalWindowInsets.current.ime
LaunchedEffect(focused) {
if (focused) {
var done = false
while (!done) {
if (ime.isVisible && !ime.animationInProgress) {
relocationRequester.bringIntoView()
done = true
}
delay(100L)
}
}
}
TextField(
modifier = Modifier
// ...
.onFocusChanged { focused = it }
// ...
)
I'm not sure if it still works with latest version because I didn't need it in recent projects yet and I haven't been working on the other one for several months.
I first posted it in this slack conversation
ar...@gmail.com <ar...@gmail.com> #109
xa...@gmail.com <xa...@gmail.com> #110
re...@googlemail.com <re...@googlemail.com> #111
wa...@gmail.com <wa...@gmail.com> #112
Let's say I have a sticky footer (bottom navigation) , Now when I type the text field will go below the bottom navigation even though I want it to be above it , so please fix that as well !
st...@google.com <st...@google.com> #113
#112 you think it's worth creating a new issue with a repro on that and we can link to this bug if they're related? just to add to the test cases to verify
wa...@gmail.com <wa...@gmail.com> #114
#113 Yeah , great !
wa...@gmail.com <wa...@gmail.com> #116
I have a question , Do I need to use BringIntoViewRequester or the textfield will be kept in view without me writing any code ? Like Do I need to do anything ?
il...@gmail.com <il...@gmail.com> #117
il...@gmail.com <il...@gmail.com> #118
st...@google.com <st...@google.com> #119
Hi there. This issue is not dead, and it is not fixed in production yet. It remains high priority for us and we're actively working on fixing it. However it is caused by a very complex combination of dependencies and the fix is not trivial. We've most recently been focusing on
ap...@google.com <ap...@google.com> #120
Branch: androidx-main
commit 7e77bb541331ce0d62cabad732e43eca41ac978a
Author: Zach Klippenstein <klippenstein@google.com>
Date: Wed Jul 06 11:42:21 2022
Move BringIntoView queueing into the scrollable implementation.
This change removes the over-complicated coroutine-based queuing of
bringIntoView requests in the BringIntoViewResponder, which now is only
responsible for dispatching the request to the actual responder
interface and propagating it up the modifier local chain.
This gives the actual responder implementation (i.e. in
Modifier.scrollable) all the information about conflicting
requests and manage the queue of ongoing requests with an actual,
explicit queue that is much more straightforward than the previous
coroutine job chaining mess. Each request is stored in an actual list
along with the continuation from the request, and requests are
explicitly resumed or cancelled when needed. This also makes debugging
easier, because there's an actual queue data structure we can inspect,
which contains all the actual information about each request.
It also completely changes how the scroll animation is performed.
On every frame, the scroll target is recomputed to account for
changes in the viewport size, the request size, or the set of active
requests since the last frame, while still keeping the animation
smooth. The animation logic is in its own class, which allows a single
suspend animation call to animate to a target value that can be updated
while the animation is running.
While this change is a valuable cleanup on its own, it also fixes
focused child tracking with an explicit API for keeping a thing in view.
Fixes:
Bug:
Bug:
Bug:
Bug:
Test: ScrollableFocusableInteractionTest
Test: androidx.compose.foundation.relocation.*
Test: RebasableAnimationStateTest
Test: BringIntoViewRequestPriorityQueueTest
Relnote: "Rewrote the way scrollables respond to
`bringIntoViewRequesters` and focusables to better model the
complexity of those operations and handle more edge cases."
Change-Id: I2e5fec8c8582a8fe1f191e37fd0f4f9165678664
M compose/foundation/foundation/api/current.txt
M compose/foundation/foundation/api/public_plus_experimental_current.txt
M compose/foundation/foundation/api/restricted_current.txt
M compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/FoundationDemos.kt
M compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/ScrollableFocusedChildDemo.kt
A compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/relocation/BringIntoViewResponderDemo.kt
M compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/relocation/BringRectangleIntoViewDemo.kt
M compose/foundation/foundation/samples/src/main/java/androidx/compose/foundation/samples/BringIntoViewSamples.kt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/ScrollableFocusableInteractionTest.kt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/lazy/list/LazyListFocusMoveTest.kt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/relocation/BringIntoViewResponderTest.kt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/relocation/BringIntoViewScrollableInteractionTest.kt
A compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/BringIntoViewRequestPriorityQueue.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/ContentInViewModifier.kt
A compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/UpdatableAnimationState.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/relocation/BringIntoViewResponder.kt
A compose/foundation/foundation/src/test/kotlin/androidx/compose/foundation/gestures/BringIntoViewRequestPriorityQueueTest.kt
A compose/foundation/foundation/src/test/kotlin/androidx/compose/foundation/gestures/UpdatableAnimationStateTest.kt
kl...@google.com <kl...@google.com> #121
Major fixes to this were just released in 1.4.0-alpha04. Text fields in lazy columns should work now too. One notable case that is still being worked on is if
ja...@gmail.com <ja...@gmail.com> #122
ATAL EXCEPTION: main
Process: com.example.textboxresearch, PID: 15827
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:558)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)
Caused by: java.lang.reflect.InvocationTargetException
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)
Caused by: java.lang.reflect.InvocationTargetException
at java.lang.reflect.Method.invoke(Native Method)
at androidx.compose.ui.tooling.ComposableInvoker.invokeComposableMethod(ComposableInvoker.kt:163)
at androidx.compose.ui.tooling.ComposableInvoker.invokeComposable(ComposableInvoker.kt:203)
at androidx.compose.ui.tooling.PreviewActivity$setComposableContent$2.invoke(PreviewActivity.kt:77)
at androidx.compose.ui.tooling.PreviewActivity$setComposableContent$2.invoke(PreviewActivity.kt:76)
at androidx.compose.runtime.internal.ComposableLambdaImpl.invoke(ComposableLambda.jvm.kt:107)
at androidx.compose.runtime.internal.ComposableLambdaImpl.invoke(ComposableLambda.jvm.kt:34)
at androidx.compose.ui.platform.ComposeView.Content(ComposeView.android.kt:428)
at androidx.compose.ui.platform.AbstractComposeView$ensureCompositionCreated$1.invoke(ComposeView.android.kt:252)
at androidx.compose.ui.platform.AbstractComposeView$ensureCompositionCreated$1.invoke(ComposeView.android.kt:251)
at androidx.compose.runtime.internal.ComposableLambdaImpl.invoke(ComposableLambda.jvm.kt:107)
at androidx.compose.runtime.internal.ComposableLambdaImpl.invoke(ComposableLambda.jvm.kt:34)
at androidx.compose.runtime.CompositionLocalKt.CompositionLocalProvider(CompositionLocal.kt:228)
at androidx.compose.ui.platform.CompositionLocalsKt.ProvideCommonCompositionLocals(CompositionLocals.kt:177)
at androidx.compose.ui.platform.AndroidCompositionLocals_androidKt$ProvideAndroidCompositionLocals$3.invoke(AndroidCompositionLocals.android.kt:123)
at androidx.compose.ui.platform.AndroidCompositionLocals_androidKt$ProvideAndroidCompositionLocals$3.invoke(AndroidCompositionLocals.android.kt:122)
at androidx.compose.runtime.internal.ComposableLambdaImpl.invoke(ComposableLambda.jvm.kt:107)
at androidx.compose.runtime.internal.ComposableLambdaImpl.invoke(ComposableLambda.jvm.kt:34)
at androidx.compose.runtime.CompositionLocalKt.CompositionLocalProvider(CompositionLocal.kt:228)
at androidx.compose.ui.platform.AndroidCompositionLocals_androidKt.ProvideAndroidCompositionLocals(AndroidCompositionLocals.android.kt:114)
at androidx.compose.ui.platform.WrappedComposition$setContent$1$1$3.invoke(Wrapper.android.kt:157)
at androidx.compose.ui.platform.WrappedComposition$setContent$1$1$3.invoke(Wrapper.android.kt:156)
at androidx.compose.runtime.internal.ComposableLambdaImpl.invoke(ComposableLambda.jvm.kt:107)
at androidx.compose.runtime.internal.ComposableLambdaImpl.invoke(ComposableLambda.jvm.kt:34)
at androidx.compose.runtime.CompositionLocalKt.CompositionLocalProvider(CompositionLocal.kt:228)
at androidx.compose.ui.platform.WrappedComposition$setContent$1$1.invoke(Wrapper.android.kt:156)
at androidx.compose.ui.platform.WrappedComposition$setContent$1$1.invoke(Wrapper.android.kt:140)
at androidx.compose.runtime.internal.ComposableLambdaImpl.invoke(ComposableLambda.jvm.kt:107)
at androidx.compose.runtime.internal.ComposableLambdaImpl.invoke(ComposableLambda.jvm.kt:34)
at androidx.compose.runtime.ActualJvm_jvmKt.invokeComposable(ActualJvm.jvm.kt:78)
at androidx.compose.runtime.ComposerImpl$doCompose$2$5.invoke(Composer.kt:3314)
at androidx.compose.runtime.ComposerImpl$doCompose$2$5.invoke(Composer.kt:3304)
at androidx.compose.runtime.SnapshotStateKt__DerivedStateKt.observeDerivedStateRecalculations(DerivedState.kt:341)
at androidx.compose.runtime.SnapshotStateKt.observeDerivedStateRecalculations(Unknown Source:1)
2023-01-12 17:38:35.171 15827-15827 AndroidRuntime com.example.textboxresearch E at androidx.compose.runtime.ComposerImpl.doCompose(Composer.kt:3304)
at androidx.compose.runtime.ComposerImpl.composeContent$runtime_release(Composer.kt:3239)
at androidx.compose.runtime.CompositionImpl.composeContent(Composition.kt:587)
at androidx.compose.runtime.Recomposer.composeInitial$runtime_release(Recomposer.kt:967)
at androidx.compose.runtime.CompositionImpl.setContent(Composition.kt:519)
at androidx.compose.ui.platform.WrappedComposition$setContent$1.invoke(Wrapper.android.kt:140)
at androidx.compose.ui.platform.WrappedComposition$setContent$1.invoke(Wrapper.android.kt:131)
at androidx.compose.ui.platform.AndroidComposeView.setOnViewTreeOwnersAvailable(AndroidComposeView.android.kt:1089)
at androidx.compose.ui.platform.WrappedComposition.setContent(Wrapper.android.kt:131)
at androidx.compose.ui.platform.WrappedComposition.onStateChanged(Wrapper.android.kt:182)
at androidx.lifecycle.LifecycleRegistry$ObserverWithState.dispatchEvent(LifecycleRegistry.kt:314)
at androidx.lifecycle.LifecycleRegistry.addObserver(LifecycleRegistry.kt:192)
at androidx.compose.ui.platform.WrappedComposition$setContent$1.invoke(Wrapper.android.kt:138)
at androidx.compose.ui.platform.WrappedComposition$setContent$1.invoke(Wrapper.android.kt:131)
at androidx.compose.ui.platform.AndroidComposeView.onAttachedToWindow(AndroidComposeView.android.kt:1176)
at android.view.View.dispatchAttachedToWindow(View.java:20753)
at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:3490)
at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:3497)
at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:3497)
at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:3497)
at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:3497)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:2613)
at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2126)
at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:8658)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1037)
at android.view.Choreographer.doCallbacks(Choreographer.java:845)
at android.view.Choreographer.doFrame(Choreographer.java:780)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1022)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loopOnce(Looper.java:201)
at android.os.Looper.loop(Looper.java:288)
at android.app.ActivityThread.main(ActivityThread.java:7839)
... 3 more
Caused by: java.lang.NoSuchFieldError: No static field $stable of type I in class Landroidx/compose/foundation/text/KeyboardActions; or its superclasses (declaration of 'androidx.compose.foundation.text.KeyboardActions' appears in /data/app/~~TC_W8Fki2PnCjomqRoVwJA==/com.example.textboxresearch-Ekc572auvJyczWtc91Ptug==/base.apk)
at androidx.compose.material.TextFieldKt.TextField(TextField.kt:207)
at com.example.textboxresearch.TestKt.CheckTest(Test.kt:29)
... 70 more
st...@google.com <st...@google.com> #123
You mean an OutlinedTextField? Can you share the snippet?
ja...@gmail.com <ja...@gmail.com> #124
kl...@google.com <kl...@google.com> #125
Can you please attach a video of BasicTextField
still going under the IME? And repro code if possible.
ja...@gmail.com <ja...@gmail.com> #126
kl...@google.com <kl...@google.com> #127
Ah, that's
wa...@gmail.com <wa...@gmail.com> #128
I am getting the same crash , waiting for next release , please release that fast
bl...@gmail.com <bl...@gmail.com> #129
Major fixes to this were just released in 1.4.0-alpha04
Major bugs were also released...
java.lang.NoSuchFieldError: No static field $stable of type I in class Landroidx/compose/foundation/text/KeyboardActions; or its superclasses (declaration of 'androidx.compose.foundation.text.KeyboardActions' appears in /data/app/~~xxx/base.apk)
at androidx.compose.material3.TextFieldKt$TextField$5.invoke(TextField.kt:343)
at androidx.compose.material3.TextFieldKt$TextField$5.invoke(TextField.kt:323)
at androidx.compose.runtime.internal.ComposableLambdaImpl.invoke(ComposableLambda.jvm.kt:107)
at androidx.compose.runtime.internal.ComposableLambdaImpl.invoke(ComposableLambda.jvm.kt:34)
at androidx.compose.runtime.CompositionLocalKt.CompositionLocalProvider(CompositionLocal.kt:228)
at androidx.compose.material3.TextFieldKt.TextField(TextField.kt:323)
st...@google.com <st...@google.com> #130
The crash above is reported here with workaround:
wa...@gmail.com <wa...@gmail.com> #131
so I upgraded to material 3 alpha04 and now I am not getting the Crash BUT I am still getting the text field going under the keyboard , I will post a video about it My TextField does take full width , is multiline but unless the user presses enter , it remains single lined , When I tap on the text field , the keyboard comes from underneath and stays on top of the field I don't use BringIntoViewRequester or any other code to bring it into view , I expect it to work magically.
ja...@gmail.com <ja...@gmail.com> #132
kl...@google.com <kl...@google.com> #133
Can you confirm you're also using Foundation version 1.4.0-alpha04? The bug was fixed in Foundation, not Material, and while material3 1.1.0-alpha04 should be using the latest alpha, I just want to make sure it actually is in your project. A video would be helpful, thanks.
ja...@gmail.com <ja...@gmail.com> #134
wa...@gmail.com <wa...@gmail.com> #135
I created a sample project and recorded this video , apparently the keyboard is opening and text field staying above when I tap on the field but not for long , when the text field becomes multiline , the text goes below keyboard
wa...@gmail.com <wa...@gmail.com> #136
This project using latest compose version
1.1.0-alpha04 for material 3
Compose version 1.4.0-alpha04 , UI , which should probably including foundation of the same version
kl...@google.com <kl...@google.com> #137
That's also
wa...@gmail.com <wa...@gmail.com> #138
So if I apply a fixed height , would it work ?
kl...@google.com <kl...@google.com> #139
Actually I think this might be a separate bug, since the resized field isn't internally scrollable. I filed
kl...@google.com <kl...@google.com> #140
We are closing this issue since the main case for this bug has been fixed: fixed-size text fields inside scrollable Column
s and LazyColumn
s will be kept above the keyboard when they gain focus and the keyboard becomes shown and would otherwise cover the field.
There are still some cases related to this that are still broken and being worked on, but those will be tracked in separate bugs going forward. The known remaining issues at this time are:
- Cursors in text fields that take all available space and are internally scrollable may disappear behind the keyboard (
)b/237190748 - Text fields that grow taller while being edited aren’t kept above the keyboard (
)b/266094055 - Crash with “No field $stable of type I in class Landroidx/compose/foundation/text/KeyboardActions” (
)b/265172081 - Text fields will stay below the keyboard when inside LazyVerticalGrid (
)b/265352893
Please follow those individual bugs for further updates.
If you find new issues, please
Description
If you put the Text Field Composable inside Lazy Column / Scrollable Column , Even After using the Insets / Content Padding on the Lazy Column / Scrollable Column
The Text goes below the keyboard Because Of The Scroll State
Since when the IME Opens the Ime comes above the Text And The Scroll State Would Remain the Same Lazy Column Wouldn't Scroll so the Text Would Remain Visible (Above Keyboard)