Describe the bug
When EnrichedText renders HTML containing an <img>, the text on the line immediately before that image can fail to visually paint on iOS. The text is still present and correctly positioned (confirmed via the accessibility tree), but it never gets drawn. The rest of the surrounding content renders fine.
This issue is specifically correlated with revisiting a screen via React Navigation (@react-navigation/native + react-native-screens native-stack, via expo-router). A fresh first visit renders correctly, but navigating away and then back causes the line to reliably or intermittently fail to paint. This is an iOS-only issue and does not reproduce on Android.
Investigation ruled out JS-side remount timing issues (the bug persists even with zero remounts/key changes on revisit, or when forcing fixed-delay remounts).
To Reproduce
Steps to reproduce the behavior:
- In an app using
expo-router or @react-navigation/native (with react-native-screens), create a screen that renders EnrichedText.
- Provide HTML ending in a text block immediately followed by an
<img>, e.g., ...<div>Some text</div><img src="..." width="..." height="..." />.
- Navigate to that screen. (Observe that it renders correctly).
- Navigate back to the previous screen.
- Navigate forward to the same screen again.
- See error: The line of text immediately before the
<img> is now blank (though still present and correctly positioned in the accessibility tree).
Expected behavior
The text immediately preceding the <img> tag should consistently paint and remain visible on subsequent visits to the screen, mirroring the behavior of the initial visit.
Screenshots
(Not applicable/No screenshot provided — visually, it manifests as empty space where the text should be).
Device (please complete the following information):
- Device: iPhone 17 Pro (iOS Simulator)
- OS: iOS 26.4
- Version:
react-native-enriched-html v1.1.1 (Running on React Native 0.86.3, Expo ~57.0.20, Fabric new architecture)
Additional context
Reproduction context: This issue could not be reproduced in isolation (e.g., via a Storybook story with identical HTML and remount behavior). It strictly depends on real React Navigation transition/view-controller behavior.
Potential contributing factor identified: In EnrichedTextView.mm, renderContent fully rebuilds textView.textStorage on every render but never explicitly invalidates/re-lays-out the NSLayoutManager around the changed content. This contrasts with the editable EnrichedTextInputView.mm, which works around similar TextKit gaps via _performRelayout. Patching EnrichedTextView to mirror this sequence did not reliably fix this specific bug on its own, but it highlights a potential TextKit gap.
Questions for maintainers:
- Is there a known interaction between
EnrichedTextView's render/layout cycle and view controller appearance/reappearance (e.g., viewWillAppear/native view recycling) that could cause a stale/incomplete TextKit layout pass specifically on a view's second-or-later appearance in a navigation stack?
- Are there any existing instrumentation or debug flags in the library for tracing
NSLayoutManager invalidation timing to help build a tighter reproduction?
Describe the bug
When
EnrichedTextrenders HTML containing an<img>, the text on the line immediately before that image can fail to visually paint on iOS. The text is still present and correctly positioned (confirmed via the accessibility tree), but it never gets drawn. The rest of the surrounding content renders fine.This issue is specifically correlated with revisiting a screen via React Navigation (
@react-navigation/native+react-native-screensnative-stack, viaexpo-router). A fresh first visit renders correctly, but navigating away and then back causes the line to reliably or intermittently fail to paint. This is an iOS-only issue and does not reproduce on Android.Investigation ruled out JS-side remount timing issues (the bug persists even with zero remounts/key changes on revisit, or when forcing fixed-delay remounts).
To Reproduce
Steps to reproduce the behavior:
expo-routeror@react-navigation/native(withreact-native-screens), create a screen that rendersEnrichedText.<img>, e.g.,...<div>Some text</div><img src="..." width="..." height="..." />.<img>is now blank (though still present and correctly positioned in the accessibility tree).Expected behavior
The text immediately preceding the
<img>tag should consistently paint and remain visible on subsequent visits to the screen, mirroring the behavior of the initial visit.Screenshots
(Not applicable/No screenshot provided — visually, it manifests as empty space where the text should be).
Device (please complete the following information):
react-native-enriched-htmlv1.1.1 (Running on React Native 0.86.3, Expo ~57.0.20, Fabric new architecture)Additional context
Reproduction context: This issue could not be reproduced in isolation (e.g., via a Storybook story with identical HTML and remount behavior). It strictly depends on real React Navigation transition/view-controller behavior.
Potential contributing factor identified: In
EnrichedTextView.mm,renderContentfully rebuildstextView.textStorageon every render but never explicitly invalidates/re-lays-out theNSLayoutManageraround the changed content. This contrasts with the editableEnrichedTextInputView.mm, which works around similar TextKit gaps via_performRelayout. PatchingEnrichedTextViewto mirror this sequence did not reliably fix this specific bug on its own, but it highlights a potential TextKit gap.Questions for maintainers:
EnrichedTextView's render/layout cycle and view controller appearance/reappearance (e.g.,viewWillAppear/native view recycling) that could cause a stale/incomplete TextKit layout pass specifically on a view's second-or-later appearance in a navigation stack?NSLayoutManagerinvalidation timing to help build a tighter reproduction?