Status Update
No update yet.
Comments
si...@google.com
Hi,
I also see my text cut off when I set maxLines = 2. Is it the same issue?
Box(
modifier =
Modifier.size(
width = 108dp,
height = 34dp,
),
contentAlignment = Alignment.Center,
) {
BasicText(
text = "text text text",
maxLines = 2,
autoSize = AutoSize.StepBased(minFontSize = 1.sp, maxFontSize = 13.sp, stepSize = 0.2.sp),
)
}
tc...@google.com
Project: platform/frameworks/support
Branch: androidx-main
Author: Jossi Wolf <
Link:
Fix TextAutoSize bug with maxLines = 1
Expand for full commit details
Fix TextAutoSize bug with maxLines = 1
We were overcaching the paragraphIntrinsics in MultiParagraphLayoutCache when mutating the style. For `AutoSizeStepBased` instances with biased windows (more values smaller/bigger than the optimal), this could result in performing layout with outdated intrinsics, and thus an outdated style and font size, without surfacing this in the TextLayoutResult.
Test: New MultiParagraphLayoutCacheTests and manual testing
Relnote: Fixed a bug in BasicText with TextAutoSize and maxLines set to 1.
Fixes: 376834366
Change-Id: Ic0450c763c5d764492995b44ee1fe570246a9689
Files:
- M
compose/foundation/foundation/src/androidInstrumentedTest/kotlin/androidx/compose/foundation/text/modifiers/MultiParagraphLayoutCacheTest.kt - M
compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/modifiers/MultiParagraphLayoutCache.kt
Hash: e1b712d78cc60384ed67a56c006148291ba146a6
Date: Tue Jan 07 18:52:26 2025
si...@google.com
si...@google.com
si...@google.com
se...@google.com
ap...@google.com
#2, yeah, that's the same issue.
se...@google.com
se...@google.com
ap...@google.com
Thanks @jo...@google.com for fixing this! Do you know when the fix would be available for g3 apps?
ap...@google.com
Moving the internal discussion offline. The bug is fixed and the fix available in snapshot builds. We will comment on this issue when the bug fix is included in a release.
ap...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.foundation:foundation:1.8.0-beta01androidx.compose.foundation:foundation-android:1.8.0-beta01androidx.compose.foundation:foundation-jvmstubs:1.8.0-beta01androidx.compose.foundation:foundation-linuxx64stubs:1.8.0-beta01
Description
Specifically, a user wanted to "close the software keyboard in onClick on a button", and Fudge's workaround was to capture the SoftwareKeyboardController in the onTextInputStarted callback and write it into a field in the parent. var controller by remember { mutableStateOf<SoftwareKeyboardController?> { null } } Button("Close", onClick={controller!!.hideSoftwareKeyboard()}) // Pray this doesn't crash (NPE) TextField(value=..., onClick=..., onTextInputStarted={c -> controller = c})
A better pattern would be to have the user create a SoftwareKeyboardController as-if it were a hoisted state object and pass it into the TextField. val controller by remember { SoftwareKeyboardController() } Button("Close", onClick={controller.hideSoftwareKeyboard()}) TextField(value=..., onClick=..., controller=controller)
We realize/expect this requires playing a bit of a trick with the internal implementation of the SoftwareKeyboardController, to make the hideSoftwareKeyboard() function capable of operating as if it were the source of truth, even though the actual source of truth doesn't exist until later when the TextField is initialized by Android, which is probably one reason why it didn't occur to the original author of this widget. But it results in a much cleaner declarative API with less reasoning about the flow of information.
Discussion in API Council back in August, but I don't think a bug ever got filed for this.