Repository navigation
Conversation
Summary: Add a new RNTester example in TextInlineView that reproduces the issue where setting a line height for Text breaks expected CSS behavior with inline views and images. Changelog: [Internal] Differential Revision: D126542681
|
@jasozh has exported this pull request. If you are a Meta employee, you can view the originating Diff in D126795867. |
jasozh
force-pushed
the
export-D126795867
branch
from
October 26, 2026 18:49
10de712 to
49a83ea
Compare
jasozh
added a commit
to jasozh/react-native
that referenced
this pull request
Oct 26, 2026
Summary: Pull Request resolved: react#59420 Fixes the issue described in [react#48727](react#48727), where adding inline views and images into Text when line height is specified results in the image clipping and overflowing the parent container. ### Root Cause On Android, CustomLineHeightSpan uses the line's merged font metrics `fm` to set the line's ascent/descent so text clamps to `lineHeight`. However, the calculation assumes `fm` only describes text whereas in reality, it also includes the height of inline views/images. As a result, taller images are also clamped to `lineHeight` and overflow. Additionally, because `StaticLayout` seeds each line with the previous line's adjusted font metrics when a text run wraps, the lines after the inline view also inherit its height and get misplaced baselines. The result is that wrapped text following an inline image appear unusually squashed. On iOS, `lineHeight` sets both `minimumLineHeight` and `maximumLineHeight` so TextKit clamps every line to the same height, even for lines with a taller inline view/image. Additionally, `RCTApplyBaselineOffset` lifts the text with `NSBaselineOffset` to center it in the line, but for inline views, this is computed from the unlifted baseline, causing images to sit below the text baseline. ### This PR For Android, modify CustomLineHeightSpan so that if the text includes an inline view, we use `TextPaint` to re-derive `fm` via `measureTextRun()` for every line. This means `fm` only describes text during the `chooseHeight()` calculation, and each line is unaffected by wrapping issues. Then, raise the line's ascent/top to fit the inline view. For iOS, set `RCTTextLayoutManager` as a `NSLayoutManagerDelegate` if an inline view exists so the layout manager calls `layoutManagerShouldSetLineFragmentRect()` which grows the line to match the height of the inline view. Separately, modify the baseline shift so that attachments match the text baseline. All changes are gated behind the `fixTextInlineViewLineHeight` flag. Changelog: [General][Fixed] - Inline views in Text with lineHeight no longer overflow the text Differential Revision: D126795867
Summary: Pull Request resolved: react#59420 Fixes the issue described in [react#48727](react#48727), where adding inline views and images into Text when line height is specified results in the image clipping and overflowing the parent container. ### Root Cause On Android, CustomLineHeightSpan uses the line's merged font metrics `fm` to set the line's ascent/descent so text clamps to `lineHeight`. However, the calculation assumes `fm` only describes text whereas in reality, it also includes the height of inline views/images. As a result, taller images are also clamped to `lineHeight` and overflow. Additionally, because `StaticLayout` seeds each line with the previous line's adjusted font metrics when a text run wraps, the lines after the inline view also inherit its height and get misplaced baselines. The result is that wrapped text following an inline image appear unusually squashed. On iOS, `lineHeight` sets both `minimumLineHeight` and `maximumLineHeight` so TextKit clamps every line to the same height, even for lines with a taller inline view/image. Additionally, `RCTApplyBaselineOffset` lifts the text with `NSBaselineOffset` to center it in the line, but for inline views, this is computed from the unlifted baseline, causing images to sit below the text baseline. ### This PR For Android, modify CustomLineHeightSpan so that if the text includes an inline view, we use `TextPaint` to re-derive `fm` via `measureTextRun()` for every line. This means `fm` only describes text during the `chooseHeight()` calculation, and each line is unaffected by wrapping issues. Then, raise the line's ascent/top to fit the inline view. For iOS, set `RCTTextLayoutManager` as a `NSLayoutManagerDelegate` if an inline view exists so the layout manager calls `layoutManagerShouldSetLineFragmentRect()` which grows the line to match the height of the inline view. Separately, modify the baseline shift so that attachments match the text baseline. All changes are gated behind the `fixTextInlineViewLineHeight` flag. Changelog: [General][Fixed] - Inline views in Text with lineHeight no longer overflow the text Differential Revision: D126795867
jasozh
force-pushed
the
export-D126795867
branch
from
October 26, 2026 18:55
49a83ea to
7851272
Compare
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



Summary:
Fixes the issue described in #48727, where adding inline views and images into Text when line height is specified results in the image clipping and overflowing the parent container.
Root Cause
On Android, CustomLineHeightSpan uses the line's merged font metrics
fmto set the line's ascent/descent so text clamps tolineHeight. However, the calculation assumesfmonly describes text whereas in reality, it also includes the height of inline views/images. As a result, taller images are also clamped tolineHeightand overflow.Additionally, because
StaticLayoutseeds each line with the previous line's adjusted font metrics when a text run wraps, the lines after the inline view also inherit its height and get misplaced baselines. The result is that wrapped text following an inline image appear unusually squashed.On iOS,
lineHeightsets bothminimumLineHeightandmaximumLineHeightso TextKit clamps every line to the same height, even for lines with a taller inline view/image.Additionally,
RCTApplyBaselineOffsetlifts the text withNSBaselineOffsetto center it in the line, but for inline views, this is computed from the unlifted baseline, causing images to sit below the text baseline.This PR
For Android, modify CustomLineHeightSpan so that if the text includes an inline view, we use
TextPaintto re-derivefmviameasureTextRun()for every line. This meansfmonly describes text during thechooseHeight()calculation, and each line is unaffected by wrapping issues. Then, raise the line's ascent/top to fit the inline view.For iOS, set
RCTTextLayoutManageras aNSLayoutManagerDelegateif an inline view exists so the layout manager callslayoutManagerShouldSetLineFragmentRect()which grows the line to match the height of the inline view. Separately, modify the baseline shift so that attachments match the text baseline.All changes are gated behind the
fixTextInlineViewLineHeightflag.Changelog: [General][Fixed] - Inline views in Text with lineHeight no longer overflow the text
Differential Revision: D126795867