iOS Fabric: wrapping <Text> with lineHeight clips the last line's final word

[orangebibleapp-create]

Description

On the iOS New Architecture (Fabric), a wrapping <Text> that has an explicit lineHeight set mis-measures the width of its last line and clips the final word (or last few characters) off the right edge. The same tree renders correctly on Android, and correctly on iOS with the legacy renderer.

Because the mis-measurement is sub-pixel and width/font-size/device dependent, it manifests as a knife-edge: the clip only appears for certain line contents at certain widths/font sizes, so it's easy to miss in testing and shows up as user reports of "the last word is cut off" on some devices but not others.

This is the same underlying defect as #53092 (closed only because a stale-bot auto-closed it after 180 days — not because it was fixed) and the abandoned/​unmerged PR #53341. Filing a fresh, self-contained report since the original is closed and the bug still reproduces on current releases.

Steps to reproduce

1. New Architecture enabled, iOS.
2. Render a <Text> with an explicit lineHeight that is wide enough to wrap to several lines, where the last line is nearly full (so the final word sits close to the right edge). Nested child <Text> spans (as in a paragraph made of multiple styled runs) make it more reliable.
3. Observe the last word/characters of the block clipped off the right edge. Remove lineHeight → renders correctly (but you lose the desired leading).

import { Text, View } from 'react-native';

export default function Repro() {
  return (
    <View style={{ padding: 20 }}>
      <Text style={{ fontSize: 24, lineHeight: 36 }}>
        <Text>Then he is to take the bull outside the camp and burn it, </Text>
        <Text>just as he burned the first bull. It is the sin offering for the assembly.</Text>
      </Text>
    </View>
  );
}

The trailing "assembly." clips on iOS Fabric; correct on Android / iOS Paper.

Workaround

Append a throwaway trailing line (a newline + zero-width space) as the last child of the wrapping <Text>. The mis-measured "last line" is then the empty one, so the real last line of content measures and wraps correctly — while the desired lineHeight is preserved:

<Text style={{ fontSize: 24, lineHeight: 36 }}>
  {/* ...content... */}
  {'\n​'}
</Text>

