Repository navigation
Open
Labels
Description
Description
Even when there is no need to shrink the font, there is sometimes a difference in the font sized used when adjustsFontSizeToFit is true vs. when it is false (or not included as a prop on a <Text> component). In other words, the font size is reduced when it should not be. This problem was introduced by the fix for #54715.
Specific font sizes needed to show this bug vary depending on the dp-to-font ratio of the test system or emulator, which points to rounding as the root cause of this bug.
Steps to reproduce
- Use two components, one with
adjustsFontSizeToFit={true}and one without. - Experiment with different
fontSizevalues until you find one or more where the rendered size differs (even though there is no need to reduce the font to accommodate the text).
The provided reproducer demonstrates the problem.
React Native Version
0.85.2
Affected Platforms
Runtime - Android
Output of npx @react-native-community/cli info
info Fetching system and libraries information...
System:
OS: macOS 15.7.5
CPU: (16) x64 Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz
Memory: 829.41 MB / 40.00 GB
Shell:
version: "5.9"
path: /bin/zsh
Binaries:
Node:
version: 24.11.1
path: /Users/USER/.nvm/versions/node/v24.11.1/bin/node
Yarn:
version: 1.22.22
path: /Users/USER/.nvm/versions/node/v24.11.1/bin/yarn
npm:
version: 11.6.2
path: /Users/USER/.nvm/versions/node/v24.11.1/bin/npm
Watchman:
version: 2026.03.30.00
path: /usr/local/bin/watchman
Managers:
CocoaPods:
version: 1.16.2
path: /usr/local/bin/pod
SDKs:
iOS SDK:
Platforms:
- DriverKit 25.2
- iOS 26.2
- macOS 26.2
- tvOS 26.2
- visionOS 26.2
- watchOS 26.2
Android SDK:
API Levels:
- "27"
- "28"
- "29"
- "30"
- "31"
- "34"
- "35"
- "36"
- "36"
Build Tools:
- 30.0.3
- 31.0.0
- 33.0.0
- 33.0.2
- 34.0.0
- 35.0.0
- 35.0.1
- 36.0.0
System Images:
- android-27 | Google APIs Intel x86 Atom
- android-27 | Google Play Intel x86 Atom
- android-29 | Google APIs Intel x86 Atom
- android-30 | Google Play Intel x86 Atom
- android-31 | Google Play Intel x86 Atom_64
- android-34 | Google APIs Intel x86_64 Atom
- android-34 | Google Play Intel x86_64 Atom
- android-35 | Google Play Intel x86_64 Atom
- android-36.1 | Google Play Intel x86_64 Atom
Android NDK: Not Found
IDEs:
Android Studio: Not Found
Xcode:
version: 26.2/17C52
path: /usr/bin/xcodebuild
Languages:
Java:
version: 17.0.10
path: /usr/bin/javac
Ruby:
version: 2.6.10
path: /usr/bin/ruby
npmPackages:
"@react-native-community/cli":
installed: 20.1.0
wanted: 20.1.0
react:
installed: 19.2.3
wanted: 19.2.3
react-native:
installed: 0.85.2
wanted: 0.85.2
react-native-macos: Not Found
npmGlobalPackages:
"*react-native*": Not Found
Android:
hermesEnabled: true
newArchEnabled: true
iOS:
hermesEnabled: true
newArchEnabled: true
info React Native v0.85.3 is now available (your project is running on v0.85.2).
info Changelog: https://github.com/facebook/react-native/releases/tag/v0.85.3
info Diff: https://react-native-community.github.io/upgrade-helper/?from=0.85.2&to=0.85.3
info For more info, check out "https://reactnative.dev/docs/upgrading?os=macos".
Stacktrace or Logs
N/A
MANDATORY Reproducer
Screenshots and Videos
Notice the text rendering differences for the following font sizes: 10, 11, 18, 22.

Reacted by Andrea Martinez and Denys Galkin
Activity
danyalahmed1995 commentedon May 13, 2026
Thanks for the clear repro and the note about #54715.
I opened a small fix in #56815. The patch adds an initial fit check before the Android
adjustsFontSizeToFitpath enters the binary-search resize loop. If the original layout already satisfies the same constraints, it returns without mutatingTextPaintorReactAbsoluteSizeSpan, so text that already fits should keep its original size.I also added a focused Robolectric test for the no-resize case.
MarkCSmith commentedon May 14, 2026
Thank you. I have not tried your patch, but it looks like you changed all of the line endings in
TextLayoutManager.kt. I think the idea behind the patch is a nice optimization and will likely solve most of the problems caused by this bug, but it would be good to fix the compounding of error (due to rounding) that seems to be taking place in the loop.danyalahmed1995 commentedon May 14, 2026
Apologies , thank you for the correction I had the files open in another editor and didn’t notice it converted the line endings.
I updated #56815 to remove the line-ending churn in
TextLayoutManager.kt. The visible diff should now only include the actual code changes.I also kept the initial “already fits” check and updated the resize loop to avoid truncating during scaling, so the rounding/drift issue is addressed directly as well. Added test coverage for both the no-resize case and the rounding path.
danyalahmed1995 commentedon May 14, 2026
Updated #56815 again with a clean branch from
upstream/main.The previous force-push still carried the line-ending churn in
TextLayoutManager.kt, so I rebuilt the branch cleanly and force-pushed it over the PR branch. The diff should now only show the actualTextLayoutManager.ktchanges plus the new focused test.MarkCSmith commentedon May 28, 2026
I tested the provided patch and it fixes this bug. It would be great to get it merged and then backported to React Native 0.85.x.
AuroPick commentedon Sep 23, 2026
This is still the same in 0.87. I think it broke in 0.84