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
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
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
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
Summary:
This fixes an issue where `POST /open-debugger?appId&device&target` does not return a proper status code, meaning that the request will never be answered and clients might hang until the request timeout is hit.
## 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] - Respond with status code `200` when successfully launching RNDT
Pull Request resolved: https://github.com/facebook/react-native/pull/46814
Test Plan:
- `curl -v -X POST "<deviceUrl>"`
- This should show a proper response for the request.
before | after
--- | ---
 | 
Reviewed By: NickGerleman
Differential Revision: D63837025
Pulled By: huntie
fbshipit-source-id: ac72fc793e015f0eec498f4a35b4fb9e301c5b32
Summary:
On the old architecture you could take control of loading the bundle by implementing
```objc
- (void)loadSourceForBridge:(RCTBridge *)bridge
onProgress:(RCTSourceLoadProgressBlock)onProgress
onComplete:(RCTSourceLoadBlock)loadCallback;
```
in your `RCTBridgeDelegate`. This is not currently possible in the new architecture.
I've added this using a pretty much identical api by adding a function to both the `RCTInstanceDelegate` and `RCTHostDelegate` protocols. This will be called on the `RCTRootViewFactory`. I've added two properties to the `RCTRootViewFactoryConfiguration`, `loadSourceForHost` and `loadSourceWithProgressForHost`. If one is present, we call it, otherwise we fallback to the normal loading process
## Changelog:
[iOS] [Breaking] - Add ability to control bundle loading on the new architecture similar to `loadSourceForBridge`. Removed some properties from the `RCTRootViewFactory`.
Pull Request resolved: https://github.com/facebook/react-native/pull/46731
Test Plan: Rn-tester works as normal and it is working for our use case in expo go.
Reviewed By: blakef
Differential Revision: D63755188
Pulled By: cipolleschi
fbshipit-source-id: f1f26b2775b9e547ce7a23028665797c19bfdd9b
Summary:
I discovered this while working on my shim of `UIGraphicsImageRenderer` for macOS (See https://github.com/microsoft/react-native-macos/pull/2209). A variable of type`CGColorRef` is not automatically retained and released when passed into a block. There was a case in `RCTBorderDrawing` where we were doing so. To fix this, we have two options:
1. Pass a `UIColor` instead (Requires a change to the signature of the function calling it)
2. Properly retain and release the variable.
The first option would technically be a breaking change (we would need to change the signature of `RCTGetBorderImage`, so I'm opting for option 2.
## Changelog:
[IOS] [FIXED] - Properly retain/release backgroundColor in RCTBorderDrawing
Pull Request resolved: https://github.com/facebook/react-native/pull/46797
Test Plan: CI should pass. Locally, borders still draw fine for me.
Reviewed By: joevilches
Differential Revision: D63827824
Pulled By: cipolleschi
fbshipit-source-id: 926601d062b90a7d741d7a1af3070cec4b8795ae
Summary:
Because `UIGraphicsImageRenderer` doesn't exist on macOS, I need to shim it for React Native macOS (See https://github.com/microsoft/react-native-macos/pull/2209). I planned to use the name `RCTUIGraphicsImageRenderer`. However.. it seems that is used by a static helper function in `RCTBorderDrawing.m`. So.. let's rename it? The function is just a helper method to make an instance of the class, so I think the name `RCTMakeUIGraphicsImageRenderer` is slightly more idiomatic anyway.
This method is not public, so it should not break the public API of React Native.
## Changelog:
[IOS] [CHANGED] - Rename `RCTUIGraphicsImageRenderer` to `RCTMakeUIGraphicsImageRenderer`
Pull Request resolved: https://github.com/facebook/react-native/pull/46772
Test Plan: CI should pass
Reviewed By: joevilches
Differential Revision: D63765490
Pulled By: cipolleschi
fbshipit-source-id: de68dce0f92ec249ea8586dbf7b9ba34a8476074
Summary:
Solve a part of this issue: https://github.com/facebook/react-native/issues/46631
## 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] [CHANGED] - Passed correct title and titleColor prop to updateTitle function
**What's the Issue:**
When updating the PullToRefreshViewProps in a React Native iOS app, changes to the title and titleColor were not being reflected properly in the RefreshControl. This happened because the function responsible for updating the title (_updateTitle) was not always receiving the correct or updated values for title and titleColor.
**Updated `_updateTitle` function:**
The _updateTitle method was modified to accept both title and titleColor as parameters. This ensures that the latest values are always used when updating the refresh control's attributedTitle.
If the title is empty, the attributedTitle is cleared by setting it to nil. Otherwise, both the title and titleColor (if present) are applied correctly.
Pull Request resolved: https://github.com/facebook/react-native/pull/46655
Test Plan:
**Without fix:**
https://github.com/user-attachments/assets/8a83c247-bf78-4080-bdc1-ac5a852481e8
**With Fix:**
https://github.com/user-attachments/assets/52e2495a-4419-41d1-b308-acb64600f9f7
Reviewed By: javache
Differential Revision: D63466516
Pulled By: cipolleschi
fbshipit-source-id: fef61a003b658b20a25b61b6d07ee9fe0750dae7
Summary:
Fixes https://github.com/facebook/react-native/issues/46568 . cc cipolleschi
## Changelog:
[IOS] [FIXED] - Fabric: Fixes animations strict weak ordering sorted check failed
Pull Request resolved: https://github.com/facebook/react-native/pull/46582
Test Plan:
See issue in https://github.com/facebook/react-native/issues/46568
## Repro steps
- Install Xcode 16.0
- navigate to react-native-github
- yarn install
- cd packages/rn-tester
- bundle install
- RCT_NEW_ARCH_ENABLED=1 bundle exec pod install
open RNTesterPods.xcworkspace to open Xcode
{F1885373361}
Testing with Reproducer from OSS
| Paper | Fabric (With Fix) |
|--------|-----------------|
| {F1885395747} | {F1885395870} |
Android - LayoutAnimation (Looks like it has been broken and not working way before this changes.)
https://pxl.cl/5DGVv
Reviewed By: cipolleschi
Differential Revision: D63399017
Pulled By: realsoelynn
fbshipit-source-id: aaf4ac2884ccca2da7e90a52a8ef10df6ae4fc8a
Summary:
React Native [app template provided by the CLI](https://github.com/react-native-community/template) currently uses [`metro-config` directly for `MetroConfig` type](https://github.com/react-native-community/template/blob/main/template/metro.config.js#L7).
However, it doesn't have `metro-config` as neither a dependency or dev dependency, which can lead to version mismatches.
While this is obviously a mistake on the template repo side, `metro-config` versions aren't matched with `react-native` versions. Therefore, getting the correct version of `metro-config` from `react-native/metro-config` would require reflecting on `react-native/metro-config`'s package.json etc. which is far from ideal. In my opinion it's would be much better to expose `MetroConfig` type from `react-native/metro-config` directly.
Version mismatching can happen in a monorepo setup. Say we have the monorepo structure using Yarn Modern:
```tree
.
├── RN75-app (workspace)
├── RN76-app (workspace)
│ ├── metro.config.js
│ └── node_modules
│ └── react-native
│ └── metro-config (0.76)
│ └── node_modules
│ └── metro-config (version for 0.76)
└── node_modules
├── react-native
│ └── metro-config (0.75)
└── metro-config (version for 0.75)
```
`react-native@0.75` gets hoisted to the monorepo root while `react-native@0.76` sits in an RN 0.76 app workspace.
Say we have the following `RN76-app/metro.config.js` contents:
```js
const {getDefaultConfig, mergeConfig} = require('react-native/metro-config');
/**
* Metro configuration
* https://reactnative.dev/docs/metro
*
* type {import('metro-config').MetroConfig}
*/
const config = {};
module.exports = mergeConfig(getDefaultConfig(__dirname), config);
```
In this case, `require('react-native/metro-config')` would resolve to `RN76-app/node_modules/react-native/node_modules/metro-config` since `react-native/metro-config` is a (dev) dependency of the App.
However `import('metro-config).MetroConfig` would resolve to `node_modules/metro-config` since it's not a direct dependency.
This is how we have a mismatch - imported functions come from different packages than imported type.
## Changelog:
[GENERAL] [ADDED] - Expose `MetroConfig` type directly from `react-native/metro-config`.
Pull Request resolved: https://github.com/facebook/react-native/pull/46602
Test Plan:
`yarn build` to generate dist for `react-native/metro-config`, see it has the export of `MetroConfig`.
## Notes
If this PR gets approved, I'll submit relevant one to the CLI template.
Reviewed By: huntie
Differential Revision: D63258881
Pulled By: robhogan
fbshipit-source-id: e6f3c880eb4a0aa902c62932d58f243c38b07c2e
Summary:
Similar to D63541483, modernises our Flow syntax support for our published ESLint config to use `hermes-eslint` (`hermes-parser`).
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D63541856
fbshipit-source-id: 06cc5725faf5934fda07713ec1dac54ff9c32ddf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46696
Following D62161923, we began to lose sync with modern Flow syntax when Metro's `transformer.hermesParser` option is disabled. This config option loads Babel for transformation (instead of `hermes-parser`), which requires a Babel plugin to parse (not strip) Flow syntax.
This diff migrates us away from `babel/plugin-syntax-flow` (see also https://github.com/babel/babel/issues/16264) and uses the modern [`babel-plugin-syntax-hermes-parser`](https://www.npmjs.com/package/babel-plugin-syntax-hermes-parser) instead (a component of the modern Hermes Parser stack).
Following this change, new projects that unset `transformer.hermesParser` will compile.
Resolves https://github.com/facebook/react-native/issues/46601.
Changelog:
[General][Fixed] - Fix parsing of modern Flow syntax when `transformer.hermesParser = false` is configured in Metro config
Reviewed By: cipolleschi
Differential Revision: D63535216
fbshipit-source-id: d2c6ddec030d89e2698e03b76194cf3568d04e6b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46699
Switch from legacy Babel Flow parser integrations to the Meta-maintained `hermes-eslint` and `babel-plugin-syntax-hermes-parser` packages (both part of the `hermes-parser` codebase).
Required to unblock D63535216.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D63541483
fbshipit-source-id: 04ccfa04c9a2b8c0a87ef1a5c38e952971838b77
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46694
The DevMenu module was never implemented on Android. This adds its implementation by mirroring the iOS implementation.
Fixes https://github.com/facebook/react-native/issues/46679
Changelog:
[Android] [Fixed] - Add missing Android implementation for DevMenu Module
Reviewed By: cipolleschi
Differential Revision: D63535172
fbshipit-source-id: 791e72b46b7d3264b98e85a73f2d9025dc3a2c7d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46677
Since removing `react-native-community/cli` as a dependency in 0.76 the `npx react-native init` command isn't working. This is the deprecated way to run this command, but users should still expect it to work for now.
This now forks this kind of request to `npx react-native-community/cli init <args>` as described in the warning logs to the user.
Changelog: [Internal]
Issue: reactwg/react-native-releases#508
Reviewed By: cortinico
Differential Revision: D63467046
fbshipit-source-id: 84560bdae8d6f62629dee61da3cbbf544b9a83b2
Summary:
I've noticed that some users are reporting build failures due to warnings inside RNGP.
We do have `allWarningsAsErrors` set to true for everyone (also for users).
That's too aggressive, and can cause build failures which are not necessary. Let's keep it enabled only on our CI (when the `enableWarningsAsErrors` property is set).
## Changelog:
[INTERNAL] - RNGP: Read `enableWarningsAsErrors` property correctly
Pull Request resolved: https://github.com/facebook/react-native/pull/46657
Test Plan: CI
Reviewed By: NickGerleman
Differential Revision: D63459601
Pulled By: cortinico
fbshipit-source-id: 0307e8d6771518038a5abe27ca5a993cb0a9f8c0
Summary:
While developing my project with New Architecture enabled I've found out that properties `tintColor` and `progressViewOffset` of component `RefreshControl` don't apply on iOS. This happens due to the lack of handling of these properties in the `RCTPullToRefreshViewComponentView.mm` class.
The bug can be easily reproduced in RNTester app on RefreshControlExample.js screen, since it has property `tintColor="#ff0000"` (Red color), but RefreshControl renders with gray color:
<img width="300" alt="RefreshControlExample.js" src="https://github.com/user-attachments/assets/10931204-dbe8-4cbd-9adc-d0f38319febd">
<img width="300" alt="gray Refresh Control" src="https://github.com/user-attachments/assets/e5d088e8-b3f5-46b8-9284-9b452232ad10">
<br />
<br />
This PR is opened to fix that by applying `tintColor` and `progressViewOffset` props to `_refreshControl` in `RCTPullToRefreshViewComponentView.mm` class.
Fixes https://github.com/facebook/react-native/pull/46628
## Changelog:
[IOS][FIXED] - Fix applying of tintColor and progressViewOffset props for RefreshControl component with New Architecture enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/46628
Test Plan:
1. Run rn-tester app with New Architecture enabled on iOS
2. Open screen of RefreshControl component:
<img width="300" alt="Снимок экрана 2024-09-24 в 19 48 49" src="https://github.com/user-attachments/assets/94a2d02d-f3e3-4e18-a345-87c22d4a2620">
3. Open `/packages/rn-tester/js/examples/RefreshControl/RefreshControlExample.js` file and change properties `tintColor` and `progressViewOffset` of RefreshControl components on the line 85:
<img width="300" alt="Снимок экрана 2024-09-24 в 22 01 19" src="https://github.com/user-attachments/assets/425826a6-d34c-4316-8484-e65f125a8b28">
4. check that your changes applied:
<img width="300" alt="Снимок экрана 2024-09-24 в 19 54 46" src="https://github.com/user-attachments/assets/b97621f1-b553-48c9-bc81-e04a99a7e099">
Reviewed By: cortinico
Differential Revision: D63381050
Pulled By: cipolleschi
fbshipit-source-id: 4f3aed8bd7a1e42ce2a75aa19740fd8be1623c86
Summary:
On iPadOS, users can change the kind of keyboard displayed onscreen, going from normal keyboard, to split keyboard (one half on the left of the screen, one half on the right), or a floating keyboard that you can move around the screen.
When a non-normal kind of keyboard is used, `<KeyboardAvoidingView>` calculations are all wrong and, depending on the `behavior` prop, can make your screen completely hidden.
This PR attempts to detect that the keyboard is not the "normal displayed-at-bottom-of-screen" keyboard, and forces `enable={false}` if this happens.
The approach of comparing the keyboard width with the window width comes from this comment: https://github.com/facebook/react-native/issues/29473#issuecomment-696658937
A better fix might be to detect the kind of keyboard used, but this involves native code changes and I do not know iOS enough to do that. In addition, I have not found an easy way to do it using iOS APIs after a quick search.
I also chose to cache the window width as a class attribute. Maybe this is not needed as `Dimensions.get('window').width` is very fast and can be called on every keyboard event?
This fixes https://github.com/facebook/react-native/issues/44068 and https://github.com/facebook/react-native/issues/29473
## Changelog:
[IOS] [FIXED] - Fix `<KeyboardAvoidingView>` with floating keyboard on iPadOS
Pull Request resolved: https://github.com/facebook/react-native/pull/44859
Test Plan:
Tested using RNTester and the "Keyboard Avoiding View with different behaviors" example.
Before:
https://github.com/facebook/react-native/assets/42070/111598a3-286c-464d-8db8-73afb35cd7f9
After:
https://github.com/facebook/react-native/assets/42070/0b3bc94f-8b67-4f42-8a83-e11555080268
Reviewed By: cortinico
Differential Revision: D62844854
Pulled By: cipolleschi
fbshipit-source-id: 577444be50019572955a013969d78178914b5b8d
Summary:
A typo means TextLayoutManager will incorrectly measure text as if `LineBreaker.HYPHENATION_FREQUENCY_NORMAL` is set, instead of the correct default of `LineBreaker.HYPHENATION_FREQUENCY_NONE` which we use to display the `TextView`. This causes truncation if hyphenation would have caused text to be shorter than if not hyphenated. Fix the typo.
Changelog: [Android][Fixed] - Fix measuring text with incorrect hyphenationFrequency
Reviewed By: mellyeliu
Differential Revision: D63293027
fbshipit-source-id: baaf2ae2676548cf0815ae96e324af273be6f99e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46559
There is an edge case when we navigate away from a screen that contains a scroll view where one of the UISCrollViewDelegates does not implement the scrollViewDidEndDecelerating method.
This happens because the Macro used assumes that the event that we are forwarding is the actual method from where the macro is called. Which is not true when it comes to `didMoveToWindow`.
This change fixes that by explicitly expanding the macro in this scenario and passing the right selector.
## Changelog:
[iOS][Fixed] - Fixed a crash when navigating away from a screen that contains a scrollView
## Facebook
This should fix T201780472
Reviewed By: philIip
Differential Revision: D62935876
fbshipit-source-id: e29aadf201c8066b5d3b7b0ada21fa8d763e9af0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46560
The `init` command should still keep on working till 2024-12-31
This handles this scenario as currently `npx react-native@next init` is broken.
Changelog:
[Internal] [Changed] - Clarify init behavior for 0.76
Reviewed By: huntie, cipolleschi
Differential Revision: D62958747
fbshipit-source-id: ce3d974df55162720d59a7ece7fcb816e257185d
Summary:
Regarding the [issue](https://github.com/facebook/react-native/issues/44755) where the app sometimes crashes due to race condition when two reloads overlap in unfortunate way. This PR fixes it in some way by introducing throttling on reload command. For now I set it to 700ms as I was still able to reproduce it on 500-550ms for provided repro in the issue. The problem may still happen for bigger apps where reload may take more time to finish.
## 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] - throttle reload command
Pull Request resolved: https://github.com/facebook/react-native/pull/46416
Test Plan: I've tested on provided repro and a smaller app trying to brake it.
Reviewed By: huntie
Differential Revision: D62847076
Pulled By: cipolleschi
fbshipit-source-id: 6471f792d6b692e87e3e98a699443a88c6ef43cd
Summary:
Following the discussion on https://github.com/facebook/react-native/issues/46505, this PR aims to allow mixte type configuration (String and/or Array of String) during the post installation of pods.
## 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
-->
[IOS] [FIXED] - allow pods mixte type settings on post-install
Pull Request resolved: https://github.com/facebook/react-native/pull/46536
Test Plan: `packages/react-native/scripts/cocoapods/__tests__/utils-test.rb` test suits was updated to support array and works as expected
Reviewed By: shwanton
Differential Revision: D62870582
Pulled By: cipolleschi
fbshipit-source-id: c0ace6d9d20e6609ceae5aafd236d97fc9e86ddf
Summary:
In this PR https://github.com/facebook/react-native/issues/45560 the BUNDLE_COMMAND initialization was removed while it is still being used. Without it, building from Xcode throws unknown options error for Physical iOS devices.
I have just brought back the initialization from the PR before that, so the bundle phase is successful.
## Changelog:
[IOS][Fixed] - Add back the BUNDLE_COMMAND
Pull Request resolved: https://github.com/facebook/react-native/pull/46495
Test Plan: I have bundled release builds in Xcode. Everything seems to be fine.
Reviewed By: cortinico
Differential Revision: D62846877
Pulled By: cipolleschi
fbshipit-source-id: 3f07e8c0bc5acf98177582f1fee9a55ae77b31a1
Summary:
Solves this issue: https://github.com/facebook/react-native/issues/46276
## 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] [ADDED] - fire onMomentumScrollEnd when UIScrollView is removed from window
**Why the issue is happening?**
The `onMomentumScrollEnd` event is typically triggered by the `UIScrollView` delegate methods `scrollViewDidEndDecelerating` and `scrollViewDidEndScrollingAnimation`. However, if the scroll view is removed from the window while navigating away, these delegate methods are not called, resulting in the event not being dispatched.
This behaviour was particularly problematic in scenarios where a scroll view is in motion, and the user navigates away from the screen before the scrolling completes. In such cases, the `onMomentumScrollEnd` event would never fire, which further make scroll area un touchable or un responsive.
**What we changed?**
In the didMoveToWindow method, we added logic to handle the scenario where the UIScrollView is being removed from the window (i.e., when the component is unmounted or the user navigates away). Here’s a breakdown of the changes:
- **Added a Check for Scroll State:** We check if the UIScrollView was decelerating or had stopped tracking (_scrollView.isDecelerating || _scrollView.isTracking == NO).
- **Manually Triggered onMomentumScrollEnd:** If the scroll view was in motion and is being removed from the window, we manually trigger the `onMomentumScrollEnd` event to ensure that the final scroll state is captured.
**_I had fixed this issue on both Old and New arch._**
Pull Request resolved: https://github.com/facebook/react-native/pull/46277
Test Plan:
Attaching a video with working solution:
https://github.com/user-attachments/assets/1a1f3765-3f11-46c3-af18-330c88478db8
Reviewed By: andrewdacenko
Differential Revision: D62374798
Pulled By: cipolleschi
fbshipit-source-id: 014be8d313bab0257459dc4e53f5b0386a39d5e0
Summary:
This reverts commit 0cb97f0261.
Revert this commit that adds a `post install` script for a couple of reasons:
1. (EDIT: This turns out to be unrelated) The `postinstall` script causes `yarn install` to fail on React Native macOS, where we use Yarn 4. I'm not entirely sure why, but I probably won't debug it for the rest of the reasons.
2. `postinstall` scripts (at least inside Microsoft) are viewed as a security risk. Any package in your dependency tree can get compromised, add the phase, and run arbitrary code. This has happened in the past with React Native past if I recall correctly. As such, we disable `postinstall` scripts in many of our repos (including `rnx-kit` and `react-native-test-app`).
3. The issue this is trying to solve is to help newcomers avoid a stale cache when they switch branches in the React Native monorepo and only run `yarn install`. I think it would be sufficient to add some documentation somewhere that it is expected one runs `yarn && yarn build` to use this repo locally? That's a fairly common practice in monorepos, at least ones inside Microsoft.
## Changelog:
[INTERNAL] [SECURITY] - Remove post install script phase in the React Native monorepo
Pull Request resolved: https://github.com/facebook/react-native/pull/46420
Test Plan: CI should pass
Reviewed By: christophpurrer, robhogan, cortinico, rshest
Differential Revision: D62755022
Pulled By: huntie
fbshipit-source-id: bf94ed33e3e451ea337ef7a6984f7ba964d0b212
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46498
Looks like this is still necessary because we still run into this error when using the Components tab when using React DevTools:
> TypeError: cyclical structure in JSON object
This effectively reverts https://github.com/facebook/react-native/pull/46382.
Changelog:
[General][Changed] - AnimatedNode (and its subclasses) once again implement `toJSON()`.
Reviewed By: javache
Differential Revision: D62690380
fbshipit-source-id: d5b7c1d156b49838abefe48a7d7b61471cc3488a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46478
These are all supported in the new arch (default as of 0.76), across all platforms. but were previously hidden from types, and undocumented.
I will make a pick request for this change, and we should then add these to documentation.
Changelog:
[General][Added] - Unhide new arch layout props
Reviewed By: cortinico
Differential Revision: D62616897
fbshipit-source-id: f6c2e71785284e667824a76918ccf2724adc4e98
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46402
JS code for importing SafeAreaView is causing error in windows due to import being used.
Fix it by using conditional require instead
Changelog:
[Internal] - Fixed mis-used import of core only SafeAreaView in JS
Reviewed By: fkgozali
Differential Revision: D62392588
fbshipit-source-id: 65c4728ff73b43cc54543ec2d141a88fce1275ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46483
Original commit changeset: 631d741bd2ec
This is breaking the RedBox on React Native 0.76 on Android when not connected to Metro.
Original Phabricator Diff: D62213722
Changelog:
[Internal] [Changed] - Back out "[react-native] Remove some Tasks overhead"
Reviewed By: cipolleschi
Differential Revision: D62644614
fbshipit-source-id: a092614da78bef65546c2539a3ebc9bff5e807b2
Summary:
This PR fixes an issue with PrivacyInfo files.
When generating a new project for using the latest RC 0.76.0.rc0 I got two privacy manifests references in Xcode.
This is because `PrivacyManifestUtils` look for build phase reference:
```ruby
reference_exists = target.resources_build_phase.files_references.any? { |file_ref| file_ref&.path&.end_with? "xcprivacy" }
```
Which doesn't exist for the generated template.
Here is how Xcode file tree looks like after installing pods:

## Changelog:
[IOS] [FIXED] - don't reference PrivacyInfo.xcprivacy twice for new projects
Pull Request resolved: https://github.com/facebook/react-native/pull/46457
Test Plan:
1. Generate a new project
2. Execute pod install
3. Check if only one PrivacyInfo file exists
Reviewed By: cortinico
Differential Revision: D62580116
Pulled By: cipolleschi
fbshipit-source-id: 1224a41307ae6c9b862832f145baf0edc92476d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46454
The SVC Validator have no idea on how to process a simple NSArray *.
With this change, we are creating two named types for the NSArray:
* BoxShadowArray
* FilterArray
To create unique types that we can reference in JS.
We are then enhancing the `getProcessor` function to return the proper processor when those types are found in the NativeViewConfig
## Changelog:
[iOS][Fixed] - Fixed warnings when validating SVC
## Facebook:
This change is OTA safe: even when we ship the JS before the native code, the new cases in the switch will be never hit, similarly to the situation we have right now.
As soon as the native code is shipped, the new cases will start get hit and the wrning will disappear
Reviewed By: NickGerleman
Differential Revision: D62574612
fbshipit-source-id: d173bf5534ee5e436f23a4bc6e2fb25e72a4b06d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46439
The SVC for some components on iOS got out of sync.
This was creating warnings in the React Native DevTools and it was affecting the release of 0.76.
With this change, I updated the manually written SVC so that we don't have warnings anymore.
We still have to fix the `boxShadow` and `filter`. This will happen in a later change.
## Changelog
[iOS][Fixed] - Solved SVC warnings for RNTester
Reviewed By: NickGerleman
Differential Revision: D62501704
fbshipit-source-id: 3c02f7615c3511a97eba73a2ddaa713d2e4e30f0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46406
As title
Second attempt at landing the new name. There were 2 issues previously which led us to revert.
1. **Error on workrooms tests.** This ended up not being caused by us but rather by D61896776. After renaming the error changed which might've caused the renaming to be blamed for the issue. It has since been resolved
2. **FB crash** FB was crashing when using drop-shadow after renaming. For some reason after renaming `filter` an invalid stylex property was making FB crash. We don't know why renaming uncovered the issue but the the code was using unsupported features on RN (`calc` & `stylex`) which then led to passing a raw unsupported value for `filter` and crashing on the `processFilter` function.
FB was fixed here D62407454 to prevent crashing after landing this diff
Changelog: [General] [Changed] - Add official `filter` CSSProperty.
Reviewed By: NickGerleman
Differential Revision: D62401985
fbshipit-source-id: 14422603c40b7ddf8300029165a85655354075c3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46404
As title
Second attempt to rename the prop. BoxShadow caused no issues after renaming but it was batched with `filter` which we reverted.
Changelog: [General] [Changed] - Add official `boxShadow` CSSProperty.
Reviewed By: NickGerleman, cyan33
Differential Revision: D62400814
fbshipit-source-id: ad721f6d11d614e987048e55556b05ff74a4747d
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
## Changelog
[Internal] - Remove dSYM path from Info.plist
Reviewed By: cortinico
Differential Revision: D62603425
fbshipit-source-id: 038ec3d6b056a3d6f5585c8125d0430f56f11bb9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46461
This bumps SoLoader to 0.12.1 inside React Native and cleans up the extra
`com.facebook.soloader.enabled` metadata which are not necessary anymore.
Changelog:
[Internal] [Changed] - Bump SoLoader to 0.12.1 and remove unnecessary extra manifest metadata
Reviewed By: cipolleschi
Differential Revision: D62581188
fbshipit-source-id: ff990c0af1f0f51070037fcb4c7c13fbe6bae234
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46459
After the SoLoader 0.12.0 bump I've noticed RNTester is instacrashing due to us not having enabled it
explicitely in the Manifest:
Changelog:
[Internal] [Changed] - Unblock RNTester instacrashing due to SoLoader not being enabled
Reviewed By: cipolleschi
Differential Revision: D62580751
fbshipit-source-id: 3b291e7f82daf1a6bd61bc9588c2d49a389801ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46422
Stubbing SoLoader comes with a couple of breaking changes (e.g. users in OSS are using `com.facebook.common.logging.FLog` which is exposed by Fresco).
In order to reduce those breaking changes, here I'm moving React Native to use SoLoader 0.12.0.
This new version comes with a constructor that accepts a MergedSoMapping implementation which we provide only for OSS apps.
Please note that the CI on this Diff will be red till SoLoader 0.12.0 releases.
Changelog:
[Internal] [Changed] - Do not stub SoLoader and use version 0.12.0
Reviewed By: cipolleschi
Differential Revision: D62447566
fbshipit-source-id: 6ff38799ed0c9f40cf3ab84be8a05979def63dc2
Summary:
This PR exposes `jsctooling` prefab that contains `facebook::jsc::makeJSCRuntime` used by Reanimated and other third-party libraries previously accessed via `libjscexecutor.so`.
Based on https://github.com/facebook/react-native/pull/46423.
## Changelog:
[Android] [Changed] - Expose jsctooling via prefab
Pull Request resolved: https://github.com/facebook/react-native/pull/46430
Test Plan: Tested on Reanimated paper-example app built from source on RN 0.76.0-rc.0 with JSC enabled
Reviewed By: cipolleschi
Differential Revision: D62492763
Pulled By: cortinico
fbshipit-source-id: 53b6c0d9bb88559c40b5b8796bf6a1513bd388d9
Summary:
This PR fixes the following error when building third-party libraries that `#include <react/fabric/Binding.h>` which includes `react/timing/primitives.h` which is not included in `reactnative` prefab.
```
FAILED: CMakeFiles/rnscreens.dir/src/main/cpp/NativeProxy.cpp.o
/Users/tomekzaw/Library/Android/sdk/ndk/26.1.10909125/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++ --target=aarch64-none-linux-android24 --sysroot=/Users/tomekzaw/Library/Android/sdk/ndk/26.1.10909125/toolchains/llvm/prebuilt/darwin-x86_64/sysroot -DFOLLY_NO_CONFIG=1 -Drnscreens_EXPORTS -I/Users/tomekzaw/RNOS/react-native-reanimated/node_modules/react-native-screens/android/../cpp -isystem /Users/tomekzaw/.gradle/caches/8.10.1/transforms/eb5443cef7868b6c3cc54bbf3f161a63/transformed/react-android-0.76.0-rc.0-debug/prefab/modules/jsi/include -isystem /Users/tomekzaw/.gradle/caches/8.10.1/transforms/eb5443cef7868b6c3cc54bbf3f161a63/transformed/react-android-0.76.0-rc.0-debug/prefab/modules/reactnative/include -isystem /Users/tomekzaw/.gradle/caches/8.10.1/transforms/b0878eb14f826ac5f04db98523604de2/transformed/fbjni-0.6.0/prefab/modules/fbjni/include -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fno-limit-debug-info -fPIC -std=c++20 -MD -MT CMakeFiles/rnscreens.dir/src/main/cpp/NativeProxy.cpp.o -MF CMakeFiles/rnscreens.dir/src/main/cpp/NativeProxy.cpp.o.d -o CMakeFiles/rnscreens.dir/src/main/cpp/NativeProxy.cpp.o -c /Users/tomekzaw/RNOS/react-native-reanimated/node_modules/react-native-screens/android/src/main/cpp/NativeProxy.cpp
In file included from /Users/tomekzaw/RNOS/react-native-reanimated/node_modules/react-native-screens/android/src/main/cpp/NativeProxy.cpp:2:
In file included from /Users/tomekzaw/.gradle/caches/8.10.1/transforms/eb5443cef7868b6c3cc54bbf3f161a63/transformed/react-android-0.76.0-rc.0-debug/prefab/modules/reactnative/include/react/fabric/Binding.h:17:
In file included from /Users/tomekzaw/.gradle/caches/8.10.1/transforms/eb5443cef7868b6c3cc54bbf3f161a63/transformed/react-android-0.76.0-rc.0-debug/prefab/modules/reactnative/include/react/jni/JRuntimeScheduler.h:11:
In file included from /Users/tomekzaw/.gradle/caches/8.10.1/transforms/eb5443cef7868b6c3cc54bbf3f161a63/transformed/react-android-0.76.0-rc.0-debug/prefab/modules/reactnative/include/react/renderer/runtimescheduler/RuntimeScheduler.h:11:
/Users/tomekzaw/.gradle/caches/8.10.1/transforms/eb5443cef7868b6c3cc54bbf3f161a63/transformed/react-android-0.76.0-rc.0-debug/prefab/modules/reactnative/include/react/performance/timeline/PerformanceEntryReporter.h:10:10: fatal error: 'react/timing/primitives.h' file not found
#include <react/timing/primitives.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
```
## Changelog:
[ANDROID] [FIXED] - Expose `react_timing` headers in `reactnative` prefab
Pull Request resolved: https://github.com/facebook/react-native/pull/46427
Test Plan: Tested on Reanimated fabric-example app with react-native-screens installed built from source on top of RN 0.76.0-rc.0 with new arch enabled
Reviewed By: cipolleschi
Differential Revision: D62492707
Pulled By: cortinico
fbshipit-source-id: 94ed7044457bea53660a6ca6d5342cf8ea20a8b4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46423
This is used by Reanimated as they were previously accessing `libhermes_executor.so`
Changelog:
[Android] [Changed] - Expose hermestooling via prefab
Reviewed By: cipolleschi
Differential Revision: D62447875
fbshipit-source-id: e863c56bc5a801ee7de8a4e5d45f95481d3497f8
Summary:
Hey.
The react-native gradle plugin didn't properly filter out [Pure](https://github.com/react-native-community/cli/pull/2387) C++ TurboModules for autolinking, which caused build failures as a non-existing gradle dependency would be emitted.
This makes Pure C++ TurboModules work again for Android.
## 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
-->
[ANDROID][FIXED] Fix autolinking issues for Pure C++ TurboModules
Pull Request resolved: https://github.com/facebook/react-native/pull/46381
Test Plan:
https://github.com/hsjoberg/rn75autolinkregression
Try running this repro project to observe the error:
```
1: Task failed with an exception.
-----------
* Where:
Build file '/Users/coco/Projects/Blixt/rn75autolinkregression/example/android/app/build.gradle' line: 54
* What went wrong:
A problem occurred evaluating project ':app'.
> Project with path ':react-native-cxx-turbomodule' could not be found in project ':app'.
```
Simply add the 1-line code from this PR to make the build succeed.
Cheers.
Reviewed By: cipolleschi
Differential Revision: D62377757
Pulled By: cortinico
fbshipit-source-id: 9e3fa3777b4e6e4d3f2eb0f996ac0ac7676eedbe
"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.",
@@ -3314,6 +3314,15 @@ public final class com/facebook/react/modules/core/TimingModule : com/facebook/f
public final class com/facebook/react/modules/core/TimingModule$Companion {
}
public final class com/facebook/react/modules/debug/DevMenuModule : com/facebook/fbreact/specs/NativeDevMenuSpec {
public fun <init> (Lcom/facebook/react/bridge/ReactApplicationContext;Lcom/facebook/react/devsupport/interfaces/DevSupportManager;)V
public fun debugRemotely (Z)V
public fun reload ()V
public fun setHotLoadingEnabled (Z)V
public fun setProfilingEnabled (Z)V
public fun show ()V
}
public final class com/facebook/react/modules/debug/DevSettingsModule : com/facebook/fbreact/specs/NativeDevSettingsSpec {
public fun <init> (Lcom/facebook/react/bridge/ReactApplicationContext;Lcom/facebook/react/devsupport/interfaces/DevSupportManager;)V
public fun addListener (Ljava/lang/String;)V
@@ -4047,6 +4056,33 @@ public class com/facebook/react/shell/MainReactPackage$$ReactModuleInfoProvider
public fun getReactModuleInfos ()Ljava/util/Map;
}
public final class com/facebook/react/soloader/OpenSourceMergedSoMapping : com/facebook/soloader/ExternalSoMapping {
public static final field INSTANCE Lcom/facebook/react/soloader/OpenSourceMergedSoMapping;
public fun invokeJniOnload (Ljava/lang/String;)V
public final fun libfabricjni_so ()I
public final fun libhermes_executor_so ()I
public final fun libhermesinstancejni_so ()I
public final fun libhermestooling_so ()I
public final fun libjscexecutor_so ()I
public final fun libjscinstance_so ()I
public final fun libjscruntime_so ()I
public final fun libjsctooling_so ()I
public final fun libjsijniprofiler_so ()I
public final fun libjsinspector_so ()I
public final fun libmapbufferjni_so ()I
public final fun libreact_devsupportjni_so ()I
public final fun libreact_featureflagsjni_so ()I
public final fun libreact_newarchdefaults_so ()I
public final fun libreactnative_so ()I
public final fun libreactnativeblob_so ()I
public final fun libreactnativejni_so ()I
public final fun librninstance_so ()I
public final fun libturbomodulejsijni_so ()I
public final fun libuimanagerjni_so ()I
public final fun libyoga_so ()I
public fun mapLibName (Ljava/lang/String;)Ljava/lang/String;
}
public final class com/facebook/react/touch/JSResponderHandler : com/facebook/react/touch/OnInterceptTouchEventListener {
public fun <init> ()V
public final fun clearJSResponder ()V
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.