Skip to content

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
merged 32 commits into from
Aug 8, 2025

Conversation

Saadnajmi
Copy link
Collaborator

Summary:

Merge up to upstream React Native 0.77.3. Make sure to update our peer dependency.

cortinico and others added 29 commits June 16, 2025 10:44
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
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]
@Saadnajmi Saadnajmi requested a review from a team as a code owner August 7, 2025 01:47
@Saadnajmi Saadnajmi changed the title chore: Merge up to React Native 0.77.3 upstream chore(0.77): Merge up to React Native 0.77.3 upstream Aug 8, 2025
@Saadnajmi Saadnajmi merged commit 2fd4b76 into microsoft:0.77-stable Aug 8, 2025
19 checks passed
@Saadnajmi Saadnajmi deleted the 0.77/release branch August 8, 2025 18:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.