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
Summary:
why: running `yarn test-e2e-local -t "RNTestProject" -p "Android" -h false -c $GITHUB_TOKEN` would actually build the app with Hermes even though it's specified as disabled.
This is because of the `if (argv.hermes == null)` condition whose body would not execute.
The condition was changed [recently](f322dc7#diff-56f57bf0eac99b0fda1b2938aceb8d9b663db82c07cb405bd53a01c8689710ffR258).
Reason for `await` being used:
```
Error ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ scripts/release-testing/test-e2e-local.js:303:32
Cannot get argv.hermes because property hermes is missing in Promise [1]. [prop-missing]
scripts/release-testing/test-e2e-local.js
300│ 'reactNativeArchitectures=arm64-v8a',
301│ 'android/gradle.properties',
302│ );
303│ const hermesEnabled = (argv).hermes === true;
304│
305│ // Update gradle properties to set Hermes as false
306│ if (!hermesEnabled) {
flow-typed/npm/yargs_v17.x.x.js
[1] 80│ argv: Argv | Promise<Argv>;
```
## Changelog:
[INTERNAL] [FIXED] - fix `hermes` param handling in `test-e2e-local.js`
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48458
NOTE: This change is made once and is not guaranteed.
**Motivation**: Requiring Flow parsing for `react-native` and its dependencies in user space can involve friction. For the case of `react-native/assets-registry` → `react-native-web`, I believe we should do the pragmatic thing to relax this requirement.
- This is a convenience stopgap until https://github.com/facebook/react-native/pull/39542 can be stabilised.
- This package is tiny and infrequently modified — I believe it's pragmatic/safe to do a one-time conversion, with the above notice and no changelog (i.e. "experimental" for now).
Resolves https://github.com/facebook/react-native/issues/48349.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D67764460
fbshipit-source-id: 7687fd79c6dea73c234a46e475c1cc745225830b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48525
Fixes https://github.com/facebook/react-native/issues/48249
`TextMeasureCacheKey` hash and equality functions only incorporates the maximum width constraint. I'm guessing this was an attempt at an optimization, but it can lead to incorrect results in pretty trivial cases. E.g. if Yoga knows a definite size of `Text` in one dimension, and measures via `YGMeasureModeExactly`, we can have a minimum size corresponding specific to the style in which the text was laid out.
Changelog:
[General][Fixed] - Fix TextMeasureCacheKey Throwing Out Some LayoutConstraints
Reviewed By: christophpurrer
Differential Revision: D67922414
fbshipit-source-id: 0ee0220059fc4e4645b1684c42a0587fe728bedd
Summary:
If 3rd party libs are using `inputAccessoryView` - the current code can easily break it. Whenever props gets changed we call `setDefaultInputAccessoryView` which will simply overwrite the current `inputAccessoryView` (which is highly undesirable).
The same fix on paper was made ~7 years ago: https://github.com/facebook/react-native/commit/bf3698323d81508fc77174df2b1ffe5fb03224e7
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [FIXED] - Fixed problem with accessory view & 3rd party libs
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/48339
Test Plan: Make sure `inputAccessoryView` functionality works as before
Reviewed By: javache
Differential Revision: D67451188
Pulled By: cipolleschi
fbshipit-source-id: bc3fa82ae15f8acedfd0b4e17bdea69cbd8c8a8d
Summary:
Related PR in `react-native-screens`:
* https://github.com/software-mansion/react-native-screens/pull/2495
Additional context:
* [my detailed explanation of **one of the issues**](https://github.com/software-mansion/react-native-screens/pull/2495#issuecomment-2478915818)
* [Android Developer: ViewGroup.startViewTransition docs](https://developer.android.com/reference/android/view/ViewGroup#startViewTransition(android.view.View))
On Android view groups can be marked as "transitioning" with a `ViewGroup.startViewTransition` call. This effectively ensures, that in case a view group is marked with this call and its children are removed, they will be still drawn until `endViewTransition` is not called.
This mechanism is implemented in Android by [keeping track of "transitioning" children in auxiliary `mTransitioningViews` array](https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/view/ViewGroup.java#7178). Then when such "transitioning" child is removed, [it is removed from children array](https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/view/ViewGroup.java#5595) but it's [parent-child relationship is not cleared](https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/view/ViewGroup.java#5397) and it is still retained in the auxiliary array.
Having that established we can proceed with problem description.
https://github.com/user-attachments/assets/d0356bf5-2f17-4b06-ba53-bfca659a1071
<details>
<summary>Full code</summary>
```javascript
import { NavigationContainer } from 'react-navigation/native';
import React from 'react';
import { createNativeStackNavigator } from 'react-navigation/native-stack';
import { enableScreens } from 'react-native-screens';
import {
StyleSheet,
Text,
View,
FlatList,
Button,
ViewProps,
Image,
FlatListProps,
findNodeHandle,
} from 'react-native';
enableScreens(true);
function Item({ children, ...props }: ViewProps) {
return (
<View style={styles.item} {...props}>
<Image source={require('../assets/trees.jpg')} style={styles.image} />
<Text style={styles.text}>{children}</Text>
</View>
);
}
function Home({ navigation }: any) {
return (
<View style={styles.container}>
<Button title="Go to List" onPress={() => navigation.navigate('List')} />
</View>
);
}
function ListScreenSimplified({secondVisible}: {secondVisible?: (visible: boolean) => void}) {
const containerRef = React.useRef<View>(null);
const innerViewRef = React.useRef<View>(null);
const childViewRef = React.useRef<View>(null);
React.useEffect(() => {
if (containerRef.current != null) {
const tag = findNodeHandle(containerRef.current);
console.log(`Container has tag [${tag}]`);
}
if (innerViewRef.current != null) {
const tag = findNodeHandle(innerViewRef.current);
console.log(`InnerView has tag [${tag}]`);
}
if (childViewRef.current != null) {
const tag = findNodeHandle(childViewRef.current);
console.log(`ChildView has tag [${tag}]`);
}
}, [containerRef.current, innerViewRef.current, childViewRef.current]);
return (
<View
ref={containerRef}
style={{ flex: 1, backgroundColor: 'slateblue', overflow: 'hidden' }}
removeClippedSubviews={false}>
<View ref={innerViewRef} removeClippedSubviews style={{ height: '100%' }}>
<View ref={childViewRef} style={{ backgroundColor: 'pink', width: '100%', height: 50 }} removeClippedSubviews={false}>
{secondVisible && (<Button title='Hide second' onPress={() => secondVisible(false)} />)}
</View>
</View>
</View>
);
}
function ParentFlatlist(props: Partial<FlatListProps<number>>) {
return (
<FlatList
data={Array.from({ length: 30 }).fill(0) as number[]}
renderItem={({ index }) => {
if (index === 10) {
return <NestedFlatlist key={index} />;
} else if (index === 15) {
return <ExtraNestedFlatlist key={index} />;
} else if (index === 20) {
return <NestedFlatlist key={index} horizontal />;
} else if (index === 25) {
return <ExtraNestedFlatlist key={index} horizontal />;
} else {
return <Item key={index}>List item {index + 1}</Item>;
}
}}
{...props}
/>
);
}
function NestedFlatlist(props: Partial<FlatListProps<number>>) {
return (
<FlatList
style={[styles.nestedList, props.style]}
data={Array.from({ length: 10 }).fill(0) as number[]}
renderItem={({ index }) => (
<Item key={'nested' + index}>Nested list item {index + 1}</Item>
)}
{...props}
/>
);
}
function ExtraNestedFlatlist(props: Partial<FlatListProps<number>>) {
return (
<FlatList
style={styles.nestedList}
data={Array.from({ length: 10 }).fill(0) as number[]}
renderItem={({ index }) =>
index === 4 ? (
<NestedFlatlist key={index} style={{ backgroundColor: '#d24729' }} />
) : (
<Item key={'nested' + index}>Nested list item {index + 1}</Item>
)
}
{...props}
/>
);
}
const Stack = createNativeStackNavigator();
export default function App(): React.JSX.Element {
return (
<NavigationContainer>
<Stack.Navigator screenOptions={{ animation: 'slide_from_right' }}>
<Stack.Screen name="Home" component={Home} />
<Stack.Screen name="List" component={ListScreenSimplified}/>
</Stack.Navigator>
</NavigationContainer>
);
}
export function AppSimple(): React.JSX.Element {
const [secondVisible, setSecondVisible] = React.useState(false);
return (
<View style={{ flex: 1, backgroundColor: 'lightsalmon' }}>
{!secondVisible && (
<View style={{ flex: 1, backgroundColor: 'lightblue' }} >
<Button title='Show second' onPress={() => setSecondVisible(true)} />
</View>
)}
{secondVisible && (
<ListScreenSimplified secondVisible={setSecondVisible} />
)}
</View>
);
}
const styles = StyleSheet.create({
container: {
flex: 1,
alignItems: 'center',
justifyContent: 'center',
},
nestedList: {
backgroundColor: '#FFA07A',
},
item: {
flexDirection: 'row',
alignItems: 'center',
padding: 10,
gap: 10,
},
text: {
fontSize: 24,
fontWeight: 'bold',
color: 'black',
},
image: {
width: 50,
height: 50,
},
});
```
</details>
Explanation (copied from [here](https://github.com/software-mansion/react-native-screens/pull/2495#issuecomment-2478915818)):
I've debugged this for a while now & I have good understanding of what's going on. This bug is caused by our usage of `startViewTransition` and its implications. We use it well, however React does not account for case that some view might be in transition. Error mechanism is as follows:
1. Let's have initially simple stack with two screens: "A, B". This is component rendered under "B":
```javascript
<View //<-- ContainerView (CV)
removeClippedSubviews={false}
style={{ flex: 1, backgroundColor: 'slateblue', overflow: 'hidden' }}>
<View removeClippedSubviews style={{ height: '100%' }}> // <--- IntermediateView (IV)
<View removeClippedSubviews={false} style={{ backgroundColor: 'pink', width: '100%', height: 50 }} /> // <--- ChildView (ChV)
</View>
</View>
```
2. We press the back button.
3. We're on Fabric, therefore subtree of B gets destroyed before B itself is unmounted -> in our commit hook we detect that the screen B will be unmounted & we mark every node under B as transitioning by calling `startViewTransition`.
4. React Mounting stage starts, view hierarchy is disassembled in bottom-up fashion (leafs first).
5. ReactViewGroupManager receives MountItem to detach ChV from IV.
6. A call to [`IV.removeView(ChV)` is made](https://github.com/facebook/react-native/blob/9c11d7ca68c5c62ab7bab9919161d8417e96b28b/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/view/ReactClippingViewManager.kt#L58-L73), which effectively removes ChV from `IV.children`, ***HOWEVER*** it does not clear `ChV.parent`, meaning that after the call, `ChV.parent == IV`. This happens, due to view being marked as in-transition by our call to `startViewTransition`. If the view is not marked as in-transition this parent-child relationship is removed.
7. IV has `removeClippedSubviews` enabled, therefore a [call to `IV.removeViewWithSubviewsClippingEnabled(ChV)` is made](https://github.com/facebook/react-native/blob/9c11d7ca68c5c62ab7bab9919161d8417e96b28b/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/view/ReactClippingViewManager.kt#L68). [This function](https://github.com/facebook/react-native/blob/9c11d7ca68c5c62ab7bab9919161d8417e96b28b/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/view/ReactViewGroup.java#L726-L744) does effectively two things:
1. if the ChV has parent (interpretation: it has not yet been detached from parent), we compute it's index in `IV.children` (Android.ViewGroup's state) and remove it from the array,
2. remove the ChV from `mAllChildren` array (this is state maintained by ReactViewGroup for purposes of implementing the "subview clipping" mechanism".
The crash happens in 7.1, because ChV has been removed from `IV.children` in step 6, but the parent-child relationship has not been broken up there. Under usual circumstances (this is my hypothesis now, yet unconfirmed) 7.1 does not execute, because `ChV.parent` is nulled in step no. 6.
Transitions. On Fabric, when some subtree is unmounted, views in the subtree are unmounted in bottom-up order. This leads to uncomfortable situation, where our components (react-native-screens), who want to drive & manage transitions are notified that their children will be removed after the subtrees mounted in screen subviews are already disassembled. **If we start animation in this very moment we will have staggering effect of white flash** [(issue)](https://github.com/software-mansion/react-native-screens/issues/1685) (we animate just the screen with white background without it's children). This was not a problem on Paper, because the order of subtree disassembling was opposite - top-down. While we've managed to workaround this issue on Fabric using `MountingTransactionObserving` protocol on iOS and a commit hook on Android (we can inspect mutations in incoming transaction before it starts being applied) we still need to prevent view hierarchy from being disassembled in the middle of transition (on Paper this has also been less of an issue) - and this is where `startViewTransition` comes in. It allows us to draw views throughout transition after React Native removes them from HostTree model. On iOS we exchange subtree for its snapshot for transition time, however this approach isn't feasible on Android, because [snapshots do not capture shadows](https://stackoverflow.com/questions/42212600/android-screenshot-of-view-with-shadow).
[Android does not expose a method to verify whether a view is in transition](https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/view/ViewGroup.java#7162) (it has `package` visibility), therefore we need to retrieve this information with some workaround. I see two posibilities:
* first approach would be to override `startViewTransition` & `endViewTransition` in ReactViewGroup and keep the state on whether the view is transitioning there,
* second possible approach would be as follows: we can check for "transitioning" view by checking whether a view has parent but is not it's parent child (this **should** be reliable),
Having information on whether the view is in transition or not, we can prevent multiple removals of the same view in every call site (currently only in `removeViewAt` if `parent.removeClippingSubviews == true`).
Another option would be to do just as this PR does: having in mind this "transitioning" state we can pass a flag to `removeViewWithSubviewClippingEnabled` and prevent duplicated removal from parent if we already know that this has been requested.
I can also add override of this method:
```java
/*package*/ void removeViewWithSubviewClippingEnabled(View view) {
this.removeViewWithSubviewClippingEnabled(view, false);
}
```
to make this parameter optional.
[ANDROID] [FIXED] - Handle removal of in-transition views.
Pull Request resolved: https://github.com/facebook/react-native/pull/47634
Test Plan: WIP WIP
Reviewed By: javache
Differential Revision: D66539065
Pulled By: tdn120
fbshipit-source-id: cf1add67000ebd1b5dfdb2048461a55deac10b16
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48182
Maintainers from SVG reached out because of an edge case they inencountered when generating the ComponentProvider. In their setup, they had a `.git` folder in the repo and the algorithm was spending a lot of time crawling the git folder.
In general, we should avoid crawling hidden folders.
This change fix that.
## Changelog:
[General][Fixed] - Skip hidden folders when looking for third party components.
Reviewed By: javache
Differential Revision: D66959345
fbshipit-source-id: 992a79f3cff22cd6a459e0272c8140bc329888da
Summary:
Fixes an [issue](https://github.com/facebook/react-native/issues/48168) where only iOS configurations with "Debug" in the name are configured to use the hermes debugger.
## Changelog:
<!-- 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
-->
[IOS] [FIXED] - Enable hermes debugger by configuration type instead of configuration name
Pull Request resolved: https://github.com/facebook/react-native/pull/48174
Test Plan:
Added new test scenarios that all pass:
```
ruby -Itest packages/react-native/scripts/cocoapods/__tests__/utils-test.rb
Loaded suite packages/react-native/scripts/cocoapods/__tests__/utils-test
Started
Finished in 0.336047 seconds.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
56 tests, 149 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
100% passed
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
166.64 tests/s, 443.39 assertions/s
```
In a personal project with the following configurations:
```
project 'ReactNativeProject', {
'Local' => :debug,
'Development' => :release,
'Staging' => :release,
'Production' => :release,
}
```
I added the following to my Podfile:
```
installer.pods_project.targets.each do |target|
target.build_configurations.each do |config|
puts "#{config.name} is debug? #{config.type == :debug}"
end
end
```
To confirm that my logic is correct:
```
Local is debug? true
Development is debug? false
Staging is debug? false
Production is debug? false
```
Reviewed By: robhogan
Differential Revision: D66962860
Pulled By: cipolleschi
fbshipit-source-id: 7bd920e123c9064c8a1b5d45df546ff5d2a7d8be
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48225
Fixes https://github.com/facebook/react-native/issues/47762
The weak event emitter in AttributedString attributes is causing a serialization error when typing into a TextInput in a Mac Catalyst build. We can resolve this by not putting the event emitters in the attributed string, but this is likely to cause other issues with event handling for nested <Text> components.
## Changelog
[iOS][Fixed] - Workaround for Mac Catalyst TextInput crash due to serialization attempt of WeakEventEmitter
Reviewed By: NickGerleman
Differential Revision: D66664583
fbshipit-source-id: efdfbcb0db4d5e6b9bf7c14f9bbb221faae2d724
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48145
While writing the docs for 0.77, I found an edge case in the generation of the RCTThirdPartyComponentProvider:
* If the app has the `codegenConfig` field set in the `package.json`
* And it does not have the `ios.componentProvider` field is not provided
Codegen was generating the mapping for the react-native core components. That's not expected as, in that case, it should only generate components that are declared in the app or in libraries.
This change fixes this edge case.
## Changelog:
[Internal] - Exclude mapping generation of core component
Reviewed By: blakef
Differential Revision: D66875080
fbshipit-source-id: 65fe10381729ec7808efec70feacf2a55f0056e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48132
Backs out D63573322 and D65645981, reverting the change that makes callbacks passed to `animation.start(<callback>)` scheduled for execution in a microtask.
This is being reverted becuase the latency introduced by the current macro and pending micro tasks can introduce visible latency artifacts that diminish the fidelity of animations.
Changelog:
[General][Changed] - Reverts #47503. (~~Callbacks passed to `animation.start(<callback>)` will be scheduled for execution in a microtask. Previously, there were certain scenarios in which the callback could be synchronously executed by `start`.~~)
Reviewed By: javache
Differential Revision: D66852804
fbshipit-source-id: 08434b9876813fe9e8b189b6b467198933843bf0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48124
Fixes https://github.com/facebook/react-native/issues/47592
The logic in HeadlessJsTaskService is broken. We should not check whether `getReactContext` is null or not.
Instead we should use the `enableBridgelessArchitecture` feature flag to understand if New Architecture was enabled or not.
The problem we were having is that `HeadlessJsTaskService` was attempting to load the New Architecture even if the user would have it turned off. The Service would then die attempting to load `libappmodules.so` which was correctly missing.
Changelog:
[Android] [Fixed] - Fix crash on HeadlessJsTaskService on old architecture
Reviewed By: javache
Differential Revision: D66826271
fbshipit-source-id: 2b8418e0b01b65014cdbfd0ec2f843420a15f9db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48090
This alleviates a breaking change on `ReactModuleInfo` constructor.
While the ctor was deprecated, we realized that there are more than 250 usages in OSS.
We'll need to properly communicate this removal before we do it.
Changelog:
[Android] [Fixed] - Re-introduce the deprecated constructor on ReactModuleInfo
Reviewed By: cipolleschi
Differential Revision: D66755541
fbshipit-source-id: 3673d8f2af278d55491cea89f1594d368513e3d8
Summary:
GHA to build HermesC for windows are failing because the machines comes with a different CMake version already.
Let's try not to install Cmake and use the one provided by the machine.
## Changelog:
[Internal] -
Pull Request resolved: https://github.com/facebook/react-native/pull/48122
Test Plan: GHA {F1973187648}
Reviewed By: alanleedev
Differential Revision: D66825216
Pulled By: cipolleschi
fbshipit-source-id: 9a9376a5409e192195a6b6cc25b4d58cb47f15da
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48039
This class was removed in D66127067 but was marked as DeprecatedInNewArchitecture and not Deprecated, which limited the signal we gave to developers to move away from this.
Restore for now to e
Changelog: [Android][Fixed] Reverted removal of TurboReactPackage
Reviewed By: rshest
Differential Revision: D66648209
fbshipit-source-id: 165f9390b4874e69353612b929d87b0c495588af
Summary:
building RN tester with 0.77 rc-0 doesn't work now because of `java.io.IOException: No such file or directory` on line 48.
`buildDirectory` is a Gradle property representing a file
https://github.com/facebook/react-native/pull/47552 removes this file altogether so feel free to close if that one is the "right one"
## Changelog:
[ANDROID] [FIXED] - fix IOException in `BuildCodegenCLITask`
Pull Request resolved: https://github.com/facebook/react-native/pull/48008
Test Plan: After this change, building RN tester works.
Reviewed By: cortinico
Differential Revision: D66650038
Pulled By: robhogan
fbshipit-source-id: 11cd83493fa118c6b79d11c9113228dd3971a803
Summary:
https://github.com/facebook/react-native/pull/46385 introduced use of `Object.hasOwn` as an incidental detail of some `Animated` performance improvements.
Unfortunately, `Object.hasOwn` is not present in the version of JSC shipped with Android, nor the built in iOS JSC until iOS 15.4, which is greater than React Native's minimum version (13.4).
Instead:
- Use `obj.hasOwnProperty(prop)` for known objects that have the `Object` prototype.
- Otherwise, use `Object.hasOwn` where it is defined.
- Lastly, fall back to `Object.prototype.hasOwnProperty.call(obj, prop)`, which is compatible with passed `null`-prototype objects.
Fixes https://github.com/facebook/react-native/issues/47963
Intend to pick for RN 0.77.
## Changelog:
[GENERAL][FIXED] Replace Object.hasOwn usages to fix Animated on JSC
Pull Request resolved: https://github.com/facebook/react-native/pull/48035
Test Plan:
- Run `rn-tester` on Android with Hermes disabled.
- Verify the FlatList->Basic example redboxes before this change, and works after it.
Reviewed By: yungsters
Differential Revision: D66638379
Pulled By: robhogan
fbshipit-source-id: 51ac525851b41adea3bf3cc41349225138e1f2fe
Summary:
This Pull Request fixes a regression introduced in https://github.com/facebook/react-native/commit/7c7e9e6571c1f702213e9ffbb40921cd5a1a786b, which adds a `filename*` attribute to the `content-disposition` of a FormData part. However, as the [MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition#directives) states, there is no `filename*` attribute for the `content-disposition` header in case of a form data.
The `filename*` attribute would break the parsing of form data in the request, such as in frameworks like `Next.js` which uses the web implementation of [`Request`](https://developer.mozilla.org/en-US/docs/Web/API/Request).
Fixes https://github.com/facebook/react-native/issues/44737
## 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
-->
[General] [Fixed] - Remove non compliant `filename*` attribute in a FormData `content-disposition` header
Pull Request resolved: https://github.com/facebook/react-native/pull/46543
Test Plan:
- Clone the `react-native` repo
- Create a simple JS file that will act as a node server and execute it
```javascript
const http = require('http');
const server = http.createServer(async function (r, res) {
const req = new Request(new URL(r.url, 'http://localhost:3000'), {
headers: r.headers,
method: r.method,
body: r,
duplex: 'half',
});
const fileData = await req.formData();
console.log(fileData);
res.writeHead(200);
res.end();
});
server.listen(3000);
```
- Go to `packages/rn-tester`
- Add a `useEffect` in `js/RNTesterAppShared.js`
```javascript
React.useEffect(() => {
const formData = new FormData();
formData.append('file', {
uri: 'https://www.gravatar.com/avatar',
name: '测试photo/1.jpg',
type: 'image/jpeg',
});
fetch('http://localhost:3000', {
method: 'POST',
body: formData,
}).then(res => console.log(res.ok));
});
```
- Run the app on iOS or Android
- The node server should output the file added to the FormData with an encoded name
Reviewed By: robhogan
Differential Revision: D66643317
Pulled By: yungsters
fbshipit-source-id: 0d531528005025bff303505363671e854c0a2b63
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47950
`addInArray` may reallocate `mAllChildren` so it's not correct to store this reference.
Changelog: [Internal]
Reviewed By: tdn120
Differential Revision: D66474532
fbshipit-source-id: 90ce2fcbf8ff236501ed47b2acc413e54ef8b82a
Summary:
Removed `node-fetch` in favour of node builtin fetch to get rid of the deprecated `punycode` warning when using Node 22.
`react-native/community-cli-plugin` already requires Node >= 18 where it was made available by default (without `--experimental-fetch` flag).
This change is similar to the one made in https://github.com/facebook/react-native/pull/45227
## Changelog:
[GENERAL] [CHANGED] - Drop node-fetch in favor of Node's built-in fetch from undici in `react-native/community-cli-plugin`
Pull Request resolved: https://github.com/facebook/react-native/pull/47397
Test Plan: tests pass
Reviewed By: blakef
Differential Revision: D66512595
Pulled By: NickGerleman
fbshipit-source-id: c4e01baf388f9fae8cea7b4bfe25034bff28b461
"description":"Package that includes native module exapmle, native component example, targets both the old and the new architecture. It should serve as an example of a real-world OSS library.",
@@ -426,6 +426,10 @@ public abstract interface class com/facebook/react/ReactRootView$ReactRootViewEv
public abstract fun onAttachedToReactInstance (Lcom/facebook/react/ReactRootView;)V
}
public abstract class com/facebook/react/TurboReactPackage : com/facebook/react/BaseReactPackage {
public fun <init> ()V
}
public abstract interface class com/facebook/react/ViewManagerOnDemandReactPackage {
public abstract fun createViewManager (Lcom/facebook/react/bridge/ReactApplicationContext;Ljava/lang/String;)Lcom/facebook/react/uimanager/ViewManager;
public abstract fun getViewManagerNames (Lcom/facebook/react/bridge/ReactApplicationContext;)Ljava/util/Collection;
@@ -2959,6 +2963,7 @@ public abstract interface annotation class com/facebook/react/module/annotations
public final class com/facebook/react/module/model/ReactModuleInfo {
public static final field Companion Lcom/facebook/react/module/model/ReactModuleInfo$Companion;
public fun <init> (Ljava/lang/String;Ljava/lang/String;ZZZZ)V
public fun <init> (Ljava/lang/String;Ljava/lang/String;ZZZZZ)V
public final fun canOverrideExistingModule ()Z
public static final fun classIsTurboModule (Ljava/lang/Class;)Z
public final fun className ()Ljava/lang/String;
@@ -7438,6 +7443,7 @@ public class com/facebook/react/views/text/TextAttributeProps {
public static final field TA_KEY_LETTER_SPACING S
public static final field TA_KEY_LINE_BREAK_STRATEGY S
public static final field TA_KEY_LINE_HEIGHT S
public static final field TA_KEY_MAX_FONT_SIZE_MULTIPLIER S
public static final field TA_KEY_OPACITY S
public static final field TA_KEY_ROLE S
public static final field TA_KEY_TEXT_DECORATION_COLOR S
@@ -7470,6 +7476,7 @@ public class com/facebook/react/views/text/TextAttributeProps {
protected field mLetterSpacingInput F
protected field mLineHeight F
protected field mLineHeightInput F
protected field mMaxFontSizeMultiplier F
protected field mNumberOfLines I
protected field mOpacity F
protected field mRole Lcom/facebook/react/uimanager/ReactAccessibilityDelegate$Role;
@@ -7831,6 +7838,7 @@ public class com/facebook/react/views/view/ReactViewGroup : android/view/ViewGro
protected fun dispatchSetPressed (Z)V
public fun draw (Landroid/graphics/Canvas;)V
protected fun drawChild (Landroid/graphics/Canvas;Landroid/view/View;J)Z
public fun endViewTransition (Landroid/view/View;)V
protected fun getChildDrawingOrder (II)I
public fun getClippingRect (Landroid/graphics/Rect;)V
public fun getHitSlopRect ()Landroid/graphics/Rect;
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Rob Hogan
React Native Bot
Nick GerlemanandRob Hogan
Riccardo CipolleschiandRob Hogan
Nicola CortiandRob Hogan
Rob HoganandGitHub
Ritesh ShuklaandNicola Corti
Rubén NorteandNicola Corti
zhongwuzwandReact Native Bot
Christian FalchandReact Native Bot
Phil PluckthunandReact Native Bot
Rob HoganandReact Native Bot
Mateo GuzmánandReact Native Bot
chrsmysandReact Native Bot
Zhi ZhouandReact Native Bot
CHOIMINSEOKandReact Native Bot
Vitali ZaidmanandNicola Corti
Alex HuntandRob Hogan
Alex HuntandGitHub
David VaccaandRob Hogan
Rickard ZrinskiandRob Hogan
Tommy NguyenandRob Hogan
Jorge Cabiedes AcostaandRob Hogan
Samuel SuslaandRob Hogan
timbocoleandRob Hogan
kirillzyuskoandRob Hogan
Thomas NardoneandRob Hogan
Kacper KafaraandRiccardo Cipolleschi
Ben HandanyanandRiccardo Cipolleschi
Eric RozellandRiccardo Cipolleschi
Blake Friedman
Tim YungandBlake Friedman
Pieter De BaetsandRob Hogan
Vojtech NovakandRob Hogan
Hugo FOYARTandRob Hogan
Jakub RomanczykandRob Hogan