This is stable in practice (it doesn't depend on tuning width/height per device the way the earlier hidden-character workarounds in #53092 did), at the cost of a small amount of trailing vertical space.

React Native Version

0.83.6

Affected Platforms

Runtime - iOS (New Architecture / Fabric). Android and iOS legacy renderer unaffected.

Environment

• React Native 0.83.6, Hermes, New Architecture enabled
• Expo SDK 55
• Reproduced on iOS 26 simulators (iPhone 16 / 17 Pro) and reported by users on physical devices

Additional notes

Refs #53092, #53341. The last human comment on #53092 (2025-09) reports the same behavior on Android in some configurations and notes the then-current workarounds were unstable across line height / font size / screen density; the trailing-empty-line approach above avoids that instability.

[react-native-bot]

Warning

Missing reproducer: We could not detect a reproducible example in your issue report. Reproducers are mandatory and we can accept only one of those as a valid reproducer:

• For majority of bugs: send us a Pull Request with the RNTesterPlayground.js edited to reproduce your bug.
• If your bug is UI related: a Snack
• If your bug is build/upgrade related: a project using our Reproducer Template

You can read more about about it on our website: How to report a bug.

[expo-bot]

Outcome: pass

@brentvatne I could not reproduce this. The code sample renders complete on iOS with the New Architecture. The last word "assembly." is present at all 10 container widths I tested, 340 to 380 points, with lineHeight: 36 and without it. Environment: hosted iOS 26 simulator, iPhone 16 Pro size, React Native 0.86.2, Fabric active.

Two statements in the report are wrong. PR #53341 did ship: it landed as commit 6da351a5ed8 and is in v0.82.0 and later, so 0.83.6 contains it. GitHub marks it closed and not merged because Meta imports and squashes such changes. And #53092 reports a different defect, the alignment of an inline <View> inside a <Text> with lineHeight, not a clipped word.

What I need from you: retest on 0.87.1 and on main (0.88 nightly). Then give the device model, the window width in points, the font size, the lineHeight, and a screenshot with a border around the <Text>. The failure depends on exact sub-pixel sizes, so those five facts are what let anyone reproduce it. The closest matching report is #53450, and its fix is on main only.

For a maintainer, one decision: whether to cherry-pick #57698 to 0.87-stable. That epsilon rounding is on main only; 0.83- through 0.87-stable still use the old rounding. This run did not show that #57698 cures this paragraph, and it proposes no code change.

Environment

Item	Value
Device	Hosted iOS simulator, iOS 26, iPhone 16 Pro size, 402x874 points, scale 3
Runtime	Expo Go, Expo SDK 57, React Native 0.86.2
Renderer	Fabric. global.nativeFabricUIManager != null is true, printed on screen in each capture
EAS builds	None used

What I measured

I rendered the code sample from the report, unchanged, with both children kept as nested <Text> spans, inside a red border. I repeated it at 10 container widths. Every block rendered all of its lines, and "assembly." is complete in all of them.

Container width (pt)	<Text> frame (pt)	Lines
340	338.00 x 180.00	5
345	343.00 x 144.00	4
350	348.00 x 144.00	4
355	353.00 x 144.00	4
360	358.00 x 144.00	4
362	360.00 x 144.00	4
365	363.00 x 144.00	4
370	368.00 x 144.00	4
375	373.00 x 144.00	4
380	378.00 x 144.00	4

The frame is 2 points narrower than the container because of the 1-point border on each side. Every measured height is an exact multiple of lineHeight 36.

I also rendered the sample at the full window content width (360 points) with lineHeight: 36 and, as a control, without lineHeight. Both render complete.

What this environment did NOT show, and why that bounds the result

I also rendered LastLineClippingExample, copied unchanged from TextSharedExamples.js L245-L264. PR #57698 added that example as the visual check for #53450, and the source comment says the final line is "prone to being clipped by one physical pixel after layout rounding". React Native 0.86.2 does not contain #57698. All seven blocks rendered complete.

So this environment never showed the known #53450 defect, on a build that lacks its fix. Read it either way, it limits my result:

• If that example is a reliable check, then this simulator, at scale 3 and this window size, cannot exhibit that defect class. My non-reproduction of the reporter's paragraph then says little about other devices.
• If that example is itself knife-edge and only clips at some scale factors or fonts, then it is not a control, and it proves nothing beyond itself.

I could not separate the two. The hosted simulator gives one device and takes no device or scale parameter, so I could not retest at scale 2.

I also ran an automated sweep over 2,200 width and font-size combinations that reported no clipping. I do not cite it. Its detector used onTextLayout, and it failed a planted positive control: the same paragraph with its frame squeezed to 60 points was not flagged. A detector that misses a planted failure cannot prove absence.

Mechanism, as code analysis and not as measurement

The precision loss behind #53450 affects both dimensions. TextMeasurementRounding.h L16-L41 states that a value on a physical-pixel boundary can round down and "clip the final line (height) or trailing glyph (width)", and the helper adds the epsilon to both width and height.

For wrapped text, however, the width path is neutral. The measurement replaces the paragraph width with the full container width at RCTTextLayoutManager.mm L568-L573. A wrapped paragraph is therefore not under-measured in width, and only the height path can apply to the reported case.

On the height path, an explicit integral lineHeight gives a measured height that is an exact multiple of that value. I measured 144.00 or 180.00 points at all 10 widths. Such values are exactly representable as float, so the double-to-float step loses nothing. Without lineHeight the height comes from font metrics and is fractional, which is where the loss can occur. On this mechanism lineHeight reduces the risk instead of creating it, which is the opposite of the report.

This does not prove that no lineHeight-dependent defect exists. It says the mechanism named in the report does not explain one.

0.83.6 against the 0.86.2 I ran

The reporter runs 0.83.6. I ran 0.86.2. git diff 0.83-stable 0.86-stable on RCTTextLayoutManager.mm gives four hunks:

@@ -208,8 +208,9 @@   null guard around [renderedString UTF8String] in getLinesForAttributedString
@@ -251,10 +252,10 @@  getEventEmitterWithAttributeString: SharedEventEmitter -> std::shared_ptr<const EventEmitter>
@@ -391,6 +392,8 @@   adds `NSRange visibleGlyphRange = ...` after the size computation
@@ -406,7 +409,15 @@  attachment clipping: adds the isOutsideVisibleRange test

None of them changes the size computation. Both branches keep the width override:

375:  if (textDidWrap) {
376:    size.width = textContainer.size.width;
377:  }

and both keep the pre-#57698 rounding, size = (CGSize){ceil(size.width * layoutContext.pointScaleFactor) / ...}. I did not run 0.83.6 itself.

What the referenced issues and pull request actually are

• Nested Text Alignment Broken In New Architecture iOS when lineHeight is provided #53092, "Nested Text Alignment Broken In New Architecture iOS when lineHeight is provided": an inline <View> inside a <Text> with lineHeight is not aligned to the text baseline on iOS Fabric. The issue API reports state_reason: not_planned and closed_by: react-native-bot, on 2026-03-26. That agrees with the report's statement that a bot closed it.
• fix(iOS)(Fabric) inline view alignment inside of a Text with line height #53341: the pull request for Nested Text Alignment Broken In New Architecture iOS when lineHeight is provided #53092. The GitHub API reports merged: false, but the change is in the repository as commit 6da351a, dated 2025-08-20, and the first release tag that contains it is v0.82.0. It is an ancestor of v0.83.6 and of 0.83- through 0.87-stable. It changed the inline attachment frame to use the glyph height and the font descender. So the change shipped; it is not abandoned. I did not test whether it fully fixes Nested Text Alignment Broken In New Architecture iOS when lineHeight is provided #53092.
• Text not fully rendered on iOS #53450, "Text not fully rendered on iOS": the last words of a wrapped paragraph are not rendered on iOS Fabric. The reporter of that issue wrote: "The sentence in the end ... is not being fully rendered, the rest of it should be rendered on the next line but it isn't." Closed as completed. I treat this as the closest matching report for iOS Fabric: wrapping <Text> with lineHeight clips the last line's final word #58156, on the wording of the two symptom descriptions. I did not reproduce either defect, so the match is not established by measurement. Note also that Text not fully rendered on iOS #53450 describes text moving to the next line, while iOS Fabric: wrapping <Text> with lineHeight clips the last line's final word #58156 describes a cut at the right edge.

Release status of the #57698 fix

TextMeasurementRounding.h is absent on 0.83-stable, 0.84-stable, 0.85-stable, 0.86-stable and 0.87-stable. All five still carry ceil(size.width * layoutContext.pointScaleFactor). The file exists only on main. Commit 5e40a17 is not an ancestor of v0.83.6. So no released version has that fix.

Not covered

• Physical devices. This environment is a simulator only.
• Devices at scale 2, or window sizes other than 402x874. The hosted simulator gives one device.
• Container widths outside 340 to 380 points, and font sizes other than 24 for the reported sample.
• React Native 0.83.6 itself. I ran 0.86.2 and showed the measurement code is the same.
• A build of main. I have no arm that runs with fix(ios): prevent pixel-grid rounding from clipping text #57698 present, so I did not measure that it cures this paragraph.
• Whether the known Text not fully rendered on iOS #53450 example can clip at all in this environment. It did not, on a build without the fix.
• Android, iPad, and text with numberOfLines set.

Verification evidence

Widths 340-360pt, lineHeight 36: last word renders	Widths 365-380pt, lineHeight 36: last word renders	Reported sample at window width, with and without lineHeight
2026-08-26T21:16:07.299Z	2026-08-26T21:16:50.617Z	2026-08-26T21:09:03.962Z
Known 53450 example also renders fully here
2026-08-26T21:09:23.194Z