-
Notifications
You must be signed in to change notification settings - Fork 24.8k
Amit/rn 0.78.2 patch fix #52755
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
base: main
Are you sure you want to change the base?
Amit/rn 0.78.2 patch fix #52755
Conversation
#publish-packages-to-npm&next
Summary: Pull Request resolved: facebook#48656 While working on 0.78, I realize we were not testing the template app with JSC. This change should fix this. ## Changelog: [Internal] - Disable Hermes for the JSC E2E tests with Maestro Reviewed By: cortinico, fabriziocucci Differential Revision: D68147849 fbshipit-source-id: 4fbe005b5d04d6163a37041d1bd57fd48a9dfda8
Summary: This change improves the E2E testing by downloading the iOS RNTesterApp that is built in CI instead of building it locally. This should let us save 10 to 20 minutes when we test a new release. ## Changelog: [Internal] - Use the RNTester app built in CI for release testing on iOS Pull Request resolved: facebook#48637 Test Plan: - build the app in ci - run `yarn test-e2e-local -c <my-token>` and `yarn test-e2e-local -h false -c <my-token>` and verify that the iOS app is not built, but run in the simulator Reviewed By: cortinico Differential Revision: D68161477 Pulled By: cipolleschi fbshipit-source-id: 577d110f9ff0197a2d3348a08a60e60a4d0a752b
Summary: Following the suggestions [here](https://stackoverflow.com/questions/79360526/uninitialized-constant-activesupportloggerthreadsafelevellogger-nameerror), it seems that concurrent-ruby has been released tonight and it is bugged. Let's pin it to the right version. ## Changelog: [iOS][Changed] - Pin 'concurrent-ruby' to a working version Pull Request resolved: facebook#48721 Test Plan: GHA Reviewed By: robhogan Differential Revision: D68262719 Pulled By: cipolleschi fbshipit-source-id: fc6410e28cc96f9d3769d3082a77cac0a3efe6db
Summary: Pull Request resolved: facebook#48672 ## Changelog: [General] [Fixed] - Buttons becoming unresponsive when transform is animated # The problem D67872307 changes when `ensureUpdateSubscriptionExists` is called to in `__attach`. This breaks the functionality because `__attach` is called before flag `__isNative` is set and subscriptions are never setup. # Fix The diff sets up subscriptions in `__makeNative` method. Reviewed By: yungsters Differential Revision: D68154908 fbshipit-source-id: e2ac108b064a66dda08902653d6bd20286f92458
…book#48678) Summary: Pull Request resolved: facebook#48678 While diagnosing a recent issue in which `AnimatedValue` instances were not being correctly updated as expected, the insertion effects feature flag was identified as a root cause. Upon further investigation, it appears that this is because the `onUserDrivenAnimationEnded` listener was not implemented the same way in the two feature flag states: - When `useInsertionEffectsForAnimations` is disabled, `useAnimatedProps` listens to `onUserDrivenAnimationEnded` in a passive effect, after all nodes have been attached. - When `useInsertionEffectsForAnimations` is enabled, `useAnimatedProps` listens to `onUserDrivenAnimationEnded` in an insertion effect when attaching nodes. The bugs occurs because `useAnimatedProps` checks whether native driver is employed to decide whether to listen to `onUserDrivenAnimationEnded`. However, we do not know whether native driver will be employed during the insertion effect. (Actually, we do not necessarily know that in a passive effect, either... but that is a separate matter.) This fixes the bug when that occurs when `useInsertionEffectsForAnimations` is enabled, by moving the listening logic of `onUserDrivenAnimationEnded` into a passive effect. This is the same way that it is implemented when `useInsertionEffectsForAnimations` is disabled. Changelog: [Internal] Reviewed By: javache, sammy-SC Differential Revision: D68171721 fbshipit-source-id: 50b23348fd4641580581cacebc920959651f96a7
…48715) Summary: Pull Request resolved: facebook#48715 {D68154908} fixed a problem with the `onAnimatedValueUpdate` listener not being correctly attached if `__attach` were called before `__makeNative` (which sets `__isNative` to true). We're potentially seeing production symptoms of stuttering interactions and user responsiveness, after queuing up many operations. Our hypothesis is that in scenarios where `ensureUpdateSubscriptionExists` is being called during `__makeNative` (instead of during `__attach`), a backup of operations occurs leading to these symptoms. This diff attempts to validate and mitigate this hypothesis by deferring `ensureUpdateSubscriptionExists` to when an `AnimatedValue` instance has had both `__attach` and `__makeNative` invoked. Changelog: [Internal] Differential Revision: D68236594 fbshipit-source-id: 2089100a773ebfc161fb5b567123eb58a893939f
#publish-packages-to-npm&next
Changelog: [Internal]
Summary: Pull Request resolved: facebook#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](facebook#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
#publish-packages-to-npm&next
Changelog: [Internal]
… Android (facebook#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](facebook#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](facebook/react-native@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 facebook#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: facebook#48998 Test Plan: See full explanation on facebook#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: `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: facebook#49047 Test Plan: n/a Reviewed By: cortinico Differential Revision: D68835789 Pulled By: huntie fbshipit-source-id: 13718f4970ed55e6e062b7c2bd719be977abdd0c
… in new architecture (facebook#47614) Summary: The `maxFontSizeMultiplier` prop for `Text` and `TextInput` was not handled in Fabric / New Architecture as documented in facebook#47499. bypass-github-export-checks ## Changelog: [GENERAL] [FIXED] - Fix `maxFontSizeMultiplier` prop on `Text` and `TextInput` components in Fabric / New Architecture Pull Request resolved: facebook#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. ### Text | 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" /> | ### TextInput | 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
facebook#48995) Summary: Pull Request resolved: facebook#48995 This change adds an extra parameter to the codegen script that allow our users to trigger codegen for Apps or for Libraries. When running codegen for Apps, we have to generate some extra files that are not needed by the Libraries. This is causing issues to our library maintainers and this change will provide more flexibility in the DevX of libraries. The default value is App, so if the new parameter is not passed, nothing will change in the current behavior. [iOS][Added] - Add the `source` parameter to generate-codegen-artifacts to avoid generating files not needed by libraries. Reviewed By: cortinico Differential Revision: D68765478 fbshipit-source-id: 8030b4472ad4f5058e58b1c91089de5122a4f60a
#publish-packages-to-npm&next
…book#49072) Summary: Pull Request resolved: facebook#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: - facebook#47587 - facebook#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: 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
Summary: Pull Request resolved: facebook#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
…on (facebook#49233) Summary: Pull Request resolved: facebook#49233 I'm converting the function inside ReactPointerEventsView from `fun` to `val`. This Kotlin conversion resulted in a breakign change for Kotlin consumer which I believe can be prevented if we do this change instead. Changelog: [Internal] [Changed] - Reviewed By: alanleedev Differential Revision: D69252562 fbshipit-source-id: b277c6720f3156ed532bf5f2253d54cd72e38050
Summary: Pull Request resolved: facebook#49229 This interface was converted to Kotlin, but the single method should have been converted to a `val`. People kotlin consumers could call ReactOverflowView.overflow; now they need to call getOverflow(). Changelog: [Internal] [Changed] - Undo a breaking change on ReactOverflowView Reviewed By: NickGerleman Differential Revision: D69250226 fbshipit-source-id: 5c7cca8c83f5c76a9cc1d254f8aa51409150c356
Summary: Pull Request resolved: facebook#49247 This was incorrectly made internal in https://www.internalfb.com/diff/D66724567 Changelog: [Android][Removed] Made ReactCookieJarContainer internal. Reviewed By: cortinico, andrewdacenko Differential Revision: D69254203 fbshipit-source-id: 5c4ba9b4f9a8e53002df25b55f0c8762874e6736
#publish-packages-to-npm&next
Changelog: [Internal]
Summary: Make UIBlock.execute params non nullable to avoid breaking changes for kotlin usages in OSS changelog: [internal] internal Reviewed By: NickGerleman Differential Revision: D69407325 fbshipit-source-id: 5fc01fba9baba97e21a388d02cf98d5aebb5ac20
#publish-packages-to-npm&next
Changelog: [Internal]
#publish-packages-to-npm&latest
Changelog: [Internal]
Summary: `loadSourceForBridge` is broken after we refactor the appdelegate. So let's add it back. ## Changelog: [IOS] [FIXED] - Added custom load js block in bridge mode Pull Request resolved: facebook#48845 Test Plan: Custom Appdelegate's `loadSourceForBridge` can be called in bridge mode. Reviewed By: robhogan Differential Revision: D68832046 Pulled By: cipolleschi fbshipit-source-id: dcea791e6d8243fdb2f45a33af175aee1a4e1223
Summary: Pull Request resolved: facebook#48997 Follows react-native-community/cli#2584. - Also add FIXME comment flagging potential core APIs gap without CLI. Changelog: [Internal] Reviewed By: cortinico Differential Revision: D68766565 fbshipit-source-id: 60747715f76c4323e306c39ab0613fb4818b4914
* Fix elevation with border-radius set (facebook#48982) * Update packages/react-native/ReactAndroid/src/main/java/com/facebook/react/uimanager/drawable/CompositeBackgroundDrawable.kt --------- Co-authored-by: Nicola Corti <corti.nico@gmail.com>
Summary: Fixes facebook#49819 . Details about how the issue was introduced in the issue description. bypass-github-export-checks ## Changelog: [IOS] [FIXED] - Fixed: extraModulesForBridge callback not called when New Architecture enabled <!-- 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: facebook#49849 Test Plan: Without the change: 1. Open `packages/rn-tester` project 2. In `AppDelegate.mm`, implement `extraModulesForBridge` and add a breakpoint / output something 3. Run the app in iOS <-- Verify that the method is not executed With the change: 1-3. Same as above <-- verify that the method is called correctly > [!NOTE] > As far as I could tell, there is no test suite for this specific codepath, so I didn't write a test for this change. Happy to write one if someone can guide me a little bit. Reviewed By: rshest Differential Revision: D70724196 Pulled By: cipolleschi fbshipit-source-id: cc08798d08cdbd6883347810c7d2697c358770fb
The publishTemplate script references a variable that is not defined. ## Changelog: [Internal] -
…acebook#49358) Summary: Pull Request resolved: facebook#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
… app on apple silicon mac (facebook#49320) Summary: Fixes facebook#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: facebook#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
Summary: Fixes facebook#49075 The Image `defaultSource` prop is causing a runtime error from 0.77 just by using it in the Image component (see error in the linked issue). This might be a regression from some changes in the prop processing logic from either facebook#47710, facebook#47713 or facebook#47754. [ANDROID] [FIXED] - Fix Image defaultSource runtime error Pull Request resolved: facebook#49097 Test Plan: - Verify it doesn't throw any error on runtime anymore for Android. - iOS behaviour should not be impacted as changes are Android specific In the RNTester, you can use the following component: ```tsx import * as React from 'react'; import {Image, View} from 'react-native'; function Playground() { return ( <View style={{flex: 1, justifyContent: 'center', alignItems: 'center'}}> <Image defaultSource={require('../../assets/bandaged.png')} source={{ uri: 'https://i.natgeofe.com/n/548467d8-c5f1-4551-9f58-6817a8d2c45e/NationalGeographic_2572187_4x3.jpg', }} style={{width: 200, height: 200}} /> </View> ); } ``` Also, this `defaultSource` prop is ignored in debug builds for Android ([as per the docs](https://reactnative.dev/docs/image#defaultsource)) – but I've verified we get the defaultSource as a string, which is what we expect on the native side: <details> <summary>Screenshot of the Android logs</summary>  </details> Reviewed By: javache Differential Revision: D69052723 Pulled By: cortinico fbshipit-source-id: 2860dd4c18cefcfcbc4e39f94dfa6305f45773a3
…li (facebook#49518) (facebook#50098) Summary: Pull Request resolved: facebook#49518 `react-native/community-cli-plugin` depends on `createDevServerMiddleware` from `react-native-community/cli-server-api`. `react-native/community-cli-plugin` currently [declares an optional peer dependency](https://github.com/facebook/react-native/blob/bae895500052bda2f55e1832b0c8a63a1b449de3/packages/community-cli-plugin/package.json#L39-L45) on `react-native-community/cli-server-api`, however because the latter isn't a dependency of `react-native` or the community template, the peer dependency is not available to package managers that enforce isolated node_modules - see facebook#47309. Rather than add an unnecessary dependency to the template (like [this](react-native-community/template#105)), my proposal is to switch to a peer dependency on only `react-native-community/cli`, because that *is* a dependency of the community template and therefore will be resolvable. Because `react-native-community/cli` doesn't re-export `createDevServerMiddleware` from its dependency on `cli-server-api`, we need to resolve the latter through the former. This can be cleaned up once a re-export lands - react-native-community/cli#2605. Changelog: [GENERAL][FIXED] Fix registering of `start` and `bundle` commands with community CLI and isolated node_modules. Reviewed By: huntie Differential Revision: D69848688 fbshipit-source-id: 009b8ffd43b2ab2d84fcc71e9e48382eb8950bb1
Summary: Pull Request resolved: facebook#49873 In the old architecture, when we were passing a `null` value as a parameter in a function that accepted nullable parameter, the null value was mapped to `nil` on iOS. After my changes in [d423679](facebook@d423679), in the New Architecture, through the interop layer, legacy modules were receiving an `NSNull` object instead of nil. This was breaking those modules which started crashing or observing undesired behavior. This change fixes the issue by making sure that, in those cases, a `nil` value is passed. Note that nested objects in the old architecture were correctly receiving NSNull, so nested objects were behaving correctly already. ## Changelog: [iOS][Fixed] - Properly pass `nil` for nullable parameters instead of `NSNull` for legacy modules Reviewed By: javache Differential Revision: D70723460 fbshipit-source-id: 384f48b6dbb3f54c369b31b6d2ee06069fa3591c
#publish-packages-to-npm&latest
Summary: fix: facebook#49368 description is provided inside the ticket. When we use TextInput on ios and manage selection with the selection prop, TextInput is reset when we change selection. ## Changelog: [IOS] [FIXED] - Fix selection makes TextInput clear its content when using children Pull Request resolved: facebook#49450 Test Plan: Tested with sample provided in ticket. I also test it with my app on both android and ios, but I cannot share video Reviewed By: sammy-SC Differential Revision: D69984616 Pulled By: cipolleschi fbshipit-source-id: a17169608f9df0ea1cb579e6038345f8e48bbc27
Summary: Pull Request resolved: facebook#49900 This appears to fix an issue where removing a sibling with zIndex breaks drawing of the next sibling. The theory is that eager return in `onViewRemoved` prevents the view from reverting into a state where it no longer uses custom draw order. However, tracing back history, this eager return was [added](facebook#43389) to fix a bug in Reanimated. cc bartlomiejbloniarz to confirm if [this Reanimated issue](software-mansion/react-native-reanimated#5715) resurfaces from this change. Fixes facebook#49838 ## Changelog [Android][Fixed] Fixes issue with z-indexed sibling removal Reviewed By: NickGerleman, cipolleschi Differential Revision: D70795631 fbshipit-source-id: 500af92226be29af73f36f911ffff27a0c083ae9
…cebook#49931) Summary: Pull Request resolved: facebook#49931 This change fixes the app startup in the Old Architecture by implementing the loadSourceForBridge:onProgress:onComplete method in the RCTDefaultReactNativeFactoryDelegate object. The method was missing here, so the Bridge was never trying to load the JS bundle from Metro, resulting in an empty app. ## Changelog: [iOS][Fixed] - Implement the loadSourceForBridge:onProgress:onComplete in the RCTDefaultReactNativeFactoryDelegate. Reviewed By: cortinico Differential Revision: D70898811 fbshipit-source-id: 3e5d519a1965e92ace91ca6d5b316a9069279448
…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: 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
…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
…0193) Summary: Pull Request resolved: facebook#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
#publish-packages-to-npm&latest
Hi @amitmundraz08! Thank you for your pull request and welcome to our community. Action RequiredIn order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you. ProcessIn order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA. Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks! |
|
Summary:
Changelog:
Test Plan: