Status Update
No update yet.
Comments
il...@google.com
seems to be dup:
yo...@luchegroup.com
Fundamentally the issue here is that the selection logic happening in composition depends on the text layout result which is available on measure. So we end up using stale TextLayoutResult which causes the issue.
il...@google.com
This is the same exception as in
ap...@google.com
There is a similar problem regarding Magnifier but I don't think these are directly related. The main cause for this issue is the async relation between TextFieldValue and layoutResult. Magnifier related crashes don't seem to be caused by changes in TextFieldValue or layout.
jb...@google.com
Branch: androidx-main
commit c1e913cdea06ac6cf01c596000d375013f1a1d7c
Author: Halil Ozercan <halilibo@google.com>
Date: Thu Jun 23 13:51:14 2022
Fix crash when selected text is cleared by state changes and re-added later
BasicTextField's String API manages the selection and composition completely internally. Therefore, its selection value stays the same across value changes that comes from hoisted state, instead of IME commands. In a case where selected text is removed by a state change and later added, text layout result lags behind. This change makes sure that selection handles are only drawn when layout result is in sync with the latest TextFieldValue.
Fix:
Fix:
Test: CoreTextFieldSelectionContentChangeTest.kt
Relnote: Fixed a crash where TextField is cleared and refilled while selection is active.
Change-Id: I1235b669921e67dcbec9e55a6d1a95ff609fe4b6
A compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/text/CoreTextFieldSelectionContentChangeTest.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/CoreTextField.kt
ju...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.fragment:fragment:1.6.0-alpha04
yo...@luchegroup.com
Thanks for the bug fix, I have confirmed that the issue is resolved.
eu...@gmail.com
We have a crash now with this change:
java.lang.IllegalStateException: enableSavedStateHandles() wasn't called prior to createSavedStateHandle() call
at androidx.lifecycle.SavedStateHandleSupport.getSavedStateHandlesProvider(SavedStateHandleSupport.kt:115)
at androidx.lifecycle.SavedStateHandleSupport.createSavedStateHandle(SavedStateHandleSupport.kt:65)
at androidx.lifecycle.SavedStateHandleSupport.createSavedStateHandle(SavedStateHandleSupport.kt:103)
at androidx.lifecycle.AbstractSavedStateViewModelFactory.create(AbstractSavedStateViewModelFactory.java:89)
at dagger.hilt.android.internal.lifecycle.HiltViewModelFactory.create(HiltViewModelFactory.java:116)
at androidx.lifecycle.ViewModelProvider.get(ViewModelProvider.kt:187)
at androidx.lifecycle.ViewModelProvider.get(ViewModelProvider.kt:153)
at androidx.lifecycle.viewmodel.compose.ViewModelKt.get(ViewModel.kt:215)
at androidx.lifecycle.viewmodel.compose.ViewModelKt.viewModel(ViewModel.kt:156)
at our.code. (points to the place where the ViewModel is injected into a constructor of a Composable view
What we do in the composable code we call viewModel like:
val extras = MutableCreationExtras()
extras[SAVED_STATE_REGISTRY_OWNER_KEY] = LocalSavedStateRegistryOwner.current
extras[VIEW_MODEL_STORE_OWNER_KEY] = checkNotNull(LocalViewModelStoreOwner.current) {
"No ViewModelStoreOwner was provided via LocalViewModelStoreOwner"
}
extras[DEFAULT_ARGS_KEY] = bundleOf("PARAM_KEY" to "PARAM_VALUE")
return viewModel(extras = extras)
I see that enableSavedStateHandles was deleted from FragmentViewLifecycleOwner.
Can you give some recommendations about situation?
jb...@google.com
Please file a separate bug with a minimal sample project that reproduces this issue.
Description
Devices/Android versions reproduced on: Nothing A063 running Android 12
PoC project:
When saving the ViewModel state object using SavedStateHandle, the object is stored in the Bundle of the FragmentState.
The issue is that the Bundle contains 2 identical ViewModel state object with different keys(`androidx.lifecycle.internal.SavedStateHandlesProvider` and `androidx.lifecycle.BundlableSavedStateRegistry.key`), so it takes up twice as much as the ViewState object size. If the ViewState object size gets bigger, it can easily cause `TransactionTooLargeException` whereas the single ViewState size is small enough to fit in the Bundle limit.