Changelog: [Internal]

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
- #49451
- #48311
- #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: #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

…opers (#49212)

Summary:
Pull Request resolved: #49212

Currently, developers can't use `popup-menu-android` at all because the Gradle file we publish is referencing
internal machinery.

I'm adding a pre-publish script that manipulates the Gradle. This is the easiest solution without having to do
crazy setup inside RNGP or having duplicated version codes around in the monorepo.

Fixes #49112

Changelog:
[Android] [Fixed] - Fix react-native/popup-menu-android not building for 3rd party developers

Reviewed By: cipolleschi

Differential Revision: D69192874

fbshipit-source-id: 9f9e8a0a6e76308e598a09f4c70dbc659c238b00

Summary:
This Pull Request fixes a regression introduced in 7c7e9e6, 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 #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: #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

…49358)

Summary:
Pull Request resolved: #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

… Android (#48998)

Summary:
This is another attempt at fixing the Android HMR client for HTTPS proxied Metro instances. The previous one unintentionally [caused the following error](#48970 (comment)):

```
java.lang.AssertionError: Method overloading is unsupported: com.facebook.react.devsupport.HMRClient#setup
```

This PR removes the overloading, and only adds the `scheme` property as a parameter to the existing `.setup` method. Aligning with the exact behavior we have on iOS.

The alternative fix, which should NOT be backward breaking (if this is) - is to move this "infer the protocol from the bundle URL" to the JS side of the HMR client. Where we don't just always default to `http`, but instead default to `https IF port === 443, otherwise http`. It's a bit more hacky, but shouldn't cause any other issues. _**Ideally**_, we have the same working behavior on both Android and iOS without workarounds.

<details><summary>Alternative workaround</summary>

See [this change](main...byCedric:react-native:patch-2).

<img width="1179" alt="image" src="https://github.com/user-attachments/assets/47c365bc-6df8-43e6-ad7d-5a667e350cd4" />

</details>

See full explanation on #48970

> We've noticed that the HMR on Android doesn't seem to be connecting when using a HTTPS-proxied Metro instance, where the proxy is hosted through Cloudflare. This is only an issue on Android - not iOS - and likely caused by the HMR Client not being set up properly on Android.
>
>- On Android, we run `.setup('android', <bundleEntryPath>, <proxiedMetroHost>, <proxiedMetroPort>, <hmrEnabled>)` in the [**react/devsupport/DevSupportManagerBase.java**](https://github.com/facebook/react-native/blob/53d94c3abe3fcd2168b512652bc0169956bffa39/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/devsupport/DevSupportManagerBase.java#L689-L691) file.
>- On iOS, we run `[self.callableJSModules invokeModule:@"HMRClient" method:@"setup" withArgs:@[ RCTPlatformName, path, host, RCTNullIfNil(port), @(isHotLoadingEnabled), scheme ]];` in the [**React/CoreModules
/RCTDevSettings.mm**](https://github.com/facebook/react-native/blob/53d94c3abe3fcd2168b512652bc0169956bffa39/packages/react-native/React/CoreModules/RCTDevSettings.mm#L488-L491) file.
>
>Notice how Android does not pass in the scheme/protocol of the bundle URL, while iOS actually does? Unfortunately, because the default protocol (`http`) mismatches on Android when using HTTPS proxies, we actually try to connect the HMR client over `http` instead of `https` - while still using port 443 - which is rejected by Cloudflare's infrastructure even before we can redirect or mitigate this issue. And the rejection is valid, as we basically try to connect on `http://<host>:443` (the source URL is `https`, so the port is infered as `443`).
>
>This change adds scheme propagation to Android, exactly like we do on iOS for the HMR Client.

## Changelog:

[ANDROID] [FIXED] Pass the bundle URL protocol when setting up HMR client on Android

<!-- Help reviewers and the release process by writing your own changelog entry.

Pick one each for the category and type tags:

[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message

For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests

Pull Request resolved: #48998

Test Plan:
See full explanation on #48970

> It's a little bit hard to test this out yourself, since you'd need a HTTPS-based proxy and reject HTTP connections for HTTPS/WSS Websocket requests.
>
>You can set this up through:
>- `bun create expo@latest ./test-app`
>- `cd ./test-app`
>- `touch .env`
>- Set `EXPO_PACKAGER_PROXY_URL=https://<proxied-metro-hostname>` in **.env**
>- Set `REACT_NATIVE_PACKAGER_HOSTNAME=<proxied-metro-hostname>` in **.env**
>- `bun run start`
>
>Setting both these envvars, the bundle URL in the manifest is set to `https://...` - which triggers this HMR issue on Android. You can validate the **.env** setup through:
>
>```bash
>curl "http://localhost:8081" -H "expo-platform: android" | jq .launchAsset.url
>```
>
>This should point the entry bundle URL towards the `EXPO_PACKAGER_PROXY_URL`.

Reviewed By: cortinico

Differential Revision: D68768351

Pulled By: javache

fbshipit-source-id: 49bf1dc60f11b2af6e57177141270632d62ab564

… app on apple silicon mac (#49320)

Summary:
Fixes #48544. We can make `RCTWeakEventEmitterWrapper` to subclass `NSDictionary` that Textinput supports encode it.

System allowed classes are:
```
Allowed classes are:
 {(
    "'NSMorphology' (0x20088b6d8) [/System/Library/Frameworks/Foundation.framework]",
    "'NSString' (0x2003f4738) [/System/Library/Frameworks/Foundation.framework]",
    "'NSInflectionRule' (0x20088d348) [/System/Library/Frameworks/Foundation.framework]",
    "'UIColor' (0x2006c0520) [/System/iOSSupport/System/Library/PrivateFrameworks/UIKitCore.framework]",
    "'NSTextAttachment' (0x20042af98) [/System/Library/PrivateFrameworks/UIFoundation.framework]",
    "'NSShadow' (0x20042ae30) [/System/Library/PrivateFrameworks/UIFoundation.framework]",
    "'NSTextEncapsulation' (0x200897e50) [/System/Library/Frameworks/CoreText.framework]",
    "'NSTextAlternatives' (0x20042af70) [/System/Library/PrivateFrameworks/UIFoundation.framework]",
    "'NSFont' (0x20042a9f8) [/System/Library/PrivateFrameworks/UIFoundation.framework]",
    "'NSAttributedString' (0x2003f3838) [/System/Library/Frameworks/Foundation.framework]",
    "'NSData' (0x2003ed528) [/System/Library/Frameworks/CoreFoundation.framework]",
    "'NSURL' (0x2003ed938) [/System/Library/Frameworks/CoreFoundation.framework]",
    "'NSAdaptiveImageGlyph' (0x2008ae538) [/System/Library/PrivateFrameworks/UIFoundation.framework]",
    "'NSNumber' (0x2003f4238) [/System/Library/Frameworks/Foundation.framework]",
    "'NSParagraphStyle' (0x20042ad40) [/System/Library/PrivateFrameworks/UIFoundation.framework]",
    "'NSDictionary' (0x2003ed5a0) [/System/Library/Frameworks/CoreFoundation.framework]",
    "'UIFont' (0x20042c668) [/System/Library/PrivateFrameworks/UIFoundation.framework]",
    "'NSColor' (0x200412350) [/System/Library/Frameworks/AppKit.framework]",
    "'NSGlyphInfo' (0x20042aa98) [/System/Library/PrivateFrameworks/UIFoundation.framework]",
    "'NSArray' (0x2003ed460) [/System/Library/Frameworks/CoreFoundation.framework]",
    "'NSPresentationIntent' (0x20088da28) [/System/Library/Frameworks/Foundation.framework]"
)}
```

## Changelog:

[IOS] [FIXED] -  Fixes TextInput crashes when any text is entered while running as iOS app on apple silicon mac

Pull Request resolved: #49320

Test Plan:
Run RNTester on apple silicon mac, and entered some text in textinput, no crash occured. Also, verified that the caret was not jumping around, thus preserving the original fix.

https://github.com/user-attachments/assets/6304f6e7-c663-4351-ace8-ab1842ee545f

Reviewed By: javache

Differential Revision: D69981500

Pulled By: cipolleschi

fbshipit-source-id: 2af9b280e42f621446efda9b101af50525e8fef7

…#47304)

Summary:
Fix `react-native-community/cli` not being found in pnpm setups

## Changelog:

[GENERAL] [FIXED] - Fix `react-native-community/cli` not being found in pnpm setups

Pull Request resolved: #47304

Test Plan:
1. Clone/check out this branch: microsoft/rnx-kit#3409
2. Run `yarn react-native config`

Reviewed By: cortinico

Differential Revision: D65209065

Pulled By: robhogan

fbshipit-source-id: 2ceb73ad140b4afe193e879779c2d8a4b9adf3fc

…found in monorepos (#47308)

Summary:
Fix `react-native-community/cli-platform-*` packages not being found in monorepos.

Note that we are making the assumption that `process.cwd()` returns the project root. This is the same assumption that `react-native-community/cli` makes. Specifically, `findProjectRoot()` has an optional argument that defaults to `process.cwd()`:

- [`findProjectRoot()`](https://github.com/react-native-community/cli/blob/14.x/packages/cli-tools/src/findProjectRoot.ts)
- Which gets called without arguments in [`loadConfig()`](https://github.com/react-native-community/cli/blob/14.x/packages/cli-config/src/loadConfig.ts#L89)
- `loadConfig()` gets called from [`setupAndRun()`](https://github.com/react-native-community/cli/blob/14.x/packages/cli/src/index.ts#L196), also without project root set

As far as I can see, the project root argument is only ever used in tests.

## Changelog:

[GENERAL] [FIXED] - Fix `react-native-community/cli-platform-*` packages not being found in monorepos

Pull Request resolved: #47308

Test Plan:
1. Clone/check out this branch: microsoft/rnx-kit#3409
2. Cherry-pick #47304
3. Cherry-pick #47308
4. Run `react-native config` inside `packages/test-app`
5. Verify that `projects` is populated

**Before:**

```js
  "healthChecks": [],
  "platforms": {},
  "assets": [],
  "project": {}
}
```

**After:**

```js
  "healthChecks": [],
  "platforms": {
    "ios": {},
    "android": {}
  },
  "assets": [],
  "project": {
    "ios": {
      "sourceDir": "/~/packages/test-app/ios",
      "xcodeProject": {
        "name": "SampleCrossApp.xcworkspace",
        "path": ".",
        "isWorkspace": true
      },
      "automaticPodsInstallation": false,
      "assets": []
    },
    "android": {
      "sourceDir": "/~/packages/test-app/android",
      "appName": "app",
      "packageName": "com.msft.identity.client.sample.local",
      "applicationId": "com.msft.identity.client.sample.local",
      "mainActivity": "com.microsoft.reacttestapp.MainActivity",
      "assets": []
    }
  }
}
```

Reviewed By: cortinico

Differential Revision: D69465533

Pulled By: robhogan

fbshipit-source-id: 3d6cf32752a7a41d9c7e84f35b0f26ae7d7a971f

Summary:
Pull Request resolved: #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 reactwg/react-native-new-architecture#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

…li (#50095)

Summary:
Pull Request resolved: #50090

Changelog: [internal]

I refactored `FabricUIManager` in D54547194 / #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

…0091)

Summary:
Pull Request resolved: #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 #49783.

Reviewed By: javache

Differential Revision: D71387739

fbshipit-source-id: 96c723ef2d6bcc659c4452434b7a4d5af26117ef

#publish-packages-to-npm&0.76-stable