Fixed
Status Update
No update yet.
Comments
jo...@google.com
Fatal Exception: java.lang.IllegalArgumentException: offset(9) is out of bounds [0, 8]
at androidx.compose.ui.text.MultiParagraph.requireIndexInRangeInclusiveEnd(MultiParagraph.kt:593)
at androidx.compose.ui.text.MultiParagraph.getCursorRect(MultiParagraph.java:442)
at androidx.compose.ui.text.TextLayoutResult.getCursorRect(TextLayoutResult.kt:390)
at androidx.compose.foundation.text.TextFieldScrollKt.getCursorRectInScroller(TextFieldScrollKt.java:207)
at androidx.compose.foundation.text.TextFieldScrollKt.access$getCursorRectInScroller(TextFieldScrollKt.java:1)
at androidx.compose.foundation.text.HorizontalScrollLayoutModifier$measure$1.invoke(TextFieldScroll.kt:179)
at androidx.compose.foundation.text.HorizontalScrollLayoutModifier$measure$1.invoke$bridge(TextFieldScroll.kt:12)
at androidx.compose.foundation.text.HorizontalScrollLayoutModifier$measure$1.invoke(TextFieldScroll.kt:178)
at androidx.compose.foundation.text.HorizontalScrollLayoutModifier$measure$1.invoke$bridge(TextFieldScroll.kt:27)
at androidx.compose.ui.layout.MeasureScope$layout$1.placeChildren(MeasureScope.kt:68)
pr...@google.com
It's hard to tackle the issue without a repro, I couldn't reproduce the crash using Compose's demo app.
It would help if you provide a repro, or at least a code of how the text field is used in your app.
jo...@google.com
I havent seen this issue for a couple of weeks now. Perhaps it was fixed thanks to some other set of fixes? Im currently using compose 1.2.0-alpha01.
Beyond that, I have no idea what might have been triggering this. The only thing that stands out to me is that my VisualTransformation also handles cases 0-8, so it could be related to that? Im using one text field composable everywhere (from the design system); but the stack-trace doesnt really point to any specific screen, so I dont think that helps much.
Edit: Seems like I jinxed it, the issue just popped up in my crashlytics logs again this afternoon.
Beyond that, I have no idea what might have been triggering this. The only thing that stands out to me is that my VisualTransformation also handles cases 0-8, so it could be related to that? Im using one text field composable everywhere (from the design system); but the stack-trace doesnt really point to any specific screen, so I dont think that helps much.
Edit: Seems like I jinxed it, the issue just popped up in my crashlytics logs again this afternoon.
ma...@google.com
Ive managed to recreate this!
My setup is as follows;
Scaffold contains a pager, and a bottom bar with a couple of text fields. Whenever the page changes, the text is updated to reflect the text thats assigned to the given page.
If I input some text, long press it so that the selection handles are visible, swipe to the next page (which effectively clears the text, and dismisses the selection handle); and then swipe back, the crash happens, presumably because the state has the selection handles visible, but the text no longer being available, hence the out of bounds crash.
My setup is as follows;
Scaffold contains a pager, and a bottom bar with a couple of text fields. Whenever the page changes, the text is updated to reflect the text thats assigned to the given page.
If I input some text, long press it so that the selection handles are visible, swipe to the next page (which effectively clears the text, and dismisses the selection handle); and then swipe back, the crash happens, presumably because the state has the selection handles visible, but the text no longer being available, hence the out of bounds crash.
al...@google.com
Thanks for more details.
pr...@google.com
Related to
ap...@google.com
I also experienced this. I created this ticket and it's most likely related:
ap...@google.com
I think
pr...@google.com
Project: platform/frameworks/support
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
https://android-review.googlesource.com/2133687
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
Description
The following Experimental APIs have existed for several releases.
Please consider stabilising or removing these APIs: