forked from facebook/react-native
-
Notifications
You must be signed in to change notification settings - Fork 148
chore(0.77): Merge up to React Native 0.77.3 upstream #2622
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Summary: Pull Request resolved: facebook#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
…om (facebook#52004) Summary: Pull Request resolved: facebook#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: 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
…51798) Summary: As per title, GH is [removing windows-2019](https://github.com/facebook/react-native/actions/runs/15421451006/job/43403215354) at the end of the month. We need to migrate away from them. ## Changelog: [Internal] - Bump windows runners Pull Request resolved: facebook#51798 Test Plan: GHA Reviewed By: cortinico Differential Revision: D75946994 Pulled By: cipolleschi fbshipit-source-id: 972b60300c918c0eae0403ed4149347a4ffa8bd0
Summary: Pull Request resolved: facebook#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
…k#48350) 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: facebook#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: Fixes facebook#42533 . ## Changelog: [IOS] [FIXED] - Fabric: Added ScrollEndDragEvent for scrollEndDrag event Pull Request resolved: facebook#48319 Test Plan: Repro please see facebook#42533 . Reviewed By: javache Differential Revision: D67517912 Pulled By: cipolleschi fbshipit-source-id: aa1caebfb690d09a207b3ebce382eceb520009e5
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: - react-native-community/discussions-and-proposals#847 - facebook#49451 - facebook#48311 - facebook#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: facebook#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: Fixes facebook#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: facebook#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: Pull Request resolved: facebook#48736 Pull Request resolved: facebook#48735 This icon was broken by D65457771, identified in [OSS testing for the 0.77 release](reactwg/react-native-releases#724). By explicitly setting the image for the `Disabled` state to the same as `Normal`, we get the same behaviour as the deprecated [`adjustsImageWhenDisabled = NO`](https://developer.apple.com/documentation/uikit/uibutton/adjustsimagewhendisabled?language=objc) without the need for `configurationUpdateHandler`. Changelog: [iOS][Fixed] Restore "Paused in debugger" overlay icon Reviewed By: cipolleschi Differential Revision: D68274336 fbshipit-source-id: 3f4b84eb7cfb518ca953c721da9885df8f98b437
…with web standard (facebook#51500) 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: apollographql/apollo-client#12632 (comment) 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: facebook#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: See facebook#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: facebook#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: Pull Request resolved: facebook#50090 Changelog: [internal] I refactored `FabricUIManager` in D54547194 / facebook#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
…ough value prop is hardcoded to false (facebook#50049) Summary: Fixes facebook#50026 ## Changelog: [IOS] [FIXED] - [Fabric] iOS: Fixes Switch component incorrectly renders as toggled on even though value prop is hardcoded to false Pull Request resolved: facebook#50049 Test Plan: Repro please see facebook#50026. Reviewed By: javache Differential Revision: D71307864 Pulled By: cipolleschi fbshipit-source-id: 57238296842229cf2f23a3f44134f43e27b54609
Summary: Fixes facebook#48245 . The reason is we reuse the modal component and also reuse the snapshot of previous modal. ## Changelog: [IOS] [FIXED] - Fabric: Fixes Modal snapshot when closing it Pull Request resolved: facebook#48252 Test Plan: Repro repo please see Fixes facebook#48245 Reviewed By: rshest Differential Revision: D70629570 Pulled By: cipolleschi fbshipit-source-id: fe97184d2f27283a9c7e6df09e9df35630429ff1
…cebook#50091) Summary: Pull Request resolved: facebook#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 facebook#49783. Reviewed By: javache Differential Revision: D71387739 fbshipit-source-id: 96c723ef2d6bcc659c4452434b7a4d5af26117ef
Summary: Fixes facebook#51193 [ANDROID][FIXED] Wrong borderBottomEndRadius on RTL Pull Request resolved: facebook#51229 Test Plan: Tested with Arabic (RTL) and English(LTR) English <img src="https://github.com/user-attachments/assets/5bd1eca9-194c-4d83-b75f-689bc13d827b" width=200> Arabic <img src="https://github.com/user-attachments/assets/459320a0-6bb2-4585-97bb-bd4ded6ec399" width=200> Reviewed By: cortinico Differential Revision: D74709219 Pulled By: NickGerleman fbshipit-source-id: 885bb84d97d73324983d044fd2874a457b40f646
Summary: Pull Request resolved: facebook#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: facebook#51048 Fixes facebook#50442 Closes facebook#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
This reverts commit f2b846f.
Summary: Pull Request resolved: facebook#52694 build_android job is always failing, with this assertion. Seems like find/replace in D78484060 gone wrong? Changelog: [Internal] Reviewed By: sbuggay Differential Revision: D78534334 fbshipit-source-id: 291bdd01b41fa6efea00ed63a0dee8bdb14cbc3a
#publish-packages-to-npm&0.77-stable
Changelog: [Internal]
tido64
approved these changes
Aug 7, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary:
Merge up to upstream React Native 0.77.3. Make sure to update our peer dependency.