Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51048
Fixes https://github.com/facebook/react-native/issues/50442
Closes https://github.com/facebook/react-native/pull/50704
Users reported that Modals on Android are first renderer anchored in 0,0.
That results in them being on the top left corner of the screen for some seconds.
This is happening because the native state of the Modal on Android as width/height set at 0,0 - which we then update in a subsequent callback.
I'm fixing this by making sure we render the Modal the first time with the right screen size - the status bar size
Changelog:
[Android] [Fixed] - Fix Modal first frame being rendered on top-left corner
Reviewed By: javache
Differential Revision: D73948178
fbshipit-source-id: 055c12aa62d70acc1e4c5a2a5c4ea0c5608e22c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52378
This adds a Gradle property called `exclusiveEnterpriseRepository`
that users can set in their `android/gradle.properties` as such:
```diff
hermesEnabled=true
+exclusiveEnterpriseRepository=https://my.internal.proxy.net/
```
This will remove all the existing Maven repositories and only use the internal mirror they have.
Changelog:
[Android] [Added] - RNGP - Add support for `exclusiveEnterpriseRepository` to specify an internal Maven mirror.
Reviewed By: mdvacca
Differential Revision: D77667573
fbshipit-source-id: 835004d2ae7aa4e250b6f7a88a41918b573f5bd5
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:
See https://github.com/facebook/react-native/issues/51212 - children aren't updated correctly in an old arch native view using the interop layer under Fabric.
This is caused by the mountChildComponentView method not updating the view, only adding the new view to a list that will be used on the next update to mount the child.
This commit fixes this by adding the same pattern as in unmountChildComponentView where children are inserted directly if the underlying paperview is available in the adapter - otherwise it uses the mounting list as before.
#Closes 51212
bypass-github-export-checks
## Changelog:
[IOS] [FIXED] - fixed adding child views to a native view using the interop layer
Pull Request resolved: https://github.com/facebook/react-native/pull/51213
Test Plan:
**Previous output**:
<image src="https://github.com/user-attachments/assets/472b95e7-0921-46c9-be6a-f31759c0cd26" width="200px" />
**After fix**:
<image src="https://github.com/user-attachments/assets/554387cd-c264-483e-9c52-d9cd40b42601" width="200px" />
Reviewed By: sammy-SC
Differential Revision: D74471278
Pulled By: cipolleschi
fbshipit-source-id: 798f9e7be389359bd6e3aa1b6a6e9fb799fcb369
Summary:
Calls to create timers should return sequential ids (integers greater than zero in the spec's words). This regressed in the `TimerManager` implementation, which instead starts at zero inclusively.
This has two side-effects for code assuming a spec-compliant implementation of `setTimeout` and `setInterval`:
- Calls to `clearTimeout(0)` or `clearInterval(0)` will potentially cancel scheduled timers, although it's supposed to be a noop
- Predicates like `if (timeoutId)` will fail since they assume non-negative ids
The change in this PR is to align with WHATWG HTML 8.6.2 (Timers): https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timers
> otherwise, let id be an [implementation-defined](https://infra.spec.whatwg.org/#implementation-defined) integer that is **greater than zero** and does not already [exist](https://infra.spec.whatwg.org/#map-exists) in global's [map of setTimeout and setInterval IDs](https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#map-of-settimeout-and-setinterval-ids).
Specifically,
- we should return `0` to indicate that no timer was scheduled
- we should start generating timer IDs at `1` instead of `0`
This was previously raised in review comments here: https://github.com/facebook/react-native/pull/45092/files#r1650790008
The spec-incompliant behaviour was raised in an issue here: https://github.com/apollographql/apollo-client/issues/12632#issue-3075269978
This PR does not,
- add bounds checking on `timerIndex_` and add a search of an available id that isn't in the unordered map
- exclude `0` from being an accepted `TimerHandle` in `TimerManager::createTimer` or `TimerManager::deleteTimer` since the above bounds checking hasn't been added either
## Changelog:
[GENERAL] [FIXED] - Align timer IDs and timer function argument error handling with web standards.
Pull Request resolved: https://github.com/facebook/react-native/pull/51500
Test Plan:
- Run `setTimeout` / `setInterval`; before applied changes the timeout for the first timer will be `0`
- Run `setTimeout(null)`; before applied changes the timer ID will be non-zero
- Run `setInterval(null)`; before applied changes an error will be thrown rather than `0` being returned
Reviewed By: cipolleschi
Differential Revision: D75145909
Pulled By: rshest
fbshipit-source-id: 6646439abd29cf3cfa9e5cf0a57448e3b7cd1b48
Summary:
Fixes https://github.com/facebook/react-native/issues/38537
Setting `WindowManager.LayoutParams.FLAG_SECURE` in the window flags is not respected in the Android Modal component, causing security issues with screenshots or screen recordings as the content in the modal is visible. The flag works correctly in the rest of the components, see the videos in the linked issue.
This PR addresses that by checking whether this flag is set in the current activity and then setting it in the dialog when creating a new one in the `ReactModalHostView`.
## Changelog:
[ANDROID][FIXED] - `FLAG_SECURE` not respected in Modal dialog
Pull Request resolved: https://github.com/facebook/react-native/pull/48317
Test Plan:
To test this, you need a physical device as with the emulator the flags don't seem to be respected either.
The easiest way to test this in code is by setting the flags in the main activity. You can do so by adding this code snippet:
<details>
<summary>onCreate in RNTesterApplication.kt</summary>
```kt
override fun onCreate() {
ReactFontManager.getInstance().addCustomFont(this, "Rubik", R.font.rubik)
super.onCreate()
...
registerActivityLifecycleCallbacks(
object : ActivityLifecycleCallbacks {
override fun onActivityCreated(activity: Activity, savedInstanceState: Bundle?) {
activity.window.setFlags(
WindowManager.LayoutParams.FLAG_SECURE,
WindowManager.LayoutParams.FLAG_SECURE
)
}
override fun onActivityStarted(activity: Activity) {}
override fun onActivityResumed(activity: Activity) {}
override fun onActivityPaused(activity: Activity) {}
override fun onActivityStopped(activity: Activity) {}
override fun onActivitySaveInstanceState(activity: Activity, outState: Bundle) {}
override fun onActivityDestroyed(activity: Activity) {}
}
)
}
```
</details>
Then, you can render a simple modal component:
<details>
<summary>RNTesterPlayground.js</summary>
```tsx
function Playground() {
const [modalVisible, setModalVisible] = React.useState(false);
return (
<>
<Modal
visible={modalVisible}
testID="playground-modal">
<Text testID="inner-text-test-id">Hello World!</Text>
<Button title="Close Modal" onPress={() => setModalVisible(false)} />
</Modal>
<Button
title="Open Modal"
onPress={() => {
setModalVisible(true);
}}
/>
</>
);
}
```
</details>
You can then try to record the screen or take screenshots. You will notice that before opening the modal, you won't be able to see anything in the recording, but when opening the modal, the content is visible.
I've tried my best to record the before and after the fix, but as the screen recordings will mostly show a black screen, you have to forward a bit in both videos to see the difference.
<details>
<summary>Before the fix (notice the blank screen and then content visible)</summary>
https://github.com/user-attachments/assets/fc5bbe26-d238-425b-90d3-0e43c89ccaac
</details>
<details>
<summary>After the fix (notice all the screen recording is a black screen)</summary>
https://github.com/user-attachments/assets/0d6991a0-974b-45c5-8f4a-bf4718c284e6
</details>
Reviewed By: cipolleschi
Differential Revision: D67368741
Pulled By: alanleedev
fbshipit-source-id: 9f31063a9208a6df257da424bf3096bf15a5ddcb
Summary:
This fixes an issue in Fabric where changing the layout direction and then reloading the JS bundle did not honor the layout direction until the app was restarted on iOS. This now calls `_updateLayoutContext` whenever RCTSurfaceView is recreated which happens on bundle reload. This is not an issue on the old architecture because the layout direction is determined within the [SurfaceViews](https://github.com/facebook/react-native/blob/acdddef48eb60b002c954d7d2447cb9c2883c8b3/packages/react-native/React/Views/RCTRootShadowView.m#L18) which were recreated on bundle reload.
## Related Issues:
- https://github.com/react-native-community/discussions-and-proposals/issues/847
- https://github.com/facebook/react-native/issues/49451
- https://github.com/facebook/react-native/issues/48311
- https://github.com/facebook/react-native/issues/45661
## How can we take this further?
If we want to make it so that it doesn't require an entire bundle reload for RTL to take effect I believe these are the steps that would need to be taken:
- Make it so [RCTI18nManager](https://github.com/facebook/react-native/blob/acdddef48eb60b002c954d7d2447cb9c2883c8b3/packages/react-native/React/CoreModules/RCTI18nManager.mm#L52) exports isRTL as a method instead of consts
- Send Notification Center notif when RTL is forced on or off
- Listen for that notification RCTSurfaceView and call _updateLayoutContext similar to UIContentSizeCategoryDidChangeNotification.
## Changelog:
[iOS] [FIXED] - Layout direction changes are now honored on bundle reload.
<!-- 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/49455
Test Plan:
On the new architecture change force the layout direction and reload the bundle:
```
import React, { useCallback } from "react";
import { Button, I18nManager, StyleSheet, Text, View } from "react-native";
import RNRestart from "react-native-restart";
export default function Explore() {
const onApplyRTL = useCallback(() => {
if (!I18nManager.isRTL) {
I18nManager.forceRTL(true);
RNRestart.restart();
}
}, []);
const onApplyLTR = useCallback(() => {
if (I18nManager.isRTL) {
I18nManager.forceRTL(false);
RNRestart.restart();
}
}, []);
return (
<View style={styles.area}>
<Text>Test Block</Text>
<View style={styles.testBlock}>
<Text>Leading</Text>
<Text>Trailing</Text>
</View>
<Button title={"Apply RTL"} onPress={onApplyRTL} />
<Button title={"Apply LTR"} onPress={onApplyLTR} />
</View>
);
}
const styles = StyleSheet.create({
area: {
marginVertical: 50,
paddingHorizontal: 24,
},
testBlock: {
paddingVertical: 10,
flexDirection: "row",
justifyContent: "space-between",
},
});
```
https://github.com/user-attachments/assets/0eab0d79-de3f-4eeb-abd0-439ba4fe25c0
Reviewed By: cortinico, cipolleschi
Differential Revision: D69797645
Pulled By: NickGerleman
fbshipit-source-id: 97499621f3dd735d466f5119e0f2a0eccf1c3c05
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/50464
Runners in GHA has been updated by github and they now ship with CMake 4.0. (actions/runner-images#11926)
This version is not compatible with React Native, so we are pinning cmake to 3.36.1
## Changelog:
[Internal] - Pin cmake to 3.36.1
Reviewed By: cortinico
Differential Revision: D72379834
fbshipit-source-id: ab09009102118e6590f02cf57fa6f9149482f62b
Summary:
Due to us moving to central.sonatype.com for publishing, we cannot publish and release the Maven repository in 2 distinct invocations.
This consolidates all the publishing job to happen during build_npm_package
Changelog:
[Internal] [Changed] -
Reviewed By: fabriziocucci
Differential Revision: D76888543
fbshipit-source-id: 3cb0db6176ed2221a12b4f3f1f575232aa006a6c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52004
This is necessary because the snapshots are now going to be published on a different repository:
central.sonatype.com.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D76596802
fbshipit-source-id: 424fb1134e41502d53b76209fba325c895c79ba8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51693
This moves React Native to use the Central Portal URLs rather than the legacy OSSRH ones.
See https://github.com/gradle-nexus/publish-plugin for more context.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D75673984
fbshipit-source-id: 1de6746809eed72f232eac0c3fb4d809c2046620
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/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/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:
A NPE can occur when a user touches the screen before the `SurfaceMountingManager` is initialized. Below is an example of the error log from our production service. This issue can also be reproduced using RNTester. To prevent invalid touch events during init time of rn app from causing an NPE, add a null check for SurfaceMountingManager before calling mark/sweepActiveTouchForTag.
```
Fatal Exception: java.lang.NullPointerException: Attempt to invoke virtual method 'void com.facebook.react.fabric.mounting.SurfaceMountingManager.markActiveTouchForTag(int)' on a null object reference
at com.facebook.react.fabric.FabricUIManager.markActiveTouchForTag(FabricUIManager.java)
at com.facebook.react.uimanager.JSTouchDispatcher.markActiveTouchForTag(JSTouchDispatcher.java)
at com.facebook.react.uimanager.JSTouchDispatcher.handleTouchEvent(JSTouchDispatcher.java)
at com.facebook.react.runtime.ReactSurfaceView.dispatchJSTouchEvent(ReactSurfaceView.java)
at com.facebook.react.ReactRootView.onInterceptTouchEvent(ReactRootView.java)
at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2870)
at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3352)
at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2963)
at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3352)
at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2963)
at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3352)
at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2963)
at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3352)
at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2963)
at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3352)
at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2963)
at com.android.internal.policy.DecorView.superDispatchTouchEvent(DecorView.java:794)
at com.android.internal.policy.PhoneWindow.superDispatchTouchEvent(PhoneWindow.java:1967)
at android.app.Activity.dispatchTouchEvent(Activity.java:4571)
at com.rainist.banksalad2.feature.common.BaseActivity.dispatchTouchEvent(BaseActivity.java)
at androidx.appcompat.view.WindowCallbackWrapper.dispatchTouchEvent(WindowCallbackWrapper.java:70)
at com.android.internal.policy.DecorView.dispatchTouchEvent(DecorView.java:752)
at android.view.View.dispatchPointerEvent(View.java:16498)
at android.view.ViewRootImpl$ViewPostImeInputStage.processPointerEvent(ViewRootImpl.java:8676)
at android.view.ViewRootImpl$ViewPostImeInputStage.onProcess(ViewRootImpl.java:8423)
at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:7752)
at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:7809)
at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:7775)
at android.view.ViewRootImpl$AsyncInputStage.forward(ViewRootImpl.java:7978)
at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:7783)
at android.view.ViewRootImpl$AsyncInputStage.apply(ViewRootImpl.java:8035)
at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:7756)
at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:7809)
at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:7775)
at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:7783)
at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:7756)
at android.view.ViewRootImpl.deliverInputEvent(ViewRootImpl.java:11343)
at android.view.ViewRootImpl.doProcessInputEvents(ViewRootImpl.java:11212)
at android.view.ViewRootImpl.enqueueInputEvent(ViewRootImpl.java:11168)
at android.view.ViewRootImpl$WindowInputEventReceiver.onInputEvent(ViewRootImpl.java:11477)
at android.view.InputEventReceiver.dispatchInputEvent(InputEventReceiver.java:337)
at android.os.MessageQueue.nativePollOnce(MessageQueue.java)
at android.os.MessageQueue.next(MessageQueue.java:335)
at android.os.Looper.loopOnce(Looper.java:187)
at android.os.Looper.loop(Looper.java:319)
at android.app.ActivityThread.main(ActivityThread.java:9063)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:588)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1103)
```
https://github.com/user-attachments/assets/e9c6ff84-c94d-4392-9042-8e635197202e
## Changelog:
[Android] [Fixed] - Avoid NPE when touch event is triggered before SurfaceManager is initiated
Pull Request resolved: https://github.com/facebook/react-native/pull/48007
Test Plan:
I checked the crashed being fixed on RNTester.
https://github.com/user-attachments/assets/71f7e359-707a-494c-ae34-fef8d432e612
Reviewed By: cortinico
Differential Revision: D66594576
Pulled By: javache
fbshipit-source-id: b1559d94866bdb021e0374f1953684849603033c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49358
When the network is under strain, the code responsible for detecting if the inspector proxy's connection to the client has been lost may incorrectly assume the connection is dead. This false positive occurs because the system assumes that if a pong is not received within 5 seconds of a ping, the other side has disconnected. However, I was able to consistently reproduce scenarios where a delay of more than 5 seconds (even more than 20 seconds) was followed by a return to normal ping-pong communication without any issues.
Since I can't think of any issues with increasing this number, I'm increasing it to 60s.
Changelog:
[General][Fixed] - Disconnections of DevTools when the network is under significant strain.
Reviewed By: robhogan, huntie
Differential Revision: D69523906
fbshipit-source-id: 50db1e7bbe690b42421bc226aa30fd6571ba2257
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/49250
The TurboModule System decided to ignore the Null values when they are coming to JS. However, in iOS, null value can be mapped to `[NSNull null];` and this value is a valid value that can be used on the native side.
In the old architecture, when the user were sending a null value from JS to a native module, the Native side was receiving the value.
In the New Architecture, the value was stripped away.
This change allow us to handle the `null` value properly in the interop layer, to restore the usage of legacy modules in the New Arch.
I also tried with a more radical approach, but several tests were crashing because some modules do not know how to handle `NSNull`.
See discussion happening here: https://github.com/invertase/react-native-firebase/issues/8144#issuecomment-2548067344
## Changelog:
[iOS][Changed] - Properly handle `null` values coming from NativeModules.
Reviewed By: sammy-SC
Differential Revision: D69301396
fbshipit-source-id: be275185e2643092f6c3dc2481fe9381bbcf69e9
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:
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
[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.
| 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" /> |
| 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:
`dev-middleware` uses `invariant` but does not declare it as a dependency. Under certain hoisting scenarios, or when using pnpm, this will cause `dev-middleware` to fail while being loaded.
## Changelog:
[GENERAL] [FIXED] - add missing `invariant` dependency
Pull Request resolved: https://github.com/facebook/react-native/pull/49047
Test Plan: n/a
Reviewed By: cortinico
Differential Revision: D68835789
Pulled By: huntie
fbshipit-source-id: 13718f4970ed55e6e062b7c2bd719be977abdd0c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48982
We were missing a conversion to px on the `getOutline()` function of `CompositeBackgroundDrawable` which led to incorrect elevation prop rendering
Changelog: [Android][Fixed] - Elevation prop on android has incorrect border-radius
Reviewed By: NickGerleman
Differential Revision: D68724947
fbshipit-source-id: b3a7a4919bfd7c60fac7c3d6e3ba760e3f74d190
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
Rob Hogan
React Native Bot
Nick Gerleman
Riccardo Cipolleschi
Nicola Corti
Rob Hogan
Ritesh Shukla
Rubén Norte
zhongwuzw
Christian Falch
Phil Pluckthun
Rob Hogan
Mateo Guzmán
chrsmys
Zhi Zhou
CHOIMINSEOK
Vitali Zaidman
Fabio PelizzolaandMateo Guzmán
Alex Hunt
Alex Hunt
David Vacca
Rickard Zrinski
Tommy Nguyen
Jorge Cabiedes Acosta
