Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50193
This fix makes sure that we convert to JSException only NSException thrwn by sync methods.
Currently, nothing in the stack will be capable of understanding that js error if it is triggered by an exception raised by an asyc method.
See https://github.com/reactwg/react-native-new-architecture/discussions/276 for further details
We need to cherry pick this in 0.78 and 0.79
## Changelog:
[iOS][Fixed] - Make sure the TM infra does not crash on NSException when triggered by async method
Reviewed By: fabriziocucci
Differential Revision: D71619229
fbshipit-source-id: b87aef5dd2720a2641c8da0904da651866370dc6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50091
Changelog: [internal]
If a library uses mount hooks to perform mount operations, it's possible to get concurrent modifications of the list of pending surface IDs to report.
This fixes that potential error by making a copy of the list before dispatching the mount notifications.
Fixes https://github.com/facebook/react-native/issues/49783.
Reviewed By: javache
Differential Revision: D71387739
fbshipit-source-id: 96c723ef2d6bcc659c4452434b7a4d5af26117ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50090
Changelog: [internal]
I refactored `FabricUIManager` in D54547194 / https://github.com/facebook/react-native/pull/43337 and accidentally removed setting this flag to avoid scheduling redundant tasks in the UI thread to report mount. This fixes it.
Reviewed By: javache
Differential Revision: D71387374
fbshipit-source-id: cad8a3ead2434738325560902cbab817e5d5dde7
Summary:
Currently we observed many iOS app crashes caused by the `[RCTFileRequestHanlder invalidate]` method, just as the below screenshot.
<img width="1008" alt="image" src="https://github.com/user-attachments/assets/d2d6714f-63d9-40ae-8de5-742cfe718a36" />
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [FIXED] - app crash caused by the `[RCTFileRequestHanlder invalidate]` method
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [FIXED] - app crash caused by the `[RCTFileRequestHanlder invalidate]` method
Pull Request resolved: https://github.com/facebook/react-native/pull/48350
Test Plan: I am not able to reproduce this issue locally either, so the changes in this PR are totally from my inference, I am not sure if it really makes sense, so please help take a deeper look, thanks.
Reviewed By: javache
Differential Revision: D69751695
Pulled By: cipolleschi
fbshipit-source-id: aa4654a30f5dfac99b72ed1bda0dae1e0dc881c9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49931
This change fixes the app startup in the Old Architecture by implementing the loadSourceForBridge:onProgress:onComplete method in the RCTDefaultReactNativeFactoryDelegate object.
The method was missing here, so the Bridge was never trying to load the JS bundle from Metro, resulting in an empty app.
## Changelog:
[iOS][Fixed] - Implement the loadSourceForBridge:onProgress:onComplete in the RCTDefaultReactNativeFactoryDelegate.
Reviewed By: cortinico
Differential Revision: D70898811
fbshipit-source-id: 3e5d519a1965e92ace91ca6d5b316a9069279448
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49900
This appears to fix an issue where removing a sibling with zIndex breaks drawing of the next sibling. The theory is that eager return in `onViewRemoved` prevents the view from reverting into a state where it no longer uses custom draw order. However, tracing back history, this eager return was [added](https://github.com/facebook/react-native/pull/43389) to fix a bug in Reanimated. cc bartlomiejbloniarz to confirm if [this Reanimated issue](https://github.com/software-mansion/react-native-reanimated/issues/5715) resurfaces from this change.
Fixes#49838
## Changelog
[Android][Fixed] Fixes issue with z-indexed sibling removal
Reviewed By: NickGerleman, cipolleschi
Differential Revision: D70795631
fbshipit-source-id: 500af92226be29af73f36f911ffff27a0c083ae9
Summary:
fix: https://github.com/facebook/react-native/issues/49368
description is provided inside the ticket.
When we use TextInput on ios and manage selection with the selection prop, TextInput is reset when we change selection.
## Changelog:
[IOS] [FIXED] - Fix selection makes TextInput clear its content when using children
Pull Request resolved: https://github.com/facebook/react-native/pull/49450
Test Plan:
Tested with sample provided in ticket.
I also test it with my app on both android and ios, but I cannot share video
Reviewed By: sammy-SC
Differential Revision: D69984616
Pulled By: cipolleschi
fbshipit-source-id: a17169608f9df0ea1cb579e6038345f8e48bbc27
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49873
In the old architecture, when we were passing a `null` value as a parameter in a function that accepted nullable parameter, the null value was mapped to `nil` on iOS.
After my changes in [d4236791e2](https://github.com/facebook/react-native/commit/d4236791e238a614d2fadf5c5659874d983ab029), in the New Architecture, through the interop layer, legacy modules were receiving an `NSNull` object instead of nil.
This was breaking those modules which started crashing or observing undesired behavior.
This change fixes the issue by making sure that, in those cases, a `nil` value is passed.
Note that nested objects in the old architecture were correctly receiving NSNull, so nested objects were behaving correctly already.
## Changelog:
[iOS][Fixed] - Properly pass `nil` for nullable parameters instead of `NSNull` for legacy modules
Reviewed By: javache
Differential Revision: D70723460
fbshipit-source-id: 384f48b6dbb3f54c369b31b6d2ee06069fa3591c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49518
`react-native/community-cli-plugin` depends on `createDevServerMiddleware` from `react-native-community/cli-server-api`.
`react-native/community-cli-plugin` currently [declares an optional peer dependency](https://github.com/facebook/react-native/blob/bae895500052bda2f55e1832b0c8a63a1b449de3/packages/community-cli-plugin/package.json#L39-L45) on `react-native-community/cli-server-api`, however because the latter isn't a dependency of `react-native` or the community template, the peer dependency is not available to package managers that enforce isolated node_modules - see https://github.com/facebook/react-native/issues/47309.
Rather than add an unnecessary dependency to the template (like [this](https://github.com/react-native-community/template/pull/105)), my proposal is to switch to a peer dependency on only `react-native-community/cli`, because that *is* a dependency of the community template and therefore will be resolvable.
Because `react-native-community/cli` doesn't re-export `createDevServerMiddleware` from its dependency on `cli-server-api`, we need to resolve the latter through the former. This can be cleaned up once a re-export lands - https://github.com/react-native-community/cli/pull/2605.
Changelog:
[GENERAL][FIXED] Fix registering of `start` and `bundle` commands with community CLI and isolated node_modules.
Reviewed By: huntie
Differential Revision: D69848688
fbshipit-source-id: 009b8ffd43b2ab2d84fcc71e9e48382eb8950bb1
Summary:
Fixes https://github.com/facebook/react-native/issues/49819 . Details about how the issue was introduced in the issue description.
bypass-github-export-checks
## Changelog:
[IOS] [FIXED] - Fixed: extraModulesForBridge callback not called when New Architecture enabled
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/49849
Test Plan:
Without the change:
1. Open `packages/rn-tester` project
2. In `AppDelegate.mm`, implement `extraModulesForBridge` and add a breakpoint / output something
3. Run the app in iOS <-- Verify that the method is not executed
With the change:
1-3. Same as above <-- verify that the method is called correctly
> [!NOTE]
> As far as I could tell, there is no test suite for this specific codepath, so I didn't write a test for this change. Happy to write one if someone can guide me a little bit.
Reviewed By: rshest
Differential Revision: D70724196
Pulled By: cipolleschi
fbshipit-source-id: cc08798d08cdbd6883347810c7d2697c358770fb
Summary:
`loadSourceForBridge` is broken after we refactor the appdelegate. So let's add it back.
## Changelog:
[IOS] [FIXED] - Added custom load js block in bridge mode
Pull Request resolved: https://github.com/facebook/react-native/pull/48845
Test Plan: Custom Appdelegate's `loadSourceForBridge` can be called in bridge mode.
Reviewed By: robhogan
Differential Revision: D68832046
Pulled By: cipolleschi
fbshipit-source-id: dcea791e6d8243fdb2f45a33af175aee1a4e1223
Summary:
This change adds an opt-in to restore JavaScript log streaming via the Metro dev server, [removed from React Native core in 0.77](https://reactnative.dev/blog/2025/01/21/version-0.77#removal-of-consolelog-streaming-in-metro).
Users can opt into this legacy behaviour by adding the `--client-logs` flag to `npx react-native-community/cli start`.
- The default experience remains without streamed JS logs.
- The existing "JavaScript logs have moved! ..." notice is printed in all cases, and we do not advertise the new flag for new users.
- Under non-Community CLI dev servers (i.e. Expo), log streaming is restored implicitly.
We will clean up this functionality again when we eventually remove JS log streaming over `HMRClient`, tasked in T214991636.
**Implementation notes**
- Logs are always sent over `HMRClient` (previous status quo), even with log streaming off in the dev server. This is a necessary evil to be able to flag this functionality in a user-accessible place, and to move fast for 0.78.
- Necessarily, emitting `fusebox_console_notice` moves to the dev server itself, on first device (Fusebox) connection.
Changelog:
[General][Added] - Add opt in for legacy Metro log streaming via `--client-logs` flag
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49300
With the refactor of the AppDelegate in favor ReactNativeFactory, the users can now instantiate multiple instances of react native.
However, currently, if you try to run multiple instances, the app will crash with the message:
```
libc++abi: terminating due to uncaught exception of type std::runtime_error: Feature flags cannot be overridden more than once
```
This happens also when the feature flags we would like to set are the same that we already applied. This should be an allowed scenario because reapplying the excatly same features flags should have no effect on React native and that's not the use case we want to forbid.
With this change, we are creating a static variable that checks whether we already apply that set of feature flags and it allows you to create multiple instances by keeping the same flags
## Changelog:
[iOS][Fixed] - Allow multiple RN instances to run at the same time
Reviewed By: rubennorte
Differential Revision: D69398441
fbshipit-source-id: a377c6a1402d38d66d348fa8c6a65e645973aadc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49229
This interface was converted to Kotlin, but the single method should have been converted to a `val`.
People kotlin consumers could call ReactOverflowView.overflow; now they need to call getOverflow().
Changelog:
[Internal] [Changed] - Undo a breaking change on ReactOverflowView
Reviewed By: NickGerleman
Differential Revision: D69250226
fbshipit-source-id: 5c7cca8c83f5c76a9cc1d254f8aa51409150c356
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49233
I'm converting the function inside ReactPointerEventsView from `fun` to `val`.
This Kotlin conversion resulted in a breakign change for Kotlin consumer which I believe can be prevented
if we do this change instead.
Changelog:
[Internal] [Changed] -
Reviewed By: alanleedev
Differential Revision: D69252562
fbshipit-source-id: b277c6720f3156ed532bf5f2253d54cd72e38050
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48823
This diff is fixing the execution of Events that are sent early in the rendering of surfaces.
This diff fixes a bug in the queueing of events that are built with not surfaceId (-1), the fixes is to call getSurfaceManagerForView() to retrieve the proper surfaceId (as we do in the execution of events)
calling getSurfaceManagerForView() has a perf hit, we believe this won't be a problem because this method will only be called in edge cases (no surfaceId and early execution of events)
changelog: [Android][Fixed] Fix execution of early InteropEvents
Reviewed By: shwanton, lenaic
Differential Revision: D68454811
fbshipit-source-id: a79be0b392004e645c48d1683bba774b6b597ca0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49072
We have instance of apps crashing when enabling the New Architecture because of the TurboModule interop layer.
What's happening is that when the module is loaded, the TM Interop Layer tries to parse the method definition to expose them in JS. However, for some libraries in the Legacy Architecture, it is possible to define a method in Objective-C and to define a different signature in Swift.
For example, the [`RNBluetoothClassic` library](https://github.com/kenjdavidson/react-native-bluetooth-classic) defines a selector in objective-c which [has the signature](https://github.com/kenjdavidson/react-native-bluetooth-classic/blob/main/ios/RNBluetoothClassic.m#L134-L136)
```
RCT_EXTERN_METHOD(available: (NSString *)deviceId
resolver: (RCTPromiseResolveBlock)resolve
rejecter: (RCTPromiseRejectBlock)reject)
```
And the method is inmplemented in Swift with [the signature](https://github.com/kenjdavidson/react-native-bluetooth-classic/blob/main/ios/RNBluetoothClassic.swift#L502-L505):
```
func availableFromDevice(
_ deviceId: String,
resolver resolve: RCTPromiseResolveBlock,
rejecter reject: RCTPromiseRejectBlock
)
```
When the TurboModule interop layer tries to parse the method, it receives the `accept:resolver:rejecter:` signature, but that signature is not actually defined in as a method in the module instance, and it crashes.
This crash was not happening in the Old Architecture, which was handling this case gracefully. Notice that the specific method from the example is not working in the Old Architecture either. However, the app is not crashing in the old architecture.
This change adds the same graceful behaviors plus it adds a warning in development to notify the developer about which methods couldn't be found in the interface.
Fixes:
- https://github.com/facebook/react-native/issues/47587
- https://github.com/facebook/react-native/issues/48065
## Changelog:
[iOS][Fixed] - Avoid crashing the app when the InteropLayer can't find some methods in the native implementation.
Reviewed By: javache
Differential Revision: D68901734
fbshipit-source-id: 844d1bf29423d5c601b583540e86d57dfffd1428
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48995
This change adds an extra parameter to the codegen script that allow our users to trigger codegen for Apps or for Libraries.
When running codegen for Apps, we have to generate some extra files that are not needed by the Libraries. This is causing issues to our library maintainers and this change will provide more flexibility in the DevX of libraries.
The default value is App, so if the new parameter is not passed, nothing will change in the current behavior.
[iOS][Added] - Add the `source` parameter to generate-codegen-artifacts to avoid generating files not needed by libraries.
Reviewed By: cortinico
Differential Revision: D68765478
fbshipit-source-id: 8030b4472ad4f5058e58b1c91089de5122a4f60a
Summary:
The `maxFontSizeMultiplier` prop for `Text` and `TextInput` was not handled in Fabric / New Architecture as documented in https://github.com/facebook/react-native/issues/47499.
bypass-github-export-checks
## Changelog:
[GENERAL] [FIXED] - Fix `maxFontSizeMultiplier` prop on `Text` and `TextInput` components in Fabric / New Architecture
Pull Request resolved: https://github.com/facebook/react-native/pull/47614
Test Plan:
I have not added any automated tests for this change but try to do so if requested. I have however added examples to RN Tester for both the Text and TextInput components, as well as compared the behaviour with Paper / Old Architecture. Both on version 0.76.
Noticed now I didn't do exactly the same steps in both videos, oops! Be aware that reapplying changes made in the Settings are currently half-broken on the new architecture, thus I'm restarting the app on Android and iOS. But this issue is unrelated to my changes. I've tested on main branch and it has the same issue.
Here are comparison videos between Paper and Fabric on iOS *after* I've made my fix.
### Text
| Paper | Fabric |
| ------------- | ------------- |
| <video src="https://github.com/user-attachments/assets/f4fd009f-aa6d-41ab-92fa-8dcf1e351ba1" /> | <video src="https://github.com/user-attachments/assets/fda42cc6-34c2-42a7-a6e2-028e7c866075" /> |
### TextInput
| Paper | Fabric |
| ------------- | ------------- |
| <video src="https://github.com/user-attachments/assets/59b59f7b-25d2-4b5b-a8e2-d2054cc6390b" /> | <video src="https://github.com/user-attachments/assets/72068566-8f2a-4463-874c-45a6f5b63b0d" /> |
Reviewed By: Abbondanzo
Differential Revision: D65953019
Pulled By: cipolleschi
fbshipit-source-id: 90c3c7e236229e9ad9bd346941fafe4af8a9d9fc
Summary:
This is another attempt at fixing the Android HMR client for HTTPS proxied Metro instances. The previous one unintentionally [caused the following error](https://github.com/facebook/react-native/pull/48970#issuecomment-2617047184):
```
java.lang.AssertionError: Method overloading is unsupported: com.facebook.react.devsupport.HMRClient#setup
```
This PR removes the overloading, and only adds the `scheme` property as a parameter to the existing `.setup` method. Aligning with the exact behavior we have on iOS.
The alternative fix, which should NOT be backward breaking (if this is) - is to move this "infer the protocol from the bundle URL" to the JS side of the HMR client. Where we don't just always default to `http`, but instead default to `https IF port === 443, otherwise http`. It's a bit more hacky, but shouldn't cause any other issues. _**Ideally**_, we have the same working behavior on both Android and iOS without workarounds.
<details><summary>Alternative workaround</summary>
See [this change](https://github.com/facebook/react-native/compare/main...byCedric:react-native:patch-2).
<img width="1179" alt="image" src="https://github.com/user-attachments/assets/47c365bc-6df8-43e6-ad7d-5a667e350cd4" />
</details>
See full explanation on https://github.com/facebook/react-native/issues/48970
> We've noticed that the HMR on Android doesn't seem to be connecting when using a HTTPS-proxied Metro instance, where the proxy is hosted through Cloudflare. This is only an issue on Android - not iOS - and likely caused by the HMR Client not being set up properly on Android.
>
>- On Android, we run `.setup('android', <bundleEntryPath>, <proxiedMetroHost>, <proxiedMetroPort>, <hmrEnabled>)` in the [**react/devsupport/DevSupportManagerBase.java**](https://github.com/facebook/react-native/blob/53d94c3abe3fcd2168b512652bc0169956bffa39/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/devsupport/DevSupportManagerBase.java#L689-L691) file.
>- On iOS, we run `[self.callableJSModules invokeModule:@"HMRClient" method:@"setup" withArgs:@[ RCTPlatformName, path, host, RCTNullIfNil(port), @(isHotLoadingEnabled), scheme ]];` in the [**React/CoreModules
/RCTDevSettings.mm**](https://github.com/facebook/react-native/blob/53d94c3abe3fcd2168b512652bc0169956bffa39/packages/react-native/React/CoreModules/RCTDevSettings.mm#L488-L491) file.
>
>Notice how Android does not pass in the scheme/protocol of the bundle URL, while iOS actually does? Unfortunately, because the default protocol (`http`) mismatches on Android when using HTTPS proxies, we actually try to connect the HMR client over `http` instead of `https` - while still using port 443 - which is rejected by Cloudflare's infrastructure even before we can redirect or mitigate this issue. And the rejection is valid, as we basically try to connect on `http://<host>:443` (the source URL is `https`, so the port is infered as `443`).
>
>This change adds scheme propagation to Android, exactly like we do on iOS for the HMR Client.
## Changelog:
[ANDROID] [FIXED] Pass the bundle URL protocol when setting up HMR client on Android
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/48998
Test Plan:
See full explanation on https://github.com/facebook/react-native/issues/48970
> It's a little bit hard to test this out yourself, since you'd need a HTTPS-based proxy and reject HTTP connections for HTTPS/WSS Websocket requests.
>
>You can set this up through:
>- `bun create expo@latest ./test-app`
>- `cd ./test-app`
>- `touch .env`
>- Set `EXPO_PACKAGER_PROXY_URL=https://<proxied-metro-hostname>` in **.env**
>- Set `REACT_NATIVE_PACKAGER_HOSTNAME=<proxied-metro-hostname>` in **.env**
>- `bun run start`
>
>Setting both these envvars, the bundle URL in the manifest is set to `https://...` - which triggers this HMR issue on Android. You can validate the **.env** setup through:
>
>```bash
>curl "http://localhost:8081" -H "expo-platform: android" | jq .launchAsset.url
>```
>
>This should point the entry bundle URL towards the `EXPO_PACKAGER_PROXY_URL`.
Reviewed By: cortinico
Differential Revision: D68768351
Pulled By: javache
fbshipit-source-id: 49bf1dc60f11b2af6e57177141270632d62ab564
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48888
We have a report from OSS where Images are not displayed properly in case they are saved on disk with no extension.
We previously had a fix attempt iwith [this pr](https://github.com/facebook/react-native/pull/46971), but this was breaking some internal apps.
This second attempt should work for both cases.
## Changelog:
[iOS][Fixed] - Load images even when the extension is implicit
Reviewed By: cortinico
Differential Revision: D68555813
fbshipit-source-id: bc25970aafe3e6e5284163b663d36e00b3df3d82
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48715
{D68154908} fixed a problem with the `onAnimatedValueUpdate` listener not being correctly attached if `__attach` were called before `__makeNative` (which sets `__isNative` to true).
We're potentially seeing production symptoms of stuttering interactions and user responsiveness, after queuing up many operations. Our hypothesis is that in scenarios where `ensureUpdateSubscriptionExists` is being called during `__makeNative` (instead of during `__attach`), a backup of operations occurs leading to these symptoms.
This diff attempts to validate and mitigate this hypothesis by deferring `ensureUpdateSubscriptionExists` to when an `AnimatedValue` instance has had both `__attach` and `__makeNative` invoked.
Changelog:
[Internal]
Differential Revision: D68236594
fbshipit-source-id: 2089100a773ebfc161fb5b567123eb58a893939f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48678
While diagnosing a recent issue in which `AnimatedValue` instances were not being correctly updated as expected, the insertion effects feature flag was identified as a root cause.
Upon further investigation, it appears that this is because the `onUserDrivenAnimationEnded` listener was not implemented the same way in the two feature flag states:
- When `useInsertionEffectsForAnimations` is disabled, `useAnimatedProps` listens to `onUserDrivenAnimationEnded` in a passive effect, after all nodes have been attached.
- When `useInsertionEffectsForAnimations` is enabled, `useAnimatedProps` listens to `onUserDrivenAnimationEnded` in an insertion effect when attaching nodes.
The bugs occurs because `useAnimatedProps` checks whether native driver is employed to decide whether to listen to `onUserDrivenAnimationEnded`. However, we do not know whether native driver will be employed during the insertion effect. (Actually, we do not necessarily know that in a passive effect, either... but that is a separate matter.)
This fixes the bug when that occurs when `useInsertionEffectsForAnimations` is enabled, by moving the listening logic of `onUserDrivenAnimationEnded` into a passive effect. This is the same way that it is implemented when `useInsertionEffectsForAnimations` is disabled.
Changelog:
[Internal]
Reviewed By: javache, sammy-SC
Differential Revision: D68171721
fbshipit-source-id: 50b23348fd4641580581cacebc920959651f96a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48672
## Changelog:
[General] [Fixed] - Buttons becoming unresponsive when transform is animated
# The problem
D67872307 changes when `ensureUpdateSubscriptionExists` is called to in `__attach`. This breaks the functionality because `__attach` is called before flag `__isNative` is set and subscriptions are never setup.
# Fix
The diff sets up subscriptions in `__makeNative` method.
Reviewed By: yungsters
Differential Revision: D68154908
fbshipit-source-id: e2ac108b064a66dda08902653d6bd20286f92458
Summary:
## Changelog:
[iOS] [Fixed] - Fix app becoming unresponsive when RefreshControl is used inside of <Modal />
Fixes: https://github.com/facebook/react-native/issues/48579
This is a UIKit bug. Switching to `didMoveToSuperview` resolves it.
Reviewed By: cipolleschi
Differential Revision: D68025099
fbshipit-source-id: 5d5e730f002ca93748674655a8393b770dc11611
Co-authored-by: kkafar <kacperkafara@gmail.com>
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48556
Changelog: [Internal]
the only place in view module that uses folly is `ViewPropsInterpolation.h` and that is only on Android.
This diff makes that dependency explicit and make it android only.
Reviewed By: javache
Differential Revision: D67942951
fbshipit-source-id: 2a1a41f5a4caba553e81d4bb78ac9c84ba90b60b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48584
[Changelog] [Internal] - Align logic in BaseTextInputShadowNode to calculate placeholder string with AndroidTextInputShadowNode
As a preparation for https://github.com/facebook/react-native/pull/48165 this aligns the implementation of those 2 methods
Reviewed By: NickGerleman
Differential Revision: D68004218
fbshipit-source-id: 722a33bb2665c59347ef1b0cd8ed7b35a05b2113
React Native Bot
Riccardo Cipolleschi
Rubén Norte
Zhi Zhou
Eric Rozell
Olivier Bouillet
Rob Hogan
Mateo Guzmán
zhongwuzw
Bruno Aybar
Tomas Polovincak
Alex Hunt
David Vacca
Pieter De Baets
Nicola Corti
Rob Hogan
Rickard Zrinski
Cedric van Putten
Tim Yung
Samuel Susla
Ilia Sidorenko
Dawid Małecki
Christoph Purrer
