chore(0.76): Merge up to 0.76.7 upstream #2388
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…5187) Summary: in iOS on a scroll generated programatically, the `onMomentScrollEnd` is fired, though in case of android the same does not happen, this PR tries to implement the same behaviour for android as well, while diving through the code it seems we have two extra `onMomentumScrollEnd` events. Only one event should be fired. **iOS Behaviour on Programmatic Scroll** https://github.com/facebook/react-native/assets/72331432/fb8f16b1-4db6-49fe-83a1-a1c40bf49705 https://github.com/facebook/react-native/assets/72331432/9842f522-b616-4fb3-b197-40817f4aa9cb **Android Behaviour on Programmatic Scroll** https://github.com/facebook/react-native/assets/72331432/c24d3f06-4e2a-4bef-81af-d9227a3b1a4a https://github.com/facebook/react-native/assets/72331432/d4917843-730b-4bd7-90d9-33efb0f471a7 If closely observed we can see the `onMomentumScrollEnd` does not gets called in Android unlike to iOS. [Android][Fixed] - Dispatch onMomentumScrollEnd after programmatic scrolling Pull Request resolved: facebook#45187 Test Plan: i have added updates to the FlatList example and ScrollViewSimple here is a ScreenRecording of `onMomentumScrollEnd` firing in android after the code changes https://github.com/facebook/react-native/assets/72331432/f036d1a5-6ebf-47ba-becd-4db98a406b15 https://github.com/facebook/react-native/assets/72331432/8c788c39-3392-4822-99c5-6e320398714b Reviewed By: javache Differential Revision: D65539724 Pulled By: Abbondanzo fbshipit-source-id: f3a5527ac5979f5ec0c6ae18d80fdc20c9c9c14b
Summary: Pull Request resolved: facebook#47333 Motivated by facebook/hermes#1549. This was originally changed in facebook#46696, as our internal Flow support had diverged from `babel/eslint-parser` (facebook#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: Pull Request resolved: facebook#47669 When investigating [facebook#47476](facebook#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: Fixes facebook#47656 . ## Changelog: [IOS] [FIXED] - Fabric: Fixes custom font of weight is not honored Pull Request resolved: facebook#47691 Test Plan: Demo in facebook#47656 Reviewed By: cipolleschi Differential Revision: D66174732 Pulled By: javache fbshipit-source-id: 5e6a8c870d3a13283548c736aed73193f7976bfc
Summary: Fixes another font weight issue mentioned in facebook#47656 (comment). We can get the weight from font name if user not specify weight. esbenvb Is this work for you ? ## Changelog: [IOS] [FIXED] - Fabric: Adjusts the weight according to the font name Pull Request resolved: facebook#47742 Test Plan: Demo in facebook#47656 (comment). Reviewed By: cipolleschi Differential Revision: D66236128 Pulled By: javache fbshipit-source-id: d325a7fee28681a1e95fa0341cb7a16fcd9918c0
…onse to new text content (facebook#47737) Summary: Pull Request resolved: facebook#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
…nfig (facebook#47670) Summary: Pull Request resolved: facebook#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 facebook/hermes#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: facebook#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:
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 facebook#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: facebook#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: Fixes facebook#48030 . [IOS] [FIXED] - Fabric: Fixes Modal onRequestClose not called Pull Request resolved: facebook#48037 Test Plan: Repro please see facebook#48030. Reviewed By: cortinico Differential Revision: D66647232 Pulled By: cipolleschi fbshipit-source-id: 773517dfe45f6f2e6348cda225e972fbac05edc2
…iated (facebook#48007) 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: facebook#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
…ntry points in Sources panel) (facebook#47726)
…ok#46433) Summary: Pull Request resolved: facebook#46433 Original commit changeset: 53667cf1a75e Original Phabricator Diff: D62143463 Changelog: [Internal] revert previous modal presentation improvement Reviewed By: sammy-SC Differential Revision: D62474039 fbshipit-source-id: b510c0460c06ab9d595d414d4ea32acd224871bc
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: facebook#48122 Test Plan: GHA {F1973187648} Reviewed By: alanleedev Differential Revision: D66825216 Pulled By: cipolleschi fbshipit-source-id: 9a9376a5409e192195a6b6cc25b4d58cb47f15da
#publish-packages-to-npm&latest
Changelog: [Internal]
Summary: Fixes facebook#47731 . [IOS] [FIXED] - Fabric: Fixes insets not adjust when keyboard disappear Pull Request resolved: facebook#47924 Test Plan: Demo in facebook#47731 Reviewed By: blakef Differential Revision: D66651865 Pulled By: cipolleschi fbshipit-source-id: a75afbd1a7651f0c77022d913f910821c482fcf7
Summary: Pull Request resolved: facebook#48124 Fixes facebook#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
facebook#48082) Summary: Fixes facebook#47949 ## Changelog: [IOS] [FIXED] - Fabric: Post RCTInstanceDidLoadBundle notification after bundle loaded Pull Request resolved: facebook#48082 Test Plan: Post RCTInstanceDidLoadBundle notification after bundle loaded Reviewed By: philIip Differential Revision: D66754060 Pulled By: cipolleschi fbshipit-source-id: d30f0ed73e127936082e6f91e137b9b4013c6651
…cebook#46732) Summary: Fixes facebook#46595 . It seems facebook#37766 broke the `automaticallyAdjustKeyboardInsets` when input accessory view become first responder. [IOS] [FIXED] - automaticallyAdjustKeyboardInsets not shifting scrollview content Pull Request resolved: facebook#46732 Test Plan: Repro please see in #facebook#46595 . Reviewed By: cipolleschi Differential Revision: D65072478 Pulled By: javache fbshipit-source-id: 7d5d7566438d4bb0e1d50074a953b18866e324d3
The d1ce8fa pick from 0.77 used the new ReactNativeFeatureFlags, backport this.
#publish-packages-to-npm&latest
Changelog: [Internal]
… name (facebook#48174) Summary: Fixes an [issue](facebook#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: facebook#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: facebook#48026 This should mitigate this particular issue we're seeing on Windows: - facebook#46210 Changelog: [Android] [Changed] - Gradle to 8.11.1 Reviewed By: javache Differential Revision: D66600321 fbshipit-source-id: d58437485222e189d90bcf4d6b41ca956449ed22
…book#48225) Summary: Pull Request resolved: facebook#48225 Fixes facebook#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 facebook#47563 It seems like a regression from facebook#45401, where it was aimed to fix `onChangeText` being called multiple times when changing the text programmatically in an input with the `multiline` prop set as true. This PR reverts that partially, as the `maxLength` check is not being evaluated correctly before setting the text. Not reverting it completely as when removing the second part of the fix, the `onChangeText` gets called multiple times again. ## Changelog: [IOS] [FIXED] - Fixing TextInput `maxLength` not working in old arch Pull Request resolved: facebook#48126 Test Plan: The issue could be reproduced in the rn-tester. See my videos with the before and after the fix. <details> <summary>Before:</summary> https://github.com/user-attachments/assets/86fd67eb-fc14-469a-a5f8-8e83b49f857c </details> <details> <summary>After:</summary> https://github.com/user-attachments/assets/368383b1-c1bd-4e0b-ac44-c78022462fa0 </details> Reviewed By: cortinico Differential Revision: D67025182 Pulled By: cipolleschi fbshipit-source-id: 720c400eef362618106ae434aef421c7529214fe
…#48525) Summary: Pull Request resolved: facebook#48525 Fixes facebook#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
#publish-packages-to-npm&latest
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: facebook#48376 Test Plan: Ran a local test after change Reviewed By: javache Differential Revision: D67621557 Pulled By: cipolleschi fbshipit-source-id: 2d73711372deba867bd616c79ef4d00c79aa86d5
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
…acebook#47739) Summary: Fixes facebook#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: facebook#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: 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
Summary: Pull Request resolved: facebook#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: `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
…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#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
… 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 [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. | 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
#publish-packages-to-npm&0.76-stable
Changelog: [Internal]
Saadnajmi
commented
Feb 28, 2025
...ges/react-native/React/Fabric/Mounting/ComponentViews/TextInput/RCTTextInputComponentView.mm
Show resolved
Hide resolved
Saadnajmi
force-pushed
the
merge-0-76-7
branch
from
456e81d to
533af03
Compare
tido64
approved these changes
Feb 28, 2025
Saadnajmi
force-pushed
the
merge-0-76-7
branch
from
533af03 to
726f4fc
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
23 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary:
Merge the rest of the 0.7-stable branch upstream, which gets us to the equivalent of
0.76.7Test Plan:
CI should pass