You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[0.86] Fix Fabric reusing nodes with a stale font scale (#57246) #1447
On iOS with the New Architecture, changing the system text size while the app is running leaves already-mounted nodes with their old line breaks and box heights while the glyphs draw at the new size. Text overflows and clips, onTextLayout keeps reporting the stale widths, and the only recovery is a remount or a relaunch. Reported in react/react-native#57512 with reproducers on 0.86.0, 0.86.2 and 0.86.3, on simulator and on physical hardware in Release builds. It reproduces at font scales reachable from the ordinary Larger Text slider, so it is not limited to accessibility sizes. For any user who changes their text size while the app is running, every screen that stays mounted renders clipped and overflowing text until the app is relaunched, with no way for the app to detect or recover from it.
#57246 moves the font-scale comparison from SurfaceHandler::constraintLayout into configureYogaTree, so a node still carrying a stale fontSizeMultiplier is re-cloned on every commit rather than only on the first one. It merged on main on 2026-06-18 (45904c866882f136edde55df2fe453327057d387) and is in 0.87.0+, but it is not on 0.86-stable. The last comment on #57512 compares a stock npx @react-native-community/cli init app on 0.86.3 against 0.87.1 with the same App.tsx: 0.86.3 shows the stale boxes after the next unrelated commit, 0.87.1 renders correctly in every variant tried. An LLDB trace earlier in the thread shows the stale node reaching shouldNewRevisionDirtyMeasurement through a state-only clone with no further measureContent call, which is the path the PR addresses.
The diff applies cleanly to 0.86-stable with git apply after dropping the scripts/cxx-api snapshot files: five files under ReactCommon, +29/-94. It is gated on enableFontScaleChangesUpdatingLayout, which already defaults to true on 0.86.
Thank you for opening a new React Native Pick Request.
These are the criteria we follow when accepting or rejecting a code change into a React Native release branch (source).
If your Pick Request does not satisfy the criteria below, please close it as it will not be considered.
✅ Which Pick Requests we accept
✅ Fixes for regressions to core APIs. Examples:
A core component is behaving differently between versions 0.X and 0.X-1
The TurboModule.getEnforcing function is throwing an unexpected assertion error.
✅ Fixes to bugs in core React Native. Examples:
Breakpoints in React Native DevTools not working correctly in the debugger
Fast Refresh not working as expected
Metro bundler not starting properly or ignoring the configuration file
Buttons that are not clickable
✅ Fixes to APIs used by third-party libraries and out-of-tree platforms. Examples:
An API used by react-native-macos is not behaving as expected or is regressing
✅ Bump of patch version of dependencies. Example:
Bump Gradle from 8.11.0 to 8.11.1
✅ Fixes for low/high severity security vulnerabilities. Example:
Bump Gradle from 8.11.0 to 8.12.0 if there is a security vulnerability in 8.11 and no 8.11.x version contains the same fix.
✅ Fixes and reverts of accidental breaking changes. Example:
Reverting or fix-forwarding a Kotlin migration of a file (e.g. ReactRootView.java) if it is causing a breaking change for the React Native ecosystem.
✅ Performance improvements. Examples:
Fixing unnecessary re-renders in FlatList.
✅ Any Pick Request if the release is still in RC0 (after RC1, the previously listed criteria apply)
❌ Which Pick Requests we don't accept
❌ Any Pick Request that introduces a breaking change after RC1. Example:
A bugfix that contains a refactoring, resulting in changes to the public API of a class
❌ Any Pick Request that introduces a new feature after RC1. Example:
A commit that introduces a new API or a specific feature for a component.
❌ Bump of major or minor version of dependencies. Examples:
Bump Gradle from 8.11.0 to 8.12.0
Bump Gradle from 8.11.0 to 9.0.0
❌ Bump of a dependency to a pre-release version. Example:
Bump Gradle from 8.11.0 to 8.11.1-beta.1
❌ Any Pick Request that introduces changes to the React Native testing infrastructure after RC1. Examples:
Changes to GitHub Actions workflows to optimize them, even if they are on main.
Changes to the logic used to publish packages to NPM or Maven Central
❌ Pick Request composed of multiple commits that have several merge conflicts.
If your Pick Request is too complex to apply to the release branch, it will be rejected.
❌ Any non-critical improvement that landed on main.
These will generally ship in the following version unless they fit one of the criteria above.
❌ Any Pick Request considered a "nice to have".
Even one-line changes carry a risk of destabilizing and further delaying the release.
ℹ️ What makes for a good Pick Request
In order for your Pick Request to be considered, please do the following:
ℹ️ Limit your Pick Request to one commit from main, or one PR against the release branch.
ℹ️ Include a clear explanation of why your Pick Request should be considered, ideally referencing one of the criteria above.
ℹ️ Target only one minor version of React Native (e.g. [0.76]). To have your Pick Request applied to more versions, please open separate Pick Requests.
Activity
github-actions commentedon Oct 14, 2026
Thank you for opening a new React Native Pick Request.
These are the criteria we follow when accepting or rejecting a code change into a React Native release branch (source).
If your Pick Request does not satisfy the criteria below, please close it as it will not be considered.
✅ Which Pick Requests we accept
TurboModule.getEnforcingfunction is throwing an unexpected assertion error.react-native-macosis not behaving as expected or is regressingReactRootView.java) if it is causing a breaking change for the React Native ecosystem.❌ Which Pick Requests we don't accept
ℹ️ What makes for a good Pick Request
In order for your Pick Request to be considered, please do the following:
main, or one PR against the release branch.