Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38233
When call ReactHost.destroy multiple times on same thread, the synchronization we have now can not protect us from concurrent issues such as ```ConcurrentModificationException```, to avoid this case this diff checks if ReactInstance has been reset, if so it means an early destroy has been called and we should not destroy again.
Changelog:
[Android][Changed] - Avoid duplicate destroy on same thread
Reviewed By: fkgozali
Differential Revision: D47276191
fbshipit-source-id: 2291b89cb980ca762abddb835e703abd095a93b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38274
Update oncall field on all of the react native android BUCK files
The goal is to prevent lint warnings
changelog: [internal] internal
Reviewed By: christophpurrer
Differential Revision: D47338271
fbshipit-source-id: 757a915458a2370dabe122fd3f4936409f8aef95
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38255
Remove package comment from JSCExecutor
This class was made public as part of D30346032, seems it's safe for it to be public
changelog: [internal] internal
Reviewed By: christophpurrer
Differential Revision: D47309285
fbshipit-source-id: 061aeb3a803ded73cad7d45909ab22fe7489c811
Summary:
### Motivation
I had a crash-causing error in our error reporting console (Bugsnag) that was extremely hard to debug due to the lack of specificity in the thrown error.
```
java.lang.NullPointerException: Attempt to invoke virtual method 'double java.lang.Double.doubleValue()' on a null object reference
at com.facebook.react.bridge.ReadableNativeArray.getDouble(ReadableNativeArray.java:92)
at com.facebook.react.bridge.JavaMethodWrapper$4.extractArgument(JavaMethodWrapper.java:64)
at com.facebook.react.bridge.JavaMethodWrapper$4.extractArgument(JavaMethodWrapper.java:60)
at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:356)
at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:188)
at com.facebook.jni.NativeRunnable.run(NativeRunnable.java:-2)
at android.os.Handler.handleCallback(Handler.java:883)
at android.os.Handler.dispatchMessage(Handler.java:100)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:27)
at android.os.Looper.loop(Looper.java:214)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:228)
at java.lang.Thread.run(Thread.java:919)
```
I noticed that `invoke` in `JavaMethodWrapper` tacks on the JS method name on other errors, so wanted to change this to handle NullPointerExceptions more gracefully too.
This helps make it easier to debug issues like https://github.com/facebook/react-native/issues/23126, https://github.com/facebook/react-native/issues/19413, https://github.com/facebook/react-native/issues/27633, https://github.com/facebook/react-native/issues/23378, https://github.com/facebook/react-native/issues/29250, https://github.com/facebook/react-native/issues/28262, https://github.com/facebook/react-native/issues/34001 and likely many more.
### After adding NullPointerException
Even after adding the NullPointerException, I got errors like this:
```
com.facebook.react.bridge.NativeArgumentsParseException: Attempt to invoke virtual method 'double java.lang.Double.doubleValue()' on a null object reference (constructing arguments for UIManager.dispatchViewManagerCommand at argument index 0) with parameters [null, 4.0, []]
at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:371)
at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:188)
at com.facebook.jni.NativeRunnable.run(NativeRunnable.java:-2)
at android.os.Handler.handleCallback(Handler.java:942)
at android.os.Handler.dispatchMessage(Handler.java:99)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:27)
at android.os.Looper.loopOnce(Looper.java:226)
at android.os.Looper.loop(Looper.java:313)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:228)
at java.lang.Thread.run(Thread.java:1012)
```
This helped, but still didn't help me easily find which library calling `dispatchViewManagerCommand` was causing this.
## Changelog:
[ANDROID] [CHANGED] - Wrap NullPointerExceptions when thrown by native code called from JS for readability
[GENERAL] [CHANGED] - Throw Error in dispatchViewManagerCommand when non-numeric tag is passed for easier debugging
Pull Request resolved: https://github.com/facebook/react-native/pull/38060
Test Plan:
Test change on our app via a beta release.
With these changes, we got better stacktraces like these:
### Java stacktrace
```
com.facebook.react.bridge.NativeArgumentsParseException: Attempt to invoke virtual method 'double java.lang.Double.doubleValue()' on a null object reference (constructing arguments for UIManager.dispatchViewManagerCommand at argument index 0) with parameters [null, 4.0, []]
at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:371)
at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:188)
at com.facebook.jni.NativeRunnable.run(NativeRunnable.java:-2)
at android.os.Handler.handleCallback(Handler.java:942)
at android.os.Handler.dispatchMessage(Handler.java:99)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:27)
at android.os.Looper.loopOnce(Looper.java:226)
at android.os.Looper.loop(Looper.java:313)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:228)
at java.lang.Thread.run(Thread.java:1012)
```
### JS stacktrace (after dispatchViewManagerCommand change)
```
Error dispatchViewManagerCommand: found null reactTag with args []
node_modules/react-native/Libraries/ReactNative/PaperUIManager.js:120:21 dispatchViewManagerCommand
node_modules/react-native-maps/lib/MapMarker.js:68:67 _runCommand
node_modules/react-native-maps/lib/MapMarker.js:60:24 redraw
templates/Components/MapViewWithMarkers/PlaceMarker.tsx:88:32 anonymous
(native) apply
node_modules/react-native/Libraries/Core/Timers/JSTimers.js:213:22 anonymous
node_modules/react-native/Libraries/Core/Timers/JSTimers.js:111:14 _callTimer
node_modules/react-native/Libraries/Core/Timers/JSTimers.js:359:16 callTimers
(native) apply
node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:427:31 __callFunction
node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:113:25 anonymous
node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:368:10 __guard
node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:112:16 callFunctionReturnFlushedQueue
```
Reviewed By: javache
Differential Revision: D47015785
Pulled By: cortinico
fbshipit-source-id: 33e0b8fbc7dc6a88d4c3383630126f99d2cf6098
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38256
Add RECEIVER_EXPORTED/RECEIVER_NOT_EXPORTED flag support to DevSupportManagerBase for Android 14 change. See
https://developer.android.com/about/versions/14/behavior-changes-14#runtime-receivers-exported for details.
Without this fix, app crashes during launch because of :
```SecurityException: {package name here}: One of RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED should be specified when a receiver isn't being registered exclusively for system broadcasts```
Changelog:
[Targeting SDK 34] Added RECEIVER_EXPORTED/RECEIVER_NOT_EXPORTED flag support in DevSupportManagerBase
Reviewed By: javache
Differential Revision: D47313501
fbshipit-source-id: 12e8299559d08b4ff87b4bdabb0a29d27763c698
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38242
See proposal: https://github.com/react-native-community/discussions-and-proposals/discussions/681
**Removed script files**
I searched GitHub (and specifically `react-native-windows/macos`) to confirm these files are not referenced:
- `scripts/launchPackager.bat`
- `scripts/launchPackager.command`
- `scripts/.packager.env`
Interestingly, React Native CLI refers to a `.packager.env` at a different location (`node_modules/.bin/`), and includes modified copies of `launchPackager.command/bat`. This PR removes duplication with these.
Changelog: [iOS][Breaking] Metro will no longer be started when running builds via Xcode
Reviewed By: cortinico
Differential Revision: D47297469
fbshipit-source-id: 06c3602d58b21ed693c3daa763d99947a70bfc5a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38220
We ran an experiment to test different implementations of TurboModules HostObjects, as the current one has various inefficiencies, such as re-creating HostFunctions on every property access. The strategy we found to be most efficient and flexible longer-term is to represent the TurboModule with a plain JavaScript object and use a HostObject as its prototype. Whenever a property is accessed through the prototype, we cache the property value on the plain object, so it can be efficiently resolved by the VM for future accesses.
Changelog: [General] TurboModules are now exposed to JS as the prototype of a plain JS object, so methods can be cached
Reviewed By: sammy-SC
Differential Revision: D47258286
fbshipit-source-id: 4562ac5316164daaf673e713b35cb31315ff9652
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38251
I'm deleting ArrayUtils from codebase, this file is not used neither internally or externally (as analyzed in github source)
I believe it's very safe to delete without following any deprecation process
changelog: [Android][Deleted] Delete ArrayUtils from codebase
Reviewed By: christophpurrer
Differential Revision: D47306287
fbshipit-source-id: 1f36ca46db107e21dc55191528cacf6f81cf63ed
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38249
Quick migration of ReactJsExceptionHandler to Kotlin.
It will documented in the next diffs of the stack (might rename it as well)
changelog: [internal] internal
Reviewed By: arushikesarwani94
Differential Revision: D47300786
fbshipit-source-id: ea15b4180c22f5759d327e43af1b7a5c077ea9f8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38241
In this diff I'm moving the ReactJsExceptionHandler interface into the react.interfaces package.
This bring consistence with the rest of bridgeless APIs
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D47277572
fbshipit-source-id: ad17b19de3571df4ea1545f45d5998912deac072
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38232
In this diff I'm completing the TaskInterface interface with subset methods from Task that should be exposed
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D47267970
fbshipit-source-id: 8a51f94e3c42a1d396e002f75547665f320c3962
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38239
In D46840717 I made SurfaceMountingManager reset its context on stop as the Context may be keeping various other objects alive and was causing memory leaks.
This does cause a race condition if JS is still rendering at this time, as it needs to access to context to support things like PlatformColor.
Changelog: [Android] Fix crash on teardown in new architecture
Reviewed By: rshest
Differential Revision: D47290581
fbshipit-source-id: ef83c1d110d1156e39f2491fb62c82ec41c3b8e1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38235
changelog: [internal]
Original commit changeset: faece0940b15
Original Phabricator Diff: D46086661
This PR broke 50 diffs. Let's back it out.
I will communicate this to the PR owner with an example of what went wrong.
This causes a slight difference in text render:
{F1043017930}
Reviewed By: javache
Differential Revision: D47284841
fbshipit-source-id: 29d28f62d3997740b2186bd60b327a0d009c4a6b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38223
Before this change, the InteropLayer was adding the view to the registry right before invoking a command and right after the command was invoked. This model was too strict as some view commands may have async behaviors that make the lookup in the registry fail.
After this change, we are going to register the view when it's created and we are going to remove it when the view is deallocated.
## Changelog:
[iOS][Changed] - Update logic to add and remove views in the view registry for the interop layer.
Reviewed By: sammy-SC
Differential Revision: D47262664
fbshipit-source-id: 503f4e29e03bfc7ad861c1502129822b383ffcc0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38118https://github.com/facebook/react-native/pull/37925 mitigated an issue where vectorized animations (e.g. AnimatedColor) would flicker. This issue was nearly not as present in Android (flickering rarely happens). In fact, it greatly increased the flickering issues on Android.
This will make it so that AnimatedProps that use vectorized animation are only ignored on iOS until a more robust fix is available.
## Changelog
[General][Fixed] - AnimatedColor flickering on Android
Reviewed By: javache
Differential Revision: D47114536
fbshipit-source-id: a61bb11a316594d12c070a3149863fe5973745c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38200
Changelog: [Android] [Internal] - W3CPointerEvents: update tester to show screen coords and modifiers
Update RNTester "Display properties of multiple pointers" to show the screen coordinates and modifier keys for each pointer.
Reviewed By: javache
Differential Revision: D47162961
fbshipit-source-id: dffc305201661f628b955829158b763efd606e3e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38222
Changelog: [Android] [Fixed] - W3CPointerEvents: include screen coordinates in pointer events
The [spec](https://www.w3.org/TR/uievents/#idl-mouseevent) says there should be properties on mouse events (and hence pointer events) indicating the screen coordinates of the event (i.e. coords relative to screen of the device).
This change adds those properties.
Reviewed By: javache
Differential Revision: D47162962
fbshipit-source-id: 5bb9780882459b3550bbac792b7d7cf9f5c10860
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38201
Changelog: [Android] [Internal] - W3CPointerEvents: fix unintentional shallow copy of coordinates
When normalizing pointer event state, we previously only made a shallow copy and thus unintentionally modified the coordinate values in the original event state. This change fixes the issue by creating new coordinate arrays for the normalized event state instead of reusing the existing ones.
Reviewed By: javache
Differential Revision: D47230953
fbshipit-source-id: b29118c1ec32cd80fc0f05b2a55f283ef060f244
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38197
Changelog: [Android] [Fixed] - W3CPointerEvents: include modifier key properties in Android pointer events
The [spec](https://www.w3.org/TR/uievents/#idl-mouseevent) says there should be properties on mouse events (and hence pointer events) indicating whether ctrl, alt, shift, and/or meta are pressed during the event.
This change adds those properties.
Reviewed By: javache
Differential Revision: D47162963
fbshipit-source-id: fa76795217c08ef410fbc5467e9547074b47f3f7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38195
`onResponderGrant`'s return value drives the `blockNativeResponder` value for the `setIsJSResponder` native callback. On Android this is used to call `requestDisallowInterceptTouchEvent`, which can be used to prevent a scrollview from activating while another responder is active.
Changelog: [Improved] Exposed ability to block native responder in Pressability. Pressables using `cancelable={false}` will now prevent scrolling and other native gestures from activating.
Reviewed By: yungsters
Differential Revision: D47225928
fbshipit-source-id: 27f1c677436da3add301ecdcda6b018b9038829e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38217
Marks more filename patterns as "internal call sites" which has the effect of collapsing them by default in LogBox (and skipping them for the purpose of providing a code frame).
Changelog: [General][Fixed] Hide Babel helpers and other core files from LogBox stack traces by default
Reviewed By: cortinico, huntie
Differential Revision: D47230876
fbshipit-source-id: fe2d59d975c61cbdfd7b8da42288e284f3ab0739
Summary:
For the contentType Parameter of the method slice in Class Blob which was fixed for
https://github.com/facebook/react-native/pull/38078
the typescript declaration is missing.
## Changelog:
[GENERAL] [ADDED] - Added contentType parameter to Blob declaration
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/38163
Test Plan: I ran yarn run test-typescript and check with Webstorm and VSCode.
Reviewed By: rshest
Differential Revision: D47228992
Pulled By: javache
fbshipit-source-id: fd767bb47c5e64657bfafba4c84d1d8671857109
Summary:
Fixes a regression added [on merge of https://github.com/facebook/react-native/issues/37531](https://github.com/facebook/react-native/commit/260bcf7f1bf78022872eb2f40f33fb552a414809#diff-16a358d6a9dea8469bfdb899d0990df1c32b8c3b1149c86685bec81f50bd24beR179) (though oddly I don't see it in [https://github.com/facebook/react-native/issues/37531's diff](https://github.com/facebook/react-native/pull/37531/files#diff-16a358d6a9dea8469bfdb899d0990df1c32b8c3b1149c86685bec81f50bd24beR179), so perhaps added during conflict resolution?) where multiple arguments in `$EXTRA_COMPILER_ARGS` are now incorrectly wrapped in quotes, including RN's own sourcemap support:
```
runner@SeansMacBookGo sampleapp % /Users/runner/builds/y_x6gsp4/0/sampleapp/ios/Pods/hermes-engine/destroot/bin/hermesc -emit-binary -max-diagnostic-width=80 '-O -output-source-map' -out /Users/runner/builds/y_x6gsp4/0/sampleapp/ios/build/derived-data/Build/Intermediates.noindex/ArchiveIntermediates/sampleapp/BuildProductsPath/Release-iphoneos/sampleapp.app/main.jsbundle /Users/runner/builds/y_x6gsp4/0/sampleapp/ios/build/derived-data/Build/Intermediates.noindex/ArchiveIntermediates/sampleapp/BuildProductsPath/Release-iphoneos/main.jsbundle
hermesc: Unknown command line argument '-O -output-source-map'. Try: '/Users/runner/builds/y_x6gsp4/0/sampleapp/ios/Pods/hermes-engine/destroot/bin/hermesc -help'
hermesc: Did you mean '-output-source-map'?
```
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [FIXED] - Fix build error when there are multiple EXTRA_COMPILER_ARGS
Pull Request resolved: https://github.com/facebook/react-native/pull/38147
Test Plan: Removing the quotes and running the command results a successful run of `hermesc` (exit code 0 and the expected files produced).
Reviewed By: rshest
Differential Revision: D47254412
Pulled By: cipolleschi
fbshipit-source-id: 96b71bb05c7a6939088816e76a9a2d02e89ed768
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38212
This mirrors the same logic that the Hermes team has on facebook/hermes.
Practically, we want to pass the CMake config flag `HERMES_ENABLE_DEBUGGER=False` only for Release
so that their CMake build is configured correctly.
Their build always enables the Debugger and allows us to selectively turn it off only for release
builds.
More context: https://github.com/facebook/hermes/commit/eabf5fcd25
Changelog:
[Internal] [Changed] - Compile hermes-engine with -DHERMES_ENABLE_DEBUGGER=False on Release
Reviewed By: cipolleschi
Differential Revision: D47252735
fbshipit-source-id: 9b5cd801dea3b540a3f80b0d0975e05984f1d9b9
Summary:
Fix build failure on iOS with pnpm and use_frameworks! due to cocoapods copying symlinked headers to wrong paths
When using pnpm all packages are symlinked to node_modules/.pnpm to prevent phantom dependency resolution. This causes react-native iOS build to fail because Cocoapods copies headers to incorrect destinations when they're behind symlinks. The fix resolves absolute paths to the header_mappings_dir at pod install time. With absolute paths cocoapods copies the headers correctly.
This commit also adds a few missing header search paths in use_frameworks! mode.
Fixes https://github.com/facebook/react-native/issues/38140
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [FIXED] - Build failure with pnpm and use_frameworks! due to incorrect header paths
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/38158
Test Plan:
1. `pnpm pnpx react-native@latest init AwesomeProject`
2. `cd AwesomeProject`
3. `rm -rf node_modules yarn.lock`
4. `mkdir patches`
5. copy [react-native@0.72.1.patch](https://github.com/facebook/react-native/files/11937570/react-native%400.72.1.patch) to `patches/`
6. Add patch to package.json
```
"pnpm": {
"patchedDependencies": {
"react-native@0.72.1": "patches/react-native@0.72.1.patch"
}
}
```
7. `pnpm install`
8. `cd ios`
9. `NO_FLIPPER=1 USE_FRAMEWORKS=static pod install`
10. `cd ..`
11. `pnpm react-native run-ios`
Hopefully an automated test of building with `pnpm` can be added to CI. I don't know how to make that happen, hopefully someone at facebook can do it.
Reviewed By: dmytrorykun
Differential Revision: D47211946
Pulled By: cipolleschi
fbshipit-source-id: 87640bd3f32f023c43291213b5291a7b990d7e1f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38205
Enable the preprocessor flag to allow debugging when in a debug build. This flag influences the Hermes headers included in the inspector, and causes them to include the debugging functionality.
Changelog:
[General][Fixed] - Re-enabled debugging for debug builds
Reviewed By: lunaleaps, cortinico
Differential Revision: D47243235
fbshipit-source-id: 7982c69ab554335a9ad985394e4416ed69831137
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38202
## Context
Native modules can synthesize these bridge/bridgeless-agnostic abstractions:
- viewRegistry_DEPRECATED
- bundleManager
- callableJSModules
- moduleRegistry
## The Problem
The TurboModule interop layer wasn't attaching these abstractions to legacy modules.
## The Issue
In Bridgeless mode, the React instance attaches these abstractions to **all** modules, by implementing TurboModuleManagerDelegate.
But, the TurboModuleManager creates legacy modules without calling into the TurboModuleManagerDelegate. So, legacy modules never had these abstractions attached.
## The Fix
Move the attachment logic to within TurboModuleManager.
Changelog: [Internal]
Reviewed By: dmytrorykun
Differential Revision: D47074304
fbshipit-source-id: 87408106c00db8011740068ac0bd7dacd6b5ff81
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38203
The TurboModule system should just assume that RCTTurboModuleEnabled() is true.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D47074303
fbshipit-source-id: 7b360ff10966d4b20206231f4200f3f474ddff8f
Summary:
Adding paragraphStyle.maximumLineHeight to a iOS UITextField displays the text under the UITextField ([ios-screenshot-1][1], [ios-screenshot-2][2], [ios-screenshot-3][3]). The issue reproduces on Storyboard App (iOS) using UITextField and paragraphStyle.maximumLineHeight. It is not caused by react-native.
[1]: https://user-images.githubusercontent.com/24992535/238834159-566f7eef-ea2d-4fd4-a519-099b0a12046c.png "ios-screenshot-1"
[2]: https://user-images.githubusercontent.com/24992535/238834184-feb454a9-6504-4832-aec8-989f1d027861.png "ios-screenshot-2"
[3]: https://user-images.githubusercontent.com/24992535/238834283-cf572f94-a641-4790-92bf-bbe43afb1443.png "ios-screenshot-3"
The issue is caused by a private class _UITextLayoutFragmentView (a CALayer children of UITextField), which assumes the wrong position when setting the lineHeight. _UITextLayoutFragmentView frame's y coordinates are set to 30, instead of 0 ([react-native-screenshot-1][4], [react-native-screenshot-2][5])
- The _UITextLayoutFragmentView layer does not correctly position
- The issue is caused by adding paragraphStyle.maximumLineHeight to UITextField.attributedText
- The parent UITextField bounds do not correctly position child _UITextLayoutFragmentView.
The issue causes the below text Sdfsd to display under the TextInput.
[4]: https://github.com/Expensify/App/assets/24992535/06726b45-7e35-4003-9fcc-50c8d0dff0f6
[5]: https://github.com/Expensify/App/assets/24992535/d9745d29-8863-4170-bcc3-e78fa7e550d2
I was able to fix the issue and correctly align the private layout view _UITextLayoutFragmentView using the public API RCTUITextField textRectForBound, which allows modifying the UITextField frame and inset.
The solution consists in the following steps, applied only to UITextField with lineHeight prop:
1) set _UITextLayoutFragmentView to vertically align to the top. Required to correctly align _UITextLayoutFragmentView.
2) apply custom bounds with RCTUITextField textRectForBound to align _UITextLayoutFragmentView with the correct y coordinates and height
2) Adjust text baseline to be center aligned
fixes https://github.com/facebook/react-native/issues/28012
## Changelog:
[IOS] [FIXED] - Fix TextInput vertical alignment issue when using lineHeight prop on iOS (Paper - old arch)
Pull Request resolved: https://github.com/facebook/react-native/pull/37465
Test Plan: Extensive test included in the PR comments https://github.com/facebook/react-native/pull/37465#issuecomment-1551459879
Reviewed By: NickGerleman
Differential Revision: D46086661
Pulled By: sammy-SC
fbshipit-source-id: faece0940b153f3525ddcfae9417e943c957a5bf