Repository navigation
Move RCTParagraphTextView drawing to contentView - #46081
Closed
cipolleschi wants to merge 2 commits into
Closed
cipolleschi wants to merge 2 commits into
cipolleschi wants to merge 2 commits into
Conversation
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D61431369 |
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D61431369 |
Summary: This diff adds an example in RNTester to verify that we can draw text on top of a colored background and non uniform border radius. As you can see from the test plan, the current code works well when: * There is only the background color * There is a background color and uniform cornerRadius * There are non uniform border radius but the background is transparent. The current code **does not** work when: * there is a background and non-uniform border radius * there is a background, uniform border radius and borderwidth The reason why this happens is because: * `RCTParagraphComponentView` draws the text in the View's main layer in the `drawRect` method * `RCTViewComponentView` has a method `invalidateLayer` that, when there are non-uniform border radii o there is a borderWidth, it creates an extra `CALayer` with an image as content and that layer is put on top of the base layer, covering the text. ## Changelog [Internal] - Add example to RNTester Differential Revision: D61389317
Summary: Pull Request resolved: #46081 This change fixes an issue that has been reported by OSS where a Text with both background color and borderWidth is not rendered properly. The reason is that `RCTParagraphComponentView` uses the `drawRect` method which draws the text in the main view layer, while the parent `RCTViewComponentView` can apply an extraLayer on top of the base layer, drawing on top of the text. This change moves the drawing of the text to an auxiliary view, `RCTParagraphTextView`, that is set as contentView of the `RCTParagraphView`. In this way, the text is drawn in a different view and can't be covered by the `_borderLayer` ## Changelog: [Internal] - Introduce a RCTParagraphTextView to draw the text Reviewed By: joevilches Differential Revision: D61431369
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D61431369 |
Contributor
|
This pull request has been merged in f4609db. |
meta-codesync Bot
pushed a commit
that referenced
this pull request
Oct 7, 2026
…ews (#58632) Summary: `RCTParagraphComponentView` derives the text view's frame and drawing frame in `layoutSubviews`, requested with `setNeedsLayout` from `updateState` and `updateLayoutMetrics`. The layout pass itself dates from #46081, but until #57408 `drawRect:` read the content frame straight from `_layoutMetrics`, which is always current; #57408 moved drawing onto a `drawingFrame` computed in `layoutSubviews`, so drawing now assumes a layout pass will run before the view is displayed. It does not when the mount itself happens inside Core Animation's display phase — which is where `AppleEventBeat` processes a synchronous event requested during layout (#58530). This transaction's layout pass is already over, so the text view displays the new attributed string in the previous drawing frame and the text is cut off at the old width. The queued `layoutSubviews` updates the frame in the next transaction, but `drawingFrame` is a plain property that does not invalidate the display, so the clipped drawing stays until something else redraws the view. Nothing on `main` emits a synchronous event from layout yet, so this is latent today; #58109 is the first thing that does (`layoutSubviews` reporting safe area insets on rotation) and it hits this on every rotation. The frames are now computed in `finalizeUpdates:`, which the mounting manager calls [once per view after all of a mutation's `update*` calls](https://github.com/react/react-native/blob/f03f6c2b856e7d923f8af13d7ef452eb4bb21cd4/packages/react-native/React/Fabric/Mounting/RCTMountingManager.mm#L108-L134). That coalesces state and layout-metrics changes the same way the layout pass did — one computation per mount, as before — without depending on a layout pass that may already have happened, and it removes the extra layout pass altogether. The `layoutSubviews` override goes away; `updateState` and `updateLayoutMetrics` keep their `setNeedsDisplay`. ## Changelog: [IOS] [FIXED] - Text no longer renders clipped when mounted from a synchronous event during layout Pull Request resolved: #58632 Test Plan: Reproduced with #58109 on top of this branch, RNTester "Safe area insets" example, iPhone 17 Pro simulator: present the padded modal, apply insets, rotate. The readout text is re-rendered synchronously from the rotation's layout pass. | Before | After | |:---:|:---:| | <img src="https://github.com/user-attachments/assets/092b162b-1b28-4b02-b584-4c28d66a96b5" width="440" /> | <img src="https://github.com/user-attachments/assets/52ae2ce8-75c7-4b2c-9e90-006e68b2588e" width="440" /> | Before: `top: 0, right: 62, bottom: 19.99996` — the accessibility label carries the full `…9482421875, left: 62`, and the layout box is the right size; only the drawing is cut at the previous width. The paragraph under it overflows on one line for the same reason. After: both render at their new width. Rotating back to portrait renders correctly too, and ordinary text throughout RNTester (normal asynchronous mounts) is unchanged. --- Found while testing #58109, which hits this on every rotation; standalone, that stack does not include this change. Reviewed By: andrewdacenko, javache Differential Revision: D121209981 Pulled By: Abbondanzo fbshipit-source-id: 6fda49771b08d489623e2bb35c5b59ec46ac03da
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:
This change fixes an issue that has been reported by OSS where a Text with both background color and borderWidth is not rendered properly.
The reason is that
RCTParagraphComponentViewuses thedrawRectmethod which draws the text in the main view layer, while the parentRCTViewComponentViewcan apply an extraLayer on top of the base layer, drawing on top of the text.This change moves the drawing of the text to an auxiliary view,
RCTParagraphTextView, that is set as contentView of theRCTParagraphView. In this way, the text is drawn in a different view and can't be covered by the_borderLayerChangelog:
[Internal] - Introduce a RCTParagraphTextView to draw the text
Differential Revision: D61431369