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:
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:
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: https://github.com/facebook/react-native/pull/47308
Test Plan:
1. Clone/check out this branch: https://github.com/microsoft/rnx-kit/pull/3409
2. Cherry-pick https://github.com/facebook/react-native/pull/47304
3. Cherry-pick https://github.com/facebook/react-native/pull/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:
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: https://github.com/facebook/react-native/pull/47304
Test Plan:
1. Clone/check out this branch: https://github.com/microsoft/rnx-kit/pull/3409
2. Run `yarn react-native config`
Reviewed By: cortinico
Differential Revision: D65209065
Pulled By: robhogan
fbshipit-source-id: 2ceb73ad140b4afe193e879779c2d8a4b9adf3fc
Summary:
This is another attempt at fixing the Android HMR client for HTTPS proxied Metro instances. The previous one unintentionally [caused the following error](https://github.com/facebook/react-native/pull/48970#issuecomment-2617047184):
```
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](https://github.com/facebook/react-native/compare/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 https://github.com/facebook/react-native/issues/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: https://github.com/facebook/react-native/pull/48998
Test Plan:
See full explanation on https://github.com/facebook/react-native/issues/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
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 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/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 https://github.com/facebook/react-native/issues/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 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:
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:
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:
`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/47313
We're going to fix up a bunch of designated initializers. `RCTSurfaceHostingProxyRootView` is particularly problematic because different initializers will do different things even though reading the code it looks like they should be equivalent. Remove the encapsulated "start" to the provided "surface", and require it to be explicit at the callsite.
## Changelog:
[iOS][Changed] - `RCTSurfaceHostingProxyRootView` no longer has different behavior (whether it calls `start` on the provided *surface*) depending on which initializer is used. Call `start` yourself on the *surface* instead.
Reviewed By: cipolleschi
Differential Revision: D65214656
fbshipit-source-id: 179d5220d4f866b4452561e1bb6e2051020c8a11
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:
Fixes https://github.com/facebook/react-native/issues/47725
Calling Appearance.setColorScheme(null) or Appearance.setColorScheme(undefined) no longer resets the color scheme useColorScheme returns like on previous rn versions.
## 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] - Fix `Appearance.setColorScheme(null)` not resetting color scheme value
Pull Request resolved: https://github.com/facebook/react-native/pull/47739
Test Plan: Repo with a patch ready to test: https://github.com/sangonz193/react-native-color-scheme-patch
Reviewed By: yungsters
Differential Revision: D66230236
Pulled By: cipolleschi
fbshipit-source-id: cc668acb1fde6d30f2706fc0ab7dee5cea1c3b14
Summary:
I noticed that `AppDelegate` subscribers listening for `applicationDidEnterBackground` events in Expo projects (as documented [here](https://github.com/expo/expo/blob/238b6f57e459dd2c0b13ee158f0af709fe922460/docs/pages/modules/appdelegate-subscribers.mdx?plain=1#L56) aren't working as expected anymore.
While investigating, I discovered that the events aren't reaching the `ExpoAppDelegate` implementation ([source](https://github.com/expo/expo/blob/71f2c55ff3f11e43ab43761bb5cece2e48eae0bf/packages/expo-modules-core/ios/AppDelegates/ExpoAppDelegate.swift#L61)) because the `RCTAppDelegate` implementation of `applicationDidEnterBackground` interrupts the event chain. This appears to be affecting some legitimate use cases.
I believe we could improve this by removing the current implementation, but I'd love to hear your thoughts on this approach. I might be missing some context about why this implementation was originally needed, so any insights would be greatly appreciated!
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [FIXED] - Fix applicationDidEnterBackground not being called
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [FIXED] - Fix applicationDidEnterBackground not being called
Pull Request resolved: https://github.com/facebook/react-native/pull/48376
Test Plan: Ran a local test after change
Reviewed By: javache
Differential Revision: D67621557
Pulled By: cipolleschi
fbshipit-source-id: 2d73711372deba867bd616c79ef4d00c79aa86d5
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/46629
If we clipped and had no border or corner radius we would end up hitting this path every time. We can optimize this a bit to avoid that.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D63299597
fbshipit-source-id: 90031f964b7669049a4a2efe00a553c888d28cd7
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:
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/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:
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:
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:
currently running jest test, it shows an error:
```
ReferenceError: You are trying to `import` a file after the Jest environment has been torn down. From __tests__/App.test.tsx.
at getState (node_modules/react-native/Libraries/Utilities/Appearance.js:18:26)
at addChangeListener (node_modules/react-native/Libraries/Utilities/Appearance.js:71:19)
at subscribe (node_modules/react-native/Libraries/Utilities/useColorScheme.js:10:66)
at subscribeToStore (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:6232:10)
at commitHookEffectListMount (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:13038:26)
at commitPassiveMountOnFiber (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:14461:11)
at commitPassiveMountEffects_complete (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:14421:9)
at commitPassiveMountEffects_begin (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:14408:7)
at commitPassiveMountEffects (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:14396:3)
at flushPassiveEffectsImpl (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:16287:3)
at flushPassiveEffects (node_modules/react-test-renderer/cjs/react-test-renderer.development.js:16236:14)
at node_modules/react-test-renderer/cjs/react-test-renderer.development.js:16051:9
at workLoop (node_modules/scheduler/cjs/scheduler.development.js:266:34)
at flushWork (node_modules/scheduler/cjs/scheduler.development.js:239:14)
at Immediate.performWorkUntilDeadline [as _onImmediate] (node_modules/scheduler/cjs/scheduler.development.js:533:21)
```
it is a regression from https://github.com/facebook/react-native/issues/46123 that to have a lazy require.
this pr tries to mock `useColorScheme` to return `light`. i think we don't necessarily test the color scheme changes in jest runtime. originally `useColorScheme` also returns `light` because of [this statement](https://github.com/facebook/react-native/blob/9a60038a40e16925ea1adeb3e3c937c22a615485/packages/react-native/Libraries/Utilities/Appearance.js#L77-L83)
## Changelog:
[GENERAL] [FIXED] - Fixed jest error from Appearance.js
Pull Request resolved: https://github.com/facebook/react-native/pull/47629
Test Plan:
```sh
$ npx react-native-community/cli init RN0762 --pm bun --version 0.76.2
$ cd RN0762
$ bun test run
```
Reviewed By: cipolleschi
Differential Revision: D66297456
Pulled By: huntie
fbshipit-source-id: 80d1460532e76bd1815c66964547b50d7f7b3558
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47875
The old architecture looks broken because in the OnLoad.cpp file we try to include the autolinking.h header which is only generated when the New Architecture is enabled.
This fix guards the include and the usage of the function provided by the autolinking so that the old architecture should work as well.
## Changelog
[Internal] - Include autolinkin.h in OnLoad.cpp only if it exists
Reviewed By: blakef
Differential Revision: D66295318
fbshipit-source-id: 18461e6b70ac92af57b805bef51c0df49db02283
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47670
Now that we have `babel-plugin-syntax-hermes-parser` in `react-native/babel-preset` (since D63535216), it's no longer necessary to use `hermes-parser` directly in Metro in order to use newer Flow syntax.
Babel with `babel-plugin-syntax-hermes-parser` is generally preferable, because it intelligently falls back to parsing with Babel for any non-`flow` files.
See https://github.com/facebook/hermes/issues/1549 for context.
Changelog:
[General][Fixed] metro-config: Don't use `hermes-parser` by default, prefer `babel-plugin-syntax-hermes-parser`, which supports other syntax plugins.
Reviewed By: huntie
Differential Revision: D66002056
fbshipit-source-id: cf48acec347e2c0791872f8ca4b53f5f8af1c783
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47737
We may see an NSRangeException when setting new AttributedString content, where setting the AttributedString itself changes selection (before we mutate it later).
It seems like the selection here is not in a good state yet in regards to the AttributedString backing exposed (since we are reading it while modifying it). So let's fold the logic for updating typing attributes into the collection of ignored work from non-user-selection updates, since programatically setting an AttributedString will already trigger updating typing attributes.
I also added a nil check here, which is unrelated to the crash, but it seems like we should have it for safety...
Changelog:
[iOS][Fixed] - Fix possible NSRangeException when updating typing attributes in response to new text content
Reviewed By: cipolleschi
Differential Revision: D66202986
fbshipit-source-id: fded492b5022c5fef5b9563f93a57549d06a7020
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47669
When investigating [#47476](https://github.com/facebook/react-native/issues/47476), I found that the `secureTextInput` prop was not changing in the Mounting layer when changing it in JS.
I track down the problem to the `UIManager::cloneNode` method.
When we clone the node, we first merge the patch that arrives from React into the props controlled by setNativeProps, ignoring the patch's props that are controlled by React.
But then, we forgot to merge back the React's controlled property into the final props, effectively losing them.
This change adds an extra merging step, merging the props controlled with setNativeProps back into the patch of props controlled by React, and then using this new set of props as source of truth.
## Changelog:
[General][Fixed] - do not discard props in the patch when they are not null while using `useNativeProps`
Reviewed By: sammy-SC
Differential Revision: D65948574
fbshipit-source-id: db4f2b793f4a6348456933c95a151012252b8ebc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47333
Motivated by https://github.com/facebook/hermes/issues/1549. This was originally changed in https://github.com/facebook/react-native/pull/46696, as our internal Flow support had diverged from `babel/eslint-parser` (https://github.com/facebook/react-native/issues/46601).
We effectively have three flavours of JavaScript in support:
- Flow@latest for the `react-native` package, shipped as source — uses `hermes-parser`.
- TypeScript for product code (community template, Expo) — uses `babel/plugin-syntax-typescript`.
- Plain JavaScript or Flow in product code, *which may be extended with additional user Babel plugins and needs lenient parsing* — uses `babel/plugin-syntax-flow` via `babel/eslint-parser` (**this change**).
I'd love to simplify this 😅.
Switching to `hermes-eslint` for the RN monorepo codebase (D63541483) is unchanged.
Changelog: [Internal]
Reviewed By: robhogan, cipolleschi
Differential Revision: D65272156
fbshipit-source-id: 3a2bbe3fcf8ed6057f6d994a0be4985e6bf46fa9
Summary:
CI is failing to build HermesC on windows due to a version mismatch of the CMake already installed
## Changelog:
[Internal] - Fix Windows CI for HermesC
Pull Request resolved: https://github.com/facebook/react-native/pull/47867
Test Plan: GHA
Reviewed By: robhogan
Differential Revision: D66292617
Pulled By: cipolleschi
fbshipit-source-id: 5e8f4f45e33fbdd9ff163b4e8a09cb98d4366dc7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47874
We should be searching for the .bat file on Windows to remain compatible with some user setups.
Changelog: [Android][Fixed] look for sdkmanager.bat
Reviewed By: cipolleschi
Differential Revision: D66295240
fbshipit-source-id: 6b79a9aa40f77ed9c5b3d6ad92b1a62e78159223
Summary:
This pull request addresses a CMake configuration issue where an invalid escape character in file paths caused the build process to fail. Specifically, it resolves the issue in the React Native CMake configuration file where the path separator was incorrectly handled, leading to an error in the build system.
the issue is in [This Issue](https://github.com/expo/expo/issues/32955) and [This](https://github.com/expo/expo/issues/32957)
## 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
-->
[INTERNAL] [FIXED] - Corrected invalid escape character in CMake path handling
Pull Request resolved: https://github.com/facebook/react-native/pull/47641
Test Plan:
To test the changes, I performed the following steps:
1. Cloned the repository and checked out the `fix-cmake-invalid-escape-character` branch.
2. Ran the CMake build on a Windows environment where the issue was previously occurring.
3. Verified that the build process completed successfully without the "invalid character escape" error.
4. Ensured that the path handling now works correctly in CMake on Windows platforms.
Reviewed By: rshest
Differential Revision: D66073896
Pulled By: cipolleschi
fbshipit-source-id: bd2a71bb00ce5c5509ed403842c995c32f58f91d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47547
In [#47176](https://github.com/facebook/react-native/pull/47176) we disabled the generation of the component registration for app specific components as it was creating a circular dependency between the app and React Native.
However, we made a couple of typos that make it not work as expected and users picked up those typos soon.
This change fixes them for good.
## Changelog
[iOS][Fixed] - Properly stop generating component registration for components defined in app.
Reviewed By: blakef
Differential Revision: D65750433
fbshipit-source-id: 1a879c5be014905558b9fd05e6f16ac36b784ed6
Summary:
Fixes https://github.com/facebook/react-native/issues/47352
This fixes a bug when the user is providing its own CMakeLists.txt file say because they want to compile more C++ code than we actually provide.
Previously the `*.cpp` will evalute file in the current directory, meaning that the app's default `OnLoad.cpp` file would be ignored.
## Changelog:
[ANDROID] [FIXED] - Use absolute path when compiling appmodules.so sources
Pull Request resolved: https://github.com/facebook/react-native/pull/47379
Test Plan:
Tested against the reproducer provided in:
- Use absolute path when compiling appmodules.so sources
Reviewed By: cipolleschi
Differential Revision: D65428676
Pulled By: cortinico
fbshipit-source-id: 7f3e4d470da0fffc5191c1a2c7e8fec517fee496
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47339
Fixing issue raised in https://github.com/facebook/react-native/issues/47307
This is a follow up from D62286026.
It appears there was a line that went missing while trying to refactor the code.
`fitsSystemWindows = true` is needeod for < API 30 to avoid content rendering under the system bars when Modal is shown with Activity that is edge-to-edge.
Changelog:
[Android][Fixed] Fix Regression - Modal content rendering below system bar on < API 30 when activity is edge-to-edge
Reviewed By: cortinico
Differential Revision: D65280014
fbshipit-source-id: 616ff739be55635f1295ef3bf8b997a27ef769ae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47269
There were [reports](https://github.com/reactwg/react-native-releases/issues/595) that patching in the fixes for iOS controlled input did not work as expected.
I think tracked this down to a difference in how I tested, where the controlled component I used passed value as a child of the `TextInput`, instead of via `value`. Passing via `value` triggers a secondary bug, where we don't correctly pass a reference to correct ShadowView when creating attributedstring, specifically in the iOS TextInputShadowNode impl.
We previously passed nothing for the ShadowView (only the first two struct fields). This was exposed in D52589303 which enabled `-Wextra`, but there, I went with same behavior of passing empty ShadowView, instead of the correct behavior (like Android impl) of passing a ShadowView of the current ShadowNode.
After fixing this, we now correctly create event emitters in the passed attributedstring, which matches expectations for pargraph-level eventemitter now in typing attributes. We don't seem actually use this on iOS for TextInput right now (just Text), but this is likely the right foundation for events regardless.
Changelog:
[iOS][Fixed] - Fix missing emitter attributes on iOS TextInput when controlled component value specified using `value` instead of `children`
Reviewed By: cipolleschi
Differential Revision: D65108163
fbshipit-source-id: 499fe28439fabd2579eca6ded7fd13fd8ea2e43e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46970
Fixes https://github.com/facebook/react-native/issues/44157
This one is a bit of a doozy...
During auto-correct in UITextField (used for single line TextInput) iOS will mutate the buffer in two parts, non-atomically. After the first part, after iOS triggers `textFieldDidChange`, selection is in the wrong position. If we set full new AttributedText at this point, we propagate the incorrect cursor position, and it is never restored.
In the common case, where we are not mutating text in the controlled component, we shouldn't need to be setting AttributedString in the first place, and we do have an equality comparison there currently. But it is defeated because attributes are not identical. There are a few sources of that:
1. NSParagraphStyle is present in backing input, but not the AttributedString we are setting.
2. Backing text has an NSShadow with no color (does not render) not in the AttributedText
3. Event emitter attributes change on each update, and new text does not inherit the attributes.
The first two are part of the backing input `typingAttributes`, even if we set a dictionary without them. To solve for them, we make attribute comparison insensitive to the attribute values in a default initialized control. There is code around here fully falling back to attribute insensitive comparison, which we would ideally fix to instead role into this "effective" attribute comparison.
The event emitter attributes being misaligned is a real problem. We fix in a couple ways.
1. We treat the attribute values as equal if the backing event emitter is the same
2. We set paragraph level event emitter as a default attribute so the first typed character receives it
After these fixes, scenario in https://github.com/facebook/react-native-website/pull/4247 no longer repros in new arch. Typing in debug build also subjectively seems faster? (we are not doing second invalidation of the control on every keypress).
Changes which do mutate content may be susceptible to the same style of issue, though on web/`react-dom` in Chrome, this seems to not try to preserve selection at all if the selection is uncontrolled, so this seems like less of an issue.
I haven't yet looked at old arch, but my guess is we have similar issues there, and could be fixed in similar ways (though, we've been trying to avoid changing it as much as possible, and 0.76+ has new arch as default, so not sure if worth fixing in old impl as well if this is very long running issue).
Changelog:
[iOS][Fixed] - Fix cursor moving in iOS controlled single line TextInput on Autocorrection (New Arch)
Reviewed By: javache, philIip
Differential Revision: D64121570
fbshipit-source-id: 2b3bd8a3002c33b68af60ffabeffe01e25c7ccfe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47195
When a user wants to create a Fabric Component i their app (not in a separate library) the app fails to build because:
- The custom component has to inherit from `RCTViewComponentView`
- `RCTViewComponentView` imports `ViewProps.h`
- `ViewProps.h` imports `HostPlatformViewProps.h`
- `HostPlatformViewProps.h` imports `BaseViewProps.h`
- `BaseViewProps.h` imports `YogaStylableProps.h`
which is a Yoga private header and the App has not visibility over it.
It is also not possible to fix this issue with forward declaring the `YogaStylableProps`, because `BaseViewProps` inherit from the yoga's props, so the compiler needs the full declaration of `YogaStylableProps` to work
This needs to be picked in 0.76
## Changelog
[iOS][Fixed] - Give apps access to Yoga headers
Reviewed By: blakef
Differential Revision: D64925222
fbshipit-source-id: e724076bbfb0a678948340dfab2ce609e6509533
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47018
This change makes it so that newly typed text in a TextInput will include the existing attributes present based on cursor position. E.g. if you type after an inner fragment with blue text, the next character will be blue (or, an event emitter specific to an inner fragment will also be expanded). This is a behavior change for the (admittedly rare) case of uncontrolled TextInput with initially present children AttributedText, but more often effect controlled components, before state update (we are after, less likely to need to reset AttributedString because of mismatch).
Originally included this in D64121570, but it's not needed to fix the common case since we include paragraph-level event emitter as part of default attributes, and has some of its own risk, so I decided it is better separate.
Changelog:
[iOS][Changed] - Include existing attributes in newly typed text
Reviewed By: cipolleschi
Differential Revision: D64352310
fbshipit-source-id: 90ef8c49f50186eadf777e81cf6af57e1aada207
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46484
We recently realized that we don't have TS types for Codegen.
These are needed to let our users use these types when writing Specs in TS
## Changelog
[General][Added] - Add CodegenTypes for TS
Reviewed By: christophpurrer
Differential Revision: D62644516
fbshipit-source-id: 92bb7e8998d31806f6eb63319fb6d406fcd65ad8
* Re-enable integration tests (#46639)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46639
These tests were skipped when we were switching to component stacks, which also hid a bug later in the stack. Re-enable them.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D63349616
fbshipit-source-id: ccde7d5bb3fcd9a27adf4af2068a160f02f7432a
* Add integration tests for console errors + ExceptionManager (#46636)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46636
Adds more integration tests for LogBox (currently incorrect, but fixed in a later diff).
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D63349614
fbshipit-source-id: 8f5c6545b48a1ed18aea08d4ecbecd7a6b9fa05a
* Refactor LogBox tests to spies (#46638)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46638
This is annoying, but in the next diff that fixes a bug I need to test using the default warning filter instead of a mock (really, all this mocking is terrible, idk why I did it this way).
Unfortunately, in Jest you can't just reset mocks from `jest.mock`, `restoreMocks` only resets spies and not mocks (wild right).
So in this diff I converted all the `jest.mock` calls to `jest.spyOn`. I also corrected some of the mocks that require `monitorEvent: 'warning',` like the warning filter sets.
I also added a test that works without the fix.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D63349615
fbshipit-source-id: 4f2a5a8800c8fe1a10e3613d3c2d0ed02fca773e
* Fix errors with component stacks reported as warnings (#46637)
Summary:
Ok so this is a doozy.
## Overview
There was a report that some console.error calls were being shown as warnings in LogBox but as console.error in the console. The only time we should downlevel an error to a warning is if the custom warning filter says so (which is used for some noisy legacy warning filter warnings internally).
However, in when I switched from using the `Warning: ` prefix, to using the presence of component stacks, I subtly missed the default warning filter case.
In the internal warning filter, the `monitorEvent` is always set to something other than `unknown` and if it's set to `warning_unhandled` then `suppressDialog_LEGACY` is always false.
However, the default values for the warning filter are that `monitorEvent = 'unknown'` and `suppressDialog_LEGACY = true`. In this case, we would downlevel the error to a warning.
## What's the fix?
Change the default settings for the warning filter.
## What's the root cause?
Bad configuration combinations in a fragile system that needs cleaned up, and really really bad testing practices with excessive mocking and snapshot testing (I can say that, I wrote the tests)
## How could it have been caught?
It was, but I turned off the integration tests while landing the component stack changes because of mismatches between flags internally and in OSS, and never turned them back on.
Changelog: [General] [Fixed] - Fix logbox reporting React errors as Warnings
Pull Request resolved: https://github.com/facebook/react-native/pull/46637
Reviewed By: huntie
Differential Revision: D63349613
Pulled By: rickhanlonii
fbshipit-source-id: 32e3fa4e2f2077114a6e9f4feac73673973ab50c
* [LOCAL] using older version of React Dev Tools
- Older version has old URL, updated tests
- Comments on test don't match what's being tested. Updated.
---------
Co-authored-by: Rick Hanlon <rickhanlonii@meta.com>
Summary:
AppRegistry was not treated as a Callable Module in bridgeless mode. This is breaking headless tasks on Android.
Fixes:
- https://github.com/facebook/react-native/issues/46050
## Changelog:
[ANDROID] [FIXED] - Made AppRegistry callable from Native code in Bridgeless (fixes headless tasks)
Pull Request resolved: https://github.com/facebook/react-native/pull/46480
Test Plan: Used repro from linked issue
Reviewed By: javache
Differential Revision: D62637486
Pulled By: cortinico
fbshipit-source-id: 756527003ac6d712e76c02c188e280d15c010068
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47237
The Xcodeproj gem has been released yesterday to version 1.26.0 and it broke the CI pipeline of react native.
This should fix the issue
## Changelog
[Internal] - Pin Xcodeproj gem to 1.26.0
Reviewed By: blakef
Differential Revision: D65057797
fbshipit-source-id: f4035a1d3c75dd4140eb1646ab2aa0ccb08fb16b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47101
See https://github.com/facebook/react-native/issues/47011
borders do not have this problem because they call `removeAllAnimations` on the layer after changing it, which is what I am doing here
Changelog: [iOS] [fixed] - Fixed bug where background colors would sometimes animate when changing on Views
Reviewed By: cipolleschi
Differential Revision: D64493968
fbshipit-source-id: cf81549f21b124b67c6e7647c6ae827bfe80a9cf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47176
While writing the guide for the New Architecture, we realized that we need to exclude the generation of the Cls function in the RCTThirdPartyFabricComponentsProvider for components defined in the app.
This is needed because a component that is defined in the app will have those function defined in the app project. However, the RCTThirdPartyFabricComponentsProvider is generated in Fabric, inside the Pods project.
The pod project needs to build in isolation from the app and cocoapods then link the app to the pods project. But the compilation of the pods project fails if one of the symbol needed by the pods lives in the app.
By disabling the generation of that function in th RCTThirdPartyFabricComponentsProvider, we can successfully build the app.
The downside is that the user needs to register the component manually, but this is not an issue because if they are writing a component in the app space, they have all the information tomanually register it in the AppDelegate
## Changelog
[iOS][Fixed] - Do not generate the ComponentCls function in the RCTThirdPartyFabricComponentsProvider for components deined in the app.
Reviewed By: cortinico, blakef
Differential Revision: D64739896
fbshipit-source-id: 0eca818ea0198532a611377d14a3ff4c95cb5fe3
Summary:
For users who may have node installed in a path with a space, this requires escaping. For example:
```
NODE_BINARY=/Users/blakef/Library/Application Support/fnm/node-versions/v20.12.0/installation/bin/node
```
Needs to be:
```
NODE_BINARY=/Users/blakef/Library/Application\ Support/fnm/node-versions/v20.12.0/installation/bin/node
```
# Changelog
[iOS][Fixed] Generated NODE_BINARY in .xcode.env.local now supports paths with a space
Reviewed By: cipolleschi
Differential Revision: D64080118
fbshipit-source-id: 1045473e4fd284fc570fa538984618630be1af6d
Summary:
Whe migrating this interface to Kotlin we've subtly introduced a breaking change which is causing a lot of breakages in the ecosystem.
This is forcing users to do:
```
// Before
reactContext.getNativeModule(UIManagerModule::class.java)!!.eventDispatcher
// After
reactContext.getNativeModule(UIManagerModule::class.java)!!.getEventDispatcher()
```
This reverts this breaking change.
Plus the method had a generic parameters which was completely unnecessary so I'm removing it.
Changelog:
[Android] [Fixed] - Undo breaking change on UIManager eventDispatcher accessor
Reviewed By: cipolleschi
Differential Revision: D64533594
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47086
When we migrated `ViewManagerDelegate` to Kotlin, we convered his string params to be `String` (rather than `String?`).
Existing implementation of this interface in OSS written in Kotlin were using `String?` due to this interface being in Java (and not being Nullsafe annotated).
Therefore now changing this interface from `String?` to `String` is a breaking change for them.
Affected libraries are:
https://github.com/search?q=%22fun+receiveCommand%28%22+%22commandId%3A+String%3F%22+%22args%3A+ReadableArray%22+language%3Akotlin+-org%3Afacebook+-is%3Afork&type=code&p=4
This prevents the breaking change and should be included in 0.76.
Changelog:
[Android] [Fixed] - Undo breaking change on ViewManagerDelegate.kt String params
Reviewed By: cipolleschi
Differential Revision: D64532446
fbshipit-source-id: aac286554ad0e35f557160f900bcbad1acc5930d
Summary:
The previous scripts to trigger the react-native-communty/template
release workflow has not been working. This is a rewrite is js, along
with some testing to make this more robust.
I've have a PR to combine the publish and tag steps in the template publication: https://github.com/react-native-community/template/pull/65, this takes advantage of that change.
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/46363
Test Plan:
1. Unit tests
2. Once the infrastructure lands in the `react-native-community/template` workflow, we can trigger a dry run.
## TODO:
- ~~Still needs to be used in the GH release workflow.~~
- ~~Template release workflow needs to land the dry_run input change.~~
## Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D62296008
Pulled By: blakef
fbshipit-source-id: 217326c44b1d820e36a1d847cf9ad24d228087c1
Summary:
When migrating `PackagerConnectionSettings` from Java to Kotlin in https://github.com/facebook/react-native/pull/45800 the new class ended up being declared as final, causing a breaking change in 0.76.
We should add the `open` directive to `PackagerConnectionSettings.kt` to restore the old behavior. That would be crucial for the `expo-dev-client` package, given that Expo needs to be able to extend this class in order to overwrite the `debugServerHost` value.
## Changelog:
[ANDROID] [FIXED] - Make PackagerConnectionSettings class open again
Pull Request resolved: https://github.com/facebook/react-native/pull/47005
Test Plan: Run RNTester on Android
Reviewed By: huntie
Differential Revision: D64323645
Pulled By: cortinico
fbshipit-source-id: 6870a3dee929ba664e4c402f321f84af7704f892
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46764
This is a patched fix to earlier attempt (D63700769) and resolving crash due to`java.lang.IllegalArgumentException: View=DecorView@b9f88af[AdsManagerActivity] not attached to window manager`.
- removing ` !dialogWindow.isActive` check as it is always true resulting in always doing early return causing other bugs
- adding try/ catch instead so the code can still run but can catch the known exception without crashing
Changelog:
[Android][Fixed] - Fix crash for Modal not attached to window manager
Reviewed By: mdvacca
Differential Revision: D63712422
fbshipit-source-id: 85fb6df340eb1139f954c92b5f1daf0dc41671d2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46472
Currently, we are building the Debug symbols (dSYM) for hermes dSYM but we are not shipping them with the xcframework.
This is correct, because Debug symbols can increase the size of Hermes thus enalrging the iOS IPA and increasing the download time when installing pods.
We distribute the dSYM separatedly, in case users needs to symbolicate Hermes stack traces.
However the path to the dSYM still appears in the Info.plist of the universal XCFramework and this can cause issues when submitting an app to apple.
This change should remove those lines from the universal framework.
It fixes https://github.com/facebook/react-native/issues/35863
[Internal] - Remove dSYM path from Info.plist
Reviewed By: cortinico
Differential Revision: D62603425
fbshipit-source-id: 038ec3d6b056a3d6f5585c8125d0430f56f11bb9
2024-10-15 10:08:57 +01:00
171 changed files with 2607 additions and 1315 deletions
"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.",
'Warning: Each child in a list should have a unique "key" prop.%s%s See https://reactjs.org/link/warning-keys for more information.%s',
'\n\nCheck the render method of `DoesNotUseKey`.',
'',
expect.stringMatching('at DoesNotUseKey'),
]);
expect(spy).toHaveBeenCalledWith({
level:'error',
category:expect.stringContaining(
'Warning: Each child in a list should have a unique',
),
componentStack:expect.anything(),
componentStackType:'stack',
message:{
content:
'Warning: Each child in a list should have a unique "key" prop.\n\nCheck the render method of `DoesNotUseKey`. See https://reactjs.org/link/warning-keys for more information.',
substitutions:[
{length:45,offset:62},
{length:0,offset:107},
],
},
});
// The Warning: prefix is added due to a hack in LogBox to prevent double logging.
// We also interpolate the string before passing to the underlying console method.
expect(mockError.mock.calls[0]).toEqual([
expect.stringMatching(
'Warning: Each child in a list should have a unique "key" prop.\n\nCheck the render method of `DoesNotUseKey`. See https://reactjs.org/link/warning-keys for more information.\n at ',
),
]);
});
it('integrates with React and handles a fragment warning in LogBox',()=>{
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.