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
Summary:
Bumps the CLI to the next version
## Changelog:
[General][Changed] - Bump cli dependencies to 15.0.0-alpha.2
Pull Request resolved: https://github.com/facebook/react-native/pull/46394
Test Plan: CI
Reviewed By: huntie
Differential Revision: D62375405
Pulled By: cipolleschi
fbshipit-source-id: fec99216bc7ad6decfd83840091d807f603184da
Summary:
This PR exposes the `newArchEnabled` flag and deprecates all of the separate methods to enable new architecture.
As discussed with cipolleschi here: https://github.com/react-native-community/template/pull/45#discussion_r1732522705
## Changelog:
[IOS] [DEPRECATED] - Deprecate turboModuleEnabled, fabricEnabled, bridgelessEnabled
[IOS] [ADDED] - Add newArchEnabled method to RCTAppDelegate
Pull Request resolved: https://github.com/facebook/react-native/pull/46228
Test Plan: Test if switching newArchEnabled flag from AppDelegate works.
Reviewed By: cortinico
Differential Revision: D61849385
Pulled By: cipolleschi
fbshipit-source-id: 8acf718386882679f00d2d5000b4432a523b34ac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46391
**Issue:**
RedBox displays early error before JS Error handling is properly setup.
On Android 15, targetSdk 35 (forced edge-to-edge), dialog overlaps with system bars making it difficult to use.
**Solution**
Add inset based margins so content does not overlap with system bars.
Changelog:
[Android][Fixed] - RedBox content overlapping with system bars on Android 15 forced edge-to-edge
Reviewed By: fkgozali
Differential Revision: D62362105
fbshipit-source-id: 57f60222914d407ebdcfd0359dbdf3ac36bde8f5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46390
As React Native's minSdkVersion is not 24, clean up version checks and code that is using deprecated version from OSS
Changelog:
[Internal] - code cleanup for minSdkVersion 24
Reviewed By: philIip
Differential Revision: D62362059
fbshipit-source-id: a851d0908d4175269524f41955acca5f2da69cad
Summary:
When creating Hermes in CI, we build it for MacOS and Mac Catalyst as well.
The slices for these platforms requires symlinks to work properly.
The upload artifacts action on github, when applied to folders, follows the symlinks and copies the destination folder. The result is that Hermes for macOS and Catalyst does not work as expected.
This should fix https://github.com/facebook/react-native/issues/46213.
## Changelog:
[Internal] - Build Hermes in CI properly
Pull Request resolved: https://github.com/facebook/react-native/pull/46387
Test Plan: Tested already in 0.75
Reviewed By: robhogan
Differential Revision: D62355050
Pulled By: cipolleschi
fbshipit-source-id: 7abb85c8a2a88f13e06a49c6cb0caccbdad4551a
Summary:
In a react native project where USE_FRAMEWORKS is not nil, every time when running `pod install`, duplicate lines are added to `HEADER_SEARCH_PATHS` section of `project.pbxproj`:
```
" ${PODS_CONFIGURATION_BUILD_DIR}/ReactCommon/ReactCommon.framework/Headers",
" ${PODS_CONFIGURATION_BUILD_DIR}/React-Fabric/React_Fabric.framework/Headers/react/renderer/components/view/platform/cxx",
" ${PODS_CONFIGURATION_BUILD_DIR}/React-graphics/React_graphics.framework/Headers",
" ${PODS_CONFIGURATION_BUILD_DIR}/ReactCommon/ReactCommon.framework/Headers",
" ${PODS_CONFIGURATION_BUILD_DIR}/React-Fabric/React_Fabric.framework/Headers/react/renderer/components/view/platform/cxx",
" ${PODS_CONFIGURATION_BUILD_DIR}/React-graphics/React_graphics.framework/Headers",
" ${PODS_CONFIGURATION_BUILD_DIR}/ReactCommon/ReactCommon.framework/Headers",
" ${PODS_CONFIGURATION_BUILD_DIR}/React-Fabric/React_Fabric.framework/Headers/react/renderer/components/view/platform/cxx",
" ${PODS_CONFIGURATION_BUILD_DIR}/React-graphics/React_graphics.framework/Headers",
```
Note: a popular library that needs `use_frameworks` is react-native-firebase.
See https://rnfirebase.io/#altering-cocoapods-to-use-frameworks
## Analyse
- `react_native_post_install` calls `ReactNativePodsUtils.update_search_paths(installer)`
- when `ENV['USE_FRAMEWORKS'] != nil` then `update_search_paths` calls `add_search_path_if_not_included`
- `add_search_path_if_not_included` checks if `"#{new_search_path}"` is already there
- if not found it adds `" #{new_search_path}"` _with an extra space_
- next time, it can't find `"#{new_search_path}"` because of the extra space, and adds `" #{new_search_path}"` again
## Changelog:
[IOS] [FIXED] - react_native_post_install script no longer adds duplicate entries to HEADER_SEARCH_PATHS
Pull Request resolved: https://github.com/facebook/react-native/pull/46262
Test Plan:
- create a react native project
- add `use_frameworks! :linkage => :static` to `ios/Podfile` (just before `use_react_native`)
- run `pod install`
- assert no duplicate lines are added to HEADER_SEARCH_PATHS of file `project.pbxproj`
Reviewed By: cipolleschi
Differential Revision: D61982680
Pulled By: shwanton
fbshipit-source-id: 61b566893c551d0813edd6eec2f8352c041c748f
Summary:
This PR bumps Socket Rocket to 0.7.1, this release brings some new improvements and visionOS support. I've also moved the version to a constant.
## Changelog:
[INTERNAL] [CHANGED] - Bump SocketRocket to 0.7.1
Pull Request resolved: https://github.com/facebook/react-native/pull/46300
Test Plan: CI Green
Reviewed By: cortinico, cipolleschi
Differential Revision: D62294833
Pulled By: blakef
fbshipit-source-id: 0e45c7de041710fb1f500b0ac23898b68a8a8936
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46359
Remove unneeded code around size calculation and old arch support
- updateState was getting called unnecessarily in multiple places --> only call from onSizeChanged()
- this is a reliable source for getting the content size area of the dialog used for Modal
- remove code checking duplicated update
- Old architecture cleanup
- Remove Java implementation of ShadowNode
- we already have logic to set the node size via UIManagerModule::updateNodeSize(). This code is now group together in updateState() for both new and old architecture
This fixes issues with resulting from wrong size calculation:
- having gaps at bottom when we set `statusBarTranslucent` to `true`
- Modal cut off at bottom on Android 15 (drawn under bottom nav bar)
Changelog:
[Android][Fixed] - Modal statusBarTranslucent bug, Modal at bottom being cut off in Android 15 (without forced edge-to-edge)
[Android][Deprecation] - Deprecating ModalHostShadowNode and ModalHostHelper classes
Reviewed By: mdvacca
Differential Revision: D62286026
fbshipit-source-id: 03b64a7783c12bebd1457c86a9a2657adc882c79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46326
- renaming variabled to make intent more clear
- `dialog` -> `dialogWindow` to distinguish with `activity.window`
- `hostView` -> `dialogRootViewGroup` as name was confusing.
- `ReactModalHostView` creates and manages `DialogRootViewGroup` but it used as contentView for the Dialog.
- bug fixes
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D62177564
fbshipit-source-id: f81b167c1a234c02617ec2a3d63979628e01063b
Summary:
Reverts the PR https://github.com/facebook/react-native/pull/45967 from philIip to bring back the `registerCxxModuleToGlobalModuleMap(..)` function, which I use in Nitro Modules and MMKV.
Ontop of that, this also removes the "experimental" `RCT_EXPORT_CXX_MODULE_EXPERIMENTAL` macro, which I think was the original intent of this PR as this macro is a bit unsafe.
I also added some small docs to `registerCxxModuleToGlobalModuleMap` while I'm at it.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[GENERAL] [CHANGED] - Bring back CxxTurboModule autolinking function, but remove `RCT_EXPORT_CXX_MODULE_EXPERIMENTAL` macro
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/46360
Test Plan: Build Nitro Modules. Worked for me! :)
Reviewed By: realsoelynn
Differential Revision: D62310637
Pulled By: philIip
fbshipit-source-id: 2caa2b8ea094dda5e13c81431a9a645cbcf8f807
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46370
Add a function to write the current trace contents to a file. To be used by the upcoming Perfetto data source while we wait for devtools to work in a profiling build.
Reviewed By: rubennorte
Differential Revision: D62262985
fbshipit-source-id: 04789f5312721434c773e51b3da333498bf0e786
Summary:
Currently, `AnimatedNode.prototype.getListeners` creates an array with `Object.keys()` to determine the number of listeners.
This is a relatively hot code path for animation-intensive user interfaces. Although `Object.keys()` is fast, every unnecessary memory allocation is an unnecessary opportunity to create garbage that requires collection.
Using an object as a dictionary performs worst than using a `Map` anyway, so this switches `AnimatedNode` to use a `Map`.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D62267352
fbshipit-source-id: 8629861a64109a3a711c0f66a345029d0bfcd440
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46312
Refactors `NativeAnimatedHelper` to make it easier to read, reduce runtime overhead, and no longer export `queueOperation` (which was not useable externally anyway).
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D62139993
fbshipit-source-id: ce75e530887da6290f26060ecfe36049cf81879a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46366
This diff adds a Systrace section to the `SurfaceMountingManager::createViewUnsafe` method.
This will allow us to see more detail within the `MountItemDispatcher::mountViews preMountItems` that was previously almost blank.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D62247235
fbshipit-source-id: 3765c15e3e24e3231a30294938c725e82d100542
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46348
`continueWithTask` skips an extra invocation layer that `onSuccess` adds. Switch to Task<Void> as the task can already represent failure or success without needing a boolean.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D62213722
fbshipit-source-id: 631d741bd2ec4917eab69a20978ab2ace737c459
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46340
**Issue:**
InspectorPanel is hidden behind 3 button nav bar on Android 15 forced edge-to-edge
**Solution:**
Apply SafeAreaView to avoid overlap with system bars
(CAUTION: SafeAreaView here is for internal RN Core usage only and should not be used elsewhere)
Changelog:
[Internal]
Reviewed By: cortinico, mdvacca
Differential Revision: D62225374
fbshipit-source-id: e762288386d4f1d210bd26b8f28e73c652c7ba4e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46341
Issue: LogBox Notification (or toast) is partly hidden behind 3 button nav bar on Android 15 targetSdk 35 build
Solution: surround with SafeAreaView to avoid overlap with system bars
(CAUTION: SafeAreaView here is for internal RN Core usage only and should not be used elsewhere)
Changelog:
[Internal]
Reviewed By: cortinico, mdvacca
Differential Revision: D62224584
fbshipit-source-id: 0662b1be9822bf51dadec2dd4879c915a47dfc65
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46368
This bumps AGP to the latest stable.
Release notes are here https://developer.android.com/build/releases/gradle-plugin
No relevant changes for React Native, other than the requirement on minimum Gradle version.
Changelog:
[Android] [Changed] - Bump AGP to 8.6.0
Reviewed By: tdn120
Differential Revision: D62296897
fbshipit-source-id: c34a18ab15dbacd6e5d69003b9e192d7f76d9f8f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46347
Calculate a frame deadline, and compare the current time against that.
This will also allow us to make frame timing more dynamic in the future, based on the display's frame rate.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D62213710
fbshipit-source-id: 1c7fc4b67d08c1eda4f3b9612a4506b33c44f626
Summary:
This diff cleans up the `use_debounced_effects_for_animated` experiment. It is not shipped because it breaks semantics of Animated.
It also removes the implementation of now unused `useDebouncedEffect` hook.
bypass-github-export-checks
Facebook
Details here https://fb.workplace.com/groups/3611662615830335/permalink/3666119690384627/
Changelog: [Internal]
Reviewed By: bvanderhoof
Differential Revision: D62188361
fbshipit-source-id: ce215cf7dd57e41e02c33760e91808d774bbd919
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46338
**Issue:**
With forced edge-to-edge on Android 15, LogBox bottom tab bar is hidden behind 3 button nav bar and is unusable.
**Solution:**
LogBox is using Android Dialog so update it to set margins based on inset values. With this change we can get rid of android header logic from JS.
Changelog:
[Android][Changed] - Modify LogBox to be usable on Android 15
Reviewed By: mdvacca
Differential Revision: D62224124
fbshipit-source-id: 4721753bf340bd813bcd560052c52b63fa58ad4b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46354
**Issue:**
With forced edge-to-edge on Android 15, RNTester title at top overlaps with the status bar and bottom tab bar overlaps with bottom nav bar
**Solution:**
Add margins based on inset values to the ReactRootView which is the contentView for RNTesterActivity which acts as global padding within RNTester
Changelog:
[Android][Changed] - Adding padding for RNTester on Android 15 forced edge-to-edge
Reviewed By: mdvacca
Differential Revision: D62247910
fbshipit-source-id: 7b35d0c2016b6897b5de436a4245c9e910559541
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46346
Noticed that we could sometimes have multiple instances of DispatchUIFrameCallback in a single frame, which would cause us to execute more view preallocations or other work scheduled by Fabric. Root cause for this is on the new architecture, onHostResume seems to be invoked multiple times.
Make this code more resilient by explicitly tracking the state of the frame callback and avoiding multiple subscriptions. Longer-term we should consider having ReactChoreographer support repeating FrameCallbacks, since most of them are.
Changelog: [Android][Fixed] Fixed multiple Fabric dispatch callbacks being executed in a single Android frame
Reviewed By: sammy-SC
Differential Revision: D62213721
fbshipit-source-id: ac6fa5483ea38d9a15824af233fd23f1f6f3c891
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46295
X-link: https://github.com/facebook/metro/pull/1343
Updated all **babel** packages in all `package.json` across the repo and ran `npx yarn-deduplicate yarn.lock --scopes babel`. Afterwards, fixed the following issues appearing as a result of that (squashed the following initially separate diffs to make this packages update work atomically):
### (D61336392) updated jest snapshot tests failing
### (D61336393) updated babel types and corrected typings accordingly
The latest babel 7 introduces the following features we need to adjust our types to:
* `JSXNamespacedName` is removed from valid `CallExpression` args ([PR](https://github.com/babel/babel/pull/16421))
* `JSXNamespacedName` is used for namespaced XML properties in things like `<div namespace:name="value">`, but `fn(namespace:name)` doesn't make any sense.
* Dynamic imports are enabled behind a new flag `createImportExpressions` ([PR](https://github.com/babel/babel/pull/15682)), introducing calls such as `import(foo, options)`. These complicate the expected values passed to `import` to be more than just strings.
* Since these are behind a flag that is not expected to be enabled, we can throw an error for now and whoever uses it can add a support to it if needed later.
### Added a new metro ENV ignore
`BROWSERSLIST_ROOT_PATH` is set to `""` explicitly in `xplat/js/BUCK`
and then ignored in
`js/tools/metro-buck-transform-worker/src/EnvVarAllowList.js`
Reviewed By: robhogan
Differential Revision: D61543660
fbshipit-source-id: abbcab72642cf6dc03eed5142eb78dbcc7f63a86
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46345
Deriving transforms can be expensive on Android. When using NativeAnimated with transforms, especially with an EventBasedDriver, we may update the transform every frame, even if it's unchanged. Ideally, we'd fix this in Animated, and diff the previous and next values, but this closes the gap somewhat in the short-term.
Both JavaOnlyArray and ReadableNativeArray implement equals, but will not compare equality correctly with each other. That's not an issue, as it just means we'll redo the transform once more than necessary.
Changelog: [Android][Fixed] Optimize BaseViewManager#setTransform to ignore duplicate values
Reviewed By: NickGerleman
Differential Revision: D62213726
fbshipit-source-id: 5df026030c66e31eb6a5fe6353de3706b5b7b799
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46333
This pull request introduces enhancements to the view controller presentation logic in React Native, allowing for multiple sheets to be presented on top of each other. The current implementation restricts the presentation to a single view at a time, which limits the flexibility needed in complex applications.
The proposed changes modify the presentation behavior to always utilize the top-most view controller for presentations. This adjustment ensures that multiple sheets can be managed more effectively, without disrupting the existing application flow.
Key changes include:
Modification of the presentation logic to reference the top-most view controller.
Utilization of a recursive method to determine the top-most controller.
The changes have been thoroughly tested with both old and new interfaces and have shown to work seamlessly across different scenarios
Changelog: [Internal] Allow multiple sheets to be presented on top of each other
Reviewed By: jessebwr
Differential Revision: D62202475
fbshipit-source-id: daa0cf95edb23ea52a26441337f9a16f5475b211
Summary:
## Context
The error message in folly dynamic has been updated in D62136190. Updating related tests to reflect the change.
## Diff
Only test code is changed. No business logic change.
## Changelog:
[Internal] [Fixed] - Fix broken unit test due to folly error message change
Pull Request resolved: https://github.com/facebook/react-native/pull/46329
```
Shows details about the selected run from the run history
Run result
java.lang.AssertionError: Test failure
Test Case RecoverableError
* Running RecoverableError.RunRethrowingAsRecoverableRecoverTest
* Running RecoverableError.RunRethrowingAsRecoverableFallthroughTest
2/2 tests passed.
Test Case JsArgumentHelpersTest
* Running JsArgumentHelpersTest.args
***** Failure in xplat/js/react-native-github/packages/react-native/ReactCommon/cxxreact/tests/jsarg_helpers.cpp:108
Expected equality of these values:
ex.what()
Which is: "Error converting javascript arg 4 to C++: TypeError: expected dynamic type 'int/double/bool/string', but had type 'array'"
std::string("Error converting javascript arg 4 to C++: " "TypeError: expected dynamic type `int/double/bool/string', but had type `array'")
Which is: "Error converting javascript arg 4 to C++: TypeError: expected dynamic type `int/double/bool/string', but had type `array'"
0/1 tests passed.
Test Case JSBigFileString
```
Reviewed By: yfeldblum
Differential Revision: D62184078
fbshipit-source-id: 6ae0a33f58e0e10f14166084b80a997e59a008ec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46318
Configures the Metro by default to use the Hermes parser so that React Native can fully leverage all modern Flow language syntax.
NOTE: This does not affect `*.ts` and `*.tsx` files which will continue to use Babel. Metro has logic to enforce this regardless of the transform options.
Changelog:
[General][Changed] - Changed Metro default config to use Hermes parser, enabling the use of advanced Flow syntax in React Native.
Reviewed By: robhogan
Differential Revision: D62161923
fbshipit-source-id: 0f4c069d429517be16abcc6a2187cd23c6bd52d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46324
For listener sets that change infrequently, `CopyOnWriteArrayList` is a better trade-off compared to copying the list to iterate on it, especially in perf-sensitive paths like scrolling. Using `WeakReference` is also significantly simpler than `Collections.newSetFromMap(WeakHashMap`.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D62178024
fbshipit-source-id: bfc4f7389683b15be673dd7731094d52199d1c66
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46311
A straightforward move of `NativeAnimatedHelper` into the private directory, so that it does not impact our Public API.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D62142349
fbshipit-source-id: c93979e26e290d13e2a19fbe40d8f460ebea15fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46316
This pull request introduces enhancements to the view controller presentation logic in React Native, allowing for multiple sheets to be presented on top of each other. The current implementation restricts the presentation to a single view at a time, which limits the flexibility needed in complex applications.
The proposed changes modify the presentation behavior to always utilize the top-most view controller for presentations. This adjustment ensures that multiple sheets can be managed more effectively, without disrupting the existing application flow.
Key changes include:
Modification of the presentation logic to reference the top-most view controller.
Utilization of a recursive method to determine the top-most controller.
The changes have been thoroughly tested with both old and new interfaces and have shown to work seamlessly across different scenarios
Changelog: [Internal] Allow multiple sheets to be presented on top of each other
Reviewed By: cipolleschi
Differential Revision: D62143463
fbshipit-source-id: 53667cf1a75e4514156780574bf604aee6b3fefc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46287
Changes `Animated` to avoid validating certain values in production builds to improve performance.
In order to maintain consistent behavior between development and production builds (so that we reduce the likelihood of bugs that only appear in one of the environments), this also changes the validation errors to use `console.error` instead of error throwing.
Changelog:
[General][Changed] - Changed `Animated` props validation to soft errors instead of thrown errors
Reviewed By: sammy-SC
Differential Revision: D62055674
fbshipit-source-id: 8e5732d00ab06e14ba8562f5190ce79ca240e374
Summary:
The following fixes were needed to restore a clean build of React Native Windows downstream.
- LayoutableShadowNode.cpp: Value must be cast to a float to avoid type conversion error.
- ValueUnit.h: Must add a default return statement. Switch statement alone produces compiler error that function may end with no return value.
## Changelog:
[GENERAL] [FIXED] - Upstream fixes for build errors in React Native Windows
Pull Request resolved: https://github.com/facebook/react-native/pull/46315
Test Plan: React Native Windows CI runs clean.
Reviewed By: javache, alanleedev
Differential Revision: D62149228
Pulled By: realsoelynn
fbshipit-source-id: 0d85455a22fbc0066076a50adee6b2d4409cd628
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46314
In Bridgeless's version of the Hermes JVM init path, we defaulted an internal GC option to allocate memory in Hermes' OldGen, and revert that behaviour once an internal API was called which marked the app as loaded.
This is an unsuitable default behaviour, since we can't rely on that internal API to be called on every launch. We're also moving to implicit performance instrumentation, which makes it harder to reliably call this API at the right time.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D61937427
fbshipit-source-id: 95e43fc093b56aee6362f43b6b0832d1f439fb3f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46249
Add internal only version of SafeAreaView.
This should be only used within RN Core or RNTester as there are a few places where this is needed and cannot have dependency on 3rd party
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D61896413
fbshipit-source-id: 03fc263a9341f9b93b696d88a77a6501cd490177
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46302
Changelog:
[General][Fixed] - Removed noisy ENOENT error message upon launching the debugger
As described in T200199544, Metro terminal in open-source would show an error message for the missing embedder script.
In this diff, we add a response of an empty file to open-source (no-op)
Reviewed By: hoxyq
Differential Revision: D62103015
fbshipit-source-id: 219bc398b7786527db00528cca175adc13a527a0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46282
We intended to enable Fusebox on `main` since https://github.com/facebook/react-native/pull/45469 — this worked when building under Buck, however was not working for builds under Xcode/Android Studio. This is because the `HERMES_ENABLE_DEBUGGER` preprocessor flag is not equivalently defined in these build configurations.
This diff genericises these checks to `!defined(NDEBUG)` (i.e. *any debug build*), meaning we are correctly able to evaluate the `ReactNativeFeatureFlags::fuseboxEnabledDebug()` setting.
Changelog: [Internal]
NOTE: `NDEBUG` should be the as-generic-as-possible choice to select a debug build in both OSS and fbsource. Having `HERMES_ENABLE_DEBUGGER` set remains significant (AFAIK) **within the Hermes codebase** (there are no other references in `jsinspector-modern`). Evaluation of whether the lack of this flag works in OSS continues in T200241280.
Reviewed By: hoxyq
Differential Revision: D61966685
fbshipit-source-id: d30950172420a0afd6c137dbf014794f3353bb7a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46271
Improves the error thrown when an invalid value is supplied to `processFilter`. Without this, the error thrown would look something like:
> TypeError: … is not iterable
Changelog:
[General][Changed] - Improved error message for invalid filter values
Reviewed By: jorge-cab
Differential Revision: D62011191
fbshipit-source-id: 5594eeaf2b9174af14cc9e4daa275ae72974e597
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46281
In CSS newlines are considered equal to whitespaces which is why when receiving strings from RSD we could get \n characters which we were not handling
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D62034706
fbshipit-source-id: df2342b89156a131fecd0b0babeb478a6962b108
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46251
The diff D21124739 introduced this as a workaround for some faulty logic we used to have.
It seems like we no longer need it and it was actually causing issues with small border radii. Its barely noticeable but Outline looks weird in some cases if we leave it as is
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D61938725
fbshipit-source-id: cf7ee7417e1085d01e2e307e780ff5d1db499e69
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46273
The implementation of `AnimatedObject` should recurse through its structure and consistently treat `ReactElement` objects as opaque.
It wasn't consistent. This makes it consistent.
Changelog:
[General][Fixed] - Fixed undefined behavior in certain scenarios when `ReactElement` objects are supplied to Animated components
Reviewed By: javache
Differential Revision: D62012006
fbshipit-source-id: e6c3ac472945af8070735f1df856ff88b30a5624
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46264
React-native was not in sync with metro changes that RN relies on
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D61982240
fbshipit-source-id: 63b1f53174ab0ec663a537569a032c62c431eb83
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46191
Borders should not have to deal with clipping logic, that is fairly independent.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D61418470
fbshipit-source-id: 762dbf30d50b5ce9b2b73720e58625447d8bf00e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46190
Right now the background color is tightly coupled with border drawing. For starters, I find this a bit confusing as one would not assume they are very closely related. But this also causes a bug around not being able to properly clip to the padding box, because if we did this we would clip the background color and transparent borders would look wrong.
This would also block a fix related to how borders display with clipped content that is coming in the later diffs. If we decide to use the border image, then we cannot properly display things like images since they would be on top of this image (otherwise background color shows through).
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D61248625
fbshipit-source-id: ad398bbcfb69edc7d61362920773b51abea81d08
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46189
A lot of the style decorators we have (filters, box shadows, borders, etc) use a separate sub-CALayer to accomplish what they want. This becomes an issue if we are clipping the content to the bounds and if these decorators extend beyond the bounds of the view as they are typically unaffected by this clipping. The main things here are `box-shadow` and `outline`. However, this implementation will let us fix some issues w.r.t content rendering under borders. See later diffs for that.
To fix this, if needed, we insert a `_containerView` to contain all of our subviews, and actually apply the clipping to. If this exists, our UIView will only have one subview, this one. But it may have multiple sublayers.
NOTE: This diff does not actually redirect the clipping. It just inserts the subview to test if this breaks anything in and of itself.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D61414649
fbshipit-source-id: ddc2bfa47199909274c44da96a16e008290f9d2b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46270
Changelog: [internal]
When analyzing traces, I noticed that we were using the choreographer to batch events in the native layer on Android. This approach isn't very efficient for 2 reasons:
1. The choreographer runs in specific intervals and there could be some delay between receiving the events and dispatching them from the choreographer.
2. A slow mount operation in the choreographer after receiving the event would completely block the dispatch for the whole duration of the operation. This could take as long as 100s of ms, so it can be very significant.
This is especially relevant with layout events, which are dispatched using the same mechanism as input events. In this case, there are instances where we delay rendering in JS because we're doing an expensive mount in the UI thread.
It makes sense to batch events in native so we don't do unnecessary work in JS to process them, but there's a better mechanism to do this. Instead of posting a frame callback in the choreographer, we can batch events using a new task in an Android handler running on the UI thread. This would run immediately after the job where the events are dispatched, after all the events are dispatched.
This implements that mechanism behind a feature flag.
Reviewed By: sammy-SC
Differential Revision: D62004018
fbshipit-source-id: d8b78a75cf05d0d8c9dd867a82a776f8d293a683
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46269
Changelog: [internal]
I'm planning some changes to this class and it was kinda hard for me to understand what some of these methods were meant to do. Doing a small refactor to rename them with more meaningful names.
Reviewed By: sammy-SC
Differential Revision: D62004020
fbshipit-source-id: 1e28e7e80f12a3a56ff16ace8794887b2f46495c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46268
Changelog: [internal]
`mReactEventEmitter` is final and initialized with a non-null value in the constructor, so this check is redundant.
Reviewed By: sammy-SC
Differential Revision: D62004021
fbshipit-source-id: bb8719c286cd04005370f2cdef89928c0d01007a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46267
We can propagate opacity, already part of AttributedString, to alpha channel of paint used to draw text and background on canvas.
This does not support propagating to views, and contrary to the iOS example added which originated with legacy arch, does not correctly support nesting opacity. This is a limitation of new arch more generally, where an AttributedString fragment only contains inner-most opacity.
Bg and foreground are drawn separately with alpha as well, instead of rendering overlapping content offscreen to properly apply it (this is an issue on RN Android more generally, and existing color alpha support, but is pretty noticeable here).
This impl targets new arch only.
Changelog:
[Android][Added] - Support simple opacity in nested text
Reviewed By: alanleedev
Differential Revision: D61999163
fbshipit-source-id: adb99834e94e00cb84a98d56f422c15b1bd849db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46242
This is transitively included, but should be explicitly included.
Changelog:
[Internal] commander is a dependency when bundling from Xcode
Reviewed By: cipolleschi
Differential Revision: D61916607
fbshipit-source-id: 1466d38d959970e5bd56576f8a7a22697d2eec4e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46253
Changelog: [internal]
This is still internal because this API hasn't been publicly released yet.
## Context
This fixes a problem in our implementation for Event Timing API with paint time reporting (currently gated behind `ReactNativeFeatureFlags::enableReportEventPaintTime`) where events that don't trigger UI changes would wait for the next (unrelated) UI change to finish the event timing information.
## Implementation
We had this issue because we were relying on mount hooks to finish pending events. The problem is that if the event itself didn't cause a commit, the mount hook will not execute immediately, and we'll wait for the mount notification of whatever is the next change (in an arbitrary point in time in the future).
The fix for this has several parts:
1. Modify `RuntimeScheduler` to start tracking which surface IDs are the rendering updates applying to. It makes sense to do this regardless because `RuntimeScheduler` implements the Event Loop, and the Event Loop is aware of "documents" on Web (and the equivalent are surfaces in RN).
2. Create a new hook in `RuntimeScheduler` to report events after the task has finished executing (which is already a step in the Event Loop on Web). This will pass the list of surface IDs with pending changes, so the listener can determine if the events should be finished already or they should wait for mount for those changes.
3. Integrate `EventPerformanceLogger` with `RuntimeScheduler` and add the proper logic to handle this.
Reviewed By: sammy-SC, rshest
Differential Revision: D61939260
fbshipit-source-id: 505bd41db8d3f62e5065424e62f9ed540832eed9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46254
Changelog: [internal]
Right now it's very hard to access the surface ID from the target when dispatching events, and we need that to determine if the event we dispatched produced any updates its surface ID.
This adds surfaceId to EventTarget so we can access it without an unnecessary large amount of indirection in the current code.
This is a dependency for https://github.com/facebook/react-native/pull/46253 / D61939260, split to simplify reviewing.
Reviewed By: sammy-SC, rshest
Differential Revision: D61939910
fbshipit-source-id: 6dd6bc55fc6d4aa6cf8a535080c14a7a5b573b71
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46252
Changelog: [internal]
The long task API should only account for work specifically done by the task. Updating the rendering shouldn't be considered for that, so this moves the determination of long tasks before doing that work.
Reviewed By: sammy-SC, rshest
Differential Revision: D61939261
fbshipit-source-id: 6d2573d561d507dff60b9703e4cc90ce4d131960
Summary:
When not drawing a border, the mGapBetweenPaths adjustment can create noticable pixelation when drawing curves through a low number of pixels. This is noticable mostly on buttons and such on low-dpi devices. This fix only applies the fix if clipping for the border radius is done.
When drawing small radius rounded backgrounds (e.g. to draw a circle or button) we see visible pixelation (see [GH-41226](https://github.com/facebook/react-native/issues/41226)) This is particularly noticable on low DPI devices.
## Changelog:
[ANDROID] [FIXED] - Don't use mGapBetweenPaths if not drawing a border
Pull Request resolved: https://github.com/facebook/react-native/pull/46239
Test Plan:
Built an android app that directly uses CSSBackgroundDrawable to draw a background and verified repro of this issue.

Then modified the code according to this PR and verified that anti-aliasing is appropriately applied

Reviewed By: NickGerleman
Differential Revision: D61925281
Pulled By: jorge-cab
fbshipit-source-id: 93014629d031bd0d716cd3bb11e2c294dedad639
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46237
I can't find any uses of this, it's not referenced in any fixtures, and flow and typescript both pass without it.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D61892355
fbshipit-source-id: 8ebb4da3e104109c740d90c2495dbcc89d3978e5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46222
This value was typed as always being a string, even though it was containing both strings and numbers in the fixtures. This was because on this line https://fburl.com/code/9j7gh4av the input type is $FlowFixMe (from the source AST), which wasn't catching that it couldn't flow into just `string`.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D61830075
fbshipit-source-id: 0d5a0239d7c0209049184ca858a7ceb1ada02f79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46221
Previously the schema special cased unparseable elementType with elementType just being undefined. This causes issues for logic that requires recursively matching types. Instead of being implicit, this makes them explicitly an AnyTypeAnnotation
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D61825742
fbshipit-source-id: 47bf70d32d21647896d8f5319087378cc8ac8d4f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46241
Our test for rebuilding the `autolinking.json` file currently rebuilds everytime if the cached json file ISN'T empty. This means users who have an empty entry get stuck there.
I've also added more validation that the contents of the cached config have at a minimum the `.project.android.packageName` entry in it, otherwise it rebuilds.
Changelog: [Internal]
Closes 46134
Reviewed By: cortinico
Differential Revision: D61911114
fbshipit-source-id: 188c7f975ce05802c8ea06eaa48345c2bc96f2b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46224
- Extract functions from StatusBarModule so they can be reused
- WindowUtil was created as a container for the extracted Window related helper functions
Changelog: [Internal]
Reviewed By: tdn120
Differential Revision: D61834841
fbshipit-source-id: a40f6b95ab7569bbe7680b5ca314eb0844114d1d
Summary:
Fix linear gradient borders with BackgroundStyleApplicator.
### After fix
<img width="200" alt="Screenshot 2024-08-18 at 3 44 56 PM" src="https://github.com/user-attachments/assets/79ae7c9c-3b64-43e0-bbbe-ddc930c73648">
## Changelog:
[ANDROID] [FIXED] - Linear gradient border styles
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/46084
Test Plan: Test border examples in LinearGradientExample.js
Reviewed By: rshest
Differential Revision: D61798132
Pulled By: NickGerleman
fbshipit-source-id: a8cf1d84166044e09fb573995cac3d3f31c2187b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46145
Filters clip children by default due to using `RenderEffect` we are keeping this behavior but we were clipping to the border box while Web clips to padding box.
To keep the clipping consistent we are enforcing `Overflow.HIDDEN` when a view contains a filter.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D61630698
fbshipit-source-id: dcc3fd680546793096d8996f405724df0a834079
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46231
Removes this option from `npx react-native start`. Flipper will no longer be the default launch flow in 0.76.
The debugger frontend variant remains controlled by `target.reactNative.capabilities?.prefersFuseboxFrontend`. This will always be Fusebox, since D60893243.
Changelog:
[General][Changed] Remove `--experimental-debugger` option from start command
Reviewed By: robhogan
Differential Revision: D61852415
fbshipit-source-id: 3351f0e12c24717916a70dd1ea28f8690bb5509f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46223
Changelog: [internal]
This introduces a new feature flag to fix some problems with `IntersectionObserver` on Android.
## Context
Our current implementation works as follows:
1. When observing a new target, we synchronously check if there are pending transactions in the mounting layer for that surface.
a) If there are, then we don't dispatch an initial notification for the current state of that target and we wait for those transactions to the applied. When they are, mount hooks are executed and the notifications are dispatched.
b) If there aren't, then we cannot rely on receiving a notification via mount hooks, so we dispatch the notification immediately.
This works well to ensure that when observing a target that was just mounted by React we'll receive a notification with the paint time for that target.
The problem we currently have on Android is that that platform uses a "push" model for the mounting layer, which means we consume transactions immediately after commit. Because of that, when we check whether there are pending transactions, the mounting layer would report "no" but the consumed transactions haven't actually been mounted. In that case, we dispatch the notification immediately.
The result of that behavior is that we don't wait for the transactions that will paint a new target and instead report its intersection immediately, providing incorrect data about when it was first mounted.
## Changes
The way the new feature flag fixes the problem is by adding a new parameter in `MountingCoordinator::pullTransaction` to tell the coordinator that it should continue reporting pending transactions if there were any when that was called. We also add a new method to clear pending transactions when we execute mount hooks for that surface.
Reviewed By: javache
Differential Revision: D61831209
fbshipit-source-id: ed6e5a3d27bd3e802c79a203e920d247b1715c61
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46234
We were seeing some cases of these not working and that was because CoreFeatures::enablePropIteratorSetter was set to true and we need to add this line for it to parse with that
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D61861547
fbshipit-source-id: 47356671dc61e99ffa3df9834eb5856f29b07c59
Summary:
RN Android has historically delegated any responsibilities for background and border rendering to individual view managers.
When we enforced that SVCs didn't allow more properties than native view configs, it meant that unlike for iOS, we needed to structure these SVCs to only apply to single view managers, to avoid warnings.
This creates issues for third-party view managers extending ReactViewGroupManager, which don't seem to get these attributes added to their SVCs under current setup. RNSVG also uses `codegenNativeComponent` on TS `ViewProps`, but for historically reasons around hiding props from the new arch, that does not include these props (and would not have a way to associate with the right process function if it did).
After we clean up an old experiment path (waiting a little bit longer for safety), BaseViewManager on Android will be able to influence rendering, and we can put these in BaseViewManager (see D61658737).
In the meantime, D60575253 allows us to make SVCs a superset of native view config, which means we can declare this for `BaseViewConfig`, before Java view managers catch up, without creating warnings.
Changelog:
[Android][Changed] - Move `experimental_boxShadow` and `experimental_backgroundImage` to BaseViewConfig
Reviewed By: RSNara
Differential Revision: D61744706
fbshipit-source-id: dcf3511ee6f826ef260f557703c182b361b7a2d7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46043
# Changelog: [Internal]
Defined JavaScript interface, which can be used by other modules, such as LogBox, which will be migrated in the next diff
Reviewed By: robhogan
Differential Revision: D61301333
fbshipit-source-id: 63bb8581b893d0fdcb36e1fa16d243f1a5b08ac4
Summary:
Solves this issue: https://github.com/facebook/react-native/issues/29763
## 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] [ADDED] - Added a conditional check in the `resolveThemeAttribute` function to reattempt resource resolution with the "android" package name if the resource ID is 0.
**Reason why app is getting crashes?**
The crash was occurring due to an issue with resolving certain color attributes in the Android theme. Specifically, when attempting to resolve attributes like textColorPrimary, the getIdentifier method returned a resource ID of 0, indicating that the resource could not be found. This issue resulted in the resolveThemeAttribute function failing, as it attempted to resolve a non-existent resource ID, which led to a crash.
**Key Points:**
**Problem**: Resource ID returned as 0 for specific attributes like textColorPrimary.
**Cause**: The resource ID of 0 indicates that the attribute was not found in the app's resources.
**Impact**: The resolveThemeAttribute function attempted to resolve an invalid resource ID, leading to crash because of this line: https://github.com/facebook/react-native/blob/6cfe51ded006e55617a6f4f2587ca2026306c58d/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/bridge/ColorPropConverter.java#L227
The introduced fix includes a fallback mechanism to attempt resolution with the "android" package name when the initial lookup returns 0. This helps in correctly resolving theme attributes that might be part of the Android system's default resources, thereby preventing the crash.
Pull Request resolved: https://github.com/facebook/react-native/pull/46202
Test Plan: - Tested the app with above colors mentioned. Ensured that app is not getting crashed.
Reviewed By: cipolleschi
Differential Revision: D61847357
Pulled By: cortinico
fbshipit-source-id: 50895a8fd7956e001dbbad9a505ae65151209bd9
Summary:
Replicates https://github.com/react-native-community/cli/commit/48d4c29bba4e8b16cbc8307bd1b4c5349f3651d8, which landed inside `cli-plugin-metro` inside RNC CLI, but because of migration of code to `community-cli-plugin` it looks like apparently the fix wasn't replicated.
## Changelog:
[GENERAL] [FIXED] - Ensure `--build-output` destination exists
Pull Request resolved: https://github.com/facebook/react-native/pull/45182
Test Plan:
Specify a new directory that doesn't exists inside `--build-output`:
`npx react-native bundle --build-output dist/new-dir/index.bundle`
and this command shouldn't fail.
Reviewed By: christophpurrer
Differential Revision: D61850942
Pulled By: huntie
fbshipit-source-id: 90e57f19c661ace8206162d6fa2e6a27acb31e20
Summary:
This PR solves a small issue I've encountered when working with the repo.
When changing branches we often run `yarn` to reinstall dependencies (let's say we change from 0.74-stable to main).
There are lots of changes between those two versions in the `react-native-codegen` package. This causes an issue when we install pods in `packages/rn-tester` the old version of codegen is used (the one cached from 0.74-stable) leading to a big error that's hard to solve at first.
This PR solves this by building codegen on `postinstall`. I've seen many newcomers blocked by this issue (and rerunning `yarn` is the natural thing to do in this situation)
## Changelog:
[INTERNAL] [ADDED] - Build codegen on postinstall when working with the monorepo
Pull Request resolved: https://github.com/facebook/react-native/pull/46227
Test Plan: Run `yarn`
Reviewed By: cipolleschi
Differential Revision: D61849150
Pulled By: huntie
fbshipit-source-id: 24fc5cf9b6a2510298f7bcdce59043e5dcfbfdd4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46229
When running codegen from `pod install`, something affects `require.resolve`, and it starts looking for codegen-enabled dependencies from the workspace root, not the current RN project root.
This is bad if we have different versions of same dependency across multiple workspaces. One of them will be hoisted to the workspace root, and will be used for all the workspaces.
This issue is described in details here https://github.com/facebook/react-native/issues/46196
This diff is supposed to fix this by adding the project root path to the `require.resolve` call.
Changelog: [iOS][Fixed] - Codegen will start looking for codegen-enabled dependencies from the project root.
Reviewed By: cipolleschi
Differential Revision: D61850219
fbshipit-source-id: d60a0e72e9c60e862c0d64e227ea3652d1be5a90
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46216
Regarding [issue](https://github.com/facebook/react-native/issues/45817) with incorrect layout when `left` is set to `auto`. This PR introduces handling `auto` whenever inline or flex position is checked to be defined and it fixes above issue.
Changelog:
[General][Fixed] - Fix handling 'auto' checks in absolute layout
## Tests:
I have run the provided unit tests and everything passes.
X-link: https://github.com/facebook/yoga/pull/1689
Reviewed By: cipolleschi
Differential Revision: D61737876
Pulled By: NickGerleman
fbshipit-source-id: 531199a91c5e122b930b49725ea567cbb1d592ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46215
These cause a build error in RN and need to be updated any time a thick Yoga API changes. This change replaces them with mocking the factories with Mockito instead.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D61804855
fbshipit-source-id: 24fbf10a12102de2975ba3aee45efe7350e294ec
Summary:
This PR modifies hermes-engine.podspec to resolve the path to `react-native` dynamically.
In OOT platforms case we often have slightly different versioning, let's say `react-native` is at 0.75.1 and `react-native-visionos` is at 0.75.2. This causes an issue while resolving the prebuilt version of Hermes. We should always get the Hermes tied to the `react-native` package version, not the OOT platform.
## Changelog:
[IOS] [FIXED] - Resolve Hermes prebuilt version based on react-native packge
Pull Request resolved: https://github.com/facebook/react-native/pull/46181
Test Plan: Install pods
Reviewed By: blakef
Differential Revision: D61720652
Pulled By: cipolleschi
fbshipit-source-id: a99c3261ae8738979f30e831ac6cb494a5c06e31
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46220
We'll want to eventually combine the module and component capabilities more, but these are at least the trivially shared ones.
More work is required to merge the more complex object types.
This change also makes it more clear where capabilities are different between native modules and components
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D61740140
fbshipit-source-id: 9e7bf740cf6cd2431be8cad822ec69903dbbc71f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46218
Changelog: [internal]
https://github.com/facebook/react-native/pull/42975 added some logic to fix modal on iOS for Paper but introduced a state update in `componentWillUnmount`. Doing this is incorrect and we've seen cases where it leads to forcing passive effects synchronously, which can affect performance.
This removes that unnecessary call to update the state, because the component will be unmounted anyway.
Reviewed By: bgirard
Differential Revision: D61813988
fbshipit-source-id: bb203578376d86a907544fa62a0d04e93ca132ef
Summary:
flattenStyle may return an object which is already frozen (in development), so it is incorrect to further mutate this.
related to https://github.com/facebook/react-native/issues/45285
## Changelog:
[GENERAL] [FIXED] - fixed fontWeight number value error for text optimized
Pull Request resolved: https://github.com/facebook/react-native/pull/45932
Reviewed By: NickGerleman
Differential Revision: D61773721
Pulled By: javache
fbshipit-source-id: c5e23becf3af0b4303dda7b9d48628b2bca3285a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46214
This tries to represent a few operations which have previously been observed to be costly in a sampling profiler (showing more granularity than the trace events):
1. TextView getting measurements via `onMeasure()` when updating layout metrics during mount, which may [trigger UI-thread text layout](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/widget/TextView.java;l=11217).
2. Text drawing, which may do layout as well
3. State updates, where we construct a new Spannable and set content to it
Changelog: [Internal]
Reviewed By: tdn120, mdvacca
Differential Revision: D61705770
fbshipit-source-id: 199a6c65c18296f2ff948642701a331ba656e9d9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46205
When React.Activity unmounts and remounts effects, we fail to re-attach the native view to the NativeAnimated nodes, which causes animations to stop working.
Changelog: [Internal]
Reviewed By: sammy-SC, bvanderhoof
Differential Revision: D61662164
fbshipit-source-id: 8e86502f7258beba02d5e60b31864974d7288af5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46179
Changelog: [Internal]
**Context**
- When debugging E2E tests, we found RNTester Legacy Arch builds were rendering border radius w/ percentages in a strange way
- The issues was only noticeable on production e2e builds
- Support for percentage on borderRadius ViewStyle props was added in D56198302
- This should be fabric only, but the same props are parsed on Paper
**Change**
- Add Custom Conversion for BorderRadius on Paper
- Only Parse integer border radius values
Reviewed By: philIip
Differential Revision: D61686841
fbshipit-source-id: cc24d3dbdb82b1dcb90f18fc44d5d13d3e6465b4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46188
UBSAN identified undefined behavior when argCount == 0 (defining a variable array of zero length).
Plus variable arrays in C++ are a clang extension.
[ChangeLog]: [General] [Fixed] - Undefined behavior fix in MethodInvoker
Reviewed By: nlutsenko
Differential Revision: D61725776
fbshipit-source-id: 3729080eae8e78b65a558305f68782ae99edbc0a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46143
Before `drop-shadow` was not creating a stacking context causing its children to get flattened and not receive the shadow effect.
This was due to incorrect parsing on C++. We didn't notice since we don't support `drop-shadow` on iOS and Android gets the parsed prop directly
Changelog: [Internal]
Reviewed By: NickGerleman, joevilches
Differential Revision: D61617699
fbshipit-source-id: a8bfbb0043fcd2b2867923eb937a6be8e9004f13
Summary:
Solves this issue: https://github.com/facebook/react-native/issues/44107
## 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] [ADDED] - Line break mode for TextInput components. **This includes iOS updates to consume new cpp functions.**
This PR is a breakdown of [this](https://github.com/facebook/react-native/pull/45968) PR.
Pull Request resolved: https://github.com/facebook/react-native/pull/46129
Test Plan: - Tested builds in new and old architecture mode.
Reviewed By: andrewdacenko
Differential Revision: D61656969
Pulled By: cipolleschi
fbshipit-source-id: 4c6ed983ad15841ce52443bba13962d45c04e756
Summary:
Solves this issue: https://github.com/facebook/react-native/issues/44107
## 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] [ADDED] - Line break mode for TextInput components. **This includes cpp changes and new functions.**
This PR is a breakdown of [this](https://github.com/facebook/react-native/pull/45968) PR.
Pull Request resolved: https://github.com/facebook/react-native/pull/46130
Test Plan: - Tested builds in new and old architecture mode.
Reviewed By: andrewdacenko
Differential Revision: D61656894
Pulled By: cipolleschi
fbshipit-source-id: 9a25387cb27cded072e76575e6d2fca01963c621
Summary:
A previous attempt at fixing this issue used a relative path (https://github.com/facebook/react-native/issues/45208), this doesn't work if the user runs bundle install outside of the `ios/`
folder, using the `--project-directory=ios` argument.
## Changelog:
[iOS][Fixed] support bundle install from outside the ios folder using --project-directory
Pull Request resolved: https://github.com/facebook/react-native/pull/46186
Test Plan:
Ran the command in a project with `react-native-firebase/app` using the
`--project-directory`, confirmed that it's fixed when using the absolute
path.
closes: reactwg/react-native-releases#341
Reviewed By: cipolleschi
Differential Revision: D61719821
Pulled By: blakef
fbshipit-source-id: d83429dd29c9e8cc066ab9843ad95fdfc0af8dea
Summary:
This PR adds few missing text content types on iOS (available from iOS 15)
- dateTime
- flightNumber
- shipmentTrackingNumber
## Changelog:
[IOS] [ADDED] - Add support for missing text content types
Pull Request resolved: https://github.com/facebook/react-native/pull/42788
Test Plan: Make sure that `RNTester` builds and runs successfully
Reviewed By: robhogan
Differential Revision: D61656748
Pulled By: cipolleschi
fbshipit-source-id: e960eded5f049d3c4bf76a5a4e3159b240546288
Summary:
I couldn't find a reference nor a reason for this method. It's a bit hard to grep, so let me know if I missed something.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D61558809
fbshipit-source-id: d977440ff98b2a5bf115d19bfa4acbcf6d216b2a
Summary:
FIXES https://github.com/facebook/react-native/issues/45858
When working with UIRefreshControl in a custom React Native component, we encountered a problem where the refresh control did not behave correctly if it was offscreen. Specifically, attempts to programmatically begin or end refreshing were ignored if the control was not visible. This typically manifested as the refresh control not updating its state properly when it was re-rendered or moved in the view hierarchy.
Happening only on old-arch.
**Problem Details**
**Offscreen Refresh Control Ignored:** The UIRefreshControl would ignore calls to beginRefreshing and endRefreshing if it was not currently visible on the screen.
**Inconsistent State:** The internal state _currentRefreshingState might not match the actual state of the UIRefreshControl, leading to unexpected behavior.
**Steps to Fix**
**Track Visibility with didMoveToWindow:**
Implement the didMoveToWindow method to track when the refresh control is added to or removed from the window.
Use a flag _hasMovedToWindow to keep track of this state.
And check this flag should be true whenever we start or end refreshing
## Changelog:
[IOS] [FIXED] - Fixed an issue where the refresh control would not behave correctly if it was offscreen.
Pull Request resolved: https://github.com/facebook/react-native/pull/45996
Test Plan:
Issue Screen recording
https://github.com/user-attachments/assets/73b45c27-19c2-4eeb-991e-33b45f0a6d97
Fix Screen Recording :
https://github.com/user-attachments/assets/ffc6b6e6-fc68-498c-abdf-3144c31caa86
Reviewed By: realsoelynn
Differential Revision: D61657472
Pulled By: cipolleschi
fbshipit-source-id: 7a369f8e3ca902536a7608fbe1b89cec7734c418
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46176
Noticed that ModalHostView's event dispatching would sometimes fallback to RCTEventEmitter, which is not supported in the new architecture. Instead, we should propagate the reactTag to the inner content view so we can correctly associate the right UIManager and host component with events emitted.
Changelog: [Android][Fixed] PointerEvents from Modal would not be dispatched correctly in new architecture.
Reviewed By: bvanderhoof
Differential Revision: D61671005
fbshipit-source-id: 6aad1ff609da81cf5e8f71c4e91be30713494679
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45966
JSI performs the check itself, no need to do it here. Plus, bytecode
bundles must not be zero terminated.
## Changelog:
[IOS] [FIXED] - Fixes NSDataBigString length calculation
Reviewed By: realsoelynn
Differential Revision: D61058869
fbshipit-source-id: 15b99ef13f9aebd11ff410d02c21db8e46cc6ac3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46156
Changelog: [internal]
This improves the handling of disconnected nodes in `IntersectionObserver`. Specifically:
* When observing a node, if the node is disconnected (unmounted) this is just a no-op (without logging errors). We can't observe an unmounted node.
* When disconnecting the observer, if the observed nodes are disconnected, we get the target shadow node from an internal map, which we always have access to if we successfully started observing the node. If this logs an error now, it's something to look into but it won't generally log it if the target is just disconnected. That will work correctly.
Reviewed By: bvanderhoof
Differential Revision: D61656597
fbshipit-source-id: 6a39c878acc976ddc0789260106da104a3f2a57f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46157
Changelog: [internal]
This improves the handling of disconnected nodes in `MutationObserver`. Specifically:
* When observing a node, if the node is disconnected (unmounted) this is just a no-op (without logging errors). We can't observe an unmounted node.
* When disconnecting the observer, if the observed nodes are disconnected, we get the target shadow node from an internal map, which we always have access to if we successfully started observing the node. If this logs an error now, it's something to look into but it won't generally log it if the target is just disconnected. That will work correctly.
Reviewed By: bvanderhoof
Differential Revision: D61655856
fbshipit-source-id: d18a885350ef000fc563c85f6775ba864d184ad1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46138
jorge-cab noticed that filters on iOS do not fit the shape of the layer if we have rounded corners. Fix is pretty straight forward.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D61612655
fbshipit-source-id: 91785ed10a039e031c5440bde131c1583ba3992a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46146
Changelog: [Internal]
`unit` is of type `UnitType`, so there's no reason to have a default case here.
i found this because my build failed when pulling in this dependency, there was a compiler flag that enforced that all cases must be enumerated. this seems like the right practice anyways.
Reviewed By: NickGerleman
Differential Revision: D61635463
fbshipit-source-id: b84b5518f2a17e792309f85ae91514a17abad295
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46103
Reducing the boundary of rerender of virtual lists. Previously with prop: "strictMode={true}" the VirtualizedList still re rendered each CellRenderer component. Because method getDerivedStateFromProps generated every time a new uniq state and the cells didn’t have a PureComponent. It helps to improve react performance for lists which have 5+ elements.
I reused recomended approach from react doc https://legacy.reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html#what-about-memoization
changelog: [internal]
Optimizing CellRenderer of VirtualizedList
Reviewed By: NickGerleman, sammy-SC
Differential Revision: D61493434
fbshipit-source-id: 917a33e48bd2f18e8ac150e5701d2e7c45dbe879
Summary:
Clean up some dead code after some refactoring of RCTParagraphComponentView. cc cipolleschi
## Changelog:
[IOS] [FIXED] - Clean up RCTParagraphComponentView & RCTParagraphTextView
Pull Request resolved: https://github.com/facebook/react-native/pull/46125
Test Plan: CI green.
Reviewed By: christophpurrer
Differential Revision: D61603193
Pulled By: cipolleschi
fbshipit-source-id: a357e8c5355707b2296462de513010acda4ee6ea
Summary:
In the recent 0.75 release I've noticed new `CONFIG_CMD` option in `react-native-xcode.sh`. But this option was not used. Insted when set `CONFIG_APP` was used.
This seems like a bug. As the usage before this PR would be as follow:
```bash
export CONFIG_CMD=true
export CONFIG_APP="/path/to/node /path/to/node_modules/react-native/cli.js config"
```
After this PR
```
export CONFIG_CMD="/path/to/node /path/to/node_modules/react-native/cli.js config"
```
This PR also removed unused explicite `--config-cmd "$CONFIG"` flag, as this is always overwriten by the code above, by default to `--config-cmd" "$NODE_BINARY $NODE_ARGS $REACT_NATIVE_DIR/cli.js config`.
## 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] - Use CONFIG_CMD if set
Pull Request resolved: https://github.com/facebook/react-native/pull/46112
Test Plan: I've set `CONFIG_CMD` and run Xcode Release build to check that the set command is executed.
Reviewed By: christophpurrer
Differential Revision: D61545010
Pulled By: blakef
fbshipit-source-id: ebbf8ebc08404bc6816277518a3b86c6f7e41e6e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46131
React native 0.75.0, 0.75.1 and 0.75.2 has been published to NPM without the latest tag, despite the tag being on the commit.
When debugging why that's happened, I realized that we were not downloading the tags when checking out the repo.
This change fixes that.
{F1816667285}
## Changelog:
[Internal] - Publish React native as latest when the latest tag is specified on git
Reviewed By: cortinico
Differential Revision: D61593398
fbshipit-source-id: 96bf8346207f0bd0b01f60ee09879210d12d30af
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46132
Temporaily disable the `nativeSourceCodeFetching` capability — which reverts this to the legacy handling in the Inspector Proxy.
This is because we've noticed performance issues when loading large bundle source maps, particularly on Android, with a nontrivial path to optimising this ([raising the frontend `IO.read` size](https://github.com/facebookexperimental/rn-chrome-devtools-frontend/pull/97) further is leading to WebSocket disconnections on Android 😐).
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D61543480
fbshipit-source-id: ee66b4cebd40f8cc6466270c5875df744d2b588a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46113
changelog: [internal]
This showed promised in local tracing but that failed to translate to real perf improvement. Unshipping.
Reviewed By: christophpurrer
Differential Revision: D61537744
fbshipit-source-id: 03a2a69a6fed32a6b493bc17372e3783b9db2d1e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46122
Implements a JavaScript cache for `colorScheme` in the `Appearance` module, so that we avoid potentially expensive and unnecessary native property accesses.
Changelog:
[General][Changed] - Improved `Appearance.getColorScheme` performance
Reviewed By: rickhanlonii
Differential Revision: D61567880
fbshipit-source-id: ca316946d68114b05239daa17105c85e637efe07
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46120
Currently, the implementation of `Appearance` duplicates the validation logic of string `colorScheme` values multiple times.
This leads to more complicated code and also unnecessary work in certain edge cases (e.g. when `NativeAppearance` is not registered).
This refactors `Appearance` to be simpler and to do less work. I've also configured `NativeAppearance.setColorScheme` to be non-nullable because it has existed since 2023.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D61567881
fbshipit-source-id: 61cb51709dc716ad97ae1397105414e74fe57a28
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46121
Updates `Appearance` on Android to supply the native module to `NativeEventEmitter` so that the native listener count can be managed like it is on iOS.
This was previously required by macOS and iOS. Android and Windows also already implement:
```
interface NativeModule {
addListener(eventType: string): void;
removeListeners(count: number): void;
}
```
So we should start passing `NativeAppearance` into the `NativeEventEmitter` constructor across all platforms.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D61567883
fbshipit-source-id: 1b3b76de9be3f35cacba1acbc43f6dcc0b41fde5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45859
"Fabric without SVCs" configuration is nearly gone, and so it doesn't make sense to need to add no-op methods, on normally Paper only code, etc to satisfy native viewconfig. These particular warnings are then more often noise, than things we need to action on.
Checking for native code to be present can also break development where users are using distributed native app, slightly older than JS.
This keeps the warning, only if static viewconfigs are missing native view config attributes (i.e. new prop would only be exposed to Paper, instead of only exposed to Fabric)
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D60575253
fbshipit-source-id: 1c118274b92eb7922c0dd92df060b24e44fceb3d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46116
If your app raises an early js exception, and you cold start it, often you'll see this error:
```
SurfaceRegistryBinding::startSurface failed. Global was not installed.
```
{F1807125099}
The reason why is because two different threads race to redbox:
* The nativemodule thread: the early js error (reported [here](https://fburl.com/code/vcrqzsdp))
* The javascript thread: the SurfaceRegistryBinding error (a subsequent native -> js call)
After this diff, the early js error will **not jump onto the nativemodule thread** to report this error.
This ensures that we "always" (to the best of my knowledge) see the early js error first.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D61339213
fbshipit-source-id: f1b9ab30150b87377817c2fd93ca349c406db48b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46104
We want to use `PrecomputedText` to store glyph-level measurements on underlying Android Spannable. This means we need to consistently reuse the same Spannable, instead of recreating them on measurement.
We have an opaque cache ID used by Android, for spannables originating from uncontrolled TextInput on UI-thread side. We also have `AttributedStringBox`, for a kind of similar purpose on iOS, which allows passing opaque pointer to the `TextLayoutManager`. This is only used for the `measure` function.
This change makes us consistently use `AttributedStringBox` at the TextLayoutManager boundary, to let us migrate calls across TextLayoutManager to all pass opaque handle to underlying Spannable we will store, instead of passing the AttributedString each time. For now, every place previously passing an AttributedString value still passes one.
There were also some egregious cases of accepting very large structures by value, causing unneeded copies. I changed the APIs to accept anything potentially larger than two pointers to pass by reference instead.
This change is technically breaking, to any 3p code calling into TextLayoutManager (IIRC live-markdown exposed prefabs for this, but should be able to adapt fairly easily).
Changelog:
[General][Breaking] - Always use AttributedStringBox instead of AttributedString in TextLayoutManager
Reviewed By: joevilches
Differential Revision: D61484999
fbshipit-source-id: 07c5600cd917f2dab3d24559a25f27e0872ebddc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46080
1. Force the examples to be alphabetized, where the hand-maintained list has some examples that are not
2. Remove reundant/not useful UI
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D61430910
fbshipit-source-id: 1f3e116fe81502faa7a72f2720912e26c9f04bb2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46076
This will add the shadows to iOS as well. let's see if anyone notices 🙂. I also removed dead styles, and removed some of the extra (excessive) padding specific to Android where the previous shadows would overlap.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D61421903
fbshipit-source-id: 887fa5aa96e3b0b4f81114ee814897c218db2b76
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46117
Currently in large cursive blocks like layout effect we can't tell what the slow leaf function is. With this fixed I'm able to root cause more complex issues in layout effects.
Reviewed By: NickGerleman
Differential Revision: D61486415
fbshipit-source-id: 5a4043b35eedcabcbea86953aac2173f66d7257b
Summary:
Fixes these issues:
- https://github.com/facebook/react-native/issues/46070
- https://github.com/facebook/react-native/issues/39362
## 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
-->
[ANDROID] [FIXED] - Fixed black strip coming when hiding status bar
`setHidden` function is responsible for hiding status bar
https://github.com/facebook/react-native/blob/25d6a152cc720e0d5f860dab228ac2e43321d9e4/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/modules/statusbar/StatusBarModule.kt#L122
**What real issue is?** **_For android devices with camera area on top a black strip is coming after hidding status bar._**
Previous Implementation:
```
override fun setHidden(hidden: Boolean) {
val activity = currentActivity
if (activity == null) {
Log.w(
ReactConstants.TAG,
"StatusBarModule: Ignored status bar change, current activity is null.")
return
}
UiThreadUtil.runOnUiThread(
Runnable {
val window = activity.window ?: return@Runnable
if (hidden) {
window.addFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN)
window.clearFlags(WindowManager.LayoutParams.FLAG_FORCE_NOT_FULLSCREEN)
} else {
window.addFlags(WindowManager.LayoutParams.FLAG_FORCE_NOT_FULLSCREEN)
window.clearFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN)
}
})
}
```
It seems that FLAG_FULLSCREEN flag are not enough to draw content in camera area.
**Solution:**
In order to tackle this, android exposes 2 flags:
- [layoutInDisplayCutOutMode](https://developer.android.com/reference/android/view/WindowManager.LayoutParams#layoutInDisplayCutoutMode): The window is always allowed to extend into the [DisplayCutout](https://developer.android.com/reference/android/view/DisplayCutout) areas on the short edges of the screen. [Android 9.0 and above]
- [setDecorFitsSystemWindows](https://developer.android.com/reference/android/view/Window#setDecorFitsSystemWindows(boolean)): allows content to be able to extend into the cutout area. [Android 10.0 and above]
By adding this flag we are now able to hide status bar properly.
```
override fun setHidden(hidden: Boolean) {
val activity = currentActivity
if (activity == null) {
FLog.w(
ReactConstants.TAG,
"StatusBarModule: Ignored status bar change, current activity is null.")
return
}
UiThreadUtil.runOnUiThread(
Runnable {
val window = activity.window ?: return@Runnable
if (hidden) {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
// Ensure the content extends into the cutout area
window.attributes.layoutInDisplayCutoutMode =
WindowManager.LayoutParams.LAYOUT_IN_DISPLAY_CUTOUT_MODE_SHORT_EDGES
window.setDecorFitsSystemWindows(false)
}
window.addFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN)
window.clearFlags(WindowManager.LayoutParams.FLAG_FORCE_NOT_FULLSCREEN)
} else {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
window.attributes.layoutInDisplayCutoutMode =
WindowManager.LayoutParams.LAYOUT_IN_DISPLAY_CUTOUT_MODE_DEFAULT
window.setDecorFitsSystemWindows(true)
}
window.addFlags(WindowManager.LayoutParams.FLAG_FORCE_NOT_FULLSCREEN)
window.clearFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN)
}
})
}
```
**_Note: This will work above Android 11 and above_**
Pull Request resolved: https://github.com/facebook/react-native/pull/46086
Test Plan:
- Tested by author of this issue
- Sharing here the videos of before and after fix
Device Detail:
Oneplus9 5G OS 11
**Before fix:**
https://github.com/user-attachments/assets/589098ff-a3fa-4962-a15b-ceacbfd03d2d
**After fix:**
https://github.com/user-attachments/assets/a87dd8e4-3624-4e09-99da-a14f9e19fcc6
Reviewed By: cipolleschi
Differential Revision: D61509889
Pulled By: alanleedev
fbshipit-source-id: 733962a3bed2efba71588a4d2fdf7c9c386bc3b4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46101
Remove overriding thread priority for RN Main Thread as it is not possible to update main thread.
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D61448536
fbshipit-source-id: 44ec28a875e3208df042ac11bdd17a7287836ebb
Summary:
Our app is using the react-native v0.74.2 with the `react-navigation` lib for screen navigation, we're facing an issue in the built iOS app that when we try to navigate to a new app screen with the `react-navigation`'s `reset` or `replace` method and meanwhile there's a react native modal displaying, then the iOS app always crashes.
I saw there is already a relevant [PR](https://github.com/facebook/react-native/pull/38491) and discussion targeting this issue, but I still think it would be better if this kind of crash can be suppressed in the framework level, currently I guess it's common in the iOS apps based on react native.
## Changelog:
[IOS] [FIXED] - app crash happening when navigate to a new app screen with a displaying modal
Pull Request resolved: https://github.com/facebook/react-native/pull/45313
Test Plan: More issue details and the reproduction steps can be found in this [PR](https://github.com/facebook/react-native/pull/38491) :)
Reviewed By: christophpurrer
Differential Revision: D61537167
Pulled By: cipolleschi
fbshipit-source-id: 3c0474d794b4216ebc073dd6558d2b6ae27492d2
Summary:
Setting a variable called `REACTNATIVE_MERGED_SO` so libraries/apps can selectively decide to depend on either libreactnative.so or link against a old prefab target (this is needed for React Native 0.76 on).
## Changelog:
[INTERNAL] - Set REACTNATIVE_MERGED_SO for React Native 0.76
Pull Request resolved: https://github.com/facebook/react-native/pull/46114
Test Plan: CI
Reviewed By: hezi
Differential Revision: D61541372
Pulled By: cortinico
fbshipit-source-id: b16fa29ce6dd1670b452848e37cfcd7be15861e6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46068
This change adds some internal E2E tests to verify that the text is rendered properly on top of a solid background color when borderWidth is set
## Changelog
[Internal] - Add E2E tests
Reviewed By: cortinico
Differential Revision: D61392253
fbshipit-source-id: 76e11821eba96ac75b055c5fe94365197c0f9be2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46081
This change fixes an issue that has been reported by OSS where a Text with both background color and borderWidth is not rendered properly.
The reason is that `RCTParagraphComponentView` uses the `drawRect` method which draws the text in the main view layer, while the parent `RCTViewComponentView` can apply an extraLayer on top of the base layer, drawing on top of the text.
This change moves the drawing of the text to an auxiliary view, `RCTParagraphTextView`, that is set as contentView of the `RCTParagraphView`. In this way, the text is drawn in a different view and can't be covered by the `_borderLayer`
## Changelog:
[Internal] - Introduce a RCTParagraphTextView to draw the text
Reviewed By: joevilches
Differential Revision: D61431369
fbshipit-source-id: 05467167186411fe42312f2ed956f5b5336de019
Summary:
This diff adds an example in RNTester to verify that we can draw text on top of a colored background and non uniform border radius.
As you can see from the test plan, the current code works well when:
* There is only the background color
* There is a background color and uniform cornerRadius
* There are non uniform border radius but the background is transparent.
The current code **does not** work when:
* there is a background and non-uniform border radius
* there is a background, uniform border radius and borderwidth
The reason why this happens is because:
* `RCTParagraphComponentView` draws the text in the View's main layer in the `drawRect` method
* `RCTViewComponentView` has a method `invalidateLayer` that, when there are non-uniform border radii o there is a borderWidth, it creates an extra `CALayer` with an image as content and that layer is put on top of the base layer, covering the text.
## Changelog
[Internal] - Add example to RNTester
Reviewed By: cortinico
Differential Revision: D61389317
fbshipit-source-id: 3e0a9e6c611190f90198a1b0b5855431b9f6ed12
Summary:
bypass-github-export-checks
Covers the case of an immediately-resolved breakpoint in `JsiIntegrationTest`, complementing the existing `ResolveBreakpointAfterReload` case.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D61468055
fbshipit-source-id: 0f68656a2558166f1302163d14722c17c590044b
Summary:
- Color stops needs to follow [fix up spec](https://drafts.csswg.org/css-images-4/#color-stop-fixup)
- Adds multiple stops syntax support. e.g. linear-gradient(red 30% 50%, green).
- Rename `position` to `positions` in object style API. Optional string array here makes more sense. We'll add number array support once `px` support is added. Will do it as a follow up to this PR.
TODOs: transition hint syntax support `linear-gradient(red, 50%, green)` (Done locally, dependent on this PR). `px` support.
## Changelog:
[GENERAL] [FIXED] - Linear gradient color stop spec.
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/45969
Test Plan: - Added testcases in processBackgroundImage-test.js
Reviewed By: javache
Differential Revision: D61309203
Pulled By: NickGerleman
fbshipit-source-id: 884052c6841320048933361f38e6478ff4192736
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45965
X-link: https://github.com/facebook/yoga/pull/1687
We are seeing some crashes that are hard to wrap our head around. Lets add more logs. I chose these values based on what could make the height/width undefined from looking at the code. We might need more but this should give us some more direction.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D61054392
fbshipit-source-id: 654ff96f94aa89605a603e2e36335bb48b61f4a2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46006
Adding some extra examples for mix-blend-mode
And added E2E tests for each mix-blend-mode example
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D60605636
fbshipit-source-id: 553f3a2c3b971c918530bdee5a73108c22bd936e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46097
I've noticed we still have some tests here and there that were not migrated to AssertJ. This finishes them all.
Changelog:
[Internal] [Changed] - Finalize AssertJ migration
Reviewed By: javache
Differential Revision: D61473682
fbshipit-source-id: 3d51bfeb0e5ba3fd8cd4f3667dc88de3d88a3dbc
Summary:
## Summary
There are old references to the react-native/template. This code has
moved to react-native-community/template.
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/46082
Test Plan:
CI
closesfacebook/metro#1324
Reviewed By: cipolleschi
Differential Revision: D61472439
Pulled By: blakef
fbshipit-source-id: fc40145c03002a7c3117b72d07981a96aa3d8760
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46074
This brings over the changes made to OutsetBoxShadowDrawable. Namely
1. Removing reliance on CSSBackgroundDrawable for drawing paths
2. Using BlurMaskFilter instead of RenderEffect
3. Removing RenderNode usage
This should make the implementation, more reliable less memory intensive for large boxes, and compatible down to Android API 29. I changed previous gating to allow outset shadows for 28+, and inset for 29+.
Changelog:
[Android][Changed] - Revamp InsetBoxShadowDrawable
Reviewed By: joevilches
Differential Revision: D61348615
fbshipit-source-id: 97b63b5dce65224ca54b76c5318c219973fc09fa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46055
Changelog: [Android][Breaking]
BaseReactPackage is a 1:1 replacement for the deprecated TurboReactPackage. TurboReactPackage has been deprecated since 0.74. let's move the codebase to the recommended standard.
Reviewed By: cortinico
Differential Revision: D61329022
fbshipit-source-id: cef69e37bb2be7f6dccbab70d0996c33a8abf091
Summary:
## Summary
Flow will eventually remove the specific `React.Element` type. For most
of the code, it can be replaced with `React.MixedElement` or
`React.Node`.
When specific react elements are required, it needs to be replaced with
either `React$Element` which will trigger a `internal-type` lint error
that can be disabled project-wide, or use
`ExactReactElement_DEPRECATED`.
Fortunately in this case, this one can be replaced with just
`React.MixedElement`.
## How did you test this change?
`flow`
DiffTrain build for commit https://github.com/facebook/react/commit/85fb95cdffdd95f2f908ee71974cae06b1c866e1.
bypass-github-export-checks
Reviewed By: poteto
Differential Revision: D61397212
Pulled By: SamChou19815
fbshipit-source-id: c0aa5a4ed3922f88b7e557738f76f872c02a9d07
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46059
This merges all the remaining dynamic libraries into libreactnative.so.
Sadly I couldn't split this in smaller diffs as all the libraries are connected with each other.
I also had to introduce 2 other SOs: `libhermestooling.so` and `libjsctooling.so` which contains
all the necessary libs used when loading either JSC or Hermes. They need to be isolated
as RNGP will remove those libraries based on the library the user decides to pick.
Changelog:
[Android] [Breaking] - Merge all the remaining .so libraries into libreactnative.so
Reviewed By: hezi
Differential Revision: D61376496
fbshipit-source-id: ab9e725b7acbebdfd8fa3ff36ad34d080044bf0e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46057
We have a bunch of prefab targets which are no longer necessary. I'm removing them all in this first round of cleanup
Changelog:
[Android] [Breaking] - Remove several unnecessary android prefab targets. Use ReactAndroid::reactnative instead
Reviewed By: cipolleschi
Differential Revision: D61376497
fbshipit-source-id: e2e3cb38b1db712890f8bd58abadbdcb5cfaeec7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46010
X-link: https://github.com/facebook/hermes/pull/1474
Changelog:
[General][Added]: support for rendering Error object previews in Chrome DevTools console
On web, an array of Error objects have previews. This diff brings the parity to RN DevTools
Reviewed By: huntie
Differential Revision: D61243518
fbshipit-source-id: d9c6af4b44cef44cb63c4462eee649a8e498a429
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45883
Isolate property lets us easily define when a <View> should set a stacking context.
This is particularly useful when used with `mix-blend-mode`
Changelog: [Internal]
Reviewed By: christophpurrer, NickGerleman
Differential Revision: D60604683
fbshipit-source-id: 449079abe45ae57e98315bdf27b54ec5cf9d6fdc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45867
Before mix-blend-mode was blending with everything in the background, now we make it blend with just stacking context parent as spec by doing off-screen rendering.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D60597403
fbshipit-source-id: 3af0c1266fde4ca32846785879d616316349369c
Summary:
Referring to the [iOS Large Content Viewer](https://developer.apple.com/videos/play/wwdc2019/261/):
iOS Tab Bars can't grow with dynamic text, but the Large Content Viewer helps them to be seen by people with low vision.
Currently on React Native we don't expose the properties that can help implementing iOS [UILargeContentViewerItem](https://developer.apple.com/documentation/uikit/uilargecontentvieweritem) protocol.
The goal of this PR is to expose the necessary props.
In this PR, I'm exposing 2 props:
- `accessibilityShowsLargeContentViewer`: to enable the large content viewer
- `accessibilityLargeContentTitle`: to define the large content viewer title
I plan to use this to open a PR on react-navigation so that bottom tabbars can implement largeContentViewer.
Should fix https://github.com/facebook/react-native/issues/30892
## Changelog:
[IOS] [ADDED] - Support LargeContentViewer on iOS for better accessibility
Pull Request resolved: https://github.com/facebook/react-native/pull/45903
Test Plan: <img width="300" src="https://github.com/user-attachments/assets/d8f1dc46-66e7-4945-bc3b-f1d29044441b" />
Reviewed By: cipolleschi
Differential Revision: D61148361
Pulled By: joevilches
fbshipit-source-id: 86dd92f4f79534a58e6e015febdaf217ea291eb4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45985
As title.
We can now create ellipses when using percentages. The algorithm for this is still flawed and to get it to be a 1:1 to web it will probably require a re-write of some of the logic but this should get us closer for now.
Some examples:
1. Border thinning on large single corner radii (100%)
{F1798145800}
2. Thinning gets worse when having irregular border colors (100%)
{F1798148002}
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D61025927
fbshipit-source-id: 218d44af014bc8351c329ff1bca82658aebac38c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46039
Broke during Kotlin conversion I assume
Image onSubmit events were failing with
```
FdingControllerListener E InternalListener exception in onSubmit
E java.lang.NullPointerException: Parameter specified as non-null is null: method com.facebook.react.views.image.ReactImageView$setShouldNotifyLoadEvents$1.onSubmit, parameter
callerContext
E at com.facebook.react.views.image.ReactImageView$setShouldNotifyLoadEvents$1.onSubmit(Unknown Source:9)
E at com.facebook.drawee.controller.ForwardingControllerListener.onSubmit(ForwardingControllerListener.java:75)
E at com.facebook.drawee.controller.AbstractDraweeController.reportSubmit(AbstractDraweeController.java:832)
E at com.facebook.drawee.controller.AbstractDraweeController.submitRequest(AbstractDraweeController.java:578)
E at com.facebook.drawee.controller.AbstractDraweeController.onAttach(AbstractDraweeController.java:468)
E at com.facebook.drawee.view.DraweeHolder.attachController(DraweeHolder.java:252)
E at com.facebook.drawee.view.DraweeHolder.attachOrDetachController(DraweeHolder.java:269)
E at com.facebook.drawee.view.DraweeHolder.onAttach(DraweeHolder.java:87)
E at com.facebook.drawee.view.DraweeView.doAttach(DraweeView.java:208)
E at com.facebook.drawee.view.DraweeView.onAttach(DraweeView.java:194)
E at com.facebook.drawee.view.DraweeView.onAttachedToWindow(DraweeView.java:168)
E at android.view.View.dispatchAttachedToWindow(View.java:20812)
E at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:3497)
E at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:3497)
E at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:3497)
E at android.view.ViewGroup.addViewInner(ViewGroup.java:5290)
E at android.view.ViewGroup.addView(ViewGroup.java:5076)
E at com.facebook.react.views.view.ReactViewGroup.addView(ReactViewGroup.java:591)
E at android.view.ViewGroup.addView(ViewGroup.java:5016)
E at com.facebook.react.views.view.ReactClippingViewManager.addView(ReactClippingViewManager.java:41)
E at com.facebook.react.views.view.ReactClippingViewManager.addView(ReactClippingViewManager.java:21)
E at com.facebook.react.fabric.mounting.SurfaceMountingManager.addViewAt(SurfaceMountingManager.java:412)
E at com.facebook.react.fabric.mounting.mountitems.IntBufferBatchMountItem.execute(IntBufferBatchMountItem.java:119)
E at com.facebook.react.fabric.mounting.MountItemDispatcher.executeOrEnqueue(MountItemDispatcher.java:387)
E at com.facebook.react.fabric.mounting.MountItemDispatcher.dispatchMountItems(MountItemDispatcher.java:294)
E at com.facebook.react.fabric.mounting.MountItemDispatcher.tryDispatchMountItems(MountItemDispatcher.java:127)
E at com.facebook.react.fabric.FabricUIManager$DispatchUIFrameCallback.doFrameGuarded(FabricUIManager.java:1362)
E at com.facebook.react.fabric.GuardedFrameCallback.doFrame(GuardedFrameCallback.kt:22)
E at com.facebook.react.modules.core.ReactChoreographer$frameCallback$1.doFrame(ReactChoreographer.kt:59)
E at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1035)
E at android.view.Choreographer.doCallbacks(Choreographer.java:845)
E at android.view.Choreographer.doFrame(Choreographer.java:775)
E at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1022)
E at android.os.Handler.handleCallback(Handler.java:938)
E at android.os.Handler.dispatchMessage(Handler.java:99)
E at android.os.Looper.loopOnce(Looper.java:214)
E at android.os.Looper.loop(Looper.java:304)
E at android.app.ActivityThread.main(ActivityThread.java:7918)
E at java.lang.reflect.Method.invoke(Native Method)
E at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
E at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1010)
```
Changelog: [Internal]
Reviewed By: fabriziocucci
Differential Revision: D61332854
fbshipit-source-id: 48409e2b93abf15e846620580d1f0d07a2e75025
Summary:
Removed UIReturnKeyDefault as it caused bug when there wasn't any type.
## Changelog:
[IOS] [REMOVED]: UIReturnKeyDefault
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/46020
Reviewed By: christophpurrer
Differential Revision: D61277058
Pulled By: cipolleschi
fbshipit-source-id: 18349c49b05d492a2c2ed5713af3ceb6d3728e70
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46034
The create release workflow was not working properly for 0.75:
* the latest tag was not pushed because we were using the wrong input
* the latest tag was not deleted because we were not fetching all the tags
* the create release job 'dry-run' defaults to false, which is a bit dangerous
This change is a backport from 0.75 to main of these changes.
## Changelog
[Internal] - Make sure that the Latest tag is properly pushed to github while releasing
Reviewed By: cortinico
Differential Revision: D61331247
fbshipit-source-id: 89bf0698c45ec6c766e25b11599dbe926d8a6297
Summary:
If a fatal error is caught in js, and the js pipeline isn't ready, route it through the c++ pipeline.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D60138414
fbshipit-source-id: 333e38e2b904d6434a88469816e39bf1b9d0bc3f
Summary:
If any fatal js error is caught in c++, just route it through js error handler.
Then, make js error handler call into the right pipeline:
1. After the js pipeline is ready: Route the errors through the js pipeline
2. Otherwise: Route errors through the c++ pipeline.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D60138417
fbshipit-source-id: 24c466ffadbd14a9e9a5571548f3d34d2f406a8d
Summary:
## History
1. Originally landed in D60138415
2. Reverted in D60232011 (it broke ios oss builds)
## Motivation
In bridgeless, we want to configure the error handling of runtime scheduler. So that we can route those errors to the C++ error handling pipeline, when necessary.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D60477342
fbshipit-source-id: f14e20d7aff39e0fee42918567ccc6e685674134
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46023
Minimizing and restoring a Mac Catalyst app causes an `interfaceOrientationDidChange` which causes a downstream crash on `application.delegate.window`.
There doesn't seem to be a clean way to get if an app is fullscreen in Mac Catalyst, so just no-oping for now.
Changelog: [Internal]
Reviewed By: shwanton
Differential Revision: D61253706
fbshipit-source-id: 73d260366adcc74e88f43f256cc5aff8a6e3ef71
Summary:
This PR solves [issue](https://github.com/facebook/react-native/issues/45958) with displaying irregular borders on Fabric. The same issue appears on the old architecture, but I am having a problems there, so I am pushing this fix for now.
The problem is solved by decoupling `backgroundColor` from `borderLayer` and setting `zPosition` on `borderLayer` to `1024.0f`, so that the border is always in front of the layer. The `zPosition` is compared within a layer, so it shouldn't impact outside components. I would love to hear your opinion if there is a case in which this could break.
## Changelog:
[IOS] [FIXED] - changed border display
Pull Request resolved: https://github.com/facebook/react-native/pull/45973
Test Plan:
I've checked that on RNTester Images.

Reviewed By: joevilches
Differential Revision: D61119409
Pulled By: cipolleschi
fbshipit-source-id: a88912061c7a8d72eec4f4092adb076dd6ae511e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45927
This was attempted earlier in the year, and was unsuccessful because HelloWorld had a hidden dependency on this.
Changelog: [General][Breaking] Projects that intend to use the community CLI will now have to declare that dependency instead of transitively having the react-native package handle this.
Reviewed By: GijsWeterings
Differential Revision: D60898346
fbshipit-source-id: 1d62615f718e06caf684f48ecfaf610bf1f51f8e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45982
Changelog: [Internal]
Recently `src/private/renderer/errorhandling/ErrorHandlers.js` started showing up in some error stack traces, making LogBox less readable. This diff ensures we collapse these extra stack frames by default (as well as hide them in Fusebox, etc).
Reviewed By: hoxyq
Differential Revision: D61128294
fbshipit-source-id: 2ebcb47265aaf3281b669ed022c29978167f3e81
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45873
I'm removing the Gradle dependency on OSS SoLoader and stubbing it with our own implementation.
This will allow us to implement merging of further .so libraries and
As Fresco also depends on SoLoader, I had to stub the `NativeLoader` dependency as well.
Changelog:
[Android] [Breaking] - Do not depend on OSS SoLoader anymore and do not expose Fresco `api` dependency.
Reviewed By: mdvacca
Differential Revision: D60652007
fbshipit-source-id: 6e70a5c37ba9337fbe8772e192b886ba4693c7f1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46005
The RCTDevLoadingView is clipped in Mac Catalyst, hiding half of it under the toolbar. This change maintains the behavior on iOS of extending past the dynamic island.
{F1803665273}
Changelog: [Internal]
Reviewed By: shwanton
Differential Revision: D61209780
fbshipit-source-id: 6c9c572a9e47a8caf191c40fb53c4a7d43b64281
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45984
A few methods were not synchronized, exposing members like `mTagsToViews` to potential out-of-sync access.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D61151447
fbshipit-source-id: 696dbec559968cdfc7c6d2e662f4c8f3471039e1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45998
The exact `React.Element` type is deprecated and will be removed in a future version of Flow.
Changelog: [Internal]
Reviewed By: gkz
Differential Revision: D61205640
fbshipit-source-id: a029a3a46c7d8d9f94b0b931b991b2ce461151b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45974
This change fixes the E2E tests on the template on main.
There were two issues:
1. we were forcing the project on the 0.75 branch. We now use the current branch name
2. we were replacing all the versions for the dependencies that starts with `react-native` to the monorepo version. The problem is that also `react-native-community` packages starts with `react-native`. We now changes the versions if the dependency name starts with `react-native/`.
## Changelog:
[Internal] - Fix E2E tests on main
Reviewed By: cortinico
Differential Revision: D61122154
fbshipit-source-id: 07210fc9f63e99eac46894f13c7ca5359e186e6c
Summary:
`RCTSharedApplication().delegate.window.safeAreaInsets.bottom;` causes a crash in Mac Catalyst.
There is already precedent of a `#if TARGET_OS_MACCATALYST` in the same file. This just defaults it to 0 in that case, which looks fine.
## Changelog:
[iOS] [Fixed] - Mac Catalyst crash in RCTRedBox
Reviewed By: shwanton
Differential Revision: D61160503
fbshipit-source-id: 5771ebff88242d9dd4b892d8823e15d1f2307728
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45986
This uses SkBlurMaskFilter under the hood, to draw geometry of a solid color with alpha blur, without going the route of full image filter/rasterization. It was not supported under hardware accelerated canvases for a while, but seems to fully work as of API 29.
Requiring Android 10 instead of 12 makes box shadows a lot more palatable (80% support vs 50%), and we see drastically better performance in one case with many large shadows, where creating many large hardware layers previously drastically hurt framerates.
{F1801807696}
At this point, the RenderNode may be redundant, though I think it can technically save us some work on redraws still. It is kept around for now. I simplified some of the math around here as well.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D61162637
fbshipit-source-id: 8f6ff486e655e64a0665c31391359c499c374c8f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45987
This is a confusing public API, because styles layer deals with DIPs, conversion only happens when parsing dynamic, and `POINT` (the `LengthPercentageType`) also maps to DIPs instead of physical pixels.
This moves conversion to physical pixels to drawing layer, so everything above `BackgroundStyleApplicator` works with `style` types which are all in DIPs.
To preserve compatibility with existing APIs using raw radii, we keep it so that (most) views operate in pixel units, while view managers operate under DIPs.
Changelog: [Android][Breaking] Do not implicitly convert parsed LengthPercentage to pixels
Reviewed By: rshest
Differential Revision: D60507151
fbshipit-source-id: b90066af7b221304aded374627fc0e2165dfc08f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45947
This adjusts logic to be similar to InsetBoxShadowDrawable to keep the full ink within RenderNode bounds. This avoids a tiny bit of overdraw, but also means we get correct rendering if RenderNode is promoted to a compositing layer.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D60972085
fbshipit-source-id: 0916733c6abae37e30dd1f64a36c0e211e41917e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45963https://chromedevtools.github.io/devtools-protocol/tot/HeapProfiler/#method-takeHeapSnapshot
As per `HeapProfiler.takeHeapSnapshot` documentation, there are a few
more configurable options to what is contained in the snapshot. Adding
a struct and the `captureNumericValue` bool to the interface since
that's what we need right now. In the future, there is the
`exposeInternals` parameters that's currently experimental for Chrome.
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D60989352
fbshipit-source-id: fcd269f0db5b24983631206a1b738dea29566f0e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45944
This diff adds support having (Legacy) Native Modules with functions with parameters of type `Dynamic`.
This is currently blocking some libraries making it harder for them to migrate to New Architecture.
I've implemented it by adding a `DynamicNative` implementation of `Dynamic` which holds a reference of
the payload as a `folly::dynamic`.
Changelog:
[Android] [Added] - Add support for handling `com.facebook.react.bridge.Dynamic` as parameter type in TurboModules
Reviewed By: mdvacca, cipolleschi
Differential Revision: D60966684
fbshipit-source-id: 2e63bc53ede5277a9c12f1b19f05f6099f5f35f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45736
This was an internally used class that was made irrelevant by Kotlin conversion. Appears to be unused in OSS, no breakages expected.
Changelog:
[Android][Breaking] - Deleted LongArray
Reviewed By: sammy-SC
Differential Revision: D60292651
fbshipit-source-id: cebb3d41113ad9f3247c3189889337d6e3e4ebab
Summary:
I maintain the `react-native-svg` library, where our elements extend `ReactViewGroup`. Currently, `ReactViewGroup` only exposes the getter for `mPointerEvents` publicly, so we cannot set it. To properly handle `pointerEvents`, we would have to duplicate all methods related to `mPointerEvents`, which results in maintaining a separate state. This duplication can lead to desynchronization between the state in our class and the state in the superclass.
PR with a workaround that we can avoid with this change https://github.com/software-mansion/react-native-svg/pull/2395
## Changelog:
[ANDROID] [CHANGED] - make `setPointerEvents` public
Pull Request resolved: https://github.com/facebook/react-native/pull/45975
Test Plan: This change was tested manually by making the field public, allowing dependent classes to override or reference it.
Reviewed By: cortinico
Differential Revision: D61124293
Pulled By: javache
fbshipit-source-id: 389d0a670375a8a68c975294f98c33c28ef41ffe
Summary:
When integrating react-native into react-native-windows, we got the following build warning (which we treat as an error) when building ReactCommon: `C4715 not all control paths return a value`
This PR adds defaults to the switches to make sure every path returns a value.
See https://github.com/microsoft/react-native-windows/issues/13516
## Changelog:
[GENERAL] [FIXED] Fix "C4715 not all control paths return a value" warning in MSVC when building ReactCommon
Pull Request resolved: https://github.com/facebook/react-native/pull/45827
Test Plan: The switches are checking enums this code should never be hit unless new enum values are added.
Reviewed By: robhogan
Differential Revision: D61103286
Pulled By: NickGerleman
fbshipit-source-id: 2028cb60e0b438b9ac17a828f5e1b690052a0bec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45345
When React diffs props, it can can short-circuit nested objects if their object identity hasn't changed. Whenever we use `flattenStyle` we prevent this optimization from taking place.
Changelog: [Internal]
Reviewed By: dmytrorykun
Differential Revision: D59518281
fbshipit-source-id: e88ca781ab4622b5342169f8f27b09f0515513b3
Summary:
When using `TSan` while running the Unit tests of `RNTester`, there are a few data races picked up. One is described [here](https://github.com/facebook/react-native/issues/45280), while this PR deals with a race related to concurrent read/write of `ReactMarker::logTaggedMarkerImpl`. Here is the `TSan` output:
```
WARNING: ThreadSanitizer: data race (pid=5236)
Read of size 8 at 0x00011a602690 by thread T34:
#0 std::__1::__function::__value_func<void (facebook::react::ReactMarker::ReactMarkerId, char const*)>::operator bool[abi:ue170006]() const <null> (RNTesterUnitTests:arm64+0x18cd49c)
https://github.com/facebook/react-native/issues/1 std::__1::function<void (facebook::react::ReactMarker::ReactMarkerId, char const*)>::operator bool[abi:ue170006]() const <null> (RNTesterUnitTests:arm64+0x18cd2bc)
https://github.com/facebook/react-native/issues/2 facebook::react::JSIExecutor::initializeRuntime() <null> (RNTesterUnitTests:arm64+0x1c96818)
https://github.com/facebook/react-native/issues/3 facebook::react::NativeToJsBridge::initializeRuntime()::$_0::operator()(facebook::react::JSExecutor*) <null> (RNTesterUnitTests:arm64+0x1a7a074)
https://github.com/facebook/react-native/issues/4 decltype(std::declval<facebook::react::NativeToJsBridge::initializeRuntime()::$_0&>()(std::declval<facebook::react::JSExecutor*>())) std::__1::__invoke[abi:ue170006]<facebook::react::NativeToJsBridge::initializeRuntime()::$_0&, facebook::react::JSExecutor*>(facebook::react::NativeToJsBridge::initializeRuntime()::$_0&, facebook::react::JSExecutor*&&) <null> (RNTesterUnitTests:arm64+0x1a79fbc)
https://github.com/facebook/react-native/issues/5 void std::__1::__invoke_void_return_wrapper<void, true>::__call[abi:ue170006]<facebook::react::NativeToJsBridge::initializeRuntime()::$_0&, facebook::react::JSExecutor*>(facebook::react::NativeToJsBridge::initializeRuntime()::$_0&, facebook::react::JSExecutor*&&) <null> (RNTesterUnitTests:arm64+0x1a79e5c)
https://github.com/facebook/react-native/issues/6 std::__1::__function::__alloc_func<facebook::react::NativeToJsBridge::initializeRuntime()::$_0, std::__1::allocator<facebook::react::NativeToJsBridge::initializeRuntime()::$_0>, void (facebook::react::JSExecutor*)>::operator()[abi:ue170006](facebook::react::JSExecutor*&&) <null> (RNTesterUnitTests:arm64+0x1a79d84)
https://github.com/facebook/react-native/issues/7 std::__1::__function::__func<facebook::react::NativeToJsBridge::initializeRuntime()::$_0, std::__1::allocator<facebook::react::NativeToJsBridge::initializeRuntime()::$_0>, void (facebook::react::JSExecutor*)>::operator()(facebook::react::JSExecutor*&&) <null> (RNTesterUnitTests:arm64+0x1a75250)
https://github.com/facebook/react-native/issues/8 std::__1::__function::__value_func<void (facebook::react::JSExecutor*)>::operator()[abi:ue170006](facebook::react::JSExecutor*&&) const <null> (RNTesterUnitTests:arm64+0x1abac9c)
https://github.com/facebook/react-native/issues/9 std::__1::function<void (facebook::react::JSExecutor*)>::operator()(facebook::react::JSExecutor*) const <null> (RNTesterUnitTests:arm64+0x1aba9d0)
https://github.com/facebook/react-native/issues/10 facebook::react::NativeToJsBridge::runOnExecutorQueue(std::__1::function<void (facebook::react::JSExecutor*)>&&)::$_8::operator()() const <null> (RNTesterUnitTests:arm64+0x1aba8d4)
https://github.com/facebook/react-native/issues/11 decltype(std::declval<facebook::react::NativeToJsBridge::runOnExecutorQueue(std::__1::function<void (facebook::react::JSExecutor*)>&&)::$_8&>()()) std::__1::__invoke[abi:ue170006]<facebook::react::NativeToJsBridge::runOnExecutorQueue(std::__1::function<void (facebook::react::JSExecutor*)>&&)::$_8&>(facebook::react::NativeToJsBridge::runOnExecutorQueue(std::__1::function<void (facebook::react::JSExecutor*)>&&)::$_8&) <null> (RNTesterUnitTests:arm64+0x1aba6d4)
https://github.com/facebook/react-native/issues/12 void std::__1::__invoke_void_return_wrapper<void, true>::__call[abi:ue170006]<facebook::react::NativeToJsBridge::runOnExecutorQueue(std::__1::function<void (facebook::react::JSExecutor*)>&&)::$_8&>(facebook::react::NativeToJsBridge::runOnExecutorQueue(std::__1::function<void (facebook::react::JSExecutor*)>&&)::$_8&) <null> (RNTesterUnitTests:arm64+0x1aba4f8)
https://github.com/facebook/react-native/issues/13 std::__1::__function::__alloc_func<facebook::react::NativeToJsBridge::runOnExecutorQueue(std::__1::function<void (facebook::react::JSExecutor*)>&&)::$_8, std::__1::allocator<facebook::react::NativeToJsBridge::runOnExecutorQueue(std::__1::function<void (facebook::react::JSExecutor*)>&&)::$_8>, void ()>::operator()[abi:ue170006]() <null> (RNTesterUnitTests:arm64+0x1aba45c)
https://github.com/facebook/react-native/issues/14 std::__1::__function::__func<facebook::react::NativeToJsBridge::runOnExecutorQueue(std::__1::function<void (facebook::react::JSExecutor*)>&&)::$_8, std::__1::allocator<facebook::react::NativeToJsBridge::runOnExecutorQueue(std::__1::function<void (facebook::react::JSExecutor*)>&&)::$_8>, void ()>::operator()() <null> (RNTesterUnitTests:arm64+0x1ab4918)
https://github.com/facebook/react-native/issues/15 std::__1::__function::__value_func<void ()>::operator()[abi:ue170006]() const <null> (RNTesterUnitTests:arm64+0x3ce2e4)
https://github.com/facebook/react-native/issues/16 std::__1::function<void ()>::operator()() const <null> (RNTesterUnitTests:arm64+0x3cdfd0)
https://github.com/facebook/react-native/issues/17 facebook::react::tryAndReturnError(std::__1::function<void ()> const&) <null> (RNTesterUnitTests:arm64+0x4af18c)
https://github.com/facebook/react-native/issues/18 facebook::react::RCTMessageThread::tryFunc(std::__1::function<void ()> const&) <null> (RNTesterUnitTests:arm64+0x51595c)
https://github.com/facebook/react-native/issues/19 facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1::operator()() const <null> (RNTesterUnitTests:arm64+0x529df0)
https://github.com/facebook/react-native/issues/20 decltype(std::declval<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1&>()()) std::__1::__invoke[abi:ue170006]<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1&>(facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1&) <null> (RNTesterUnitTests:arm64+0x529b54)
https://github.com/facebook/react-native/issues/21 void std::__1::__invoke_void_return_wrapper<void, true>::__call[abi:ue170006]<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1&>(facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1&) <null> (RNTesterUnitTests:arm64+0x529978)
https://github.com/facebook/react-native/issues/22 std::__1::__function::__alloc_func<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1, std::__1::allocator<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1>, void ()>::operator()[abi:ue170006]() <null> (RNTesterUnitTests:arm64+0x5298dc)
https://github.com/facebook/react-native/issues/23 std::__1::__function::__func<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1, std::__1::allocator<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1>, void ()>::operator()() <null> (RNTesterUnitTests:arm64+0x524518)
https://github.com/facebook/react-native/issues/24 std::__1::__function::__value_func<void ()>::operator()[abi:ue170006]() const <null> (RNTesterUnitTests:arm64+0x3ce2e4)
https://github.com/facebook/react-native/issues/25 std::__1::function<void ()>::operator()() const <null> (RNTesterUnitTests:arm64+0x3cdfd0)
https://github.com/facebook/react-native/issues/26 invocation function for block in facebook::react::RCTMessageThread::runAsync(std::__1::function<void ()>) <null> (RNTesterUnitTests:arm64+0x515384)
https://github.com/facebook/react-native/issues/27 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ <null> (CoreFoundation:arm64+0x8dc0c)
https://github.com/facebook/react-native/issues/28 __NSThread__start__ <null> (Foundation:arm64+0x645c60)
Previous write of size 8 at 0x00011a602690 by main thread:
#0 std::__1::__function::__value_func<void (facebook::react::ReactMarker::ReactMarkerId, char const*)>::swap[abi:ue170006](std::__1::__function::__value_func<void (facebook::react::ReactMarker::ReactMarkerId, char const*)>&) <null> (RNTesterUnitTests:arm64+0x43b078)
https://github.com/facebook/react-native/issues/1 std::__1::function<void (facebook::react::ReactMarker::ReactMarkerId, char const*)>::swap(std::__1::function<void (facebook::react::ReactMarker::ReactMarkerId, char const*)>&) <null> (RNTesterUnitTests:arm64+0x433100)
https://github.com/facebook/react-native/issues/2 std::__1::function<void (facebook::react::ReactMarker::ReactMarkerId, char const*)>& std::__1::function<void (facebook::react::ReactMarker::ReactMarkerId, char const*)>::operator=<registerPerformanceLoggerHooks(RCTPerformanceLogger*)::$_1, void>(registerPerformanceLoggerHooks(RCTPerformanceLogger*)::$_1&&) <null> (RNTesterUnitTests:arm64+0x432d50)
https://github.com/facebook/react-native/issues/3 registerPerformanceLoggerHooks(RCTPerformanceLogger*) <null> (RNTesterUnitTests:arm64+0x4170fc)
https://github.com/facebook/react-native/issues/4 -[RCTCxxBridge initWithParentBridge:] <null> (RNTesterUnitTests:arm64+0x416504)
https://github.com/facebook/react-native/issues/5 -[RCTBridge setUp] <null> (RNTesterUnitTests:arm64+0x3bf6f4)
https://github.com/facebook/react-native/issues/6 -[RCTBridge initWithDelegate:bundleURL:moduleProvider:launchOptions:] <null> (RNTesterUnitTests:arm64+0x3bc540)
https://github.com/facebook/react-native/issues/7 -[RCTBridge initWithBundleURL:moduleProvider:launchOptions:] <null> (RNTesterUnitTests:arm64+0x3bc124)
https://github.com/facebook/react-native/issues/8 -[RCTImageLoaderTests testImageLoaderUsesImageURLLoaderWithHighestPriority] <null> (RNTesterUnitTests:arm64+0x7de8)
https://github.com/facebook/react-native/issues/9 __invoking___ <null> (CoreFoundation:arm64+0x13371c)
Location is global 'facebook::react::ReactMarker::logTaggedMarkerImpl' at 0x00011a602678 (RNTesterUnitTests+0x438a690)
Thread T34 (tid=11229216, running) created by main thread at:
#0 pthread_create <null> (libclang_rt.tsan_iossim_dynamic.dylib:arm64+0x2bee4)
https://github.com/facebook/react-native/issues/1 -[NSThread startAndReturnError:] <null> (Foundation:arm64+0x6458f0)
https://github.com/facebook/react-native/issues/2 -[RCTBridge setUp] <null> (RNTesterUnitTests:arm64+0x3bf748)
https://github.com/facebook/react-native/issues/3 -[RCTBridge initWithDelegate:bundleURL:moduleProvider:launchOptions:] <null> (RNTesterUnitTests:arm64+0x3bc540)
https://github.com/facebook/react-native/issues/4 -[RCTBridge initWithBundleURL:moduleProvider:launchOptions:] <null> (RNTesterUnitTests:arm64+0x3bc124)
https://github.com/facebook/react-native/issues/5 -[RCTImageLoaderTests testImageLoaderUsesImageDecoderWithHighestPriority] <null> (RNTesterUnitTests:arm64+0xbe8c)
https://github.com/facebook/react-native/issues/6 __invoking___ <null> (CoreFoundation:arm64+0x13371c)
```
The proposed solution is to wrap `logTaggedMarkerImpl` in a class that has a static getter and setter wherein a read/write lock is employed. It is my understanding that `logTaggedMarkerImpl` is read several times, but only assigned rarely, and thus it seems appropriate with a read/write lock. The getter and setter functions are also inlineable, such that one should not need to make an extra function call when obtaining the `logTaggedMarkerImpl` instance.
In order to reproduce my findings and verify fix:
* Clone this branch
* Run setup code as described in README
* Execute `git revert -n 65998835c2198b9d626160a6883744801fa056a9 83a2a3c9b4e5ea588a6cc3a9281ad385a388b84a`
* Enable TSan for both `RNTester` and its test scheme.
* Enable Runtime issue breakpoint for TSan
* Run unit tests
* Observe the `TSan` breakpoint is hit (possibly other places in the codebase as well) when accessing `logTaggedMarkerImpl`. Continue execution if other breakpoints are hit before this breakpoint.
* Execute `git revert --abort`
* Run the tests again and observe the `TSan` breakpoint does _not_ hit said code again.
## Changelog:
[iOS][Fixed] Data race related to read/write on `ReactMarker::logTaggedMarkerImpl`
Pull Request resolved: https://github.com/facebook/react-native/pull/45557
Test Plan: I believe there are existing tests that will cover the proposed changes.
Reviewed By: cipolleschi
Differential Revision: D60525080
Pulled By: dmytrorykun
fbshipit-source-id: 78b0ce2a660af0e29909ff68c018698a9a1e29f8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45837
Some Internal tests in the old architecture were failing after landing [#45414](https://github.com/facebook/react-native/pull/45414) because the `RCTNativeAnimatedModule` in the old architecture was not declaring the event.
This change fixes it by declaring the event that is never fired in the Old Architecture as it is not needed.
## Changelog
[iOS][Added] - Declare the `onUserDrivenAnimationEnded` in the old Architecture
Reviewed By: sammy-SC
Differential Revision: D60499584
fbshipit-source-id: 581a30a88dbd6d8d67078a11699157c55ed19e58
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45839
Pull Request resolved: https://github.com/facebook/react-native/pull/45414
This change completes the fix for broken pressable when animations were applied to components with native driven animations.
When creating the AnimatedProps, if they are natively drive animation, we look for the AnimatedValue involved and we register a listener. This is needed to make sure that the NativeModule will send te updated value upon calling the `update` function.
Then, when observing the props lifecycle, it register a listener to the new `OnUserAnimationEnded` event, fired by the NativeAnimation module.
When the `OnUserAnimationEnded` event is fired, the AnimatedProps will update the props that depends on the user driven animation.
## Changelog
[General][Fixed] - reallign the shadow tree and the native tree when the user finishes interacting with the app.
Reviewed By: sammy-SC
Differential Revision: D60499583
fbshipit-source-id: 02d25e7ca31b91f4d6e4ec1654350e2d84117eda
Summary:
Fixes this issue: https://github.com/facebook/react-native/issues/45880
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID] [CHANGED] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID] [CHANGED] - Replaced `mLastHeight` with `mVisibleViewArea.height()` since mLastHeight value is not getting updated. For `width` we are already using `mVisibleViewArea.width()`
Pull Request resolved: https://github.com/facebook/react-native/pull/45928
Test Plan: - Tested the fix in new and old architecture both
Reviewed By: christophpurrer
Differential Revision: D61023998
Pulled By: cortinico
fbshipit-source-id: df67616330effb7b9e6724d94b3be92c0dbd6190
Summary:
React-native 0.75 RC7 gradle sync is currently broken due to the fact that the `shared-testutil` folder is missing from the `react-native/gradle-plugin` npm package
## Changelog:
[INTERNAL] [ADDED] - Add shared-testutil folder to NPM files to be published
Pull Request resolved: https://github.com/facebook/react-native/pull/45936
Test Plan: N/A
Reviewed By: cipolleschi
Differential Revision: D60969631
Pulled By: cortinico
fbshipit-source-id: 850edfe0cf6b0e8174a1df9ea962d207d2ce0112
Summary:
This PR implements the missing `automicallyAdjustsKeyboardInsets` for new architecture. It's a fixed version of reverted: https://github.com/facebook/react-native/issues/45819
We now check if the view intersects with the keyboard's end frame and if it doesn't we just do nothing.
Here is the app running on new arch:
https://github.com/user-attachments/assets/673f0587-6a67-47e3-8050-d6ee33a45724
## Changelog:
[IOS] [FIXED] - implement automicallyAdjustsKeyboardInsets for new arch
Pull Request resolved: https://github.com/facebook/react-native/pull/45939
Test Plan:
1. Test out ScrollViewKeyboardInsets example
2. See if it works the same with old and new arch
Reviewed By: cortinico
Differential Revision: D60958475
Pulled By: cipolleschi
fbshipit-source-id: 8650064af84bc79b6b89e07293640e5d010154c2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45946
This code is forked on iOS, where we have been, as a policy, avoiding Paper-specific changes. This code is shared between renderers on Android, but it is confusing developer experience to have it work on Android Paper, to then fail on iOS unless it is on new arch.
This change disables support on Android Paper for consistency.
Changelog:
[Android][Removed] - Gate off % translate on Android Paper
Reviewed By: joevilches
Differential Revision: D60970266
fbshipit-source-id: 5df73b948464f5093941528b0af2e694827a9460
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45948
This change effectively reverts D59489788 which fixed Image implementation of `hasOverlappingRendering()`. When this is true, Android will draw offscreen, then composite the rasterized layer with alpha in one pass, instead of drawing each element with alpha (which results in incorrect rendering).
The unforseen downside is that this prevents drawing overflow, which means images with non-full opacity break box shadows and outline in the future.
This deserves a fuller fix... but in the meantime, I discovered we disable offscreen alpha in many of the core components already, with `<View>` as a major example requiring explicit opt-in. This is... kinda terrible, since `opacity` rendering is pretty broken on RN Android, but the status quo lets us avoid a pretty bad boxShadow bug for now.
Changelog:
[Android][Changed] - Avoid image ofscreen render
Reviewed By: Abbondanzo
Differential Revision: D60972846
fbshipit-source-id: 403714d6bb0527a7426feba3dafee05b6aefbb7d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45950
Changelog:
[iOS][Deprecated] Deprecated StatusBar.setNetworkActivityIndicatorVisible
The status bar network activity indicator is deprecated in iOS 13. Setting its visibility has no effect in iOS 13 and later. It will be completely removed in a future release.
Reviewed By: philIip
Differential Revision: D60977517
fbshipit-source-id: 31e79113fffd0201c4393b61236d3911e82b40d1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45805
After recent changes where we dive into paths ourselves, we really don't have a good reason to use the heavy CSSBackgroundDrawable. Accept a box shadow style in place of a reference to the original drawable, and then draw using calculated round rect path instead of new whole Drawable. This lets us avoid a lot of conversions as well (with the last diff already removing some).
This should also resolve a crash we started seeing:
```
androidx.core.util.Preconditions.checkNotNull (Preconditions.java:136) [inlined]
- com.facebook.react.uimanager.drawable.CSSBackgroundDrawable.drawRoundedBackgroundWithBorders (CSSBackgroundDrawable.java:386)
[inlined]
- com.facebook.react.uimanager.drawable.CSSBackgroundDrawable.draw (CSSBackgroundDrawable.java:142)
- com.facebook.react.uimanager.drawable.OutsetBoxShadowDrawable.draw (OutsetBoxShadowDrawable.kt:137)
- android.graphics.drawable.LayerDrawable.draw (LayerDrawable.java:1019)
```
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D60401423
fbshipit-source-id: 693d9bf5e85956290db932cdb18f15ba26446894
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45945
This code is forked on iOS, where we have been, as a policy, avoiding Paper-specific changes. This code is shared between renderers on Android, but it is confusing developer experience to have it work on Android Paper, to then fail on iOS unless it is on new arch.
This change disables support on Android Paper for consistency.
Changelog:
[Android][Removed] - Gate off % border radii on Android Paper
Reviewed By: cortinico
Differential Revision: D60967347
fbshipit-source-id: 1d26bc71aee677aa9a0dc9bb38f781a99c7762a8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45783
Improves type strictness in the `react-native` package.
- Break out `URLSearchParams` from `URL.js` into its own module, to isolate a `$FlowFixMe[unsupported-syntax]` suppression within that definition.
- Update `public-api-test` to require an adjacent `<module>.js.flow` type definition file whenever a `$FlowFixMe[unsupported-syntax]`is present.
- Add `URLSearchParams.js.flow` with a Flow parser compatible typedef (`@iterator` instead of `[Symbol.iterator]`).
The result of these changes is to add missing typedef test coverage for `Libraries/Blob/URL.js` (see updated test snapshots).
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D60376327
fbshipit-source-id: 93c0949289a4b53f621f563769ffb68d5dc38d91
Summary:
This PR fixes Cache repear
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
[INTERNAL] [FIXED] - Cache repear job
Pull Request resolved: https://github.com/facebook/react-native/pull/45943
Test Plan: CI Green
Reviewed By: blakef
Differential Revision: D60962822
Pulled By: cortinico
fbshipit-source-id: 453153005bbc1b99dbe569eb6be77d17c8a176db
Summary:
Added a check in setRemoteJSDebugEnabled in DevSupportManagerBase.java to check for PREFS_REMOTE_JS_DEBUG_KEY to see if the value has changed.
Fix for https://github.com/facebook/react-native/issues/45399 - App restarting when `NativeDevSettings.setIsDebuggingRemotely` is used in a landing component. If this was invoked from a component load or action that would fire on app start, it was creating an infinite loop where the app would keep on restart before eventually leading to a crash.
## Changelog:
[ANDROID] [FIXED] - Fix issue with `NativeDevSettings.setIsDebuggingRemotely` where the app would keep on restarting if remote debugging was invoked from an action / component that was called on app start.
Pull Request resolved: https://github.com/facebook/react-native/pull/45775
Test Plan:
Create a new project using RN CLI.
Set `newArchEnabled=false`.�
Install modules using `yarn install`.�
Build from source for Android by setting the following in `settings.gradle`-�
```
includeBuild('../node_modules/react-native') {
dependencySubstitution {
substitute(module("com.facebook.react:react-android")).using(project(":packages:react-native:ReactAndroid"))
substitute(module("com.facebook.react:react-native")).using(project(":packages:react-native:ReactAndroid"))
substitute(module("com.facebook.react:hermes-android")).using(project(":packages:react-native:ReactAndroid:hermes-engine"))
substitute(module("com.facebook.react:hermes-engine")).using(project(":packages:react-native:ReactAndroid:hermes-engine"))
}
}
```
Set the ANDROID_HOME and ANDROID_NDK_HOME environment variables required for react native.�Call `NativeDevSettings.setIsDebuggingRemotely` from App.tsx which is the landing component.�
Test with both `hermesEnabled=true` and `hermesEnabled=false` and ensure that app does not keep on restarting after fix.
Reviewed By: cipolleschi
Differential Revision: D60377406
Pulled By: huntie
fbshipit-source-id: c8faf184b50b67f50f8a4b6851df9d0ef3350949
Summary:
This diff sets up an experiment to use `useDebouncedEffect` for managing animated props lifecycle.
Changelog: [Internal]
bypass-github-export-checks
Facebook
This diff also defaults to `useDebouncedEffect` for managing animated props lifecycle in IGVR and FBVR.
Based on local tracing of FBVR, `useDebouncedEffect` results in **~19ms faster visual completion**.
Before we executed **54.2 ms** of passive effects vs **35.6 ms** after.
Reviewed By: josephsavona, rubennorte
Differential Revision: D60834116
fbshipit-source-id: 35d5eb4c4be18e716f96129911e66eaffe54bb17
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45941
Quick fix to avoid imports from Swift chaining to Objective-C++ headers. Will follow up with a redesign.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D60960077
fbshipit-source-id: 4ce9507900196d5298c7885a99a5e4d786f76982
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45930
This introduces the `enableEventEmitterRetentionDuringGesturesOnAndroid` that allows us to gate the
fix for bug #45126 and #44610.
Changelog:
[Internal] [Changed] - Introduce the enableEventEmitterRetentionDuringGesturesOnAndroid to gate the Pressable fix
Reviewed By: mdvacca
Differential Revision: D60908117
fbshipit-source-id: 885917832718d9b90d043b2d7e2cdb47e0f01ea7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45865
This diff introduces the logic to defer the destruction of ViewState (and EventEmitter) for views that are currently touched on by the user. The idea is to let the UIManager know which view is currently active from the `JSTouchDispatcher` and eventually defer the view deletion till the view is not interacted anymore.
The JSTouchDispatcher already retains the information on which tag was the touch originally fired.
We'll pass over that information to the UIManager/SurfaceMountingManager so that it can be accounted for when the view has to be deleted.
This is causing a couple of bad bugs on Android:
Fixes https://github.com/facebook/react-native/issues/45126
Fixes https://github.com/facebook/react-native/issues/44610
Closes https://github.com/facebook/react-native/pull/45675
Changelog:
[Android] [Fixed] - Do not destroy views when there is a touch going on for New Architecture
Reviewed By: mdvacca
Differential Revision: D60594878
fbshipit-source-id: c3334d16cf305e0178f50772576050ebfbba85ec
Summary:
This PR enables the `cache-repear.yml` only for the main repository. This is running constantly on forks creating lots of notifications and it's mostly needed only for the main repo.

## Changelog:
[INTERNAL] [CHANGED] - Run `cache-repear.yml` only on main repo
Pull Request resolved: https://github.com/facebook/react-native/pull/45940
Test Plan: CI GREEN
Reviewed By: blakef
Differential Revision: D60957003
Pulled By: cortinico
fbshipit-source-id: 2f250d734688739a278095af8d860a54426604bf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45922
Introduce the ReactNativeNewArchitectureFeatureFlagsDefaults class, which initializes default values for ReactNativeFeatureFlags when the New architecture is enabled.
This class is meant to be overrode by ReactNativeNewArchitectureFeatureFlagsDefaults or others apps migrating to the new architecture.
changelog: [internal] internal
Reviewed By: philIip
Differential Revision: D60861873
fbshipit-source-id: b31ba947dae999fea8bb4effd63c56dc142a5c3d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45934
The OSS impl of gradient was wrong, and ends up skipping shadows if it is not defined. Fixed that.
Changelog: [Internal]
Reviewed By: jorge-cab
Differential Revision: D60917620
fbshipit-source-id: 3d4ea3e8084d33fa5d15fb82d45cfd063143087c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45850
Enables the `nativeSourceCodeFetching` capability flag for the modern debugger stack on both Android and iOS. This disables source code fetching hacks within the Inspector Proxy layer and instead enables the debugger server to handle all source code fetching directly on the device.
Changelog: [Internal]
Differential Revision: D60236216
fbshipit-source-id: 1239b4d7d2233852f007114721b202d90459fa06
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45849
This fixes a bug where we were calling `delegate.didReceiveMessage` (and other handlers) from multiple threads on Android. In particular, with the addition of `Network.loadNetworkResource` in D54496969, we observed memory access issues in the implementation for `IO.read` in `NetworkIOAgent` after multiple successive requests are received.
This approach updates the Android-specific implementation of `IWebSocketDelegate` to schedule delegate handler and `close` calls on the inspector thread.
Changelog: [Internal]
Differential Revision: D60520747
fbshipit-source-id: 459b44b424157793faaf5967435e1303a0061292
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45664
Implement the `networkRequest` method of `jsinspector_modern::HostTargetDelegate` for Android (Bridge). This diff introduces a common `InspectorNetworkHelper` class that will be shared for the Bridgeless implementation.
This change allows the modern debugger server to handle CDP `Network.loadNetworkResource` (etc) requests. Notably, resources in the Chrome DevTools Sources panel will now be loaded by the backend.
Changelog: [Internal]
Differential Revision: D60036502
fbshipit-source-id: 5fdca7f34634c7541395041025bef62ddfad9eab
Summary:
This diff introduces the `useDebouncedEffect` hook. It should be used for expensive effects that can be scheduled asynchronously, not blocking the rendering.
Changelog: [Internal]
bypass-github-export-checks
Facebook
This a copy of https://www.internalfb.com/code/fbsource/xplat/js/RKJSModules/public/xplat-react/shared/core/react_hooks/DebouncedEffectImplementation.js
I put it here temporarily to be able to run an experiment with `Animated`. We should come up with a better way to introduce this hook to OSS.
I'm bypassing GH export to not to draw extra attention to this.
Reviewed By: rubennorte
Differential Revision: D60762745
fbshipit-source-id: c13b20424360493a7fc94dc27264591a7253f77f
Summary:
Building for the visionOS simulator in the Release scheme requires an x86_64 slice to be included.

## Changelog:
[IOS] [FIXED] - Include x86_64 slice when building for visionOS simulator
Pull Request resolved: https://github.com/facebook/react-native/pull/45911
Test Plan: CI Green
Reviewed By: GijsWeterings
Differential Revision: D60828872
Pulled By: cipolleschi
fbshipit-source-id: 74444ac0b6661baf427837d242ba0ca295da0d16
Summary:
This PR fixes few issues with Hermes scripts:
- Set visionOS vendored frameworks
- Fail if env variables are not set
## Changelog:
[INTERNAL] [FIXED] - Hermes script should fail when no deployment target is set
Pull Request resolved: https://github.com/facebook/react-native/pull/45841
Test Plan: Try to build Hermes
Reviewed By: blakef
Differential Revision: D60901886
Pulled By: cipolleschi
fbshipit-source-id: b9ff470ac6c07e1bd5abc7410ac0c366d66016c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45878
Changelog:
[General][Added] - Add optional `PackagerAsset.resolver` prop so AssetSourceResolver can use it instead of `Platform.OS` to identify where asset is stored on device.
Reviewed By: rshest
Differential Revision: D60447815
fbshipit-source-id: 44fb8510746905ca0cd266144e213c40a3fa86a9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45917
Did this the right way for BorderStyle, but not for Overflow.
Changelog:
[Android][Fixed] - Gracefully handle unexpected overlow values
Reviewed By: necolas
Differential Revision: D60853891
fbshipit-source-id: e641e62e9e301681a1be190d8158f793ec17c1f5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45860
This has been on by default for a long while.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D60579198
fbshipit-source-id: 4bd8a13dada8edf00489dc64b1ff4ff0364a8843
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45918
In this diff we are deprecating ReactFeatureFlags.enableBridgelessArchitecture, this flag will be deleted in the next version of ReactNative (0.77)
Please use DefaultNewArchitectureEntryPoint.load() to enable TurboModules.
changelog: [Android][Deprecated] deprecate ReactFeatureFlags.enableBridgelessArchitecture
Reviewed By: philIip
Differential Revision: D60853317
fbshipit-source-id: 2476bb81887893cedc8d43b117c10cd9d96bdee3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45920
In this diff we are deprecating ReactFeatureFlags.useTurboModules, this flag will be deleted in the next version of ReactNative (0.77)
Please use DefaultNewArchitectureEntryPoint.load() to enable TurboModules.
changelog: [Android][Deprecated] deprecate ReactFeatureFlags.useTurboModules
Reviewed By: philIip
Differential Revision: D60853315
fbshipit-source-id: 084ef8073daae16b288d82ececf770fd4b68e80c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45921
In this diff we are deprecating ReactFeatureFlags.enableFabricRenderer, this flag will be deleted in the next version of ReactNative (0.77)
Please use DefaultNewArchitectureEntryPoint.load() to enable fabric instead.
changelog: [Android][Deprecated] deprecate ReactFeatureFlags.enableFabricRenderer
Reviewed By: philIip
Differential Revision: D60853316
fbshipit-source-id: f9883a68771c8db8f24269630b0950e96741cf9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45905
- Updating minSdk to 24 before we do the update for the RN
Changelog: [Internal]
Reviewed By: blakef
Differential Revision: D60788291
fbshipit-source-id: d21d766159a04d79547e64fca802600279d08255
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45916
When a Filter was removed by state update we missed this check which led to setting the layer type to HARDWARE incorrectly
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D60840169
fbshipit-source-id: e375e7d25c85e9d031c1e1a0795c49687e0018e7
Summary:
- Adds `background` prop that supports CSS's linear gradient. Later this can be extended to support various other gradients and possibly CSS's background image (less motivation as better solutions exists for image)
- Uses `CAGradientlayer` to draw Linear Gradient layers. So it is GPU optimised under the hood.
- Style supports JS object to specify `LinearGradient`, so it can support Animated libraries.
## Changelog:
[IOS] [ADDED] - linear gradient
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/45434
Test Plan:
- Check out `processBackground-test.js` for supported syntax testcases.
- Checkout example added in ViewExample.js
Although the PR is tested well but open to any changes/feedback on the approach taken.
Android PR - https://github.com/facebook/react-native/pull/45433. Separated the PRs to keep it easier to review. Both PRs can be reviewed individually.
Reviewed By: NickGerleman
Differential Revision: D60791581
Pulled By: joevilches
fbshipit-source-id: 051088fdf68d9fe20c0c306f1f1c591cbd77f3d5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45915
We avoid recomputing the RenderNode display list for shadow shape when the inputs have not changed, but Android may clear the display list itself, in which case we need to recreate it.
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D60833553
fbshipit-source-id: fe1ea04b13f85dda6af2761693e7c664794235e1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45913
Changelog: [Internal] - Call ViewManagers' onSurfaceStopped() before onDropViewInstance()
This allows `ViewManager` to call `mRecyclableViews.remove(surfaceId)` before it wastes time on `prepareToRecycleView()` for views in a stopped surface.
Reviewed By: sammy-SC
Differential Revision: D60806242
fbshipit-source-id: d5eaaa5443fcb1d9390d8b84e0b5069618bb175e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45885
There are some gaps here right now, but Android API 31+ is looking good.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D60731848
fbshipit-source-id: f515270a61a00c362b584f0d1549d14098c2e385
Summary:
In build_npm_package, the publishing of the bumped template is [failing](https://github.com/facebook/react-native/actions/runs/10148492447/job/28063424722)
because it's running in sh instead of bash, but using bash syntax.
## Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/45910
Test Plan:
~~I'm unclear on how to test this, and the fix is very much speculative based on other having hit a similar issue.~~
I've had to stub some of the values that the action substitutes.
Reviewed By: cortinico
Differential Revision: D60828697
Pulled By: blakef
fbshipit-source-id: 0a8f909ae5219268f034e5ff0efb8acc94bdb7b1
Summary:
We had CI on main failing consistently the past couple of days.
The problem is that the hermes pipeline is failing to create the iOS XCFramework with the error:
> unable to create a Mach-O from the binary at '/Users/runner/work/react-native/react-native/packages/react-native/sdks/hermes/destroot/Library/Frameworks/catalyst/hermes.framework/hermes'
The main cause is this upgrade of [upload-artifacts](https://github.com/actions/upload-artifact/issues/590) which breaks symlinks.
The solution is to bump the caches and downgrade the `upload-artifact` actions.
## Changelog:
[Internal] - Try to fix CI for Hermes
Pull Request resolved: https://github.com/facebook/react-native/pull/45908
Test Plan: GHA must be green
Reviewed By: cortinico
Differential Revision: D60828616
Pulled By: cipolleschi
fbshipit-source-id: 6976b86dd67e2fd9d806ebaa62f47e39dc44b30d
Summary:
Last month, during the migration to GHA, we decided to reimplement the same behavior we had in CCI: when a new commit comes in, we stop executing tests on the previous one.
This behavior is great to save money, but on main it has the side effect that it makes it hard to detect when the ci was broken.
\With this change, we want to disable this behvior on main while keeping it in PRs.
After this change, when a new commit arrives on main, the previous jobs will not be interrupted
## Changelog
[Internal] - Do not cancel jobs on main when new commits are pushed.
Reviewed By: cortinico, blakef
Differential Revision: D60822657
fbshipit-source-id: 38561438f2e2850a94220d732cd73a09d04e8b81
Summary:
This PR implements the missing `automicallyAdjustsKeyboardInsets` for new architecture.
After fixing this I've noticed there is an open issue (https://github.com/facebook/react-native/issues/45647) with somebody assigned (sorry shubhamguptadream11 for taking your task)
Here is the app running on new arch:
https://github.com/user-attachments/assets/673f0587-6a67-47e3-8050-d6ee33a45724
## Changelog:
[IOS] [FIXED] - implement automicallyAdjustsKeyboardInsets for new arch
Pull Request resolved: https://github.com/facebook/react-native/pull/45819
Test Plan:
1. Test out ScrollViewKeyboardInsets example
2. See if it works the same with old and new arch
Reviewed By: sammy-SC
Differential Revision: D60453404
Pulled By: cipolleschi
fbshipit-source-id: bd7ce5bac8facffc527106b50c54112acf687bc3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45846
In general this diff fixes all crashes related to RTCImageUtills happened because of uncovered cases in switch.
In this current bug the problem was in this part of code
RCTTargetSize(imageSize, imageScale, frame.size, RCTScreenScale(), (RCTResizeMode)self.contentMode, YES);
when we cast UIViewContentMode to RCTResizeMode. RCTResizeMode doesnt cover all of UIViewContentMode values.
So just added default cases to swithces in places where it was lost.
Changelog:
[iOS][Fixed] - fixed crash in RCTImageUtils
Reviewed By: philIip
Differential Revision: D60523540
fbshipit-source-id: b8027537c600a7ca226e62238d16a6b05301d4de
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45900
Changelog: [internal]
make `normalizeEventType` public, it looks like a nice util when we want to write code to intercept event, e.g. "scroll" event could be named as "onScroll" or "topScroll", this function contains the source of truth of how RN parses it
Reviewed By: christophpurrer
Differential Revision: D60767388
fbshipit-source-id: b3880fda57e2d92d9d199db5f5d39b8a8435820c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45899
Changelog: [internal]
replace ScrollViewEventEmitter::Metrics for ScrollEvent payload type created earlier
make ScrollViewEventEmitter::Metrics an alias of ScrollEvent as well
Reviewed By: christophpurrer
Differential Revision: D60767390
fbshipit-source-id: 8db88c0e1fa837b5dbad92d7bcce825882feaaf6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45851
Create ScrollEvent payload type, so we can unwrap the scroll event metrics if intercept it in C++
Changelog: [internal]
Reviewed By: christophpurrer
Differential Revision: D60526048
fbshipit-source-id: 219a690ccf67d0b1c90e3496b8e5970ab7e2a79b
Summary:
For the ones where `React.MixedElement` would suffice, I change them to `React.MixedElement`. For everything else, I changed it to be `React.Element`
Changelog: [Internal]
Reviewed By: gkz
Differential Revision: D60798229
fbshipit-source-id: 40176b44769aade2c6b63a680d03c10056b2ddfa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45904
Flow will error on these dollar types soon. For all the ones changed here, they can all be further simplified.
Changelog: [Internal]
Reviewed By: gkz
Differential Revision: D60786768
fbshipit-source-id: e26bf0be1c4a933fc0bd8b59827e10cbd7242a83
Summary:
Adds changelog for the 0.74.5 patch.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Add 0.74.5 changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/45898
Reviewed By: christophpurrer
Differential Revision: D60768626
Pulled By: arushikesarwani94
fbshipit-source-id: 62196fc8a4fec1ff992ecc4622116b97dd96b79b
Summary:
I introduced a typo in https://github.com/facebook/react-native/issues/45486 . Thanks migueldaipre
for the catch-up. cc cipolleschi
## Changelog:
[IOS] [FIXED] - Fixes typo of function callFunctionOnBufferedRumtimeExecutor
Pull Request resolved: https://github.com/facebook/react-native/pull/45902
Test Plan: Just a typo.
Reviewed By: cipolleschi
Differential Revision: D60775511
Pulled By: arushikesarwani94
fbshipit-source-id: da781ea5ecf2e0a15e5419430240e10194043b1b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45893
changelog: [internal]
This is mainly impact for the Event Loop where setting up of animation graph will no longer block paint.
Reviewed By: rubennorte
Differential Revision: D60648823
fbshipit-source-id: 8efa1dac2a42b14a609adae05e9266f78a181d43
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45877
A couple fixes:
- Test was mixing up event names - refactored to make the code [hopefully] clearer
- Code potentially recreates `events` if it's a singleton map, but that was lost due to it not being returned
Changelog: [Internal] Minor fix to UIManagerModuleConstantsHelper
Reviewed By: cortinico
Differential Revision: D60609294
fbshipit-source-id: 3c82ba30b9401674e678585b1612324f885c9ae1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45743
This is a Java-centric class that can be replaced by Kotlin's map extensions.
Changelog:
[Android][Deprecated] Deprecate MapBuilder
Reviewed By: cortinico
Differential Revision: D60309106
fbshipit-source-id: 4a764fa1d59993dc735b2181a2270dc79a0e0396
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44569
# Changelog:
[Internal] -
This converts the vertical of NativeArray/ReadableNativeArray/WritableNativeArray classes to Kotlin.
NOTE: the `getArray`, `getMap` and `getString` being annotated as `NonNull` in the Java code is a scam - there is no guarantee that native side will send non-null to the Java side, and in practice, indeed, in certain cases it doesn't. So I opted to make it nullable instead - this way it's at least explicit and is not a ticking bomb hidden to explode behind the false sense of security.
Reviewed By: javache
Differential Revision: D57327835
fbshipit-source-id: 1b546b2ff22af2be903fe6ab91f0148b645595fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45872
build_android is currently broken, this should fix it.
Changelog:
[Internal] [Changed] - Unbreak build_android by not depending on PreferenceManager from androidx
Reviewed By: cipolleschi, hezi
Differential Revision: D60652912
fbshipit-source-id: a089609c6643c40c95919fdc882a89406f6ce871
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44587
# Changelog:
[Internal] -
As in the title, moving towards migrating all the interfaces in react.bridge.
Reviewed By: tdn120
Differential Revision: D57433401
fbshipit-source-id: 35581d27d6d093edb1cc59b245e6468758825f68
Summary:
Issue: https://github.com/facebook/react-native/issues/45596
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [CHANGED] - Migrated `packages/gradle-plugin/react-native-gradle-plugin/src/test/kotlin/com/facebook/react/tasks/GenerateCodegenArtifactsTaskTest.kt` to assertj.
Pull Request resolved: https://github.com/facebook/react-native/pull/45845
Test Plan: Run `./gradlew -p packages/gradle-plugin test`
Reviewed By: hezi
Differential Revision: D60597025
Pulled By: cortinico
fbshipit-source-id: 4228b958c7b9e1506640b9ff217f098e2626ea81
Summary:
This re-applies D60495100 after I've fixed the history for `ReactImageView`.
bypass-github-export-checks
Changelog:
[Internal] [Changed] - Re-apply Use BackgroundStyleApplicator in View setters on ReactImageView.kt
Reviewed By: NickGerleman
Differential Revision: D60578453
fbshipit-source-id: 995f5e54ea6ca3161935e8b7814df390d827a463
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45866
This turns on enableBackgroundStyleApplicator() by default, which will get us more screenshot tests over existing apps, and let us add new screenshot tests for box-shadow against stock RNTester.
This is a breaking change, for the small number of libraries which use CSSBackgroundDrawable/ReactViewBackgroundDrawable off of a view directly, for setting or accessing styles (this was already unreliably), along with libraries which read `mBorderRadius` from views using reflection. This is more or less confined to Reanimated, react-native-navigation, and one internal library.
Users who want to access or mutate background styles should use the public `BackgroundStyleApplicator` instead.
Changelog:
[Android][Breaking] - Set "enableBackgroundStyleApplicator" by default
Reviewed By: joevilches
Differential Revision: D60365677
fbshipit-source-id: aab8588b27c1125920adb257406c53dadb356767
Summary:
In Android, when constructing a multipart body for a file and that file source is a uri (base64-encoded) we do the following:
1. Decode the base64 string into bytes
2. Create a bitmap object
3. Compress the bitmap object as PNG into new bytes
The process does an unnecessary work (bytes -> bitmap -> bytes) and creates unexpected results e.g. a GIF file will be converted into PNG when uploaded. This PR removes the unnecessary steps (2 and 3).
## Changelog:
[ANDROID] [FIXED] - Fix uploading GIF URI
Pull Request resolved: https://github.com/facebook/react-native/pull/45826
Test Plan:
1. Upload a GIF; use URI (base64-encoded)
2. Verify that the uploaded file is a GIF
```js
const formData = new FormData();
formData.append('photo', {
uri: GIFURI,
type: 'image/gif',
name: 'photo.gif',
});
fetch(UPLOAD_URL,
{
body: formData,
method: "POST",
}):
```
| Before | After |
|:------:|:-----:|
| <video src="https://github.com/user-attachments/assets/6ce4769a-8fa5-4d00-8066-9a1911608632" /> | <video src="https://github.com/user-attachments/assets/76a29d14-ce9d-48cd-94d0-7591064a5b1b" /> |
Reviewed By: cortinico
Differential Revision: D60515478
Pulled By: tdn120
fbshipit-source-id: d6ad1c42631c184c3dcdf3a956641e25d0c1b926
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45799
No idea how I missed this but I don't think `defaultProps` is a thing in React Native? So the images were not showing
Changelog: [internal]
Reviewed By: joevilches
Differential Revision: D60392853
fbshipit-source-id: 27280033fb719340a809053d6ca98ac3f178c8c3
Summary:
- Adds `background` prop that supports CSS's linear gradient. Later this can be extended to support various other gradients and possibly CSS's background image (less motivation as better solutions exists for image)
- Extended `CSSBackgroundDrawable` to draw Linear Gradient shader while preserving the border style support.
- Style supports JS object to specify `LinearGradient`, so it can support Animated libraries.
## Changelog:
[ANDROID] [ADDED] - linear gradient
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/45433
Test Plan:
- Check out `processBackground-test.js` for supported syntax testcases.
- Checkout examples added in `LinearGradientExample.js`
Although the PR is tested well but open to any changes/feedback on the approach taken.
iOS PR - https://github.com/facebook/react-native/pull/45433. Separated the PRs to keep it easier to review. Both PRs can be reviewed individually.
Reviewed By: joevilches
Differential Revision: D60493360
Pulled By: NickGerleman
fbshipit-source-id: 762929c4fe16d87cbbd9ebe83ecce96a9e13192c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45832
The main one! This allows box-shadow to be used in View, and uses BackgroundStyleApplicator (if flag is enabled) for background management.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D60491176
fbshipit-source-id: c068b1dc971253f1303de5bae62e42a9eceb0de6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45835
`ReactViewBackgroundManager` will do this for us (and otherwise doesn't do anything draw related), but this will be removed when BackgroundStyleApplicator is rolled out, and not all callers use `ReactViewBackgroundManager`.
Changelog:
[Android][Fixed]
Reviewed By: philIip
Differential Revision: D60489756
fbshipit-source-id: 37cfc2b90af057bc142ad95b93e32941edb17ca5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45834
These are very rarely called, outside of directly by the view manager, but they are still public, so we should make these work off the same composite drawable as the view managers (eventually BasrViewManager).
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D60495100
fbshipit-source-id: 90f51870dd9929d1f3657d8f5368ef46216c8544
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45854
Right now these border widths are incorporated into Yoga layout, but view manager never responds to it.
This adds the props supported by <View> to text, still missing many others. The underlying functions are aware of the spacing type,
I plan to fix this more thoroughly, across the different edges, properties, and different components, after we remove the legacy background stack, and all of these can live in a single place on BaseViewManager.
Changelog:
[Android][Fixed] - Add borderStartWidth and borderEndWidth support
Reviewed By: necolas
Differential Revision: D60560343
fbshipit-source-id: 8e1ebaa087e0728b5758850239c41aeae5d619a9
Summary:
Many `AccessibilityInfo` functions (`isReduceMotionEnabled`, `isBoldTextEnabled`, etc.) return promises, but the mocked versions of them in jest/setup.js aren't returning promises.
All of these functions live in [packages/react-native/Libraries/Components/AccessibilityInfo/AccessibilityInfo.js](https://github.com/facebook/react-native/blob/main/packages/react-native/Libraries/Components/AccessibilityInfo/AccessibilityInfo.js), where you can verify their return types are Promises.
When using `react-native/jest-preset` and running tests that utilize one of these functions, you'll get an error:
```
AccessibilityInfo.isReduceMotionEnabled().then() is not a function
```
https://github.com/facebook/react-native/pull/29381 was opened in 2020 but closed after becoming stale. My PR is nearly identical but covers additional Promise-returning functions that have been added to `AccessibilityInfo` since then.
## Changelog:
[GENERAL] [FIXED] - Update the react-native/jest-preset mock of AccessibilityInfo to better match its API
Pull Request resolved: https://github.com/facebook/react-native/pull/45825
Test Plan:
I've tested by making the change locally in my project's `node_modules/react-native/jest/setup.js` file and confirming that I no longer get an error when running this test:
```
it("should pass", async () => {
await AccessibilityInfo.isReduceMotionEnabled().then(enabled => {
expect(enabled).toBe(false);
});
});
```
Before:
```
TypeError: Cannot read properties of undefined (reading 'then')
16 |
17 | it.only("should pass", async () => {
> 18 | await AccessibilityInfo.isReduceMotionEnabled().then(enabled => {
| ^
19 | expect(enabled).toBe(false);
20 | });
21 | });
```
After: No type error, and test passes.
Reviewed By: robhogan
Differential Revision: D60519836
Pulled By: tdn120
fbshipit-source-id: 24fc77b0f9693e131686a0a45b81fbd33ff65f01
Summary:
Issue: https://github.com/facebook/react-native/issues/45596
## Changelog:
[INTERNAL] [CHANGED] - Migrate `BundleHermesCTaskTest.kt` to AssertJ testing library
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/45806
Test Plan: Run `./gradlew -p packages/gradle-plugin test`
Reviewed By: mdvacca
Differential Revision: D60522760
Pulled By: cortinico
fbshipit-source-id: f7847143d182b29e1bbbba738a0ddae9bf3ee59c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45746
Once the spread was past a certain value, it could break some of this logic by creating a null rect or negative size. This just makes it so that in those cases, inset will be a 0x0 clear region rect and outset will be nothing
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D60317780
fbshipit-source-id: 021bf41d71ae69809076b4f5e6413d04cd878372
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45681
This diff fixes 2 related issues that arise when we add a border to the view with box shadow
1) The shadow fills the padding box and not the border box. To fix this we just need to subtract the edge insets (border width) from both the shadow size and the clear region size. We also need to change the clipping area to clip anything outside the padding box
2) The corner radius of the clear region is based on the corner insets, so border radius - border width
The first change required a bit of thinking on my part to remember what bits of the crazy arithmetic here needed to change. So I refactored a bit:
* The general theme now is that all of the rects are derived from one another, and make use of CGRectOffset and CGRectInset to make their necessary adjustments.
* We introduce `shadowFrame` which is just the frame of the shadow area - agnostic of things like blur padding and offscreen shenanigans. So its the size of the layer insetted by the border widths.
* From this we can derive our 2 offscreen rects. The `shadowCastingRect` outsets the shadow frame by the blurRadius, while the `clearRegionRect` insets by spread distance. We then use `CGRectOffset` to push it offscreen. We save this offset so we can use it later to get the CG shadow back in place (since this is all originally derived from `shadowFrame`.
* There is now a single place that dictates the size of the shadow (`shadowFrame`), and a single place that dictates the offset to push our rects offscreen. The necessary change to trace padding box and not content box therefore just needs to change `shadowFrame` as opposed to 4 other spots.
* Additionally, when we offset, we do not need to worry about things like spread and blur, since `CGRectInset` takes care of that along with the size
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D60201959
fbshipit-source-id: 4ecf0e0db8ce9d54f08e89adec94d50eb19a26a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45679
`cornerRadiiForBoxShadow(cornerRadii, 0)` no-ops since there is no spread, and it returns the same type as it takes as an input, so there is no point for this complexity
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D60203620
fbshipit-source-id: c1f86ce6e8fef07365ab57caa3e906f1601a0c2b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45678
This doesn't need to be an explicit path, its just tracing out a rect. CG has a method for that
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D60202842
fbshipit-source-id: 61faa21e57b1341c3b96961f12503eb4a7f3020b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45824
changelog: [internal]
add a bounds check to prevent crash in TouchTargetHelper.
as it turns out, firstReactAncestor may be bigger than the size of pathAccumulator.
Reviewed By: christophpurrer
Differential Revision: D60449741
fbshipit-source-id: 4e981d06877e26d278c4567beebebd82262f60d0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45822
Changelog: [internal]
## Context
`react-native/Libraries/Renderer/shims/ReactFabric` is the default module to load the RN renderer and loading it has side-effects (among other things it sets `global.RN$stopSurface`.
We introduced a proxy module (`RendererProxy`) so we could use dependency injection to overwrite the renderer module with a custom implementation (the original goal was to be able to use a renderer version that didn't pull paper and only used Fabric).
Unfortunately, using both the proxy and the module directly in some places leads to race conditions setting `global.RN$stopSurface`, which causes some screens to be rendered with one renderer and unmounted/disposed with a different one (because we accessed `ReactFabric` later and set `RN$stopSurface` from a different renderer implementation). When this happens, the unmount request in the other renderer is a no-op because no surface was renderer in it. This leads to surfaces not being disposed.
## Changes
This modifies the proxy to add additional functions and modifies all other modules in the package to make sure that all the accesses to the renderer go through the proxy.
Reviewed By: sammy-SC
Differential Revision: D60452544
fbshipit-source-id: 1b17a95ed9b1c529718f22983dde1f00f1b2adae
Summary:
Issue: https://github.com/facebook/react-native/issues/45596
## Changelog:
[INTERNAL] [CHANGED] - Migrate `GenerateCodegenSchemaTaskTest.kt` to AssertJ testing library
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/45807
Test Plan: Run `./gradlew -p packages/gradle-plugin test`
Reviewed By: andrewdacenko
Differential Revision: D60509334
Pulled By: cortinico
fbshipit-source-id: 0702958f0c9d03994b0c9a6a1c743f5db84e5703
Summary:
Issue: https://github.com/facebook/react-native/issues/45596
## Changelog:
[INTERNAL] [CHANGED] - Migrate `PreparePrefabHeadersTaskTest.kt` to AssertJ testing library
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/45808
Test Plan: Run `./gradlew -p packages/gradle-plugin test`
Reviewed By: andrewdacenko
Differential Revision: D60509282
Pulled By: cortinico
fbshipit-source-id: 1b7d9f0c24bb0e8e573f685582c532a38e6b3b13
Summary:
Fixes [44566](https://github.com/facebook/react-native/issues/44566)
Issue was onChangeText was called 5-6 times if maxLength was set in a multiline component and TextInput Value was changed via state update.
`if (_maxLength) {
NSInteger allowedLength = MAX(
_maxLength.integerValue - (NSInteger)backedTextInputView.attributedText.string.length + (NSInteger)range.length,
0);
if (text.length > allowedLength) {
// If we typed/pasted more than one character, limit the text inputted.
if (text.length > 1) {
if (allowedLength > 0) {
// make sure unicode characters that are longer than 16 bits (such as emojis) are not cut off
NSRange cutOffCharacterRange = [text rangeOfComposedCharacterSequenceAtIndex:allowedLength - 1];
if (cutOffCharacterRange.location + cutOffCharacterRange.length > allowedLength) {
// the character at the length limit takes more than 16bits, truncation should end at the character before
allowedLength = cutOffCharacterRange.location;
}
}
// Truncate the input string so the result is exactly maxLength
NSString *limitedString = [text substringToIndex:allowedLength];
NSMutableAttributedString *newAttributedText = [backedTextInputView.attributedText mutableCopy];
// Apply text attributes if original input view doesn't have text.
if (backedTextInputView.attributedText.length == 0) {
newAttributedText = [[NSMutableAttributedString alloc]
initWithString:[self.textAttributes applyTextAttributesToText:limitedString]
attributes:self.textAttributes.effectiveTextAttributes];
} else {
[newAttributedText replaceCharactersInRange:range withString:limitedString];
}
backedTextInputView.attributedText = newAttributedText;
_predictedText = newAttributedText.string;
// Collapse selection at end of insert to match normal paste behavior.
UITextPosition *insertEnd = [backedTextInputView positionFromPosition:backedTextInputView.beginningOfDocument
offset:(range.location + allowedLength)];
[backedTextInputView setSelectedTextRange:[backedTextInputView textRangeFromPosition:insertEnd
toPosition:insertEnd]
notifyDelegate:YES];
[self textInputDidChange];
}
return nil; // Rejecting the change.
}}`
This is the original code snippet.
It was happening because of wrong check of maxLength with text length `if (text.length > allowedLength)` this should be
`(text.length > _maxLength.integerValue)` and `if (allowedLength <= 0)` we should not change the string and fire `textInputDidChange`
## Changelog:
[IOS] [FIXED] : Fixing maxLength check which was firing onChange multiple times
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/45401
Test Plan:
Tested in Ios
Ran yarn test
<img width="1661" alt="Screenshot 2024-07-12 at 1 00 28 PM" src="https://github.com/user-attachments/assets/fbad94a8-9989-4252-ad7d-e507d4eafd9e">
Reviewed By: sammy-SC
Differential Revision: D59911745
Pulled By: cipolleschi
fbshipit-source-id: 67410ec50d6a2415e568e1685699bfed02fd0a27
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45838
Some Internal tests in the old architecture were failing after landing [#45414](https://github.com/facebook/react-native/pull/45414) because the `RCTNativeAnimatedModule` in the old architecture was not declaring the event.
This change fixes it by declaring the event that is never fired in the Old Architecture as it is not needed.
## Changelog
[iOS][Added] - Declare the `onUserDrivenAnimationEnded` in the old Architecture
Reviewed By: sammy-SC
Differential Revision: D60507812
fbshipit-source-id: eb12563c6551204bcf98f3a2001e1efcf84ef05e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45803
This makes the same rough changes as I made to images, to apply background styles in view manager layer, using BackgroundStyleApplicator, including new boxShadow style property.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D60409795
fbshipit-source-id: 304cb99855de72fe36af33cdda4a150e21b629b9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45797
Android borders are drawn using a path generated by `addRoundRect()` inset by half the border width, using the full border width as stoke width. The edges of the ellipsis drawn for rounded borders do not line up with the math used to trace the bounding border-box path.
In a relatively similar hack to elsewhere in border drawing code for gap between content and the border, we inset the clipOut path, as if its bounding rectangle were about half a subpixel smaller, to mininally overlap the border on these edges. We then place the outer box shadows under the border in z-ordering, so that the minimal extra insetting is only visible with transparent backgrounds.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D60389685
fbshipit-source-id: 8c449cc3eee1a3e4100f06fd87f27ae341e02eac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45781
This adds some RNTester examples for `boxShadow`, that render correctly when `ReactNativeFeatureFlags.enableBackgroundStyleApplicator()` is set!
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D60367850
fbshipit-source-id: 3c9ae2bf906ae923c713b5f36cd2000f612fe3dc
Summary:
Backout of the [commit](https://github.com/facebook/react-native/commit/afa887b6225352d35ed99eb5271bef8a3fe1c7d6) to react to the new event as it is breaking internal tests.
## Changelog:
[General][Changed] - Revert React to onUserDrivenAnimationEnded event in JS
Reviewed By: mdvacca, arushikesarwani94
Differential Revision: D60467143
fbshipit-source-id: c70bb057adf49b5f26df4201f8b987bf6b876f46
Summary:
Backout of this [commit]() as the previous one was making some E2E fail and need to investigate further.
## Changelog:
[Internal] - Add back `_shouldEmitEvent` guardrails
Reviewed By: mdvacca, arushikesarwani94
Differential Revision: D60467145
fbshipit-source-id: a703022aa74ca0ed0fed05b59da68918eb2001e1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45795
Changelog: [internal]
Our modules to set up the runtime have side-effects and depend on import order to work correctly. This is error-prone and complicates the migration to ESM in some cases, so this refactors all of them in `src/private/setup` to export a function instead.
Reviewed By: rshest
Differential Revision: D60382506
fbshipit-source-id: 9ac30b29659b74605d59eb97562d6cbf01f48e47
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45793
Changelog: [internal]
These files are safe to move because they haven't been enabled in OSS and people shouldn't be importing them directly.
Reviewed By: rshest
Differential Revision: D60381603
fbshipit-source-id: bba62b56c42817b15bb28bce22d6c2cf668dc797
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45791
Changelog: [internal]
These files are safe to move because they haven't been enabled in OSS and people shouldn't be importing them directly.
Reviewed By: rshest
Differential Revision: D60377869
fbshipit-source-id: 02bc0335385859c0589a494de9b59b0c2ebc06f6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45792
Changelog: [internal]
These files are safe to move because they haven't been enabled in OSS and people shouldn't be importing them directly.
Reviewed By: rshest
Differential Revision: D60377868
fbshipit-source-id: db0ec2839af91620fe8b6d3927ad0b809d1bdf23
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45784
Changelog: [internal]
I originally created `src/private/core` as a directory to contain set up files for RN, but the name wasn't implying that and ended up holding more stuff.
This moves everything out of that directory and renames it as `src/private/setup` so it has a clearer scope.
Reviewed By: NickGerleman
Differential Revision: D60290620
fbshipit-source-id: b5dc27fbaa64df9a8a09a84f02023896f6fd2884
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45414
This change completes the fix for broken pressable when animations were applied to components with native driven animations.
When creating the AnimatedProps, if they are natively drive animation, we look for the AnimatedValue involved and we register a listener. This is needed to make sure that the NativeModule will send te updated value upon calling the `update` function.
Then, when observing the props lifecycle, it register a listener to the new `OnUserAnimationEnded` event, fired by the NativeAnimation module.
When the `OnUserAnimationEnded` event is fired, the AnimatedProps will update the props that depends on the user driven animation.
## Changelog
[General][Fixed] - reallign the shadow tree and the native tree when the user finishes interacting with the app.
Reviewed By: sammy-SC
Differential Revision: D59681428
fbshipit-source-id: c6690c41ea6d5517b7f8413e9dba1e12861a2400
Summary:
Adds changelog for the 0.74.4 patch.
bypass-github-export-checks
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Add 0.74.4 changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/45818
Reviewed By: cortinico
Differential Revision: D60448807
Pulled By: cipolleschi
fbshipit-source-id: 9737523dccf767091a6f1c1e076f8a192d0e5136
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45693
This wires box shadow application for `ReactImageViewManager` to `BackgroundStyleApplicator` for setting shadows. This same logic will get copy-pasted to other view managers later up the stack (including Vito images, ScrollViews, etc, then eventually View), until we are able to consolidate to BaseViewManager.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D60266016
fbshipit-source-id: eaa842f539ee1654ab719c7d341b4b748db7a15c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45780
D59300215 noticed that the drawable was leaking a clipping rect for the rest of the operations, and added a `save/restore` pair, but the save happens conditionally, so we can restore more often than we save, if we hit a fast path of not needing to invalidate the shadow RenderNode when drawing. This leads to the following unhandled exception:
```
java.lang.IllegalStateException: Underflow in restore - more restores than saves
at android.graphics.Canvas.restore(Canvas.java:647)
at com.facebook.react.uimanager.drawable.OutsetBoxShadowDrawable.draw(OutsetBoxShadowDrawable.kt:110)
at android.graphics.drawable.LayerDrawable.draw(LayerDrawable.java:1019)
```
This change moves saving canvas context to before setting state and drawing onto the canvas, instead of the area manipulating the RenderNode.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D60375357
fbshipit-source-id: 773c733fce11ce89ab6741589eea19b6f060f9a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45692
This moves to using `BackgroundStyleApplicator` instead of `ReactViewBackgroundManager`, or Fresco based drawing, for setting background/border style props when the feature gates are right.
This will be ported to Vito (and... all the other built-in views) later up the stack.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D60265326
fbshipit-source-id: d9dea8d35eeb09a10d012c3ab93957dbf2ebfdd7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45689
Going to use this to gate usage of the applicator, for each of the components, including `<View>`, which
This also conveniently sidesteps some unsavory reflection on View member happening that we can't clean up yet.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D60265327
fbshipit-source-id: fabac3ac8479ff359ae6d798407047287dc712f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45688
Box shadows are handled as part of different drawables. We have other cases where we want to show multiple drawables at once, such as for ripple feedback, or more commonly, for app-wide TextInput styles (which adds padding).
With more multi-background scenarios in the future, and CSSBackgroundDrawable already way overloaded, the arch here I want to go towards is less drawables, as hidden implementation details, with single responsibilities, more often switched out. Once path logic is extracted, this would also allow for better fast-paths, like not needing to create a (heavy) CSSBackgroundDrawable, for simple views with a color background.
`CompositeBackgroundDrawable` is then a more structured LayerDrawable, which also lets us mutate or retrieve information from specific layers, and enforces the different types of layers are correctly z-ordered.
`BackgroundStyleApplicator` is the public API for manipulating these styles, inspired by the existing `ReactViewBackgroundManager`. There are some important design differences.
1. The only per-view state is the publicly accessible background drawable. This means the applicator can be used on arbitrary views, and eventually used in BaseViewManager for all views (once all the QEs settle)
2. We have reliable accessors for every setter, which seem to be what folks use externally for animation
3. We work consistently in CSS device independent pixels (for the most part...)
4. More structure/safety in how we refer to edges vs uniform
5. Overflow state is not kept on the applicator, so views can set/keep their own defaults
Overflow clipping must still be implemented per-view, during drawing unfortunately.
Changelog:
[Android][Added] - Add BackgroundStyleApplicator for managing view backgrounds
Reviewed By: joevilches
Differential Revision: D60252279
fbshipit-source-id: 4c6da3e128d4da94f35d50c30c7c412cb513cc12
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45734
Rather than enumerating all platforms the iOS podspec should not compile this inverts the source_files field to an allowlist for only files relevant to iOS.
## Changelog
[Internal]
Reviewed By: cipolleschi
Differential Revision: D60291091
fbshipit-source-id: a0f7e3181ec527e39602c4523622f836a04183d9
Summary:
With the React revert from 19 to 18.3.1 of 0.75 the template is not compatible with main anymore.
As a quick solution, we are disabling the e2e tests running on main.
## Changelog
[Internal] - disable E2E template tests
Reviewed By: cortinico
Differential Revision: D60387687
fbshipit-source-id: 74d4133477bcfdc8ba5909b46d9180ac372ec6bb
Summary:
Issue: https://github.com/facebook/react-native/issues/45596
## Changelog:
[INTERNAL] [CHANGED] - Migrate `GeneratePackageListTaskTest.kt` to AssertJ testing library
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/45790
Test Plan: Run `./gradlew -p packages/gradle-plugin test`
Reviewed By: sammy-SC
Differential Revision: D60382287
Pulled By: cortinico
fbshipit-source-id: 338c771db9d407f0d83e1c62a8c13ac26d898926
Summary:
The Maestro team just released a new version of maestro which dies in our CI
This change pins the version to something we know it's working, so we can decide when to move to the next version
## Changelog
[Internal] - Pin Maestro version
Reviewed By: cortinico
Differential Revision: D60380466
fbshipit-source-id: af842b7922736cc08300ac3bceef2d6110bcd913
Summary:
`getGradleDependenciesToApply` tries to call `implementation:` in all libraries, including the ones that are not supported on Android.
## Changelog:
[INTERNAL] [FIXED] - Filter out platform-specific libraries from the auto-linking gradle plugin
Pull Request resolved: https://github.com/facebook/react-native/pull/45749
Test Plan: CI should be green
Reviewed By: cipolleschi
Differential Revision: D60374769
Pulled By: cortinico
fbshipit-source-id: 33c83e9cc39d81b0e5c497570a936831ebb345f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45708
# Changelog: [Internal]
This was originally highlighted by linter in D59975264, but I forgot to fix it.
Reviewed By: robhogan
Differential Revision: D60282937
fbshipit-source-id: 2869634f2d2111a5e2a81871b38b15a122b3ed8a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45528
Right now these exist in static view config (iOS BaseViewConfig), but not native view config, so the props don't work without bridgeless/SVCs, and we would get warnings if doing viewconfig validation.
This change adds the props to native view configs as well.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D59940432
fbshipit-source-id: 89d57d4e58de2a55b749c68274ef0d2271f69100
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45630
removeOutstandingSurfacesOnDestruction is safe to fully release, we are deleting the flag
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D60142272
fbshipit-source-id: 5e7470d52cfc964b72f0cec7224a234ce9e6c2c4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45422
When `ReactNativeFeatureFlags.setAndroidLayoutDirection()` is set, we assume in components like ReactHorizontalScrolView that the Yoga contextual layout direction has been set on the underlying component, and skip using I18nManager global direction.
These native views are also used in Paper, so we need to make the change there as well to avoid regressions.
This change mechanically ports the change from Fabric to Paper, at the same layer as used in Fabric (applying ShadowNode layout to the Android view tree).
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D59708408
fbshipit-source-id: 52d6fa80c102250eae7ccccedd7184569f6a727f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45753
Let's turn this off, for clients where the feature flag isn't wired to a config, until the issue with `removeClippedSubviews` is resolved.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D60273063
fbshipit-source-id: 6302a7e1f204459ec7f5cbdb26a521e07e023458
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45690
ViewManager layer often uses `YogaConstants.UNDEFINED` (`NaN`) as null-state value. Teaching PixelUtil how to handle `NaN` values makes glue code around easier. I think this technically isn't needed, since the resultant operations would become `NaN`, but it seems like poor form/hard to reason about to propagate NaN into arithmetic or library functions.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D60265329
fbshipit-source-id: b2f4abaefb30ebd58c2644d072bb7e5bc4b3ee7b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45691
1. Add some accessors, so we can keep accessors and setters symetric
2. Use the shared BorderStyle enum added in last diff
3. Fix some missing invalidation on setting style
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D60252276
fbshipit-source-id: 3dde6ad5926f109cefc7247da4ba1894694b1867
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45687
This adds some more enums and data classes to encapsulate style values we are working with for border/background rendering. Right now, a lot of these are passed around as strings, or raw ints (of differing ordinals). These will be used as the public API of `BackgroundStyleApplicator` up the stack.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D60252277
fbshipit-source-id: 0f8001869421ffffae9727c7904bf5e395505c08
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45685
We built these to be able to parse web style string values, but the types only allow object form, and the TypeScript type is wrong.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D60263730
fbshipit-source-id: 7a6e93924a92e8e62346645cb4f8ab1a37dca34f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45722
Splitting the ReactImageView convertion to another file, to see if this is causing further failures.
Changelog:
[Internal] [Changed] - Convert ReactImageManager to Kotlin
Reviewed By: rshest
Differential Revision: D60285050
fbshipit-source-id: 68415782a40c1eacf4e67fbdd2d70c962c0600c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45711
Migrating this package in one go is proving harder than expected.
Let's split this through in smaller parts: I'm first marking the package as nullsafe.
Changelog:
[Internal] [Changed] - Make `com.facebook.react.views.image` nullsafe
Reviewed By: cipolleschi
Differential Revision: D60282604
fbshipit-source-id: 68879142a88bdc3c837dff91e53c5f5e891773f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45683
Changelog: [Internal]
this did not make any meaningful progress, let's clean it up and revisit it later.
Reviewed By: fkgozali
Differential Revision: D60219828
fbshipit-source-id: 89a283d7c572dfcd6ef16472e81f3dce1c2cd284
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45706
## Context
Running manual tests when preparing a release, it's time consuming.
We have to do the cherry picks, wait for CI to finish, and then manually test 8 configurations.
Maestro is a tool that allow us to run E2E tests automatically, and we can wire it to CI.
## Change
To avoid flakyness and costs, let's run E2E tests only on main and on stable branches
Changelog:
[Internal] - Exploration to integrate maestro
Reviewed By: blakef
Differential Revision: D60283204
fbshipit-source-id: 806cb8905cb269f18785158dcc5777ef10e0ef44
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45710
## Context
Running manual tests when preparing a release, it's time consuming.
We have to do the cherry picks, wait for CI to finish, and then manually test 8 configurations.
Maestro is a tool that allow us to run E2E tests automatically, and we can wire it to CI.
## Change
Add job to create a new Android app from the template and run maestro test on it
Changelog:
[Internal] - Exploration to integrate maestro
Reviewed By: cortinico
Differential Revision: D60282836
fbshipit-source-id: 0c3b4c1bbacfd6c8695f987c86b7e615a3cef026
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45703
## Context
Running manual tests when preparing a release, it's time consuming.
We have to do the cherry picks, wait for CI to finish, and then manually test 8 configurations.
Maestro is a tool that allow us to run E2E tests automatically, and we can wire it to CI.
## Change
Add job to create a new iOS app from the template and run maestro test on it
Changelog:
[Internal] - Exploration to integrate maestro
Reviewed By: blakef
Differential Revision: D60282811
fbshipit-source-id: 2a1dcb1de09795bd0323357455e98a7fa379a2e7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45713
## Context
Running manual tests when preparing a release, it's time consuming.
We have to do the cherry picks, wait for CI to finish, and then manually test 8 configurations.
Maestro is a tool that allow us to run E2E tests automatically, and we can wire it to CI.
## Change
Add Maestro flow for a new app created from the template
Changelog:
[Internal] - Exploration to integrate maestro
Reviewed By: blakef
Differential Revision: D60282783
fbshipit-source-id: 0aa7f3fae4f5bf31518e02ddc56ca2d4fac4dfa3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45709
## Context
Running manual tests when preparing a release, it's time consuming.
We have to do the cherry picks, wait for CI to finish, and then manually test 8 configurations.
Maestro is a tool that allow us to run E2E tests automatically, and we can wire it to CI.
## Change
Connect RNTester Android to Maestro action
Changelog:
[Internal] - Exploration to integrate maestro
Reviewed By: blakef
Differential Revision: D60282769
fbshipit-source-id: 2a20f1cb249fc5c43b0579c3309efd60369a1da6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45707
## Context
Running manual tests when preparing a release, it's time consuming.
We have to do the cherry picks, wait for CI to finish, and then manually test 8 configurations.
Maestro is a tool that allow us to run E2E tests automatically, and we can wire it to CI.
## Change
Create a github action to run Maestro on Android
Changelog:
[Internal] - Exploration to integrate maestro
Reviewed By: cortinico, blakef
Differential Revision: D60282719
fbshipit-source-id: 9544eea192894696361fada1e519caad35f74154
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45705
## Context
Running manual tests when preparing a release, it's time consuming.
We have to do the cherry picks, wait for CI to finish, and then manually test 8 configurations.
Maestro is a tool that allow us to run E2E tests automatically, and we can wire it to CI.
## Change
Wire RNTester to the Maestro Action
Changelog:
[Internal] - Exploration to integrate maestro
Reviewed By: blakef
Differential Revision: D60282689
fbshipit-source-id: 51c624c2acf7a27ed5527e7453d9a04678df6c66
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45704
## Context
Running manual tests when preparing a release, it's time consuming.
We have to do the cherry picks, wait for CI to finish, and then manually test 8 configurations.
Maestro is a tool that allow us to run E2E tests automatically, and we can wire it to CI.
## Change
Create a reusable GHA to run Maestro tests on iOS
Changelog:
[Internal] - Exploration to integrate maestro
Reviewed By: blakef
Differential Revision: D60282657
fbshipit-source-id: 3a2a427f0954b46fc6c3a8bf753e807371eb0239
Summary:
## Context
Running manual tests when preparing a release, it's time consuming.
We have to do the cherry picks, wait for CI to finish, and then manually test 8 configurations.
Maestro is a tool that allow us to run E2E tests automatically, and we can wire it to CI.
## Change
Add a test flow for RNTester
## Changelog:
[Internal] - Exploration to integrate maestro
Pull Request resolved: https://github.com/facebook/react-native/pull/45574
Test Plan: GHA
Reviewed By: blakef
Differential Revision: D60282147
Pulled By: cipolleschi
fbshipit-source-id: 4ecba84f0b2c7186de2bb9938043e73a0bd9a6bd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45735
This merges several 2 external libraries from .so to be included inside
libappmodules.so.
Changelog:
[Internal] [Changed] - Move react_codegen_* libraries for RNTester to OBJECT
Reviewed By: rozele, rshest
Differential Revision: D60290806
fbshipit-source-id: 6bfa40995d7538e075819d916e8a204464edb75b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45727
All instances mirror types which are already defined in the platform-independent base module. See snapshot changes.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D60286148
fbshipit-source-id: 30665252ff5e449a2c10ff3a3e76d9337daecb80
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45640
Other two libraries that don't need to be dynamic libraries but can just be exposed via libreactnative.so
Changelog:
[Internal] [Changed] - Move react_featureflags and react_render_consistency inside libreactnative.so
Reviewed By: cipolleschi
Differential Revision: D55796945
fbshipit-source-id: be40b1523a560b2783fc7b6312326e20dc8cf595
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43909
As we're moving towards a single `libreactnative.so` file, we need to remove several of our prefab targets. Here I'm cleaning up those that are not having an OnLoad.cpp file which needs to be loaded from SoLoader.
This is breaking for libraries using native dependencies via Prefab (i.e. search for `ReactAndroid::` in CMakeLists.txt files for your project).
If so, the CMakeLists.txt files should be updated as follows:
```diff
- ReactAndroid::react_render_debug
+ ReactAndroid::reactnative
```
This applies to every prefab dependencies (the example is just for `react_render_debug`
Changelog:
[General] [Breaking] - Remove several libs from default App CMake setup
Reviewed By: cipolleschi
Differential Revision: D55751683
fbshipit-source-id: 3aca7897852b5f323d60ede3c5036cae2f81e6c3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43908
This creates a new dynamic library that we want to be the only .so that is loaded from apps/libraries.
Changelog:
[Internal] [Changed] - Create the libreactnative.so dependency
Reviewed By: cipolleschi
Differential Revision: D55751682
fbshipit-source-id: 50f4167dc2f9953a8673b28dba3357e19fe88d6b
Summary:
https://github.com/facebook/react-native/issues/45596
Migrated all the assertions to use `assertThat()` function from AssertJ.
Also updated the `prepareBoostTask_withMissingConfiguration_fails` test to use `assertThatThrownBy` to check if the tested task throws a given exception.
## Changelog:
Migrate tests to assertj in these files:
- `packages/gradle-plugin/react-native-gradle-plugin/src/test/kotlin/com/facebook/react/tasks/internal/PrepareBoostTaskTest.kt`
[INTERNAL] [CHANGED] - Migrated PrepareBoostTaskTest from junit.Assert to assertj.core.api.Assertions.
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/45718
Test Plan:
All tests pass when `./gradlew -p packages/gradle-plugin test` command is ran.
<img width="454" alt="image" src="https://github.com/user-attachments/assets/9e954f7b-2208-48a9-ae15-ab642252e6da">
Reviewed By: GijsWeterings
Differential Revision: D60284566
Pulled By: cortinico
fbshipit-source-id: 11af0a0ca574f935e6aab3a7855b5daaeab1a718
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45701
# Changelog: [Internal]
One weird thing is that this test actually never runs for Android, so its only compiled. I am not sure why exactly this one produces an error during execution, given that the next test is almost identical.
Nothing valuable from logcat, just a `SIGSEGV`. Since its something with memory, I've tried calling `unsubscribe`, same as in the next test to free memory before the test tear down (which should not run, because this test doesn't run).
Reviewed By: dmytrorykun
Differential Revision: D60282464
fbshipit-source-id: 2c7760f02c1128083f28651fe8ecd0f3cee27715
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45578
# Changelog: [Internal]
Use previously introduced native module for managing the presence of warning notifications in LogBox:
- Don't display warnings and Fusebox migration message if there is an active debugging session
- If the session has just been started, clear warnings to hide Fusebox migration message
- If there is no active debugging session (even if there were some at some point of Host lifetime), display Fusebox migration message
See demo in test plan.
Reviewed By: huntie
Differential Revision: D59975265
fbshipit-source-id: 87d91b4d7f3c825dc795ec1b5b3073f969bc7b60
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45577
# Changelog: [Internal]
This diff adds new native module, which can be used from JavaScript.
The API includes:
1. `hasActiveSession`: returns a boolean flag, which can be used for determining if 1 or more debugging sessions are active for current HostTarget.
2. `subscribe`: receives a callback, which will be executed once the debugging state changes. To be more precise, this will only be called when state is changing from no active sessions to 1 session or the other way around. Callback should expect to receive one boolean argument, which can be used for determining if there is an active session.
Reviewed By: huntie
Differential Revision: D59975264
fbshipit-source-id: dd095954529f573f38e9fae1792465a59e639d23
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45670
**Motivation**
There is a special [code path](https://github.com/facebook/react-native/blob/bb23026daf1a853f4482be46d6f242712a6b7330/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/animated/FrameBasedAnimationDriver.java#L98) for native driven looping animations that restarts the animation in native, never calling the "animation end" callback. This was designed for and works fine with the `Animated.loop(Animated.timing(...))` animations. Unfortunately, it doesn't work well with more complex animations.
Consider an `Animated.loop(Animated.sequence(Animated.timing(...)))` animation. It doesn't trigger this code path. Instead, its nested `Animated.timing` animations are continuously rescheduled from JS by the looping `Animated.sequence` as singular native driven animations. Each time they end, they fire their "animation end" callback.
This introduces a subtle breakage when those "animation end" callbacks trigger React to update its state. This in turn restarts the rendering. In case with long transitions such looping animations can restart the rendering multiple times. In worst cases it may render the app unresponsive.
**Solution**
We don't need to tell React to update its state when running looping animations. This diff introduces a mechanism, using which `Animated.loop` can tell its nested animations that they are in a loop, and and there's no need to send state updates when they finish. This is consistent with how `Animated.loop(Animated.timing(...))` behaves.
Changelog: [General][Breaking] - Looping animations will not send React state updates.
Facebook
This diff enables this new behaviour for IGVR and FBVR, it also set up the experiment for FBiOS and FB4a.
Reviewed By: javache
Differential Revision: D59970265
fbshipit-source-id: 4832ae05b82f6cc59f92f72305b68610fa422f0a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45638
When looping a frame-based animation, we want to make sure to use the latest frame from the easing curve, which may not necessarily match `mToValue`.
Changelog: [Internal]
Differential Revision: D60143746
fbshipit-source-id: 68fa5421a958acc8291f396bc9f263fa110fdc54
Summary:
As explained in https://github.com/facebook/react-native/issues/45280, `TSan` picks up data races related to concurrent read/write to fields in `RCTCxxBridge`. See this report for reference:
```
WARNING: ThreadSanitizer: data race (pid=19983)
Write of size 1 at 0x00010af1dfd8 by thread T13:
#0 -[RCTCxxBridge _flushPendingCalls] <null> (RNTesterUnitTests:arm64+0x42b484)
https://github.com/facebook/react-native/issues/1 __53-[RCTCxxBridge executeSourceCode:withSourceURL:sync:]_block_invoke <null> (RNTesterUnitTests:arm64+0x426050)
https://github.com/facebook/react-native/issues/2 decltype(std::declval<void () block_pointer __strong&>()()) std::__1::__invoke[abi:ue170006]<void () block_pointer __strong&>(&&, decltype(std::declval<void () block_pointer __strong&>()())&&...) <null> (RNTesterUnitTests:arm64+0x456298)
https://github.com/facebook/react-native/issues/3 std::__1::__function::__func<void () block_pointer __strong, std::__1::allocator<std::__1::allocator>, void ()>::operator()() <null> (RNTesterUnitTests:arm64+0x455c6c)
https://github.com/facebook/react-native/issues/4 std::__1::__function::__value_func<void ()>::operator()[abi:ue170006]() const <null> (RNTesterUnitTests:arm64+0x3ce2e4)
https://github.com/facebook/react-native/issues/5 std::__1::function<void ()>::operator()() const <null> (RNTesterUnitTests:arm64+0x3cdfd0)
https://github.com/facebook/react-native/issues/6 facebook::react::tryAndReturnError(std::__1::function<void ()> const&) <null> (RNTesterUnitTests:arm64+0x4af18c)
https://github.com/facebook/react-native/issues/7 facebook::react::RCTMessageThread::tryFunc(std::__1::function<void ()> const&) <null> (RNTesterUnitTests:arm64+0x51595c)
https://github.com/facebook/react-native/issues/8 facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1::operator()() const <null> (RNTesterUnitTests:arm64+0x529df0)
https://github.com/facebook/react-native/issues/9 decltype(std::declval<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1&>()()) std::__1::__invoke[abi:ue170006]<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1&>(facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1&) <null> (RNTesterUnitTests:arm64+0x529b54)
https://github.com/facebook/react-native/issues/10 void std::__1::__invoke_void_return_wrapper<void, true>::__call[abi:ue170006]<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1&>(facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1&) <null> (RNTesterUnitTests:arm64+0x529978)
https://github.com/facebook/react-native/issues/11 std::__1::__function::__alloc_func<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1, std::__1::allocator<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1>, void ()>::operator()[abi:ue170006]() <null> (RNTesterUnitTests:arm64+0x5298dc)
https://github.com/facebook/react-native/issues/12 std::__1::__function::__func<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1, std::__1::allocator<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1>, void ()>::operator()() <null> (RNTesterUnitTests:arm64+0x524518)
https://github.com/facebook/react-native/issues/13 std::__1::__function::__value_func<void ()>::operator()[abi:ue170006]() const <null> (RNTesterUnitTests:arm64+0x3ce2e4)
https://github.com/facebook/react-native/issues/14 std::__1::function<void ()>::operator()() const <null> (RNTesterUnitTests:arm64+0x3cdfd0)
https://github.com/facebook/react-native/issues/15 invocation function for block in facebook::react::RCTMessageThread::runAsync(std::__1::function<void ()>) <null> (RNTesterUnitTests:arm64+0x515384)
https://github.com/facebook/react-native/issues/16 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ <null> (CoreFoundation:arm64+0x8dc0c)
https://github.com/facebook/react-native/issues/17 __NSThread__start__ <null> (Foundation:arm64+0x645c60)
Previous read of size 1 at 0x00010af1dfd8 by main thread:
#0 -[RCTCxxBridge isLoading] <null> (RNTesterUnitTests:arm64+0x43236c)
https://github.com/facebook/react-native/issues/1 -[RCTBridge isLoading] <null> (RNTesterUnitTests:arm64+0x3c0170)
https://github.com/facebook/react-native/issues/2 -[RCTComponentPropsTests setUp] <null> (RNTesterUnitTests:arm64+0xe6f34)
https://github.com/facebook/react-native/issues/3 __70-[XCTestCase _shouldContinueAfterPerformingSetUpSequenceWithSelector:]_block_invoke.134 <null> (XCTestCore:arm64+0x540d8)
Location is heap block of size 384 at 0x00010af1de80 allocated by main thread:
#0 calloc <null> (libclang_rt.tsan_iossim_dynamic.dylib:arm64+0x4fc30)
https://github.com/facebook/react-native/issues/1 _malloc_type_calloc_outlined <null> (libsystem_malloc.dylib:arm64+0xf488)
https://github.com/facebook/react-native/issues/2 -[RCTBridge initWithDelegate:bundleURL:moduleProvider:launchOptions:] <null> (RNTesterUnitTests:arm64+0x3bc540)
https://github.com/facebook/react-native/issues/3 -[RCTBridge initWithBundleURL:moduleProvider:launchOptions:] <null> (RNTesterUnitTests:arm64+0x3bc124)
https://github.com/facebook/react-native/issues/4 -[RCTComponentPropsTests setUp] <null> (RNTesterUnitTests:arm64+0xe6b3c)
https://github.com/facebook/react-native/issues/5 __70-[XCTestCase _shouldContinueAfterPerformingSetUpSequenceWithSelector:]_block_invoke.134 <null> (XCTestCore:arm64+0x540d8)
Thread T13 (tid=11290378, running) created by main thread at:
#0 pthread_create <null> (libclang_rt.tsan_iossim_dynamic.dylib:arm64+0x2bee4)
https://github.com/facebook/react-native/issues/1 -[NSThread startAndReturnError:] <null> (Foundation:arm64+0x6458f0)
https://github.com/facebook/react-native/issues/2 -[RCTBridge setUp] <null> (RNTesterUnitTests:arm64+0x3bf748)
https://github.com/facebook/react-native/issues/3 -[RCTBridge initWithDelegate:bundleURL:moduleProvider:launchOptions:] <null> (RNTesterUnitTests:arm64+0x3bc540)
https://github.com/facebook/react-native/issues/4 -[RCTBridge initWithBundleURL:moduleProvider:launchOptions:] <null> (RNTesterUnitTests:arm64+0x3bc124)
https://github.com/facebook/react-native/issues/5 -[RCTComponentPropsTests setUp] <null> (RNTesterUnitTests:arm64+0xe6b3c)
https://github.com/facebook/react-native/issues/6 __70-[XCTestCase _shouldContinueAfterPerformingSetUpSequenceWithSelector:]_block_invoke.134 <null> (XCTestCore:arm64+0x540d8)
```
In order to fix the data races, `std::atomic` instead of primitive boolean types.
In order to reproduce my findings and verify fix:
* Clone this branch
* Run setup code as described in README
* Execute `git revert -n 11c09fdc7c442dd694909bebbbc8f21c3e69edf2`.
* Enable TSan for both RNTester and its test scheme.
* Enable Runtime issue breakpoint for TSan
* Run unit tests
* Observe the TSan breakpoint is hit (possibly other places in the codebase as well) when accessing `_loading`, `_moduleRegistryCreated`, and `_valid`.. Continue execution if other breakpoints are hit before this breakpoint.
* Execute git revert --abort
* Run the tests again and observe the TSan breakpoint does not hit said code again.
NB! While this will fix data races, it will not fix potential race conditions. I have not encountered bugs related to race conditions in `RCTCxxBridge`, but given the nature of how it is made use of concurrently, it is, in my opinion, plausible.
## Changelog:
[iOS][Fixed] Use std::atomic for eliminating races in RCTCxxBridge.
Pull Request resolved: https://github.com/facebook/react-native/pull/45558
Test Plan: I believe there are existing Unit tests in place for verifying this fix.
Reviewed By: cipolleschi
Differential Revision: D60233758
Pulled By: dmytrorykun
fbshipit-source-id: 8aa124a0521ad43a5e17b42e0ce6d22ae6b4e667
Summary:
This adds `ccache` on the Android build to speedup the building process.
## Changelog:
[INTERNAL] - Adding ccache for Android builds
Pull Request resolved: https://github.com/facebook/react-native/pull/45662
Test Plan: CI
Reviewed By: cipolleschi
Differential Revision: D60229625
Pulled By: cortinico
fbshipit-source-id: bc7e416f4ed1b4932159feb672947669bfb498d7
Summary:
A previous commit (https://github.com/facebook/react-native/pull/45616) broke the ci in OSS.
It looks like that JSI is not working well in objective-c++ files when frameworks is enabled.
We need to look into it further but we need to have green CI
## Changelog:
[Internal] - Unblock CI
Reviewed By: blakef
Differential Revision: D60232011
fbshipit-source-id: b02ae163258786ce43cc11bc94420682661a6dd0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45634
This allows the Android runtime to pass additional options to Metro. Each app can
decide what to send based on the needs. The use case is to send
transform.xyz=somevalue to Metro.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D60155757
fbshipit-source-id: 006d5ff2e3f14634fb39d44b390f30da479b1faa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45621
This allows the iOS runtime to pass additional options to Metro. Each app can
decide what to send based on the needs. The use case is to send
`transform.xyz=somevalue` to Metro.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D60143663
fbshipit-source-id: 3e35a01a0ee121096d3a5cf0547e8e0ebf77f8ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45624
Must have forgot to add this functionality in, since it was just using a Rect for the clear region. This uses the proper rounded path.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D60147035
fbshipit-source-id: 3eebb2c4a56e4dfc957213e54f3d2de2c966082b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45622
The rest of these props setters opts to use `needsInvalidateLayer`, not `_needsInvalidateLayer` the latter of which is a instance variable. This change no effect since we set `_needsInvalidateLayer` to the or of both below, but we should be consistent with the rest of the logic here.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D60144215
fbshipit-source-id: b4b863d964a688c1cb9f6fada626d390681d1542
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45620
This does not really depend on anything in the layer. It is just a prop on the layer itself, so we can just set it in place. This pattern already happens for things like transform: https://fburl.com/code/0bhsdlcy
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D60142154
fbshipit-source-id: 52ee0e1e6eacf3bba005a727a5a4325a5cc6d338
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45613
We had a bug where box shadows were not getting cleaned up. The fix here is easy - just call `[_boxShadowLayer removeFromSuperView]`. Previously we were just setting this layer to nil, which does not do the job.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D60137528
fbshipit-source-id: 310df944f63ffc73ee5fe938cfb5a48674f997ab
Summary:
## Context
During TW Bloks testing, I frequently encounter the issue of a page not loading. After investigating further, I discovered that for one XOCReactNativeHost, there are multiple instances of ReactInstanceManager created. One of them is properly initialized with XOCLoginActivity, while the other one is not initialized and its activity is null.
When calling ReactContext onHostResume, there is a small chance that the ReactInstanceManager with a null activity will be used, resulting in a "no activity" issue.
After analyzing the construction call stack of ReactInstanceManager, it appears that there is a race condition in the function of ReactNativeHost.getReactInstanceManager https://fburl.com/code/kh6o84m9.
I noticed that two threads are calling this function simultaneously, which can lead to the creation of two instances despite the `mReactInstanceManager == null check`, as it is not within a synchronized statement.
An example of one ReactNativeHost with multiple ReactInstanceManagers can be found at https://fburl.com/code/kh6o84m9.
{F1768111631}
The following are the call stack to create the ReactInstanceManagers, the line number may have slightly shift from the prod code because of debugging info.
P1490866855
P1490869412
## About this diff
Added synchronized lock to the checking of `mReactInstanceManager == null` and make mReactInstanceManager as volatile to avoid creating duplicated instance.
## Changelog:
[Android] [Fixed] - Made several methods in ReactNativeHost.java thread-safe to avoid race conditions
bypass-github-export-checks
Reviewed By: javache
Differential Revision: D60088120
fbshipit-source-id: a4c1970bb54c7395dbfc3282d02bd66d9dc95df9
Summary:
This just fixes a warning in scripts/releases-ci/__tests__/publish-updated-packages-test.js that the CI is firing on every PR
## Changelog:
[INTERNAL] - Fix warning on scripts/releases-ci/__tests__/publish-updated-packages-test.js
Pull Request resolved: https://github.com/facebook/react-native/pull/45643
Test Plan: CI
Reviewed By: blakef
Differential Revision: D60170227
Pulled By: cortinico
fbshipit-source-id: 5889f7dd530cc00651d683001e1f2624bd79c27e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45616
We want to eventually route all js error handling through JsErrorHandler in bridgeless.
This will help with that.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D60138415
fbshipit-source-id: de62edfe75066ba135225e24543628306aa5f4a0
Summary:
When trying to use the legacy view interop with `stripe/stripe-react-native` there is an issue with the `CardField` component because it tries to access module registry inside the `view` method (https://github.com/stripe/stripe-react-native/blob/master/ios/CardFieldManager.swift#L7).
The problem is that we attach the legacy view apis after creating view, so they are not available in that method.
To fix this we can change the order of the methods and attach the apis first. Note that we also need to use the `manager` method instead of `bridgelessViewManager` since `bridgelessViewManager` is not initialized otherwise, it is initialized lazily in the `manager` method.
## Changelog:
[IOS] [FIXED] - Fix legacy view interop apis not available in view method
Pull Request resolved: https://github.com/facebook/react-native/pull/45609
Test Plan: Tested in an app that legacy interop apis (`moduleRegistry`) is available in the `view` method in an app using RN 0.74 with bridgeless mode enabled.
Reviewed By: cipolleschi
Differential Revision: D60165191
Pulled By: dmytrorykun
fbshipit-source-id: 60187556fb36d342bb1ef084a093132bdb0496bd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45593
I'm guessing either there is a race condition between Github removing cache entries when we're over budget OR there is an eventual consistency issue between reported cache entries and their removal. Either way, this job is best efforts. If a entry targetted for removal isn't there, great.
This change prevents the job from stopping if an entry no longer exists.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D60106847
fbshipit-source-id: 252bba7bb0bbb91d279f06a39301491332cd5ace
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45585
Changelog: [internal]
Just migrates the flag to the new system.
Reviewed By: sammy-SC
Differential Revision: D60050005
fbshipit-source-id: 4da39446ecdb6cd86ccf7ee75a0d489764c37be6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45598
I've noticed we attempt to load JSC from the Sonatype Snapshot repository.
That is inefficient as we already know that JSC is available only inside node modules.
This change makes the repository resolution stricter by better specifying which
repo can download which dependency.
Changelog:
[Internal] [Changed] - Do not attempt to load JSC from other repositories
Reviewed By: cipolleschi
Differential Revision: D60116002
fbshipit-source-id: 21a2213708f5b0103860a59f3342f1bc0f59cdb9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45589
I don't know why, but we had some CCI leftovers in the repo.
This cleans them up!
## Changelog:
[Internal] - Remove CCI leftovers
Reviewed By: cortinico
Differential Revision: D60048949
fbshipit-source-id: 08792abd53ba919a7afc0922d6f7c98cc9c4544e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45590
This gives us more wiggle room with the release of 0.76.
Changelog: [General][Changed] Move init deprecation notice 30 Sept → 31 Dec
Reviewed By: cortinico
Differential Revision: D60105868
fbshipit-source-id: d03fcf5d4a97db9b21792eff6f993e2671b276ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45515
After some provisional hacking on macOS support for React Native DevTools last week, this revealed some incompatibilities with traditional OS X APIs, which are minimally addressed here.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D59807146
fbshipit-source-id: 39c4eab723046926b0b469232152e2f994af2366
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45575
We should move over to use AssertJ as per our linter.
I'm adding it here to a first test and will use it as a reference for some OSS contributions from outside.
Changelog:
[Internal] [Changed] - Migrate settings-plugin to Assertj
Reviewed By: cipolleschi
Differential Revision: D60037797
fbshipit-source-id: 579ed7bf5fb219e25577af3ab87934503ee7898e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45572
0.75-rc.5 is currently broken on Windows.
This is due to us invoking `npx react-native-community/cli config` without
a `cmd /c` prefix.
This fixes it by using our function `windowsAwareCommandLine`.
The problem is that this required a lot of refactoring since that util was not available for the settings plugin.
Fixes#45403
Changelog:
[Internal] [Changed] - Fix core autolinking not working on Windows
Reviewed By: cipolleschi
Differential Revision: D60037587
fbshipit-source-id: eefeda7aafc43b9ce08f0f9225b0847fad2f46b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45587
changelog: [internal]
There is a way to avoid doing large number of JNI calls from JS thread for view preallocation on Android. We can move the JNI call to the main thread by creating a queue of views to be created on the JS thread and pulling it from the main thread. This way, the expensive part of JNI call (the actual call + creating JNI values) is moved to the main thread and doesn't block the JS thread from executing rendering.
Reviewed By: javache
Differential Revision: D59966062
fbshipit-source-id: af85138cfdb9b2a7a7710d79e09e165b2be55067
Summary:
The CLI of Metro bundler only accepts key presses when the Caps Lock is off. This is somehow inconvenient because the developers might think the Metro bundler doesn't response when the Caps Lock is on.
## 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] [ADDED] - Add upper case keys to the debug key handler
Pull Request resolved: https://github.com/facebook/react-native/pull/45559
Test Plan: n/a
Reviewed By: huntie
Differential Revision: D60107316
Pulled By: dmytrorykun
fbshipit-source-id: 045dcd382d84c4781dff75a1ff913cd3ccc8d288
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45573
This makes this module now be fully in Kotlin instead of having mixed Java/Kotlin sources.
Changelog:
[Internal] [Changed] - Converted com.facebook.react.modules.dialog to Kotlin
Reviewed By: tdn120
Differential Revision: D60035771
fbshipit-source-id: b45fd099c0b353768ab6580eb6a4a3dccf68f07d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45570
We do have several methods/classes that are `deprecated` in the JavaDoc but not
with an annotation. That's not correct as users will never get those deprecation otherwise
and we'll be forced to keep both implementation around for a longer time.
Changelog:
[Internal] [Changed] - Properly annotate with Deprecated methods that are just deprecated in JavaDoc
Reviewed By: javache
Differential Revision: D60036159
fbshipit-source-id: 466072d6a3fb4f1220e1dc3deaa51a46c714a388
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45567
Changelog: [internal]
(internal because our integration for Perfetto hasn't been released in OSS yet)
In our current React integration for Perfetto we're logging arbitrary time spans via `performance.measure` in specific tracks (that can be custom based on a naming scheme).
For a given track, Perfetto doesn't allow partially overlapping segments (as it's considered to always be a stack of time spans). When logging arbitrary time spans that partially overlap, Perfetto cuts the nested ones to make sure they fit into their suspected parent. This makes the logged data incorrect and makes it hard to understand the performance of an application using this data.
There's a fix for this problem: logging these arbitrary segments/time spans in separate tracks that only share the name. In this case, Perfetto groups the data in the UI but allows overlapping (as they're not really on the same track).
Reviewed By: sammy-SC
Differential Revision: D60010696
fbshipit-source-id: 378ea492c4fafbe55ef97fa91e4fa50bbc1893ae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45564
Changelog: [internal]
(this is internal because the integration hasn't been enabled in OSS yet)
In our current React integration for Perfetto we're currently creating multiple custom tracks that are spread throughout the process section and it can be hard to identify the source of the information.
This adds a "Web Performance: " prefix to all custom tracks coming from JS to achieve 2 purposes:
* Group them together (in terms of order in the process)
* Clarify the source of the data
Reviewed By: sammy-SC
Differential Revision: D60010695
fbshipit-source-id: 081f5b6417d676c61005114337530a089142e7c6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45539
Changelog: [internal]
This exposes several classes (interfaces in the spec lingo) related to the Performance API to the global scope, so users can access them directly to do things like refinements using `instanceof`. This also prevents the need from importing the modules from `react-native` directly, which would prevent code sharing with Web.
Reviewed By: rshest
Differential Revision: D59859654
fbshipit-source-id: e1f7afb0c98b394b1f97c3790db2e570e6ba0cd9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45535
Changelog: [internal]
Small refactor to group things based on the spec where they're defined.
Reviewed By: rshest
Differential Revision: D59911334
fbshipit-source-id: 1c40d6bf82b6cc7be78bd81b652d6855c39a53eb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45526
Changelog: [internal]
Just using the right interfaces so we can expose them in the global scope and do refinements as necessary using `instanceof`.
Reviewed By: rshest
Differential Revision: D59911144
fbshipit-source-id: 9779e3220f2c6f81955f54506f97142f0f4ffdd4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45525
Changelog: [internal]
This makes several changes to the Performance API to align it closer with the spec:
* Makes fields of `PerformanceEntry` and subclasses read-only.
* Returns instances of the correct subclass of `PerformanceEntry` to observers.
* Renames `HighResTimeStamp` as `DOMHighResTimeStamp` for alignment with the spec and native
Additionally, I realized that the way we handle `performance.measure` is a bit problematic at the moment. When we call the function, we create a `PerformanceMeasure` instance with the data we receive, and return that value. In parallel, we notify the entry to native, which will in turn notify the observers. But the observers will not get those instances we just created, but new instances of `PerformanceEntry` (not even `PerformanceMeasure`) with the resolved values. At the same time, the `PerformanceMeasure` instance we return doesn't resolve its `startTime` and `duration` based on the indicated marks (when specified as strings). We need to fix this in the future by resolving the timing data synchronously when calling `performance.measure`.
Reviewed By: rshest
Differential Revision: D59911145
fbshipit-source-id: e0be0441f307cc9bdea8795ae88b6f390780fc7b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45524
Changelog: [internal]
The `durationThreshold` option is only meant to be used with `event` entry types. `mark`, `measure`, `longtask`, etc. shouldn't take that option into account, as per the spec.
Reviewed By: mdvacca
Differential Revision: D59918519
fbshipit-source-id: 0553d46944cbe80a32712ff57140763f2514f734
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45545
ReactInstance creation in bridgeless returns a callback that requires dispatching on the UI thread to complete the init. If that thread is busy (eg with other startup tasks), we delay starting the initial surface unnecessarily.
This diff adds an experiment to return early from that startup task to allow follow-up tasks to be scheduled on the JS thread without waiting for lifecycle changes to have been applied.
Changelog: [Internal]
Reviewed By: markv
Differential Revision: D59961779
fbshipit-source-id: dd6a6fe093a32144ef6823bde5ac94a61d268fd2
Summary:
CircleCI was automatically cancelling an old run if a new commit was pushed on the branch.
GitHub does not have the same behavior enabled by default.
Keep running jobs in a pipeline when there is a new commit is usually wasteful of resources and cost money we can save.
## Changelog:
[Internal] - Cancel old jobs if a new commit is pushed
Pull Request resolved: https://github.com/facebook/react-native/pull/45568
Test Plan: Tested on GHA on this PR
Reviewed By: blakef
Differential Revision: D60035940
Pulled By: cipolleschi
fbshipit-source-id: 88b4dfc8bdd3eded6489a87db285e9544d3a1bcf
Summary:
In Node 20, the script to run unit tests in CI (`scripts/run-ci-javascript-tests.js`) will fail, even when all the Jest tests pass. This happens because one of the JS modules being tested is setting `process.exitCode` (see https://github.com/jestjs/jest/issues/9324#issuecomment-1808090455).
Changes:
- Modified the affected module to throw an exception when failing, instead of setting the exit code
- Adjusted the unit test for that module
## Changelog:
[General] [Fixed] - Remove setting of process.exitCode that breaks Jest tests
Pull Request resolved: https://github.com/facebook/react-native/pull/45562
Test Plan:
Before this change, running `node scripts/run-ci-javascript-tests.js` would fail with Node 20.
After this change, it succeeds.
Reviewed By: blakef
Differential Revision: D60033582
Pulled By: cipolleschi
fbshipit-source-id: 71b7f4495d414e719a9bd2d892bd1bc3045ddd5d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45554
In this diff I'm extracting the creation of borderWidth into its own method, this is necessary for next diffs of the stack.
Nh behavior change is introduced here
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D59942306
fbshipit-source-id: 85d39b64deaa4e8a8632d6f4aab72f626e594b5d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45553
This diff introduces a "temporary" method called getDiffProps to calculate the difference between 2 props and serialize its result into a folly::dynamic map.
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D59613245
fbshipit-source-id: 3e23cde0113ac2a3904c8daa48a1ca048cd0262d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45556
I missed updating this, and the e2e test we had isn't running, so switching JS objects to camel case broke this.
Changelog: [internal]
Reviewed By: jorge-cab
Differential Revision: D60003747
fbshipit-source-id: 6b7b1138e3ebbfdb982f5a089804351cc4b198ba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45550
`ConcurrentModificationException` is happening from `emitScrollEvent()`.
This usually happens if we modify the collection (add/remove) while accessing collection in a foreach loop.
Seems likely add/remove is called from a different thread while in the foreach loop.
Converting to list before we do the foreach as a quick fix.
Changelog: [Internal] - quick fix for exception
Issure reported here: https://fb.workplace.com/groups/rn.support/permalink/26557068097248454/
Reviewed By: mdvacca
Differential Revision: D59991739
fbshipit-source-id: a2fcc798430acaadd07561a5be871967cc8f2c3b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45549
## Summary
Calling `getCurrentReactContext` on an unmounted `ReactRootView` could lead to a NPE. The method currently returns a nullable value so return type is the exact same. This change checks if the react instance manager is present and returns null early if not.
## Changelog:
[Android] [Fixed] - Adds a null check in react context getter
Reviewed By: zeyap
Differential Revision: D59982179
fbshipit-source-id: bac5c12e7dc4ee3296991063eb3746141b8446bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45544
## This diff now does 5 things:
1. removes the old way we used `actions/setup-node` to manage the cache itself.
2. it creates a new `update-node-modules-cache` workflow, which is the only job that will update the node modules cache
3. it create a `yarn-install-with-cache` action that should be used install of directly calling `yarn install --non-interactive`. This will load a cache against a hash of `package.json`.
4. updated the cache reaper to aggressively remove everything but the latest `npm-{{ hash('package.json') }}`.
5. removed a `cache-setup`, which couldn't be used (we're using artefacts now).
## Why are we doing this:
The various `node-cache-` keys for platforms and on various branches accounts for a very large proportion of the cache (10-20%).
We don't frequently change these dependencies, and even when we do running `yarn install` after loading the cache will resolve any issues.
Limiting the cache to `main` and aggressively pruning older cache entries will clean up a lot of "small win" caching.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D59917944
fbshipit-source-id: 4be6f1959e8fde642a4f208f7d19aceba2c3262f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45530
Enable viewconfig validation for RNTester to catch where static and native viewconfigs are mismatched, during development or contribution time. This relies on `useNativeViewConfigsInBridgelessMode()` which is already enabled in `DefaultNewArchitectureEntryPoint` on Android, and seems to be in iOS AppDelegate `RCTRootViewFactory` as well.
We put it in an early place in the bundle before first render, since we don't have RNTester preludes right now, but I think it is still early enough?
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D59946366
fbshipit-source-id: ae0c23b13a566489a88a7b4e408f61dce314b003
Summary:
This moves the `helloworld` app to build from the artifacts produced by build_npm_package so that we don't rebuild ReactNative Android from source 8 times.
It reduces build time of such jobs from 14mins to 4mins, resulting in 80mins of build time for every test_all run.
## Changelog:
[INTERNAL] - Move helloworld to build from artifacts on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/45517
Test Plan: CI
Reviewed By: blakef
Differential Revision: D59957613
Pulled By: cortinico
fbshipit-source-id: b6c4adcf804af6c8d2661cf56549d037e09aa2c1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45543
# Changelog:
[Internal]-
Introduced recently, this confuses viewconfig validation vs the vanilla Android view managers.
So this change effectively reverts the exposure of `ScrollView.scrollIndicatorInsets` to Android, achieving the goal in a different way (via the SVC injection workaround for the specific Android platform flavour).
Reviewed By: NickGerleman
Differential Revision: D59960782
fbshipit-source-id: 3b9a49f1466426d909e94bf4d33f1d09fbf822c2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45542
As we do have several version numbers for external actions all across the codebase,
here I'm aligning all of them to just use the majors.
I'm doing it only for GitHub first party actions as we trust them,
so minor/patch changes can safely be pulled in without code changes.
Changelog:
[Internal] [Changed] - Align github/* action versions on major
Reviewed By: cipolleschi, blakef
Differential Revision: D59959978
fbshipit-source-id: bb07ce0dfd74d9502a2ac0ea90a2b32f55d6d655
Summary:
With the migration to GHA, we can remove all the duplicated jobs from CircleCI.
These are the only 4 jobs remained to migrate
## Changelog:
[Internal] - Remove all the jobs already migrated to GHA
Pull Request resolved: https://github.com/facebook/react-native/pull/45219
Test Plan: CCI is green
Reviewed By: cortinico
Differential Revision: D59156888
Pulled By: cipolleschi
fbshipit-source-id: 193f1f8fa7484154d5295ac36a63bb81a159da6e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45541
This is another round of letting react-native-bot do the job that the
generic GitHub Action bot was doing.
Changelog:
[Internal] [Changed] - Act On label as react-native-bot
Reviewed By: cipolleschi
Differential Revision: D59959468
fbshipit-source-id: 8e0f7e2e90a40ed2aa265e637c8a809064e22747
Summary:
Nightly/Release workflow are currently broken due to a wrong path reference to a composite action. This fixes it.
## Changelog:
[INTERNAL] - Fix nightly/release workflow
Pull Request resolved: https://github.com/facebook/react-native/pull/45537
Test Plan: CI
Reviewed By: cipolleschi
Differential Revision: D59959185
Pulled By: cortinico
fbshipit-source-id: 02c556d86105eac35e152b4dc09705bc42c8031a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45533
This input is unused and is causing a warning on the build pipeline.
I'm cleaning it up.
Changelog:
[Internal] [Changed] - Remove unused build-from-source input
Reviewed By: blakef
Differential Revision: D59958184
fbshipit-source-id: 23ba010da077342605afaaee122bc7ceabc89915
Summary:
Added space to $(inherited) string to avoid creation of wrong cpp flags in RCTAppDelegate podspec
<img width="1157" alt="Screenshot 2024-07-18 at 8 51 19 PM" src="https://github.com/user-attachments/assets/29d32d08-e81f-4c25-b8ee-5dccc0f620ea">
## Changelog:
[IOS] [FIXED] - Building of iOS project when RCTAppDelegate is used in the project
Pull Request resolved: https://github.com/facebook/react-native/pull/45520
Test Plan: To test this you can simply change in your node modules and run pod install, the build will now work successfully
Reviewed By: cipolleschi
Differential Revision: D59950906
Pulled By: arushikesarwani94
fbshipit-source-id: 0d58620aa0be7ac4fcbcd309f06df0eef7844016
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45529
`experimental_boxShadow` is not yet part of Android view managers, and when we enable it, we are likely to do a view manager at a time before moving to BaseViewManager.
This causes user-visible errors when viewconfig validation is turned on, since we have a static view config, but not yet a native view config.
This removes the static viewconfig for Android until we start adding setters to view manager.
It is kept in `ReactNativeStyleAttributes` (which I think can have members not in the native view-config, since it has component specific props like tintColor), and iOS base viewconfig. On Fabric iOS, this is part of BaseViewProps, and handled by RCTView, but it looks like the prop (and also `experimental_filter`, `experimental_mixBlendMode`) do not have entries in iOS RCTViewManager, which is fixed in next diff in the stack.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D59939866
fbshipit-source-id: 2781029a0c29ba111ed04edfe9940c6c72f4e5ac
Summary:
Viewconfig processors may still get called for nullish values I think. Most other processors explicitly handle these (but some don't??).
This returns an empty list, like on parse error, when we have a value, but the value is nullish.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D59933611
fbshipit-source-id: 3f1d89d21977bbe01a05e708aadf1a9451d88083
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45512
isBufferingEnabled_ can be read (by design) from multiple threads, but
it's not atomic. Make it so.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D59907026
fbshipit-source-id: ffce54a28404148b3e270fa90dfe850a334ca2f0
Summary:
This PR fixes a case where the user initializes react native in a directory that contains a space.
It was causing pod install to fail because the path to `create-dummy-hermes-xcframework.sh` script wasn't in a string.
## Changelog:
[IOS] [FIXED] - Hermes prepare_command fails with space in path
Pull Request resolved: https://github.com/facebook/react-native/pull/45316
Test Plan:
1. Create a directory with space in path
2. Initialize React Native inside
3. Install pods
4. Check if pod install doesn't fail
Reviewed By: dmytrorykun
Differential Revision: D59912979
Pulled By: cipolleschi
fbshipit-source-id: b2c08d5035a245f8b4d6bfaf562e46d9c5d127b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45501
changelog: [internal]
Implement caching for FabricUIManager::getColor. A call to FabricUIManager::getColor takes on average 0.4ms and there can be many of them. The arguments for the call keep repeating in majority of times. Employing a simple caching mechanism here to avoid unnecessary trips via JNI to reduce overhead.
The dependencies in graphics in BUCK are incorrect. I tried to separate this into multiple files and move implementation to .cpp file but this will require a bit of a more restructuring to make it possible.
Reviewed By: mdvacca, dmytrorykun
Differential Revision: D59859754
fbshipit-source-id: 748efce7f0b8c96001b6ac1a4b457b8c9d63fe9c
Summary:
Factor out the Build NPM package job in a separate action for code reuse
## Changelog:
[Internal] - Factor out the Build NPM package job in a separate action for code reuse
Pull Request resolved: https://github.com/facebook/react-native/pull/45493
Test Plan: GHA are green
Reviewed By: robhogan
Differential Revision: D59858572
Pulled By: cipolleschi
fbshipit-source-id: 561a215ba5812352034157aa254999db56fcd31e
Summary:
With the recent changes to the CI, we need to update the test-e2e-local to work with the new artifacts
## Changelog:
[Internal] - Update local-e2e-test to run with the new Android Artifacts
Pull Request resolved: https://github.com/facebook/react-native/pull/45499
Test Plan: Tested locally.
Reviewed By: blakef
Differential Revision: D59902087
Pulled By: cipolleschi
fbshipit-source-id: 84ef78e8dba222bf8a9e3620632fb2a9d286d42b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45471
Changelog: [internal]
This is a React Native specific modification of the Long Tasks API that refines the logic to detect long tasks considering voluntary yielding checks.
In RN, as opposed to Web, we can have a very long task executing in the JS thread without causing any issues to the responsiveness of the app, as long as the task checks whether it should yield in short intervals. In this case, if the app always checks whether it should yield at least once every 50ms, the task will not be considered "long".
Check the new unit tests to see this behavior in practice.
Reviewed By: sammy-SC
Differential Revision: D55647992
fbshipit-source-id: 82ab41173d4d9deee65b8ade2268c40d7f58c6e2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45473
This is a basic implementation of the Long Tasks API (https://w3c.github.io/longtasks/).
It detects and reports long tasks when using the Event Loop (in the modern RuntimeScheduler) when a new feature flag for this purpose is enabled.
This doesn't include attribution information at the moment.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D55491870
fbshipit-source-id: e1ccad9cc6a35073b31230a8cf3a4660ab9a043d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45492
Changelog: [internal]
When testing the changes in https://github.com/facebook/react-native/pull/45473 / D55491870, I saw that the reported time spans for long tasks didn't perfectly align with the long tasks themselves in traces (Perfetto).
Taking a closer look, I realized that I wasn't doing the conversion between times and durations from `chrono` and `DOMHighResTimeStamp` (a `double`) correctly, and we're doing this conversion very often.
This moves the definition of `DOMHighResTimeStamp` to its own library and adds conversion methods to make sure we don't make this mistake in the future.
Reviewed By: rshest
Differential Revision: D59820241
fbshipit-source-id: c123920de56336da384ddc484f6ac9d287724301
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45464
Previous work would cause versions >= react-native 0.76 to exit if called through `npx react-native <cmd>`. This was intended to be full deprecated and removed. The intention was to shift users to calling react-native-community/cli directly.
This change allows commands to be proxied to react-native-community/cli but with no guarantees of success. It's up to each framework / project to explicitly create that dependency.
This also provides warnings, which won't go away, suggesting the supported method of calling the community CLI directly.
The outcome is that we're not going to break existing workflows.
closes: #45461
Changelog: [General][Fixed] allow proxying commands from react-native to react-native-community/cli with explicit warning
Reviewed By: cortinico
Differential Revision: D59805357
fbshipit-source-id: 21e23b082a9c709effa050d8e7dd04a40f5ab0e6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45483
We don't really use this functionality and is getting harder to migrate to GHA,
hence I'm removing it.
Changelog:
[Internal] [Changed] - Remove report-app-size
Reviewed By: cipolleschi
Differential Revision: D59822862
fbshipit-source-id: 2d082454aea3b3c5863bd34556a23c2fc847f841
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45510
This is just a quality of life improvement, where we test the C++ autolinking
code generation a bit more.
Changelog:
[Internal] [Changed] - Improve tests for GenerateAutolinkingNewArchitecturesFileTask
Reviewed By: blakef
Differential Revision: D59907847
fbshipit-source-id: e6367cc3b1c01700310437b73bc984e3666b3499
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45511
This adds react-native.config.js to autolinking default lockfiles
so autolinking can account for changes in that file.
Changelog:
[Internal] [Changed] - Add react-native.config.js to autolinking lockfiles
Reviewed By: blakef
Differential Revision: D59907268
fbshipit-source-id: d5893a3f7b4d5d9f6c6c13042aa6866ad16b2ea4
Summary:
This change adds a job that runs 2 hours after the nightlies. This jobs returns successfully if the nightly has been published or it report an error in case it has failed.
We will hook this signal to the internal system to be notified about Nightlies failures
## Changelog:
[Internal] - Add jobs to check for nightlies
Pull Request resolved: https://github.com/facebook/react-native/pull/45509
Test Plan: Test the Action on GHA
Reviewed By: blakef
Differential Revision: D59907442
Pulled By: cipolleschi
fbshipit-source-id: 3b35aa2ad69b376c65a765f740a1d6e6ed8ad99f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43333
This change fixes https://github.com/facebook/react-native/issues/43285.
Basically, when using a `yarn` alias to install pods, yarn creates a copy of the `node` and `yarn` executables and the `command -v node` command will return the path to that executable.
## Changelog
[iOS][Fixed] - Do not use temporary node when creating the .xcode.env.local
Reviewed By: dmytrorykun
Differential Revision: D54542774
fbshipit-source-id: 3ab0d0bb441988026feff9d5390dcfd10869a1b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45508
The scripts/clean-gha-cache.js uses the `gh` cli too, which expects the GITHUB_TOKEN presented GH_TOKEN. Also allowed us to manually kick off this workflow.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D59901639
fbshipit-source-id: f3543cc83cbf67b6969abc3390790e038e06c305
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45503
Kebab case object literals are a pain as an API to give folks. Keep string parsing using the kebab-case web names, like in CSS, but keep object notation camelCase.
This is super super hacked up, and we should burn away all these viewconfig processors as soon as we can.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D59793095
fbshipit-source-id: 888cad31142d7aeed42687ab23c2023ac7e4882d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45452
With this we enable <View> to use BoxShadow.
BoxShadow property can be a string as defined on MDN: https://developer.mozilla.org/en-US/docs/Web/CSS/box-shadow
Or it can also be a list of BoxShadow primitives:
```
[
{
offsetX: 10,
offsetY: 5,
color: 'red',
inset: true,
},
{
...
},
]
```
The diff includes:
* Style sheet changes so typing is valid
* Process function to turn boxShadow format into parsed boxShadow primitive
* Test for process function
* View config changes on Android, iOS and ReactNativeStyleAttributes
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D57872933
fbshipit-source-id: 2c5732709959bd996cce2f979549fc95cf2410e2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45481
We are going with this name as it is more commonly used in the spec and makes more sense since there are no circles involved with spread
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D59819180
fbshipit-source-id: cf20c22b11e9ff9935b9f54e28db37d3ea399d8f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45334
Adds support for the `xml` file extension as a loadable asset, and lets Flow treat the type signature as an image
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D58261501
fbshipit-source-id: b29cffee81d0438827529711e86267edd5d2a0f7
Summary:
I'm picking 1630b5c743 in main as it's currently missing (available only on `0.75-stable`).
## Changelog:
[INTERNAL] - Update testing scripts to work with any version of React native
Pull Request resolved: https://github.com/facebook/react-native/pull/45498
Test Plan: Nothing to test as this is a backport
Reviewed By: cipolleschi
Differential Revision: D59861440
Pulled By: cortinico
fbshipit-source-id: 57f642c66c7a6976f5a5cd53debaeb2e461a1f30
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45457
With this change, we are implementing in Android a similar logic that we implemented in iOS.
1. When the user stops dragging a scroll view, it tells native animated modle that a scroll has finished
2. NativeAnimated module asks to the NativeAnimatedNodesModule if there are native node listening to the scroll
3. In case they are, it emits an event to JS
4. JS listen to the events and resync the Shadow Tree and the Native Tree (this implemented in a previous change)
## Changelog
[Android][Fixed] - Sync the Shadow Tree and the Native Tree with Native animation when scroll is driving the animation
Reviewed By: sammy-SC
Differential Revision: D59756577
fbshipit-source-id: e558557b477f4da9da1f89fb31ba86d0ea1390a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45383
This is the second step required to fix the onTouchMove event in the new architecture.
In this change, we are retrieving the list of nodes that are connected by the animation, and we are sending an event to the nodes so that we can trigger the commit.
## Changelog
[iOS][Added] - retrieve the tags of the nodes connected by the animation and send them to JS
Reviewed By: sammy-SC
Differential Revision: D59524617
fbshipit-source-id: 584317afa8e4cf0ad9f98f38e4e5d436c5fe3ac5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45382
This change is the first step to tr and solve the pressability's `onTouchMove` issue with animation driven natively in the New Architecture.
The idea is to trigger a special event from native to let JS know that a scroll event has ended (`scrollViewDidEndDragging` or `scrollViewdidEndDecelerating`).
When this happens, we need to send an event to JS to let him know that it has to sync the Native Tree with the Shadow Tree.
Step 2 is to connect Native with JS
## Changelog:
[iOS][Added] - Send onScrollEnded event to NativeTurboAnimatedModule
Reviewed By: sammy-SC
Differential Revision: D59459989
fbshipit-source-id: cb425cddcdaa9d700ec40accaf4ab3ce1f3c5038
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45495
Unify type definitions to semver@7, to fix a [type-sync](https://www.internalfb.com/intern/test/281475050813096/) test that was broken by D59378011. The test is very simple and doesn't actually understand the typing.
I don't believe there is a significant difference in the typing, esp. with how we're using it. Flow will tell us if this is the case though (🏖️🏰).
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D59855434
fbshipit-source-id: ae3c6b7aa81b3cde25468d72a7922bcb2b6f652f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45478
Some code is far too recursive. This consumes buffer space and causes problems for the Perfetto frontend. Let's limit it to 50 frames.
Changelog: [Internal]
Reviewed By: rubennorte, sammy-SC
Differential Revision: D59813638
fbshipit-source-id: 69068f9c2193d706ec0cc00ffc0d5950ae094e05
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45474
Our actions inputs are now a mixture of different casing.
I'm moving everything to be kebab-case
Changelog:
[Internal] [Changed] - Composite actions inputs should be kebab-case
Reviewed By: cipolleschi
Differential Revision: D59809181
fbshipit-source-id: af6d541c2b4f5fa162dcde412fb8808bae1ef2d3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45480
We currently use the default GITHUB_ACTION which makes a lot of interaction
appear as user "GitHub Actions". Instead we could use the `REACT_NATIVE_BOT_GITHUB_TOKEN`
which we have as secret so the bot will actually perform the actions.
Changelog:
[Internal] [Changed] - Act as react-native-bot on all the actions
Reviewed By: cipolleschi
Differential Revision: D59815201
fbshipit-source-id: 702b121ec07d0db10abf25e23f7ddf5658dd5d62
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45491
The build_android job was missing the sonatype credentials so could not
publish a -SNAPSHOT version. This fixes it.
Changelog:
[Internal] [Changed] - Unbreak nightlies by fixing secrets
Reviewed By: cipolleschi
Differential Revision: D59848810
fbshipit-source-id: 2cc1d03b090d0aeb3886590ec0696f9c3a6556b9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45485
## Changelog:
the new functions I introduced in https://github.com/facebook/react-native/pull/45365 to read color channel value, like `alphaFromColor`, will return float between 0~255 on iOS and 8bit unsigned ints on other platforms, because of different platform implementation. However that way we cannot assume consistent return value across platforms, which kind of contradicts with RN's cross platform design.
so here I make `alphaFromColor` in Color.h (the cross platform method) to always return uint8_t, while still allow `alphaFromHostPlatformColor` to return different result
[Internal] [Fixed] -
Reviewed By: christophpurrer
Differential Revision: D59826142
fbshipit-source-id: 4401918be29980474bdc8601443ae33155710f22
Summary:
FIXES [45404](https://github.com/facebook/react-native/issues/45404)
sending headers from Image component not working in new arch , implementation was missing
```
<Image
source={{
uri: "http://localhost:3000/image",
headers: {
"test-header": 'test',
"hello":"tested"
}
}}
style={{
width: 300,
height: 300,
}}
/>
```
## Changelog:
[IOS] [ADDED]- sending missing **headers** field with **Image** component in fabric
Pull Request resolved: https://github.com/facebook/react-native/pull/45415
Test Plan:
# Tested
Attaching the below video to show how headers are getting received on server from Image component running in new arch
https://github.com/user-attachments/assets/c816265d-0bb5-4670-bde0-cfec72d7618f
Reviewed By: javache, cipolleschi
Differential Revision: D59807462
Pulled By: blakef
fbshipit-source-id: dffa4d80db58de6a81947ac876aa76ec7e62dd48
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45445
Roll our own base64 encoding and revert D59685218, which fixed the missing Folly dependency implied by D54309633.
I assumed Folly base64 was already elsewhere in RN but given it isn't, and we only need simple, non-perf-sensitive encoding for the debugger (not the SIMD or delegated implementations, or decoding), it might be best to just include our own encoder.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D58323859
fbshipit-source-id: 5ce98561e9ced82765e8e7c18e5d2ebfa8148c8c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45468
This should greatly reduce the time spent on build_npm_package
because we're moving all the publishing logic to build_android.
I need to do a bit more testing with nightlies to make sure that everything is published correctly.
Changelog:
[Internal] [Changed] - Make build_android publish to the stating repositories
Reviewed By: cipolleschi
Differential Revision: D59804015
fbshipit-source-id: be3f0b6e16f5fdbf760ec7a5e16c8e258e06dd28
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45426
The initial implementation of `Network.loadNetworkResource` and the accompanying `IO.read` (D54202854) base64-encodes all data as if it is binary. This is the more general case, and we'll continue to base64-encode non-text resources.
In the common case of text resources (particularly JS and JSON), it'd be preferable to do as Chrome does and send UTF-8 over the wire directly. This has a few performance benefits:
- Less CPU and RAM footprint on device (UTF-8 truncation is constant-time, fast, and in-place), similarly less decoding for the frontend.
- 25% less data per chunk (base64 encodes 3 bytes as 4 characters), implies up to 25% fewer network round trips for large resources.
It also has the benefit of being human-readable in the CDP protocol inspector.
## Determining whether data is text
We use exactly Chromium's heuristic for this (code pointers in comments), which is based only on the `Content-Type` header, and assuming any text mime type is UTF-8.
## UTF-8 truncation
The slight implementation complexity here is that `IO.read` requests may specify a maximum number of bytes, and so we must slice a raw buffer up into valid UTF-8 sequences. This turns out to be fairly simple and cheap:
1. Naively truncate the buffer, inspect the last byte
2. If the last byte has topmost bit =0, it's ASCII (single byte) and we're done.
3. Otherwise, look back at most 3 bytes to find the first byte of the code point (topmost bits 11), counting the number of "continuationBytes" at the end of our buffer. If we don't find one within 3 bytes then the string isn't UTF-8 - throw.
4. Read the code point length, which is encoded into the first byte.
5. Resize to remove the last code point fragment, unless it terminates correctly exactly at the end of our buffer.
## Edge cases + divergence from Chrome
Chrome's behaviour here in at least one case is questionable and we intentionally differ:
- If a response has header "content-type: text/plain" but content eg`0x80` (not valid UTF-8), Chrome will respond to an `IO.read` with `{ "data": "", "base64Encoded": false, "eof": false }`, ie an empty string, but will move its internal pointer such that the next or some subsequent `IO.read` will have `"eof": true`. To the client, this is indistinguishable from a successfully received resource, when in fact it is effectively corrupted.
- Instead, we respond with a CDP error to the `IO.read`. We do not immediately cancel the request or discard data, since not all `IO.read` errors are necessarily fatal. I've verified that CDT sends `IO.close` after an error, so we'll clean up that way (this isn't strictly guaranteed by any spec, but nor is `IO.close` after a resource is successfully consumed).
Changelog:
[General][Added] Debugger: Support text responses to CDP `IO.read` requests
Reviewed By: hoxyq
Differential Revision: D58323790
fbshipit-source-id: def8bf8426266f16bb305d836a6efe8927a9dfc4
Summary:
When running the entire unit test suite of `RNTesterPods` with `TSan`, I saw that occasionally a data race was detected on line 843 of `RCTImageLoader`. It seems the completion handler that does contain the lock around `cancelLoad` is called concurrently with the value being assigned on line 843. Here there is no lock in place.
Here is the output of `TSan` when I comment out my fix:
```
WARNING: ThreadSanitizer: data race (pid=72490)
Write of size 8 at 0x000144151ce8 by main thread:
#0 -[RCTImageLoader loadImageWithURLRequest:size:scale:clipped:resizeMode:priority:attribution:progressBlock:partialLoadBlock:completionBlock:] <null> (RNTesterUnitTests:arm64+0x16e8030)
https://github.com/facebook/react-native/issues/1 -[RCTImageLoader loadImageWithURLRequest:size:scale:clipped:resizeMode:priority:progressBlock:partialLoadBlock:completionBlock:] <null> (RNTesterUnitTests:arm64+0x16df8dc)
https://github.com/facebook/react-native/issues/2 -[RCTImageLoader loadImageWithURLRequest:size:scale:clipped:resizeMode:progressBlock:partialLoadBlock:completionBlock:] <null> (RNTesterUnitTests:arm64+0x16df534)
https://github.com/facebook/react-native/issues/3 -[RCTImageLoaderTests testImageLoaderUsesImageURLLoaderWithHighestPriority] <null> (RNTesterUnitTests:arm64+0x7cb8)
https://github.com/facebook/react-native/issues/4 __invoking___ <null> (CoreFoundation:arm64+0x13371c)
Previous write of size 8 at 0x000144151ce8 by thread T4 (mutexes: write M0):
#0 __140-[RCTImageLoader loadImageWithURLRequest:size:scale:clipped:resizeMode:priority:attribution:progressBlock:partialLoadBlock:completionBlock:]_block_invoke_2 <null> (RNTesterUnitTests:arm64+0x16e8894)
https://github.com/facebook/react-native/issues/1 __139-[RCTImageLoader _loadImageOrDataWithURLRequest:size:scale:resizeMode:priority:attribution:progressBlock:partialLoadBlock:completionBlock:]_block_invoke <null> (RNTesterUnitTests:arm64+0x16e3430)
https://github.com/facebook/react-native/issues/2 __139-[RCTImageLoader _loadImageOrDataWithURLRequest:size:scale:resizeMode:priority:attribution:progressBlock:partialLoadBlock:completionBlock:]_block_invoke_3 <null> (RNTesterUnitTests:arm64+0x16e52a8)
https://github.com/facebook/react-native/issues/3 __75-[RCTImageLoaderTests testImageLoaderUsesImageURLLoaderWithHighestPriority]_block_invoke_2 <null> (RNTesterUnitTests:arm64+0x7f24)
https://github.com/facebook/react-native/issues/4 -[RCTConcreteImageURLLoader loadImageForURL:size:scale:resizeMode:progressHandler:partialLoadHandler:completionHandler:] <null> (RNTesterUnitTests:arm64+0x6c470)
https://github.com/facebook/react-native/issues/5 __139-[RCTImageLoader _loadImageOrDataWithURLRequest:size:scale:resizeMode:priority:attribution:progressBlock:partialLoadBlock:completionBlock:]_block_invoke.172 <null> (RNTesterUnitTests:arm64+0x16e4964)
https://github.com/facebook/react-native/issues/6 __tsan::invoke_and_release_block(void*) <null> (libclang_rt.tsan_iossim_dynamic.dylib:arm64+0x77ee0)
https://github.com/facebook/react-native/issues/7 _dispatch_client_callout <null> (libdispatch.dylib:arm64+0x3974)
Location is heap block of size 48 at 0x000144151cc0 allocated by main thread:
#0 malloc <null> (libclang_rt.tsan_iossim_dynamic.dylib:arm64+0x4fa48)
https://github.com/facebook/react-native/issues/1 _malloc_type_malloc_outlined <null> (libsystem_malloc.dylib:arm64+0xf3ec)
https://github.com/facebook/react-native/issues/2 _call_copy_helpers_excp <null> (libsystem_blocks.dylib:arm64+0x10b4)
https://github.com/facebook/react-native/issues/3 -[RCTImageLoader loadImageWithURLRequest:size:scale:clipped:resizeMode:priority:progressBlock:partialLoadBlock:completionBlock:] <null> (RNTesterUnitTests:arm64+0x16df8dc)
https://github.com/facebook/react-native/issues/4 -[RCTImageLoader loadImageWithURLRequest:size:scale:clipped:resizeMode:progressBlock:partialLoadBlock:completionBlock:] <null> (RNTesterUnitTests:arm64+0x16df534)
https://github.com/facebook/react-native/issues/5 -[RCTImageLoaderTests testImageLoaderUsesImageURLLoaderWithHighestPriority] <null> (RNTesterUnitTests:arm64+0x7cb8)
https://github.com/facebook/react-native/issues/6 __invoking___ <null> (CoreFoundation:arm64+0x13371c)
Mutex M0 (0x000108f316e8) created at:
#0 pthread_mutex_init <null> (libclang_rt.tsan_iossim_dynamic.dylib:arm64+0x2cc98)
https://github.com/facebook/react-native/issues/1 -[NSLock init] <null> (Foundation:arm64+0x5ca14c)
https://github.com/facebook/react-native/issues/2 -[RCTImageLoader loadImageWithURLRequest:size:scale:clipped:resizeMode:priority:progressBlock:partialLoadBlock:completionBlock:] <null> (RNTesterUnitTests:arm64+0x16df8dc)
https://github.com/facebook/react-native/issues/3 -[RCTImageLoader loadImageWithURLRequest:size:scale:clipped:resizeMode:progressBlock:partialLoadBlock:completionBlock:] <null> (RNTesterUnitTests:arm64+0x16df534)
https://github.com/facebook/react-native/issues/4 -[RCTImageLoaderTests testImageLoaderUsesImageURLLoaderWithHighestPriority] <null> (RNTesterUnitTests:arm64+0x7cb8)
https://github.com/facebook/react-native/issues/5 __invoking___ <null> (CoreFoundation:arm64+0x13371c)
Thread T4 (tid=10935088, running) is a GCD worker thread
```
## Changelog:
[iOS][Fixed] Data race in `RCTImageLoader` related to assignment of cancellation block.
Pull Request resolved: https://github.com/facebook/react-native/pull/45454
Test Plan: There are already tests in place for `RCTImageLoader`. I hope these will cover the fix.
Reviewed By: realsoelynn
Differential Revision: D59816000
Pulled By: zeyap
fbshipit-source-id: f959d472eb60f83f39ced6711ee395949ab37e7c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45479
This just prints a summary on PRs if the Gradle task fails so it's easier to jump directly
to the failure.
Changelog:
[Internal] [Changed] - Enable add-job-summary-as-pr-comment for failed jobs
Reviewed By: cipolleschi
Differential Revision: D59812845
fbshipit-source-id: 2069a1c8db7d264ca1af3c1182fa443cb0a69646
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45469
Enables React Native DevTools by default on `main`, ahead of the 0.76 release. We've observed no new bug reports internally over the last two weeks, and are moving forward with our rollout plan.
Changelog: [Internal]
Reviewed By: blakef
Differential Revision: D59804882
fbshipit-source-id: 0cb6302f4d940718786db2e5d8fb652fae6a8c54
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45475
Instead of zipping all the RNTester's APK together, let's
upload them per buildVariant so it's easier to retrieve them later.
Changelog:
[Internal] [Changed] - Split the rntester APK artifacts in 4
Reviewed By: cipolleschi
Differential Revision: D59809721
fbshipit-source-id: 2d375475d5cee71c212f4d1f3a4a9edf3442358f
Summary:
We don't need to specify a minor/patch for actions/upload-artifact.
We also have all sorts of different versions scattered around the codebase.
This aligns them to the latest sable in the 4.x series.
Changelog:
[Internal] [Changed] - actions/upload-artifact to v4.x
Reviewed By: cipolleschi
Differential Revision: D59811525
fbshipit-source-id: 7264db097bcb2ff34b3ace467996e8308c0f2034
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45463
Changelog: [Internal]
State updates will clone shadow nodes for an shadow tree revision that is outdated.
This can lead to accessing deallocated shadow node references because the JS renderer committed a newer revision and deallocated the one used by the pending state update.
By using a weak pointer to hold a reference to the runtime shadow node reference, we can only update references for wrappers that are still valid.
Reviewed By: javache
Differential Revision: D59804999
fbshipit-source-id: 89c9967d139d3cac7d7252994beae419bc591e79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45413
## Changes
Add an example in RNTester to test that pressability with NativeDrivers works properly.
## Context
The pressability handling is a bit peculiar.
We have to handle 3 main behaviors:
* `PressIn` -> `PressOut` => triggers the `onPress`
* `PressIn` -> move inside the rectangle -> `PressOut` => triggers the `onPress`
* `PressIn` -> move outside the rectangle -> `PressOut` => cancel `onPress`.
For the first case, we detect whether the press happens inside a component in the Native layer only. And everything works.
When a move is involved, we:
1. Detect the initial press in the Native layer
2. We move the coursor and we delegate the detection of whether we are inside of a rect or not to the JS layer
3. The JS layer asks the C++ layer about the layout and decide whether we are in case 2 (move but still inside the rect) or in case 3 (move but outside the rect).
The problem is that with `nativeDriver` and animations, the C++ layer doesn't know about where the receiver view actually is.
This results in issues like the one shown by [#36504](https://github.com/facebook/react-native/issues/36504), where the onMove is not handled correctly.
## Solution
The solution is to keep detecting whether we are in the receiver view or not in the Native layer and pass the receiver view position and size back to JS so that the JS layer don't have to jump to C++ to make this decision.
We decided to pass the frame information because the JS layer is adding some padding and configurations to the final rectangle and we don't want to lose those configurations.
## Changelog
[General][Added] - Add example in RNTester to show that pressability works properly with NativeDrivers
Reviewed By: sammy-SC
Differential Revision: D58182480
fbshipit-source-id: 9ca4fb9a3ca1a8af52ccbe208cbfe8434175f87d
Summary:
CCI on main is broken. We suspect that's due to cache issues which restore a wrong layout for the Folly pod.
This PR is an attempt to fix it
## Changelog:
[Internal] - Fix missing folly base 64
Pull Request resolved: https://github.com/facebook/react-native/pull/45460
Test Plan: CCI and GHA are green
Reviewed By: sammy-SC, huntie
Differential Revision: D59804748
Pulled By: cipolleschi
fbshipit-source-id: 44d6b169cf3319f4d7ee9e0a5833f07bc6ba4bb3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45458
Checking for packager is an async operation, which may return when we've already destroyed the ReactInstanceManager. Prevent the CatalystInstance from being created if the ReactInstanceManager has been invalidated.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D59753247
fbshipit-source-id: e3ac2b6dd142330e2d4051519b9863584b33f8a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45459
Seeing failures on main with GHA for gradle builds, in the Post Setup gradle step:
```
Could not get unknown property 'cleanupTime' for object of type org.gradle.api.internal.cache.DefaultCacheConfigurations.
```
This is a speculative change to get CI back to stable.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D59802517
fbshipit-source-id: c7b5259397fddef9420570043263e92f21718934
Summary:
This change factors out build-android job so we can reuse it
## Changelog:
[Internal] - Factor out the build-android job for code reuse
Pull Request resolved: https://github.com/facebook/react-native/pull/45455
Test Plan: GHA are green
Reviewed By: blakef
Differential Revision: D59802116
Pulled By: cipolleschi
fbshipit-source-id: 12ece8004da3bfd1f275b4af8e9822d4b0ccc0f0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45448
changelog: [internal]
I would like to experiment with executing insert mount instructions after layout and state update. It has shown small improvement in local testing
Reviewed By: mdvacca
Differential Revision: D59582123
fbshipit-source-id: 3ee6ec12a533a287ed32f7373863175f3a107548
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45410
changelog: [internal]
For better performance, let's test setting up the animation graph from passive effects. This will delay the work, not blocking the paint.
Reviewed By: rubennorte
Differential Revision: D59644374
fbshipit-source-id: ff951ee7c1a1d47e13c55fc7c7f6c0690aa465f7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45444
## Changelog:
[Internal] -
Even though `ScrollView.scrollIndicatorInsets` isn't supported on the vanilla Android platform, it still may be used on some other variations of it, which means that the changes may not potentially find the way into C++/Fabric, opening a door of all kinds of weird corner case issues.
Reviewed By: christophpurrer
Differential Revision: D59761458
fbshipit-source-id: 4dae5c96791ca924d589a3d803d8fa60fdca1b67
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45304
Add support for most keyword values of mix-blend-mode on iOS and added RNTester Example
Missing compositing operators and global values
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D59402969
fbshipit-source-id: b7e1aaed01fbf8f80e04ad0fa73d2ef63b5ad933
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45306
Adding missing drop-shadow test to rn-tester.
Added with alpha-hotdog image to show we are creating the shadow with the alpha channel of the view.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D59410148
fbshipit-source-id: 5a03ee84313979f99585b8ca7e07abf9cdbe2396
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45443
We are only building these out for Fabric. This means only one natural iOS impl, but that other Android bits will not work fully correctly on Paper (like setting containing block for filter element). This also means we can remove view configs once we're on Fabric CSS parser. We will do the same for boxShadow once that is ready.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D59762282
fbshipit-source-id: 14ce07f04b822c6aee908894c9081419594fc484
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45421
RNTester contains Android resources that are loaded by name and not resolved by Metro. As a result, these assets are not automatically linked when RNTester JS code is embedded in other projects. This is considered "legacy" loading and is generally discouraged, but is still showcased as an alernative way of loading resources.
I also modified the Image test to ensure that flag status is printed so it's obvious why the vector drawable hasn't loaded.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D59585555
fbshipit-source-id: d42fb44d8846d8e7c7aa01dca4cec89ae85a9195
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45442
This deprecates also `DeveloperSettings.isStartSamplingProfilerOnInit`
so we can remove it in a future version of React Native.
This field is unused so you should not be using it at all.
Changelog:
[Android] [Changed] - Deprecate DeveloperSettings.isStartSamplingProfilerOnInit
Reviewed By: blakef
Differential Revision: D59757500
fbshipit-source-id: dc879ba46f2f937e5f259a4101646c2f060db548
Summary:
## Summary
Now that HostContext determination for Fabric is a DEV-only behavior, we
can move the HostContext determination to resolve from the ViewConfig
for a given type. Doing this will allow arbitrary types to register
themselves as potential parents of raw text string children. This is the
first of two diffs for react as we'll:
1. Add the new property to the ViewConfig types
2. Update React Native to include the `supportsRawText` property for
`RCTText`, `RCTVirtualText`, `AndroidTextInput`, etc.
3. Switch the behavior of react to read from the ViewConfig rather than
a static list of types.
Changelog: [Internal]
## Test Plan
- yarn test
- yarn test --prod
- Pulled change into react-native, added `supportsRawText` props to
RCTText, RCTVirtualText, etc. ViewConfigs and confirmed everything type
checks.
DiffTrain build for commit https://github.com/facebook/react/commit/a5cc797b8801dfe58c7a34c99a9fa60c6c9c8274.
bypass-github-export-checks
Reviewed By: poteto
Differential Revision: D59641180
Pulled By: rozele
fbshipit-source-id: a3ddb1bc810a70d5f782e708cb845e3eae136d78
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45365
## Changelog
As a followup to https://github.com/facebook/react-native/pull/45139
There I only implemented `hostPlatformColorFromRGBA` and `alpha/red/green/blueFromHostPlatformColor` on cxx platform, then used cxx platform specific method at some places. but really I should implement and use methods in `Color.h` that are platform agnostic
* cxx/android: platform color format is int32_t, RGBA are 8bit unsigned int ([0,255])
* windows: platform color format is `winrt::Windows::UI::Color` where RGBA props are 8bit unsigned ints ([0,255])
* apple: platform color format is `UIColor` where RGBA props are floats in [0,1]
[Internal]
previous change D58872165
Reviewed By: christophpurrer
Differential Revision: D59593659
fbshipit-source-id: 5d18419039817510e607d4e3f632c207d25c30a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45436
changelog: [internal]
In D58355433, delete tree experiment was cleaned up. These are the remainings of the experiment that are no longer used. Let's delete them to clean up dead code
Reviewed By: javache
Differential Revision: D59732137
fbshipit-source-id: a22c0b14eda70e62817e80224f367ccb9006acc9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45354
Fresco has indicated that they have no plans to support loading vector assets and similar drawable types in Drawee-backed views ([issue](https://github.com/facebook/fresco/issues/329), [issue](https://github.com/facebook/fresco/issues/1463), [issue](https://github.com/facebook/fresco/issues/2463)). Guidance has been to instead load the vector drawable onto the backing image view ourselves. On the React Native side, having the ability to load vector drawables has been requested many times ([issue](https://github.com/facebook/react-native/issues/16651), [issue](https://github.com/facebook/react-native/issues/27502)).
I went this route over using a custom Fresco decoder for XML assets because vector drawables are compiled down into binary XML and I couldn't find a trivial, performant way to parse those files in a context-aware manner. This change only accounts for vector drawables, not any of the other XML-based drawable types (layer lists, level lists, state lists, 9-patch, etc.). Support could be added easily in the future by expanding the `getDrawableIfUnsupported` function.
## Changelog
[Android] [Added] - Added support for rendering XML assets provided to `Image`
Reviewed By: javache
Differential Revision: D59530172
fbshipit-source-id: 3d427c06238287e0a3b7f9570ac20e43d76126c7
Summary:
This is just a minor nit to make it easier to copy-n-paste
## Changelog:
[INTERNAL] - Remove extra dot from close-pr.yml
Pull Request resolved: https://github.com/facebook/react-native/pull/45441
Test Plan: N/A
Reviewed By: cipolleschi
Differential Revision: D59752879
Pulled By: cortinico
fbshipit-source-id: caa398010b64024e2a0259d177762fd76082507f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45440
We only have one type of JavaScriptException anymore, so this can be simplified.
Changelog: [Android][Removed] Removed HasJavascriptExceptionMetadata as a marker interface. Use JavascriptExecption directly
Differential Revision: D57379390
fbshipit-source-id: a088834fddb156ceed5ccc8010d3c4acd365bf29
Summary:
The rn-tester android build assumes the react-native-community/cli is available. This is no longer the case.
Changelog: [Internal]
Differential Revision: D59170923
Pulled By: blakef
fbshipit-source-id: 6f414c2be387ef46dd50ce09a98beb230c8e73b9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45420
Devex improvement to skip validation when no native view config exists. Redbox is still hit, showing the true error. See test plan below before/after
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D59702501
fbshipit-source-id: 9aada9813c2930ee2b4bb23e5ba8a3e546c4e9af
Summary:
This change factors out the build hermesc windows job into a separate action to reuse the code in different jobs
## Changelog:
[Internal] - Factor out build hermesc windows for code reuse
Pull Request resolved: https://github.com/facebook/react-native/pull/45432
Test Plan: GHA are green
Reviewed By: blakef
Differential Revision: D59748955
Pulled By: cipolleschi
fbshipit-source-id: bb6b96c93ec7ba6af1a210511ec672907f237b45
Summary:
Call the react-native-community/template GHA to trigger a new release when we publish a react-native release. This then waits to confirm that the package is published.
See react-native-community/template#36 for the matching change
Changelog: [General][Added] trigger template publish
Pull Request resolved: https://github.com/facebook/react-native/pull/45327
Test Plan: Not sure on the best way forward here.
Reviewed By: cipolleschi
Differential Revision: D59467829
Pulled By: blakef
fbshipit-source-id: 091269e7ecdae5801ac7c03a1ede54452ae99b24
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45423
I noticed while fixing some CI issues that `jsinspector` emits a bunch of warnings, making finding errors (especially in CI logs) awkward.
Also fix up a couple of stale comments from earlier designs of `NetworkIOAgent`.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D59693730
fbshipit-source-id: d032150787bda320b9c38ccf2e95139411758f47
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45380
Removed the use of version checking and error code that is in react-native-community/cli-tools.
Changelog:
[Internal] [Changed] - Removed community-cli-plugin version & error dependencies
Reviewed By: robhogan
Differential Revision: D59378012
fbshipit-source-id: b009edc615b873ff2bff31296ac5d87a4482944f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45381
Removing the remaining dependencies from the react-native-community/*. This
inlines a copy of the logger.
Changelog:
[Internal][Changed] Removed react-native-community/cli-tools logger dependency
Reviewed By: cipolleschi
Differential Revision: D59378011
fbshipit-source-id: ef93d9fff1c623658e33c36b6329f5d548f649e8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45409
Changelog: [internal]
This removes `BridgelessJSCallInvoker` in favor of `RuntimeSchedulerCallInvoker`. This change should be transparent when not invoking JS callbacks using priorities, as both of them would just go directly to the scheduler using `scheduleWork`, but when priorities are specified, they'd now be honored in `RuntimeSchedulerCallInvoker`.
I realized this wasn't being used when I saw that `PerformanceObserver` callbacks were always scheduled with the highest priority, instead of with idle priority as specified in code.
Reviewed By: sammy-SC
Differential Revision: D59679512
fbshipit-source-id: 51d36d56ef1ff0b34e5157ed7b5e08de0a3884d2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45387
This diff prepares an experiment to test `setNativeProps` for syncing the final state of native driven animations with Fabric.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D59634489
fbshipit-source-id: 453c5a2f0edfea695f7564e0c5ead58db21cf61e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45337
tsia. Some things to consider when reviewing:
* Made a new drawable for inset shadows
* The drawable in this class is the same size as the view with some padding. The padding is needed for 2 reasons
* Blur near edges looks good
* Blur artifacts can appear inside the view if the clear region barely exits the bounds of the view
* We draw the clear shape with another drawable, which solely exists so that we can get the border box path for the adjust border. We just use this path to clip out the shadow
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D59300215
fbshipit-source-id: 30acc7aafd82122aa278a42d06418bb1079ca71f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45408
Changelog: [General][Fixed] Fixed prioritization of idle priority tasks
We recently found out that idle priority tasks were never scheduled with the lowest priority possible. We didn't realize before because idle priority tasks weren't used, but now they are via `requestIdleCallback` and other mechanisms.
The problem was that the timeout for idle priority tasks was `std::chrono:milliseconds::max()`, and we compute the expiration time adding that to the current time. Doing that operation is always guaranteed to overflow, and the resulting expiration time was always in the past, resulting in the task having higher priority than any other tasks with any other priorities.
Instead of using `max()` we can just use a sensible value for idle priorities. In this case, 5 minutes should be more than enough.
Reviewed By: sammy-SC
Differential Revision: D59679513
fbshipit-source-id: 6c0f9e275818737ce804f05615c01f7ea6c126ab
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45396
This diff extends TransformOrigin with a new method to serialize this Struct into a folly::dynamic map (similar to Transform)
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D59613247
fbshipit-source-id: 00e4a08d1a99fe9cabb67206e21712e65b355f7f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45417
Add sources for `folly::detail::base64` to our existing `folly` dependency for Android and iOS OSS build toolchains, now a (tiny) dependency of the JS debugger since D54309633, and already part of Folly's Buck sources.
Changelog: [Internal]
Reviewed By: cipolleschi, blakef
Differential Revision: D59685218
fbshipit-source-id: bac33402927f310bf867d2c47b4ebbb9276cf545
Summary:
Fixes: https://github.com/facebook/react-native/issues/43413
This pull request addresses an issue on Android where the text selection was not working when both `selectTextOnFocus` and `autoFocus` were set to true on TextInput.
`ReactTextInputManager` was calling `setSelectAllOnFocus` on `ReactEditText` before its onLayout is called causing text selection to not work on auto focus.
Changes Made
- Added logic to wait for the ReactEditText view's layout to be drawn before attempting to select the text.
On the first layout pass, the code now explicitly calls selectAll() to select the text.
- Implemented a check to ensure selectAll() is only called during the first layout pass, avoiding unnecessary calls on subsequent layout passes.
Impact
This change ensures that text selection is properly triggered when selectTextOnFocus and autoFocus are both enabled, improving the user experience and making text input behavior consistent and reliable.
## Changelog:
[ANDROID] [FIXED]: fixed select text on auto focus for TextInput
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/45004
Test Plan:
| Before | After |
|--------|--------|
|  |  |
Reviewed By: javache
Differential Revision: D59448600
Pulled By: cortinico
fbshipit-source-id: 8a594d3193f227ba2d64b808d905bab8b3d24e9b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45407
This bumps to the latest minor of Gradle
Changelog:
[Android] [Changed] - Gradle to 8.9
Reviewed By: NickGerleman
Differential Revision: D59677575
fbshipit-source-id: 05b9afc6f32a9cd11461bc04522d1e522644867e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44845
## Design
- `NetworkIOAgent` is owned by the `HostAgent`.
- `NetworkIOAgent` is passed any CDP requests not handled by the `HostAgent` itself, and before delegating to `InstanceAgent`.
- It handles:
- [`Network.loadNetworkResource`](https://chromedevtools.github.io/devtools-protocol/tot/Network/#method-loadNetworkResource)
- [`IO.read`](https://chromedevtools.github.io/devtools-protocol/tot/IO/#method-read)
- [`IO.close`](https://chromedevtools.github.io/devtools-protocol/tot/IO/#method-close)
- `NetworkIOAgent.loadNetworkResource` creates a `Stream` corresponding to a single resource download/upload. A reference is held in a map `streams_` until an error, the agent is disconnected (destroyed) or it is discarded by the frontend with `IO.close`.
- `delegate.loadNetworkResource` is called with a `stream`-scoped executor, which it uses to call back with headers, data and errors.
- Callbacks for `IO.read` requests are held by the `Stream` until the incoming data is complete or enough data is available to fill the request (an implementation choice to optimise for fewest round trips). Any incoming data or error causes any pending requests to be rechecked.
{F1719616688}
## Unimplemented platforms
- Platforms may optionally implement `HostTargetDelegate.networkRequest` (as of this diff, none do). If they don't we report a CDP "not implemented" error, similar to the status quo where it was unimplemented by the C++ agent.
Changelog:
[General][Added] Debugging: implement common C++ layer of CDP `Network.loadNetworkResource`
Reviewed By: motiz88
Differential Revision: D54309633
fbshipit-source-id: 51e416e9d537b253f72693952d5fd520b6ae11b6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45384
changelog: [internal]
add a little more information to the mounting instructions block
Reviewed By: javache, rubennorte, mdvacca
Differential Revision: D59631537
fbshipit-source-id: 140ba1834172686998c51a9645ea1e66fff1879d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45398
Accidentally left in a value (that Phabricator then hid) which I was using to test fixed prerelease constants in D59141948... On real releases, this is overwritten by the version stamping process.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D59668218
fbshipit-source-id: 3d04e52db75a5d8a53cf47d3a2f88b643030d94e
Summary:
This change factors out the Build HermesC for Linux job so that we can reuse the code in various workflows
## Changelog:
[Internal] - Factor out build-hermesc-linux for code reuse
Pull Request resolved: https://github.com/facebook/react-native/pull/45402
Test Plan: GHA are green
Reviewed By: cortinico
Differential Revision: D59673895
Pulled By: cipolleschi
fbshipit-source-id: f5c680d523866442d25317e880b4803ac89c3741
Summary:
After `pod install`, it would set some empty flags, which seems useless. cc cipolleschi .

## Changelog:
[IOS] [FIXED] - Don't set empty string when remove ccache
Pull Request resolved: https://github.com/facebook/react-native/pull/45400
Test Plan: No empty flags should be set after we exec `pod install`.
Reviewed By: cortinico
Differential Revision: D59671357
Pulled By: cipolleschi
fbshipit-source-id: 26b55da9efaeed36876649cc27f09ecafaba412a
Summary:
In recent commits, some new targets have been added, and they are not exposed as prefabs, yet are used in e.g. `TextLayoutManager`. They are needed then for `react-native-live-markdown`: https://github.com/Expensify/react-native-live-markdown/pull/428/commits/c1611cd98ed5009fd66c871b9999b55941086af0
## 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] [ADDED] - expose prefabs for newly added targets
Pull Request resolved: https://github.com/facebook/react-native/pull/45386
Test Plan: It cannot be tested inside the repo, but try to build the `example` app with new arch enabled on `Android` in the `react-native-live-markdown` repo to see that those are needed.
Reviewed By: NickGerleman
Differential Revision: D59638801
Pulled By: cortinico
fbshipit-source-id: 3d09507d72a0c4d3dbb3a2a81b753625230a04a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45389
This undos a breaking change with ResourceDrawableIdHelper for Kotlin consumer.
I've re-added a `getInstance` method so that Kotlin libraries won't break.
The method is added as Deprecated as those libraries need to migrate to `.instance`
accessors as more idiomatic.
Changelog:
[Android] [Fixed] - Undo a breaking change with ResourceDrawableIdHelper.instance
Reviewed By: robhogan
Differential Revision: D59638043
fbshipit-source-id: ae2aab962e9a7676f0bfbae21f699e274502dc6a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45390
This undos a breaking change with I18nUtil for Kotlin consumer.
I've re-added a `getInstance` method so that Kotlin libraries won't break.
The method is added as Deprecated as those libraries need to migrate to `.instance`
accessors as more idiomatic.
Changelog:
[Android] [Fixed] - Undo a breaking change with I18nUtil.instance
Reviewed By: alanleedev
Differential Revision: D59638044
fbshipit-source-id: 1c93a98676b5b01e89be3b974961c5f3ae919511
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45388
This undos a breaking change we're about to ship in 0.75, where Kotlin users
where forced to update this callsite to be `.getEntryIterator`.
This re-introduces a `entryIterator` val so both Kotlin and Java compatibility are retained.
Changelog:
[Android] [Fixed] - Undo breaking change for ReadableMap.entryIterator for Kotlin consumers
Reviewed By: alanleedev
Differential Revision: D59637925
fbshipit-source-id: b674df86e056f17791d9cabe28557529886f1c93
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45378
Kotlin consumers of those APIs are forced with this breaking change:
```
# Before thanks to Java property conversion
Dynamic.type
# After
Dynamic.getType()
```
This restores the old more idiomatic API by moving those 2 funcitons to be vals.
Changelog:
[Android] [Fixed] - Undo breaking change on Dynamic.type and Dynamic.isNull
Reviewed By: javache
Differential Revision: D59631783
fbshipit-source-id: 8d720af34e104ee0e4f3120302a4a84fc17a7b1c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45392
In this diff I'm introducing a new overload of Systrace.beginSection to receive arguments by parameter
changelog: [Android][Added] Introduce Systrace.beginSection with arguments
Reviewed By: sammy-SC
Differential Revision: D59639329
fbshipit-source-id: 23d43e5dd48fdde9c7d49a1c10fa9ecc4c3b7196
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45385
We ran various experiments with this flag, and this does not turn out to provide any significant benefits at this point to make it worth the complexity and platform divergence it introduced.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D58355433
fbshipit-source-id: 4b857a5d0b8aa5915b4a880cbcae2526a16a08a9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45324
Improve concurrency during startup of bridgeless by concurrently initializing eager native modules and triggering bundle load.
Changelog: [Android][Changed] Modules marked with needsEagerInit = true will now be created on the mqt_native thread.
Reviewed By: mdvacca
Differential Revision: D59465977
fbshipit-source-id: 55cc0f0359bafcf32dc538f4346c6a5d5546f658
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45376
This reduces one breaking change users are seeing on `CatalystInstance.getJsCallInvokerHolder`.
I had to specify:
```
Suppress("INAPPLICABLE_JVM_NAME")
get:JvmName("getJSCallInvokerHolder")
```
as the Kotlin compiler is unhappy with me setting a JvmName on a interface property.
More on this here: https://youtrack.jetbrains.com/issue/KT-31420
Changelog:
[Android] [Fixed] - Undo breaking change on `CatalystInstance.getJsCallInvokerHolder`
Reviewed By: javache
Differential Revision: D59631640
fbshipit-source-id: 4d5b3499e4e0e0bec1d380c4b7942ea28ae35465
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45374
This change factors out the language standard in a separate constant so we can easily control it from a single place.
There are only 2 exception to this:
1. hermes-engine: the podspec is used in CI and it has no access to the rct_cxx_language_standard variable
2. Yoga: it can be used as a separate pod, outside of React Native, so it makes sense to leave it alone.
This change also fixes a problem where, in some setup, the language was set to C++14
## Changelog
[Internal] - Refactor Cxx language standard in a single constant
Reviewed By: dmytrorykun, blakef
Differential Revision: D59629061
fbshipit-source-id: 41eac64e47c14e239d8ee78bd88ea30af244d695
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45322
Instead of using multiple weak_ptr and weak_ref, use a single weak_ref to the Java object and use that to get back to the original C++ instance, without the need for additional shared_ptr.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D59465976
fbshipit-source-id: d410bdacf21a1886c6ed95d2c57ac8c6e17428e3
Summary:
Factor out the build-hermes-macos job to reuse the code
## Changelog:
[Internal] - Factor out build hermes macos action
Pull Request resolved: https://github.com/facebook/react-native/pull/45371
Test Plan: GHA are green
Reviewed By: blakef
Differential Revision: D59627977
Pulled By: cipolleschi
fbshipit-source-id: 84226d8a2c036f816fa8ea949b467873a7eef37c
Summary:
Fixes: https://github.com/facebook/react-native/issues/45307
## Changelog:
[Android] [Fixed] - if `npx react-native-community/cli config` fails or timeouts proper error is shown and built is aborted, instead of leaving and empty autolinking.json
During build `npx react-native-community/cli config` is generated into autolinking.json. When command fails, we should error and should not leave and empty `autolinking.json`
Pull Request resolved: https://github.com/facebook/react-native/pull/45333
Test Plan:
Output of the reproducer in https://github.com/facebook/react-native/issues/45307 looks like this:
```log
android % ./gradlew assembleDebug
Starting a Gradle Daemon (subsequent builds will be faster)
ERROR: autolinkLibrariesFromCommand: Failed to create /Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/android/build/generated/autolinking/autolinking.json - process npx react-native-community/cli config exited with error code: 126
FAILURE: Build failed with an exception.
* Where:
Settings file '/Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/android/settings.gradle' line: 3
* What went wrong:
A problem occurred evaluating settings 'android'.
> ERROR: autolinkLibrariesFromCommand: Failed to create /Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/android/build/generated/autolinking/autolinking.json - process npx react-native-community/cli config exited with error code: 126
* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.
BUILD FAILED in 10s
8 actionable tasks: 4 executed, 4 up-to-date
```
Output if you modify the package.json to be invalid looks like this:
```log
android % ./gradlew assembleDebug
ERROR: autolinkLibrariesFromCommand: process npx react-native-community/cli config exited with error code: 1
JSONError: JSON Error in /Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/package.json:
35 | "node": ">=18"
36 | },
> 37 | SOMETHING_NON_JSON
| ^
38 | "packageManager": "yarn@3.6.4",
39 | "resolutions": {
40 | "rtn-centered-text": "portal:../RTNCenteredText"
Unexpected token "S" (0x53) in JSON at position 1019 while parsing near "...ode\": \">=18\"\n },\n SOMETHING_NON_JSON\n ..."
35 | "node": ">=18"
36 | },
> 37 | SOMETHING_NON_JSON
| ^
38 | "packageManager": "yarn@3.6.4",
39 | "resolutions": {
40 | "rtn-centered-text": "portal:../RTNCenteredText"
at parseJson (/Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/node_modules/parse-json/index.js:29:21)
at loadJson (/Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/node_modules/react-native-community/cli-config/node_modules/cosmiconfig/dist/loaders.js:48:16)
at #loadConfiguration (/Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/node_modules/react-native-community/cli-config/node_modules/cosmiconfig/dist/ExplorerSync.js:116:36)
at #loadConfigFileWithImports (/Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/node_modules/react-native-community/cli-config/node_modules/cosmiconfig/dist/ExplorerSync.js:87:54)
at #readConfiguration (/Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/node_modules/react-native-community/cli-config/node_modules/cosmiconfig/dist/ExplorerSync.js:84:82)
at search (/Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/node_modules/react-native-community/cli-config/node_modules/cosmiconfig/dist/ExplorerSync.js:50:63)
at emplace (/Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/node_modules/react-native-community/cli-config/node_modules/cosmiconfig/dist/util.js:36:20)
at ExplorerSync.search (/Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/node_modules/react-native-community/cli-config/node_modules/cosmiconfig/dist/ExplorerSync.js:78:42)
at getUserDefinedOptionsFromMetaConfig (/Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/node_modules/react-native-community/cli-config/node_modules/cosmiconfig/dist/index.js:32:37)
at mergeOptionsBase (/Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/node_modules/react-native-community/cli-config/node_modules/cosmiconfig/dist/index.js:60:31)
FAILURE: Build failed with an exception.
* Where:
Settings file '/Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/android/settings.gradle' line: 3
* What went wrong:
A problem occurred evaluating settings 'android'.
> ERROR: autolinkLibrariesFromCommand: process npx react-native-community/cli config exited with error code: 1
* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.
BUILD FAILED in 2s
8 actionable tasks: 4 executed, 4 up-to-date
```
Reviewed By: cipolleschi
Differential Revision: D59582430
Pulled By: cortinico
fbshipit-source-id: bedb9563175cc5c46f5af80cf309769e56b803cc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45366
This updates ReactImageView to share the background drawing and clipping code used by other built-in components. This means manipulating a background drawable, and clippping at draw time, instead of using Fresco hierarchy background (in view foreground), and radii which manipulate the underlying bitmap.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D59495407
fbshipit-source-id: ce3c975e5ed323fa3d4610ec1515ef3c8dd8b2d1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45356
Subview clipping was disabled for RTL on Android due to a bug where TextInputs automatically blur when selected. This bug is reintroduced when `set_android_layout_direction` is set.
When `set_android_layout_direction` is enabled, and we use View `getLayoutDirection()` instead of `I18nManager.isRTL()`, the layout direction is not known until layer in the mounting process. This defeats the check a `setRemoveClippedSubviews()` prop setter to ignore the prop if the view is RTL (since it doesn't invalidate when a new layout direction is set).
The root cause of the underlying RTL bug is due to updating clipping status triggered by `onSizeChanged()`, which is called before `onLayout()`, where `ReactHorizontalScrollContainerView` offsets content in RTL. This also seems potentially erroneous, as we do not update the clipping rect on position change (unless that is handled elsewhere).
I moved the check to `onLayout()`, called after ReactHorizontalScrollView will change metrics, which seems to fix the issue. I then removed the exclusion in `removeClippedSubviews` prop setter.
Changelog:
[Android][Fixed] - Fix Android removeClippedSubviews in RTL
Reviewed By: mdvacca
Differential Revision: D59566611
fbshipit-source-id: a2eb12b984dc78940756804b6b7a3950377af9de
Summary:
When setting a shadow on a `Text` inside a `TextInput`, the shadow was rendered with artifacts when `backgroundColor` was set on the `TextInput`.
This is caused by how attributed strings are constructed on the new architecture - all text attributes from the text input (including background color) are propagated onto the string. Then, it's converted to a `Spannable` on Android side, which includes `ReactBackgroundColorSpan` being set on the entire text when it doesn't have a background color set explicitly. Then Android tries to render the shadow not only for the text but also for the background rect which results in the artifacts.
This PR prevents background color from the `TextInput` from being propagated onto the attributed string, so the `ReactBackgroundColorSpan` is only applied when a text fragment has its background set explicitly.
## Changelog:
[ANDROID] [FIXED] - Fixed text shadow rendering with artifacts when `backgroundColor` was set on the `TextInput`
Pull Request resolved: https://github.com/facebook/react-native/pull/45343
Test Plan:
Checked relevant examples on RNTester
|Old arch|New arch (before)|New arch (after)|
|-|-|-|
|<img width="436" alt="Screenshot 2024-07-09 at 14 44 52" src="https://github.com/facebook/react-native/assets/21055725/64005ec4-3e42-4327-9b09-f57d3c477fb6">|<img width="436" alt="Screenshot 2024-07-09 at 14 43 03" src="https://github.com/facebook/react-native/assets/21055725/f558ad26-08de-4231-acdf-92f596ec186c">|<img width="436" alt="Screenshot 2024-07-09 at 14 41 46" src="https://github.com/facebook/react-native/assets/21055725/6b4ff6ed-5267-4f1a-a895-1bbd760f73e5">|
Reviewed By: NickGerleman
Differential Revision: D59527817
Pulled By: cortinico
fbshipit-source-id: d03d4749e4435ef04e51b1018f046be0e5e0bca4
Summary:
Factor out build-apple-slices-hermes to a seprate action to reuse code
## Changelog:
[Internal] - Refactor the CI to reuse code
Pull Request resolved: https://github.com/facebook/react-native/pull/45359
Test Plan: GHA are green
Reviewed By: cortinico
Differential Revision: D59575467
Pulled By: cipolleschi
fbshipit-source-id: 5d253f3dd523cb70b768c62db10fb7ff39fbd49f
Summary:
This PR updates the comments for `~ShadowNodeWrapper()` and `~ShadowNodeListWrapper()` to align them with the actual implementation that now uses `jsi::NativeState` instead of `jsi::HostObject`.
## Changelog:
[GENERAL] [FIXED] - Updated comments for `~ShadowNodeWrapper()` and `~ShadowNodeListWrapper()`
Pull Request resolved: https://github.com/facebook/react-native/pull/45357
Reviewed By: sammy-SC
Differential Revision: D59578988
Pulled By: javache
fbshipit-source-id: 1c46ce8407fc8b337f3a6762caee3b2e0e1edfc6
Summary:
Factor out the action to build hermesc for apple platform so we can reuse it across jobs
## Changelog:
[Internal] - Factor out hermesC apple to reuse code
Pull Request resolved: https://github.com/facebook/react-native/pull/45346
Test Plan: GHA are green
Reviewed By: cortinico
Differential Revision: D59521564
Pulled By: cipolleschi
fbshipit-source-id: c99966e314b3d418d1d83d653c0be68b2931b03b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45348
flattenStyle may return an object which is already frozen (in development), so it is incorrect to further mutate this.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D59525418
fbshipit-source-id: 094b7c9c952d8684e24203cc07d6bda51bdf12b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45352
We claim that we will never draw multiple elements on top of each other, which isn't correct when we have a background.
We should claim that we can draw overlapping elements if we have a background drawable which we place in the Drawee hierarchy (part of the ImageView foreground drawable), or if the underlying view has a background drawable (which is handled by `ImageView` superclass `hasOverlappingRendering()`).
The effect of this is subtle, and just means that we get correct compositing when an opacity is set on image with background.
Changelog:
[Android][Fixed] - Fix ReactImageView.hasOverlappingRendering()
Reviewed By: mdvacca
Differential Revision: D59489788
fbshipit-source-id: fe2922f064b91f1709ed546dd647d4d4112d04c1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45338
`CSSBackgroundDrawable` is a silly goose and reuses layout types to store color. This has extended into a really strange public API, where we use floating point colors, where the color is itself in int with packed integer color components.
This hides that away, and marks some classes with `UnstableReactNativeAPI` that I plan to hide shortly.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D59488811
fbshipit-source-id: 7dc57edc9888f8a92088d2410ee71c2768ae8ec1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45169
This is a follow-up to D56280451 where I made all SystraceSection calls feed into the Instruments signposts API. This will additionally do the same for all calls to nativeTraceBeginSection/nativeTraceEndSection from JSITracing.cpp.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D58895740
fbshipit-source-id: ee1cdff883ac1172f9bafe11ab950738d7ae7f82
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45336
The spec says we need to adjust the border radius of the shadow if spread is present. It gets bigger for outset shadows and smaller for inset shadows.
Source https://drafts.csswg.org/css-backgrounds/#shadow-shape
> To preserve the box’s shape when spread is applied, the corner radii of the shadow are also increased (decreased, for inner shadows) from the border-box (padding-box) radii by adding (subtracting) the spread distance (and flooring at zero). However, in order to create a sharper corner when the border radius is small (and thus ensure continuity between round and sharp corners), when the border radius is less than the spread distance (or in the case of an inner shadow, less than the absolute value of a negative spread distance), the spread distance is first multiplied by the proportion 1 + (r-1)3, where r is the ratio of the border radius to the spread distance, in calculating the corner radii of the spread shadow shape.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D59296120
fbshipit-source-id: e55327701547f27961a0d612ed595b4383e1d763
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45340
flattenStyle may return an object which is already frozen (in development), so it is incorrect to further mutate this.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D59515063
fbshipit-source-id: 92df158d5841988d40bcd76b861963b06dad1573
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45323
We're no longer running experiments with TurboModule and legacy module rollout, so this debug info is no longer required, and adds unnecessary verbosity to TurboModule lookup errors.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D59465974
fbshipit-source-id: 87a2ebd9c05ad312889bcbd819ccbe885b429064
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45320
TurboModule should be the default path, and we should only fallback to the legacy native modules if we can't find a module through the TurboModule mechanism.
Changelog: [General][Changed] - TurboModules will be looked up as TurboModules first, and fallback to legacy modules after.
Reviewed By: christophpurrer
Differential Revision: D59465978
fbshipit-source-id: c5672d34e90dcee321de0a5acd3a50b6bb1092b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45330
changelog: [internal]
With view preallocation, we want to trigger image download in case there is only a single image source even if layout hasn't been determined.
This can lead to images appearing 100s of milliseconds earlier.
This optimisation is already used by plain ImageView: https://fburl.com/code/cp87xmw7
Reviewed By: rubennorte
Differential Revision: D59465972
fbshipit-source-id: e045d6bd9d595d366541ffa32364488be4766ef8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45319
This test has been cleaned up, we can remove the callers.
Changelog: [Internal]
Reviewed By: fabriziocucci
Differential Revision: D59465975
fbshipit-source-id: 01f4b24f221aa017fbfd2238f81454d38d05920a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45325
We don't want to lose this context when we cleanup the old architecture.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D59466876
fbshipit-source-id: 3cf3c63d619d9e8535e369ec1ef7c5706431b85d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45317
changelog: [internal]
ship optimized version of Text componant. In local benchmarking this version shows 35% improvement over old Text component.
Reviewed By: NickGerleman
Differential Revision: D59460871
fbshipit-source-id: c3a41d3aac4cd40e054b669d56295bcb631d8310
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45331
Let's add the a new JSRuntime API to register the thread. This allows Hermes sampling to correctly work in Bridgeless/Activity.
## Changelog:
[General][Added] - Add experimental api to JSRuntimeFactory to initialize runtime on js thread
Reviewed By: RSNara
Differential Revision: D58787655
fbshipit-source-id: 2202271b9ad88cf8ba2145fb4e9e7bfd6e0c09fa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45329
Thanks to [#45232](https://github.com/facebook/react-native/issues/45232) we found a bug in the interop layer, where we were not passing the BridgeProxy in bridgeless mode to the view managers.
This Change should fix that issue.
## Changelog:
[iOS][Fixed] - Make sure to pass the RCTBridgeProxy to ViewManagers
Reviewed By: dmytrorykun
Differential Revision: D59468292
fbshipit-source-id: 00666be21385a735878eb567c4b8a0986c609c5f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45328
This assertion is currently not actionable since the stack trace will always be just `mCreateReactContextThread`. Moving this assert is safe, as the only other place we write it is also the UI thread.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D59467576
fbshipit-source-id: c4606672255149a202f99a8f787230e2a23a868a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45321
Changelog: [internal]
This creates a variant of the internal hook in `TextInput` that handles the synchronization of the state between native and JS. The new variant moves everything that's not needed for rendering to refs instead of state.
One of the reasons for this change is that by not setting state in layout effects, we're not forcing passive effects to be flushed synchronously, which can improve perceived performance (as we can start painting before passive effects are executed).
Reviewed By: sammy-SC
Differential Revision: D59400624
fbshipit-source-id: 540c20daf49919fbfabd357a1a057ca126ec6b03
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45315
Changelog: [internal]
This moves some logic from the `TextInput` component to its own hook. It's just a refactor in preparation for a following change were we're going to test replacing this hook with an alternative version that relies less on state (using refs for some things instead).
Reviewed By: sammy-SC
Differential Revision: D59400614
fbshipit-source-id: ea37b8514f89e94be1386774ad70d56389878886
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45318
I'm setting the Gradle cache to write-only for build_android on main/stable branches.
This is so we start from a fresh cache on those jobs (as they're not on the critical path for developers).
Changelog:
[Internal] [Changed] - Attempt to limit the Gradle cache size
Reviewed By: cipolleschi
Differential Revision: D59466459
fbshipit-source-id: 8b7936ebe053ae06256f8506093eb17c07219de9
Summary:
This PR removes usage of deprecated `statusBarFrame` method in `RCTPerfMonitor` . Instead `RCTPerfMonitor` now uses `safeAreaInsets` which also fixes issue causing Perf Monitor to appear under corner in landscape mode on e.g. `iPhone 15 Pro`. It also fixes initial position of expanded state which was causing it to render under notch.
Also removed duplicate background color setting
## Changelog:
[IOS] [REMOVED] - Remove usage of deprecated statusBarFrame method
[IOS] [FIXED] - Fix position of RCTPerfMonitor in landscape mode & expanded mode
Pull Request resolved: https://github.com/facebook/react-native/pull/43058
Test Plan: `RNTester` builds and runs successfully, `RCTPerfMonitor` works and displays correctly
Reviewed By: dmytrorykun
Differential Revision: D59116913
Pulled By: cipolleschi
fbshipit-source-id: 0ff61f61b206c530cfb9e471bc2dc33a0a43c833
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45303
`ViewManagersPropertyCache` uses reflection to find all ReactProp but fails when any symbols in the method refer to classes not available in the current build.
Work around this by extracting this helper to a separate private inner class.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D59397865
fbshipit-source-id: e77d3167698e4311e8778ebab28a0c8a0d2666c2
Summary:
To fix [The Memory Leak Issue](https://github.com/facebook/react-native/issues/45080) This change modifies the timing of view creation in the LogModule. The motivation behind this update is to address a potential memory leak issue. Previously, views were being created and held onto, which could lead to references to the Activity being retained even when they were no longer needed. By creating the view only when the show method is called and ensuring it is removed in the hide method, we can prevent these memory leaks and improve the overall memory management and stability of the LogModule.
Fixes https://github.com/facebook/react-native/issues/45080
- Adjusted the timing of view creation to occur when the `show` method is called.
- Ensured that the created view can be removed in the `hide` method.
- This update addresses potential memory leaks by preventing the view from holding a reference to the Activity.
These changes improve memory management and stability within the LogModule.
Modify the timing of view creation in LogModule. The view is now created when the show method is called, and it can be removed in the hide method. This change resolves potential memory leaks caused by the view holding a reference to the Activity.
## Changelog:
[ANDROID] [FIXED] - Fix LogModule to create view when show is called
Pull Request resolved: https://github.com/facebook/react-native/pull/45261
Reviewed By: dmytrorykun
Differential Revision: D59372962
Pulled By: cortinico
fbshipit-source-id: 6693afdb279c7164ff0f68c93f8ca8a54b1c2077
Summary:
In https://github.com/facebook/react-native/issues/44483 `If-None-Match` request failed to get a 304 after a 200 response. This is caused by NSRequest's
cachePolicy which prevents sending a request to server to check 304 state and return directly a 200 response.
## Changelog:
[IOS] [FIXED] - fix: on iOS not getting 304 from `If-None-Match` request
Pull Request resolved: https://github.com/facebook/react-native/pull/45263
Test Plan: repeat request given in https://github.com/facebook/react-native/issues/44483
Reviewed By: cortinico
Differential Revision: D59364609
Pulled By: dmytrorykun
fbshipit-source-id: 2a8b86c526320a1e9c1c58e41aa9c74beeeac2ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45287
Fixes https://github.com/facebook/react-native/issues/45277
This fixes an NPE reported in OSS if you do this call in JavaScript:
```
const fr = new FileReader();
fr.readAsText({});
```
Changelog:
[Android] [Fixed] - Fix NPE in FileReaderModule
Reviewed By: dmytrorykun
Differential Revision: D59372620
fbshipit-source-id: ad5073376eaa26852c8277bdbb7d76b1aa480b3c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45295
When registering Babel to run RN from source, we currently call `babel/register` directly from `scripts/babel-register.js`.
This has the effect of overwriting any previous registration, which causes problems in the FB monorepo because RN also loads other projects that lie outside this registration (like Metro) from source - possibly requiring different configurations.
Moreover, if Metro is subsequently loaded from source, its own registration clobbers RN's.
Instead, this diff runs the registration through `metro-babel-register`, which maintains a cumulative list of registration directories and applies a uniform transform.
Note that this means we're not using exactly the same transform at build/publish time as for running from source - to fix that, we ought to move everything to a central `babel.config.js`, but that's a much bigger change, and this gets us close enough to unblock.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D59376984
fbshipit-source-id: 0dbb00970ac87dbe40ec8904bf51ef4b1fee5e0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45294
Just doing some cleanup here as those exports are scattered around this file.
Changelog:
[Internal] [Changed] - Cleanup exports for PressableExample in RN-Tester
Reviewed By: yungsters
Differential Revision: D59376617
fbshipit-source-id: 0f6f81fca7b5cbcdc05bbb6a1f87d3ad74c20b50
Summary:
This PR restores the virtual destructor for `ShadowNodeWrapper` which was added in https://github.com/facebook/react-native/pull/33500 and unfortunately removed in https://github.com/facebook/react-native/pull/40864.
The virtual destructor here serves as a key function. Without a key function, `obj.hasNativeState<ShadowNodeWrapper>(rt)` **does not** work correctly between shared library boundaries on Android and always returns false.
We need this pretty badly in third-party libraries like react-native-reanimated or react-native-gesture-handler.
## 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 dynamic_cast (RTTI) for ShadowNodeWrapper when accessed by third-party libraries again
Pull Request resolved: https://github.com/facebook/react-native/pull/45290
Test Plan: This patch fixes an issue in Reanimated's fabric-example app.
Reviewed By: fabriziocucci
Differential Revision: D59375554
Pulled By: javache
fbshipit-source-id: 09f3eda89a67c26d6dacca3428e08d1b7138d350
Summary:
[`querystring`](https://www.npmjs.com/package/querystring) package is deprecated. In this Pull Request I've replaced usage of `querystring` with `URLSearchParam` what is recommended by Node.js.
It's also causing a warning when installing dependencies inside a React Native app:
```
warning react-native > react-native/community-cli-plugin > querystring@0.2.1: The querystring API is considered Legacy. new code should use the URLSearchParams API instead.
```
## Changelog:
[INTERNAL] [FIXED] - Replace `querystring` package with `URLSearchParam`
Pull Request resolved: https://github.com/facebook/react-native/pull/45125
Test Plan:
Params should be parsed in the same way and warning shouldn't be presented.
js1 jest xplat/js/tools/metro/packages/metro/src/cli/__tests__/parseKeyValueParamArray-test.js
Reviewed By: cipolleschi
Differential Revision: D58948498
Pulled By: GijsWeterings
fbshipit-source-id: 79b1f7b3feae230d2d3641205c513b98b3fda511
Summary:
We do have a mixture of casing in the custom GH actions in our repo.
This aligns them all to be `kebab-case`
## Changelog:
[INTERNAL] - Aling all custom actions to kebab-case
Pull Request resolved: https://github.com/facebook/react-native/pull/45286
Test Plan: CI
Reviewed By: blakef
Differential Revision: D59374046
Pulled By: cortinico
fbshipit-source-id: 030a9323e501e375585e90f10a3b29c3bb671b28
Summary:
Changes `.npmignore` file to only exclude the `ReactAndroid/build` directory instead of all `build` directories under `ReactAndroid` (which included the `ReactAndroid/src/main/java/com/facebook/react/common/build` package). This problem was caused by the newer version of NPM being used.
Closes https://github.com/facebook/react-native/issues/45204
## Changelog:
[ANDROID] [FIXED] - Fixed build from source failing due to a missing file
Pull Request resolved: https://github.com/facebook/react-native/pull/45279
Test Plan:
Run `npm pack` or `npm publish -dry-run`.
Before this change it includes 3774 files in the package and `ReactBuildConfig` isn't included. After this change it includes 3775 files in the package and `ReactBuildConfig` is included.
Reviewed By: javache
Differential Revision: D59371555
Pulled By: cortinico
fbshipit-source-id: f54f1e88e30429d538b9e160e6ce20d994c5d1b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45269
There's no callers to this property, and we already create a `jsRuntimeFactory` above in DefaultReactHost, which will actually decide which VM to use.
Changelog: [Android][Removed] Unused jsEngineResolutionAlgorithm from ReactHost
Reviewed By: cortinico
Differential Revision: D59333435
fbshipit-source-id: 21be4d138bca64c0cb78de366bf2e247b4f37650
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45053
Add support for most keyword values of mix-blend-mode on Android
Missing compositing operators and global values
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D58752052
fbshipit-source-id: e63e01d45a7e0924f3853f08dff5cec7e2f1ceaf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45256
The actual stamped versions here are all strings.
Android interface for constants is untyped, and we always return a string here. iOS, we will try to parse the string into a double, which will fail for every prerelease version RN has ever published.
Platform on Windows seems to uniquely be doing the right thing.
Changelog:
[General][Fixed] - Fix Platform.constants.reactNativeVersion type
Reviewed By: robhogan, necolas
Differential Revision: D59141948
fbshipit-source-id: 9c758e5eb8796b03197258d87ec06b31018e211c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45250
Adds and implements a new `appDisplayName` field as part of `HostTargetMetadata` and the `ReactNativeApplication.metadataUpdated` CDP event.
This will be used to display the app display name in the debugger frontend.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D59273360
fbshipit-source-id: d770cccadb520b9c13c7288cd690df21683d2cc1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45249
Follows D58288489, D58415181.
Implements the remaining `HostTargetMetadata` fields, sent by the debugger on `ReactNativeApplication.metadataUpdated`, on **Android Bridgeless**.
This will be used to display details such as the app name and React Native version in the debugger frontend.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D59271755
fbshipit-source-id: a2488fed98df0800ec0a611d2317cd40cd809aac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45234
Follows D58288489.
Implements the remaining `HostTargetMetadata` fields, sent by the debugger on `ReactNativeApplication.metadataUpdated`, on **Android Bridge** (Bridgeless to follow).
This will be used to display details such as the app name and React Native version in the debugger frontend.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D58415181
fbshipit-source-id: 8aca707c0b9f6e933ac5e5b4ac47ba8d48e99241
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45258
Setting this to false, then removing, will not reset back to default state of `true`. Add explicit defaults so that the absence of the prop will lead to scroll indicators always being shown.
Changelog:
[Android][Fixed] - Fix default for `showsHorizontalScrollIndicator` and `showsVerticalScrollIndicator`
Reviewed By: javache
Differential Revision: D59285745
fbshipit-source-id: 6a7c204cfe9c4ab9e4efbbda300cdfdaf57e8f37
Summary:
Fix entails using non-synthesized getter, such that underlying backing is an std::atomic<RCTNetworkTaskStatus>.
In the greater scheme of things, I believe `RCTNetworkTask` should be improved as it has several `nonatomic` properties that are read and written to on different threads. Thread safety of this class seems to have been addressed on a per property basis, judging from the employment of `std::mutex` elsewhere in the implementation.
This is an attempt at fixing https://github.com/facebook/react-native/issues/44687.
## Changelog:
[iOS][FIXED] - Fix data race related to access on `RCTNetworkTask.status`.
Pull Request resolved: https://github.com/facebook/react-native/pull/44694
Test Plan: Added unit test in class `RCTNetworkTaskTests`.
Reviewed By: cortinico
Differential Revision: D59217353
Pulled By: javache
fbshipit-source-id: 1af77238ddd99db21e2e53f174a81e207d5832b2
Summary:
This migrates `analyse_code` to GHA into a single job called `lint`.
## Changelog:
[INTERNAL] - Migrate analyse_code to GHA
Pull Request resolved: https://github.com/facebook/react-native/pull/45247
Test Plan: CI
Reviewed By: NickGerleman
Differential Revision: D59283393
Pulled By: cortinico
fbshipit-source-id: dcdc4828a551062b3706e6450614b8c94e1a7e81
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45264
Changelog: [internal]
We added a flag to fix some issues when committing state updates synchronously from the main thread in https://github.com/facebook/react-native/pull/44015 but that implementation was incorrectly not invoking item dispatch listeners after mount.
This adds the missing logic so we can unblock shipping sync state updates.
Reviewed By: javache
Differential Revision: D59319230
fbshipit-source-id: b0ab7e7c79a3315ef29dbb024e62c10444192509
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45240
X-link: https://github.com/facebook/yoga/pull/1675
There was a bug where some crash would happen if a tree was cloned that had static/absolute parent/child pair inside it. This was because we were no longer calling `cloneChildrenIfNeeded` on the static parent, but would still layout the absolute child. So that child's owner would be stale and have new layout. In React Native this would lead to a failed assert which causes the crash.
The fix here is to clone the children of static nodes during `layoutAbsoluteDescendants` so that we guarantee the node is either cloned if it is going to have new layout.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D59175629
fbshipit-source-id: 4d110a08ba5368704327d5ab69a8695b28e746f4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45242
tsia, comments should explain how this works but tldr is
* Set up cropping region to only draw within the view's bounds
* Draw 2 offscreen rects to cast the shadow. One represents the bounds of the original view, the other represents the clear region. Fill these rects with EO fill algo so the intersection is clear. The disjoint will be colored and cast a shadow.
* Do that for each shadow in reverse order
Changelog: [Internal]
bypass-github-export-checks
Reviewed By: lenaic
Differential Revision: D58885576
fbshipit-source-id: 2f3a5de75e93c7d34676128bbddbe38d64f1fb59
Summary:
tisa. Algo is
* Draw offscreen rect the size of the outset shadow (so accounting for spread)
* Set g state to cast shadow in proper place ON screen
* Clear out region in view
The rects need to be offscreen for the following reasons
* We need to account for spread radius, and CGContext shadows do not have support for this. So the only way to create a bigger shadow is the create a path that is the same size as the shadow we want
* We cannot just position this rect onscreen with no offset (so the shadow is casting directly under it) since the blur will look unnatural
* Offscreen means we do not see filled shadow rect but we do see the shadow it casts by offsetting it in the proper location
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D58881588
fbshipit-source-id: 2ea1b8945a3b9f182c4fb11668ac91a0ae7846ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44882
tsia, nothing too fancy here. Just taking the box shadows from raw props and throwing them into a struct so we can read it.
Changelog: [Internal]
bypass-github-export-checks
Reviewed By: NickGerleman
Differential Revision: D57617028
fbshipit-source-id: 29cf683b663b4903721d674efbf61a200eaf3a64
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45237
Changelog: [internal]
This creates a feature flag to test a fix for an incorrect state update dispatched to Fabric when using smooth scroll animations.
Specifically, when starting a smooth scroll animation from X to Y, the scroll view would set the state to Y, and then all the range from X to Y again. For example, the sequence of state updates when smooth scrolling from 0 to 5 would be `0 -> 5 -> 1 -> 2 -> 3 -> 4 -> 5`, which is obviously incorrect.
This flag prevents setting the final value before it's actually reached.
Reviewed By: javache
Differential Revision: D59233069
fbshipit-source-id: 221602d7d30635070e7776ce756e2ef438edf638
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45236
Changelog: [internal]
## Context
We're currently observing inconsistencies between the state of the UI on Android and the propagated state in Fabric.
When investigating the issue, we saw that there are some state updates that were going to be dispatched from scroll views to Fabric were skipped because the state object in native was deallocated.
The reason for that is a race condition between:
1. Dispatching new state updates from the UI thread
2. Updating the state previously dispatched from the UI thread on the JS thread.
{F1735383134}
## Changes
This creates a new feature flag to replace the weak reference with a strong one, so when the previous state is deallocated we can still access it to set new state.
The use of weak references was introduced in D44472121 to avoid holding onto JSI references (which could be contained in the state) when the runtime was deallocated, but we later introduced an explicit clean up mechanism in D45905628 that would make that unnecessary.
Reviewed By: javache
Differential Revision: D59233070
fbshipit-source-id: 018d8935f506430ecab96df0f7a998a37ee0f556
Summary:
This migrates the `test_js` workflow to GHA
## Changelog:
[INTERNAL] - Migrate test_js to GHA
Pull Request resolved: https://github.com/facebook/react-native/pull/45246
Test Plan: Will wait for CI
Reviewed By: javache
Differential Revision: D59270333
Pulled By: cortinico
fbshipit-source-id: e77eb9819e0819638c51e61b1e477ac04680a2f4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45233
We want the Gradle cache to be written only on main/-stable branches run, and only for jobs with `cache-read-only` == false (i.e. `build_android`).
This changes implements it.
Changelog:
[Internal] [Changed] - Further refine the Gradle caching logic.
Reviewed By: blakef
Differential Revision: D59225944
fbshipit-source-id: b6c3a5d4d0d399d6fe42287976925c43f3f12eb7
Summary:
Adds changelog for the 0.74.3 patch.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Add 0.74.3 changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/45238
Reviewed By: cortinico
Differential Revision: D59263876
Pulled By: dmytrorykun
fbshipit-source-id: 0f16d51a01790b4ddcaca092dec7527aab386dcd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44914
Shows a proof of concept how '*strongly typed Turbo Module scoped*' `EventEmitters` can be used in a ObjC Turbo Module.
## Changelog:
[iOS] [Added] - Add ObjC Turbo Module Event Emitter example
Reviewed By: rshest
Differential Revision: D57650830
fbshipit-source-id: c5c2dee4766484e9e58415e33c084999a9ae3bc6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45218
Noticed that when an exception occurred we would not cleanup global_refs, leaking them in the global table.
Restructure this to use RAII and rely on JNIArgs to do the cleanup as necessary.
Changelog: [Android][Internal]
Reviewed By: RSNara
Differential Revision: D59156494
fbshipit-source-id: c89552d72387bad2a120373e78a2c545415a7c82
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45207
These are their own shared library, and their own soloader-call, but they can easily be pulled into existing targets without causing excessive bloat.
Changelog: [Android][Removed] react_newarchdefaults is no longer a prefab, instead use fabricjni
Reviewed By: christophpurrer
Differential Revision: D59107105
fbshipit-source-id: fb3b25f3ce4511aa18126477f2beefe1292c6d09
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45231
Following up to cipolleschi's work, it turns out that me setting this command inside
the docker file for React Android is unneffective:
https://github.com/react-native-community/docker-android/pull/228
The reason is that the user executing is different (1001 for the Dockerfile, while GHA executes as root 1000).
So we need to set this, otherwise the nightlies will be invoked with the `-TEMP` prefix:
Changelog:
[Internal] [Changed] - Setup `git config --global --add safe.directory '*'` when running jobs inside Docker
Reviewed By: blakef
Differential Revision: D59223862
fbshipit-source-id: 26674fc8cdaebf6687407072cc4e4f5c38246845
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45205
We only need a static register method, which includes the core components and the provider function. CoreComponentsRegistry isn't referenced at all in Kotlin/Java, and can be replaced with DefaultComponentsRegistry with no change in behaviour in all scenarios.
Changelog: [Android][Removed] CoreComponentsRegistry is now fully replaced by DefaultComponentRegistry.
Reviewed By: cortinico
Differential Revision: D59107106
fbshipit-source-id: e679be490f43dab52eb5e11a08aa9d0ae2a89a92
Summary:
Fixes https://github.com/facebook/react-native/issues/45222
## Changelog:
[ANDROID] [FIXED] - Fix autolink plugin for libraries that are platform-specific
Pull Request resolved: https://github.com/facebook/react-native/pull/45223
Test Plan: And a library that does not have Android native code such as react-native-segmented-control/segmented-control and sync gradle
Reviewed By: rshest
Differential Revision: D59221562
Pulled By: cortinico
fbshipit-source-id: 55739d63ded63e46897d0d770281f937668c1f50
Summary:
Users are reporting that RN 0.75 is crashing due to us attempting to accessing a static method
on `AndroidUnicodeUtils.convertToCase` which is not static anymore due to Kotlin conversion.
Static access is inside Hermes codebase here:
https://github.com/facebook/hermes/blob/f5c867514c71b25212eb3039230e0c095518b532/lib/Platform/Unicode/PlatformUnicodeJava.cpp#L107-L109
Changelog:
[Android] [Fixed] - Fix crash due to missing JvmStatic to `convertToCase`
Reviewed By: javache
Differential Revision: D59218291
fbshipit-source-id: ac121a8bcd5fd917ee134d257f967c8e3e338ca5
Summary:
Use the hard-coded config for Helloworld instead of assuming the community cli is there to generate a config, which we can no longer assume.
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/45221
Test Plan:
This works in my local environment:
```
bundle exec pod install
```
and
```
./gradlew generateAutolinkingPackageList
```
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D59162715
Pulled By: blakef
fbshipit-source-id: 95ff2c3929f12ee0ecf468cb80d2df1281eb746e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44906
Shows a proof of concept how '*strongly typed Turbo Module scoped*' `EventEmitters` can be used in a Java Turbo Module.
## Changelog:
[Android] [Added] - Add Java Turbo Module Event Emitter example
Reviewed By: javache
Differential Revision: D57530807
fbshipit-source-id: 04261d8885760f0e3b3c8c1931e0d56a5d33a0df
Summary:
The fix entails making `AllocationTestModule.valid` an Objective-C atomic property and funneling access to the ivar via the synthesized property getter and setter.
While the data race was present in test code, it would make it more difficult to spot more severe data races with the TSan. Also, getting rid of a data race is always good.
## Changelog:
[iOS][Fixed] - Data race related to access of `AllocationTestModule.valid`
Pull Request resolved: https://github.com/facebook/react-native/pull/45191
Test Plan: `RCTAllocationTests` will test the implementation of `AllocationTestModule`.
Reviewed By: christophpurrer
Differential Revision: D59155083
Pulled By: javache
fbshipit-source-id: e3217cffd0801377a25f04bf8ed0b4e2d1d88498
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44928
The react-native-community/ dependencies aren't being explicitly included as part of the Framworks (RFC-0759) work.
Changelog: [General][Breaking] react-native isn't dependend on react-native-community/*
WARNING: Do not commit until we've cut 0.75, this goes in the 0.76 release only otherwise it'll break `npx react-native@latest init`.
Reviewed By: cortinico
Differential Revision: D58528447
fbshipit-source-id: f238e621c47df9e28b2e18f4137eb08e525052f6
Summary:
In order to fix the data races described in https://github.com/facebook/react-native/issues/44715, I propose a simple solution by leveraging shared counter functions wherein `std::atomic` is the backing for the integer values.
## Changelog:
[iOS] [Fixed] - Implement shared atomic counters and replace static integers in `RCTImageLoader` and `RCTNetworkTask` that were accessed concurrently, which in some cases lead to data races.
Pull Request resolved: https://github.com/facebook/react-native/pull/45114
Test Plan: Added unit tests for the counters in `RCTSharedCounterTests`.
Reviewed By: cipolleschi
Differential Revision: D59155076
Pulled By: javache
fbshipit-source-id: f73afce6a816ad3226ed8c123cb2ccf4183549a0
Summary:
Having React Native support every Apple platform is tough to achieve as it introduces many platform-specific ifdefs.
On the other side, maintaining an OOT platform fork is already a demanding job, so to make it easier I propose adding ifdefs for iOS-specific code. Thanks to this change, OOT platforms can focus on their OS-specific features while the core is also adding iOS-specific features behind ifdefs. Fortunately, **most of the code on Apple platforms can be shared** and this PR aims to introduce better support for this and to minimize OOT fork's surface.
In this example `RCTDeviceInfo.mm` has support for handling orientation changes and the availability of this feature across Apple OS looks as follows:
| Platform | Support |
| ------------- | ------------- |
| macOS | ❌ |
| tvOS | ❌ |
| visionOS | ❌ |
| iOS/iPadOS | ✅ |
Here is a table from `TargetConditionals.h` header file which shows the coverage of `TARGET_OS_IOS` macro. (It supports both iOS and iPadOS)

## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [ADDED] - Conditionals for iOS only code in RCTDeviceInfo.mm
Pull Request resolved: https://github.com/facebook/react-native/pull/45176
Test Plan: CI Green
Reviewed By: christophpurrer
Differential Revision: D59106103
Pulled By: cipolleschi
fbshipit-source-id: 594a9d2451024baddfbc9cd3bc1ccfb8829fc31c
Summary:
This PR fixes rendering of `RCTRedBoxExtraData`
I noticed that it wasn't displaying the `reload` and `dismiss` buttons, which made it impossible to close modal and to reload JS on e.g. `visionOS` (on `iOS` it could only be closed by swiping).
PR adds these buttons back and also introduces some refactoring
Before & After:
<img width="1118" alt="pr-img" src="https://github.com/facebook/react-native/assets/56474758/50e22499-9df0-45f0-84ac-2118ab7a8e6c">
## Changelog:
[IOS] [FIXED] - Fix rendering `RCTRedBoxExtraData`
Pull Request resolved: https://github.com/facebook/react-native/pull/43102
Test Plan: Make sure that `RCTRedBoxExtraData` displays and works as expected
Reviewed By: dmytrorykun
Differential Revision: D59108365
Pulled By: cipolleschi
fbshipit-source-id: b88c5665962d0280d68377863aa3346edfdf86b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45197
With React 19, `forwardRef` is no longer necessary because `ref` is available on props. However, this only holds true for functional components — not class components.
This eliminates the `forwardRef` invocation in `ScrollView`, while retaining the wrapper component to map `ref` to `scrollViewRef` for the class component. For now...
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D59091873
fbshipit-source-id: 60afcd441aec82fa050738b5c09083f3a26378d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45203
Configures a `REACT_NATIVE_ENABLE_FUSEBOX_DEBUG` flag, and exposes this flag in the Buck target via a [constraint setting](https://www.internalfb.com/intern/wiki/Buck-users/select-and-friends/#constraint-setting-and-c). This is an additional hook to enable the new debugger stack (codename Fusebox) as part of our internal rollout.
NOTE: This approach replaces D59014161 (reverted).
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D59109110
fbshipit-source-id: 7d23d9d402569b00d8dd17b9c8f3bcc108f0365f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45151
This change was missed when fixing hue-rotate and adding drop-shadow. I believe the only issue with this was stacking context was not being created for these two filters.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D58965245
fbshipit-source-id: e6bfdb738a8bc8caa878f60420cfe8b421f64aa4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45161
This is part of a bigger refactoring of the Android pipelines.
As `build_android` is already building everything, let's save the maven-local
so it can be reused by other jobs (test_android_helloworld and build_npm_package).
Changelog:
[Internal] [Changed] - Let build_android produce a signed maven-local.zip archive
Reviewed By: cipolleschi, blakef
Differential Revision: D59002893
fbshipit-source-id: db03946c975b2ce91dae0c4011981b2fe9dd6113
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45133
Recently, CircleCI has failed pretty often due to these tests.
The reason is that we migrated these jobs to M1 machines, as circleCI is deprecating intel ones, and on these machines the simulators tend to freeze. Hence, every often we get stuck when running the tests. :(
We are going to move to GHA, so that should not be a big issue.
## Changelog:
[Internal] - Disable unit tests in CircleCI to improve CI robustness
Reviewed By: cortinico
Differential Revision: D58948614
fbshipit-source-id: 5420bdf0fda325779a4e287e7b00c623de822ccb
Summary:
This PR refactors `supportedInterfaceOrientations` to use RCTKeyWindow instead of `[RCTSharedApplication() keyWindow]`.
## Changelog:
[IOS] [CHANGED] - Refactor supportedInterfaceOrientations method to use RCTKeyWindow()
Pull Request resolved: https://github.com/facebook/react-native/pull/43026
Test Plan: CI Green
Reviewed By: dmytrorykun
Differential Revision: D59109614
Pulled By: cipolleschi
fbshipit-source-id: 025534c419078dce29e1e5caacf8a1b15de1abcc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45196
Currently, `mockComponent` makes a false assumption that if a component is a function, it extends `React.Component`.
There's a bunch of problems with this mocking setup with requiring mock components that extend `React.Component`, but this change does not attemp to solve that.
This change unblocks future refactors to make native components export functional components (that are neither class component nor `forwardRef` results).
Changelog:
[General][Changed] - Fixed native component mocking in Jest unit tests to support functional components
Reviewed By: javache
Differential Revision: D59097730
fbshipit-source-id: ca2784ac3baa9ab4ab6a503c5fd6437c60179352
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45195
Configure `Modal-test.js` to reset modules between test cases so that there is better isolation, making the tests easier to reason about and to debug.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D59097729
fbshipit-source-id: 3b9260283e171ff7fa6b7ffc56685f703875291e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45174
As per title, this port bck to main the changes we made in the release testing script.
## Changelog:
[Internal] - Update release testing script to work with the new template
Reviewed By: blakef
Differential Revision: D59054045
fbshipit-source-id: 0e93c2db94499407845b4fb2c98c8b44310e770f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45175
This change ports the CI improvements we made on stable branch to main.
## Changelog:
[Internal] - Port back to main improvements we made in GHA
Reviewed By: cortinico
Differential Revision: D59053873
fbshipit-source-id: 73eb7e33b9bbdc5d8c3a9294f487ad969b144bf3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45190
Just a small follow up from the previous change to `IntersectionObserverManager`.
Changelog: [internal]
Reviewed By: javache
Differential Revision: D59065041
fbshipit-source-id: 2944299143e6a0fe53fe64083db85635e72d71af
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45162
Previously we would crash in ReactInstance#callFunctionOnModule (P1443291303) when reloading (due to the onHostPause call) because we removed a source of synchronization by using the immediate executor.
Workaround it by making sure we always null out references to `mReactInstance` before we actually start destroying it.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D59002404
fbshipit-source-id: 3ee14cd1fe7d423bb6158356bb99b3d2d6af8d6f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45170
Reimplements `unstable_subscribeToOnScroll` so it does not invalidate all descendant children upon first invocation per `ScrollView` instance.
Previously, the state update would cause the entire `ScrollView` component to re-render. This refactors the `enableSyncOnScroll` boolean state so that it resides in a lower level component that implicitly memoizes all of its `props` (including the `ScrollView` children).
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D59033393
fbshipit-source-id: 5a4b75aebdcbd0dd1dfa28511862bee495816250
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45194
Makes a couple improvmeents to `LogBoxInspectorHeader`:
- Avoid eagerly initializing the `StatusBar` TurboModule until it is actually needed (which is only when the inspector is rendered on Android).
- Switch to `SafeAreaView` on iOS, for more accurate spacing (instead of the hardcoded iPhone X notch size).
Changelog:
[General][Changed] - Improve LogBox initialization performance
[iOS][Changed] - Improve LogBox safe area insets styling
Reviewed By: lyahdav
Differential Revision: D59081529
fbshipit-source-id: 01cc351fa9267f96b7a3c13cf1db80de3e597f93
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45186
Changelog: [internal]
(this is an internal change because `IntersectionObserver` hasn't been released yet).
When testing IntersectionObserver, I realized that it wasn't triggering notifications for elements not intersecting when the surface that contained them was completely deallocated.
This is unexpected because IntersectionObserver notifications are delivered when the element is removed from the root, but not when the root itself is removed.
This fixes that behavior by:
1. Adding a method in `UIManagerMountHooks` to get a notification about the surface being unmounted. This is necessary to keep the API backwards compatible.
2. Using that method in `IntersectionObserverManager` to notify all observers (and report a change if necessary).
Reviewed By: javache
Differential Revision: D59061136
fbshipit-source-id: ef5669f9d6b08d98652489e6731902d192ec28f8
Summary:
Tests were failing on windows due to parsing CRLF line endings. This change enables the API tests for windows by normalizing line endings before parsing the file.
## Changelog:
[INTERNAL] [ADDED] - `public-api-test` now runs on Windows.
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/45145
Test Plan: Build-time-only change; relying on CircleCI
Reviewed By: cipolleschi
Differential Revision: D59001867
Pulled By: huntie
fbshipit-source-id: a7a41945e8c93288be1d5b7b59df7f621e467657
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45185
Follow-up to D59058085.
Since the release branch for 0.75 has been cut, we are able to simplify this step.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D59058084
fbshipit-source-id: 21b77a74e13bb196336a63b984f921f0c9fde587
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45184
This is a follow-up to D59055522.
> NOTE:This diff will be followed up by a merge of the set-rn-version script into set-version. (I had considered a rename to version-rn-artifacts, intentionally keeping this script separate and distinct from a future [lerna version + this script] setup — however the current UX and confusion with this naming would be too confusing. It can move into a util 👍🏻.)
- Rename `set-rn-version` to `set-rn-artifacts-version` (more accurate).
- Mark this script as deprecated.
- For now, there are too many references to this script in CI test jobs to refactor away this entry point, so I am avoiding this — these should later be standardised to `set-version`.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D59058085
fbshipit-source-id: 4123ac73b5c7a2e07a1d1b6da61e0ad94fc31f84
Summary:
While developing React Server Component support for React Native, I've been adding this patch to the `react-native` package. It opts the entire `react-native` package out of being server rendered.
In the future, we'll want to circle back and refactor the `react-native` package to be more isomorphic so we can allow for utilities like `processColor` to be used in server bundles that target native platforms.
## Changelog:
[GENERAL] [ADDED] - Added support for importing `react-native` in a `react-server` environment for React Server Components support.
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/43986
Test Plan:
Using react-native with this patch in a framework that supports React Server Components for native platforms, such as my unreleased branch of Expo Router, will allow for server rendering views from `react-native` to RSC Flight code with client references to the `react-native` package, e.g.
```js
import { View } from 'react-native';
export default function App() {
return <View testID="basic-view" style={{ "backgroundColor":"#191A20" }}/>
}
```
Can be server rendered to ↓
```
2:I["/node_modules/react-native/index.bundle?platform=ios&dev=true#798513620",["..."],"View"]
1:["$","$L2",null,{"testID":"basic-view","style":{"backgroundColor":"#191A20"}}]
```
> The client boundaries (URL paths) are specific to the current Expo CLI implementation (based on Metro) and may look different in other implementations.
Reviewed By: rickhanlonii
Differential Revision: D55891243
Pulled By: TheSavior
fbshipit-source-id: d8dc9590039181ebf2c013dacca5f255d7a8f625
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45180
- Simplifies the responsibilities of `scripts/releases/set-rn-version.js`.
- This no longer modifies `packages/react-native/package.json`, delegating this to `set-version`.
- Simplifies logic in `set-version`, **fixing behaviour** against deps in `packages/react-native/package.json`.
- This also acts as cleanup since D58469912 (template removal) — removing the unreferenced `update-template-package.js` util.
NOTE: This diff will be followed up by a merge of the `set-rn-version` script into `set-version`. (I had considered a rename to `version-rn-artifacts`, intentionally keeping this script separate and distinct from a future [`lerna version` + this script] setup — however the current UX and confusion with this naming would be too confusing. It can move into a util 👍🏻.)
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D59055522
fbshipit-source-id: 79b937f9e0ac790512b180ab4147aefef7f5202c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45028
Since the addition of new workspaces to the repo which introduce interdependencies on `react-native` (`helloworld`, `react-native-test-library`), this fix is needed to preserve our current versioning strategy and bump the repo after yesterday's `0.75-stable` branch cut.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D58725561
fbshipit-source-id: ab282806560f47dc5acf7e694302ca6b85649b14
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44814
We needed this workaround to import the paper renderer in the New Architecture to make sure that the event emitter is properly registered before we use it.
With the previous change, we don't need this lines of code anymore as we are using a different mechanism for the events.
## Changelog:
[Internal] - Avoid to import the old Renderer in the New Architecture
## Facebook:
This diff was initially part of D57097880, but I split them for the OTA
Reviewed By: cortinico
Differential Revision: D58234325
fbshipit-source-id: 1335992460635e9e97ee83615f9fd2651936b32c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45167
Configures a `REACT_NATIVE_ENABLE_FUSEBOX_DEBUG` flag, and exposes this flag in the Buck target. This is an additional hook to enable the new debugger stack (codename Fusebox) as part of our internal rollout.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D59014161
fbshipit-source-id: f05e8b01ed07da90ef6d7a66ade05f462dd82023
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45156
We don't want to bubble up exceptions from props parsing, so match the behaviour from convertRawProp and fall back to the default value when an exception is encountered.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D59000397
fbshipit-source-id: f6f64a80fed98525cdd2a5b5d360c2d6ede76a12
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45160
This should optimize the Gradle cache, so that only `build_android` which
effectively builds everything Android related, should be allowed to write there.
More info on this strategy here:
https://github.com/gradle/actions/blob/main/docs/setup-gradle.md
Changelog:
[Internal] [Changed] - Only build_android should write to the Gradle Cache
Reviewed By: cipolleschi
Differential Revision: D59002323
fbshipit-source-id: 31b815747efdf93bfc7baf97799e287c8dcd7f02
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45165
This is a fix for https://github.com/facebook/react-native/issues/45112
This diff changes the codegen so that the output path is computed relative to project root (or `path` if provided) instead of current working directory.
Changelog: [General][Fixed] - Codegen computes output path relative to project root instead of current working directory.
Reviewed By: fkgozali
Differential Revision: D59009821
fbshipit-source-id: 3a138a3508fc239c8600b8c9f242f1c665f8e3c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45049
WithRuntimeDecorator is missing many methods that were added after it.
Add implementations for them.
The underlying issue here is that because this inherits from
RuntimeDecorator, which implements all methods, there is no compilation
error for this runtime when we add new methods.
Changelog:
[GENERAL] [FIXED] - Add missing methods to the WithRuntimeDecorator class.
Reviewed By: avp
Differential Revision: D58752127
fbshipit-source-id: d80b4ed1c38698ed3850d0cd961bf7ddde2449a0
Summary:
This PR adds missing `WithRuntimeDecorator` methods related to `NativeState`. This pattern is used by reanimated to ensure no concurrent access to the runtime. Without this `override` the `RuntimeDecorator` implementation was used, bypassing our mutex.
Changelog:
[GENERAL] [FIXED] - Add missing `NativeState` methods to the `WithRuntimeDecorator` class.
Pull Request resolved: https://github.com/facebook/react-native/pull/45042
Reviewed By: fbmal7
Differential Revision: D58744051
Pulled By: neildhar
fbshipit-source-id: 3f5c85d0bf7cd6445d0c434ac4ae7ed54df203ba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45168
Refactors the native component imports in `ScrollView` so that 1) they create less clutter in the `ScrollView` implementation file, and 2) they offer more efficient import inlining.
Currently, `ScrollView` has to evaluate both horizontal and vertical components even though only one may be used. Now this optimization is possible.
Changelog: [Internal]
Reviewed By: lyahdav
Differential Revision: D59015990
fbshipit-source-id: 963009821a7d3019d36a43269e9792ac1f2f38ec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45164
Some changes have been made to the codegen since `react-native-test-library` was published. This diff updates the generated artifacts in that library.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D59010093
fbshipit-source-id: f11ccd3645da72d45c70581e485f8546166ca182
Summary:
## Summary
Right now, the only way to load the javascript bundle is through the assets:// directory.
But, legacy react native also supports loading bundles via regular file urls.
If present, those file urls override the assets:// bundle urls.
This diff implements that support in bridgeless.
Changelog: [Android][Added] Allow js bundle file urls
Reviewed By: christophpurrer
Differential Revision: D58977143
fbshipit-source-id: 6f1a170546c8bbeac3a1b9d2dd5633177e33a688
Summary:
The ReactInstanceManager allows applications to register a ReactInstanceEventListener with itself.
Exposing a similar functionality to ReactHost. So, applications can do the same in bridgeless.
Changelog: [Android][Added] - Make ReactInstanceEventListener available on ReactHost
Reviewed By: christophpurrer
Differential Revision: D58890092
fbshipit-source-id: c18ee8a45d274c5cba859c6a5b4049904f1d308a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45138
Add a new `/open-debugger` endpoint format that allows specifying `target` - the proxy-unique target `id`. This is logically equivalent to specifying both device and page.
Changelog:
[General][Added]: Inspector: Support `/open-debugger` specifying `target` param
Reviewed By: hoxyq
Differential Revision: D58950622
fbshipit-source-id: 9665f8a24ba2bb0561cc3c693dfb84bfffdeb4a4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45140
Previously, if the `/open-debugger` endpoint was provided with both `device` and `appId` query params, we would:
- Try to find a target with a matching `device` (note that these logical "devices" are unique per-app) - if found, use it. Otherwise,
- Try to find a target with a matching `appId` - if found, use that.
This could go "wrong" in two ways:
- If a `device` is given with a spurious `appId`, we'd open to a target with an `appId` differing from the one specified.
- If the `device` has gone away but there is a different target with the same app, we'd use that as a fallback (right app, wrong device).
This applies the filters more strictly so that if both are given, both must match.
Changelog:
[General][Changed]: Inspector: Enforce device and appId filters if both are given to /open-debugger
Reviewed By: hoxyq
Differential Revision: D58951952
fbshipit-source-id: a95f1160e5c88f957445058f3273e922a5d28c1e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45088
This diff should make iterator-style prop setting more performant.
- It removes some layers of indirection. Now `ConcreteComponentDescriptor` calls into `setProp` directly.
- On both platforms, we will use `folly::dynamic` parser, it seems it is slightly faster.
- On Android, we will reuse `props->rawProps` parsed as a `folly::dynamic` representation, instead of parsing stuff twice.
Changelog: [Internal] - This hasn't been rolled out to OSS yet.
Reviewed By: javache
Differential Revision: D58593492
fbshipit-source-id: aa2dcb4e7ba2248f6ba7aa82a60355efdf769b2c
Summary:
This PR replaces the depreacted `statusBarOrientation` method to `interfaceOrientation`, as in the apple developer docs it clearly says the method has been deprecated
https://developer.apple.com/documentation/uikit/uiapplication/1623026-statusbarorientation
## Changelog:
[iOS] feat:- added UIInterfaceOrientation in place of statusBarOrietation.
[IOS] [ADDED] - Added RCTUIInterfaceOrientation helper method
Pull Request resolved: https://github.com/facebook/react-native/pull/44825
Test Plan: Tried `RNTester` build after the changes and it ran successfully!
Reviewed By: cortinico
Differential Revision: D58947500
Pulled By: cipolleschi
fbshipit-source-id: 401abf1d46b415093f441d1dbee139e7aaf8712c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45146
Changelog: [Internal]
Currently, on Android, we destroy the Fusebox `HostTarget` when we receive the `onHostDestroy` event, which (counterintuitively) does not mean the ReactHost/InstanceManager ("Java Host") is being destroyed. This can lead to situations where the `HostTarget` is destroyed too soon (e.g. when a single Java Host is reused across multiple Activities).
Now that we have the `invalidate()` method on the Java Host classes, we can tie `HostTarget`'s destruction to that instead.
Since calling `invalidate()` is explicitly optional, we also need to account for the case where the caller just lets go of the Java Host reference and expects GC to handle cleanup. This includes:
* Breaking the retain cycle between the Java Host and its C++ part. We achieve this using `WeakReference` to reference the Java Host.
* Making the C++ part of the Host safe to destroy from any thread (and in particular the finalizer thread). We achieve this by scheduling `HostTarget`'s unregistration (in C++) on the executor supplied by the Java Host.
Reviewed By: hoxyq
Differential Revision: D58284590
fbshipit-source-id: 4ee4780354fb81137b891d5891d6138ac215cbff
Summary:
Improve compatibility with web implementations of JS timers.
Fixes https://github.com/facebook/react-native/issues/45085
## Changelog:
[GENERAL] [CHANGED] - Timer functions are now throwing exceptions in less cases and are instead quiet quitting (similar to browsers)
[GENERAL] [CHANGED] - Timer functions `timeout` argument is now coerced to a number
Pull Request resolved: https://github.com/facebook/react-native/pull/45105
Test Plan: Updated RN tester
Reviewed By: christophpurrer
Differential Revision: D58952146
Pulled By: javache
fbshipit-source-id: 5b6de524f6a03f5221f0d11e0ae2a9313951c767
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45143
Changelog: [internal]
Just a small refactor of some private methods in `RuntimeScheduler_Modern` to refer to some concepts in terms of the event loop.
Reviewed By: christophpurrer
Differential Revision: D58948811
fbshipit-source-id: 979c78ccd4cf5d96f00061049366171934b43ee2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45082
Changelog: [Android][Breaking] `ReactNativeHost` invalidates the instance manager on `clear()`
Changes `ReactNativeHost.clear()` to invalidate the underlying `ReactInstanceManager`, rather than merely destroying the instance.
This is technically a **breaking change** because the underlying `ReactInstanceManager` may have escaped (via `ReactNativeHost.getReactInstanceManager()`) before the `clear()` call. In my reading of the API and of usages like [this one in Expo](https://github.com/expo/expo/blob/23a905b17065703882ebeda1fc9f65a05cc69fa7/packages/expo-dev-menu-interface/android/src/main/java/expo/interfaces/devmenu/ReactHostWrapper.kt#L117), this should rarely occur in practice.
The plan:
1. D58811090: Add the basic `invalidate()` functionality.
2. **[This diff]**: Add `invalidate()` call sites where it makes sense in core.
3. [Upcoming diff]: Keep the Fusebox debugging target registered until the Host is explicitly invalidated.
Reviewed By: javache
Differential Revision: D58811091
fbshipit-source-id: 5dfebad46a2bdf3601642b3c3fe3e79e8695e193
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45081
Changelog: [Android][Added] Add `invalidate()` method to ReactHost and ReactInstanceManager
Adds an `invalidate()` method to both `ReactHost` (Bridgeless) and `ReactInstanceManager` (Bridge). This method is an *optional* signal that the application is about to permanently stop using the Host, and that the Host can therefore fully clean up any resources it's holding.
Reusing a Host after it's invalidated is illegal and will trigger a Java assertion.
The plan:
1. **[This diff]**: Add the basic `invalidate()` functionality.
2. [Upcoming diff]: Add `invalidate()` call sites where it makes sense in core
3. [Upcoming diff]: Keep the Fusebox debugging target registered until the Host is explicitly invalidated.
Reviewed By: tdn120
Differential Revision: D58811090
fbshipit-source-id: 79b607dcc74de38b85fc0ebb4c640b9654595c9a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44939
DropShadow is a filter so we need to add the logic for sending it to native through the same process function for the other filters.
Drop shadow can have more arguments than the other filters. I'm following a similar pattern to boxShadow D57872933.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D58370127
fbshipit-source-id: dba06bb2e0ea2799d20e8b0b9065a5729df22bb6
Summary:
Accidentally shipped, removing.
## Changelog: [Internal]
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/45135
Reviewed By: christophpurrer
Differential Revision: D58950410
Pulled By: blakef
fbshipit-source-id: 7bda7278f918a1e50c25f86e461e19fe7e176c5c
Summary:
The cache checks in GHA were performed against bool values, while the actual values are strings.
So the checks were always failing and all the steps were executed, even when not necessary.
The reason why it was failing is because, with this setup, when a cache is hit, some steps were skipped in previous jobs, making following jobs trying to execute code on not-existing files.
## Changelog:
[Internal] - Fix cache for build_hermes_macos
Pull Request resolved: https://github.com/facebook/react-native/pull/45127
Test Plan: GHA are green again
Reviewed By: blakef
Differential Revision: D58947838
Pulled By: cipolleschi
fbshipit-source-id: 8dba216e72a3034fd4c1484418d37bfb78cf314d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45116
Changelog: [Internal]
The UIManagerBinding `findShadowNodeByTag_DEPRECATED` method returns a shadow node and was updating the runtime reference on the shadow node with the created wrapper for the return value.
The JSObject holding the wrapper would get deallocated, which would deallocate the wrapper stored on the shadow node.
This would cause crashes on the next reference update for the shadow node, due to the shared_ptr being reassigned with the new value while it was already deallocated.
The `sendAccessibilityEvent` function calls `findShadowNodeByTag_DEPRECATED` to get the shadow node referenced by the provided react tag, which could lead to runtime shadow node reference corruption.
Reviewed By: sammy-SC
Differential Revision: D58920296
fbshipit-source-id: ddb9ed0ee64bc01934aabde7070731dc53a2db70
Summary:
Platforms like visionOS require explicit framework dependencies to be set in pods to build properly. For some reason linking on visionOS is more strict than on iOS but this might change in some future OS versions so it's good to have pods having exact dependencies.
I've discussed that earlier with Saadnajmi and cipolleschi. Let me know if you are okay with this change.
## Changelog:
[IOS] [FIXED] - set proper framework dependencies for built-in pods
Pull Request resolved: https://github.com/facebook/react-native/pull/45104
Test Plan: CI Green
Reviewed By: dmytrorykun
Differential Revision: D58943593
Pulled By: cipolleschi
fbshipit-source-id: 3d2df4f3bbdf36704e09f5e39bfb838b2e0f3c99
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45111
Spent time debugging this issue today:
https://fb.workplace.com/groups/1700234700326965/posts/2197109080639522
The problem is described here:
https://perfetto.dev/docs/concepts/buffers
But basically we're writing too much data, too fast and the traced process can't read it fast enough. Perfetto is doing data drop.
This diff tries to use the `kStall` mode. It doesn't seem to do much but I'll leave it in for now because it shouldn't hurt too much. It's designed for our use case.
The main fix comes from increasing the buffer size to 20MB. Since it's not on by default I think it's fine to have a really large buffer for now to unblock tracing.
Reviewed By: javache
Differential Revision: D58832598
fbshipit-source-id: 101b364e2e9e28aa6a041ded1df82d5fec1f42e1
Summary:
This PR changes the call from `RCTSharedApplication()` to retrieve the status bar size using the `RCTUIStatusBarManager()` method, a way which supports multi-window apps.
## Changelog:
[IOS] [FIXED] - Retrieve status bar size using RCTUIStatusBarManager
Pull Request resolved: https://github.com/facebook/react-native/pull/45103
Test Plan: Check if the perf menu pops up in the correct spot.
Reviewed By: javache
Differential Revision: D58868503
Pulled By: cipolleschi
fbshipit-source-id: db5fc80a712a8a18a2863cdfbbe44f48bafe9fc3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45091
Changelog: [internal]
We're currently logging when we execute timers in Systrace/Perfetto, but we have no information about them whatsoever.
This adds some additional information:
* What kind of timer it is
* It's ID
* And most importantly, when it was created (including the ID as well).
This allows us to know where was a specific timer scheduled and with what API.
Reviewed By: bgirard
Differential Revision: D58832112
fbshipit-source-id: 1bc11759b6c8296acf63ff3533ca1dc3428360a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45090
Changelog: [internal]
The definition of these methods is redundant when using microtasks, so it's better to avoid defining them in the first place (to also detect issues if the setup is not what we expect).
Reviewed By: sammy-SC
Differential Revision: D58816582
fbshipit-source-id: dd1b07f8b11069605e3184b1272a9bbc3b44ca75
Summary:
After upgrading my project to the latest version of react native i.e, 0.74.2, i was getting an error when running `pod install` an the error was coming from the post install hook. Going deeper into the file tree, i found that some of the things are Nil and react native is trying to use some methods on them, so fixed those issues by using chaining operators to conditionally apply the path method on them.
## Changelog:
[Internal] - fixes the post install issue when running pod install with react native version, 0.74.2
Pull Request resolved: https://github.com/facebook/react-native/pull/45095
Test Plan: Manually tested the fix. Works perfectly fine in both debug and production mode.
Reviewed By: cortinico
Differential Revision: D58863666
Pulled By: cipolleschi
fbshipit-source-id: 64459711dcf926b7544b99b542e9861c1c0f05ca
Summary:
This PR uses a suggested solution from here: https://github.com/facebook/react-native/issues/42698 to allow users to use Cocoapods 1.15.2 which fixed issues regarding RN builds.
## Changelog:
[IOS] [FIXED] - Bump cocoapods version to 1.15.2 excluding 1.15.0, 1.15.1
Pull Request resolved: https://github.com/facebook/react-native/pull/45099
Test Plan: CI Green
Reviewed By: blakef
Differential Revision: D58863685
Pulled By: cipolleschi
fbshipit-source-id: 0128eb0cbf83e4a3d35addbae4c31e349775688c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45101
This test broke after I merged
https://github.com/facebook/react-native/pull/34785
yesterday.
Just fixing it in a similar way as the test above.
Changelog:
[Internal] [Changed] - Fix broken unableToAddHandledRootView
Reviewed By: rubennorte, blakef
Differential Revision: D58864166
fbshipit-source-id: 4f48dbfd5238a2811564ce02199af7fc284d39b4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44832
I'm renaming this folder as now we have 2 gradle plugins + we currently have
`package/react-native-gradle-plugin/react-native-gradle-plugin/` which is confusing so we can just call this folder `packages/gradle-plugin/`
to be consistent with the NPM package name
Changelog:
[Internal] [Changed] - packages/react-native-gradle-plugin/ -> packages/gradle-plugin/
Reviewed By: blakef
Differential Revision: D58284883
fbshipit-source-id: 5a7bb40a5d80f6fbab4ffb29e44107453f1013ec
Summary:
Follow the same solution (do not throw a crash when view ID is set already) used in `ReactAndroid/src/main/java/com/facebook/react/ReactRootView.java` for `ReactAndroid/src/main/java/com/facebook/react/fabric/mounting/SurfaceMountingManager.java`
## Changelog
[Android] [Changed] - Log a SoftException on SurfaceMountingManager.addRootView
Pull Request resolved: https://github.com/facebook/react-native/pull/34785
Test Plan: None
Reviewed By: cipolleschi
Differential Revision: D40022263
Pulled By: cortinico
fbshipit-source-id: d565d2831e2833ccea55f28ea16083b7bae0ed32
Summary:
Adds an overload for `createLayout` method that also handles extracting paragraph attributes and scaling font size if necessary.
## Changelog:
[ANDROID] [CHANGED] - Extracted common parts related to calculating text layout to a helper
Pull Request resolved: https://github.com/facebook/react-native/pull/45083
Test Plan: Tried out on RNTester
Reviewed By: robhogan
Differential Revision: D58818560
Pulled By: cortinico
fbshipit-source-id: a42b5de04c4a70edb88cdd734387d7e4cee94032
Summary:
While landing a change on GH, I forget to remove one line that does not belong to an action
## Changelog:
[Internal] - CI fix
Pull Request resolved: https://github.com/facebook/react-native/pull/45084
Test Plan: GHA are green
Reviewed By: blakef
Differential Revision: D58817768
Pulled By: cipolleschi
fbshipit-source-id: 5fc02d2d2a19dd3fe2202c93d0d1873e5dda4b82
Summary:
This change is the first step in refactoring GHA so that they can be reused more easily across jobs.
Its goal is also to be more reliable w.r.t. caches.
That this change do:
* moves `prepare_hermes_workspace` to a composite action
* saves the `prepare_hermes_workspace` caches only on main
* uploads the destination folder as an artifact so that we can use it later in the run
* makes the `test-all`, `nightly` and `publish-release` workflow use the new composite action
* updates the `setup-hermes-workspace` to download and use the artifact uploaded by `prepare_hermes_workspace`
## Changelog:
[Internal] - Factor out the prepare_hermes_workspace action
Pull Request resolved: https://github.com/facebook/react-native/pull/45071
Test Plan: GHA in CI
Reviewed By: cortinico
Differential Revision: D58808087
Pulled By: cipolleschi
fbshipit-source-id: 42c46bcf75fc73b2edfda9be62b5d0fe8a919a5d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45076
> **start**: The same as left if direction is left-to-right and right if direction is right-to-left.
This is equivalent to `auto`, which is not actually a valid CSS value.
Changelog: [General][Added] Add support for `texAlignment: 'start'`
Reviewed By: sammy-SC
Differential Revision: D58791937
fbshipit-source-id: 09622d814212a7055f94b1f091c71edae5db117c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45073
We can also remove the workaround needed for git `safe.directory`
as this is now configured inside the container as `*`
Changelog:
[Internal] [Changed] - Bump reactnativecommunity/react-native-android to 13.1
Reviewed By: blakef
Differential Revision: D58789791
fbshipit-source-id: f44163a0aa822b19e0dd1106d3f039fd0dc83186
Summary:
This change splits the build step and the test step for running the test on iOS, so we can introduce a retry for the test only.
We are doing that because we have seen some flakyness in CI jobs as sometimes the simulator fails to install the app.
## Changelog:
[Internal] - Add retry to iOS tests
Pull Request resolved: https://github.com/facebook/react-native/pull/45070
Test Plan: Testing in CircleCI
Reviewed By: cortinico
Differential Revision: D58786706
Pulled By: cipolleschi
fbshipit-source-id: 61363cb86dd1a496d3595b43b6331cbee7f032ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45060
Currently, `j`, (i.e., `/open-debugger` with no parameters), connects the "first available" target, which in practice is the first page of the first connected device still connected.
In the absence of a target selection UI, a better guess at user intent is to use the *latest* target (most recently added page of most recently connected device).
Also slightly reduces CLI noise by not claiming that we're launching a debugger when there's no target, and not qualifying which target when there's only one.
Changelog:
[General][Changed] Debugger: `j` opens most recent (not first) target.
Reviewed By: huntie
Differential Revision: D58736151
fbshipit-source-id: 3d106a1fa958f9e5c91b16e04075609e1abf6e97
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45069
Currently, `/json/list` returns pages within each device in the iteration order of a C++ `unordered_map`, which doesn't tell us anything useful. Page IDs happen to be sequential, but only as an implementation detail.
Change this contract so that we guarantee ordering reflects addition order, allowing clients to consistently select e.g. most recently added page for a given device.
The implementation of this is as simple as switching from an `unordered_map` to a key-ordered`map`, because we already assign keys (page IDs) with an incrementing integer. Within the inspector proxy, devices already use an insertion (connection)-ordered JS `Map`, so we just document this guarantee.
Changelog:
[General][Changed] Debugger: Make `/json/list` return connection-addition-ordered targets.
Reviewed By: huntie
Differential Revision: D58735947
fbshipit-source-id: 7a132cc5e750475792a2b845afc9a42424690bf1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44840
Changelog: [Internal]
Introduce a simplified and minimal tracing backend for Fusebox. This backend is sufficient to implement a pretty usable performance panel.
Although the more I see how easy this is and how annoying working with Perfetto is, the more I think we should just maintain this going forward. Anyways we can figure that out incrementally. For now the plan is still for this to be temporary.
Reviewed By: motiz88
Differential Revision: D57981944
fbshipit-source-id: b3d8c6e8c5a18311bbe98254f8ddf3810fa1334b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45068
changelog: [internal]
In D58672844 I added gating to module.exports.
This gating is sensitive to when feature flags are initialised and causes test failures and regressions for developers. Let's move the feature flag check to component's render function. It introduces extra spread operator but it is good enough to compare new and old <Text /> component.
Reviewed By: GijsWeterings
Differential Revision: D58783941
fbshipit-source-id: f89f4f48e6aeb774ed4a84483a9f4ad59d5bc045
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45026
All callsites for these containers already explicitly synchronize using these objects, so there's no need to use a synchronized collection wrapper here.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D58724044
fbshipit-source-id: 5151ebb0ceda8656b6039d9984cc32a843051abd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45025
This API just passed through the `enableArchitectureIndicator` prop to a custom WrapperComponent, as there is no default consumer of it. Instead, each provider of a custom WrapperComponent can capture the required value of itself.
Changelog: [General][Removed] Removed enableArchitectureIndicator API which is only used internally.
Reviewed By: cortinico
Differential Revision: D58723922
fbshipit-source-id: 0c52a904424382f33caab92ac50b316ae161f877
Summary:
This incorrectly used the SHA from facebook/react-native instead of
facebook/hermes to label the hermes cache key. This would bloat our
cache by ~ 1.2GB for each PR.
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/45061
Test Plan: We should remove the existing entries for v4-hermes and track the growth over time.
Reviewed By: cipolleschi
Differential Revision: D58780475
Pulled By: blakef
fbshipit-source-id: 0f192faa287f53154f1c8319be6783820d614018
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45059
Changelog: [internal]
By moving the command to a code block it's going to be easier to see it when quickly reading the README.
Reviewed By: cortinico
Differential Revision: D58779883
fbshipit-source-id: e912a58641245c6d7dc158f7af0a722e438a0cc3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44964
Testing property priority and correct setting percentages for business logic of `BorderRadiusStyle.kt`
To prevent issues like the one fixed by D57473482
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D58705515
fbshipit-source-id: 74e9a68fc0e3d1e88b8eebbb34a1ca8c29052c21
Summary:
The existing regex is not workign. I've split it in two and tested it against a private repo.
## Changelog:
[INTERNAL] - Fix release regex for publish-release workflow
Pull Request resolved: https://github.com/facebook/react-native/pull/45043
Test Plan: Tested on privare repo with GHA
Reviewed By: cipolleschi
Differential Revision: D58736292
Pulled By: cortinico
fbshipit-source-id: f07ef32dcb0059922100c555f7894bbf0c7dd8f6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45035
Changelog: [General][Fixed] Avoid a zombie state when opening a second debugger frontend concurrently.
The problem here was that we were sending proxy-protocol messages to the device in the wrong order (`disconnect` *after* `connect`):
{F1701266597}
The root cause was that we were depending on the outgoing debugger socket's async `close` event to trigger sending the `disconnect` message to the device. This would happen after we'd already (synchronously) sent the `connect` message.
With this diff, we send the `disconnect` message synchronously with calling `close()` on the debugger socket, which fixes the ordering problem at the source. To avoid sending duplicate `disconnect` messages (e.g. one before calling `close()` and one from the `close` event handler), we store some extra state on `Device` (`#connectedPageIds`).
Reviewed By: robhogan, huntie
Differential Revision: D58730634
fbshipit-source-id: 0f54af2e4f8071a8f6d97cc9e3d8a4ea89a46f43
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45027
Changelog: [Internal]
Changes the device ID collision handling logic to reuse `Device` instances instead of creating new ones. This enables further refactoring of `Device` to improve session state isolation.
Reviewed By: hoxyq
Differential Revision: D58724884
fbshipit-source-id: bc11ce45ce8c80c58c32dcd1b07b28f1d1753a62
Summary:
We are moving to publish from gha so we need to remove these jobs
## Changelog:
[Internal] - Remove old publishing jobs from CI
Pull Request resolved: https://github.com/facebook/react-native/pull/45040
Test Plan: CircleCI is green
Reviewed By: cortinico
Differential Revision: D58734881
Pulled By: cipolleschi
fbshipit-source-id: 5981bfcf2aa51d55d54d08556631b30b6102a7cd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45032
Those tests haven't been running since ~1 year now.
I know it's not ideal but I'd rather remove them instead of keeping them around not executing.
We can still revert them back from the history once we decide to revive the E2E testing effort.
Changelog:
[Internal] [Changed] - Remove unused rn-tester e2e tests
Reviewed By: cipolleschi
Differential Revision: D58729123
fbshipit-source-id: f0f47e3c2e087141fdff506b7c5c9b460263721b
Summary:
Fixes https://github.com/facebook/react-native/issues/41988
Hopefully even if this isn't the right way to go about solving this, it at least points in the right direction for a different fix!
Currently - both on Paper and Fabric - the `selectTextOnFocus` prop does not work as expected on a single line text input. It seems that if the `UITextField` has not yet become the first responder, the text will be briefly selected but then deselected immediately afterward.
This can be seen in the tester when running for either Fabric or Paper (video using Fabric)
https://github.com/facebook/react-native/assets/153161762/aa9c609e-6eb8-4177-a41f-32aae53c06ac
Instead, we can move the `selectAll` call to `reactFocus` in `RCTBaseTextInputView` or `focus` `RCTTextInputComponentView` - both of which first call `becomeFirstResponder` - to get the expected result.
## Changelog:
[IOS] [FIXED] - fix selectTextOnFocus in Fabric and non-Fabric by calling selectAll after becomeFirstResponder
Pull Request resolved: https://github.com/facebook/react-native/pull/44307
Test Plan:
* Test changes on RN Tester (iOS)
https://pxl.cl/55kDc
Reviewed By: cipolleschi
Differential Revision: D56699773
Pulled By: fabriziocucci
fbshipit-source-id: ed092835f3c602e2c50a4198357653a9cef942d9
Summary:
Use GHA on PRs:
1. run test_android_helloworld when users create a PR, to provide coverage while we figure out what's going on with our CircleCI tests / deprecate them.
2. fixes uploading the `.apks` that are generated.
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/45019
Test Plan: Does GHA run for this PR?
Reviewed By: cipolleschi
Differential Revision: D58728019
Pulled By: blakef
fbshipit-source-id: c6db41d60225702d50343384f103585d83e3528c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45023
This mirrors the same setup we have on the 0.75 release branch
Changelog:
[Internal] [Changed] - Move test_android_helloworld to 4-core-ubuntu
Reviewed By: cipolleschi, blakef
Differential Revision: D58724157
fbshipit-source-id: 754d4f777d4239eeaa6a5232508f54cfe62d4c88
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45013
Changelog: [internal]
## Context
We recently realized that in the majority of events dispatched to React from Fabric, passive effects were being mounted synchronously, blocking paint instead of in a separate task after paint.
The reason for that is that in React, passive effects for discrete events are mounted synchronously by design (see https://github.com/reactwg/react-18/discussions/128), and Fabric is currently assigning the discrete event priority to most current events (including things like layout events).
## Changes
This creates a feature flag to opt into a more granular control over event priorities in React Native. Instead of assigning the discrete event priority to events by default, this would assign the "default" event priority by default, except for events dispatched during continuous events that would also be considered continuous.
This would also fix the priority for continuous events, that it was currently being assigned as "default" incorrectly.
Reviewed By: christophpurrer, javache, sammy-SC
Differential Revision: D58677191
fbshipit-source-id: c65a8dc2118ed028e1e895adec54f9072b7e55a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45011
Changelog: [Internal]
Fixes an inspector-proxy test case that was (silently) incorrect. This is in preparation for an upcoming rewrite of the core of inspector-proxy to more strictly isolate session state, which causes the incorrect test to fail.
Reviewed By: hoxyq
Differential Revision: D58193527
fbshipit-source-id: bdc27179210117ca9249b272f2e4aff19ba8a06c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44908
Changelog: [General] [Changed] - CircleCI test to Helloworld, but disabled for now until we remove the template
Reviewed By: cipolleschi
Differential Revision: D58469912
fbshipit-source-id: 718a774946bd70347697f18bbfc470b2897d2f87
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44962
Add a short term fork of `Text` for the purpose of performance testing.
Specific differences from `Text`:
- Lazy init Pressability via a nested component.
- Skip children context wrapper when safe.
- Move props destructuring to function param.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D58601810
fbshipit-source-id: 988bac6100287705fb1bf8dc48cb2cfae56343df
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44964
Testing property priority and correct setting percentages for business logic of `BorderRadiusStyle.kt`
To prevent issues like the one fixed by D57473482
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D58602799
fbshipit-source-id: 605bc384267d9f4ae5a051e76c1a4d862fe54039
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44884
Removing JavaScript error handler supplied to ReactHostImpl.java which is just a stub and creating a default handler in ReactInstance.java which uses NativeExceptionHandler TurboModule to handle error.
Changelog: [Android][BREAKING] Removing `ReactJsExceptionHandler` param from ReactHostImpl() constructor and providing a default private implementation
Reviewed By: javache, cortinico
Differential Revision: D58385767
fbshipit-source-id: 46548677df936b7c2f584084a2c9769c27e6a963
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45010
D46482492 added logic for handing off state across "device" connections that have the same ID. This logic currently has no test coverage. It also contains a bug whereby the new device's pages are removed from the target listing endpoint (`/json`) when the *old* device's socket is closed.
This diff adds tests and fixes the bug.
Changelog: [General][Fixed] inspector-proxy no longer accidentally detaches connected devices.
## Next steps
It seems that the device ID handoff logic exists to paper over a deeper problem with the inspector proxy protocol (or its implementation in React Native): The React Native runtime should not routinely be creating new "device" connections without tearing down previous ones.
In followup diffs, I'll explore changing this behaviour for Fusebox, based on the new test coverage.
Reviewed By: robhogan
Differential Revision: D51013056
fbshipit-source-id: e0c17678cc747366a3b75cef18ca2a722fc93acd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45009
This script dependes on the template existing in react-native/template. We're removing this, but can't land that until we disable this test.
Future work could move this test into the react-native-community/template project to validate against RN release candidates to support releases.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D58672744
fbshipit-source-id: c1500aebb0b21afd1ba37785e73dd6a0e1d6020e
Summary:
Qhile landing the changes for React19 in 0.75, we missed one test that needs to be updated
## Changelog:
[Internal] - Fix Jest tests in React 19
Pull Request resolved: https://github.com/facebook/react-native/pull/45007
Test Plan: CircleCI is green
Reviewed By: robhogan
Differential Revision: D58671824
Pulled By: cipolleschi
fbshipit-source-id: 48a72f5cdc4d03201cb1778915ed3519759cf017
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45006
The steps were pointing to an incorrect folder. Updated to points to react-native/packages
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D58669426
fbshipit-source-id: b58b9bc7d8c7860f2f46c8bdf4bf0636e82ee357
Summary:
After updating my project to 0.73.2 I noticed that even though I had a specific port set in my `metro.config.js`, every time I'd start my project, it was running on port 8081. Passing the `--port` argument would allow me to change the port, but the config from metro did not. I checked if the metro config was being properly applied, using `--verbose` and it was.
So I dug a bit, trying to figure out what had changed and noticed the coalescing of the value, whenever the argument `--port` is not present. That seemed odd since it meant that there's always a port defined for the `options` of `loadMetroConfig`, which would always be used in the `loadConfig` step.
To confirm I was on the right track I went to the [cli-plugin-metro](https://github.com/react-native-community/cli/blob/v11.3.10/packages/cli-plugin-metro) repo, to the last release before the move here, and noticed that there was [no coalescing in the same method](https://github.com/react-native-community/cli/blob/v11.3.10/packages/cli-plugin-metro/src/commands/start/runServer.ts#L60).
In this PR, I remove the coalescing of the port from `runServer.js` from the `community-cli-plugin`, to allow the port configuration through `metro.config.js`.
## Changelog:
[INTERNAL] [FIXED] - Fix server port configuration via `metro.config.js`
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/44957
Test Plan:
Running `yarn start` and verifying that:
- it would listen to port `8081` if no argument nor a custom port was set in `metro.config.js`
- it would listen to port `8082` if that one was defined in `metro.config.js`
- it would listend to port `8083` if that port was passed as an argument to the command (i.e. `yarn start --port 8083` even though port 8082 was defined in `metro.config.js`
Reviewed By: cortinico
Differential Revision: D58605152
Pulled By: robhogan
fbshipit-source-id: 9cf7a8b6a0d9de3af1ca4092906b4c648acee373
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45005
We've had failures owing to running out of disk space, however this isn't a stable failure. Adding more data about disk availability and utilisation to help debug these issues.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D58667190
fbshipit-source-id: 3d5f7cc985ac71044818f7b5663ef7400ad691b5
Summary:
Implements `requestIdleCallback` and `cancelIdleCallback`
### Notes
Proposed implementation does yet cover all WHATWG eventloop requirements.
- Deadline computation is not implemented and is polyfilled by giving each callback `50ms`, rather than it being shared between other idle callbacks.
- The requested callbacks are called with lowest priority by the scheduler as of now, but the execution is not as described in the standard.
## Changelog:
- [GENERAL] [ADDED] - Implemented `requestIdleCallback` and `cancelIdleCallback`
Pull Request resolved: https://github.com/facebook/react-native/pull/44759
Reviewed By: javache, sammy-SC
Differential Revision: D58415077
Pulled By: rubennorte
fbshipit-source-id: 46189d4e3ca1d353fa6059a904d677c28c61b604
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44991
Updates the open source renderers for React 19. This is in preparation for React Native 0.75.
Notable, this incorporates the feature flag changes from [facebook/react#29903](https://github.com/facebook/react/pull/29903).
Changelog:
[General][Changed] - Upgrade Renderers for React 19
Reviewed By: robhogan
Differential Revision: D58632199
fbshipit-source-id: 674bb47554e4b0c6ab5127fb9683ed8284b7a4ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44990
Upgrades React Native and Relay to depend on React 19, which is currently published as release candidates. This is in preparation for React Native 0.75.
This will depend on updating open source renderers after [facebook/react#29903](https://github.com/facebook/react/pull/29903) is merged.
Changelog:
[General][Changed] - Upgrade to React 19
Reviewed By: robhogan
Differential Revision: D58625271
fbshipit-source-id: f9ad95b18716a9ce02f7cfbcc7248bdfb244c010
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44989
Enables these 2 global feature flags for React Native Jest testing:
- `IS_REACT_ACT_ENVIRONMENT`
- `IS_REACT_NATIVE_TEST_ENVIRONMENT`
Changelog:
[General][Changed] - Enables React global flag that causes Jest testing environment to require `act()`
Reviewed By: robhogan
Differential Revision: D58644562
fbshipit-source-id: 4de5ea3a89e8ca99ac4c1c21721872db4f5552b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45002
There are a couple Jest unit test cases for `VirtualizedList-test.js` that require further investigation.
We believe that these are problems with Jest fake timers in the test and not with the component itself, so for now let's skip them so as to unblock the upgrade to React 19.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58656948
fbshipit-source-id: d52f3ad8277def6eae20cbbc11751d73b769d929
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44997
Wrap `VirtualizedList-test` uses of `react-test-renderer` in `act` as appropriate, so as to pass under current React and mostly pass under React 19, with further fixes to come.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D58649295
fbshipit-source-id: 5e0fa791d581fbf004a2ca7eaa5c4b4d9a15ddfe
Summary:
Migrate `VirtualizedSectionList-test` to use `act`-wrapping in prepation for React 19.
Avoid the `react-native/jest/renderer` abstractions as this is a separate package.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D58653558
fbshipit-source-id: 0e19fff5c3998fb00b71c3d07100a2064682cb4c
Summary:
Use `act`-wrapping abstractions for `create`/`update`/`unmount` in `Animated-test` so that it's React 19-ready.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D58653231
fbshipit-source-id: 44075dfde9740070279c0d1004674349d63de9cd
Summary:
Wrap `ReactTestRenderer.create` in `act` within `ReactNativeTestTools.expectRendersMatchingSnapshot`, as required for concurrent rendering and `IS_REACT_ACT_ENVIRONMENT` in React 19.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D58653136
fbshipit-source-id: 9ca0d053bda3e87dd92b762061b839d7bdd571b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44961
Switch the "number of lines" warning, which ensures this value is not negative, to only fire in DEV.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D58472148
fbshipit-source-id: e52849effe9a6dc3f25288a64deebd4fd7624e4e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44999
Use `act`-wrapped abstraction for test rendering in preparation for this becoming mandatory.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D58651098
fbshipit-source-id: d797c792b1f6ac155f02951a8264cf0631961d83
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44998
Add async helpers to the existing `jest/renderer` module to wrap `react-test-renderer`'s `update` and `unmount` in `act`.
Migrate one test `ScrollView-test` as a usage example and to make it compatible with incoming React 19 concurrency requirements.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D58650989
fbshipit-source-id: 5eb48722ee7a5487355969e553ba79c3ce361067
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44994
For RN monorepo tests, wrap `create` calls through our `jest/renderer` abstraction in `await act`.
This is a no-op under current React but will be required under `react-test-renderer@19` with `IS_REACT_ACT_ENVIRONMENT`.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D58650940
fbshipit-source-id: 4013af89dd7c9f447b2dd493989f3a4fdf2b6508
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44996
Mock out some LogBoxData symbolication in LogBoxInspector-test that would otherwise make it sensitive to an async `useEffect` when wrapping in `act`.
This is immaterial to the snapshot under test (changing a state from `PENDING` to `NONE`).
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D58651811
fbshipit-source-id: d47100a87d83102bbe183cb7266d66344e75b0b0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44993
Use our existing thin abstraction around `react-test-renderer` `create` within `react-native/jest/renderer`, in order to benefit from the introduction of async `act` wrapping in that abstraction.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D58650874
fbshipit-source-id: d3d1967fa68568e3ae2d8069478cb79aa7049ed0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44992
To allow for async `act` in a subsequent diff, make this utility method async and awaited at all call sites.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D58647828
fbshipit-source-id: 3a47c57569814638c216309eed1885dd37521dde
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44995
Use our existing abstraction around `react-test-renderer`'s `create` and make it asynchronous, to allow for wrapping `create` in `act` in a subsequent diff, and using the async API per guidance in https://react.dev/reference/react/act?#await-act-async-actfn .
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D58647827
fbshipit-source-id: f81cf382892ef5ba14b452bd32980c98bd7ef03b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44982
Removes `react-shallow-renderer` dependency from the `react-native` package because it is no longer used.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643454
fbshipit-source-id: f9aa62af2ff0282d6b54b97da6f2870a38881947
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44973
Changes `expectRendersMatchingSnapshot` to no longer make assertions about shallow rendering, because shallow rendering is now deprecated.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643365
fbshipit-source-id: 03653045a44a176095c53fc0ff27743cc8ea1820
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44980
These Jest unit test cases were making assertions about shallow rendering, but that shallow rendering is now deprecated.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643065
fbshipit-source-id: 34a31989f298535546a64c3ccd2888d648c1cdf1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44977
These Jest unit test cases were making assertions about shallow rendering, but that shallow rendering is now deprecated.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643060
fbshipit-source-id: a61dfcf6cd778a8556aec874fd5e42f8e11f2be2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44970
These Jest unit test cases were making assertions about shallow rendering, but that shallow rendering is now deprecated.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643058
fbshipit-source-id: 75c95b3ef8f9c481b50d90bf195ba3bd90196f0b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44975
These Jest unit test cases were making assertions about shallow rendering, but that shallow rendering is now deprecated.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643064
fbshipit-source-id: 19cb05df25b4b92ee584ea126d238276f5b214f7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44981
Migrates this Jest unit test away from using `react-shallow-renderer` because it is no longer recommended.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643062
fbshipit-source-id: 6d7bba78945509bbb6bdab1e6347ba0d90343ec3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44971
Migrates this Jest unit test away from using `react-shallow-renderer` because it is no longer recommended.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643068
fbshipit-source-id: f3a0331140fbaa9ee19b76da8700e60b3efc525a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44976
Migrates this Jest unit test away from using `react-shallow-renderer` because it is no longer recommended.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643067
fbshipit-source-id: 2e298e2736227afb9322463daa3db0578638559a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44969
Migrates this Jest unit test away from using `react-shallow-renderer` because it is no longer recommended.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643057
fbshipit-source-id: 0d2943a714ca718841ab4bec5a33f6c9e48fea92
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44986
Migrates this Jest unit test away from using `react-shallow-renderer` because it is no longer recommended.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643069
fbshipit-source-id: a2dbba104a7f6af57b6990da3cb0055a5390bc00
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44983
Migrates this Jest unit test away from using `react-shallow-renderer` because it is no longer recommended.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643056
fbshipit-source-id: 61494765f68f1810b19a33f5e2a6c5d4087ce11c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44972
Migrates this Jest unit test away from using `react-shallow-renderer` because it is no longer recommended.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643055
fbshipit-source-id: 419fe07643f623e75050487beb9ca306417e43d9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44978
Migrates this Jest unit test away from using `react-shallow-renderer` because it is no longer recommended.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643059
fbshipit-source-id: 0eb36537fd3a8c69f4861fac14b99755eff97f04
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44968
Migrates this Jest unit test away from using `react-shallow-renderer` because it is no longer recommended.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643066
fbshipit-source-id: 216a036ef8e5cfe9b362c2f367da052ee6c9808b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44979
Migrates this Jest unit test away from using `react-shallow-renderer` because it is no longer recommended.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643061
fbshipit-source-id: 0c68324d4d92fc8818ac469737eda3679aa773b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44974
Migrates this Jest unit test away from using `react-shallow-renderer` because it is no longer recommended.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58641098
fbshipit-source-id: be7592b3fb5c4a66879ad734439faceb4ad5cdde
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44987
Migrates this Jest unit test away from using `react-shallow-renderer` because it is no longer recommended.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58641097
fbshipit-source-id: a9d3abee19d58262d36ac250a55780df803c464b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44967
Migrates this Jest unit test away from using `react-shallow-renderer` because it is no longer recommended.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58641096
fbshipit-source-id: e9752f21763156ee409ae81a304cada84a346bdb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44985
Migrates this Jest unit test away from using `react-shallow-renderer` because it is no longer recommended.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58641095
fbshipit-source-id: 90563955876a148a2b867e0ec5128bdd8786f274
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44888
In https://github.com/facebook/react/pull/29839 we removed the `Warning: ` prefix. This PR replaces the special cases in LogBox for `Warning: ` to use the presence of a component stack instead. This is what LogBox really cares about anyway, since the reason to let errors pass through to the exception manager is to let DevTools add the component stacks.
Changelog: [General] [Fixed] - Fix logbox reporting for React errors
Reviewed By: rickhanlonii
Differential Revision: D58441017
fbshipit-source-id: 5355cd04ddcd5238dadbfcbd64fe1f43c8cd04dc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44958
Now, all soft exception methods will have raiseSoftException(...)
## Before
```
BridgelessReact: ReactHost{0}.getOrCreateDestroyTask(): handleHostException(message = "Unable to load script. Make sure you're either running Metro (run 'npx react-native start') or that your bundle 'RNTesterBundle.js' is packaged correctly for release.")
```
## After
```
BridgelessReact: ReactHost{0}.raiseSoftException(getOrCreateDestroyTask()): handleHostException(message = "Unable to load script. Make sure you're either running Metro (run 'npx react-native start') or that your bundle 'RNTesterBundle.js' is packaged correctly for release.")
```
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D58593609
fbshipit-source-id: 171a872cd41e4ffe9c2e9654c563a6f3af342ad9
Summary:
When an XMLHttpRequest is performed, the `onprogress` event it is not invoked when the `Content-Length` header is missing in the response. This is the case when we are calling an endpoint that responds with `transfer-encoding: chunked` (https://tools.ietf.org/html/rfc9112#section-7.1), preventing the user to keep track of the progress while the server is sending chunks. Despite we will never know the total length of the content (because it will not be known due to the RFC specification, so it will be always `-1`), we will now be able to keep track of the loaded data.
Note that in Android, this is the current default behaviour.
To address this issue:
- I removed the condition where the `downloadProgressBlock` was dispatched only when `response.expectedContentLength` was greater than 0
- I created a new test case for `XMLHttpRequest` in the tester app to download a chunked file
## Changelog:
[IOS] [CHANGED] - fire `onprogress` event for `XMLHttpRequest` even when the `Content-Length` header is missing in the response headers
Pull Request resolved: https://github.com/facebook/react-native/pull/44899
Test Plan:
|before|after|
|----------|:-------------:|
|https://github.com/facebook/react-native/assets/37150312/6da3518f-eed3-4808-a2f8-abe26e5c7487|https://github.com/facebook/react-native/assets/37150312/ed1da300-dcf7-4874-a941-a2289f1cb777
Reviewed By: cortinico
Differential Revision: D58562088
Pulled By: NickGerleman
fbshipit-source-id: 23a1cafa49ddcd25fa0db7d04fae845126771425
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44952
The test_helloworld_android Release variant are broken on GHA.
This fixes it as it forces hermesc to be built *before* the app attempts to create a bundle.
Changelog:
[Internal] [Changed] - Fix for broken test_helloworld_android on Release
Reviewed By: cipolleschi, blakef
Differential Revision: D58591480
fbshipit-source-id: 2afc1cfe8c416da6f5919d20098639653798dd1a
Summary:
With the migration to GHA, we are updating the testing scripts to work with the new CI.
There are a bit of shenanigans due to:
* How GHA archives artifacts => they are all `.zip` files, so I had to play around with unzipping them
* GHA seems to create a different commit, like if it is forking the repo instead of using it. I think that it is how the checkout action works. *Note:* this might be a problem for the `Create React Native Release` workflow because it has to commit on the stable branch!
* Android is building only the simulator architecture when running from regular CI. The app is not configured to run only on that, so the RNTestProject was a failing because it was trying to build all the available architectures. It is an easy fix in the user project space when release testing.
## Changelog:
[Internal] - Update the testing script to work with the new CI
Pull Request resolved: https://github.com/facebook/react-native/pull/44923
Test Plan:
Tested locally.
* [iOS] RNTester - Hermes ✅
* [iOS] RNTester - JSC ✅
* [Android] RNTester - Hermes ✅
* [Android] RNTester - JSC ✅
* [iOS] RNTestProject - Hermes ✅ (The project is created correctly and it builds, crash at runtime for https://github.com/facebook/react-native/issues/44926)
* [iOS] RNTestProject - JSC ✅ (The project is created correctly and it builds, crash at runtime for https://github.com/facebook/react-native/issues/44926)
* [Android] RNTester - Hermes ✅ (Needed to build only the simulator architecture)
* [Android] RNTester - JSC ✅ (Needed to build only the simulator architecture)
Reviewed By: andrewdacenko
Differential Revision: D58528432
Pulled By: cipolleschi
fbshipit-source-id: 733065de4c532b13d8e95e2217f9aafd5a2ef8a0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44924
# Changelog: [Internal]
For Strict Mode, RDT backend will apply ANSI escape codes to style the message, basically to dim it for 2-nd invocations of logs / warnings / errors in Strict Mode.
With these changes, LogBox will filter out these stylings, so that the message is displayed correctly in the LogBox bubble and in LogBox panel (full screen mode).
Reviewed By: rickhanlonii, yungsters
Differential Revision: D58477316
fbshipit-source-id: 17773f658d2a3bfa7f6a3ccec9fc88a97dd2c0af
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44919
## Changelog:
[Internal] [Fixed] - Call Turbo Module methods 'methods' in the Turbo Module JSON schema
We don't support `properties` on Turbo Modules. We only support methods (even eventEmitters are just methods)
Reviewed By: javache
Differential Revision: D58510557
fbshipit-source-id: 02b1dc93a37b58b47bb9fd94a9658b5a7301bf55
Summary:
PR changing the single mountingOverrideDelegate to a vector of those, so other listeners can operate on the transaction. Used by `react-native-screens` in https://github.com/software-mansion/react-native-screens/pull/2134 and `react-native-reanimated` in https://github.com/software-mansion/react-native-reanimated/pull/6055.
Till now, only one listener could be added there, meaning that e.g. `Layout Animations` from `react-native`, `Layout Animations` from `react-native-reanimated` and listening for `Screen` removal in `react-native-screens` could not operate at the same time.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[GENERAL] [FIXED] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[GENERAL] [FIXED] - Add option for multiple `mountingOverrideDelegates`
Pull Request resolved: https://github.com/facebook/react-native/pull/44927
Test Plan: The code of `LayoutAnimations` inside `react-native` should work the same since it will add just one listener then. For other cases, different libraries can read/mutate transactions.
Reviewed By: javache
Differential Revision: D58530278
Pulled By: sammy-SC
fbshipit-source-id: d6305963621000be11d51a50cffff64526cca934
Summary:
CircleCI is removing support for intel machines at the end of June, hence we have to migrate to M1.
## Changelog:
[Internal] - Migrate to M1
Pull Request resolved: https://github.com/facebook/react-native/pull/44944
Test Plan: CircleCI is green
Reviewed By: robhogan
Differential Revision: D58589100
Pulled By: cipolleschi
fbshipit-source-id: da7359d8c13093ef1595adc5fabb4f3628006c7a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44951
As the latest minor of AGP just released, let's bump it so that 0.75 users can use it.
Changelog:
[Android] [Changed] - AGP to 8.5.0
Reviewed By: cipolleschi
Differential Revision: D58587826
fbshipit-source-id: c14091faba1cb270ea2386f22fdbf079bce61421
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44948
This is a small improvement suggested by tido64 to also account for package.json when computing caching
for autolinking of libraries.
Changelog:
[Internal] [Changed] - Add package.json to default `lockFiles` for ReactSettingsExtension
Reviewed By: cipolleschi
Differential Revision: D58587739
fbshipit-source-id: 6e0acf7d4badd8d8cc25dd90bb55fd6c0fa3779b
Summary:
## Context
Right now, the ReactInstance construtor eagerly initializes native modules.
## Problem
When these modules initialize, they may load other modules. But, all those loads will fail, because the react instance is in the process of being constructed.
## Changes
Eagerly initialize modules after the react instance is created. That way, these native module requires work.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D58537536
fbshipit-source-id: d0e424df708ec35b014f5cecda11e8756e8f4346
Summary:
## Changes
1. Store the react instance inside a private property (vs in the mReactInstanceTaskRef)
2. Attach the react instance to that property immediatley, after create
## Problems resolved
1. React host apis that use the instance (like ReactContext.getNativeModule()) will now also work **during** react native init. (see T191972567).
2. If exceptions get thrown during react instance init, the react instance will now get cleaned up (see test plan).
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D58537535
fbshipit-source-id: fddf44d45b214b52a950e33d67ac6612a50ddcba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44905
Replaces the last template CI job.
Changelog: [Internal] [Changed] Use Helloworld in GHA CI workflow.
Reviewed By: cortinico
Differential Revision: D58466813
fbshipit-source-id: 333b9a4c71eec6901c78f144db48f365539c6a5a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44936
# Changelog: [Internal]
Added a small test that uses `folly:ManualExecutor`, which reproduces the memory leak issue in Hermes' RemoteObjectsTable:
1. Send `Runtime.enable`
2. Evaluate `console.log(<object>);` to populate `RemoteObjectsTable`
3. Send `Page.reload` to reload VM
This test is expected to fail, because by the time it is published, the D58398254 hasn't landed.
Reviewed By: motiz88
Differential Revision: D58531763
fbshipit-source-id: 99af3bfce0a31fe905d5bf2bf433f62cfbc34897
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44887
The previous inexact object types and documentation for Share.share()'s arguments have led to confusion in how this library should be used. This diff updates the argument types to be more explicit, and rewrites some of the documentation for clarity.
Changelog:
[General][Breaking] Update `Share.share()`'s argument types to be more explicit.
Reviewed By: NickGerleman
Differential Revision: D58224906
fbshipit-source-id: 5ac8efe7caa0ecdd430fa7a1951c73c4acd8c6a1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44938
Yoga is transitively included in Swift targets and needs to be modular.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D58469454
fbshipit-source-id: 72bc6b5d3e5ee0710d9334a626e4e7297ce26b09
Summary:
Changelog: [ANDROID] [ADDED] - Add the ReactMarkerConstants.CONTENT_APPEARED support on Android in bridgeless mode.
This re-applies https://github.com/facebook/react-native/pull/43620 which was reverted because a CI job started failing because we forgot to update `packages/react-native/ReactAndroid/api/ReactAndroid.api`.
Reviewed By: cortinico
Differential Revision: D58535868
fbshipit-source-id: 9eec33c5e798850a7434a6c391abf2fc3fc9d0a6
Summary:
Changelog: [Internal]
Showing warnings in LogBox is noisy, confusing for web developers, and not the best use of screen real estate on mobile platforms. Since the Fusebox console offers a superior experience, as of this diff we'll suppress warnings in LogBox if we detect that Fusebox is available.
*The first time* a warning is suppressed, globally (i.e. at most once per app launch), we'll show a notification pointing the user towards Fusebox. When the notification is clicked, we call the `DevSettings.openDebugger` method and dismiss it.
The wording of the notification ("Open debugger to view warnings") is intentional:
1. It's short enough to fit on small screens in its entirety.
2. It doesn't actually say "*click here* to open the debugger". This is for the best because `DevSettings.openDebugger` is a best-effort method that might fail, and in the current implementation there's no reliable feedback to the user about the success/failure of the launch.
Reviewed By: huntie
Differential Revision: D57681446
fbshipit-source-id: fe6101785780de3bc586ade11f471f7c74707be1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44934
Resubmission of D57681447 with an updated `ReactAndroid.api`.
---
Changelog: [Internal]
Adds a private API that gives JS the ability to trigger the same "open debugger" action as in the Dev Menu. This is in preparation for changes to LogBox.
For simplicity, this method operates on a best-effort basis - i.e. it doesn't report the success or failure (or failure reason) of the launch.
Reviewed By: huntie
Differential Revision: D58529832
fbshipit-source-id: e5510f529a19e0149d8dce04fa610e6c2371cc79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44910
Props within the `Text` component are accessed both via destructuring the props object but also in some cases by using a "dot" access on the destructured `restProps`. However in all of the "dot" access cases the property is being overrided. Which means in the final JSX these properties get set twice, e.g. via the `restProps` spread then overrrided by static properties. This change just destructures all values to avoid this inefficiency.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D58446569
fbshipit-source-id: 12a800f5e2218a1d95d57cc689a4c79caab480b4
Summary:
This change removes the need for the trigger-react-native-release.js script.
Thanks to the migration to Github Actions, we can now leverage the GHA workflow UI to trigger a Prepare Release job that creates a github tag that will spin a new release.
The pro of this approach are:
- less code to maintain: instead of a complex trigger release scripts, we only have to maintain two very straightforward scripts for the CI
- easier to trigger a release: instead of running a script, we can now just use the GH UI
The `trigger-react-native-release` script was doing the following steps:
- check that we are in the release branch ==> Already implemented in the GHA workflow
- Gets the branch name (not needed) ==> the job will automatically run on the stable branch
- Check for unsent changes (not needed) ==> we are not in a local environment
- get the gh token (not needed) ==> You need to be logged in GH and have write access to the repo
- get the version ==> provided as a parameter
- fails if the tag is already there ==> Functionality added in the workflow
- Parse and validate the version ==> Functionality added to the action prepare-release action + the JS Script
- Compute the npmTag ==> Functionality added to the action prepare-release action + the JS Script
- trigger the release workflow ==> The GH UI does that for us
## Changelog:
[Internal] - Remove the trigger-react-native-release.js
Pull Request resolved: https://github.com/facebook/react-native/pull/44898
Test Plan: Testing in Production!
Reviewed By: cortinico, huntie
Differential Revision: D58461470
Pulled By: cipolleschi
fbshipit-source-id: 32bb0ee91370c9483a29e2ca2e18e24557d5fd53
Summary:
Add 0.72.15 to Changelog
## Changelog:
[Internal] [Changed] - Generated 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
Pull Request resolved: https://github.com/facebook/react-native/pull/44904
Reviewed By: cipolleschi
Differential Revision: D58470819
Pulled By: cortinico
fbshipit-source-id: 20a1816811213ed9a69f1ede3579aa8fc661faf2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44901
Point Gradle to the monorepo instead of a node_modules, as well as remove some commented out entries we're not interested in.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D58287786
fbshipit-source-id: 92b3d15d05c55a2589bb8a6b75dc3d5d0f9756ff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44647
Changelog: [Internal]
Adds a private API that gives JS the ability to trigger the same "open debugger" action as in the Dev Menu. This is in preparation for changes to LogBox.
For simplicity, this method operates on a best-effort basis - i.e. it doesn't report the success or failure (or failure reason) of the launch.
Reviewed By: hoxyq
Differential Revision: D57681447
fbshipit-source-id: ddb1fbd0f1c8d07bfa57d65c54e3a34bb7a470a8
Summary:
Add the `ReactMarkerConstants.CONTENT_APPEARED` support on Android in bridgeless mode. This is an important marker for TTI measurement.
## Changelog:
[ANDROID] [ADDED] - Add the `ReactMarkerConstants.CONTENT_APPEARED` support on Android in bridgeless mode.
Pull Request resolved: https://github.com/facebook/react-native/pull/43620
Test Plan:
adding this on RNTesterActivity to see if the log is executed
```kotlin
ReactMarker.addListener { name, tag, instanceKey ->
if (name == ReactMarkerConstants.CONTENT_APPEARED) {
Log.i("XXX", "XXX")
}
}
```
Reviewed By: cortinico
Differential Revision: D58459930
Pulled By: rubennorte
fbshipit-source-id: 4498a3623c506d228aea995c8aeafdb51fcc5b96
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44925
I have the suspect this is causing our builds to be slower and especially causing the template tests to take 6 hours.
Let's try to disable it.
Changelog:
[Internal] [Changed] - Do not publish Gradle Scans
Reviewed By: cipolleschi
Differential Revision: D58520463
fbshipit-source-id: 028e16a725ea87e178ed4e0bf134737f32780544
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44909
Today we wrap all `onPressIn` and `onPressOut` callbacks we pass to pressability so we can set the `highlighted` state. However highlighted state is only ever set to anything other that false on iOS. This change not only skips calling `setHighlighted(false)` on every press event but also skips wrapping the callback.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D58391419
fbshipit-source-id: e79f51469609a59063098501f015f8078e3db79f
Summary:
This PR solves [this issue](https://github.com/facebook/react-native/issues/44151).
Inverted FlatList doesn't work (elements cannot be clicked) when the list is scrolled.
## 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 clicking items on the inverted FlatList on the new architecture
Pull Request resolved: https://github.com/facebook/react-native/pull/44168
Test Plan:
# Steps
1. `buck2 install catalyst-ios` or `buck2 install catalyst-android`
2. Go to `RNTester Browser - Fabric` -> `FlatList` -> `Inverted`
3. Toggle inverted to `true`
4. Scroll to the top
5. Tap down and drag to either left or right
6. Expected is to have Red highlighted (which indicate Press Down) when dragged.
## iOS
| Before | After |
|-----------------------|----------------------|
| https://pxl.cl/53vCW | https://pxl.cl/53vDq |
## Android
| Before | After |
|-----------------------|----------------------|
| https://pxl.cl/53vFp | https://pxl.cl/53vFG |
## Reproducing steps from OSS
1. Use this reproducer: https://github.com/WoLewicki/reproducer-react-native/tree/%40wolewicki/flatlist-inverted
2. Apply changes from this PR & build the app.
3. Scroll a bit the list, so it changes the position.
4. The `onPress` should be fired when the button is clicked.
5. Do the following tests:
1. Add a `horizontal` prop to the FlatList - verify everything works.
2. Remove a `inverted` prop - verify everything works.
3. Remove a `inverted` prop and add a `horizontal` prop - verify everything works.
6. Test different combinations of transforms of the FlatList, example:
```javascript
<FlatList
inverted
horizontal
style={{
transform: [
{scaleY: -1},
{scaleY: -2},
{scaleY: -0.5},
{translateY: 20},
{translateY: -10},
{skewX: '10deg'},
{rotateX: '10deg'},
],
}}
/>
```
<details>
<summary>Reproducrer</summary>
https://github.com/facebook/react-native/assets/104823336/28cfe607-43e8-4f80-bbfb-59085ae0f986
</details>
<details>
<summary>RN tester</summary>
https://github.com/facebook/react-native/assets/104823336/e00cd488-d98f-4ece-9cab-b8a7212acb04
</details>
Reviewed By: arushikesarwani94
Differential Revision: D56441112
Pulled By: realsoelynn
fbshipit-source-id: 82c47f6bcc1f25cfbbd55aedf9652052bb86cf47
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44912
While moving from CircleCI → GHA, we're removing this blocking folks landing PRs and just running on main. We will re-enable once GHA is stable.
Changelog: [General][Changed] Disable GHA on PRs until it's stable
Reviewed By: NickGerleman
Differential Revision: D58478000
fbshipit-source-id: 053ee53455956bf19b6f9113cb796346359ad4ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44803
This change introduces a new prop to the Android `Image` component: `resizeMultiplier`. This prop can be used when the `resizeMethod` is set to `resize`, and it directly modifies the resultant bitmap generated in memory from Fresco to be larger (or smaller) depending on the multiplier. A default of 1.0 means the bitmap size is designed to fit the destination dimensions. A multiplier greater than 1.0 will set the `ResizeOptions` provided to Fresco to be larger that the destination dimensions, and the resulting bitmap will be scaled from the hardware size.
This new prop is most useful in cases where the destination dimensions are quite small and the source image is significantly larger. The `resize` resize method performs downsampling and significant image quality is lost between the source and destination image sizes, often resulting in a blurry image. By using a multiplier, the decoded image is slightly larger than the target size but smaller than the source image (if the source image is large enough).
It's important to note that Fresco still chooses the closest power of 2 and will not scale the image larger than its source dimensions. If the multiplier yields `ResizeOptions` greater than the source dimensions, no downsampling occurs.
Here's an example:
If you have a source image with dimensions 200x200 and destination dimensions of 24x24, a `resizeMultiplier` of `2.0` will tell Fresco to downsample the image to 48x48. Fresco picks the closest power of 2 (so, 50x50) and decodes the image into a bitmap of that size. Without the multiplier, the closest power of 2 would be 25x25, which is half the quality.
## Changelog
[Android][Added] - Adds a new `Image` prop `resizeMultiplier` to help increase quality of small images on low DPI devices
Reviewed By: javache
Differential Revision: D58120352
fbshipit-source-id: e0ebf4bd899170134825a29f72a68621447106c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44885
Cleanup accessibility related props checks to ensure we are doing the minimal amount of work. e.g. reduce duplicate `null` checks and shift checks to conditional branches that use them.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D58390430
fbshipit-source-id: f2c8989b6520cda9f14f9a04cd4fd6e126c501fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44877
Changelog: [Internal]
We're seeing a sporadic iOS crash that suggests `[RCTBridge dealloc]` is being called off the main queue (despite a comment suggesting it shouldn't be). This exposes a race condition between destroying the `HostTarget` and attempting to unregister the instance+runtime from it . Here we use `RCTExecuteOnMainQueue` to make sure the `HostTarget` destruction is always sequenced after the `unregisterFromInspector()` call.
Reviewed By: huntie
Differential Revision: D58415684
fbshipit-source-id: a22e239c80c3204fe32b9e73719ffaa131feaffb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44911
This diff reverts D58288489
D58288489: [RN][Fusebox][iOS] Implement new HostTargetMetadata fields (iOS) by huntie causes the following test failure:
Tests affected:
- [fbsource//xplat/js/react-native-github/packages/react-native/ReactCommon/jsinspector-modern:testsAndroid - main](https://www.internalfb.com/intern/test/844425054538351/)
Here's the Multisect link:
https://www.internalfb.com/multisect/5466028
Here are the tasks that are relevant to this breakage:
T191385299: 50+ tests unhealthy for react_native
The backout may land if someone accepts it.
If this diff has been generated in error, you can Commandeer and Abandon it.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D58475289
fbshipit-source-id: 3a4476d1350c4986cdb673bdb4ac52af353a00ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44495
## Summary
Migrates the `AlertFragment` from `android.app.AlertDialog` to `androidx.appcompat.app.AlertDialog`. This backports tons of fixes that have gone into the AlertDialog component over the years, including proper line wrapping of button text, dark mode support, alignment of buttons, etc.
This change provides a fallback to the original `android.app.AlertDialog` if the current activity is not an AppCompat descendant.
## For consideration
- Alert dialog themes may no longer need the `android` namespace, meaning themes can now be specified as `alertDialogTheme` rather than `android:alertDialogTheme`.
## Changelog:
[Android] [Changed] - Migrated `AlertFragment` dialog builder to use `androidx.appcompat`
Reviewed By: zeyap
Differential Revision: D57113950
fbshipit-source-id: ba5109c9d79b6ceb042ff93eebe796a2d14ebd63
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44494
Pull Request resolved: https://github.com/facebook/react-native/pull/44880
Migrates the `AlertFragment` from `android.app.AlertDialog` to `androidx.appcompat.app.AlertDialog`. This backports tons of fixes that have gone into the AlertDialog component over the years, including proper line wrapping of button text, alignment of buttons, etc.
## For consideration
- Alert dialog themes may no longer need the `android` namespace, meaning themes can now be specified as `alertDialogTheme` rather than `android:alertDialogTheme`.
- This change requires all implementing activities to have a theme that inherits from `Theme.AppCompat`. Creation of any activities which do not have a descendant of this style will result in an `IllegalStateException`: https://www.internalfb.com/intern/signalinfra/exception_owners/?mid=5ee93f6ecd59f3d8ad82a78c213ea016&result_id=16044073705339118.281475102518721.1715097866
## Changelog:
[Android] [Changed] - Migrated `AlertFragment` dialog builder to use `androidx.appcompat`
Reviewed By: zeyap
Differential Revision: D57019423
fbshipit-source-id: 84d8f69d896d32e72434149c0e31735d358370a9
Summary:
This change migrates the GHA template jobs to the HelloWorld package for iOS.
## Changelog:
[Internal] - Move iOS template jobs to HelloWorld
Pull Request resolved: https://github.com/facebook/react-native/pull/44875
Test Plan: GHA are green
Reviewed By: cortinico
Differential Revision: D58459398
Pulled By: cipolleschi
fbshipit-source-id: 95404445d7375186860af5835b750b4735795434
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44811
Changelog:
[General][Fixed] - Debugger frontend socket-termination countdown now begins after the ping message is actually sent
The debugger is currently disconnected if a ping-pong message is missed.
This causes the debugger to be unusable if it happens to be lagging, e.g. when the initialisation is competing with the flood of log spam T191394188
There are a few ways to fix this as discused with motiz88 and robhogan:
1. Ensure the websocket has a chance to respond, e.g. in via web worker
1. Lengthen the time allowed for the pong resopnse
I've done some digging to find the root cause of the UI being blocked in CDT, However, profiling shows that most of the work is not simple to break up, i.e. the number of expensive re-layout calls. Diving into that rabbit hole could mean accidentally writing React.
Because we ping every 10 seconds, we could get un/lucky where CDT happens to be busy _at that exact moment_, making this a flaky symptom to fix, even if we lengthen the allowed time-to-respond.
# V2+
So upon further investigation, CDT websocket is actually responding to the pings in due time:
{F1679132204}
(CDT doesn't show the ping/pong API as frames, so a custom tick/tock message was used to visualise the timing)
Over here in dev-middleware, we currently start a timeout to terminate the socket after sending the ping:
https://www.internalfb.com/code/fbsource/[813870db697a8701f2512d25a7fed730f0ec6ed9]/xplat/js/react-native-github/packages/dev-middleware/src/inspector-proxy/InspectorProxy.js?lines=306-307
If CDT doesn't respond in time, websocket would be terminated.
But we saw CDT respond immediately above, even during the log spam, so the delay must be coming from somewhere else.
The intuition is that during the log-spam, the middleware takes a perf hit too when it's processing the spam from the device and forwarding it to the CDT websocket.
We can confirm this by passing a "sent" callback via `socket.ping(cb)`:
https://github.com/websockets/ws/blob/9bdb58070d64c33a9beeac7c732aac0f4e7e18b7/lib/websocket.js#L246-L254
This gives us the timing between calling `socket.ping()` and when the ping is actually sent.
Regular, stress-free operation without log-spam shows most pings are sent within the same millisecond:
{F1679223326}
With the pong response grace period at 5 seconds, there's plenty of time for CDT to `pong` back. That's why it has been working in most cases.
However, during the log-spam, we easily see this send-sent delay over 5 seconds. In extreme cases, almost 30 seconds would have passed before middleware sent a message to CDT, which then responded under 2 seconds:
{F1679163335}
This means while CDT is getting flooded and has observable lag in the UI, the smoking gun is actually the middleware.
Digging a little deeper, we know that incoming messages from the target goes into a Promise queue, including the console logs:
https://www.internalfb.com/code/fbsource/[d5d312082e9c]/xplat/js/react-native-github/packages/dev-middleware/src/inspector-proxy/Device.js?lines=155-157
This means during the flood of logs from the target, the Promise queue keeps getting chained rapidly for each message.
Meanhile, the `ws` lib uses the underlying NodeJS `Socket.write` method for `ping(…)` and `send(…)`:
https://github.com/websockets/ws/blob/9bdb58070d64c33a9beeac7c732aac0f4e7e18b7/lib/sender.js#L349
…which is guaranteed to fire the callback asynchronously:
https://github.com/nodejs/help/issues/1504#issuecomment-422879594
Promise queue is in the macro task queue, which gets priority before the micro task queue. So if the Promise queue is not cleared yet, the websocket queue will have a hard time getting executed in time – explaining the extreme send-sent durations during a log spam.
The fix is simple:
1. Start the terminate-socket-timer until the `ping` is actually sent
1. Treat any incoming message (along with `pong`s) as a terminate-socket-timer reset
1. This also applies if `pong` comes in between `send` and `sent`, which can happen sometimes due to the async nature of the callback:
{F1679288626}
# V1
~~In this diff, a more forgiving mechanism is introduced, i.e. CDT is allowed to miss a ping-pong roundtrip 3 times before the websocket connection is terminated.~~
~~This allows a bit more breathing room for CDT's initialisation during log spam while maintaining the same ping-pong interval for VS Code to keep the auto SSH tunnel alive.~~
Reviewed By: huntie
Differential Revision: D58220230
fbshipit-source-id: 7111c9878492d8755a6110a5cdf4ef622265001d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44894
Adds the new CDP domain `ReactNativeApplication`, with the following messages:
- `ReactNativeApplication.enable` (method) — Sent by the connected frontend to enable features under this domain.
- `ReactNativeApplication.metadataUpdated` (event) — Sent by the backend containing a metadata object about the host.
We intend to use this for displaying richer information in the debugger frontend, such as device information and React Native version.
Changelog:
[General][Added] - Add `ReactNativeApplication.[enable,metadataUpdated]` CDP messages for reading host metadata
Reviewed By: motiz88
Differential Revision: D58288490
fbshipit-source-id: 02384f0cdfaa35f1c5de9fad7ddd5aab483b2768
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44878
A refactor moving `SessionMetadata` (now renamed as `HostTargetMetadata`) out of `inspectorTarget->connect()` calls into a `HostTargetDelegate::getMetadata` method. This provides a cleaner interface and location for extending metadata fields in future.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D58288491
fbshipit-source-id: 67e8b9a3fb6d0b7966187fa98d9852222f242b9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44897
changelog: [internal]
To get better understanding of where the time is spent, let's split IntBufferBatchMountItem systrace section into individual types.
Reviewed By: javache
Differential Revision: D58080444
fbshipit-source-id: d71dcc74a042c6c40270ca6f1dc7a8735c0471b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44895
Enables the new debugger stack (codename Fusebox) in RNTester.
This feature is experimental and is enabled for testing purposes only. This change **should not** be adopted as the default by React Native frameworks.
Changelog: [Internal]
Reviewed By: cortinico, rubennorte, NickGerleman
Differential Revision: D58366246
fbshipit-source-id: 809a1edb79ced4a7920457ed661cc3d863b35c7b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44879
This sets up publishing of Gradle scans for every build on GHA.
Changelog:
[Internal] [Changed] - Setup publishing of Gradle Scans on GHA
Reviewed By: blakef
Differential Revision: D58419361
fbshipit-source-id: f54365ad259324747248ef0bb726dc64964507f8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44810
Adds an example how to use the `EventEmitter` on a (C++) Turbo Module
## Changelog:
[General] [Added] - Add C++ Turbo Module Event Emitter example
Reviewed By: javache
Differential Revision: D57473949
fbshipit-source-id: 1a8d17fb83af4220ef12379e0102b5b2e233ed45
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44864
Switch the style normalizer checks to only do a single top level `null` check and remove unneeded flow suppression comments.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D58386781
fbshipit-source-id: e4df6fdadb5bfab4c8ae674a420ac453ba262f78
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44822
Changelog: [Breaking]
This is to make `getContentOriginOffset` to have `includeTransform` information passed during Layout computation.
Reviewed By: NickGerleman
Differential Revision: D58223380
fbshipit-source-id: 4faa1409d9c87e2c92118941aa193ba0a0f34367
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44809
Adding react-native-codegen parser support for a new `EventEmitter` property type on C++ Turbo Modules.
It is possible to later expand this feature to other languages (Java, ObjC).
## Characteristics
An `EventEmitter` must:
- be non null:
`EventEmitter<string>` works, `?EventEmitter<string>` does NOT
- have a non null eventType:
`EventEmitter<number>` works, `EventEmitter<?number>` does NOT
- have at most 1 eventType, `void` is possible as well:
`EventEmitter<>` or `EventEmitter<MyObject>` work - `EventEmitter<number, string>` do NOT
- have a concrete eventType, `{}` is not allowed
`EventEmitter<{}>` does NOT work
- be used in `Cxx` Turbo Modules only at this time
## Example
For these 4 eventEmitters in on an RN JS TM spec
```
+onPress: EventEmitter<void>;
+onClick: EventEmitter<string>;
+onChange: EventEmitter<ObjectStruct>;
+onSubmit: EventEmitter<ObjectStruct[]>;
```
We now generate this code:
1.) in the spec based header `{MyModuleName}CxxSpec` in the constructor:
```
... // existing code
eventEmitterMap_["onPress"] = std::make_shared<AsyncEventEmitter<>>();
eventEmitterMap_["onClick"] = std::make_shared<AsyncEventEmitter<OnClickType>>();
eventEmitterMap_["onChange"] = std::make_shared<AsyncEventEmitter<OnChangeType>>();
eventEmitterMap_["onSubmit"] = std::make_shared<AsyncEventEmitter<OnSubmitType>>();
```
2.) as `protected` functions
```
void emitOnPress() {
std::static_pointer_cast<AsyncEventEmitter<>>(delegate_.eventEmitterMap_["onPress"])->emit();
}
void emitOnClick(const OnClickType& value) {
std::static_pointer_cast<AsyncEventEmitter<OnClickType>>(delegate_.eventEmitterMap_["onClick"])->emit(value);
}
void emitOnChange(const OnChangeType& value) {
std::static_pointer_cast<AsyncEventEmitter<OnChangeType>>(delegate_.eventEmitterMap_["onChange"])->emit(value);
}
void emitOnSubmit(const OnSubmitType& value) {
std::static_pointer_cast<AsyncEventEmitter<OnSubmitType>>(delegate_.eventEmitterMap_["onSubmit"])->emit(value);
}
```
## Changelog:
[General] [Added] - Add EventEmitter code-gen support for C++ Turbo Modules
Reviewed By: javache
Differential Revision: D57407871
fbshipit-source-id: 2345cc6dacf0cb0d45f8a374ad9d4cbf8082f9d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44734
Fixes https://github.com/facebook/react-native/issues/44671
This integrates functionality for clipping content to padding box into `ReactViewBackgroundManager`, to be shared between several ViewManagers. In practice, this means:
1. `overflow: hidden` now works on `Text` and `TextInput`
2. ScrollView children are now clipped to the interior of borders, included curved ones via borderRadius
This will be made more generic, then start being used in ReactViewGroup, and eventually ReactImage. That abstraction will then hide away extra background management we will use for shadows.
Different places in code currently do clipping in any of `draw()`, `onDraw()`, or `dispatchDraw()`. The distinction between these, is that `draw()` allows code to run before drawing background even, `onDraw()` is invoked before drawing foreground, and `dispatchDraw()` is before drawing children. We don't want to clip out borders/shadows, but do want to clip foreground content like text, so I used `onDraw()` here.
Changelog:
[Android][Fixed] - Better overflow support for ScrollView, Text, TextInput
Reviewed By: rozele
Differential Revision: D57953429
fbshipit-source-id: ca3b788deb4b32706df7db958877d18f525c039c
Summary:
Before all React errors showed junk like this:

This is because `isComponentStack` detected a component stack but `parseComponentStack` couldn't actually parse it (it doesn't deal with React's current format like `in Foo (created by FeedItemInner)`) so `componentStack` was an empty array, resulting in the next block of code pushing stuff into `argsWithoutComponentStack` _again_, thus repeating its args.
The fix is not to do that. Result on my local copy:

Ofc this doesn't actually show the component stack but that was broken before too.
I edited in-place in my `node_modules` so I haven't verified this 100% works on main.
Hope this is useful!
## Changelog:
[General] [Fixed] - Remove accidental duplication in React warnings in Logbox
Pull Request resolved: https://github.com/facebook/react-native/pull/44812
Reviewed By: cortinico
Differential Revision: D58240357
Pulled By: rickhanlonii
fbshipit-source-id: b6ecb659d3b393e497caf5e7b2087a8e529f1b28
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44808
Adds an `AsyncEventEmitter` class which can be used as a property of currently C++ only Turbo Modules to send type safe data back to JavaScript.
Adding support for ObjC / Java Turbo Modules is possible, straight forward and can be added as an afterthought.
It implements this interface
```
export type EventEmitter<T> = {
addListener(handler: (T) => mixed): EventSubscription,
};
```
## Hybrid
It is a 'hybrid' object.
1.) You `addListener(handler: (T) => mixed)` in JavaScript for emitted events (coming from C++, native code)
2.) You `emit(...Arg)` events in C++, native code (getting sent to JavaScript)
## Changelog:
[General] [Added] - Add EventEmitter C++ bridging type
## Facebook:
Apps usually create custom functionality to achieve this kind of behavior - e.g. https://www.internalfb.com/code/fbsource/[e72bd42a028a]/arvr/js/apps/RemoteDesktopCompanion/shared/turbo_modules/TMSubscription.h
Reviewed By: javache
Differential Revision: D57424391
fbshipit-source-id: 4999cafe9daeac125712a4bb7679d7acb9a6c389
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44841
This change adds native support in Fabric for the remaining CSS cursor style values as defined here: https://developer.mozilla.org/en-US/docs/Web/CSS/cursor. Please note, this functionality is simply for prop parsing capabilities in Fabric, which are shared across all platforms. This does not add any additional cursor behavior support to iOS or Android, and the Flow and TypeScript types for cursor style values are still limited to `auto` and `pointer`.
## Changelog
[General][Added] Fabric prop parsing capabilities for all CSS cursor style values
Reviewed By: NickGerleman
Differential Revision: D58301970
fbshipit-source-id: 37ef8fcb4f62ac8c7613c7f6abcc48303953b71b
Summary:
Sometimes the events map can be a of type `SingletonMap` which will cause this code to throw exception when adding keys to it, so we change it to normal `HashMap`. Creating `SingletonMap` can especially happen in Kotlin when there is only one event added to a map, see:
https://github.com/plaid/react-native-plaid-link-sdk/blob/5ffab5eef576163528f0da504181162da3bef08b/android/src/main/java/com/plaid/PLKEmbeddedViewManager.kt#L21
## Changelog:
[ANDROID] [FIXED] - Cover SingletonMap when parsing events exported by module
Pull Request resolved: https://github.com/facebook/react-native/pull/42354
Test Plan: Create `getExportedCustomBubblingEventTypeConstants` as `SingletonMap` in some example module and see that the code does not throw.
Reviewed By: cipolleschi
Differential Revision: D58417266
Pulled By: cortinico
fbshipit-source-id: 6c46398ddf4d044386a36d0c1663bd071d642fb6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44874
While reviewing https://github.com/facebook/react/pull/29830, I noticed this file was committed with tab indentation in React Native. I have also used the `.gitignore` entry to clarify how `react-native.code-workspace` interacts with an optional user `.vscode/` config directory.
Note: The `json-stringify` parser can be used with Prettier 3+ only, so we use `json` instead.
Changelog: [Internal]
Reviewed By: vzaidman
Differential Revision: D58413581
fbshipit-source-id: 58c14db6648fed10736062b1f055475154aa74a4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44835
As titled. The `vm` field is not part of the CDP spec and will not be used by the modern debugger frontend or proxy.
This change affects modern CDP targets only (using `InspectorPackagerConnection`). We aim to enable sharing of more detailed metadata over 1/ a new, dedicated CDP domain, and 2/ namespaced under the existing `reactNative` field (for the latter, strictly limited to metadata necessary for dev server functionality).
Changelog: [Internal]
(Note: `/json` endpoint behaviour is unchanged for legacy CDP targets)
Reviewed By: robhogan
Differential Revision: D58285587
fbshipit-source-id: dfef3a56b20486ba11891df9940f6c7bef59528e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44858
- Enables an opt-in to the Fusebox stack on Android for both architectures in open source.
- Templates use of this opt-in in RNTester.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D58359907
fbshipit-source-id: d565dc8e00747dff56d3060e36e7f59e7dd2aec5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44871
This re-enables and fix `test_android_template`.
The problem was that we were invoking `yarn install` inside the template after we already installed with `npm install --registry`.
So this was invalidating the Verdaccio setup and effectively fetching packages from NPM
Changelog:
[Internal] [Changed] - Fix test_android_template
Reviewed By: cipolleschi
Differential Revision: D58407941
fbshipit-source-id: 9b7b877cfc994eb8db1b5bf71dd35289c3937f5c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44860
- Enables an opt-in to the Fusebox stack on iOS for both architectures in open source.
- Templates use of this opt-in in RNTester.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D58364053
fbshipit-source-id: c604b1589174bf7cfd0fe1bfb5624c4edd0a125d
Summary:
Seems like hermesc produced by GitHub Actions is not executable. This fixes it.
Changelog:
[Internal] [Changed] - Make hermesc executable
Reviewed By: cipolleschi
Differential Revision: D58407086
fbshipit-source-id: 84d7ba950b99214dfaed09a6aa499835fd01ede0
Summary:
Just doing some cleanup of the `.github/workflows` folder:
* apply-version-label-issue.yml hasn't been working since 0.72
* ios-tests is unnecessary as it's now covered by test-all
* nightlies-feedback.yml was experimental and last execution was ~5 months ago.
We can still recover them from the Git history if necessary.
## Changelog:
[INTERNAL] - Cleanup the .github/workflows folder
Pull Request resolved: https://github.com/facebook/react-native/pull/44857
Test Plan: Will wait for CI result
Reviewed By: NickGerleman
Differential Revision: D58362912
Pulled By: cortinico
fbshipit-source-id: d886e4f077eebfdf906169f09f96a950a361cab7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44865
This has not yet passed on main since we started testing on main two weeks ago: https://github.com/facebook/react-native/actions/runs/9316380994/job/25688028045
This change disables the GitHub Actions version `test_android_template` as a signal for PRs or diffs, since it isn't stable yet (but we still run it on main, and can manually dispatch it on any branch). This coverage is still enabled in CircleCI.
Changelog: [Internal]
Reviewed By: cortinico, alanleedev
Differential Revision: D58394745
fbshipit-source-id: 3227328b150a89b450d48784190f5d08d510cd1b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44821
Changelog: [Internal]
- Originally D37994809 was attempted to fix `Inverted FlatList` but was put behind Feature Toggle because it was causing problems in other scenarios.
- Later, D45866231 which was trying to fix scaling transform issue helped solve the issue attempted by the original diff.
- But after that points, Unit test around `computeRelativeLayoutMetrics` was having two variants where Feature Toggle for D37994809 was checked in with a wrong expected value.
- This diff revert D37994809 changes and clean up the unit test.
Reviewed By: NickGerleman
Differential Revision: D58197918
fbshipit-source-id: d8ae552018617e785e4010bc5805c53a875e02a3
Summary:
## Changelog
make RNTesterApp take a `customBackButton` prop to enable overriding whether to display back button and the look
by default, only ios platform has a back button, and android app relies on back button on navigation bar that comes with platform
[Internal]
Reviewed By: christophpurrer
Differential Revision: D58218208
fbshipit-source-id: 63a47390cc6d3de057b92a3c522c1b00d942c69d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44792
X-link: https://github.com/facebook/yoga/pull/1663
Fixing https://github.com/facebook/yoga/issues/1658. We had a problem where if a child had a different flex direction than its parent, and it also set a position as a percent, it would look at the wrong axis to evaluate the percent. What was happening was we were passing in the container's mainAxis size and crossAxis size to use to evaluate the position size if it was a percent. However, we matched these sizes with the main/cross axis of the child - which is wrong if the flex direction is different.
I changed it so that the function just takes in ownerWidth and ownerHeight then calls isRow to determine which one to use for the main/cross axis position. This reduces the ambiguity quite a bit imo.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D58172416
fbshipit-source-id: eafd8069e03493fc56c41a76879d1ad9b7e9236d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44791
X-link: https://github.com/facebook/yoga/pull/1662
This should fix https://github.com/facebook/yoga/issues/1657. Rather insidious bug but we had code like
```
// The total padding/border for a given axis does not depend on the direction
// so hardcoding LTR here to avoid piping direction to this function
return node->style().computeInlineStartPaddingAndBorder(
axis, Direction::LTR, widthSize) +
node->style().computeInlineEndPaddingAndBorder(
axis, Direction::LTR, widthSize);
```
That comment is NOT true if someone sets both the physical edge and relative edge. So like paddingLeft and paddingEnd for RTL. This diff simply pipes the direction to that spot to use instead of hardcoding LTR. Every file changed is just to pipe `direction`.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D58169843
fbshipit-source-id: 5b4854dddc019285076bd06955557edf73ef7ec5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44852
This attempts to fix#44842 by capturing the accessed field in a new variable.
We don't have a way to reproduce this & this is a best guess fix.
Changelog:
[Android] [Fixed] - Tentative fix for NPE `JavaTimerManager$IdleCallbackRunnable.cancel`
Reviewed By: javache
Differential Revision: D58356826
fbshipit-source-id: d016df9a52f81a8d645a0a100c6bc6111841e24e
Summary:
This change migrates the prepare_release workflow from CCI to GHA
## Changelog:
[Internal] - Migrate from CCI to GHA
Pull Request resolved: https://github.com/facebook/react-native/pull/44833
Test Plan: Test on GHA
Reviewed By: huntie
Differential Revision: D58289050
Pulled By: cipolleschi
fbshipit-source-id: 134fc7ffb66a18eec1187e14500daec2828cae61
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44851
This method is available on the (deprecated) CatalystInstance interface, but not on ReactContext, even though it is trivially supported.
Changelog: [Android][Added] - Added getNativeModule(name) to ReactContext
Reviewed By: cortinico
Differential Revision: D58355135
fbshipit-source-id: 0cc76bb2da2b49510dc626cb8b3a3e93db5a16b0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44823
Changelog: [internal]
This modifies the example for `IntersectionObserver` in RNTester to test that the API reports changes in intersection also coming from changes in layout (previously is was only from changes in scroll position).
Reviewed By: javache
Differential Revision: D58260057
fbshipit-source-id: 305d5996148730d718da30896f6cc62991b717f7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44805
Google has discouraged attempting to read the `status_bar_height` resource [since 2017](https://youtu.be/_mGDMVRO3iE?si=qGQd7gLa_qTmfLGL&t=1079). With the introduction of display cutouts there can be a mismatch between the resource value and the true status bar size (and issues like [this one](https://github.com/facebook/react-native/issues/33612) popped up). The recommended approach is to instead call `getInsets` with the proper status bar and navigation flags provided by `WindowInsets`. On older APIs where `getInsets` is not supported, we have access to `systemWindowInsetTop`.
Changelog:
[Android][Fixed] - Fixed StatusBar.currentHeight calculations to honor all cutout sizes
Reviewed By: tdn120
Differential Revision: D58088036
fbshipit-source-id: 9c035a79cbb96db1cf3b5b5c36242df7453fe205
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44854
In the previous change, I followed the suggestion of the linter but in that case I shouldn't.
This was breaking circleci and GHA
This change will fix it
## Changelog:
[Internal] - Fix OSS CI
Reviewed By: huntie
Differential Revision: D58358164
fbshipit-source-id: eba1f41c17a191aa9d3bd213fddddd8ff3c24a6a
Summary:
As discussed with cipolleschi offline, this PR adds visionOS to the prebuilt Hermes binary for the CI.
## Changelog:
[IOS] [ADDED] - Prebuilt version of Hermes for visionOS
Pull Request resolved: https://github.com/facebook/react-native/pull/44691
Test Plan: Check if CI builds xcframework for visionOS.
Reviewed By: cortinico
Differential Revision: D58189271
Pulled By: cipolleschi
fbshipit-source-id: dc76746b2c1e22670bef4c21411a598e43dad577
Summary:
I've noticed that nightly CI build was also running on my fork. I don't think this is necessary for every React Native fork (there are 24k of forks). This can save lots of unnecessary CI time.
## Changelog:
[INTERNAL] [FIXED] - Enable nightly run only on the main repo
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/44844
Test Plan: CI Green
Reviewed By: cipolleschi
Differential Revision: D58356192
Pulled By: cortinico
fbshipit-source-id: 1384d06708220d297e67d31433fcf3ac1d58bbbc
Summary:
While migrating from CCI to GHA, we mistakenly set the `ORG_GRADLE_PROJECT_reactNativeArchitectures` wrongly. The result was that the nightly was building only 1 architecture for android instead of all of them.
This change fixes that, but asking GHA to build all the architectures when running nightlies
bypass-github-export-checks
## Changelog:
[Internal] - Build all the architectures for android when running nightlies
Pull Request resolved: https://github.com/facebook/react-native/pull/44847
Test Plan: Run a nightly from the branch and see it working
Reviewed By: huntie
Differential Revision: D58347697
Pulled By: cipolleschi
fbshipit-source-id: 43a2b83ba9183e6f5a11d1e6f6a27df622ee8cc6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44850
I'm removing this line from settings.gradle:
```
import com.facebook.react.ReactSettingsExtension
```
and just using a fully qualified class name in the `configure{}` block
as imports cannot be conditionally included and is making hard for RNTA
to integrated those changes.
Changelog:
[Internal] [Changed] - Remove import of `com.facebook.react.ReactSettingsExtension`
Reviewed By: huntie
Differential Revision: D58354443
fbshipit-source-id: bc45516661318021a042e1c5921e28d7217cacbc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44829
Another renaming that now we can merge to make clear what's the intent of this header.
Changelog:
[Internal] [Changed] - rncli.h -> autolinking.h
Reviewed By: javache
Differential Revision: D58284662
fbshipit-source-id: 7b69118f72d9b34a88ece7e0855918f5c717999a
Summary:
While writing some Jest tests, I noticed some instances of the following error:
```
Cannot read properties of undefined (reading 'remove')
```
Looks like there were two cases where the `{remove: () => {}}` return result was missing in the provided Jest mocks:
- `AccessibilityInfo.addEventListener`
- `Linking.addEventListener`
## Changelog:
[GENERAL] [FIXED] - Added missing `remove` methods for `Linking.addEventListener` and `AccessibilityInfo.addEventListener` Jest mocks
Pull Request resolved: https://github.com/facebook/react-native/pull/44270
Test Plan: N/A
Reviewed By: christophpurrer
Differential Revision: D58324784
Pulled By: robhogan
fbshipit-source-id: f46bd55db2517413f14182ae1bb81068d8d1e9f6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44828
I was using PackageList2 temporarily as I was migrating to Core Autolinking.
Now we can rename everything to `PackageList` to reduce the number of changes to the template for users.
Changelog:
[Internal] [Changed] - PackageList2 -> PackageList
Reviewed By: blakef
Differential Revision: D58284661
fbshipit-source-id: 8e1cc54e248519ece05336d79bb79e3f4ca706f4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44799
This is the final part of core autolinking:
1. I split RNGP into an `app-plugin` and a `settings-plugin`. This was necessary as the Gradle modules need to be loaded inside the settings.gradle.kts.
2. I've introduced a Settings Plugin to take care of either invoking the `config` command from CLI or receiving a file in input.
3. I've removed the former `RunAutolinkingConfigTask` as now the command is invoked inside the settings plugin
4. I've added hashing computed based on the lockfiles so we won't be re-executing teh `config` command if the lockfiles are not changed.
5. I've updated RN-Tester to use the core autolinking rather than manual linking for the 2 libraries it's using.
Changelog:linking
[Internal] [Changed] - RNGP - Autolinking. Add support for linking projects
Reviewed By: blakef
Differential Revision: D58190363
fbshipit-source-id: 6ab8b36729e77ca715f50a4a00aa0ca4eb5b63b1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44818
Introduce a new data source for Perfetto. This one turns on the Hermes sampler, and at the end we flush the state to Perfetto.
This provides JS sampling data in Perfetto traces that can be used to easily spot JS performance problems not otherwise obvious.
Reviewed By: javache
Differential Revision: D57226087
fbshipit-source-id: 77c4a335bb462e73d74345eedc3fa634405bfd0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44827
After D57856389 (#44684), the build is now firing an issue as `libmapbufferjni.so` is exposed as a public `.so` and we're missing a pickFirst directive.
Changelog:
[Internal] [Changed] - Add libmapbufferjni.so to pickFirst directives
Reviewed By: javache
Differential Revision: D58284481
fbshipit-source-id: d476bd5df8ec4687177df7a698cbb6595ce62565
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44831
The build_npm_package jobs remains sometimes in queue because there are not enough executors for it to run.
This makes our signals less reliable.
Plus, it is rebuilding part of Android, so it can benefit from a bigger machine
## Changelog:
[Internal] - Bump build_npm_package machine to more powerful ones
Reviewed By: cortinico
Differential Revision: D58284884
fbshipit-source-id: a29b7db843633ff3cfd9373cf4dbe55b24c939b1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44830
Now that we have nightlies in GHA, we can safely remove them from CCI.
## Changelog:
[Internal] - Remove Nightlies from CCI
## Facebook:
Once this land, we need to disable the trigger in the CCI setting page.
Reviewed By: cortinico
Differential Revision: D58284941
fbshipit-source-id: 9a6ceb416de1d54f59f784a61509cd93f5684aaf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44826
This was rolled out a while back, but some references remained.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D58190612
fbshipit-source-id: e7884909959c98eb5617c9dee75f4ce53834b05c
Summary:
In order to host a ReactNative surface whose size is controlled by the RN content rather than the size of the surface, we need the ability to remove the flex:1 style on the root View component.
`SurfaceHandler` has layout functions which take a `LayoutConstraint` (so min/max size). The root View component in `AppContainer` has a hardcoded `flex:1` style. This view is above the `WrapperComponent`, which we can currently override. But I dont see anyway to avoid the root View having that flex style. This flex style means that the rootview will always be the maxheight passed into the layout functions on `SurfaceHandler`. Which prevents allowing RN surfaces that can size themselves based on their content.
This change adds a `setRootViewStyleProvider` method to `AppRegistry`, which works similar to `setWrapperComponentProvider` but allows apps to override the style property on the root View component. In particular, this allows apps to remove the flex:1 style, which is required to enable react surfaces which are sized based on their contents.
## Changelog:
Pick one each for the category and type tags:
[GENERAL] [ADDED] - Added AppRegistry.setRootViewStyleProvider
Pull Request resolved: https://github.com/facebook/react-native/pull/44665
Test Plan: Will be including this change into react-native-windows to enable scenarios with content sized surfaces within Microsoft Office to work with the new architecture. Would like signoff on this direction before I go and integrate it there.
Reviewed By: javache
Differential Revision: D58138443
Pulled By: hoxyq
fbshipit-source-id: 95ab4842aa7f827867788d8787527f9675cf4fcc
Summary:
This change adds a separate workflow for Nightlies. This workflow do not run tests on iOS and Android and proceed to release a nightly.
**🚨 Important 🚨** We need to update the GHA secrets as there is none set.
_Note: This is a first step to ensure that we can release Nightlies from GHA. I'll factor out all the actions in following updates to cleanup and refactor once we know that everything works!_
## Changelog:
[INTERNAL] - Add nightlies workflow on GHA
Pull Request resolved: https://github.com/facebook/react-native/pull/44741
Test Plan:
1. Add the `pull_request` trigger to see the workflow start
2. Monitored the workflow to make sure that it worked
3. Tested the nightly locally
4. Removed the `pull_request` trigger, otherwise we would publish a nightly on each PR! xD
Reviewed By: cortinico
Differential Revision: D58084002
Pulled By: cipolleschi
fbshipit-source-id: 593145392fe686930ccb00beb68d9130b8401cbc
Summary:
Hi, I'm Filip from software mansion. This PR solves a problem I stumbled upon.
On iOS, applications are always in light mode on initial load. Even if the device is turned to dark mode.
### Cause of the problem:
The initial appearance is taken from `RCTKeyWindow()`, but at the time of initialization of `RCTAppearance` it does not exist yet.
### Solution:
This PR moves repeats initialization of the appearance the first time `getColorScheme()` is called if it was not initialized properly before.
## Changelog:
[IOS] [FIXED] - Fix dark mode on initial load.
Pull Request resolved: https://github.com/facebook/react-native/pull/44335
Test Plan:
- Create new React native app with `npx react-native@latest init AwesomeProjec`
- Run the application on iphone using simulator
- turn on dark mode using `cmd+shift+A`
- close application and run it again
### without changes:
The application will turn on in light mode despite the simulator being set to dark mode.
When you reload the application it works as expected (is in dark mode)
### with changes:
Works as expected
#### note:
any change to device ui settings will trigger a listener that will set appearance to correct state, so testing of this problem should happen in as isolated conditions as possible.
Reviewed By: cortinico
Differential Revision: D58189058
Pulled By: cipolleschi
fbshipit-source-id: 9a864f3d045e966bc88601f661d221c4796c5c95
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44815
Remove our `test_ios_template` job for `test_ios_helloworld`.
NOTE: There needs to be a followup to do the same in our Github Actions.
Changelog: [General][Changed] use helloworld instead of template for CI tests.
Reviewed By: cipolleschi
Differential Revision: D57122797
fbshipit-source-id: 744c79230b716716fdfc234832f1eb241e091893
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44797
Noticed when profiling bridgeless that that every call into JS would be passed via a (default priority) background thread first. This is inefficient from a scheduling perspective. Instead use the Task's default/immediate executor to immediately execute the success callback on the current thread and avoid a thread change.
This diff adds a new feature flag, to use the immediate executor for any ReactInstance method that doesn't require further synchronization within ReactInstance. For most methods, this is indeed unnecessary as ReactInstance will synchronize internally by scheduling work on the JS thread.
Changelog: [Android][Added] Added featureflag to avoid additional background threads during execution
Reviewed By: cortinico
Differential Revision: D58186090
fbshipit-source-id: 67ffed2d34083a6b6e7871160a2f3d6f1967d630
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44767
Changelog: [Internal]
Fixes a lifecycle bug in both the Bridge (`com.facebook.react.bridge`) and Bridgeless (`com.facebook.react.runtime`) integrations of Fusebox in React Native Android, whereby `HostTarget::unregisterInstance` gets called after the `HostTarget` has been destroyed.
The solution consists of two parts:
1. If a ReactHost / InstanceManager is asked to destroy itself while it contains no active ReactInstance / ReactContext, we destroy the `HostTarget` immediately.
2. Otherwise, if there *is* a live ReactInstance / ReactContext that has yet to be destroyed, we wait for that to happen before destroying the `HostTarget`. In practice, we do this by checking for the BEFORE_CREATE ( = Host destroyed) lifecycle state every time we destroy a ReactInstance / ReactContext.
Reviewed By: javache
Differential Revision: D58031215
fbshipit-source-id: 321c73e85afd17a1b38c63f73aee5ebb59c00686
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44722
Add support for bundling, building and uploading on iOS. I've verified these locally and will enable on CircleCI to validate.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D57915365
fbshipit-source-id: 1e73918b31f70d337de4d3aee934c8acf88c86d0
Summary:
This PR adds cocoapods utility to set `SWIFT_ACTIVE_COMPILATION_CONDITIONS` to DEBUG, which is set to this value by default (when generating a new native Xcode project).
This allows to use the `#if DEBUG` compilator directive in Swift to work out of the box, without any changes on user's side:
```swift
override func bundleURL() -> URL? {
#if DEBUG
RCTBundleURLProvider.sharedSettings().jsBundleURL(forBundleRoot: "index")
#else
Bundle.main.url(forResource: "main", withExtension: "jsbundle")
#endif
}
```
## Changelog:
[IOS] [ADDED] - Set SWIFT_ACTIVE_COMPILATION_CONDITIONS to DEBUG
Pull Request resolved: https://github.com/facebook/react-native/pull/42330
Test Plan:
Run `bundle exec pod install` and check if the active compilation flags are populated:

Reviewed By: cortinico
Differential Revision: D58188103
Pulled By: cipolleschi
fbshipit-source-id: 64746f3c7bfbdf47c2dea5e5e8cb2962635b719b
Summary:
The new `customizeRootView` does not have the feature parity as `createRootViewWithBridge` where reusing RCTRootViewFactory to create a root view, it does not call `customizeRootView`. This PR moves the `customizeRootView` support from RCTAppDelegate into RCTRootViewFactory and improves the customizeRootView support.
## Changelog:
[IOS] [CHANGED] - Support `customizeRootView` from `RCTRootViewFactory`
Pull Request resolved: https://github.com/facebook/react-native/pull/44775
Test Plan:
Add customizeRootView to **packages/rn-tester/RNTester/AppDelegate.mm** and test whether RNTester has blue background color in both new arch and old arch mode.
```objc
- (void)customizeRootView:(RCTRootView *)rootView
{
rootView.backgroundColor = [UIColor blueColor];
}
```
Reviewed By: dmytrorykun
Differential Revision: D58179693
Pulled By: cipolleschi
fbshipit-source-id: 0fac9a1bd5b2583a2700b3a3d2c80d0f608c4481
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44721
For iOS builds of `react-native`, the [react-native-xcode.sh](https://www.internalfb.com/code/fbsource/[7ad79aae3e8bf565d53f087ac7f7b7622b19acec]/xplat/js/react-native-github/packages/react-native/scripts/react-native-xcode.sh) script is executed as one of the build phases. This phase bundles the JS application (dev or production).
I've updated this to use the new `bundle.js` script instead of calling the `react-native/cli.js`. This is identical except with how the config is captured:
{F1669960016}
This is similar to our approach with the Gradle plugin, giving Framework authors more control.
**Other:** formatting changes for the Privacy Manifest that Xcode keeps updating.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D57915368
fbshipit-source-id: f52ea4b3cb94212ac97a3d7edeb68747418fe0a9
Summary:
Fixes a bug where page IDs would collide for multiple connected Android devices running the same React Native app. The `Secure.ANDROID_ID` key (not value!) was being substituted in the ID string (pre-hashing) — now this segment is fixed.
Changelog:
[Android][Changed] - Update constructor signature of `DevServerHelper`
Reviewed By: hoxyq
Differential Revision: D58134323
fbshipit-source-id: 859e2758108e266167205a777bb6a6e87ca0573b
Summary:
## Changelog:
[Internal] - Exclude the windows folder from View in React-Fabric podspec
## Facebook:
The `platforms/windows` folder is internal only, not synched with OSS.
However, the C++ linking was picking up some files from that folder when running RNTester on iOS using the OSS pipeline.
bypass-github-export-checks
Reviewed By: dmytrorykun
Differential Revision: D58182437
fbshipit-source-id: 5397fadbe96d5c2c7980fbf5e74ffab7b237b912
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44790
Was seeing crash due to:
> Abort message: 'terminating due to uncaught exception of type facebook::jni::JniException: java.lang.NoSuchMethodError: no non-static method "Lcom/facebook/react/bridge/ReactInstanceManagerInspectorTarget$
TargetDelegate;.onSetPausedInDebuggerMessage(Ljava/lang/String;)V"
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D58165901
fbshipit-source-id: ceafd5776933fca5abb2e2edcac5e5f677cb7f7d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44788
We disabled the event loop in RN on the main branch after we found some issues in the implementation. Those have been resolved already so we can re-enable it again.
For context, it's already enabled in the latest branch so this is just for main.
Changelog: [internal]
Reviewed By: cortinico
Differential Revision: D58146393
fbshipit-source-id: ab908ecbd507d7087137a36cad5cc917eb7b1311
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44765
Noticed this was not shared with open-source. Needs to be converted to Kotlin still.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D58088583
fbshipit-source-id: 51d13f2faddc7bce297dda54f2dd23cefed6a588
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44779
We forked a copy of Bolts when we open-sourced bridgeless, but it contains many features we don't require, since we only use Tasks to orchestrate the bridgeless startup path.
The only meaningful change I made is removing the fallback on stack overflow from the immediate executor, which is not something we expect to hit during startup, and would be better surfaced as a StackOverflowException.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D58087989
fbshipit-source-id: a4908723a04bf47fdc38d91bf47df928b91456f5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44766
Changelog: [Internal]
There is currently a lifecycle bug in both the Bridge (`com.facebook.react.bridge`) and Bridgeless (`com.facebook.react.runtime`) integrations of Fusebox in React Native Android, whereby `HostTarget::unregisterInstance` gets called after the `HostTarget` has been destroyed. This manifests as a handful of related C++ crashes depending on the exact circumstances and build flags.
This diff makes the bug trigger a Java assertion instead of a C++ crash for ease of debugging. The next diff in the stack will actually fix the lifecycle issue.
Reviewed By: hoxyq
Differential Revision: D58031217
fbshipit-source-id: 9301b34edf5e526cbc72d86e78b328d29c9921b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44778
We now have the Publish_bumped_packages in GHA, so we should not have two jobs in two different systems that perform the same publishing operation.
## Changelog:
[Internal] - Remove duplicated jobs from CCI
Reviewed By: cortinico
Differential Revision: D58131196
fbshipit-source-id: 408b0a76dff89e9d327fe56d1e6e4c13b55eb2bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44758
Changelog: [Internal]
Adding a unit test to verify that the shadow node references are correctly updated to reference the new shadow node instance after cloning.
Reviewed By: sammy-SC
Differential Revision: D57893880
fbshipit-source-id: 6e36ca3d1b159f7bafb084246f714f3bfec58c1e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44773
Changelog: [Internal]
Update runtime shadow node references for cloning happening within `YogaLayoutableShadowNode` during layout. This will update the JS references to shadow nodes with the latest layout metrics used to render the component and improve layout cache usage on the next commit.
Reviewed By: sammy-SC
Differential Revision: D58000071
fbshipit-source-id: 373d41f37a81e81ab8f23006491027473493de61
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44771
Changelog: [Internal]
Adding a feature flag for enabling runtime shadow node reference updates only for clones happening within `YogaLayoutableShadowNode` to support layout data changes.
Reviewed By: sammy-SC
Differential Revision: D58000072
fbshipit-source-id: 204c0488edb992511a4b33d098b9df1b04001b9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44770
Changelog: [Internal]
Any shadow node cloning happening outside the execution of the UIManagerBinding `cloneNode` function should update references held to the shadow node to reference the latest revision. All shadow node cloning not requested by the JS runtime should update the references to those shadow nodes within the JS runtime so that these would hold the latest state updated outside of the React renderer (i.e. state data and layout metrics).
This guarantees that the React renderer's current fiber tree holds references to the ShadowNode instances that acually were layed out and committed for rendering on the native side. Maintaining these references up to date on the JS current fiber tree allows to maximize layout cache usage on subsequent commits.
Reviewed By: sammy-SC
Differential Revision: D57860867
fbshipit-source-id: f13e3fa9ad501fb2c8a387fb58b6379d236d7c2d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44772
Changelog: [Internal]
React native clones shadow nodes internally without providing the new instances to the React renderer (current fiber tree). To support updating the shadow node references held by the JS side, this diff wraps the returned shadow nodes and adds a link to the runtime reference on the shadow node instance.
This will allow for updating the shadow node references held within the JS runtime from the native side.
Reviewed By: sammy-SC
Differential Revision: D57860869
fbshipit-source-id: 1703f0cd0183e2760436920a122857e17fda8dbb
Summary:
This diff reverts D57878119
D57878119: [RN] [Android] Fix status bar height calculation for all cutout sizes by Abbondanzo causes the following test failure:
Tests affected:
- [xplat/endtoend/jest-e2e/apps/fb4a/__tests__/dating/onboarding/fb4aDatingOnboardingSessionImpressionLogging-e2e.js](https://www.internalfb.com/intern/test/562949977559606/)
Here's the Multisect link:
https://www.internalfb.com/multisect/5267005
Here are the tasks that are relevant to this breakage:
T189149205: 17 critical tests unhealthy for oncall dating_react_native_sop
The backout may land if someone accepts it.
If this diff has been generated in error, you can Commandeer and Abandon it.
Changelog: [Internal]
Reviewed By: Abbondanzo
Differential Revision: D58053899
fbshipit-source-id: c65a1094259f85c8e6084b2f191ca1e4cd149510
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44702
Based on bgirard initial changes in D53478653, this creates an initial integration of the Perfetto SDK with the User Timing API, allowing performance information to be logged from JS to Perfetto traces.
We only enable this for Android right now, but may be able to leverage this on other platforms too in the future.
The logic in `initializePerfetto` may need to moved to another common target (eg reactperflogger) once we want to make this usable in other components, but keeping it scoped to User Timing for now.
Changelog: [Internal]
Reviewed By: bgirard
Differential Revision: D57881823
fbshipit-source-id: 11ba09cbc01a102a72eee65ce6d6aeca508e864a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44480
TextInputs' onTextInput callback was removed way back in React Native 0.62 with https://github.com/facebook/react-native/commit/3f7e0a2c9601fc186f25bfd794cd0008ac3983ab , but remnants of the implementation exists.
Fully remove references on JS side now that no older clients are emitting this event
Changelog: [General][Removed] Remove viewconfigs for onTextInput callbacks
Reviewed By: cipolleschi
Differential Revision: D57092733
fbshipit-source-id: 62dae37d8e8f155969a1ca65131d4ee9a1d5f1c4
Summary:
Based on https://github.com/facebook/react-native/issues/44723.
This PR removes some Old Arch build only jobs on iOS.
Some of the recent changes where unifying the build process across archs, so we don't have to build Old and New Arch
## Changelog:
[Internal] - Remove OldArch jobs when they are not required
Pull Request resolved: https://github.com/facebook/react-native/pull/44729
Test Plan: CCI is green
Reviewed By: cortinico
Differential Revision: D57975238
Pulled By: cipolleschi
fbshipit-source-id: ffd0ff0534f25019d501aa3862baee1442088784
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44733
We are returning a Path to callers, which shouldn't be mutated. This isn't really safe. Return a copy to external callers instead, if they need a path to work with.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D57996157
fbshipit-source-id: 53cd95df6e2641d946f7c3fef40f6449b16ca5cb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44732
`getBorderBoxPath()` and `getPaddingBoxPath()` currently assume `updatePath()` will set a path, but this does not happen on Android 24 emulators where it seems like `onBoundsChanged` isn't called to set flag for needing update.
But, the current design tries to be lazy with path generation, and these are probably more expensive to clip, so we should really make these functions return nullable value, then fall back to rect, like the internals of `CSSBackgroundDrawable`, and how I misremembered these as working in the view code added originally in D57668976.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D57951852
fbshipit-source-id: 33bc8f738950597822ae9026408ab3a23b0923f3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44668
Enables regenerator for `hermes-canary`. Along with the previous diff, regenerator is the only difference between `hermes-stable` and `hermes-canary`.
Reviewed By: motiz88
Differential Revision: D57742907
fbshipit-source-id: ca14cb50fe976744c7fa2c0b3397e81661359f15
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44728
This makes them identical so the diff that makes them diverge is clear.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D57970711
fbshipit-source-id: 8586ef202ad27796918378832fa62df1708a0218
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44744
Correctly handle TurboModule promise rejections when there is no Exception message.
Changelog: [Android][Fixed] Android exceptions without a message would lead to unexpected crashes
Reviewed By: fabriziocucci
Differential Revision: D58014797
fbshipit-source-id: c94042818a00669a1be2db8e89e84c6b616efbec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44697
Google has discouraged attempting to read the `status_bar_height` resource [since 2017](https://youtu.be/_mGDMVRO3iE?si=qGQd7gLa_qTmfLGL&t=1079). With the introduction of display cutouts there can be a mismatch between the resource value and the true status bar size (and issues like [this one](https://github.com/facebook/react-native/issues/33612) popped up). The recommended approach is to instead call `getInsets` with the proper status bar and navigation flags provided by `WindowInsets`. On older APIs where `getInsets` is not supported, we have access to `systemWindowInsetTop`.
Changelog:
[Android][Fixed] - Fixed StatusBar.currentHeight calculations to honor all cutout sizes
Reviewed By: cipolleschi, alanleedev
Differential Revision: D57878119
fbshipit-source-id: 9fadd33d5f9b617a70a052c98dbd53fd29281650
Summary:
Changelog: [General][Fixed] Fixed LogBox not showing correctly on the New Architecture
We found an incorrect behavior in the event loop, where an error in a task would prevent its microtasks from running. This isn't spec compliant and should be fixed.
This caused LogBox to not work correctly, as error reporting is implemented via microtasks that would never execute.
Reviewed By: sammy-SC
Differential Revision: D58010521
fbshipit-source-id: 7901c5d6e83fb63af148e12ad6c32be490a3999d
Summary:
In the previous months, we worked with a GH engineer to run our test workflow on PRs. The workflow was running properly, so we want to run it on main too.
## Changelog:
[Internal] - Run gha on main too
Pull Request resolved: https://github.com/facebook/react-native/pull/44723
Test Plan: GHA is green
Reviewed By: cortinico, NickGerleman
Differential Revision: D57975230
Pulled By: cipolleschi
fbshipit-source-id: 89d06361ad6f2230b7000e05970e9b16539c9164
Summary:
Add synchronous JS bindings installation for TurboModules. That would help some 3rd party JSI based modules to install JS bindings easier.
https://github.com/facebook/react-native/issues/44486 for Android
## Changelog:
[Android] [ADDED] - Add BindingsInstaller for TurboModules
Pull Request resolved: https://github.com/facebook/react-native/pull/44526
Test Plan:
Added test in RN-Tester TurboModule test case
{F1660267530}
{F1660287029}
Reviewed By: javache
Differential Revision: D57223328
Pulled By: philIip
fbshipit-source-id: d4a69a16f6ce77c0a0fd63f008bea929b1964ab8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44709
Add some extra logging to try to figure out heisenbug, where we cannot find MapBuffer key that we should expect to be present, only during view preallocation.
ReadableMapBuffer toString() will itself iterate through MapBuffer entries, so this might not return something sane if underlying MapBuffer is corrupt or wrongly oriented, but should give us more context.
We also need to be careful here, to avoid logging the actual state mapbuffer or its binary which may contain text content. Only the paragraph attributes.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D57925730
fbshipit-source-id: cecca1a1fe53b4b417d520e65c30d47243cb2fb2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44707
Changelog: [Internal]
For DrawerLayoutAndroid in New Architecture, when we use ReactDev Tools layout inspection, incorrect node is being shown in the inspector tools.
This is because pointerEvents is not set to either `box-none` or `none` based on the drawer open/close state for the drawer child wrapper `View`.
Reviewed By: hoxyq
Differential Revision: D57873834
fbshipit-source-id: b2b82633969922189a0b96feea2115ddc0b2ebb5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44726
Changelog: [internal]
## Context
We ran an experiment to test synchronous state updates in Fabric and we saw some crashes on Android. Those crashes were caused by mounting operations not being applied in the correct order.
There were 2 root causes for that problem:
1. State updates triggered during mount would be committed and mounted synchronously during that specific mount operation. That caused problems like trying to clip views that weren't created already (as we were processing the state update for the content offset before we actually created the child views).
2. Same problem as before, but with mount operations that were processed when the root view wasn't available yet (this is a separate queue).
We tried to fix the problem in https://github.com/facebook/react-native/pull/44015, but the solution for 2) was incorrect, as we didn't account for those operations being in a different queue (it was reverted in https://github.com/facebook/react-native/pull/44724).
## Changes
I think the right solution for point 2) is that, instead of marking the root view as available and then process all pending operations, we flip those operations.
That was, if there are any mount operations as a side-effect of processing that queue, those will also be added to the same queue, instead of being processed immediately in `MountItemDispatcher`.
Reviewed By: sammy-SC
Differential Revision: D57968937
fbshipit-source-id: 93d10cdeced0c837d4301768aee8575d2c940b10
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44725
Changelog: [internal]
## Context
We're currently testing synchronous state updates in Fabric (committing shadow trees for state updates synchronously in the thread where they were dispatched, instead of always scheduling it in the JS thread).
In these experiments we saw a problem caused by a recent change in the Android mounting layer (done to fix a problem with the Event Loop) where we were doing the mount operations inside a mutex lock. The problem is that we didn't have recursive commit+mount operations (because we were dispatching state updates in the JS thread) but now that we do we get a deadlock here.
{F1659804385}
These recursive commit+mount operations happen because it's possible to trigger state updates while we mount changes in the host platform (e.g.: we create the scroll view and we update the state to set the content offset). Those state updates trigger more mount operations, which deadlock in the mentioned place.
## Changes
This fixes the described issue by restricting the lock only to access the list of pending operations, but not to apply them. In the current implementation, `mountingManager->executeMount` is protected by the lock, whereas in the new version it isn't (so it can be safely called recursively). The synchronization of the mount operations is done directly at the mounting layer on Android.
Reviewed By: sammy-SC
Differential Revision: D57968936
fbshipit-source-id: 52f996d212cad691646610632b03b5223e7e90ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44724
Changelog: [internal]
Batching operations at this layer was wrong because these are the operations that were already flushed by the mounting layer but were accumulated in `SurfaceMountingManager` because the root view wasn't created.
These operations should be executed before anything else that's scheduled in the `MountItemDispatcher`, so we should never batch them. The problem this was trying to solve is solved in a different way in D57968937.
This was gated so this shouldn't affect any current usages.
Reviewed By: sammy-SC
Differential Revision: D57968939
fbshipit-source-id: e9131614cdc76e9d553540757611bc8b0736c927
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44727
This is a re-land of https://github.com/facebook/react-native/pull/44048
Reverting it caused even bigger regression, so my earlier assessment was wrong. The initial regression was caused by something else.
Changelog: [Internal] - Let's keep the changelog entry form the original diff.
Reviewed By: fkgozali
Differential Revision: D57970133
fbshipit-source-id: c683d661a805d44434f5491e89dd4b7218379bee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44716
Move to listr2 which handle non-TTY environment, outputting to CircleCI logs in a useful way. This gives our CI users more useful debugging information, but limits the output when running locally.
If you want more explicit output locally, do something like:
```
yarn run build | cat
```
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D57915369
fbshipit-source-id: ae9f87b0b9608f16ee035b791c5f7b81544c498c
Summary:
On React Native macOS (I am not sure with the current state of React Native), the Xcode Unit and Integration tests are a bit flaky. Rather than set "retry on failure up to 3 times" through the pipeline config (in our case, Azure Pipelines), I realized my earlier PR to use Xcode test plans (https://github.com/facebook/react-native/pull/36443) means we can have Xcode retry the test. This should be faster than retrying it on the pipeline, because it retries just the failing test, not the entire "test" step. I did this on React Native macOS, so I'm doing it upstream so we can remove a diff.
## Changelog:
[INTERNAL] [CHANGED] - Set `retryOnFailure` for Xcode Unit and Integration tests
Pull Request resolved: https://github.com/facebook/react-native/pull/44642
Test Plan: CI should pass (faster)
Reviewed By: cortinico
Differential Revision: D57662523
Pulled By: cipolleschi
fbshipit-source-id: 8de2ab0ea15ba4d38c3b5bf96108c0c7ff5e9f32
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44708
Changelog: [internal]
We had a fallback to use a Hermes internal API if the native module exposing `queueMicrotask` wasn't available. This is no longer necessary as the module is available everywhere we enable the event loop, so we can remove it.
Reviewed By: christophpurrer
Differential Revision: D57922076
fbshipit-source-id: 0ca48abacd77a75ce8559db08f55c78a3e0ec815
Summary:
Add synchronous JS bindings installation for TurboModules. That would help some 3rd party JSI based modules to install JS bindings easier.
Re-create from https://github.com/facebook/react-native/issues/43110 but for iOS
## Changelog:
[IOS] [ADDED] - Add BindingsInstaller for TurboModules
Pull Request resolved: https://github.com/facebook/react-native/pull/44486
Test Plan: Added test in RN-Tester TurboModule test case
Reviewed By: javache
Differential Revision: D57224891
Pulled By: philIip
fbshipit-source-id: fabe5c4f8d2087ac9a465f2cb90d884b83265a68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44705
`focusable` props behaviors are inconsistent across different flavors of Touchable components. Some use the disabled prop to check if the component should be focusable, others do not.
This ensures all Touchable* component flavors use the disabled prop.
## Changelog
[General][Fixed] Fixed inconsistency in TouchableX component disabled / focusable behavior
Reviewed By: yungsters
Differential Revision: D57910488
fbshipit-source-id: af17227403338fcd5bebd9ba7c3172b4c6776e1f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44706
We didn't ship this, and asking around, I don't think mdvacca was looking at this actively (though is on PTO right now).
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D57913491
fbshipit-source-id: 86afd5a6bb5e7ce6be540f2295aa407134a6d81c
Summary:
Expose host delegate methods that users can do some customize work.
## Changelog:
[IOS] [ADDED] - Bridgeless: Expose host delegate methods
Pull Request resolved: https://github.com/facebook/react-native/pull/44158
Test Plan: Users can do some customized work by `RCTRootViewFactory`.
Reviewed By: sammy-SC
Differential Revision: D56521470
Pulled By: cipolleschi
fbshipit-source-id: dd22d0978b9fd4385380945a514eb6596b7d874f
Summary:
XCode privacy files might not contain a `NSPrivacyAccessedAPITypes` key, which causes the following error:
```
[!] An error occurred while processing the post-install hook of the Podfile.
undefined method `each' for nil
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:111:in `block (4 levels) in get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:106:in `each'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:106:in `block (3 levels) in get_used_required_reason_apis'
```
## 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] - Privacy Manifest aggregation failing due to no `NSPrivacyAccessedAPITypes` key
Pull Request resolved: https://github.com/facebook/react-native/pull/44628
Test Plan: I tested this patch on our own app and it solved the issue.
Reviewed By: christophpurrer
Differential Revision: D57618425
Pulled By: cipolleschi
fbshipit-source-id: 1a36ab5a1bb45b8507d3663b782c95258d97c8a4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44699
Changelog: [Internal]
In Fabric, overflow props for ScrollView is not passed down. Hence, the overflow props is ignored and FlatList content is always clipped.
Reported from OSS https://github.com/facebook/react-native/issues/44683
Reviewed By: sammy-SC
Differential Revision: D57895399
fbshipit-source-id: 6ce65bea0803971060e8229b66563123dd6fc114
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44695
Changelog: [internal]
We tested this feature flag at Meta and it's neutral when used outside the event loop. We'll handle its effects on the event loop as part of the event loop experiment itself (when enabling paint blocking).
Reviewed By: tdn120
Differential Revision: D57861195
fbshipit-source-id: 11a208ef5433321a464cfc16f4ff026d52988b42
Summary:
Currently, if the `Animated.sequence` animation is finished, and then the `start()` method is called without a `reset()` method being invoked beforehand, the failure happens: ```undefined is not an object (evaluating 'animations[current].start')```.
Use cases:
- sequence animation started, finished, and then started again
- sequence animation is used in `Animation.loop` with `resetBeforeIteration` set to `false`, which essentially does the same as the previous case
Related issues:
- https://github.com/facebook/react-native/issues/43120
- https://github.com/facebook/react-native/issues/37611
## Changelog:
[General] [Fixed] - Fix sequence restart failure
Pull Request resolved: https://github.com/facebook/react-native/pull/44031
Test Plan: Test cases are included: 1 for regression and 2 for mentioned use cases in the summary
Reviewed By: cipolleschi
Differential Revision: D56015346
Pulled By: dmytrorykun
fbshipit-source-id: 8b0f46c8a33397fece807634463ce630c89d28af
Summary:
When running the Analyzer in Xcode, I got a warning denoting that `viewDidLoad` was not called on `super` in the overridden `RCTRedBox.viewDidLoad`. While I have not observed any anomalies, it is best practice to call on super in the overridden view controller life cycle methods.
## Changelog:
[iOS] [FIXED] - Add missing call to `[super viewDidLoad]` in `RCTRedBox.mm`.
Pull Request resolved: https://github.com/facebook/react-native/pull/44686
Test Plan:
Running the RNTester yielded the following screenshot:
<img width="549" alt="Screenshot 2024-05-27 at 11 26 40" src="https://github.com/facebook/react-native/assets/2263015/b91e126c-9dc1-4e52-8a6b-50ea8bea2c3f">
Reviewed By: fabriziocucci
Differential Revision: D57856354
Pulled By: javache
fbshipit-source-id: d76a4779e02f40af69eed156489e57299968d4be
Summary:
The `mapbufferjni` was not exposed via prefab. I'm adding it to make possible for react-native-live-markdown to integrate on top of React Native via prefab. Based on https://github.com/facebook/react-native/issues/36166.
## 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] [CHANGED] - Expose `mapbufferjni` via prefab.
Pull Request resolved: https://github.com/facebook/react-native/pull/44684
Reviewed By: fabriziocucci
Differential Revision: D57856389
Pulled By: javache
fbshipit-source-id: 9926b02724950f4025c7f867257e8229d44c43a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44655
Required to compile with clang
This is because previously it was comparing size_t with int which is not allowed under compilation with clang
Changelog: [Internal] [Fixed] - Replaced old style for loop with new style to avoid clang errors with size_t to int comparisons
Differential Revision: D57721635
fbshipit-source-id: 2738f7b415d668c37536f7f93b2e0985fa2cc5e6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44672
Swaps out and simplifies the internals of the debugger launch flow.
We observed that we could achieve better launch/windowing behaviour by passing the `--app` argument directly to the detected Chrome path.
This shares the user's default Chrome profile:
- Fixes unwanted behaviour such as a separate dock icon on macOS (which, when clicked, would launch an unwanted empty window).
- Enables settings persistence.
This change also removes the `LaunchedBrowser.kill` API.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D57726649
fbshipit-source-id: fc3a715dc852a50559048d1d1c378f64aeb2013f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44638
Reverts the debugger launch flow to use the default `ChromeLauncher` profile. This is the approach used in the current `--experimental-debugger` experiment and by Expo.
This is motivated after a review of the tradeoffs of a guest profile — which allow us to programatically quit the browser process, however takes over system URL handling.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D57619542
fbshipit-source-id: 3713e1cf8eed61e7a70ed1e4eb58f02da845155f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44496
When doing performance profiling on a React Native iOS app and trying to identify bottlenecks on the native side it can be helpful to correlate actions to what is happening inside React Native. We already have the SystraceSection class for this, but it does nothing in open source. This diff allows SystraceSection to feed into the Instruments signpost API on iOS/macOS.
Changelog:
[iOS][Added] - Add Instruments signposts API for SystraceSection
Reviewed By: sammy-SC
Differential Revision: D56280451
fbshipit-source-id: 4e962e932b6b6e09e5953abdc1aa621a2723c91e
Summary:
This PR adds percentage support in translate properties for android. Isolating this PR for easier reviews.
## Changelog:
[Android] [ADDED] - Percentage support in translate
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/43193
Test Plan:
- Checkout TransformExample.js -> Translate percentage example.
- Added a simple test in `processTransform-test.js`. The regex is not perfect (values like 20px%, 20%px will pass, can be improved, let me know!)
Related PRs - https://github.com/facebook/react-native/pull/43191, https://github.com/facebook/react-native/pull/43192
Reviewed By: joevilches
Differential Revision: D57723216
Pulled By: NickGerleman
fbshipit-source-id: c9da007678341b62745df858f043821bcc662a98
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44646
We can remove most of the code for clipping children to border radius, and recalculating paths, in ReactViewGroup, and rely on the padding box path/rect already set.
I will move this to something more generic up the stack so other native components can reuse this logic.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D57668976
fbshipit-source-id: 8b8cf956dc8689827bccba5e41751b465fd85eeb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44590
emitDeviceEvent is frequently used for perf-critical operations such as sending network responses from native to JS. We don't need to go through JavaScriptModule Proxy (which is missing caching in bridgeless) and instead can immediately invoke the callable JS module.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D57435750
fbshipit-source-id: 1c120073ac80afd95deb8e3e6f1c00c2d3d80133
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44576
Store callable modules as either a factory function or an object, so we can skip invoking the factory function for frequently accessed objects.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D57338528
fbshipit-source-id: cd39ccbe7168c6f093a0e62d5880cbbcd5209c8e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44631
Changelog:
[General][Breaking] Use hasteModuleName for C++ Turbo Module enums
This is a follow up to https://github.com/facebook/react-native/pull/44630
This changes the names of C++ Turbo Modules enums to use the `hasteModuleName`.
Example: `NativeMyAbcModule.js` with this spec:
```
export enum EnumNone {
NA,
NB,
}
export interface Spec extends TurboModule {
+getStrEnum: (arg: EnumNone) => EnumStr;t
}
export default (TurboModuleRegistry.get<Spec>('MyAbcModuleCxx'): ?Spec);
```
Before now we generated a base C++ struct with the name:
```
MyAbcModuleCxxEnumNone
^^^
```
Now the generate name is:
```
NativeMyAbcModuleEnumNone
^^^^^^
```
## Changes:
- No `Cxx` injected anymore
- Ensure base struct is `Native` prefixed (all RN JS TM specs start with it)
Reviewed By: cipolleschi
Differential Revision: D57602082
fbshipit-source-id: 9ebd68b8059dfbc6e2ec11065915cf049aa3cb0b
Summary:
In https://github.com/facebook/react-native/pull/37510, a check was introduced to check if user is using `latest` version of `npx`, but right now it checks for every command executed, but it should only ensure that `latest` is included when creating a new project.
In this Pull Request I've added a condition to only warn if `init` was fired.
## Changelog:
[GENERAL] [FIXED] - Warn only in `init` command when CLI uses cached `npx` version
Pull Request resolved: https://github.com/facebook/react-native/pull/44644
Test Plan: Warning about using `latest` version CLI should only be presented when running `init` command.
Reviewed By: arushikesarwani94
Differential Revision: D57681864
Pulled By: blakef
fbshipit-source-id: 5c81b9a08141396efcd24539b2560cea16028dd9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44650
Changelog: [Internal]
Adds the missing `DoNotStrip` annotations to methods of `CxxInspectorPackagerConnection.DelegateImpl` that are called from C++.
Reviewed By: huntie
Differential Revision: D57708376
fbshipit-source-id: 8a72b19211b60ce7a6049079e5ecfc2e96bc974f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44630
Changelog:
[General][Breaking] Use hasteModuleName for C++ Turbo Module structs
This changes the names of C++ Turbo Modules structs to use the `hasteModuleName`.
Example: `NativeMyAbcModule.js` with this spec:
```
export type ValueStruct = {
x: number,
y: string,
z: ObjectStruct,
};
export interface Spec extends TurboModule {
+getValueStruct: () => ValueStruct
}
export default (TurboModuleRegistry.get<Spec>('MyAbcModuleCxx'): ?Spec);
```
Before now we generated a base C++ struct with the name:
```
MyAbcModuleCxxValueStruct
^^^
```
Now the generate name is:
```
NativeMyAbcModuleValueStruct
^^^^^^
```
## Changes:
- No `Cxx` injected anymore
- Ensure base struct is `Native` prefixed (all RN JS TM specs start with it)
## Why?
- The `Cxx` extension is a temporary hint to react-native-codegen to enable extra capabilities and might disappear eventually
- The C++ base struct name should be 'stable'
- The name of the exported TM JS spec `TurboModuleRegistry.get<Spec>(...)` is abritrary, the hasteName is not
- The name of the RN JS TM spec must start with `Native` which better guarantees a consistent naming scheme for these generated base class
- The C++ Turbo Module base class has now the same prefix as the generated structs - `NativeMyAbcModule` for the example above
Reviewed By: cipolleschi
Differential Revision: D57599257
fbshipit-source-id: 4fafe6c7e920737fa766bd7e8e68e521f608e775
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44620
We added a log message when trying to lock revisions in `LazyShadowTreeRevisionConsistencyManager` when they were already locked, and we've seen that being logged in existing experiments, which could indicate we're doing re-entrance from the JS runtime.
This protects against that case migrating the boolean flag to an integer.
Changelog: [internal]
Reviewed By: NickGerleman
Differential Revision: D57509193
fbshipit-source-id: 1712aa84d665c9dfe50630818e7f56de7d7e145c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44619
Some methods in `LazyShadowTreeRevisionConsistencyManager` can be called in parallel when using synchronous state updates (which is also behind a flag). This implements thread-safety to cover that case so we don't have issues when testing that variant in production.
Changelog: [internal]
Reviewed By: NickGerleman
Differential Revision: D57506540
fbshipit-source-id: 362e1df534bc8c87289882236cfe0d7ee261f507
Summary:
Changelog: [Internal]
bypass-github-export-checks
Currently, Hermes never generates object/array previews for values logged via the `console` API. This makes console logs significantly less readable than in Chrome. Here we enable the preview generation machinery that already exists in Hermes.
We conservatively mimic V8's behaviour of [only generating previews for immediately-emitted messages](https://source.chromium.org/chromium/chromium/src/+/main:v8/src/inspector/v8-console-agent-impl.cc;l=53,64;drc=451a101b0a8bbc323dbf5697dd956b55284ec9ee) and not for buffered messages. I don't know *why* V8 does this, but can only guess it's meant to improve the performance of starting a debugging session, by evaluating less code and sending smaller payloads. (Anyway, we can change our decision later.)
Reviewed By: dannysu
Differential Revision: D57617059
fbshipit-source-id: 1f5a71ce98ac915a5b874ed6c009d971405a9f2d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44637
Setting the wrong thing to {}. `result` should be set here just like in the other early returns.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D57617046
fbshipit-source-id: e47dbdb7821879ffa02d11b7e68eec1c9bfbdefd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44226
Changelog: [Android][Removed] Delete ReactContext.initializeWithInstance(). ReactContext now no longer contains legacy react instance methods. Please use BridgeReactInstance instead.
Yet another attempt to land this (last one was D55964787).
Copy-pasting below the amazing summary from RSNara.
## Context
Prior, ReactContext used to implement bridge logic.
For bridgeless mode, we created BridgelessReactContext < ReactContext
## Problem
This could lead to failures: we could call bridge methods in bridgeless mode.
## Changes
Primary change:
- Make all the react instance methods inside ReactContext abstract.
Secondary changes: Implement react instance methods in concrete subclasses:
- **New:** BridgeReactContext: By delegating to CatalystInstance
- **New:** ThemedReactContext: By delegating to inner ReactContext
- **Unchanged:** BridgelessReactContext: By delegating to ReactHost
## Auxiliary changes
This fixes ThemedReactContext in bridgeless mode.
**Problem:** Prior, ThemedReactContext's react instance methods did not work in bridgeless mode: ThemedReactContext wasn't initialized in bridgeless mode, so all those methods had undefined behaviour.
**Solution:** ThemedReactContext now implements all react instance methods, by just forwarding to the initialized ReactContext it decorates (which has an instance).
NOTE: Intentionally not converting `BridgeReactContext` to Kotlin to minimize the risk of these changes.
Reviewed By: cortinico
Differential Revision: D56064036
fbshipit-source-id: 2e380bf7ee46892c5fc0044b03a929f12d122157
Summary:
Goal of this PR is to optimise `Pressable` component, similarly to https://github.com/react-native-tvos/react-native-tvos/pull/724 . `Pressable` `style` and `children` properties can, but doesn't have to be functions. Usually we passing objects or arrays. `pressed` state is used only when `style` or `children` are `functions`, so let's update that state only in such case, otherwise let's skip state updates to improve the performance.
That way we won't have to rerender the component when it is being pressed (assuming that `style` and `children` are not going to be functions)
## Changelog:
[GENERAL] [CHANGED] - Improve performance of `Pressable` component.
Pull Request resolved: https://github.com/facebook/react-native/pull/44615
Test Plan: Verify that `Pressable` updates its `pressed` state when `style` or `children` are functions.
Reviewed By: javache
Differential Revision: D57614309
Pulled By: fabriziocucci
fbshipit-source-id: 473e0ab3c4bf7b3ef04ba19f76105ac65371a3fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44582
D54496604 fixed lifecycle methods for JavaTimerManager, which now reveals another bug. Because this codepath ends up creating a `HeadlessJsTaskContext` which in turn creates a `Handler`, ReactInstance destruction doesn't complete cleanly.
```
2024-05-15 17:42:52.935 12681 27113 W fb4a.BridgelessReact: ReactHost{1}.getOrCreateDestroyTask(): React destruction failed. ReactInstance task faulted. Fault reason: Can't create handler inside thread Thread[pool-51-thread-1,5,main] that has not called Looper.prepare(). Destroy reason: FbReactInstanceHolder.destroyReactManager(): FbReactInstanceLogoutCleaner.clearReactInstanceData()
```
The fix is to not create our own Handler, but instead use the shared methods in UiThreadUtil.
Changelog: [Android][Fixed] Fixed error thrown during ReactInstance teardown
Reviewed By: cortinico
Differential Revision: D57378247
fbshipit-source-id: a31dc8e35b5418a71b83c301973f12350f2ee01b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44633
`toDynamic` no longer exists for ParagraphState, so try the MapBuffer value first, before triggering the error introduced in D56963463.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D57439386
fbshipit-source-id: 31e6466d9dec5b835551cca6c946b28cfbd4578b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44626
This variable is unused and is shadowed by a function local.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D57568098
fbshipit-source-id: e5f56b7ef88497d4b9935275eb7e805660741146
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44237
This adds support for color function values to ColorPropConverter per the wide gamut color [RFC](https://github.com/react-native-community/discussions-and-proposals/pull/738). It updates the color conversion code so that it returns a Color instance before ultimately being converted to an Integer in preparation for returning long values as needed.
## Changelog:
[ANDROID] [ADDED] - Update ColorPropConverter to support color function values
Pull Request resolved: https://github.com/facebook/react-native/pull/43031
Test Plan:
Colors should work exactly the same as before.
Follow test steps from https://github.com/facebook/react-native/pull/42831 to test support for color() function syntax.
While colors specified with color() function syntax will not yet render in DisplayP3 color space they will not be misrecognized as resource path colors but will instead fallback to their sRGB color space values.
---
After the failure with the tests, I reapplied the changes and test some Jest e2e tests that were failing yesterday:
{F1495277376}
Reviewed By: cortinico
Differential Revision: D56517579
Pulled By: cipolleschi
fbshipit-source-id: ae9b5bc2afe9eb9760dd91afb090385daf7102b8
Summary:
D57197676 reordered the TextExample test cases, but accidentally reused the same string as the case in packages/rn-tester/js/examples/Text/TextInlineViewsExample.js
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D57279961
fbshipit-source-id: 60a41eaf13d82538ee149fe4ef5531e42c00b012
Summary:
tsia. Done to allow for easier interaction of the examples, especially those with long descriptions
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D57278607
fbshipit-source-id: f0a1d06c97c019fe177c8b9e51c3ca0ae12caef5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44552
Changelog: [Android][Fixed] If the RNTester app is started with a deeplink intent, we now correctly navigate there for Android to facilitate e2e testing. This already worked on ios.
Reviewed By: javache
Differential Revision: D54662737
fbshipit-source-id: 5bbf824c80e226f441bdcbc4fa67e41ab4c3eb33
Summary: Changelog: [Android][Added] add FBEndToEndDumpsysHelper stub to RNTester Android to be able to dump ViewHierarcies internally.
Reviewed By: makovkastar
Differential Revision: D54662739
fbshipit-source-id: 5236ae84ed648d431a8f01558f8f84049480ba39
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44618
This change is a prerequisite to converting this file to Kotlin. It adds null checks to potentially nullable window and inset getters that were previously not there.
## Changelog:
[Android] [Changed] - Added null checks, marked null safety in StatusBarModule
Reviewed By: NickGerleman
Differential Revision: D57553395
fbshipit-source-id: 5293bb74a95d22bb82971c0a9d691c9e5e36d81f
Summary:
`pod install` and CocoaPods are actually not macOS specific.
Still, the pod lifecycle scripts of `react-native` depend on macOS-only utilities and will fail on Linux.
This is an attempt to make the scripts portable and make the pod install cleanly on Linux as well as macOS.
## Changelog:
[INTERNAL] [FIXED] - Skip XCode patching when not run on macOS
[INTERNAL] [FIXED] - Fall back to `which gcc`/`which g++` to identify C/C++ compiler when `xcrun` not available
[INTERNAL] [FEAT] - Recognize CC and CXX env vars supplied to the script and prefer them over autodetection
Pull Request resolved: https://github.com/facebook/react-native/pull/44417
Reviewed By: NickGerleman
Differential Revision: D57055928
Pulled By: cipolleschi
fbshipit-source-id: 1c49f70c52b4667abf0a215cbee52ee6aa6dd052
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44602
Fix regression caused by D56943825 where radii set to 0 was not being considered. Also preemptively fix a possible bug with RTL due to incorrect overrides.
Changelog:
[Android][Fixed] - Fix borderRadius incorrect overrides
Reviewed By: NickGerleman
Differential Revision: D57473482
fbshipit-source-id: d22a46bdd271d5f254e7d7e54abc55c00a8da8f2
Summary:
Apple is enforcing that new apps submission to the store mst use XCode 15. There is no reason to keep testing on Xcode 14.3 anymore, hence we are removing those jobs.
While doing that, we are also aligning the tests between Test_All and test_iOS workflows.
bypass-github-export-checks
## Changelog:
[Internal] - Remove CircleCI tests for Xcode 14.3
Pull Request resolved: https://github.com/facebook/react-native/pull/44448
Test Plan: CircleCI must stay Green
Reviewed By: huntie
Differential Revision: D57153939
Pulled By: cipolleschi
fbshipit-source-id: 82278bcb598b134238852e32b667a28619fb74cb
Summary:
One of the last parts of the migration. This PR foucuses on bringing the template jobs to Github actions.
bypass-github-export-checks
## Changelog:
[Internal] - Migrate template jobs from CCI to GH
Pull Request resolved: https://github.com/facebook/react-native/pull/44511
Test Plan: https://fburl.com/workplace/f6mz6tmw
Reviewed By: blakef
Differential Revision: D57202477
Pulled By: cipolleschi
fbshipit-source-id: be562cd3690d221f094dc734dd501aac25c36f59
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44613
We are building a native CSS parser for Fabric, to allow broader support for CSS. One area not yet implemented are features required for color.
<hash-token> is a pre-requisite.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D57180293
fbshipit-source-id: 0932c44d881f205aed55bcdf4fa23ad04b336c11
Summary:
Right now we use layout direction determined by I18NManager to influence the root Yoga layout direction.
Individual views may have a different resolved layout direction (e.g. due to `direction` style prop), and even though we don't rely on Android layout props, Android components still need to inherit or know the right layout direction to still do correct drawing. Example of this was scrollbar showing up on the left, instead of right in RTL, as soon as ScrollView knew it was in RTL.
This has potential to change a good amount of behavior, so this is under QE.
Changelog:
[Android][Fixed] - Propagate layout direction to Android Views and Drawables
Reviewed By: joevilches
Differential Revision: D57248417
fbshipit-source-id: 4bcdf2b23277ff926a796b8377df08d49c7b914c
Summary:
D57285584 was reverted because we have service code with a faulty measure function, and adding logging to Yoga when invalid measurements were received was enough to spike error rate to elevated levels and block release.
This is a reland of the below change, with a couple modifications:
1. We log warnings instead of errors, which from what I heard, shouldn't block release, but should still make signal
2. We only zero the dimension which was NaN, to preserve exact behavior
## Original
We've started seeing assertion failures in Yoga where a `NaN` value makes its way to an `availableHeight` constraint when measuring Litho tree.
Because it's only happening on Litho, I have some suspicion this might be originating from a Litho-specific measure function. This adds sanitization in Yoga to measure function results, where we will log an error, and set size to zero, if either dimension ends up being negative of `NaN`.
This doesn't really help track down where the error was happening, but Yoga doesn't have great context to show this to begin with. If we see this is issue, next steps would be Litho internal intrumentation to find culprit.
Changelog: [Internal]
Reviewed By: sbuggay
Differential Revision: D57473295
fbshipit-source-id: 979f1b9a51f5550a8d3ca534276ec191a3cb7b9e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44600
I didn't pay close enough attention during merge between V1 and V2 of D57248205, and what I ultimately checked in is not correct. Fix the logic here.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D57488372
fbshipit-source-id: c9db597a6ae4ca5ae81e6ccd9913a14be268dd57
Summary:
This PR adds percentage support in translate properties for new arch iOS. Isolating this PR for easier reviews.
The approach taken here introduces usage of `ValueUnit` struct for transform operations so it can support `%` in translates and delay the generation of actual transform matrix until view dimensions are known. I have tried to keep the changes minimal and reuse existing APIs, open to changes if there's an alternative approach.
## Changelog:
[IOS] [ADDED] - Percentage support in translate in new arch.
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/43192
Test Plan:
- Checkout TransformExample.js -> Translate percentage example.
- Added a simple test in `processTransform-test.js`. The regex is not perfect (values like 20px%, 20%px will pass, can be improved, let me know!)
Related PRs - https://github.com/facebook/react-native/pull/43193, https://github.com/facebook/react-native/pull/43191
Reviewed By: javache
Differential Revision: D56802425
Pulled By: NickGerleman
fbshipit-source-id: 978cbbdde004afe1e68ffee9a3c7eb7d16336b46
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44538
Android originated without RTL support. When RTL support was added, Applications needed to set `android:supportsRtl="true"` in their manifest, to allow Android to do RTL specific layout and drawing. This became the default for new projects created by Android Studio at some point.
React Native was not setting this in template, which means apps created from it do not do any of Android's RTL layout, text alignment, or drawing (e.g. in D3652980 8 years ago, a native drawer component came from the wrong side of the screen). RN would still layout the app using Yoga in RTL if in RTL locale though.
This change sets `android:supportsRtl` in template matching default new Android projects, and to avoid mismatched states in the future, will only tell I18NManager that RTL is allowed if `android:supportsRtl` is also set. This is breaking, since existing apps may not get Yoga RTL support unless telling Android that the application should support RTL layout.
Changelog:
[Android][Breaking] - Set and require `android:supportsRtl="true"` for RTL layout
Reviewed By: joevilches
Differential Revision: D57248205
fbshipit-source-id: 3f60c9f855db26f8d34a2e05d460f95961f5ffeb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44561
D57089275 introduced a layer to parse component values out of the token stream. I modeled this similar to the tokenizer, as a flat iterator of component values. Because function components can nest a variable number of child component values, this now looks like storing a fully resolved tree of tokens on the heap during parsing.
This diff changes the model, so that `CSSSyntaxParser::consumeComponentValue()` no longer returns a resolved CSS function value. Instead, users of the parser are expected to provide "visitors" which continue parsing, matched based on component value type pattern matched. Visitors can perform parsing specific to their context, and propagate values up the stack, based on their evaluation of the component value.
Removing the heap allocated list of tokens here also lets this core CSS parsing stack keep constexpr, so I added that back, though we need to keep expression trees for math expressions in uncommon cases, so the layer up probaly won't keep constexpr.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D57206706
fbshipit-source-id: 25db84d376ef18f6291e60ed953e29c4000a7a26
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44546
# Changelog:
[Internal] -
This is the first chunk of moving all of the interfaces to Kotlin inside `react.bridge`, covering the small-ish (functional/SAM and such) interfaces.
Reviewed By: javache
Differential Revision: D57253634
fbshipit-source-id: aa26d26b9681ac7c6059c249b985ff5121ad1e9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44583
This native module is only available in the new architecture, stub the methods elsewhere.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D57382785
fbshipit-source-id: f6c988bcfd12633697b45a1f862b2cd4fb5d00d4
Summary:
Currently RCTPerfMonitor won't show up in scene based app, we should first try to extract the window from the connected scenes, and fallback to the window in `UIApplicationDelegate`.
## 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] - Fix RCTPerfMonitor not showing up in scene based app
Pull Request resolved: https://github.com/facebook/react-native/pull/43476
Test Plan:
- Tested RCTPerfMonitor in app not using scenes;
- Tested RCTPerfMonitor in app using scenes in iOS 13 & 14;
- Tested RCTPerfMonitor in app using scenes in iOS 15+.
Reviewed By: rshest
Differential Revision: D57381551
Pulled By: javache
fbshipit-source-id: fd6cce20c9a4ed41d7aae84751fc0c83391d0865
Summary:
I used the `createRootViewWithBridge` in a Project and got the hint to migrate to the `customiseView` Method. I searched for the Method, but found it under a different name: `customizeRootView`.
So i thought it would be helpful to use the correct Method name inside the hint message.
## 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] - fixed Method name in hint from customiseView to customizeRootView
Pull Request resolved: https://github.com/facebook/react-native/pull/44585
Test Plan:
* Use `createRootViewWithBridge`
* Should get a hint to migrate to `customizeRootView` method
Reviewed By: fabriziocucci
Differential Revision: D57431185
Pulled By: javache
fbshipit-source-id: 14f8c33771551ea3fb66d2c8f3fce4b4e3ef962a
Summary:
The current implementation does not support System font variants. Currently the isCondensed variable is always returning false. This pr adds an extra check to support the 'SystemCondensed' font variant on iOS.
## 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][ADDED] - Update font to handle system condensed variant
Pull Request resolved: https://github.com/facebook/react-native/pull/43188
Test Plan:
```
<Text style={{ fontSize: 28, fontFamily: 'System' }}>System</Text>
<Text style={{ fontSize: 28, fontFamily: 'SystemCondensed' }}>SystemCondensed</Text>
<Text style={{ fontSize: 28, fontFamily: 'AmericanTypewriter-Condensed' }}>AmericanTypewriter-Condensed</Text>
<Text style={{ fontSize: 28, fontFamily: 'HelveticaNeue' }}>HelveticaNeue</Text>
<Text style={{ fontSize: 28, fontFamily: 'HelveticaNeue-CondensedBold' }}>HelveticaNeue-CondensedBold</Text>
```

Reviewed By: fabriziocucci
Differential Revision: D57329036
Pulled By: javache
fbshipit-source-id: b0fffde1a568cb498f907e0a007df4da3e11d586
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44554
Noticed than when reload is triggered by Metro (`handleReloadJS`), the application would often get stuck and not respond to further reload commands. Often an IOException would get printed as well, due to concurrent bundle loads happening.
Changelog: [Android][Fixed] Improved resiliency of reloads when bundle loading fails
Reviewed By: RSNara
Differential Revision: D57112152
fbshipit-source-id: b0bf8c8311264504684a137c0910e2eeb008b0c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44574
`emitDeviceEvent` is frequently used for perf-critical operations such as sending network responses from native to JS. We don't need to go through JavaScriptModule Proxy (which is missing caching in bridgeless) and instead can immediately invoke the callable JS module.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D57329165
fbshipit-source-id: 6506a7afb522b672a1f3dc7d348c9b80e6734225
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44577
There are no references to `AnimationsDebugModule` and it is also no longer public, so it is dead code. This cleans it up.
Changelog:
[Android][Removed] - Removed `NativeAnimationsDebugModule` (already not Public API)
Differential Revision: D57351893
fbshipit-source-id: 5a78a3b8e93a87ccb0cd5cdf8d2308d6c53d0ffa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44558
Right now this is only exposed to RNTester on iOS, but the prop exists on both platforms.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D57281892
fbshipit-source-id: 9effc2b9c6421f8c74a2f4b933ab0fa0f15e7d70
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44540
Noticed when running `arc nn`
> Advice xplat/js/react-native-github/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/fabric/mounting/mountitems/IntBufferBatchMountItem.java:39
> [Class has 0 issues and can be marked Nullsafe] Congrats! `IntBufferBatchMountItem` is free of nullability issues. Mark it `Nullsafe(Nullsafe.Mode.LOCAL)` to prevent regressions.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D57249958
fbshipit-source-id: d38559a3fafae0ad778c19dd85c5da610a650d7c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44557
We've started seeing assertion failures in Yoga where a `NaN` value makes its way to an `availableHeight` constraint when measuring Litho tree.
Because it's only happening on Litho, I have some suspicion this might be originating from a Litho-specific measure function. This adds sanitization in Yoga to measure function results, where we will log an error, and set size to zero, if either dimension ends up being negative of `NaN`.
This doesn't really help track down where the error was happening, but Yoga doesn't have great context to show this to begin with. If we see this is issue, next steps would be Litho internal intrumentation to find culprit.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D57285584
fbshipit-source-id: 935fcdd28c05bbac0d73e1c7654ae11a74898537
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44562
D56963463 deleted some tests for code it also deleted. This broke the Android GTest OSS build, which is a centralized list of these test files. Remove from there as well.
Changelog: [Internal]
Reviewed By: joevilches, realsoelynn
Differential Revision: D57299969
fbshipit-source-id: 1bf0b718ca5fcee03272dd0142f80ea2f8257902
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44464
Adds `app` to allow building and serving your React Native app in a similar structure to the boostrap and build tasks. This is the more comprehensive followup to D57067040.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D57067039
fbshipit-source-id: fdbe891657d826535cb779a4d1b71cfd13921684
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44462
Users using the new `react-native/scripts/cocoapods/autolinking.rb` script will expect all of the helper methods previously exposed throug `react_native_pods.rb`.
This was an oversight.
Changelog: [iOS][Fixed] exposes react_native_pods methods through autolinking.rb
Reviewed By: cipolleschi
Differential Revision: D57066094
fbshipit-source-id: d65dc79430101c9c43cbd90d1456630e338a22bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44463
Helper methods to help the cli grab system state, devices and run react-native/core-cli-utils tasks using Listr.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D57067037
fbshipit-source-id: 28cb4239f3a93558b88417f366a2146f696cc411
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44466
Contains a *light* wrapper to help launch Metro and build bundles or wait for localhost requests against Metro's dev-server.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D57067040
fbshipit-source-id: 8ab7ecb5d9b98d1abddd5d4f04c7eb25129cd0a1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44512
We only ever go through MapBuffer now, so we can remove the code related to storing text fragments in folly::dynamic.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D56963463
fbshipit-source-id: 98bce8aa4ccad134ce18bf35028e1b7b5082c3ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44529
The percentage formula was incorrect. We actually want to consider the shorter side as 100%. If we set a radius > minimum side there are no changes reflected. This is correct on iOS.
D56943825's summary also highlights the reasoning.
Changelog:
[Android][Fixed] Border-Radius percentages are now correctly resolved.
Reviewed By: NickGerleman
Differential Revision: D57214561
fbshipit-source-id: 45125b80289506a6dd51d24451e2b0222cd227c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44542
React Native no longer has a `Navigator` component, so let's clean up this reference in a comment in the `StatusBar` component definition.
Changelog:
[General][Changed] - Obsolete comments referencing Navigator
Reviewed By: GijsWeterings
Differential Revision: D57251899
fbshipit-source-id: bf2923bcaf22daf525381efbc3577c3610afaec4
Summary:
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/44524
After D56845572, I've started seeing the following redbox when running apps in bridgless mode:
{F1633641432}
Note sure this is the correct/complete fix but, after this, the error seems to go away.
Reviewed By: RSNara
Differential Revision: D57207925
fbshipit-source-id: c02b9b268c135aabaaa1dc8329abc80ca5c8a500
Summary:
Though the `ReactHost.destroy()` is not being used from OSS code, we use it at Expo for expo-dev-client to change loading apps from different dev servers. Without cleanup the `mAttachedSurfaces`, it will have dangling or duplicated attached surfaces that cause duplicated react trees.
<img src="https://github.com/facebook/react-native/assets/46429/f84d274e-aaad-4352-9e3c-6262571a5625">
This PR tries to cleanup the `mAttachedSurfaces` from destroying.
## Changelog:
[ANDROID] [FIXED] - Fixed dangling `mAttachedSurfaces` after `ReactHost.destroy()`
Pull Request resolved: https://github.com/facebook/react-native/pull/44393
Test Plan: have to manually call `ReactHost.destroy()` and recreate the MainActivity without killing the process. then reload the app will startSurface for the same attached surfaces.
Reviewed By: RSNara
Differential Revision: D56901863
Pulled By: javache
fbshipit-source-id: c7f822501d971810ac6aa7262b15da69ec41355e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44470
CSS component values, as defined in the syntax spec, are either "preserved tokens", CSS functions, or simple blocks. This is distinct from the higher-level "component value type" specified in the [values and units](https://www.w3.org/TR/css-values-3/#component-types) spec.
I was previously short-circuiting a bit, from preserved tokens, to a higher level data structure. This separates them out, adding a layer exposing the preserved token as `CSSSyntaxParser::Token`, and now a `CSSSyntaxParser::Function`, which can represent a named function and its nested component values.
This does not yet wire functions beyond CSSParser returned component values.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D57089275
fbshipit-source-id: 97eeb1a7b3363c79d99f9419ba6e022c4c3c31d0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44521
changelog: [internal]
mapbuffer leaks into every component even though it is only used by 2: Paragraph and TextInput. Let's isolate it only to those two.
To do that, I added a new template prop: usesMapBufferForStateData. It is false by default and only Paragraph and TextInput set it to true.
Reviewed By: christophpurrer
Differential Revision: D56636011
fbshipit-source-id: 4a99e6e68caaf40111b6b7b205854a71f33c5864
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44493
Just keeping our version of AGP up to date.
Changelog:
[Internal] [Changed] - Bump AGP to 8.4.0
Reviewed By: arushikesarwani94
Differential Revision: D57104079
fbshipit-source-id: 4d5c0dec95bf73696a0274f61e0536e53c11adaf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44528
Changelog: [internal]
In the `IntersectionObserver` API we dispatch the initial notification in the `observe` method, but it might be possible that the surface has been removed from the registry by the time we execute that code.
This guards against that case to possibly fix a crash we're seeing in on the `IntersectionObserver` experiments.
Reviewed By: sammy-SC
Differential Revision: D57213994
fbshipit-source-id: 5cd1f16958949cc1ff64153e8012e6a59819d68a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44513
The removed code was moved to LogBoxInspectorContainer, and is not referenced inside the LogBoxStateSubscription component.
## Changelog
[Internal]
Reviewed By: GijsWeterings
Differential Revision: D57168569
fbshipit-source-id: 07f843b2df126cc05f65937dd44781525d6afeb4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44525
These examples were added, but their names were duplicated. This caused our internal e2e tests to accidentally target the wrong examples.
Changelog:
[General][Fixed] RNTester examples for border percentages are now properly covered by E2E screenshot tests.
Reviewed By: NickGerleman
Differential Revision: D57207306
fbshipit-source-id: 32ed5cc6b136a8928b11afe8b824c752edcdd9e5
Summary:
Tweaks the Paused Debugger Overlay design on iOS. The tap area to resume the application is now the entire "Paused in debugger" item.
|Before|After|
| {F1578785144} | {F1578734918} |
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D57161216
fbshipit-source-id: 581ebe44e45a57cdfe3e617e8f97f78619f84e73
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44516
# Changelog:
[Internal] -
This is a generally cross-platform attribute, which is supported not only on Android, and conceptually does arguably belong in TextAttributes.
Reviewed By: NickGerleman
Differential Revision: D57181633
fbshipit-source-id: 7251f0a90158f0466fbf13b9d855c7a449e6dd0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44518
# Changelog:
[Internal] -
For some inexplicable reason, we had majority of `Text` test examples (42 out of 46) in RNTester stuffed into `<RNTesterBlock/>` components inside one huge "Basic" test case.
This was highly imbalanced, introduced extra nesting, cluttering the UI, but most importantly, none of those 42 out 46 test cases were searchable for.
This change flattens all of the corresponding nested test cases to the top level, making them into valid separate test cases, which are also searchable.
It also corresponds to the general structure we have in other test examples, such as `TextInput`.
Reviewed By: cipolleschi
Differential Revision: D57197676
fbshipit-source-id: 777eb2aa238a91bb3f52d2f0ab10edc6bfad5c85
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44479
TextInputs' onTextInput callback was removed way back in React Native 0.62 with https://github.com/facebook/react-native/commit/3f7e0a2c9601fc186f25bfd794cd0008ac3983ab , but remnants of the implementation exists.
We first have to remove the event emitting in native code, and can land the full removal separately in D57092733, once there's no older client references remaining to this event.
Changelog: [General][Removed] Remove deprecated onTextInput callback
Reviewed By: cipolleschi
Differential Revision: D57092734
fbshipit-source-id: 5b0beee3d55b70717216fe8ceaf52444540f5adc
Summary:
The new cocoapod post install script includes aggregation and generation of privacy manifests for iOS, which is great. However, the script doesn't consider the case where the file reference doesn't have a path.
Example, for a project setup like the screenshot:
<img width="249" alt="image" src="https://github.com/facebook/react-native/assets/22592111/45dd1cf4-c2f6-4abb-940f-136a4d502966">
The code
https://github.com/facebook/react-native/blob/05a4232dd591e2d43f192d69ca14a04f4a3fb6a1/packages/react-native/scripts/cocoapods/privacy_manifest_utils.rb#L80-L81
prints `file_refs`:
```
[
<PBXFileReference name=`LaunchScreen.storyboard` path=`learnX/LaunchScreen.storyboard` UUID=`81AB9BB72411601600AC10FF`>,
<PBXVariantGroup name=`InfoPlist.strings` UUID=`D40B9F832B248EF5004BC08C`>,
<PBXFileReference path=`AppCenter-Config.plist` UUID=`D40B9F802B248EC2004BC08C`>,
<PBXFileReference name=`PrivacyInfo.xcprivacy` path=`learnX/PrivacyInfo.xcprivacy` UUID=`D403DD362BCA2BCF00E5295C`>,
<PBXFileReference name=`Assets.xcassets` path=`learnX/Assets.xcassets` UUID=`D40B9F652B248AEB004BC08C`>
]
```
where a `PBXVariantGroup` exists and it doesn't have `path`. The error `undefined method 'end_with?' for nil` occurs as a result.
## 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] - In privacy manifest post install script, handle the case where the file reference doesn't have a path
Pull Request resolved: https://github.com/facebook/react-native/pull/44410
Test Plan:
1. Add a new "Strings File (Legacy)" in Xcode to the project.
2. Run `pod install` for iOS.
3. See the error `undefined method 'end_with?' for nil`.
4. Apply the fix and rerun `pod install`.
5. The script runs successfully.
Reviewed By: javache
Differential Revision: D57056159
Pulled By: cipolleschi
fbshipit-source-id: 42caaf1a98efb9111f6ff1014a5c8b7703b042f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44517
# Changelog:
[Internal] -
A follow-up to https://github.com/facebook/react-native/pull/44505, turns out this is also an issue for TextInput examples, which work of assumption of some of the text input fields being of limited width, but in practice growing to occupy the parent window width, which can be quite large on platforms different from the classic mobile ones.
This diff makes the corresponding tests more practical, not expanding to the parent window anymore.
Reviewed By: christophpurrer
Differential Revision: D57196308
fbshipit-source-id: 7018e8c51adb70fe6a03e50d71eff9ba997fd07a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44515
this has been the default for a while
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D57195561
fbshipit-source-id: b441d972134dba754d714ae5694d94537707ded3
Summary:
Root cause of the fetch memory leak:
The fetch requests store its result inside Blob which memory is managed by BlobCollector. On the JS engine side,
the Blob is represented by an ID as JS string, and the GC don't know the size of the blob. So GC won't have interests to release the Blob.
Fix:
On iOS and Android, use `setExternalMemoryPressure` to acknowledge JS engine the size of Blob it holds.
## Changelog:
[GENERAL] [FIXED] - fix fetch memory leak
Pull Request resolved: https://github.com/facebook/react-native/pull/44336
Test Plan: `RepeatedlyFetch` inside `XHR` example
Reviewed By: javache
Differential Revision: D57145270
Pulled By: NickGerleman
fbshipit-source-id: afa53540e8563db4f9c6657f2dbbdff7bdfa66c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44429
`Transform::Rotation(x, y, z)` creates an empty transform with the associated operation, then [multiplies by xyz rotation vectors](https://en.wikipedia.org/wiki/Rotation_matrix#General_3D_rotations).
Multiplication chains each transform operation, so afterward, we end up with correct transform matrix, but duplicate operations.
This removes the first transform operation, and lets the per-axis multiplications set them.
Changelog:
[General][Fixed] - Fix duplicate rotation operations
Reviewed By: rshest
Differential Revision: D57025602
fbshipit-source-id: 5eb47dbf9a72eab89a351fd5ae02261566b35ffb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44471
Need to make the current headers a bit more granular to avoid cyclical dependencies, and a lot of bloat.
This code isn't wired up more broadly, so this isn't breaking yet.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D57089140
fbshipit-source-id: f6e0312c207664b0a59f682c673cd00e263915bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44450
Adding some of the tokenization needed for things like `transform` and `filter`. Parsing will be a bit trickier with the model currently built up.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D57047886
fbshipit-source-id: 260a681ab60944c8f127d937589fc4c8589a53e2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44435
Every CSS prop at this sparse stage is represented as an enum, and each enum can be specialized to different types, according to the global CSS property table.
With this change, we add a string name to each property table entry that we use to generate a function to be able to set CSS value strings, against property name strings. Like `declaredStyle.set("aspectRatio", "4 / 3")`.
I was considering specializing this a bit, to allow DeclaredStyles which only support a subset of CSS props. E.g. so `ParagraphShadowNode` has a more derived declared style than `LayoutableShadowNode` does. But, I am not sure the best way yet to make that compose nicely.
Changelog: [internal]
Reviewed By: sammy-SC, rshest
Differential Revision: D57039255
fbshipit-source-id: c5289254bb97fa355af5f416b79952e426720934
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44505
# Changelog:
[Internal] -
The RNTester/Text tests, that are related to text wrapping (such as "wrap mode", "hyphenation", "ellipsize", "numberOfLines" ones) were written with the mobile form factor in mind, whereas the RNTester window is generally expected to be narrow and tall.
Now, that we are running on other platforms as well, there is no guarantee about the RNTester window width, in general, so these tests relying on particular window width is not practical anymore.
This makes the corresponding tests work in a useful way without making assumptions about the RNTester's window width.
Differential Revision: D57166025
fbshipit-source-id: 3305a31f7ca254d82c85d67c975c1140050adc28
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44500
tsia really, added tests for blur, brightness, and chained brightness + blur. I don't really think I need to add them all, as e2e tests can be flaky and I doubt someone changes specific color matrix values ever.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D57127765
fbshipit-source-id: 7644c9493eee176e24922f7c06656360340e00d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44408
Why?
Previously we didn't support using percentages like:
```
style={{
width=100,
height=100,
borderRadius='100%',
}}
```
These percentages refer to the corresponding dimension of the border box.
What?
- Added LengthPercentage class and LengthPercentageType enum. To track when we are dealing with percentage vs points
- Now radius properties start as Dynamic which then get transformed into LengthPercentage.
- Modified certain function parameters so we can consider height and width when resolving BorderRadius values
With this we conditionally calculate the corresponding point (dp) value for a given percentage (considering size). Ex:
```
result = {raw_percentage_value} / 100 * (max(height, width))
```
We know the maximum border radius for our current implementation is half the dp of the shorter side of our view, hence why we consider half our maximum view side as equivalent to 100%.
Note: We still don't support vertical/horizontal border radii
## Changelog:
[Android][Added] - Added support for using percentages when defining border radius related properties.
Reviewed By: NickGerleman
Differential Revision: D56943825
fbshipit-source-id: 3e5a9933ca90e499aff9c7d2561f5f6bb55157da
Summary:
## Summary
Sets up dynamic feature flags for `disableStringRefs`, `enableFastJSX`,
and `enableRefAsProp` in React Native (at Meta).
## How did you test this change?
```
$ yarn test
$ yarn flow fabric
```
DiffTrain build for commit https://github.com/facebook/react/commit/9b1300209eb00a2d6c645fddf6d2729d67d7b10a.
Reviewed By: kassens
Differential Revision: D57026752
Pulled By: yungsters
fbshipit-source-id: 18b2112fce1671bb83f281b1e036991fa7d6d4ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44499
Changelog: [internal]
As [discussed](https://fb.workplace.com/groups/react.devx.team/permalink/930483712103526/), we'll begin segmenting Telemetry signals by Fusebox/non-Fusebox.
* Add new flag in event reporter for `debugger_command` (other events in subsequent diffs)
* Add new column to the Scuba destination
Reviewed By: blakef
Differential Revision: D57140479
fbshipit-source-id: 7ea813b1b4d53a282873fa95c8ee82e5d6f3d1d3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44498
Changelog: [internal]
Quick refactor to reduce commit noise in the following diff in the stack
Reviewed By: blakef
Differential Revision: D57140480
fbshipit-source-id: aa1fef83d5347b8a11651d3d5c4112b4adf7a7d5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44476
# Changelog:
[Internal] -
This is the last step to converting the whole `modules.debug` module to Kotlin.
Reviewed By: christophpurrer
Differential Revision: D57095966
fbshipit-source-id: 3fcb52528674565a4a2b5c306262e0af11a19e6e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44475
# Changelog:
[Internal] -
As the title says, this is preparing to complete the conversion of the whole corresponding module to Kotlin.
Reviewed By: christophpurrer
Differential Revision: D57095896
fbshipit-source-id: 87fe08aec974f5f1327189d0e74c3782c4391e85
Summary:
This pull request fixes an issue where the `selectionColor` prop was not applied to the `TextInput` component on iOS, starting from React Native version 0.74.x.
This issue was introduced in PR [1e68e485](https://github.com/facebook/react-native/commit/1e68e48534aedf1533327bf65f26e5cf5b80127b#diff-b6634353ea5b10a91de24605dc51bdfb50e8ddb652ccd5b9dab194168a69d4b1) which relocated `selectionColor` along with `selectionHandleColor` and `cursorColor` out of `otherProps`. This modification inadvertently prevented `selectionColor` from being passed to the iOS native component.
This change ensures that the `selectionColor` prop is explicitly included in the `RCTTextInputView` component's properties, fixing the regression.
Note: `selectionHandleColor` and `cursorColor` are Android-specific and do not require explicit passing on iOS.
## 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] - Fixed an issue where the `selectionColor` prop was not being applied on the `TextInput` component.
Pull Request resolved: https://github.com/facebook/react-native/pull/44420
Test Plan:
**Environment:** iOS Simulator, React Native 0.74.0.
**Steps to reproduce:**
- Implement a `TextInput` component with the `selectionColor` prop set.
- Run the application on an iOS device or simulator.
- Focus on the TextInput component, write some text and select it.
**Expected Result:** the selection color should match the color provided to the `selectionColor` prop.
**Actual result before fix:** the selection color did not reflect the specified `selectionColor` prop and fell back to the default iOS selection color (blue).
**Screenshots:**
- Before fix:
<img width="1710" alt="before_fix" src="https://github.com/facebook/react-native/assets/17989553/8660068c-55c9-4f55-a788-f96eb681fb70">
- After fix:
<img width="1710" alt="after_fix" src="https://github.com/facebook/react-native/assets/17989553/93c9eb26-7da0-4957-b54f-8444aff7e374">
Reviewed By: javache
Differential Revision: D57017836
Pulled By: NickGerleman
fbshipit-source-id: 263ce22168e09c15cdfdb4eb4300a2605d8af032
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44319
The files were identical so no need for both. Having both is error-prone as one may be modified without modifying the other.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D56659179
fbshipit-source-id: e5f414f0c4a00c126d301a7fcd26eeb17d74a56c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44491
Changelog: [internal]
Ensure only one scroll event is fired per frame by tracking the events in FabricUIManager
Reviewed By: sammy-SC
Differential Revision: D57018741
fbshipit-source-id: c1ad59f934e359edfeb8f3e084106eebd467a0b1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44489
Changelog: [internal]
Integrate a synchronous event API to trigger synchronous scroll events in Android. The API will be changed in the future, this is exposed only for experimentation.
Reviewed By: sammy-SC
Differential Revision: D56886403
fbshipit-source-id: 337277c735c0943ce4ba29bb2d646a72fe101ede
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44451
Changelog: [internal]
Exposing the experimental API EventEmitter::experimental_flushSync to trigger synchronous events from Android. The API will be changed in the future, this is exposed only for experimentation.
Reviewed By: NickGerleman
Differential Revision: D56886402
fbshipit-source-id: 7b71cd489e3bb65dffcfb53fef2ea7cafbb973f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44458
This is the JS plumbing to get it so that views can now use filters. The typing looks like
`filter: [{brightness: 1.5}, {hueRotate: '90deg'}]`
which is different than web which would look like `filter: brightness(1.5) hue-rotate(90deg)`. I feel like the web version is overly complicated and not very *react native-y*. Transform uses the array based approach (albeit they also accept a string). Open to changing this but really feel like the web format is silly and bad since it would just involve parsing some arbitrary string.
The diff includes:
* Style sheet changes so typing is valid
* Process function to turn filter format into {name: string, amount: string}
* Test for process function
* View config changes on Android, iOS and ReactNativeStyleAttributes
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D56845572
fbshipit-source-id: 5029b5adac29bb863c89f6c699d5693c58cad711
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44457
Most filters are not going to work on iOS. It is a long story but essentially there is not a good way to continuously get a snapshot of the view and its descendants to filter.
We can, however, implement `brightness` using `compositingFilter` and blend mode. This is really not documented at all, but if you assign a string representing the blend mode to the [`compositingFilter`](https://developer.apple.com/documentation/quartzcore/calayer/1410748-compositingfilter?language=objc) property on CALayer, it will actually work. The filter we use is [`multiplyBlendMode`](https://developer.apple.com/library/archive/documentation/GraphicsImaging/Reference/CoreImageFilterReference/index.html#//apple_ref/doc/filter/ci/CIMultiplyBlendMode). As the title suggests this just multiplies the two layers. We can apply this to a `_filterLayer` and set its background color to the brightness amount to get the desired results. Most other color filters either operate on the color components dependently (e.g. new red component depends the value in blue and green), or they have addition operations. We can do addition with `linearDodgeBlendMode`, but the order of operations does not work (we multiply, clamp, then add vs. multiply, add, then clamp).
`opacity` is just a multiplier on the CALayer `opacity` property.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D56447175
fbshipit-source-id: 6705673dd9dec9fc3ec89e49b583523eec1028b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44455
Title says it all. Right now this ignores drop-shadow as that will be implemented later. Some of this code will need to be adjusted as it is the one filter that takes multiple amounts. But I feel that can be amended later when we get there - after all the `amount` parsing code is just casting to a float at the moment, so we are not locking ourselves into anything.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D54640629
fbshipit-source-id: c8e1206ab46accab3c99614241b8bd9aa252e12c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44453
This works similar to how `transform` is parsed in that it sets tags on the View to actually update the prop when all the prop setters are done being called since the parsing of the array is not very trivial. Besides that it is pretty simple and just calls into `FilterHelper` and uses `setRenderEffect`: https://developer.android.com/reference/android/view/View#setRenderEffect(android.graphics.RenderEffect).
That API is only exposed in version 31 of the SDK so it is gated accordingly.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D54640600
fbshipit-source-id: ad4cde2bed9611f476f4ecb2550c2269965d7917
Summary:
In this pr, I updated the deprecated babel-plugins with their new library. When you enter the npm page of the relevant plugins, it is recommended to implement new packages instead of the deprecated package.
For example :
<img width="1305" alt="Screenshot 2024-05-05 at 17 50 16" src="https://github.com/facebook/react-native/assets/113903710/a58fdac3-79db-4b53-98bd-4c5325a1e560">
## Motivation:
We use the react-native package in our project and aim to upgrade pnpm to the latest version. First, we wanted to clear deprecated warnings. Babel plugin deprecated warnings were caused by the react-native package, so I created this pull request.
Deprecation Warnings from package installing :
<img width="581" alt="Screenshot 2024-05-05 at 17 53 05" src="https://github.com/facebook/react-native/assets/113903710/9c5859a5-f194-43ab-ae35-417dfaacebab">
## Changelog:
[GENERAL][FIXED] - Replace deprecated babel-plugin libraries to fix deprecation warnings on installation
Pull Request resolved: https://github.com/facebook/react-native/pull/44416
Test Plan: CI should pass
Reviewed By: huntie
Differential Revision: D57056843
Pulled By: robhogan
fbshipit-source-id: b75b329bbc2105c31da85e861ef71ffdcbbb0623
Summary:
Changelog: [internal]
This is a new attempt at fixing mounting errors during synchronous state updates after what we tried in https://github.com/facebook/react-native/pull/44015.
That fix didn't work because `dispatchMountItems` actually makes a copy of the mount items that it's going to process, so when we added the mount items to the list they were actually not being picked up by the current processing.
This changes the fix to call `dispatchMountItems` as many times as needed, while there are mount items to process in the list.
Reviewed By: sammy-SC
Differential Revision: D57107212
fbshipit-source-id: 46988a71daae15d70399258f850653046d0790ff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44445
The `ReactNativeInternalFeatureFlagsMock` module is not references in the open source repository, so there's no reason it should exist there. This cleans that up.
Changelog:
[Internal]
Reviewed By: kassens
Differential Revision: D57052284
fbshipit-source-id: d220eae2ba76f20ed48742779fbffd5de1f77529
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44444
Changelog: [Internal] - Request bundles with `excludeSource=true` and `sourcePaths=url-server`.
Changes RN's bundle client to request more efficient source maps from Metro by relying on lazy-fetching of source contents.
NOTE: Requires a Metro version with D56952064 and D56952063 (not yet released on npm) to work properly.
Reviewed By: robhogan
Differential Revision: D56952065
fbshipit-source-id: 0ed083ecc64adbd7acf209bb9abd40db24ffc86b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44461
Users would have to do this by manipulating the environment before.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D57067036
fbshipit-source-id: 6df16c884412578c3b5cae50e26ca37636a7dc5b
Summary:
Minor inconvenience I noticed while doing some testing in a mono-repo.
The current paths points to the android folder, but should point to the project root. Currently the android build fails if one uncomments the folder paths as they are.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID] [FIXED] - Fix incorrect paths in app build.gradle react config block
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID] [FIXED] - Fix incorrect paths in app build.gradle react config block
Pull Request resolved: https://github.com/facebook/react-native/pull/44472
Test Plan:
Uncomment the paths are they are and notice the android build error:
```
FAILURE: Build failed with an exception.
* What went wrong:
A problem occurred configuring project ':app'.
> Failed to notify project evaluation listener.
> /xyz/xyz/xyz/xyz/RNPathTester/android/node_modules/react-native/ReactAndroid/gradle.properties (No such file or directory)
```
Use the updated paths and notice the build succeeds 🥳
Reviewed By: GijsWeterings
Differential Revision: D57093768
Pulled By: cipolleschi
fbshipit-source-id: 8472151c74c7aa5c51dc75f9adda6116387bdf99
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44436
The backing buffer behind `ReadableMapBuffer` is effectively immutable, so we can make reads of nested MapBuffers work on an inline view of the same buffer. This book-keeping is kept within ReadableMapBuffer (we can not user `ByteBuffer.wrap()` because the fbjni produces ByteBuffer is not array backed).
The main downside I can think of is that the whole buffer is kept in memory until all children buffers leave, but current use-cases don't involve long-term storage of MapBuffer children, so this is probably a better tradeoff.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D57020759
fbshipit-source-id: d2f5a76561fa4a4219fe5022ba62cc96f56ce022
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44398
**Problem:**
`selection` prop is not being set on component creation.
Not quite sure which RN version this issue was introduced but fixing it on latest code.
Use playground for testing (refer to following diff)
**Proposed Solution:**
Added notes in comments but `viewCommands.setTextAndSelection()` is called only on text or selection update which relies on comparing data with `lastNativeSelection`. Problem is that `lastNativeSelection` is initially set to the props value that is passed in so does not send the command on component creation.
So assign a default selection value of `{start: -1, end: -1}` so it can be set on component creation.
**Changelog:**
[General][Fixed] - `selection` prop in `TextInput` was not being applied at component creation
Reviewed By: cipolleschi
Differential Revision: D56911712
fbshipit-source-id: 7774b246383f85216536040688b0a8ea85b3478a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44432
Implements a bit more of the tokenizer algorithm, to correctly support dimensions like `.25turn` instead of just `0.25turn`.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D57033796
fbshipit-source-id: 6d73de22e3a0f0ca0de432be56bca97f0069ad96
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44431
Turn `expectTokens()` function into a macro so that GTest assertion macros point to the right line numbers.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D57034303
fbshipit-source-id: f6d18c0d2420e50c75b61a57489e9ddc12653fb6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44430
Let's add support for angles so we can correctly represent things like rotation/skew transforms or hue-rotate filter. This should replace `ValueUnit` in prop related transform code.
A couple implementation notes:
1. RN currently uses radians internally, but CSS says the cannonical angle unit is degrees, so we keep to that
2. We have all the information to convert to cannonical value type at parsing layer, so we do that, and clients can only see degreee values instead of units. Less flexible, but simpler/more efficient for now, where higher levels don't care.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D57029378
fbshipit-source-id: 91341f1bf4686d9016823ac8cf91897e933345f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44427
We only need the default module implementation headers in the C++ file. These were added to the header file for the default module helper by mistake.
## Changelog
[Internal]
Reviewed By: NickGerleman
Differential Revision: D57003838
fbshipit-source-id: d37ebd247eaa2c0cb05ebc6c666a585e6352646d
Summary:
After upgrading my app from React Native 0.74.0 to 0.74.1, iOS builds were failing due to the privacy manifest ruby script failing due to what seemed to be a missing nil check.
```
[Privacy Manifest Aggregation] Appending aggregated reasons to existing PrivacyInfo.xcprivacy file.
[Privacy Manifest Aggregation] Reading .xcprivacy files to aggregate all used Required Reason APIs.
[!] An error occurred while processing the post-install hook of the Podfile.
no implicit conversion of nil into Array
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:115:in `+'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:115:in `block (5 levels) in get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:111:in `each'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:111:in `block (4 levels) in get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:106:in `each'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:106:in `block (3 levels) in get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:105:in `each'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:105:in `block (2 levels) in get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:104:in `each'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:104:in `block in get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:102:in `each'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:102:in `get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:18:in `add_aggregated_privacy_manifest'
node_modules/react-native/scripts/react_native_pods.rb:301:in `react_native_post_install'
ios/Podfile:38:in `block (3 levels) in from_ruby'
vendor/bundle/ruby/3.3.0/gems/cocoapods-core-1.15.2/lib/cocoapods-core/podfile.rb:196:in `post_install!'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:1013:in `run_podfile_post_install_hook'
vendor/bundle/ruby/3.3.0/gems/cocoapods-pod-sign-1.3.0/lib/cocoapods-pod-sign/pod_installer.rb:45:in `run_podfile_post_install_hook'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:1001:in `block in run_podfile_post_install_hooks'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/user_interface.rb:149:in `message'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:1000:in `run_podfile_post_install_hooks'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:337:in `block (2 levels) in create_and_save_projects'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer/xcode/pods_project_generator/pods_project_writer.rb:61:in `write!'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:336:in `block in create_and_save_projects'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/user_interface.rb:64:in `section'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:315:in `create_and_save_projects'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:307:in `generate_pods_project'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:183:in `integrate'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:170:in `install!'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/command/update.rb:63:in `run'
vendor/bundle/ruby/3.3.0/gems/claide-1.1.0/lib/claide/command.rb:334:in `run'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/command.rb:52:in `run'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/bin/pod:55:in `<top (required)>'
vendor/bundle/ruby/3.3.0/bin/pod:25:in `load'
vendor/bundle/ruby/3.3.0/bin/pod:25:in `<top (required)>'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/cli/exec.rb:58:in `load'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/cli/exec.rb:58:in `kernel_load'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/cli/exec.rb:23:in `run'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/cli.rb:451:in `exec'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/vendor/thor/lib/thor/command.rb:28:in `run'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/vendor/thor/lib/thor.rb:527:in `dispatch'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/cli.rb:34:in `dispatch'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/vendor/thor/lib/thor/base.rb:584:in `start'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/cli.rb:28:in `start'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/exe/bundle:28:in `block in <top (required)>'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/friendly_errors.rb:117:in `with_friendly_errors'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/exe/bundle:20:in `<top (required)>'
/Users/swrobel/.gem/ruby/3.3.1/bin/bundle:25:in `load'
/Users/swrobel/.gem/ruby/3.3.1/bin/bundle:25:in `<main>'
```
Adding some good old `puts` debugging to this file indicated that the problem was that an invalid manifest file was being generated for react-native-image-crop-picker, which I don't understand, because it [doesn't currently have a Privacy Manifest](https://github.com/ivpusic/react-native-image-crop-picker/issues/2040).
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>NSPrivacyTracking</key>
<false/>
<key>NSPrivacyTrackingDomains</key>
<array/>
<key>NSPrivacyCollectedDataTypes</key>
<array/>
<key>NSPrivacyAccessedAPITypes</key>
<array>
<dict/>
</array>
</dict>
</plist>
```
It seems there may be some upstream issue in whatever tool generates these missing privacy manifests, but that seemed beyond the scope of a simple nil check.
## Changelog:
[iOS] [FIXED] - Privacy Manifest aggregation failing due to missing nil check
Pull Request resolved: https://github.com/facebook/react-native/pull/44400
Test Plan: Build completes successfully after making this change.
Reviewed By: cipolleschi
Differential Revision: D56921303
Pulled By: philIip
fbshipit-source-id: 1b6b10b05d403bf71f78f5b80543a2d82f043e23
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44439
Changelog: [internal]
(IntersectionObserver isn't enabled yet in OSS).
This fixes a bug in `IntersectionObserver` when observing the same target in multiple observers. In that case, the first time we `unobserve` we clean up some metadata that's shared across observers, and other observers observing the target have problems with the missing data.
This fixes the problem by removing the clean up, as the data structure backing this information is a `WeakMap` anyway, so it'll be cleaned up automatically eventually, and the stored data is very small.
Reviewed By: twobassdrum
Differential Revision: D57046864
fbshipit-source-id: b001cf1ae4f4c91b74b1ad487e01691d5f3be1ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44440
# Changelog:
[Internal] -
As in the title, note that there are more files there to migrate, will come separately, to make reviewing easier.
Reviewed By: javache
Differential Revision: D57046953
fbshipit-source-id: e45316da1ed9caaa4daafa96dfabfd374926bd73
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44394
Lint fix - flip to a guaranteed non-null value instead of the nullable field
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D56898951
fbshipit-source-id: 8740ed77d71a827c7ce80b2df941d24985339619
Summary:
TextInputs' `onTextInput` callback was removed way back in React Native 0.62 with https://github.com/facebook/react-native/commit/3f7e0a2c9601fc186f25bfd794cd0008ac3983ab , but remnants of the implementation exists. Let's just remove it altogether?
## Changelog:
[IOS] [REMOVED] - Remove deprecated onTextInput callback
Pull Request resolved: https://github.com/facebook/react-native/pull/44351
Test Plan: CI should pass
Reviewed By: NickGerleman
Differential Revision: D56804590
Pulled By: javache
fbshipit-source-id: 89101fa53cdc628a97ba176cf3deca691784bfdd
Summary:
Cocoapods regression is now fixed (been fixed for a while) but we forgot to remove the upper bound and explicit `activesupport` in Gemfile.
https://github.com/CocoaPods/CocoaPods/releases/tag/1.15.2
## Changelog:
[IOS] [CHANGED] - Update Gemfile in template
Pull Request resolved: https://github.com/facebook/react-native/pull/44434
Test Plan: Run `bundle install/update` should update cocoapods to the latest version and active support should work properly without any issues.
Reviewed By: blakef
Differential Revision: D57046638
Pulled By: cipolleschi
fbshipit-source-id: 9d8e716d4392d7bc5a1940b523e57d2193134f95
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44362
Packages that are built and directly run in the monorepo no longer need to worry about
conditionally registering themselves to transpile Flow -> JS at runtime. Our build step
strips this file now.
Changelog: [Internal] changes in published packages no longer require conditional calls to Babel register.
Reviewed By: huntie
Differential Revision: D56839521
fbshipit-source-id: 6bec706c639f1ab4138e0b790be8a07654333046
Summary:
https://github.com/facebook/react-native/commit/7af288e5 introduced a breaking change for whoever importing HermesExecutorFactory.h, because the `hermes/inspector-modern/chrome/HermesRuntimeTargetDelegate.h` is not a public header. Also the nested import is not ideal for CocoaPods or use_frameworks.
I think HermesRuntimeTargetDelegate could be an implementation detail that hide from header. This PR tries to turn the ownership declaration from std::optional to std::unique_ptr, so that we could hide the concrete type.
## Changelog:
[IOS] [FIXED] - Fixed `HermesExecutorFactory.h` build error when importing its private header
Pull Request resolved: https://github.com/facebook/react-native/pull/44423
Test Plan: should introduce no breaking change and ci passed
Reviewed By: cipolleschi
Differential Revision: D57041498
Pulled By: huntie
fbshipit-source-id: bfa10c7307458813d99c52313682dd62bea80f19
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44415
# Changelog:
[Internal] -
RNTester Image example used hardcoded `https://www.facebook.com/favicon.ico`, which has an uncommon ICO format, for no good reason aside of just this image being served from `facebook.com`.
This diff:
* Replaces the ICO image with a PNG one (which is still served from `facebook.com`
* Factors out all the multiple hardcoded paths into constants, so that it's easier to make such changes in the future
* Changes another image to something that is a bit better on the eyes when severely downscaled
Reviewed By: christophpurrer
Differential Revision: D56978929
fbshipit-source-id: c627d1671c8cb66e9a78f4382faa56e539b2f7b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44414
# Changelog:
[Internal] -
I noticed that "Image/Fade Duration" test in RNTester is practically useless, as at the moment one scrolls to the test, the fading is most probably had already ended.
This adds a "button" to refresh the image and be able to see the fading in again and again, if desired.
Reviewed By: christophpurrer
Differential Revision: D56978930
fbshipit-source-id: 02873b45600ad319b0b1077467f599dc1a54bee3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44413
## Changelog:
[Internal] -
As in the title, the corresponding module is migrated from Java to Kotlin.
Reviewed By: christophpurrer
Differential Revision: D56978931
fbshipit-source-id: e1e8f22ad9bd2f594bc7cf77c6344f8f23996bcc
Summary:
Followup to D56848799!
Created from CodeHub with https://fburl.com/edit-in-codehub
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D56935723
fbshipit-source-id: 859cd88c06a972b2fb44525eee075df7c701c83a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44381
Changelog: [Android][Added]
I am adding this API in favor of RCTRuntimeExecutor. CallInvoker is now preferred because after #43375, the CallInvoker has access to the jsi::Runtime. Since the community is using CallInvoker already for their async access use cases, CallInvoker is the preferred choice of RuntimeExecutor / RuntimeScheduler because of easier migration. Also, having a wrapper like CallInvoker will give us more flexibility in the future if we want to expand this API.
this will be forward compatible in the old architecture
Reviewed By: RSNara
Differential Revision: D56866817
fbshipit-source-id: 4096847c52559d9a49feb072a0385da6b64392d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44383
This diff allows the default fallback style to be grabbed from KeyWindow. Previously with the TraitCollections being passed in from overridden views it was not getting the accurate system fallback.
We need this for Twilight, which is adopting a Light/Dark mode toggle. Previously when setColorScheme was getting called it would modify overrideUserInterfaceStyle and that would serve as the "default fallback" for future setColorScheme calls. setColorScheme shouldn't be setting the defaults, it should be setting the user-session theme preference.
Changelog:
[Internal] [Changed] - Added option for treating the KeyWindows's userInterfaceStyle as the source of truth for the system's dark/light mode.
Differential Revision: D56868862
fbshipit-source-id: 229894947baed65ef15cece5bece120e8497462f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44409
This is kind of a mess.
D56800381 moved us away from code relying on legacy TextLayoutManager, under the assumption we weren't using the old one anymore. It turns out we were still using the legacy TextLayoutManager for the sole case of cached spannables, where we ask FabricUIManager to measure using non-mapbuffer path, and pass the cache key (no underlying attributedstring). After the diff, we call default VM measure function, which returns zero size. This specifically breaks measurements of uncontrolled TextInput components.
This updates that path to use the same TextLayoutManager as we use for everything else.
This model breaks some code which assumes the AttributedString is present, instead of just para attributes. The redundant calls to get fragments is expensive and already something on my radar to fix, but for now, we mostly just no-op, the same way the old TextLayoutManager did when fragments were not set. This needs a good cleanup.
Changelog:
[Android][Fixed] - Fix cached spannable measurement path
Reviewed By: javache
Differential Revision: D56963152
fbshipit-source-id: 6dc0e29f6b63d367be1ba0be82dfbc18c4654ab2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44376
Changelog: [Internal]
In order to make migration a little bit cleaner, I thought it would be nice to implement forward compatibility for RCTCallInvokerModule. This way, the consumer doesn't have to have branching logic when they try to retrieve the callInvoker in their code, and can remove a callsite to the bridge.
Reviewed By: RSNara
Differential Revision: D56807993
fbshipit-source-id: 6c9aa74db15e04b8ab632d230b3e525363a4d1ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44399
Improves the result of `mockComponent` in React Native's Jest environment so that it has an accurate `name` property.
This will be important when React enables deriving component stack locations via error stack frames.
Changelog:
[General][Changed] - `mockComponent` now also mocks `name`
Reviewed By: kassens
Differential Revision: D56914915
fbshipit-source-id: 1bea3e8773c56f70a89d2171c436f85178676373
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44380
* setInterval's second argument is optional, and defaults to 0
* setTimeout is spec'ed to return a positive integer.
There's also no need to use HostObjects here to represent the timer index, it just hurts performance and makes this code more complex for no clear reason.
Changelog: [General][Fixed] New architecture timer methods now return integers instead of an opaque object.
Reviewed By: RSNara
Differential Revision: D56863422
fbshipit-source-id: fd3e75303662d865083d01e2bfe8633bac151a0e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44385
The current core autolinking is failing if a dependency doesn't have an `android` block.
Instead we should filter out all the dependencies that don't have an `android` definition when generating code.
Fixes https://github.com/reactwg/react-native-releases/issues/276
Changelog:
[Internal] [Changed] - RNGP - Fix core Autolinking attemping to link dependencies without a `android` block
Reviewed By: blakef
Differential Revision: D56876267
fbshipit-source-id: 900b13bec697fceac50c994f277621a10e281410
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44377
Changelog: [iOS][Deprecated] deprecate RCTRuntimeExecutorModule
After we make CallInvoker available to native modules, we don't need this. Document it and mark it as deprecated.
Reviewed By: RSNara
Differential Revision: D56848799
fbshipit-source-id: 5628eef01a53bfd29d5b89c0398a938bdd87b0ac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44378
Changelog: [iOS][Added] introduce CallInvoker support in bridgeless native modules
I am adding this API in favor of RCTRuntimeExecutor. CallInvoker is now preferred because after #43375, the CallInvoker has access to the jsi::Runtime. Since the community is using CallInvoker already for their async access use cases, CallInvoker is the preferred choice of RuntimeExecutor / RuntimeScheduler because of easier migration. Also, having a wrapper like CallInvoker will give us more flexibility in the future if we want to expand this API.
Reviewed By: RSNara
Differential Revision: D56807994
fbshipit-source-id: 5c3585356d016a50645eda3af2d3bbe00298b4e4
Summary:
The motiviation of this change is to produce sorted / stable native module schemas which members are alphabetically sorted. The benefit is mainly for verifying test fixtures as now new test cases will be inserted at predicatable spots.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D56741776
fbshipit-source-id: 842af73cac3b4859d2074e6a5206015924e87201
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44379
A common pattern to implement `ViewManagerOnDemandReactPackage` is to use a `getViewManagersMap` helper. If we capture `ReactApplicationContext` there, we will indefinitely retain the the very first ReactApplicationContext, and break/leak across reloads. Instead we should pass the `ReactApplicationContext` whenever we construct the ViewManager.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D56838427
fbshipit-source-id: 76583dd7f5564ed29f0dbfcef33d8d288cbb90e0
Summary:
Clean this up, now that there is only one TextLayoutManager.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D56801446
fbshipit-source-id: 1b81a16031ab520d06d8935000d5019609f8a254
Summary:
No longer used after last diff.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D56801475
fbshipit-source-id: 45320418493cb47cc9df192de3dcc73284005fb4
Summary:
These are all either dead, or duplicate code (e.g. for spannable cache). Let's delete it, so we can get rid of the redundant TextLayoutManager that is no longer getting new updates.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D56800381
fbshipit-source-id: 264c2ede43b765ff094d3d3976ad8535579cc4d9
Summary:
This prop was introduced into horizontal <ScrollView/> in D35735978.
**Note:** This prop did not work for bridgeless mode.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D56854758
fbshipit-source-id: 2b25296a065b01f11aa04c2ff06cabf64ff5fce1
Summary:
This prop was introduced for horizontal and vertical scrollview in D40642469.
That diff updated the native view configs only.
**Note:** This prop did not work for bridgeless mode.
Partial fix: Add the prop to vertical scrollview: D54223244
Full fix: this diff.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D56854757
fbshipit-source-id: aff2da407f4df4575ceb66d3d381a144fa07a8e9
Summary:
The margin/padding props were introduced in this diff: D41267765
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D56846578
fbshipit-source-id: 396cab3fdd63d9c630690157a385f1ae53208bb7
Summary:
The insets props were introduced in this diff: D42193661
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D56849870
fbshipit-source-id: 7be2a5825086ac954fdb8bc3bb86b57a2fa6d326
Summary:
onClick was made into a capture event in this diff: D45745906
- Partial fix: D51551255
- Full fix: this diff.
**Note:** This prop did not work for bridgeless mode.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D56849867
fbshipit-source-id: 15acc16b162e0dd17513c6452008331e3fee4526
Summary:
As pointed out by liamjones here:
https://github.com/facebook/react-native/pull/44214#discussion_r1587755403
The original PR did introduce a bug in the `find/first` check, but in my testing, we do need to look at `group.name`, so let's make sure we check both.
This also makes it play nice with an existing file even if it is added to a different directory, by appending to it instead of forcing it to exist in the main group.
## Changelog:
[IOS] [FIXED] - Fix privacy aggregation
Pull Request resolved: https://github.com/facebook/react-native/pull/44390
Test Plan: Tested on rn-tester
Reviewed By: cipolleschi
Differential Revision: D56893594
Pulled By: philIip
fbshipit-source-id: b92589bc2bed9d07e9af20c56a8b9f6c61d864f0
Summary:
This is a major sync, featuring our recent rebase of `chromium/6344`.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D56884975
fbshipit-source-id: bc91f66bfc92464ab8fa99893ab0181077041b79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44339
We require the wrapper code for in repository calls to these packages directly from node (i.e. using CommonJS). This wrapper code typically sits at the entrypoint of the build packages (i.e. `index.js`).
NOTE: This unblocks an issue preventing me from landing further work on the `helloworld` cli replacing the community template.
## Problem:
The [flow-api-translator](https://www.npmjs.com/package/flow-api-translator) library doesn't allow CommonJS `module.exports` when generating TypeScript Type Defintions.
## Change
1. At the built time, this strips out our wrapper code and sets up the dist/ folder appropriately for npm distribution.
2. Updated the `package.json` files to consistently share Flow types
Changelog: [Internal] refactor build packages output to remove wrapper.
NOTE: Added better error messages when users deviated from the current pattern:
{F1501571608}
Reviewed By: huntie
Differential Revision: D56762162
fbshipit-source-id: f110b31e4ad780998dbc81a2482891ac8d8c6458
Summary:
In RELEASE mode, the `devSupportManager` received is ReleaseDevSupportManager for which `showDevOptionsDialog()` & `handleReloadJS()` is a no-op
https://github.com/facebook/react-native/blob/main/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/devsupport/ReleaseDevSupportManager.java
Which is expected since this is a capability only in Dev mode(useDeveloperSupport = true). However, ATM `shouldShowDevMenuOrReload()` returns true in RELEASE as well which is a bug.
Since there is no need for `shouldShowDevMenuOrReload()` in RELEASE, changing it's logic to introduce that check, early exit and return false in case of RELEASE.
Changelog:
[Android][Fixed] shouldShowDevMenuOrReload() in RELEASE mode
Reviewed By: RSNara
Differential Revision: D56851473
fbshipit-source-id: e9e12b0bec8aead5e9227fcd676459ca54490b61
Summary:
In RELEASE mode, the `devSupportManager` received is ReleaseDevSupportManager for which `showDevOptionsDialog()` is a no-op
https://github.com/facebook/react-native/blob/main/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/devsupport/ReleaseDevSupportManager.java#L66
Which is expected since this is a capability only in Dev mode(useDeveloperSupport = true). However, ATM `onKeyLongPresss()` returns true in RELEASE as well which is a bug.
Since there is no need for `onKeyLongPress()` in RELEASE, changing it's logic to introduce that check and return false in case of RELEASE.
Changelog:
[Android][Fixed] onKeyLongPress() in RELEASE mode
Reviewed By: christophpurrer, RSNara
Differential Revision: D56850466
fbshipit-source-id: 92d2c8572b32d065f5f9d54e22588bb085b9dcc9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44361
In order to keep all platforms in sync (Android, iOS, Windows, etc.), it makes sense to consolidate all C++ TurboModules that we want available by default on all platforms to a shared C++ header / implementation.
This moves the duplicated code from Android and iOS to such a shared module provider and updates relevant build specs.
## Changelog
[Internal]
Reviewed By: christophpurrer
Differential Revision: D56835783
fbshipit-source-id: 7322ed054ded5749973885c63257e5caf23b3fc3
Summary:
Changelog: [Internal]
A very similar diff was attempted with D50647971 and reverted in D51617862. The main difference here is all behavior is gated behind the feature flag. Before, we were enqueuing the extra frame callback on start_animating_node even if ondemand choreographer was disabled.
Reviewed By: javache
Differential Revision: D56085369
fbshipit-source-id: fa6335303fe98199b18fa2b4819110afb8efcc0d
Summary:
ViewManagers are all BaseJavaModule, and thus have access to methods like `getReactApplicationContext`. We don't expose the appropriate constructors though to pass this context down from the base class.
Not a breaking change, as the no-arg constructor is still used implicitly.
Changelog: [Android][Fixed] ViewManagers can pass context to their base class.
Reviewed By: fabriziocucci
Differential Revision: D56804318
fbshipit-source-id: b0e6b15dfd7786073da058beccfaba2ff30daf5a
Summary:
In a future release of React Native, string refs will no longer be supported. This increases the severity of the `no-string-refs` lint rule to convey this.
Changelog:
[General][Changed] - `no-string-refs` is now a lint error
Reviewed By: kassens
Differential Revision: D56826663
fbshipit-source-id: 603f5b205bb9fd8a5dcb8ee917f6a2ba1ac47e6e
Summary:
Changelog: [Internal]
Updates the doc comment on `Function::createFromHostFunction` to
mention that (a copy of) the provided `std::function` may be destroyed
on an arbitrary thread, much like `HostObject` (where this is already
documented).
Reviewed By: neildhar
Differential Revision: D56628194
fbshipit-source-id: 1939602135e83a9c36896c395816054376026edc
Summary:
This change removes a couple of method from RCTHost which were not following the iOS convention for names.
We deprecated them in 0.74 and now that the branch is cut, we can remove them.
## Changelog:
[iOS][Breaking] - Remove `getSurfacePresenter` and `getModuleRegistry` from RCTHost
Reviewed By: sammy-SC
Differential Revision: D56633554
fbshipit-source-id: 88fd1525bfe68ca1f6c2d8403d0dec505a23e9f8
Summary:
We [received an issue](https://github.com/react-native-maps/react-native-maps/issues/5042) in OSS where a ViewManager was configured to be initialized on the main queue, but it wasn't.
This was creating a soft crash and showing a RedBox to the user.
The library was going through the Interop Layer.
This change makes sure that, if the ViewManager is configured to be setup in the main queue, we retrieve the constants from the Main Queue
## Changelog
[iOS][Fixed] - Extract the constants from ViewManagers in the UI Thread if needed.
Reviewed By: sammy-SC
Differential Revision: D56762253
fbshipit-source-id: ca807b34d6e61418da9fd6a639a05f3394879f7c
Summary:
Changelog: [internal]
Migrating this feature flag (which is currently unused) to the new system, so we can test it in production and ship it soon.
Reviewed By: NickGerleman
Differential Revision: D56766553
fbshipit-source-id: 42d44cdd163568564e789cdffe1683e78fe91b53
Summary:
This work is based on Ruslan's https://www.internalfb.com/intern/diff/D56185630/
Changelog: [Internal]
`Expectation`: In React DevTools, user should be able to select an element on screen and it will show you what React component rendered it. This doesn't work in RN app that is using JS navigation
`Root Cause`:
In Fabric, when we try to find `ShadowNode` in the `ShadowTree`, `pointerEvents` props are not considered during the lookup of node using coordinate. Hence, in React DevTools when we inspect element, it was hightlighting the overlay `View` with `pointerEvents` props `box-none` was getting highlighted instead of its children view in the hierarchy.
Reviewed By: javache
Differential Revision: D56334314
fbshipit-source-id: ebfe58c5a1516add347c2c21ab5d075f804df8a9
Summary:
This removes the bulk of code added in https://github.com/facebook/react-native/pull/39630.
We're not shipping it, as it caused performance regressions.
Changelog:
[Internal]
Reviewed By: christophpurrer
Differential Revision: D56796936
fbshipit-source-id: 82f3a51cf145bc1695d70393e1f050685a1e6174
Summary:
Changelog: [General][BREAKING] Don't support 'float' enums in Turbo Modules
- The current implementation of 'float enums' in C++ does not work as invalid results are returned.
- At potential fix could still cause rounding errors when crossing language bounaries, e.g. `4.6` can become `4.5599999942..`
- C++ enum classes don't support float: https://eel.is/c++draft/dcl.enum#2.sentence-4
> The type-specifier-seq of an enum-base shall name an integral type; any cv-qualification is ignored.
Hence removing the feature of `float enums` for now
Reviewed By: NickGerleman
Differential Revision: D52120405
fbshipit-source-id: 3685ad0629e16ff9db424ba67e07d09df6027553
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44294
**Problem:**
It was discovered while testing 3 party library, generated member variables in a C++ `struct` in `Props.h` is not initialized.
Also `WithDefault` would not work as well.
(For the problematic case it was a `boolean` but would also apply to other primitive types.)
If there is no default initialization and the component prop is optional and the user of the native component does not set the prop then the variable is never initialized and this is problematic for primitive types in C++ where no initialization results in an undefined behavior.
**Proposed solution:**
(Following C++Core Guideline of [always initialize](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-always).)
Reusing `generatePropsString()` used by `ClassTemplate` to generate props for `StructTemplate` as well.
updated relevant test snapshots.
This change is only concerning the `Props.h` file.
**Changelog:**
[General][Fixed] - fixed `Props.h` created from codegen missing default initializers in C++ `struct`
Reviewed By: cipolleschi
Differential Revision: D56659457
fbshipit-source-id: 0d21ad20c0491a7e8bb718cd3156da65def72f23
Summary:
As of now, Apple does not respect privacy manifests added as cocoapods resource bundles. This forces react-native developers to manually copy `.xcprivacy` files content for each native dependency that accesses restricted reason APIs to the root file.
This PR adds an aggregation step that crawls through pod dependencies to collect all reasons into the root privacy info file.
## Changelog:
[IOS][ADDED] – Add privacy manifest aggregation.
Pull Request resolved: https://github.com/facebook/react-native/pull/44214
Test Plan:
When run on RNTester, it appends aggregated entries (while keeping existing ones) to existing .xcprivacy file without modifing .pbxproj:

When run on RNTester with the xcprivacy file removed from xcode beforehand, it creates a new .xcprivacy file, and adds it to Compile Bundle Resources in the same way as in the new template:

When run on RNTester with an empty .xcprivacy file, it appends aggregated entries from pods AND reasons for react-native core.
When run with `privacy_file_aggregation_enabled: false` in `use_react_native`, it falls back to existing behavior:

Reviewed By: cipolleschi
Differential Revision: D56481045
Pulled By: philIip
fbshipit-source-id: 1841bad821511c734d0cc0fcff5065ed92af76d8
Summary:
This enables to code-gen base C++ types for custom exported JS types from a RN TM spec - which have been previously excluded from code-gen as these aren't used in any function.
The only work around so far was to ‘register’ a random function using the custom type which should be used for RCTDeviceEventEmitter events
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D56685903
fbshipit-source-id: add9ca40018b91c9fca98609ba3d1f85d3affec1
Summary:
Changelog: [internal]
`LazyShadowTreeRevisionConsistencyManager` wasn't correctly updating the locked revision, because `emplace` is a no-op if there's already a value for the key in the `unordered_map`.
This fixes the issue and adds tests that actually showed it.
Reviewed By: sammy-SC
Differential Revision: D56761941
fbshipit-source-id: 340e9195b14460a591c48186bd365688c74ade04
Summary:
## 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
-->
Changelog: [Internal] Generated changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/44333
Reviewed By: cortinico
Differential Revision: D56756077
Pulled By: cipolleschi
fbshipit-source-id: 4e8d2f6b83499bd89d6a60de4eede385b7a8ac3c
Summary:
`RCTComposedViewRegistry` extends `NSMutableDictionary` which is a clustered class in iOS.
NSMutableDictionary is techncially an abstract class, but when instantiated by `[NSMutableDictionary new];` the system will return one of concrete classes that inherit from `NSMutableDictionary`, opaquely from the perspective of the caller.
By calling `super`, we are actually calling the not implemented method for the abstract class. If this happen, this can crash the app.
Given that the `RCTComposedViewRegistry` is extending the dictionary only for its interface but is using other mechanisms as storage, is it fair to return `NULL`if the storages don't have the requested view.
## Changelog
[iOS][Fixed] - Avoid calling abstract methods in RCTComposedViewRegistry
Reviewed By: cortinico
Differential Revision: D56755427
fbshipit-source-id: f5c56dc59ccc6b30c00199b4196c42eb9b021e2b
Summary:
I accidentally broke build_android.
Here the two fixes:
1. Make sure the constructor of PackageList2 are actually called `PackageList2`
2. Make sure the package of `OSSLibraryExamplePackage` is `com.facebook.react.osslibraryexample`
Changelog:
[Internal] [Changed] - Fix accidentally broken build_android job
Reviewed By: dmytrorykun
Differential Revision: D56756601
fbshipit-source-id: 862597ca829d702d880624d29276193f8548715d
Summary:
Changelog: [Internal]
The bodies of all `console` methods are currently written as lambdas within `installConsoleHandler` but actually capture nothing meaningful from that scope. This diff rewrites them as free functions instead.
To enable the "forwarding console methods" to be written as free functions, we also replace the runtime loop over `kForwardingConsoleMethods` with a compile-time equivalent using macros. (This technique is inspired by the Hermes source code, which uses it heavily for compile-time code generation.)
Reviewed By: huntie
Differential Revision: D56679956
fbshipit-source-id: babf368ecacb9dc426b2356a4a2091881ca1023e
Summary:
Changelog: [Internal]
Switches to constrained `auto` instead of `std::function` to represent intermediate function types in `RuntimeTargetConsole::installConsoleHandler`. This removes some indirection and potential runtime overhead.
Reviewed By: huntie
Differential Revision: D56675188
fbshipit-source-id: 76cbf8b8be9ca1a9466efbcd187bddd60c921019
Summary:
Changelog: [internal]
This migrates all the classes related to performance in `react-native/src/private` to use private fields instead of regular fields prefixed with `_`.
Reviewed By: yungsters
Differential Revision: D55931659
fbshipit-source-id: e8b2018048dbb6c8d6e8a4d143357bf2ac39dd1e
Summary:
Changelog: [internal]
Quick refactor to use private fields instead of fields with a naming convention, in classes in `react-native/src/private`.
Reviewed By: yungsters
Differential Revision: D56700382
fbshipit-source-id: ee0a7b30a9da20c31b92878be3316227b2d0a0c4
Summary:
Adds changelog for the 0.73.8 patch.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Add 0.73.8 changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/44331
Reviewed By: cortinico
Differential Revision: D56753881
Pulled By: cipolleschi
fbshipit-source-id: eed053cd39a768d6acb40a037a4218ee5e1fbbf8
Summary:
Changelog: [internal]
We have a comment explaining how to update all generated files everywhere but here.
Reviewed By: NickGerleman
Differential Revision: D56717344
fbshipit-source-id: cc538e37dd6ab09f67d67bb13ce4e560870d44d0
Summary:
This diff is part of RFC0759
https://github.com/react-native-community/discussions-and-proposals/pull/759
Here I'm creating data classes that will allow us to parse the `config` JSON output.
Code is pretty straightforward and follows the structure as the `config` command output.
Changelog:
[Internal] [Changed] - RNGP - Autolinking - Add model classes for parsing the `config` output
Reviewed By: cipolleschi, blakef
Differential Revision: D55475595
fbshipit-source-id: 3457c008ff0c5bce2b47fd637c7b10a5e7427c01
Summary:
This diff is part of RFC0759
https://github.com/react-native-community/discussions-and-proposals/pull/759
Here I'm creating the `runAutolinkingConfig` task.
This task is responsible of either:
- Invoking the `npx react-native-community/cli config` command (or the one specified by the user)
- Copying the config output file specified by the user (if any).
The task re-executes only if any of the lockfile are actually changed otherwise it just returns as "UP-TO-DATE"
This allows us to
Changelog:
[Internal] [Changed] - RNGP - Setup the RunAutolinkingConfigTask to run the config command
Reviewed By: cipolleschi, blakef
Differential Revision: D55475596
fbshipit-source-id: 3c687f965c59eb82fc447546ebd936ba401f34f2
Summary:
Hermes' ConsoleMessage constructor now accepts StackTrace, so the construction can be done in one go.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D56738060
fbshipit-source-id: 709b47d8f9cf69994e4c5eaa4f9310e70a4d9ed0
Summary:
## Changelog:
[Internal]-
Even though `TextInput.autoCapitalize` is supposed to be cross-platform, on the C++ side of the props data structures it was only exposed as an Android-specific one.
This would have it still work on the iOS side (as the corresponding prop is passed to Objective C around the C++ structs anyway), however it may also cause subtle scenarios, whereas the prop changes dynamically on the iOS side, but this doesn't get reflected on the native side.
This change fixes this problem by simply hoisting the prop into the `BaseTextInputProps`, which makes it available across all platforms, as it should be.
Differential Revision: D56726940
fbshipit-source-id: 9ba18f1f92095874e07207650b46655c331f3e91
Summary:
RuntimeAdapter.h is only needed when using CDPHandler, which the new code path doesn't need.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D56738299
fbshipit-source-id: 8cb512a3dc8dc303851871021e04aab94aa25d1e
Summary:
`Response` is `Closeable`, so we must close it even if the download is no longer relevant. Found while running with StrictMode enabled and reloading quickly multiple times.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D56629079
fbshipit-source-id: 041bf295313cbf78b7f2bb6580c50fdc2a324728
Summary: Changelog: [General][Removed] `launchId` query param for `/debugger-frontend` is no longer generated automatically for each `/open-debugger` call. Caller of `/open-debugger` is now responsible for generating the `launchId`, which will be passed along to `/debugger-frontend`.
Reviewed By: robhogan
Differential Revision: D55164645
fbshipit-source-id: b83303eda77b6fb86ebf50f699d9f308676533c6
Summary:
Supports the removal of Flipper from the template in 0.74, paried with additional blog post messaging: https://reactnative.dev/blog/2024/04/22/release-0.74#removal-of-flipper-react-native-plugin.
Changelog:
[General][Changed] - Update "Open Debugger" action to print extended Flipper guidance
Reviewed By: cipolleschi
Differential Revision: D56705236
fbshipit-source-id: d7e869625262ebb02bc2454c924f832cccfbcd31
Summary:
Just a minor fix to fix a missing space in the debug message.
Fixes a missing space in the message
```
Invariant Violation: TurboModuleRegistry.getEnforcing(...): 'MmkvPlatformContext' could not be found. Verify that a module by this name is registered in the native binary.Bridgeless mode: false. TurboModule interop: false. Modules loaded: {"NativeModules":["PlatformConstants","LogBox","Timing","AppState","SourceCode","BlobModule","WebSocketModule","SettingsManager","DevSettings","RedBox","Networking","Appearance","DevLoadingView","UIManager","DeviceInfo","ImageLoader","LinkingManager"],"TurboModules":[],"NotFound":["NativePerformanceCxx","NativePerformanceObserverCxx","BugReporting","HeadlessJsTaskSupport","SoundManager","IntentAndroid","MmkvPlatformContext","MmkvCxx"]}
```
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [FIXED] - Fixed missing space in TurboModule.getEnforcing error message
Pull Request resolved: https://github.com/facebook/react-native/pull/44311
Reviewed By: christophpurrer
Differential Revision: D56702036
Pulled By: rshest
fbshipit-source-id: e339a6ee8c265b2c6d27184e8e9941f3f02e3c85
Summary:
## Changelog:
[Internal] -
I was looking at the logs, troubleshooting a non-dev build issue, and noticed a line:
```
I0429 15:56:42.107558 1874554880: Running "MyApplication
```
In `__DEV__` mode this usually continues with `" with ...`, but in release mode the closing quote was missing, which made me think there may be something going on garbling the log messages.
Which ultimately was a red herring, and it's just a bad formatting in the message in release mode, which this change fixes.
Reviewed By: zeyap
Differential Revision: D56704170
fbshipit-source-id: a28604fffec6be74733c8759f59ee52a67a81746
Summary:
Changelog: [Internal]
Fixes a crash that may happen on Android when the `inspectorEnableModernCDPRegistry` feature flag is true, and clarifies the documentation of `HostTarget::create()` to avoid similar issues in future integrations.
## Context
The executor provided to `HostTarget::create()` ("the inspector executor") is used throughout the CDP backend to schedule work on the inspector thread. (See also D53356953.) To facilitate this, the executor is a copyable `std::function`.
On Android, the executor is backed by a Java object, to which we hold a reference from C++ using JNI. This reference is expressed as a `facebook::jni::global_ref` which gets copied as part of the executor. (`global_ref` is a RAII wrapper around the `NewGlobalRef` / `DeleteGlobalRef` JNI functions.)
## The bug
All the *calls* to the inspector executor from C++ happen on threads that are already properly [attached to the JVM](https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/invocation.html#attaching_to_the_vm) ( = the UI thread / the JS thread) and are therefore allowed to make JNI calls. However, there are cases where a copy of the inspector executor may have its *destructor* run on an unexpected thread, namely the (Hermes) JS GC thread. (This happens when the executor itself is captured in a lambda that's stored in a `jsi::HostObject` or `jsi::HostFunction`, which is in turn [destroyed on the JS GC thread](https://github.com/facebook/react-native/blob/5a0ae6e2d9d7f2357f9ea6c5dc1d573233075326/packages/react-native/ReactCommon/jsi/jsi/jsi.h#L118-L126).) In such cases, the `DeleteGlobalRef` call mentioned above will crash, because the JS GC thread is not attached to the JVM.
## The fix
First, we document that copies of the inspector executor provided to `HostTarget::create` may indeed be destroyed on arbitrary threads. This is an unavoidable consequence of the existing design. Second, we adapt the Android integration to this requirement.
`fbjni` provides the [`jni::ThreadScope`](https://github.com/facebookincubator/fbjni/blob/968e3815f92aeb0670f5d88ae975fbbd47a4b482/cxx/fbjni/detail/Environment.h#L93-L123) RAII helper to manage attaching C++ threads to the JVM. If we had any explicit control over the setup and teardown of the JS GC thread, we could create a single `jni::ThreadScope` to globally ensure the safety of JS-finalizer-to-JNI calls in React Native. However, neither JSI nor the Hermes API provides such control.
Instead, we essentially resort to creating a temporary `ThreadScope` around each `DeleteGlobalRef` call where we don't control the calling thread. We do this using a new kind of JNI reference wrapper class called `SafeReleaseJniRef`. Retaining a `SafeReleaseJniRef` instead of a plain `global_ref` is all that's needed to make a particular reference safe to destroy on any thread.
Reviewed By: huntie
Differential Revision: D56620131
fbshipit-source-id: 0b6f32a7bd6477d0384af19c42e21d9242ce623d
Summary:
This gives Frameworks more control in selecting specific tasks and integrating the return types data in their UI. For example piping `stdout` to the user or using packages like [Listr2](https://www.npmjs.com/package/listr2) to run tasks in parallel and show progress.
The ordering is suggestive (but also enforced by some assertions). Frameworks are free to do what they want.
The order was implicit in the previous data structure with lists of Tasks, but made it difficult to tap into each async task.
I've also had to rework how we transpile the code if directly executed from the monorepo. This keeps our:
- flow types valid,
- allows the core-cli-utils package to be built (to generate TypeScript types and a valid npm module), and
- allows direct transpiled execution as a yarn script.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D56242487
fbshipit-source-id: a1a18f14a4aef53a98770462c8ebdef4111f0ab4
Summary:
Changelog: [Internal]
In the new CDP backend, calling any `console` method a second time involves a call to a moved-from `std::function`. This shouldn't work, and indeed results in an exception on some platforms, but isn't strictly an error according to the C++ standard: moving from a `std::function` leaves it in an [unspecified state](https://en.cppreference.com/w/cpp/utility/functional/function/function#:~:text=the%20call%20too.-,other,is%20in%20a%20valid%20but%20unspecified%20state%20right%20after%20the%20call.,-5), not necessarily an empty state, so (in particular) it's perfectly legal for the implementation to perform a copy instead of a move and leave the original variable intact.
(See [Compiler Explorer](https://godbolt.org/z/qoo5Mnd68) for proof that libc++ and libstdc++ differ on this - the former performs a copy, while the latter actually performs a move, resulting in a `std::bad_function_call` exception later.)
In the code in question, we're right to want to avoid a copy of the `body` function into the argument of `delegateExecutorSync` - only one copy of this function needs to exist at a time. But the correct way to avoid this copy is to capture `body` by reference, as we can do that repeatedly with no ill effects. (`delegateExecutorSync` is, as its name suggests, synchronous, so there are no lifetime issues.) Doing this also allows us to remove the use of `mutable` so the capturing is by *const* reference.
Reviewed By: sammy-SC
Differential Revision: D56673529
fbshipit-source-id: b235977b2fbc889462c4c78adfe41ae6f509e349
Summary:
changelog: [internal]
force_static doesn't need to be in here, let's remove it.
I change one module per diff. It makes it easier to land it and pinpoint where build failures are coming from.
Reviewed By: christophpurrer
Differential Revision: D56678530
fbshipit-source-id: c602e065d77fdd649c66ce2d26eee83428ef5ba8
Summary:
Resolved Pull request: https://github.com/facebook/react-native/pull/44296
changelog: [internal]
force_static doesn't need to be in here, let's remove it.
I change one module per diff. It makes it easier to land it and pinpoint where build failures are coming from.
Reviewed By: javache
Differential Revision: D56632286
fbshipit-source-id: e942603d3c69d9eebf4d3b64e2f73ee6a5df6de4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44295
changelog: [internal]
mapbuffer is only used on Android. Let's remove the option to have it compile on iOS.
Reviewed By: NickGerleman
Differential Revision: D56635289
fbshipit-source-id: 1a57c271d21b8aef81179d96b1a6832e7615dd27
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44283
changelog: [internal]
force_static doesn't need to be in here, let's remove it.
I change one module per diff. It makes it easier to land it and pinpoint where build failures are coming from.
Reviewed By: christophpurrer
Differential Revision: D56630625
fbshipit-source-id: 069587893dbb8866d1a08de256b4612d60bcc3b8
Summary:
changelog: [Android][Fixed] - fix a crash in Modal component
Instance variable `propertyRequiresNewDialog` in `ReactModalHostView` controls if new dialog will be created on next `showOrUpdate` or not. It must be kept in sync with `dialog` ivar.
if `dismiss` is ever called from anywhere but `showOrUpdate`, the class gets into a state where the next `showOrUpdate` call will throw an error because dialog is set to null but `propertyRequiresNewDialog` stays false.
`dismiss` is called from three places: `showOrUpdate` (this is ok), `onDropInstance()` and `onDetachedFromWindow`.
The fix in this diff is to make sure propertyRequiresNewDialog is set to true when dialog is dismissed.
Reviewed By: alanleedev
Differential Revision: D56627522
fbshipit-source-id: e7a16cd022401a7a4a0fbf8fc71a2312d05fcb8e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44140
Why?
Previously we didn't support using percentages like:
```
style={{
width=100,
height=100,
borderRadius='100%',
}}
```
These percentages refer to the corresponding dimension of the border box.
What?
Change the unit type for `BorderRadii` values to `ValueUnit`. This type allows us to have an object containing a `float`, and a `UnitType` properties. With this we conditionally calculate the corresponding point (dp) value for a given percentage (considering size). Ex:
```
result = {raw_percentage_value} / 100 * (max(height, width))
```
We know the maximum border radius for our current implementation is half the dp of the shorter side of our view, hence why we consider half our maximum view side as equivalent to 100%.
Note: We still don't support vertical/horizontal border radii
## Changelog:
[iOS][Added] - Added support for using percentages when defining border radius related properties.
Reviewed By: NickGerleman
Differential Revision: D56198302
fbshipit-source-id: 6cd510b1c7164dcb82ca5ad8a9861c5ce5c8b15b
Summary:
Non-uniform edge insets caused issues on iOS 10. The code nowadays interferes with the rendering for large borderRadii so this diff removes it.
Since we didn't support this behavior before there are some bugs/missing features that happen:
T186810893 Incorrect border rendering with large radii
T186812303 View discoloring with overlapping border radii
T186812736 Add support for vertical and horizontal border radii
## Changelog:
[iOS][Fixed] - Removed Legacy iOS 10 code messing with border radius
Reviewed By: NickGerleman
Differential Revision: D56333637
fbshipit-source-id: 92b1bb1459d1e95476b3d768db725dfbbc1e55ae
Summary:
`flow-api-translator` can't handle `module.exports`. Shift this to ESM style exports like the other built packages.
Changelog: [Internal] - Fixing an internal build script broken by D56243647
Reviewed By: cipolleschi
Differential Revision: D56638506
fbshipit-source-id: f5a4c7bea06b7f95300388e3d37cf0d377bc3b17
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44220
This diff is part of RFC0759
https://github.com/react-native-community/discussions-and-proposals/pull/759
Here we're looking into splitting the autolinking into a component that will live inside core (specifically inside the React Native Gradle Plugin - RNGP) and another component that will live inside the Community CLI.
Here I start by adding 2 fields to RNGP extension, that frameworks and templates can use to provide their autolinking config.
Changelog:
[Internal] [Changed] - RNGP - Add autolinking fields to ReactExtensions
Reviewed By: cipolleschi
Differential Revision: D55475597
fbshipit-source-id: 316d1919a113a94c57426710f487f334c6128345
Summary:
We ran CodeQL in react-native-windows and it found a comparison of narrow type with wide type in loop condition in ReactCommon/react/renderer/core/RawPropsKeyMap.cpp
microsoft/react-native-windows#12701
## Changelog:
[INTERNAL] [SECURITY] - Fix comparison of narrow type with wide type in loop condition in RawPropsKeyMap.cpp
Pull Request resolved: https://github.com/facebook/react-native/pull/44262
Test Plan: Tested on windows.
Reviewed By: cipolleschi
Differential Revision: D56628137
Pulled By: javache
fbshipit-source-id: 9ff3bd3cbcfd084efc1e01180ff01529d1be02eb
Summary:
In addition to memoizing `mergedStyle` in `createAnimatedComponent`, this avoids unnecessary object allocations by:
* Not allocating `passthroughProps`, created via a rest spread operator. It is unnecessary because we always override `style` in the JSX.
* Not allocating a new object if either `style` or `passthroughStyle` are null or undefined. Also, create an array of the two style objects instead of spreading them, which is needless.
Changelog:
[General][Changed] - Improved performance of `Animated` components
Reviewed By: sammy-SC
Differential Revision: D56621191
fbshipit-source-id: ac863661c60d87c681284ce5ef5d6774b9c50653
Summary:
Changes two important aspects of `StyleSheet.compose`:
- Extract it from `StyleSheet` so that it can be imported from other internal modules without incurring circular dependencies. (Surprisingly, `StyleSheet` has a lot of dependencies.)
- Avoid a redundant `style1 != null` check.
Changelog:
[General][Changed] - Optimized performance of `StyleSheet.compose`
Reviewed By: sammy-SC
Differential Revision: D56621407
fbshipit-source-id: f899b50d9f13f1514485371c8513a85be78eae24
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44239
A simple CLI to build our iOS `helloworld` application. This isn't intended for an audience other that the release team.
Some Framwork authors might be interested in it as an example of how to use our react-native/core-cli-utils to build a React Native application.
Changelog: [Internal]
I'm not going to export because it's not that interesting to folks outside / in need of scrutiny.
Reviewed By: cipolleschi
Differential Revision: D56243647
fbshipit-source-id: a5f1b6d1046bda165aa7c6848938e05f0cca2dc8
Summary:
On the new architecture on Android on the new arch, `textAlign` style was ignored (`Layout.Alignment.ALIGN_NORMAL` was always used) during the measurement of text. During this phase, the positions of attachments are also calculated, which results in inline views being always positioned as if alignment to the left was set. This PR updates the measurement logic to also take `textAlign` into account during measurement.
Fixes https://github.com/facebook/react-native/issues/41008
## Changelog:
[ANDROID] [FIXED] - Fixed `textAlign` not being taken into account when positioning views inlined in text
Pull Request resolved: https://github.com/facebook/react-native/pull/44146
Test Plan:
<details>
<summary>I've been testing on the following code</summary>
```jsx
import { SafeAreaView, Text, View } from "react-native";
function InlineView(props) {
return (<View style={{margin: 10}} >
<Text style={{ textAlign: props.textAlign, backgroundColor: 'cyan' }}>
Parent Text
<Text style={{ fontWeight: 'bold' }}>Child Text</Text>
<View style={{width: 50, height: 50, backgroundColor: 'red'}} />
<Text style={{ fontWeight: 'bold' }}>Child Text</Text>
{props.long && <Text style={{ fontWeight: 'bold' }}>aaaa a aaaa aaaaaa aaa a a a aaaaa sdsds dsdSAD asd ASDasd ASDas</Text>}
</Text>
</View>)
}
export default function Test() {
return (
<SafeAreaView style={{ flex: 1 }}>
<Text style={{textAlign: 'center', fontSize: 20}}>BoringLayout</Text>
<InlineView textAlign="left" />
<InlineView textAlign="center" />
<InlineView textAlign="right" />
<InlineView textAlign="justify" />
<Text style={{textAlign: 'center', fontSize: 20}}>StaticLayout</Text>
<InlineView textAlign="left" long />
<InlineView textAlign="center" long />
<InlineView textAlign="right" long />
<InlineView textAlign="justify" long/>
</SafeAreaView>
);
}
```
</details>
| Old architecture | New architecture |
|------------------|------------------|
| <img width="447" alt="Screenshot 2024-04-18 at 17 08 59" src="https://github.com/facebook/react-native/assets/21055725/b21848ff-3939-4dde-9f78-03ce50c9429a"> | <img width="447" alt="Screenshot 2024-04-18 at 17 04 46" src="https://github.com/facebook/react-native/assets/21055725/fb57a3c4-09e8-4db7-abc3-79747314529b"> |
Reviewed By: NickGerleman, cipolleschi
Differential Revision: D56361169
Pulled By: cortinico
fbshipit-source-id: c3002f65541774e376e315c3076a6157aa330f8d
Summary:
Based on a more recent 14.x.x release of Listr.
Changelog: [Internal]
These are direct copies from `xplat/js/flow/{listr,rxjs_v6.x.x}.js`
Reviewed By: huntie
Differential Revision: D56576985
fbshipit-source-id: c850c89891bf8eb57586a5e2a50f0204fd885f65
Summary:
Any component wrapped via `createAnimatedComponent()` will always re-render, because it creates a new `style` object. It's impossible to memoize.
Adding `useMemo()` here ensures that the `style` object passed to the underlying object is stable: if no `style` is passed to the wrapped component, then memoization can work.
Allowing memoization to function when the `style` object is passed in will require a deeper fix. See https://fb.workplace.com/groups/rn.support/permalink/26084643474490921/
Before:
{F1496803038}
After:
{F1496805410}
## Changelog:
[General] [Fixed] - Fixed memoization for components wrapped with createAnimatedComponent
Differential Revision: D56618868
fbshipit-source-id: a0af8b1a02c34b5cf6e6d7e9f0381fb323b232cc
Summary:
While the class and constructor are referenced from native code, the constructor is only accidentally retained on the Java side without proper keep rules. Adding explicit DoNotStrip in the code here.
Changelog: [Internal]
Reviewed By: beicy
Differential Revision: D56529943
fbshipit-source-id: 5459b7d32ada5eeb1fabff1dfc796c2f81d3bb96
Summary:
One way we register cxx turbo modules with React Native is via cxxreactpackages.
This diff allows the application to pass in cxxreactpackages into the default react host, which allows the application to, in turn, register cxx modules with react native!
Changelog: [Android][Added] - Allow bridgeless apps to register cxx modules via cxxreactpackages
Reviewed By: cortinico
Differential Revision: D56547493
fbshipit-source-id: 4e8f02f0546c4b647a915fc65ea9687aa1592190
Summary:
We might want to publish some new versions of React Native with experimental feature to allow some partners to test whether those versions fixes some reported issues, before creating a proper stable version for the whole ecosystem.
The infra is mostly [setup for this](https://www.internalfb.com/code/fbsource/[496a64d180faab501b8598aa0ec26d47454fb961]/xplat/js/react-native-github/scripts/releases/utils/version-utils.js?lines=149), already. The only detail we need to take care of is not to move the `next` tag.
## Changelog:
[Internal]
Reviewed By: cortinico, huntie
Differential Revision: D56578456
fbshipit-source-id: 8dcc674aab5f85077c1b3e6580c5aeb99226eff8
Summary:
There are a couple scenarios where flattening the child of a ScrollView can cause problems.
1. `maintainVisibleContentPosition` on both Android and iOS rely on reading live positions in the view tree
2. `snapToAlignment` on Android uses live view tree, for items to snap to. iOS seems to have very different behavior, and aligns assuming that children are scroll view height, or that a snap interval has been set.
This change adds a prop `collapsableChildren` which can be used to disable children of scroll content view from being collapsed.
Differentiator is... complicated... but we can mostly just adapt the code dealing with existing traits at the surface level.
Changelog:
[General][Fixed] - Automatically disable flattening of scroll content view children when needed
[General][Added] - Add `collapsableChildren` prop
Reviewed By: javache
Differential Revision: D56226241
fbshipit-source-id: ed81f7fff5a15eac424708f763afc9b844aefa9c
Summary:
Flow shouldn't consider definitions inside this folder. This speeds up working in the OSS checkout if you happen to have Hermes built.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D56575537
fbshipit-source-id: 8e5cdd0436712322a4a7298a24c721d9659d98af
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44256
## Changelog:
[iOS] [Fixed] - Preserve content offset in ScrollView when the component is suspended
# The problem
On iOS, components are recycled. For ScrollView, its content offset has to be reset back to original position. When we call `[UIScrollView setContentOffset:]`, it triggers all of its delegate methods and triggers `scrollViewDidScroll` where we set native state.
So when user scrolls to position 100 and scroll view suspends. it is removed from view hierarchy and recycled. Once the suspense boundary is resolved, scroll view will be inserted back into view hierarchy. But when it was recycled, we set back its original content offset (the default is 0, 0) but this was accidentally propagated through to shadow tree.
# Solution
To avoid this, we simply need to invalidate `_state` before calling `[UIScrollView setContentOffset:]`.
Reviewed By: cipolleschi
Differential Revision: D56573370
fbshipit-source-id: c03d7d2d403af2e1649b4cf189072baeb4c286c8
Summary:
Set the proper build flags for debugging in Bridgeless mode.
This fixes [#44240](https://github.com/facebook/react-native/issues/44240)
## Changelog:
[iOS][Fixed] - Add `HERMES_ENABLE_DEBUGGER=1` flag to React-RuntimeApple
Reviewed By: cortinico
Differential Revision: D56575647
fbshipit-source-id: a0613a5d46caeb1d3e636e54ecd43428fbaf46e8
Summary:
Defines module for `React-jsinspector` that for swift modules to integrate with.
to fix https://github.com/expo/expo/issues/28209, any podspec depends on HermesExecutorFactory should use ` add_dependency(s, "React-jsinspector", :framework_name => 'jsinspector_modern')` to add dependency. otherwise it will encounter the header not found issue because use_frameworks will change "jsinspector-modern" to "jsinspector_modern".
to depend on React-jsinspector from expo-modules-core, we need it to define as a module.
otherwise, it will have the error
```
The Swift pod `ExpoModulesCore` depends upon `React-jsinspector`, which does not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies.
```
## Changelog:
[IOS] [CHANGED] - Add `DEFINES_MODULE` for React-jsinspector.podspec
Pull Request resolved: https://github.com/facebook/react-native/pull/44252
Test Plan: ci passed
Reviewed By: cortinico
Differential Revision: D56575102
Pulled By: cipolleschi
fbshipit-source-id: 9b7b4568a3e499f0a741a79a846263118ff2d112
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44231
changelog: [internal]
The flag is not used and is statically set to false, let's delete it.
Reviewed By: NickGerleman
Differential Revision: D56473851
fbshipit-source-id: fe1076d20a765ffed2437f080764f2b5fe060bb6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44232
changelog: [internal]
surfaceId parameter is not needed `schedulerDidRequestPreliminaryViewAllocation` as it can be derived from shadow node.
Additionally, conversion to ShadowView can happen on the lower layers.
Reviewed By: NickGerleman
Differential Revision: D56350599
fbshipit-source-id: 9c38cc0df36911bbd6927fe0a0d5e64c248d87c4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44167
We received an issue for OSS where, when the main window is inactive and the system tries to present a dialog, the dialog is not presented in the right position on the screen.
This change introduce a fallback to the first inactive window (which is still visible on screen) and it fixes the issues.
## Changelog:
[iOS][Changed] - Fallback to the first `foregroundInactive` window when there are no `foregroundActive` windows in RCTKeyWindow
Reviewed By: dmytrorykun
Differential Revision: D56354741
fbshipit-source-id: fa23131ecd40f6d91c705879a72890506ee21486
Summary:
Inside [Re.Pack](https://github.com/callstack/repack) we consume command's options, to reduce the amount of assumptions that 3rd party tools need to make - we can move assigning default value to config command level, so default values will be aligned across tools.
For default `start` command this change doesn't change any behaviour.
## Changelog:
[INTERNAL] [CHANGED] - Add `localhost` as default host in `start` command config
Pull Request resolved: https://github.com/facebook/react-native/pull/44244
Test Plan: `start` command should work the same way as before.
Reviewed By: huntie
Differential Revision: D56567793
Pulled By: blakef
fbshipit-source-id: fe8f3686ae39a3d2996de11930a0d03364692adc
Summary:
Web props work (somewhere around D41230978 and D39268920) made it so that numeric font weights can be set instead of just strings. This is implemented by converting number to string before passing to native component within the `Text` component.
We have crash with:
```
2024-04-19 09:38:21.360 16963 17190 E ViewManager: Error while updating prop fontWeight
2024-04-19 09:38:21.360 16963 17190 E ViewManager: java.lang.IllegalArgumentException: method com.facebook.react.views.text.ReactBaseTextShadowNode.setFontWeight argument 1 has type java.lang.String, got java.lang.Double
2024-04-19 09:38:21.360 16963 17190 E ViewManager: at java.lang.reflect.Method.invoke(Native Method)
```
`TextStyleProps` can also be passed to `TextInput`, which passes to underlying native component, without going through this logic. And the types for Native props directly derive from JS props, so type system does not catch passing incorrect number type to underlying native component.
This does a quick and dirty replication of the exact logic in `Text.js` to `TextInput.js`. I'd love to potentially fix this up for Fabric in a different way when we rethink CSS parsing.
Changelog:
[General][Fixed] - Handle `fontWeight` normalization for TextInput component
Reviewed By: arushikesarwani94
Differential Revision: D56539571
fbshipit-source-id: 8975886c117d814a624f817bffe408841bb03b88
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44236
## Changelog:
[Android] [Fixed] - fix a case when view preallocation or props forwarding on Android lead to dropped props update
# What does this fix
This fixes a bug where prop change is not delivered to Android mounting layer if the prop change was initiated from state update inside of `useLayoutEffect`, `componentDidMount` or `componentDidUpdate`.
This affects android only and when batched rendering is enabled.
There are two root causes of this problem:
1. View preallocation on Android: https://fburl.com/code/r62p3vot
2. Prop forwarding on Android: https://fburl.com/code/644f1ppk
Minimal repro :
```
import React, {useLayoutEffect, useState} from 'react';
import {Button, SafeAreaView, View} from 'react-native';
function Foo() {
const [bgColor, setBgColor] = React.useState('red');
useLayoutEffect(() => {
console.log('useLayoutEffect');
setBgColor('blue');
}, []);
return (
<View
style={{
backgroundColor: bgColor,
width: '100%',
height: '100%',
}}
/>
);
}
function RNTesterApp() {
const [show, setShow] = useState(false);
return (
<SafeAreaView>
<Button title="Toggle" onPress={() => setShow(!show)} />
{show && <Foo />}
</SafeAreaView>
);
}
export default RNTesterApp;
```
# The underlaying problem
The problem is combination of view preallocation and batched rendering updates.
Here is a step by step what happens in the repro above:
1. React issues asks Fabric to create new shadow node A with background colour **red**.
2. Fabric asks Android to allocate a view for shadow node A with background colour **red**.
3. React commits tree **T1** and calls layout effects. Meanwhile Fabric waits, without trying to mount the tree **T1**, to prevent painting state that is about to be updated and prevent flickering.
4. React clones node A, changing the background colour to **blue** and commits the new tree **T2**.
5. Fabric, will now go ahead and mount the latest tree **T2**. While creating mount instructions, it will drop prop updates because it believes prop updates where delivered already as part of step 2.
# The fix
The fix is to change two things:
1. Ignore view preallocation for shadow nodes which were cloned with new props.
2. Set hasBeenMounted flag on ShadowNode later in the Fabric pipeline to fix it.
Both of these are hidden behind a single feature flag: `fixMountedFlagAndFixPreallocationClone`
## Performance implication:
I estimate that this will impact around 3% of views.
Reviewed By: rubennorte
Differential Revision: D56353589
fbshipit-source-id: 651d3cd2d0f78bfbbe9c05aa1ae1b1690c15e4ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44188
The current approach used for `batchRenderingUpdatesInEventLoop` is not compatible with Android due to limitations in its props processing model. The raw props changeset is passed through to Android, and must be available for the Android mounting layer to correctly apply changes.
We have some logic to merge these payloads when multiple ShadowNode clones take place but were previously assuming that a ShadowTree commit was a safe state to synchronize.
In the current implementation this means that two commits driven from layout effects (triggering states A → B → C) may cause Android to observe only the B → C props change, and miss out on any props changed in A → B.
Changelog: [Android][Fixed] Cascading renders were not mounting correctly when `batchRenderingUpdatesInEventLoop` is enabled.
Reviewed By: rubennorte
Differential Revision: D56414689
fbshipit-source-id: 7c74d81620db0f8b7bd67e640168afc795c7a1d7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44233
The package was added to our build scripts, but shouldn't have been. We're not exporting this package or making it public.
Changelog: [Internal]
This should unblock our OSS CI.
Reviewed By: cipolleschi
Differential Revision: D56513694
fbshipit-source-id: f37c75871253b2570fb933175165d8f0a9593a16
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44197
Changelog: [General][Breaking] Remove executeAsynchronously and executeSynchronously_CAN_DEADLOCK
these are not used anywhere nor in OSS, we can delete this safely
Reviewed By: javache
Differential Revision: D56447959
fbshipit-source-id: d66c10f676946422385750c1b8825ead2d5d0ed8
Summary:
This is a copy of the current packages/react-native/template that we exclusively use internally for testing.
Changelog: [Internal]
NOTE: Best contribution would be to scan the file list and ensure there isn't anything that shouldn't be in there.
bypass-github-export-checks
Reviewed By: cortinico, cipolleschi
Differential Revision: D56242484
fbshipit-source-id: 0913ff7acff9b0314b49f48e986674b77dbb908e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44209
## Changelog:
[Android] [Fixed] - When React Native is destroyed, unmount all Fabric surfaces.
Previously, Fabric surfaces would not be torn down. Meaning that passive and layout effects wouldn't be unmounted and surface infra wouldn't be cleaned up.
For example:
```
useEffect(() => {
return () => {
console.log('unmounted');
}
)};
```
When calling `ReactNativeHost.clear()` on Android in native code, the above effect should be unmounted.
This is a requirement for Fabric.
Reviewed By: javache
Differential Revision: D56238947
fbshipit-source-id: 5dbf5cdef520f34c78953c2b8f2d42349549e893
Summary:
This decouples the listing of modules from the linking of those modules into Cocoapods. I've made this backwards compatible, but our internal template wont lean on the community config.
The user can now override how they capture a list of React Native modules, providing an escape hatch for Framework authors to build on.
Changelog: [General][iOS] Use our fork of the react-native-communti/cli-platform-ios use_native_modues.rb script
Reviewed By: cipolleschi
Differential Revision: D56242486
fbshipit-source-id: 78505669ab6abd6718348388c3bfba3290f7071b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44206
Changelog: [internal]
We finally managed to implement mount hooks without reliability issues on Android, so we can clean up the feature flag and enable it unconditionally.
Reviewed By: cortinico
Differential Revision: D56467379
fbshipit-source-id: d797ec770b731135332bc9f39df1c1e684b3bde4
Summary:
This change is a preliminary change to add support to `Long` and `long` React props that are required for supporting WideGamut color space.
## Changelog
[Android][Added] - Extend Property Processor to support long props
Reviewed By: cortinico
Differential Revision: D56461183
fbshipit-source-id: 0f70388abe2b414a09df640f04e767f1164d63ce
Summary:
This adds support for enabling wide color gamut mode for ReactActivity per the wide gamut color [RFC](https://github.com/react-native-community/discussions-and-proposals/pull/738).
## Changelog:
[ANDROID] [ADDED] - Add isWideColorGamutEnabled to ReactActivityDelegate
Pull Request resolved: https://github.com/facebook/react-native/pull/43036
Test Plan:
Update RNTesterActivity.kt to enable wide color gamut:
```diff
class RNTesterActivity : ReactActivity() {
class RNTesterActivityDelegate(val activity: ReactActivity, mainComponentName: String) :
// ...
override fun getLaunchOptions() =
if (this::initialProps.isInitialized) initialProps else Bundle()
+ override fun isWideColorGamutEnabled() = true
}
```
Reviewed By: cortinico
Differential Revision: D55749124
Pulled By: cipolleschi
fbshipit-source-id: 44dd5631e1a2e429c86c01ed8747bbebbc8bdb3b
Summary:
This adds support for color function values to ColorPropConverter per the wide gamut color [RFC](https://github.com/react-native-community/discussions-and-proposals/pull/738). It updates the color conversion code so that it returns a Color instance before ultimately being converted to an Integer in preparation for returning long values as needed.
bypass-github-export-checks
## Changelog:
[ANDROID] [ADDED] - Update ColorPropConverter to support color function values
Pull Request resolved: https://github.com/facebook/react-native/pull/43031
Test Plan:
Colors should work exactly the same as before.
Follow test steps from https://github.com/facebook/react-native/pull/42831 to test support for color() function syntax.
While colors specified with color() function syntax will not yet render in DisplayP3 color space they will not be misrecognized as resource path colors but will instead fallback to their sRGB color space values.
Reviewed By: cortinico
Differential Revision: D55749058
Pulled By: cipolleschi
fbshipit-source-id: 37659d22c1db4b1a27a9a4f88c9beb703517b01f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44182
## Changelog:
[iOS] [Fixed] - Fixed stale state on TouchableOpacity and TouchableBounce
When TouchableOpacity and TouchableBounce are unmounted, we need to reset their state. This includes animation state. If we don't do that, view is unmounted on the mounting layer and animation will not be applied. This leaves view in undefined state. In TouchableOpacity, it is view with reduced opacity. TouchableBounce that is view with applied transform.
This was reported in https://github.com/facebook/react-native/issues/44044
Reviewed By: rubennorte, cipolleschi
Differential Revision: D56416571
fbshipit-source-id: 01214ec8a5e07c80a609e082b955a30305ad8396
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44196
Changelog: [Internal]
BufferedRuntimeExecutor is unnecessarily coupled with these other targets (React-runtime, React-cxxreact), break that dependency so we can modularize this file
Reviewed By: realsoelynn
Differential Revision: D56382644
fbshipit-source-id: ed9725fbddcda04b73c583d927351440b4fc3328
Summary:
After creating a new project with `npx react-native init`, line 39 in `project.pbxproj` contains both spaces and tabs for indentation (accidentally introduced in 520d120375). This line will be unnecessarily touched and rewritten by a subsequent `pod install`.
Fix the indentation by replacing 4 spaces with one tab character (the Xcode managed file exclusively uses tabs for indentation).
## Changelog:
[GENERAL] [FIXED] - Fix space/tab indentation in template project.pbxproj
Pull Request resolved: https://github.com/facebook/react-native/pull/44186
Test Plan: Generate project again with change and observe that the file will be generated with the expected indentation.
Reviewed By: NickGerleman
Differential Revision: D56439289
Pulled By: arushikesarwani94
fbshipit-source-id: ced9f0c94757a4925cd01673c65f2c38d28629e6
Summary:
Changelog: [Internal]
add this to the framework's resource bundle
from the audit there was a callsite to fstat in our forked copy of glog, so use C617.1.
callsites:
- glog/src/logging.cc
current problem with this method is that the required reasons are not currently be aggregated during app store review, so those need to live in the app's. but go ahead and add it here for now, i think apple will try to fix it.
Reviewed By: cipolleschi
Differential Revision: D55625116
fbshipit-source-id: b10ea2dad2238cc85b5fe30df56269a5808a35b5
Summary:
Changelog: [Internal]
add this to the framework's resource bundle
from the audit there were callsites to fstat variants in our forked copy of boost, so use C617.1.
callsites:
- RCT-Folly/folly/FileUtil.h
- RCT-Folly/folly/portability/SysStat.h
current problem with this method is that the required reasons are not currently be aggregated during app store review, so those need to live in the app's. but go ahead and add it here for now, i think apple will try to fix it.
Reviewed By: cipolleschi
Differential Revision: D55625114
fbshipit-source-id: fb388f474e62543828218925b0d409d4b558c3db
Summary:
Changelog: [Internal]
add this to the framework's resource bundle
from the audit there were callsites to mach_absolute_time and fstat variants in our forked copy of boost, so use 35F9.1 and C617.1 respectively.
current problem with this method is that the required reasons are not currently be aggregated during app store review, so those need to live in the app's. but go ahead and add it here for now, i think apple will try to fix it.
Reviewed By: cipolleschi
Differential Revision: D55625113
fbshipit-source-id: 0dcd216116595d1bb14e6b843f711aac68f84e5c
Summary:
Changelog: [Internal]
add this to the framework's resource bundle
reasons:
- C617.1 (JSBigString)
current problem with this method is that the required reasons are not currently be aggregated during app store review, so those need to live in the app's. but go ahead and add it here for now, i think apple will try to fix it.
Reviewed By: sammy-SC
Differential Revision: D55624716
fbshipit-source-id: 400e9852a64e7f9fd9e32225b199f2664a069fc2
Summary:
Changelog: [Internal]
add this to the framework's resource bundle
reasons:
- C617.1 (RCTJavaScriptLoader)
- CA92.1 (RCTI18nUtil, RCTBundleURLProvider, RCTSettingsManager)
current problem with this method is that the required reasons are not currently be aggregated during app store review, so those need to live in the app's. but go ahead and add it here for now, i think apple will try to fix it.
Reviewed By: sammy-SC
Differential Revision: D55622471
fbshipit-source-id: f6ab864f51d4fa6e20f5de4fd56d8126d55dea8d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44185
This change will fix a symbol not found for JSC Runtime.
The `if` check was not a compile time check, therefore the symbol ended up in the binary even if it is not available.
Following this post on [Apple forum](https://forums.developer.apple.com/forums/thread/749534), this changes should do the trick.
## Changelog
[iOS][Fixed] - Fix Symbol not found: (_JSGlobalContextSetInspectable)
Reviewed By: hash3r
Differential Revision: D56425834
fbshipit-source-id: a37af51b078bd47a938e6b65d9d8e0f7506e746f
Summary:
codegen generates type alias for array enum props with uint32_t which cause wrong overloaded fromRawValue to call at runtime eventually app to terminate
more detailed info at issue https://github.com/facebook/react-native/issues/43821
## Changelog:
[Internal] [Fixed] - Codegen for array enum props
Pull Request resolved: https://github.com/facebook/react-native/pull/44123
Test Plan: TODO
Reviewed By: cipolleschi
Differential Revision: D56414554
Pulled By: dmytrorykun
fbshipit-source-id: 0ec1b65951bc16ff58dd2b119c97a4e3fac2b161
Summary:
This is an automatically generated fixup patch to bring fbsource back into sync with
facebook/react-fbsource-import on GitHub. Please land this patch as soon as possible, as the difference
reflected on here is already on GitHub and future changes may depend on these
changes!
Changelog: [Internal]
<< DO NOT EDIT BELOW THIS LINE >>
diff-train-skip-merge
diff-train-source-id: 13710c68616cf643d3cdfd69e5f39b2dc5a801b4
Generated by: https://www.internalfb.com/intern/sandcastle/job/36028798276627863/
GitHub Repo: facebook/react-fbsource-import
Reviewed By: jackpope
Differential Revision: D56357596
fbshipit-source-id: 171ed7b816869348a1cc3c06a78b3803b86eb7c4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44180
Changelog: [General][Changed] Update Chrome launch flags for `--experimental-debugger` launch flow
Internally at Meta, we've been testing the experimental debugger launch flow with a different set of Chrome flags than are currently shipped in open source. This diff fixes those differences:
* Removes `--disable-backgrounding-occluded-windows`
* Adds `--guest`
Reviewed By: EdmondChuiHW
Differential Revision: D56418271
fbshipit-source-id: 884c5746e93cad89f17e4ef9e3ef193a2a454eb5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44179
Fix `package.json#exports` main entry point in `react-native/oss-library-example` (which is actually at `packages/react-native-test-library`), to fix a Metro resolver warning on building RN-tester.
`"./": "./index.js"` is intended as an export map entry for the main export, whereas `".": "./index.js"` is correct (see [`PACKAGE_EXPORTS_RESOLVE`](https://nodejs.org/api/esm.html) spec).
Changelog: [Internal]
(This package is not published)
Reviewed By: cortinico, dmytrorykun
Differential Revision: D56414480
fbshipit-source-id: 01874cf11ae687aaf5aa5aa56075232f03d691b8
Summary:
This is a follow-up to https://github.com/facebook/react-native/pull/44075. I've missed the fact that `ReactConstants.UNSET` is `-1` and the default value of `numberOfLines` prop is `0`. This resulted in font size being set to the minimal value when `adjustFontSizeToFit` was used without setting `numberOfLines` to a positive value.
## Changelog:
[ANDROID] [FIXED] - Fixed `adjustFontSizeToFit` when used without `numberOfLines`
Pull Request resolved: https://github.com/facebook/react-native/pull/44165
Test Plan:
<details>
<summary>Tested on the following code</summary>
```jsx
import { Text, SafeAreaView, View, StyleSheet } from 'react-native';
export default function Test() {
return (
<SafeAreaView style={styles.container}>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }}>
Some text that fits (no adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} adjustsFontSizeToFit>
Some text that fits (adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} numberOfLines={1}>
Some text that fits (no adjust, 1 line)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} adjustsFontSizeToFit numberOfLines={1}>
Some text that fits (adjust, 1 line)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }}>
Some longer text that doesn't fit if displayed in one line (no adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} adjustsFontSizeToFit>
Some longer text that doesn't fit if displayed in one line (adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} numberOfLines={1}>
Some longer text that doesn't fit if displayed in one line (no adjust, 1 line)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} adjustsFontSizeToFit numberOfLines={1}>
Some longer text that doesn't fit if displayed in one line (adjust, 1 line)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }}>
Even longer text that doesn't even fit if it has as much as two entire lines for itself, what a darn shame (no adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} adjustsFontSizeToFit>
Even longer text that doesn't even fit if it has as much as two entire lines for itself, what a darn shame (adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} numberOfLines={2}>
Even longer text that doesn't even fit if it has as much as two entire lines for itself, what a darn shame (no adjust, 2 lines)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} numberOfLines={2} adjustsFontSizeToFit>
Even longer text that doesn't even fit if it has as much as two entire lines for itself, what a darn shame (adjust, 2 lines)
</Text>
</View>
</SafeAreaView>
);
}
```
</details>
|Old arch|New arch (without this PR)|New arch (with this PR)|
|-|-|-|
|<img width="447" alt="a_old" src="https://github.com/facebook/react-native/assets/21055725/4822f7f1-a19c-4225-9318-0eb2fec6f925">|<img width="447" alt="a_new_no_change" src="https://github.com/facebook/react-native/assets/21055725/ff594673-b362-4a81-8837-624cb1061d28">|<img width="447" alt="a_new_changed" src="https://github.com/facebook/react-native/assets/21055725/1f29c01c-1c91-4c9f-9edd-0950338b5d39">|
Reviewed By: NickGerleman
Differential Revision: D56362020
Pulled By: cortinico
fbshipit-source-id: 2aecbe66043870cf14536850ecbfb7c3890acd72
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42115
React Native Android had a concept called JSIModules, which iOS doesn't have. The JSIModule concept was introduced in the early stages of the Fabric project to represent modules that interact with JS through JSI and they are not NativeModules.
In the new architecture this concept is not really necessary and these interfaces were only used to initialize and destroy the Fabric renderer and TurboModule Manager in react native core. Bridgeless mode doesn’t use JSIModule anymore. Also, it has an explicit list of supported JSI module types, so is not open for extension.
In order to simplify RN concepts and reduce confusion with TurboModules, which also "use JSI", deleting everything related to JSIModule. This was already deprecated in 0.74.0.
Please use ReactInstanceEventListener to subscribe for react instance events instead of getJSIModule() and we recommend using TurboModules instead of JSIModules.
Changelog:
[General][Breaking] Delete JSIModule
Reviewed By: javache, cortinico
Differential Revision: D49597702
fbshipit-source-id: bc2bc190aafaf559336b341b50ffabf413474105
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44155
Add ReactSoftException in ReactHostImpl only when `onActivityResult`, `onNewIntent`and `onWindowFocusChange` do not have the context
Changelog:
[Android][Fixed] ReactSoftExceptions in ReactHostImpl only when Context is null
Reviewed By: cortinico
Differential Revision: D56325407
fbshipit-source-id: a9f8fd5772fc05d39e72236fb8edfe5f8a9d6a43
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44169
## Changelog:
[General][Changed] Disable new event loop behavior when bridgeless (new architecture) is enabled.
# What is the problem
With event loop, specifically with `batchRenderingUpdatesInEventLoop`, prop change is not delivered to Android mounting layer if the prop change was initiated from state update inside of `useLayoutEffect`, `componentDidMount` or `componentDidUpdate`. Note this has to be a prop change affecting mounting layer directly, not something consumed by Yoga, e.g. background colour or border colour.
This affects android only.
Minimal repro :
```
import React, {useLayoutEffect, useState} from 'react';
import {Button, SafeAreaView, View} from 'react-native';
function Foo() {
const [bgColor, setBgColor] = React.useState('red');
useLayoutEffect(() => {
console.log('useLayoutEffect');
setBgColor('blue');
}, []);
return (
<View
style={{
backgroundColor: bgColor,
width: '100%',
height: '100%',
}}
/>
);
}
function RNTesterApp() {
const [show, setShow] = useState(false);
return (
<SafeAreaView>
<Button title="Toggle" onPress={() => setShow(!show)} />
{show && <Foo />}
</SafeAreaView>
);
}
export default RNTesterApp;
```
# The underlaying problem
The problem is in batched rendering updates and how props are delivered to Android mounting layer.
Here is a step by step what happens in the repro above:
1. React issues asks Fabric to create new shadow node A with background colour **red**.
2. Fabric asks Android to allocate a view for shadow node A with background colour **red**.
3. React commits tree **T1** and calls layout effects. Meanwhile Fabric waits, without trying to mount the tree **T1**, to prevent painting state that is about to be updated and prevent flickering.
4. React clones node A, changing the background colour to **blue** and commits the new tree **T2**.
5. Fabric, will now go ahead and mount the latest tree **T2**. While creating mount instructions, it will drop prop updates because it believes prop updates where delivered already as part of step 2.
At first this might appear as a problem with view preallocation. But the underlaying trouble is that on Android, we currently have no way of knowing how to combine changesets from React into single folly::dynamic.
Reviewed By: javache, cortinico
Differential Revision: D56355863
fbshipit-source-id: f8616ee48e10fc10e129bb632c5d398842220d24
Summary:
On the old architecture `adjustFontSizeToFit` only shrinks the font size when there's too little space, while on the new arch it's also enlarged when there's too much space so that it always takes the entire width. This PR changes this behavior so that it only shrinks the text.
Fixes https://github.com/facebook/react-native/issues/42044
bypass-github-export-checks
## Changelog:
[IOS] [FIXED] - Fixed font size enlarging when `adjustFontSizeToFit` is set
Pull Request resolved: https://github.com/facebook/react-native/pull/44163
Test Plan:
<details>
<summary>Tested on the following code</summary>
```jsx
import { Text, SafeAreaView, View, StyleSheet } from 'react-native';
export default function Test() {
return (
<SafeAreaView style={styles.container}>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }}>
Some text that fits (no adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} adjustsFontSizeToFit>
Some text that fits (adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} numberOfLines={1}>
Some text that fits (no adjust, 1 line)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} adjustsFontSizeToFit numberOfLines={1}>
Some text that fits (adjust, 1 line)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }}>
Some longer text that doesn't fit if displayed in one line (no adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} adjustsFontSizeToFit>
Some longer text that doesn't fit if displayed in one line (adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} numberOfLines={1}>
Some longer text that doesn't fit if displayed in one line (no adjust, 1 line)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} adjustsFontSizeToFit numberOfLines={1}>
Some longer text that doesn't fit if displayed in one line (adjust, 1 line)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }}>
Even longer text that doesn't even fit if it has as much as two entire lines for itself, what a darn shame (no adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} adjustsFontSizeToFit>
Even longer text that doesn't even fit if it has as much as two entire lines for itself, what a darn shame (adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} numberOfLines={2}>
Even longer text that doesn't even fit if it has as much as two entire lines for itself, what a darn shame (no adjust, 2 lines)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} numberOfLines={2} adjustsFontSizeToFit>
Even longer text that doesn't even fit if it has as much as two entire lines for itself, what a darn shame (adjust, 2 lines)
</Text>
</View>
</SafeAreaView>
);
}
```
</details>
|Old arch (without this PR)|Old arch (with this PR)|
|-|-|
|<img width="546" alt="old_no_change" src="https://github.com/facebook/react-native/assets/21055725/f9682c0c-9a23-46b3-984d-607f83811d9e">|<img width="546" alt="old_changed" src="https://github.com/facebook/react-native/assets/21055725/c07f88fb-8ca2-415e-95c9-27bf718fc510">|
|New arch (without this PR)|New arch (with this PR)|
|-|-|
|<img width="546" alt="new_no_change" src="https://github.com/facebook/react-native/assets/21055725/173ac140-a836-4a40-83ef-c5365972700f">|<img width="546" alt="new_changed" src="https://github.com/facebook/react-native/assets/21055725/b0b00e45-17d2-4756-8ae5-a21c4ec242d9">|
Reviewed By: cortinico
Differential Revision: D56356139
Pulled By: cipolleschi
fbshipit-source-id: d11a5f4b95fb7da28a24d9136d41349d39851d9e
Summary:
`_textStorageForNSAttributesString` seems to be unused and its implementation is exactly the same as `_textStorageAndLayoutManagerWithAttributesString`. This PR removes it.
## Changelog:
[IOS] [REMOVED] - Removed `_textStorageForNSAttributesString` which was unused
Pull Request resolved: https://github.com/facebook/react-native/pull/44166
Test Plan: Built RN Tester on iOS.
Reviewed By: sammy-SC, cipolleschi
Differential Revision: D56355860
Pulled By: javache
fbshipit-source-id: d9672478c1c914a468b480d9e7cbcbb0eaf8371f
Summary:
This change splits the React-Fabric podspec in two podspecs: React-Fabric and React-FabricComponents.
The reson is that we are codegenerating some of the core components and we want for the FabricComponents to depend on ReactCodegen.
Before this change, we had a circular dependency if we make ReactFabric depends on Codegen because ReactCodegen has to depend on ReactFabric.
Now, the dependency graph would be:
`React-FabricComponents --> ReactCodegen --> React-Fabric`
and no cycle is created
## Changelog
[internal] Split React-Fabric in React-Fabric and React-FabricComponents
Reviewed By: cortinico
Differential Revision: D56306355
fbshipit-source-id: 8b609d9c962913d5d730ac1c4e3614777b5953d9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44109
(Following up from suggestion of prior diff)
For consistency with `OnSelectionChange` callback, rename `onPopupDismiss` to `onDismiss`.
Changelog:
[Android][Internal] - rename function
Reviewed By: RSNara
Differential Revision: D56168456
fbshipit-source-id: c4a32637951200736202f43294973d783ecf5ace
Summary:
RCTRootViewFactory is a great work for creating react binding view. we want to reuse the factory inside expo and would be good to have these improvements.
- exposing `reactHost` property so that we can update the RCTHost instance without recreate a factory.
- break bridgeless creation logic to a specific `createReactHost`, so that we can reuse the method for RCTHost creation
## Changelog:
[IOS][CHANGED] - Improve reusability for RCTRootViewFactory
Pull Request resolved: https://github.com/facebook/react-native/pull/43528
Test Plan: this pr should not introduce any regression and getting all ci passed
Reviewed By: cortinico
Differential Revision: D56056103
Pulled By: cipolleschi
fbshipit-source-id: 9f312707b9013c36863945c9b99a697f949f10b5
Summary:
Changelog: [Internal]
## 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
Pull Request resolved: https://github.com/facebook/react-native/pull/44154
Reviewed By: cortinico
Differential Revision: D56335973
Pulled By: arushikesarwani94
fbshipit-source-id: b481b04e218f34b0760f21106e6b5b583cb7f760
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44131
Stub tree creation is using an old differentiator path we aren't shipping today. This removes that path, so that we can unit test the new one
1. Remove `ForTesting`/`Legacy` functions
3. Update stub view tree code for API/behavior difference of new differentiator functions including unflattened views. Don't create view instructions for those, and use `mountIndex` instead of pair index
4. Remove `V2` suffix, since the old path is deleted
5. Move mounting stub test utils out of the production library
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D56227426
fbshipit-source-id: 0f525097cfb576e0228c9ca20a770fa41ddf1e0d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44096
These Android only APIs have been deprecated and are being removed for 0.75 release.
Changelog:
[Android][Removed] - UIManager.showPopupMenu() and UIManager.dismissPopupMenu() have been removed
Reviewed By: RSNara
Differential Revision: D56041827
fbshipit-source-id: e2afebf55860f33d2c8d1887e865adb4dd555e6c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44150
Changelog: [Internal]
* Adds the `RuntimeTargetDelegate::captureStackTrace` method for capturing stack traces during JS execution. The returned stack traces are opaque to RN, but may be passed back into the `RuntimeTargetDelegate`, particularly through the `addConsoleMessage` method.
* Implements `captureStackTrace` for Hermes (based on D55757947).
* Integrates `captureStackTrace` into the `console` handler (`RuntimeTargetConsole`)
Reviewed By: hoxyq
Differential Revision: D55474512
fbshipit-source-id: 3547d756844fa24c24cd9bcdc507b33c6ab673a9
Summary:
bypass-github-export-checks
Changelog: [Internal]
Rewrites all `ConsoleApiTest` test cases to use matchers instead of a homegrown solution for buffering `EXPECT_*` calls.
Reviewed By: robhogan
Differential Revision: D55485495
fbshipit-source-id: 1aa50bbbb5a3b02280ed4a0bee59682716b4fd7e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44139
I added logic to make useEffect() work w/ fragment-based nav, but I mixed up some logic. Fixed it here
Changelog: [Internal]
Differential Revision: D56264138
fbshipit-source-id: b551f0cb93cb4a0291733edbd341d3508b61e392
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44124
This API was introduced as part of Backwards Compat effort recently but now this backwards comptability is supported through BridgelessCatalystInstance. The major OSS usages are through Catalyst Instance and not through Bridgeless React Context which is why deleting this makes sense so that people do not start depending on this.
Changelog:
[Android][Removed] - Remove getJavaScriptContextHolder() from BridgelessReactContext since now it can be accessed through BridgelessCatalystInstance in Bridgeless mode
Reviewed By: RSNara
Differential Revision: D56205699
fbshipit-source-id: 175463e17c526359c2e04fec4b2104aea3949d5d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44102
Remove `getRuntimeExecutor()` from ReactContext since now it can be accessed through BridgelessCatalystInstance.getRuntimeExecutor() directly
Changelog:
[Android][Removed] - Remove getRuntimeExecutor() from ReactContext since now it can be accessed through BridgelessCatalystInstance in Bridgeless mode
Reviewed By: RSNara
Differential Revision: D56151365
fbshipit-source-id: 42bb6a6a3d729339cfb83ffdd3f7cbec314b687a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44133
# Changelog: [Internal]
Previous implementation doesn't have support for one specific case, when RN runtime was initialized and frontend is ready to be connected, but then it gets disconnected and re-connected again for the same runtime.
The issues were:
- For Fusebox: backend and frontend are correctly re-connected if user had Chrome DevTools opened, frontend invalidated via reload, then Chrome DevTools closed and re-opened again
- For DebuggingOverlayRegistry: it didn't subscribe to events from new `react-devtools-agent`, which emits events such as `showNativeHighlight` or `drawTraceUpdates`
Reviewed By: motiz88
Differential Revision: D56239185
fbshipit-source-id: ffa886b396790cb46de1d86fb000ff907edc1437
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44076
Removes fields in the root `package.json` manifest left over from the monorepo migration. `react-native/monorepo` is not a package published to npm, but is a root project configuration for the monorepo. Therefore it **doesn't need**:
- npm metadata fields (or even a `name` or `version` — I'm leaving these included due to 1/ references in fbsource, 2/ some non-Yarn tooling may complain).
- Fields used by tooling that are present in packages/react-native: `jest-junit`, `types`.
- A `peerDependency` on `react` (again, present in packages/react-native/package.json).
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D56134668
fbshipit-source-id: bc3449eb4c122eb5d885fabda9af7d19bb71faff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44097
There are two places where we use a feature specific to the system version of 'cp', the:
-X Do not copy Extended Attributes (EAs) or resource forks.
This feature isn't available in GNU's cp, which is commonly installed on macOS using:
brew install coreutils && brew link coreutils
We can avoid the problem alltogether by being specific about the path of the system cp.
Changelog: [General][Fixed] don't break script phase and codegen when coreutils installed on macOS
Reviewed By: cipolleschi
Differential Revision: D56143216
fbshipit-source-id: f1c1ef9ea2f01614d6d89c4e9eedf43113deb80c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44132
Changelog: [Breaking][Android] `DevSupportManagerFactory.create()` changed to take an additional parameter of type `PausedInDebuggerOverlayManager` (nullable)
Enables integrators of React Native Android to supply their own implementation of the Fusebox "paused in debugger" overlay. This is primarily intended for legacy Meta-internal integrations that can't use the built-in implementation based on `Dialog`. **The API will likely go away once those integrations have been migrated.**
Reviewed By: javache
Differential Revision: D56215119
fbshipit-source-id: 9cd79a6948c268a952ac28e5563ae57c90756da7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44065
React Native will try to use static view config if native view config is not available.
This will allow Fabric-only native components in Bridge mode.
Changelog: [General][Added] - Add support for Fabric-only native components in Bridge mode.
Reviewed By: cortinico
Differential Revision: D56062759
fbshipit-source-id: e562700695c14c88d11056aec1e66f8aa10a3957
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44081
Changelog: [Internal]
Migrates the Fusebox "pause in debugger" on Android from `AlertDialog` to a custom dialog, with a look and feel based closely on the equivalent Chrome feature. I've adapted the layout slightly to be mobile-appropriate (touch target sizes etc) and drawn new icon assets that are effectively hand-upscaled versions of the Chrome ones.
Reviewed By: hoxyq
Differential Revision: D56105051
fbshipit-source-id: 42d7472c8dd8f842c0dbd82c12eba102bcf59b87
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44082
Changelog: [Internal]
Adds the ability to interactively resume/step from the Fusebox "paused in debugger" overlay on Android. This uses HostCommands (D56098083) and extends the AlertDialog-based overlay (D56068445). In an upcoming diff on this stack, we'll update the design of the overlay to match Chrome's.
Reviewed By: hoxyq
Differential Revision: D56098084
fbshipit-source-id: 587b8bac7b0dd636363fc28ea7d0577b1a52d5c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44079
Changelog: [Internal]
Implements an unstyled, non-interactive version of the "paused in debugger" in-app overlay in Fusebox on Android, based on the event introduced in D56068444. The implementation in `DevSupportManagerBase` is shared across Bridge and Bridgeless.
In upcoming diffs in this stack, we'll add interactive features (namely "resume" and "step over" buttons, like in Chrome) and improve the visual styling of this overlay.
Reviewed By: hoxyq
Differential Revision: D56068445
fbshipit-source-id: a9ac2765d29d64615751b5cdf03939e0b84d2545
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44085
Changelog: [Internal]
Styles the Fusebox "paused in debugger" overlay on iOS to look similar to the Chrome implementation (and the Android implementation as of D56105051) instead of using a plain `UIAlertController`.
The only thing missing at this point is the custom asset for the "step over" icon. Unlike on Android, RN doesn't currently ship any built-in images for iOS, so I'll figure out how to do that in a separate diff and use a system-provided icon in the interim.
Reviewed By: hoxyq
Differential Revision: D56116881
fbshipit-source-id: a07e1a7592c4210606a0e61366ad750faf6148bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44083
Changelog: [Internal]
Adds a working, interactive "paused in debugger" overlay to Fusebox for iOS (similar to what D56068445 + D56098084 did on Android). The overlay is rendered using a standard `UIAlertController`. In upcoming diffs on this stack we'll style the overlay to look more like the Chrome implementation.
Reviewed By: hoxyq
Differential Revision: D56105959
fbshipit-source-id: d752d6611b2d9e48b67a82f3a9a96c7785c31a7a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44114
In OSS, we should use the ClassFinder wrapper as the `Class.byName` calls will never succeed (we don't run the annotation processor in OSS).
Changelog:
[Internal] [Changed] - Use ClassFinder inside ViewManagerPropertyUpdater
Reviewed By: arushikesarwani94
Differential Revision: D56191175
fbshipit-source-id: a67195e983774872e27d35456b45651540411e2b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44128
Changelog: [Internal]
idk what happened but this link got abbreviated when i copypastad it, fixing it here
Reviewed By: javache
Differential Revision: D56228228
fbshipit-source-id: 35c5c9fb44e82083773302618474c1e3bbc71712
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44080
## Design
Adds a new public `HostTarget::sendCommand` method, enabling integrators to send simple imperative commands to the target.
As an implementation detail, the commands are translated internally to CDP and sent over a dedicated `HostTargetSession` (encapsulated in `HostCommandSender`). Any response from the underlying Agent is ignored.
From the caller's perspective, these commands don't occur in the context of a session at all, and from the frontend's perspective, only the *effects* of the commands (if any) are seen.
## Use case
HostCommands are specifically useful when we want to resume/step execution in response to a UI action. The commands map directly to the `Debugger.resume` and `Debugger.stepOver` CDP methods.
NOTE: This is inspired by Chrome/V8's existing support for multiple concurrent CDP sessions. Any CDP client can successfully send `Debugger.resume` and `Debugger.stepOver` (without even subscribing to debugger events using `Debugger.enable`) and affect the state of other ongoing debugging sessions.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D56098083
fbshipit-source-id: 013ab748b360f700c453cf1447fb82d6d0d77c6f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44105
Previously, we skipped calling the ReactDelegate callback functions when the ReavtNavigationFragment was destroyed because it set the current activity to null when we need to actually keep the reference to the activity. However, skipping this entirely also skips core clean up logic, such as running the return() function for useEffect().
Instead of skipping the callback function entirely, we just need to make sure we don't set mCurrentActivity to null. I followed D30504616 to configure an option to not set mCurrentActivity to null if mKeepActivity flag is set on the ReactInstanceManager.
Changelog: [Internal]
Reviewed By: keoskate
Differential Revision: D56167533
fbshipit-source-id: cb3620e21599683e0c6bbc5a6a9c4f384fdbcc51
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44104
We previously added the option to skip calling the delegate lifecycle events in D55646221 to support fragment-based navigation. However, we don't actually want to skip calling these events as they run some core clean up logic, such as calling the return value of useEffect(). There's a better way to get this working with fragment-based nav (see next diff).
Changelog:
[Internal] [Changed] - Remove option to skip calling delegate on ReactFragment lifecycle events
Reviewed By: keoskate, cortinico
Differential Revision: D56167614
fbshipit-source-id: 3a4b91a303a27c0e19644a4e6611229211a1e530
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44120
changelog: [internal]
Prevent measuring the same text twice in `ParagraphShadowNode`.
The current implementation calls `TextLayoutManager::measure` twice for a single `ParagraphShadowNode`. The first time to measure the node for Yoga. The second time inside `ParagraphShadowNode::layout`. I think the original author counted on the cache inside of `TextLayoutManager` to deal with this, but this is not always the case and `TextLayoutManager::measure` is called with two different available widths, leading to cache miss and fills the cache faster.
Reviewed By: NickGerleman
Differential Revision: D55757264
fbshipit-source-id: 0bf8b49f062f802a4e2f04cad1bf1d4bf001b870
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44094
# Changelog: [Internal]
This script was added in D54770207.
This will be DEV-only for 2 reasons:
1. We need to double-check if Fusebox is ready to be used with production bundles, I don't think so.
2. Previous integration with RDT was DEV-only
Reviewed By: motiz88
Differential Revision: D56141041
fbshipit-source-id: 1141c65a5811d0f56c944e25a319ba21211b7836
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44088
This is a power user option for Release Crew members when testing locally — a flag to bypass being blocked on the latest in-progress CircleCI job and instead fetch build artifacts from the most recent successful pipeline (typically `HEAD~1`).
Example use cases where the latest pushed commit isn't impactful:
- An iOS-only fix, meaning Android can be tested now.
- A trivial fix that applies to CI only (e.g. RNTester Podfile.lock update).
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D56138727
fbshipit-source-id: f9884bdb289a92486807e8e033b756466fcec559
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44116
This is just the bridgeless analogue to .hasCatalystInstance()
Changelog: [Android][Added] - Introduced ReactContext.hasReactInstance() to replace .hasCatalystInstance()
Reviewed By: fabriziocucci
Differential Revision: D56164488
fbshipit-source-id: 8be4676e18dc7df4765746f46cf36e62405b4ffa
Summary:
As part of decoupling our dependency on the react-native-community/cli, the `react-native.config.js` which is
a part of the community's config ecosystem should probably be entirely removed from the react-native package.
As part of this, we're making the config fail gracefully if these dependencies aren't available in a user's project:
- react-native-community/cli-platform-android
- react-native-community/cli-platform-ios
Changelog: [Internal]
This isn't going to be a visible change to any users.
bypass-github-export-checks
Reviewed By: cortinico
Differential Revision: D56137820
fbshipit-source-id: 528e25809a83b90e79b806a875001fc0f06db1cf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44078
Changelog: [Internal]
Adds stub support for the [`Overlay.setPausedInDebuggerMessage`](https://cdpstatus.reactnative.dev/devtools-protocol/tot/Overlay#method-setPausedInDebuggerMessage) CDP method to `HostAgent` in the Fusebox backend, and propagates it into the Android and iOS integrations through `HostTargetDelegate`.
We take care to call `HostTargetDelegate::onSetPausedInDebuggerMessage()` a final time with a null `message` parameter, regardless of whether the client has actually sent the corresponding CDP message. Since multiple clients might be connected concurrently, we only send the `null` message when the *last* client which has requested a non-null message has disconnected.
Reviewed By: robhogan
Differential Revision: D56068444
fbshipit-source-id: c26e1cf17dec8d7dbb7edd5ab7fa3133642628ff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44092
In a setup where a device retrieves a bundle from `http://127.0.0.1:8081`, but this is tunnelled to a remote host with only an IPv6 stack (eg, FB dev servers), the host running the inspector-proxy will fail to fetch source or source maps from 127.0.0.1 despite typically being on the same host (indeed, process) as Metro.
This causes a surprising inconsistency where using a bundler URL of `localhost` from the device results in source maps being inlined into `Debugger.scriptParsed`, but using a bundler URL of `127.0.0.1` causes inspector-proxy to fall back to preserving URLs, which are typically fetched lazily by CDT later.
This should be unnecessary once we've implemented CDP `Network.loadNetworkResource` and removed `Debugger.scriptParsed` rewriting, but for now it brings IPv6 tunnelled servers in line with local servers.
Changelog:
[General][Changed] Inspector proxy: Rewrite 127.0.0.1 to localhost in source map URLs for better IPv4->IPv6 tunnelling support.
Reviewed By: motiz88
Differential Revision: D56138742
fbshipit-source-id: b65c9cc8225a0ed54cf32171f640ef9e6408c762
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44103
Changes here fixes events in PopupMenuAndroid not being triggered correctly.
Issuses were:
1) naming mismatch
2) wrong parameters were set for the Event Map
3) missing code in .cpp
Applied fixes:
1) consistent event naming
2) fixed key used for event mapping
3) re-ran codegen to update .cpp files
## Changelog:
[Android] [internal] - Fix issue with PopupMenuAndroid event callback not working
Steps took to run codegen for this diff: https://www.internalfb.com/intern/phabricator/paste/markdown/P1214671854/
This diff is patching issues from D55531870
Reviewed By: RSNara
Differential Revision: D56164235
fbshipit-source-id: 4cf66ad3cfd753c146c5e219f27910834731e183
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44098
This sets `QualiferAlignment` so that code is automatically formatted to west const.
I did a pass at this before, but now that we are on new Clang Format, we can enforce it automatically, and I think a couple more cases not previously changed now are.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D56143678
fbshipit-source-id: 8f12b288476ea6019fd7d7a93a39b4fe2e75af14
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44089
While doing the release of 0.74.0-RC.9, we encountered some failures while building because the committed project had some new flags that have been added by cocoapods and that required Ccache.
However, Ccache is not a hard requirement to run React Native and the build started failing on systems that does not have ccache installed.
That happened because we were missing the piece of code that removed Ccache from the project in case the tool is not installed in the system.
We already committed such commit in the stable branch of 0.74, with [this commit](https://github.com/facebook/react-native/commit/2b18fdf8063b423a0fb5762f2c6044244b4c35e6). This change will port the same fix in main.
## Changelog
[iOS][Fixed] - Make sure to remove ccache scripts when ccache is not installed
Reviewed By: cortinico
Differential Revision: D56140015
fbshipit-source-id: 24e7ebb4e5c08766b29705e8b6f03c3f164a96ab
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44086
When a debugger frontend is connected to inspector-proxy via another proxy or tunnel that times out on idle (such as [VS Code's remote tunnel](https://github.com/microsoft/vscode/blob/main/src/vs/platform/tunnel/node/tunnelService.ts)), the connection between proxy and debugger may be dropped.
In addition, when the connection is dropped without a closing handshake, the proxy does *not* detect the disconnection - no disconnect is logged to the reporter and no notifications are sent to any connected devices.
This adds a mechanism using the WebSocket-standard `ping` and `pong` frames to:
1. Keep the connection alive
2. Detect when the debugger has gone away
Note that as all WebSocket clients already **must** reply to a ping with a pong, this is non-breaking for compliant implementations: https://datatracker.ietf.org/doc/html/rfc6455#section-5.5.2
Changelog:
[General][Added] Inspector proxy: Add ping/pong keepalive to debugger connections.
Reviewed By: hoxyq
Differential Revision: D56069185
fbshipit-source-id: e322de631c652a502f3d554c15ed5412a751ee04
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44087
The `mFabricEnabled` field is initialized to false. This is a misalignment with how other classes are behaving like
ReactActivityDelegate.
Changelog:
[Internal] [Changed] - ReactFeatureFlags.mFabricEnabled should default to ReactFeatureFlags.enableFabricRenderer
Reviewed By: arushikesarwani94
Differential Revision: D56013057
fbshipit-source-id: fcab903ab42d3b30094dcebbcf5b662cd2f2c506
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44040
This is just a clarification for the KDoc of this property.
Changelog:
[Internal] [Changed] - Clarify documentation for debuggableVariants
Reviewed By: andrewdacenko
Differential Revision: D56012825
fbshipit-source-id: 837d2dbc0f7ca5853ba1cedf71a4a5c36661318f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43722
This change adds a drawable, when when drawn on the bounds of a border-box sized view, will draw a spec compliant box-shadow outside the box. This is reliant on Android `RenderNode` and `RenderEffect` APIs provided by API 31.
Inset box shadows can also be added using a similar method, but this is not done yet.
The code which manages this is in flux, but the underlying drawable should be good. Will add some tests once it's more wired up.
Changelog: [Internal]
Reviewed By: javache, cortinico
Differential Revision: D55561465
fbshipit-source-id: 6180568cff2779b826e73bb9184dbe042863b262
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43983
We duplicate some pretty hairy code related to conversion between logical and physical edges, along with the grafting between uniform and non uniform radii. This encapsulates border radius resolution/assignment logic.
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D55635743
fbshipit-source-id: 906c35af2bf18f0586d71d05f9cf61d4248ede1e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43721
Makes some changes to `FilterHelper` to expose RenderEffects for filters publicly to other classes in the module. We use this in box-shadow, in order to reuse logic for sigma accepting blur filters.
Also fixes a crash related to the conversions back and forward between sigma and radius, where small values would cause a crash.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D55563775
fbshipit-source-id: fabc888eecb451e75a88c8633fe5cca1f6644faa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43720
This lets us use BG drawing code in rules which view depends on. I also removed some lib usage.
The original class is still present, subclassing the class in its new location, but is marked deprecated.
Next diffs in stack clean up some of our own now deprecated usage.
Changelog:
[Android][Breaking] - Deprecate `ReactViewBackgroundDrawable` in favor of `CSSBackgroundDrawable`
Reviewed By: javache
Differential Revision: D55565035
fbshipit-source-id: 501b3e2f674c09a88b1825657ba6349823054e8c
Summary:
After a [recent change](https://github.com/facebook/react-native/commit/90296be1d4fab09a52e02dd09f34f819136d0a07) we break part of the integration with the debug menu, which is was using the presence/absence of the bridge to decide whether we were in bridge or bridgeless.
For backward compatibility reasosn, the bridge ivar is now populated with the bridgeProxy, so just checking whether is nil or not is not enough to verify whether we are in bridge or in bridgeless mode anymore.
## Changelog:
[iOS][Fixed] - Make sure that the Open Debugger appears in bridgeless mode
Reviewed By: fkgozali
Differential Revision: D56067897
fbshipit-source-id: e2501ed730ff35bc755c24ef400130c551032e28
Summary:
We would set the value of _bridge ivar to bridgeProxy for turbo module in bridgeless mode in https://github.com/facebook/react-native/issues/43757 , so we need to change the way of bridgeless/bridge check.
## Changelog:
[IOS] [FIXED] - Change bridgeless check in dev menu
Pull Request resolved: https://github.com/facebook/react-native/pull/43976
Test Plan: Dev menu shows bridgeless/bridge mode correctly.
Reviewed By: christophpurrer
Differential Revision: D56056640
Pulled By: cipolleschi
fbshipit-source-id: 1358c3027c1d5f12c70dd4486cc1d5975c7a185a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44056
## Changelog:
[Internal] -
Was looking into how devsupport is exactly implemented on different platforms (in the context of doing it for a new platform) and figured I may just well convert this to Koltin in the process (helped to understand inner working details as well).
Reviewed By: christophpurrer
Differential Revision: D56058560
fbshipit-source-id: 1e2ffcec480c5fa3fd8b6494c29a0db6f94aec78
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44055
## Changelog:
[Internal] -
Was looking into how devsupport is exactly implemented on different platforms (in the context of doing it for a new platform) and figured I may just well convert this to Koltin in the process (helped to understand inner working details as well).
Reviewed By: christophpurrer
Differential Revision: D56052137
fbshipit-source-id: 25280a57f46bec95dc1437ea6eb2eef08332797f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44058
## Changelog:
[Internal] -
This was revealed when running an ASAN build on MacOS - we were doing an unsafe downcast from `LayoutableShadowNode->ViewShadowNode` inside `ShadowTree::emitLayoutEvents`.
Which, even though incidentally worked, is generally unsafe, as we may get e.g. `ImageShadowNode` there, which doesn't inherit from `ViewShadowNode`.
That downcast to `ViewShadowNode` wasn't even required, to begin with, as all the needed information can be already extracted from the `LayoutableShadowNode` itself.
Reviewed By: christophpurrer, javache
Differential Revision: D56062334
fbshipit-source-id: 08d5b3f5e0c57dc51b051d23506c7933581fea29
Summary:
The goal of this PR is to allow the usage of `RCTRootViewFactory` from Swift. The issue with `RCTTurboModuleManager.h` is that it uses C++ in its header file, which is not allowed in Swift, making this initializer unavailable.
This PR allows users to just pass configuration + adds a nullable annotation to bundleURL.
Example usage:
```swift
import Foundation
import UIKit
import React
import React_RCTAppDelegate
main
class AppDelegate: NSObject, UIApplicationDelegate {
var window: UIWindow?
private var rootViewFactory: RCTRootViewFactory?
func application(
_ application: UIApplication,
didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil
) -> Bool {
// Create config
let config = RCTRootViewFactoryConfiguration(
bundleURL: self.bundleURL(),
newArchEnabled: true,
turboModuleEnabled: true,
bridgelessEnabled: false
)
// Create rootview factory
rootViewFactory = RCTRootViewFactory(configuration: config)
// Create rootview
let rootView = rootViewFactory?.view(withModuleName: "RN0740RC4")
let rootViewController = UIViewController()
rootViewController.view = rootView
// Create window and assign view controller
window = UIWindow(frame: UIScreen.main.bounds)
window?.rootViewController = rootViewController;
window?.makeKeyAndVisible()
return true
}
func bundleURL() -> URL? {
RCTBundleURLProvider.sharedSettings().jsBundleURL(forBundleRoot: "index")
}
}
```
## Changelog:
[IOS] [FIXED] - Allow usage of `RCTRootViewFactory` from Swift
Pull Request resolved: https://github.com/facebook/react-native/pull/43590
Test Plan: CI Green, check usage of initializer without turbo module delegate
Reviewed By: christophpurrer
Differential Revision: D56055938
Pulled By: cipolleschi
fbshipit-source-id: c80d9f7f707c376f590f3dc4c9bb8f88f2e57e6a
Summary:
Changelog: [Internal]
With the Hermes fix in D55250610, we're able to make stronger assertions in `CDPAgentReentrancyRegressionTest`, which is an integration test covering a class of related bugs.
bypass-github-export-checks
Reviewed By: mattbfb
Differential Revision: D55962593
fbshipit-source-id: 09d03effc51d6f1904842f1c7c2f7e4407fefc63
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44022
changelog: [internal]
move the new state reconciliation algorithm to the unified feature flag system.
Reviewed By: rubennorte
Differential Revision: D55965530
fbshipit-source-id: 3edde0858a670e86dc2d1cb561f03f584ff21896
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44021
changelog: [internal]
This is an evolution of cloneless state progression, introduced in D49012353.
# Problem
## When React clones the wrong node revision
Whenever React wants to commit a new change, it first needs to clone shadow nodes. React sometimes clones from the wrong revision. This has mostly been fine, Fabric does state reconciliation to pass newest state forward. State reconciliation is needed, as we need to keep native state in the shadow tree.
However, when React clones a node that has never been through layout step, it will clone a node without any layout information and its yoga node is dirtied. Even though there might be a subsequent revision of the node with layout information already calculated. As a result, Yoga needs to traverse bigger parts of the tree, even though layout has been calculated before. It is just cached on a different revision that was used as a source.
There are two main sources (there is more but they don't help to paint the picture) when this can happen. Background Executor and State Progression. Let's start with the simpler one but less severe: Background Executor.
Background Executor moves layout from JavaScript thread. React can start cloning nodes right away, even though they might not have layout information calculated yet. This is a race condition and depending on when the node is cloned, we can see different results. In this case, React eventually clones node from the correct revision with the layout cache. It will be in a correct state in the end. This case is not as bad as far as I can tell but I included it here because it better illustrates what is going on.
State Progression is where things get worse. In this scenario, React will never clone from the correct revision and will never recover from this. Anytime React clones node with a state that needs to be progressed, it will get cloned one more time during commit but React will hold the wrong revision. Depending on where this node is located in the view hierarchy, it may lead to expensive layout calculations.
Example:
Let's use notation A/r1 as node of family A revision 1.
- React calls create node. Node A/r1 is created and React holds reference to this. It will later use it to clone it.
Node A has native state that was updated. New revision A/r2 is created. Now React and RN do not observe the same node anymore (this is sometimes necessary).
- React now clones node A to create A/r3. This revision may have the wrong yoga cache. Now this might sound like one off but let's explore what happens next.
- During commit, Fabric must do state progression to give node A/r3 state from A/r2. This requires cloning and new revision A/r4 is created. React has again a wrong node that does not have Yoga cache and can't recover from this state.
The blast radius of this varies depending on where in the tree the node is.
# Solution - State Alignment Mechanism
The main principle for new state progression is to make sure React references the correct shadow node after commit to avoid layout cache miss on subsequent commit.
Agenda for the diagrams below:
- Black colour: node was not cloned.
- Blue colour: node was cloned by React.
- Orange colour: node was cloned by host platform.
- Blue and Orange colour: node was cloned by both React and host platform.
## Simple cases
### Base case
{F1483309510}
### React Cloned
{F1483308354}
### React and host platform clone the same node
{F1483309324}
## Medium difficulty
### React clones a different branch than host platform
{F1483349393}
### React deletes a branch that was cloned by host platform
{F1483349259}
### React changes structure of the tree, node cloned by host platform remains
{F1483349758}
### React reorders nodes that were cloned by host platform
{F1483350283}
Reviewed By: rubennorte
Differential Revision: D53405702
fbshipit-source-id: c7d4b0772c144c86d72e39965e9626a2daefa6fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44020
changelog: [internal]
This diff only adds more tests for state reconciliation to cover more cases.
Thanks to this, I discovered bugs in my previous implementation of cloneless state progression.
Reviewed By: rubennorte
Differential Revision: D55926491
fbshipit-source-id: 5945ba9bc1d6fed111fbca07e19589cbef50712d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44019
changelog: [internal]
use size_t instead of int32_t so that caller of `ShadowNode::replaceChild` does not need to cast.
Reviewed By: rubennorte
Differential Revision: D55923333
fbshipit-source-id: 8f8062708d9aaddedb600aa7dac419a177e2ab24
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44018
changelog: [internal]
New trait ClonedByNativeStateUpdate is used to mark the path that was cloned by native state update.
This is a pre-requisite for new state reconciliation algorithm. It will mark part of shadow tree that was affected by native state update.
Reviewed By: rubennorte
Differential Revision: D55922776
fbshipit-source-id: 6d4515460346c341af3ee6117d570b3201328bc9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44017
changelog: [internal]
Add an option to mark all nodes clone indirectly by `ShadowNode::cloneTree`.
This is a pre-requisite for new state reconciliation algorithm. It will be used to mark part of shadow tree that was affected by native state update.
Reviewed By: rubennorte
Differential Revision: D55745323
fbshipit-source-id: 5e2a2e8a572cc5077d907608f83992a43625d58e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44016
changelog: [internal]
Add option to set traits when node is created or cloned via ShadowNodeFragment.
This is a pre-requisite for new state reconciliation algorithm.
Reviewed By: rubennorte
Differential Revision: D55691094
fbshipit-source-id: 0bdf024c3c9b28304969ddc9b9c63b0f0b924bb0
Summary:
IOS builds started failing due to Xcode version checks falsely claiming newer versions are not installed
TODO affecting Xcode version checking reads: Remove this code after April 2024, when Apple will push the lower version of Xcode required to upload apps to the Store.
## Changelog:
remove deprecated Xcode version check
Pick one each for the category and type tags:
[IOS] [REMOVED] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/43949
Test Plan: Should run as before, only the deprecated version check has been removed.
Reviewed By: dmytrorykun
Differential Revision: D56056701
Pulled By: cipolleschi
fbshipit-source-id: 47288e04bd1cfc989cf05994cb47421fd2379af0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44026
Changelog: [Android][Removed] Delete ReactContext.initializeWithInstance(). ReactContext now no longer contains legacy react instance methods. Please use BridgeReactInstance instead.
Yet another attempt to land this (last one was D55505416).
Copy-pasting below the amazing summary from RSNara.
## Context
Prior, ReactContext used to implement bridge logic.
For bridgeless mode, we created BridgelessReactContext < ReactContext
## Problem
This could lead to failures: we could call bridge methods in bridgeless mode.
## Changes
Primary change:
- Make all the react instance methods inside ReactContext abstract.
Secondary changes: Implement react instance methods in concrete subclasses:
- **New:** BridgeReactContext: By delegating to CatalystInstance
- **New:** ThemedReactContext: By delegating to inner ReactContext
- **Unchanged:** BridgelessReactContext: By delegating to ReactHost
## Auxiliary changes
This fixes ThemedReactContext in bridgeless mode.
**Problem:** Prior, ThemedReactContext's react instance methods did not work in bridgeless mode: ThemedReactContext wasn't initialized in bridgeless mode, so all those methods had undefined behaviour.
**Solution:** ThemedReactContext now implements all react instance methods, by just forwarding to the initialized ReactContext it decorates (which has an instance).
NOTE: Intentionally not converting `BridgeReactContext` to Kotlin to minimize the risk of these changes.
Reviewed By: RSNara
Differential Revision: D55964787
fbshipit-source-id: b404efe0c7095894fa815165cc8682f78dccfa17
Summary:
X-link: https://github.com/facebook/react-fbsource-import/pull/5
Pull Request resolved: https://github.com/facebook/react-native/pull/44046
changelog: [internal]
`passthroughAnimatedPropExplicitValues` from sticky header were removed in D46703731 with assumption that native animations trigger on complete callback and it can be used as a synchronisation point for Fabric.
On complete callback is triggered for native animations do trigger on complete callback with one exception: when the native animation is driven by scroll view's content offset.
As a result, synchronisation between React and Fabric doesn't happen and Pressability stops working if there is a pressable element in the sticky header.
Reviewed By: rubennorte
Differential Revision: D56005408
fbshipit-source-id: daead3a566e157593aa3f1b3ae3553ec1094b6da
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43418
Changelog: [Internal]
This diff adds a script, which will be later imported from `InitializeCore` to setup a required global for communication between React Native runtime (RDT Backend in it) and Chrome DevTools Frontend (RDT Frontend in it).
See README for the architecture overview and how bidirectional communication is established.
Corresponding PR in Chrome DevTools frontend - https://github.com/facebookexperimental/rn-chrome-devtools-frontend/pull/15
Reviewed By: motiz88
Differential Revision: D54770207
fbshipit-source-id: 0f0f04a338b5c7eab817c843a99b07cca95e57fd
Summary:
If you check the source of truth `packages/react-native/Libraries/Components/Touchable/TouchableHighlight.js` I'll find that `TouchableHighlight` is a result of `React.forwardRef(...)` :
https://github.com/facebook/react-native/blob/44d59ea6f9a1705487314e33de52f7056651ba25/packages/react-native/Libraries/Components/Touchable/TouchableHighlight.js#L382-L391
So the TS type isn't correct : (
```tsx
<TouchableHighlight ref={ref => { }} />
// ^^^ ref should be a `View` (but now it's `TouchableHighlight`)
```
---
**Breaking changes**
As `TouchableHighlight` isn't class anymore it can't be used as value & type
```tsx
import {TouchableHighlight} from 'react-native';
const ref = useRef<TouchableHighlight>();
// ^^^ TS2749: TouchableHighlight refers to a value, but is being used as a type here.
// Did you mean typeof TouchableHighlight?
```
**Recommend solution:** use build-in react type `React.ElementRef`
```diff
-const ref = useRef<TouchableHighlight>();
+const ref = useRef<React.ElementRef<typeof TouchableHighlight>>();
```
Also, it possible to use `View` as type:
```diff
-const ref = useRef<TouchableHighlight>();
+const ref = useRef<View>();
```
## Changelog:
[GENERAL] [BREAKING] - [Typescript] Transform TouchableHighlight from JS class to ForwardRef component
Pull Request resolved: https://github.com/facebook/react-native/pull/44038
Test Plan: See: `packages/react-native/types/__typetests__/index.tsx`
Reviewed By: NickGerleman
Differential Revision: D56015309
Pulled By: dmytrorykun
fbshipit-source-id: fee346536787a5921626ed69a4c01da2b599dc2f
Summary:
If you check the source of truth `packages/react-native/Libraries/Components/Touchable/TouchableOpacity.js` I'll find that `TouchableOpacity` is a result of `React.forwardRef(...)` :
https://github.com/facebook/react-native/blob/f7eaf63881b23216c06ab3c81ea94d0312cd6a7b/packages/react-native/Libraries/Components/Touchable/TouchableOpacity.js#L326-L335
So the TS type isn't correct : (
```tsx
<TouchableOpacity ref={ref => { }} />
// ^^^ ref should be a `View` (but now it's `TouchableOpacity`)
```
---
**Breaking changes**
As `TouchableOpacity` isn't class anymore it can't be used as value & type
```tsx
import {TouchableOpacity} from 'react-native';
const ref = useRef<TouchableOpacity>();
// ^^^ TS2749: TouchableOpacity refers to a value, but is being used as a type here.
// Did you mean typeof TouchableOpacity?
```
**Recommend solution:** use build-in react type `React.ElementRef`
```diff
-const ref = useRef<TouchableOpacity>();
+const ref = useRef<React.ElementRef<typeof TouchableOpacity>>();
```
Also, it possible to use `View` as type:
```diff
-const ref = useRef<TouchableOpacity>();
+const ref = useRef<View>();
```
## Changelog:
[GENERAL] [BREAKING] - [Typescript] Transform `TouchableOpacity` from JS `class` to `ForwardRef` component
Pull Request resolved: https://github.com/facebook/react-native/pull/44030
Test Plan: See: `packages/react-native/types/__typetests__/index.tsx`
Reviewed By: NickGerleman
Differential Revision: D56017133
Pulled By: dmytrorykun
fbshipit-source-id: 58f4c1a14c9b3bd2407ea6c825a90b355acb16bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44005
When using frameworks on iOS, there is a possibility that modules import the Spec.h file twice and this might end up in a Redefinition of some symbols and duplication of symbols which ends up in build errors, as reported here: https://github.com/facebook/react-native/issues/42670.
This change adds some [`#include guards`](https://en.wikipedia.org/wiki/Include_guard) in codegen to avoid the redefinition of those symbols if the header is imported/included multiple times.
Note: I also experimented with `#pragma once`, but it looks like Apple is not happy with that directive. [It seems](https://forums.developer.apple.com/forums/thread/739964) that it started working flakely from Xcode 15.
## Changelog:
[General][Fixed] - Make sure that we can't include Codegen symbols multiple times
Reviewed By: cortinico
Differential Revision: D55925605
fbshipit-source-id: 15ca076aace2ffbd03ab8fa8a68a3d8ce0d1ea65
Summary:
this PR cleans up an outdated compatibility function in AndroidExecutors. the function in question was checking whether the code was running on Gingerbread or later - this is no longer needed, as RN requires Marshmallow or later.
## Changelog:
[INTERNAL] [FIXED] - Clean up outdated compatibility function
Pull Request resolved: https://github.com/facebook/react-native/pull/43958
Test Plan: this should work as normal.
Reviewed By: cortinico
Differential Revision: D55877661
Pulled By: dmytrorykun
fbshipit-source-id: 02eac50b0898d683f6abf731bf8e438ae4219a41
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43979
changelog: [internal]
using `availableSize` instead of `measurement` to avoid dependency on calling `textLayoutManager_->measure` before dispatching `onTextLayout` event.
This is important in subsequent optimisation.
Reviewed By: javache
Differential Revision: D55796594
fbshipit-source-id: 06b516e2afaf668c6359ad86b570229824933bae
Summary:
## 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
-->
Changelog: [Internal] Generated changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/44008
Reviewed By: christophpurrer
Differential Revision: D56017161
Pulled By: dmytrorykun
fbshipit-source-id: 512c576a055a17b37a1f9fd5e328a1ff5165b398
Summary:
Using version information previously housed in react-native-communtiy/cli
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D55960009
fbshipit-source-id: 38f8b2310942a9337a7b64b51a87ae629d9bbbaf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44039
Changelog: [Internal]
Get label color from theme to fix dark mode.
Reviewed By: NickGerleman
Differential Revision: D56011777
fbshipit-source-id: 3ef14d6437c51118f0c0db3950b24f7e71d33fb3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43914
changelog: [internal]
This QE with caching text measurement and NSTextStorage did not deliver the desired results. Let's remove the code to simplify the text measure infra.
Reviewed By: javache
Differential Revision: D55753670
fbshipit-source-id: b194c4ca1eded70b0d00da748716628c264a47b9
Summary:
Capturing the correct attribution in the licenses as well as adding some documentation.
I think the code will have changed significantly enough across the files that once we change to flow, we can drop the attribution in the files but leave the mention in the README.
Changelog: [Internal]
bypass-github-export-checks
Reviewed By: huntie
Differential Revision: D55752899
fbshipit-source-id: b436d745d5ad439661d2af840b2cc8df4bff0038
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44041
changelog: [internal]
Building rn-tester left artifacts that would be picked up by mercurial.
```
❯ hg s
? rn-tester.xcodeproj.local/Project Settings.plist
? rn-tester.xcodeproj.local/Project Settings.plist.lock
```
To mitigate this, add `rn-tester.xcodeproj.local` introduce .gitignore for rn-tester.
Reviewed By: fabriziocucci
Differential Revision: D56006193
fbshipit-source-id: 5701f1adf395e98f84ca59574dbd8747cf7e85db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44010
X-link: https://github.com/facebook/yoga/pull/1641
Yoga has quirk where newly constructed nodes are clean, which isn't really correct. Normally never shows in in real code because setting a style or children will dirty. Fabric doesn't use the public APIs that do this dirtying, so it ends up getting creative instead.
We should fix so that newly constructed nodes are dirty. Copy-constructed Nodes (also only a Fabric thing, will retain original dirty flag.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D55855328
fbshipit-source-id: be49efaf8ac29351f8e5ec509bd9912546944332
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44028
Changelog: [Internal]
While testing something completely unrelated (i.e. D55964787), I've noticed that [test_android](https://github.com/facebook/react-native/actions/runs/8635097933/job/23673157303?pr=44026) actually failed on Github with this error:
> Task :packages:react-native:ReactAndroid:compileDebugUnitTestKotlin
e: file:///__w/react-native/react-native/packages/react-native/ReactAndroid/src/test/java/com/facebook/react/views/image/ReactImagePropertyTest.kt:62:38 Smart cast to 'CatalystInstance' is impossible, because 'catalystInstanceMock' is a mutable property that could have been changed by this time
Reviewed By: RSNara
Differential Revision: D55982797
fbshipit-source-id: a49e766ae95e22603293326da93007d78250da6a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43998
Another library with an empty JNI_OnLoad method.
Moving it to `INTERFACE` so it exposes only the Header it has declared.
This removes the `libreactperfloggerjni.so` from the final APK.
Changelog:
[Internal] [Changed] - Move reactperfloggerjni to INTERFACE library
Reviewed By: javache
Differential Revision: D55919228
fbshipit-source-id: 634f4f6013825b0de8827b3143a012e6c880509d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44015
Changelog: [internal]
## Context
When we introduced synchronous state updates in Fabric, we saw some crashes on coming from the mounting layer on Android.
It seems some of these crashes are caused by nested mount operations. When we're mounting some views, like [scroll views](https://github.com/facebook/react-native/blob/881c0bc8970b9e402df6b4f87e1759b238b24735/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/scroll/ReactHorizontalScrollView.java#L383), we dispatch state updates that end up doing more mutations. When we were doing these state updates asynchronously, all the original mutations were processed before these updates, but now that we do them synchronously, the mutations are interleaved causing errors.
## Changes
This introduces a new flag that will force all the mutations going through `MountItemExecutor` in `FabricUIManager` to be batched instead of executed synchronously. This fixes the issues I saw locally and I'm expecting this will unblock synchronous state updates in production.
Potentially, this might fix other crashes we've been seeing with a low frequency.
Reviewed By: sammy-SC
Differential Revision: D55942125
fbshipit-source-id: b8d9c145ec307de7318dbbed14880bc9a84fdb2a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43992
# Changelog:
[Internal] -
While looking into implementing native DevLoadingView on non-Android/iOS platform, I realized that the current code inside `LoadingView.android.js`/`LoadingView.ios.js` is functionally identical, and can be transformed into each other with simple code transformations.
This diff:
* Renames `LoadingView` into `DevLoadingView` (as it's arguably more fitting name, given that it also relies on `NativeDevLoadingView` native module implementation)
* Merges the iOS/Android specific JS files into one
* Factors usage of the colors out of the actual logic, to better separate presentation from the business logic
From the perspective of public APIs there should be no changes.
Reviewed By: christophpurrer
Differential Revision: D55914787
fbshipit-source-id: 656311db80e5ee03f60ee7ffcf5f405ca99a9ce5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43068
This diff adds `react-native-test-library` package.
It contains native module and native component example, and targets both the new and the old architecture. It has structure similar to many OSS React Native libraries, and is supposed to be used to test the integration with third-party libraries.
It is integrated with RNTester as the **OSS Library Example** screen.
{F1457510909}
**Change Background** tests native commands.
**Set Opacity** tests native props.
**Get Random Number** tests native module.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D50793835
fbshipit-source-id: ff6daefab10e6e9f13049e3013f8f63cfa8a929e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43995
With a previous change, we started taking snapshots of the Modal every time a Fabric mounting event was happening. this might cause perf regression when a modal is presented, and there is no need to take a snapshot that often.
This change moves the snapshotting code right before the dismissal of the Modal.
## Changelog
[iOS][Changed] - Move the snapshotting code before the dismissal.
## Facebook
This should fix T179288585, T184520225
Differential Revision: D55914776
fbshipit-source-id: 6679babf7f72aef7254113497116d5482640e789
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43999
Currently NewArch-BridgeMode is partially broken when creating views via `ReactDelegate`.
That's because we're using the ctor that doesn't account for `Boolean: fabricEnabled`.
That means that the `RootView` that it will be created are all having setIsFabric(FALSE).
This is causing problems like whitescreens on several reload + multiple warnings such as:
```
E com.facebook.react.bridge.ReactNoCrashSoftException: Cannot get UIManager because the context doesn't contain an active CatalystInstance.
```
Fixes#43692
See for more context on this issues: https://github.com/facebook/react-native/issues/43692
Changelog:
[Android] [Fixed] - Fix bridge mode by constructing ReactDelegate correctly
Reviewed By: cipolleschi
Differential Revision: D55921078
fbshipit-source-id: 2c21d089a49538402d546177bcdb26c8d7d5fbc1
Summary:
This current consists of a bunch of TypeScript code, which will be ported to Flow in the stack.
Changelog: [Internal]
bypass-github-export-checks
Reviewed By: huntie
Differential Revision: D55741526
fbshipit-source-id: 1dc30d2ab63e0526dd6fed17ccf7cce9f57bdbee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43994
We received [this issue](https://github.com/facebook/react-native/issues/43764) from OSS where an app can't connect to Metro on reloads in the following scenario:
* Start the App when metro does not run.
* Observe the error screen
* Start Metro
* Press Reload
* Observe the error message again
While the desired behavior should be to connect to Metro now that this is running.
The root cause of the problem is that the RCTHost is initialized with a value of the `bundleURL` that is `nil`. Upon reload, the RCTHost is **not** recreated: the instance is restarted, but with the previous `bundleURL`, which is still `nil`.
The solution is to initialize the `RCTHost` with a closure that re-evaluate the `bundleURL` whenever it is invoked and to evaluate it only on `start`, to keep the initialization path light.
This way, when the app is started with Metro not running, the `bundleURL` is `nil`. But when it is reloaded with Metro starting, the `bundleURL` is properly initialized.
Note that the changes in this diff are not breaking as I reimplemented (and deprecated) the old initializer so that they should work in the same way.
## Changelog:
[iOS][Fixed] - Let RCTHost be initialized with a function to provide the `bundleURL` so that it can connect to metro on Reload when the url changes.
Reviewed By: dmytrorykun
Differential Revision: D55916135
fbshipit-source-id: 6927b2154870245f28f42d26bd0209b28c9518f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43963
changelog: [internal]
This experiment did work out. Let's clean it up
Reviewed By: cortinico
Differential Revision: D55797519
fbshipit-source-id: a5da97a7d31b9395b25bfd37db567054721599b0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43971
It turns out that we forgot to add a listener for the orientation change event in Bridgeless.
We used to have `UIApplicationDidChangeStatusBarOrientationNotification` but this is slightly unreliable because there might be use cases where the status bar has been hidden and, therefore, the event is not triggered.
This should fix an issue reported by OSS.
## Changelog:
[iOS][Fixed] - Make sure that the New Architecture listens to orientation change events.
Reviewed By: cortinico
Differential Revision: D55871599
fbshipit-source-id: c9b0634ec2126aa7a6488c2c56c87a9610fa1adf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43852
Changelog: [internal]
Just a small refactor so we rely less on shared pointers within `RuntimeSCheduler_Modern`.
Reviewed By: javache
Differential Revision: D55646389
fbshipit-source-id: d01dcba7b1551d349d21717ba585828ed7fb3259
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43853
Changelog: [internal]
## Context
This is part of a refactor to decouple the performance entry reporter from the rendering infra and from the native module that uses it.
## Changes
This moves the logic to report the timing of events to a separate class (outside `PerformanceEntryReporter` that now is agnostic to the rendering infra).
Reviewed By: sammy-SC
Differential Revision: D55646392
fbshipit-source-id: 5032a36b23d0741b19fb74cb04f0af3d3d476ef0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43854
Changelog: [internal]
## Context
This is part of a refactor to decouple the performance entry reporter from the rendering infra and from the native module that uses it.
## Changes
This moves the `PerformanceEntryReporter` and related classes to their own target in `ReactCommon/react/performance/timeline` that's not coupled with any rendering logic.
Reviewed By: sammy-SC
Differential Revision: D55646391
fbshipit-source-id: a759ed39c893a0bc14246c7ee608b1727e6ee4cd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43849
Changelog: [internal]
## Context
This is part of a refactor to decouple the performance entry reporter from the rendering infra and from the native module that uses it.
## Changes
This refactors `PerformanceEntryReporter` to make the class not depend on the native module that uses it. Instead of using the `RawPerformanceEntry` type from the native module, we define `PerformanceEntry` in `PerformanceEntryReporter` and use it as the source of truth in the native module instead.
Thanks to the bridging template sytem we have, we can convert the raw objects passed from JS to the C++ structs, defining how the enums are converted from and to JS.
Reviewed By: sammy-SC
Differential Revision: D55646394
fbshipit-source-id: 9cf5a7db6ecb221ca08320d0aaae7e7bc8d91804
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43848
Changelog: [internal]
This makes it easier to see the behavior of the new Event Timing API in RN.
Reviewed By: sammy-SC
Differential Revision: D55646393
fbshipit-source-id: 441fed789a980211783f04095303a139e7b08483
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43847
Changelog: [internal]
(This is an internal change because the API hasn't been released in OSS yet)
This fixes 2 problems in how we dispatch `PerformanceObserver` notifications:
1. If an observer callback throws an error, the remaining observers don't receive notifications.
2. We're notifying observers with an empty list of events when they don't match the filters.
Reviewed By: javache
Differential Revision: D55646390
fbshipit-source-id: 6511c7babd45517baf42076308268ea89afe1265
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43993
changelog: [internal]
clean up tests. The logic is exactly the same, just renaming few variables and deleting unused ones.
Reviewed By: javache
Differential Revision: D55689499
fbshipit-source-id: fffef1051798f1787210cced5e681fa3fe47842b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43985
This is just personal preference.
The name "OnJsError" makes the intent of the abstraction clear: an instance of OnJsError is a function that gets called when a js error is caught.
The name "JsErrorHandlingFunc" is not as good.
Changelog: [General][Breaking] - JsErrorHandler: Rename JsErrorHandlingFunc to OnJsError
Reviewed By: christophpurrer
Differential Revision: D55563580
fbshipit-source-id: 4d20bc984e6633aeac6193b9276a88d76961df2c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43957
Right now, JsErrorHandler is only used to handle fatal exceptions.
So, let's just scope handleJsError down to handleFatalError.
Changelog: [General][Breaking] - JsErrorHandler: Rename handleJsError to handleFatalError
Reviewed By: cortinico
Differential Revision: D55547901
fbshipit-source-id: 261e0c8fea2852bc95e53c688d90d012d4abea34
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43956
I think we should try to centralize all things js error handling related inside JsErrorHandler. So, I moved this bool into JsErrorHandler.
This makes ReactInstance easier to understand: it removes one member variable from ReactInstance.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D55547897
fbshipit-source-id: 73d1e0eedf3896c42cda4ce1013863960585da2c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43955
Just makes it easier to pass around JsErrorHandler.
We'll need this in D55547897, when we start storing the "has fataled" boolean inside the JsErrorHandler.
Changelog: [internal]
Reviewed By: cipolleschi
Differential Revision: D55547898
fbshipit-source-id: 162faaeff43bada0301de29111b2c17f7ef878c6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43952
getRuntimeScheduler() allows things to schedule work on the js thread by bypassing main bundle buffering.
This is unsafe: almost everything should be using the buffered runtime executor, unless it sets up bindings used in the main bundle.
I filed a task for the investigation to see if there's any problems. And added it to the code in this diff.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D55547899
fbshipit-source-id: 7785b9777e93f36ea0278993332662ed45a20cf2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43861
Changelog: [Internal]
_____
## Why?
We recommend to use Kotlin for any new code and are actively migrating Java code to Kotlin. This codemod service attempts to migrate existing Java code to Kotlin.
## How was this diff generated?
This codemod service scans through qualified paths and looks for Java modules. Then it runs `kotlinator.sh` on each module, which generated this diff.
## What if I see problems in this diff?
We recommend commandeering and fixing the diff. If you reject or abandon the diff, the codemod service will regenerate it in a few days
- Script for easily commandeer & open diff: In fbandroid, `scripts/commandeer_and_checkout.sh <DIFF>`. It not only commandeer the diff, but also rebase & open diff in Android Studio.
- Report repeating issues in [Kotlinator Papercut](https://fburl.com/papercuts/1g4f4qas)
See more useful tips & scripts in [Kotlin Auto-Conversion Codemod Wiki](https://fburl.com/wiki/c68ka0pu)
_____
## Questions / Comments / Feedback?
**Your feedback is important to us! Give feedback about this diff by clicking the "Provide Feedback" button below.**
* Returning back to author or abandoning this diff will only cause the diff to be regenerated in the future.
* Do **NOT** post in the CodemodService Feedback group about this specific diff.
_____
## Codemod Metadata
NOTE: You won't need to read this section to review this diff.
https://www.internalfb.com/intern/sandcastle/job/22517999373069959/
|Oncall|[kotlin_in_fb4a](https://our.intern.facebook.com/intern/oncall3/?shortname=kotlin_in_fb4a)|
|CodemodConfig|[fbsource/kotlinator.json](https://www.internalfb.com/codemod_service/fbsource%2Fkotlinator.json)|
|ConfigType|configerator|
Rules run:
- CodemodTransformerFBSourceScript
This diff was created with [CodemodService](https://fburl.com/CodemodService).
Reviewed By: cortinico
Differential Revision: D55725451
fbshipit-source-id: fea231c0f11f41013bcf7a8a9b5cf65badf82503
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43981
Changelog: [Internal]
_____
## Why?
We recommend to use Kotlin for any new code and are actively migrating Java code to Kotlin. This codemod service attempts to migrate existing Java code to Kotlin.
## How was this diff generated?
This codemod service scans through qualified paths and looks for Java modules. Then it runs `kotlinator.sh` on each module, which generated this diff.
## What if I see problems in this diff?
We recommend commandeering and fixing the diff. If you reject or abandon the diff, the codemod service will regenerate it in a few days
- Script for easily commandeer & open diff: In fbandroid, `scripts/commandeer_and_checkout.sh <DIFF>`. It not only commandeer the diff, but also rebase & open diff in Android Studio.
- Report repeating issues in [Kotlinator Papercut](https://fburl.com/papercuts/1g4f4qas)
See more useful tips & scripts in [Kotlin Auto-Conversion Codemod Wiki](https://fburl.com/wiki/c68ka0pu)
_____
## Questions / Comments / Feedback?
**Your feedback is important to us! Give feedback about this diff by clicking the "Provide Feedback" button below.**
* Returning back to author or abandoning this diff will only cause the diff to be regenerated in the future.
* Do **NOT** post in the CodemodService Feedback group about this specific diff.
_____
## Codemod Metadata
NOTE: You won't need to read this section to review this diff.
https://www.internalfb.com/intern/sandcastle/job/27021599000417439/
|Oncall|[kotlin_in_fb4a](https://our.intern.facebook.com/intern/oncall3/?shortname=kotlin_in_fb4a)|
|CodemodConfig|[fbsource/kotlinator.json](https://www.internalfb.com/codemod_service/fbsource%2Fkotlinator.json)|
|ConfigType|configerator|
Rules run:
- CodemodTransformerFBSourceScript
This diff was created with [CodemodService](https://fburl.com/CodemodService).
Reviewed By: cortinico
Differential Revision: D55725602
fbshipit-source-id: b8b77bf97de5a0eda5b077d6c5441b9af36fc26b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43967
Following up https://github.com/facebook/react-native/issues/43943, the metro loading banner is presented twice in Bridgeless mode.
This happens because both the RCTInstance and the RCTHost are listening to the Reload Command and issuing the instructions to refetch the JSBundle and to present the banner.
The RCTInstance should not concern itself with lifecycle events, owned by the RCTHost.
## Changelog:
[iOS][Fixed] - Avoid to show Metro Loading banner twice.
Reviewed By: cortinico
Differential Revision: D55870640
fbshipit-source-id: addb67d3226f7d7db20736309172a42fc15f3aa3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43864
This change tries to vendor boost. It has several sustainable benefits:
- Reduce the download time to download boost
- Reduce the time to install pods
- Reduce the time to build the project
- Protects us from SEVs due to boost download link being down (happened twice already)
- Fixes how we build boost: currently it is a pseudo-target in iOS with no code, this makes all the symbols weak and this does not plays nicely with the new Apple linker.
## Changelog:
[Internal] - Vendor boost from React Native
Reviewed By: cortinico
Differential Revision: D55742345
fbshipit-source-id: 75abb5a2875e949b3dae299d2e18cb648c46151e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43968
Changelog: [Internal]
When going from a Fusebox build to a non-Fusebox build of the same app, users can accidentally connect a previously opened Fusebox frontend to a non-Fusebox backend (or vice versa).
To prevent this, here we assign a distinct "device ID" to the Fusebox backend on both Android and iOS. This will prevent a mismatched CDT frontend from reconnecting to the app after a backend change, forcing the user to close and reopen the debugger.
Reviewed By: hoxyq
Differential Revision: D55870800
fbshipit-source-id: 8552e009ef1e43b512d35035c98d1a859e3ccf91
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43966
The `context` field was confusing. I've renamed it to `currentActivityContext` +
I've made sure the `onKey` method is using the right context with a this@ accessor.
Changelog:
[Android] [Fixed] - Fix ClassCastException in `ReactModalHostView`
Reviewed By: GijsWeterings
Differential Revision: D55870250
fbshipit-source-id: a25a31452fb0d21cf8e2807eca62cf09fe4fd74b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43742
## Changelog:
[Internal] -
As in the title - taking a subset of the views/image Java files, those that are related to interfaces, and convert them to Kotlin.
Reviewed By: tdn120
Differential Revision: D55589946
fbshipit-source-id: 60f03eaaca467821634d5b0195e42bfb931f65fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43920
React native is shipped as a whole, so it makes no sense for individual pods to specify which version of boost they support.
With this change we let the `react_native_pods` and the `boost.podspec` file to decide which version of boost is supported and all the other podspecs will follow.
## Changelog:
[Internal] - Remove explicit boost version from other podspecs
Reviewed By: NickGerleman
Differential Revision: D55801708
fbshipit-source-id: 3dcbbfb25010d2ee615afc4acfd5232fdc0c2a14
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43951
## Context
The **early js** error reporting pipeline catches javascript exceptions.
After errors are caught, the pipeline parses the exception, and puts the data into into a map buffer. 🤨
## Problems
We don't need to use a mapbuffer here: The structure of this exception data is known and never changes. (A map buffer is a type-unsafe bag of key/value pairs).
Instead, we could just use lower-level type-safe language primitives: regular C++ struct, and java class w/ fbjni.
## Changes
Migrate the **early js** error handling infra to C++ structs/fbjni.
## Impact
Now, there is no mapbuffer usage on iOS. We could re-introduce it when there is a need.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D55265170
fbshipit-source-id: cda97633d4c6ccaad541e5d416067390fe6f61b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43913
changelog: [internal]
We have this turned on in ParagraphShadowNode, let's roll it out for TextInput as well.
I came across this while profiling scroll performance when TextInput is part of the view hierarchy.
Reviewed By: javache
Differential Revision: D55751341
fbshipit-source-id: 2af20ddb5a4fb9b0ccd33217e60e8b9e8a95b920
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43939
## Problem
If we link the default tmmdelegate with our vr apps, we get this issue:
```
ld.lld: error: duplicate symbol: facebook::react::NativeDevLoadingViewSpecJSI::NativeDevLoadingViewSpecJSI(facebook::react::JavaTurboModule::InitParams const&)
>>> defined at firsttimenux_v2AppModulesCodegen-generated.cpp:1367 (buck-out/v2/gen/fbsource/bcbe7a50bd5ff29a/arvr/libraries/react-panellib/FirstTimeNux/__firsttimenux_v2AppModulesCodegen-codegen-modules-jni_cpp__/out/firsttimenux_v2AppModulesCodegen-generated.cpp:1367)
>>> firsttimenux_v2AppModulesCodegen-generated.cpp.pic.o:(facebook::react::NativeDevLoadingViewSpecJSI::NativeDevLoadingViewSpecJSI(facebook::react::JavaTurboModule::InitParams const&)) in archive buck-out/v2/gen/fbsource/bcbe7a50bd5ff29a/arvr/libraries/react-panellib/FirstTimeNux/__firsttimenux_v2AppModulesCodegen-jni__/libfirsttimenux_v2AppModulesCodegen-jni.pic.a
>>> defined at rncore-generated.cpp:606 (buck-out/v2/gen/fbsource/bcbe7a50bd5ff29a/xplat/js/react-native-github/__rncore-codegen-modules-jni_cpp__/out/rncore-generated.cpp:606)
>>> rncore-generated.cpp.pic.o:(.text._ZN8facebook5react27NativeDevLoadingViewSpecJSIC2ERKNS0_15JavaTurboModule10InitParamsE+0x0) in archive buck-out/v2/gen/fbsource/bcbe7a50bd5ff29a/xplat/js/react-native-github/__rncore-jniAndroid__/librncore-jniAndroid.pic.a
```
## Cause
My best understanding of the problem:
- Default tmmdelegate links against rncore, which contains codegen for react native's standard library of modules.
- But, the default delegate also pulls in this appmodules.so library. That library also contains codegen for react native's standard library of modules + the app's modules.
So, two so libraries define the same symbols. Hence the build fails.
## Solution
Remove the codegen for react native's standard library of modules from the default tmmdelegate.
Prereq: In open source, also make appmodules.so include the codegen for react native's standard library of modules.
Changelog: [Android][Breaking] - Make the app responsible for returning core turbomodule jsi hostobjects
Reviewed By: cortinico
Differential Revision: D55613024
fbshipit-source-id: 6406a9f388ff9de01288de0e263a78a079e7a0da
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43860
Changelog: [Internal]
_____
## Why?
We recommend to use Kotlin for any new code and are actively migrating Java code to Kotlin. This codemod service attempts to migrate existing Java code to Kotlin.
## How was this diff generated?
This codemod service scans through qualified paths and looks for Java modules. Then it runs `kotlinator.sh` on each module, which generated this diff.
## What if I see problems in this diff?
We recommend commandeering and fixing the diff. If you reject or abandon the diff, the codemod service will regenerate it in a few days
- Script for easily commandeer & open diff: In fbandroid, `scripts/commandeer_and_checkout.sh <DIFF>`. It not only commandeer the diff, but also rebase & open diff in Android Studio.
- Report repeating issues in [Kotlinator Papercut](https://fburl.com/papercuts/1g4f4qas)
See more useful tips & scripts in [Kotlin Auto-Conversion Codemod Wiki](https://fburl.com/wiki/c68ka0pu)
_____
## Questions / Comments / Feedback?
**Your feedback is important to us! Give feedback about this diff by clicking the "Provide Feedback" button below.**
* Returning back to author or abandoning this diff will only cause the diff to be regenerated in the future.
* Do **NOT** post in the CodemodService Feedback group about this specific diff.
_____
## Codemod Metadata
NOTE: You won't need to read this section to review this diff.
https://www.internalfb.com/intern/sandcastle/job/1239557953/
|Oncall|[kotlin_in_fb4a](https://our.intern.facebook.com/intern/oncall3/?shortname=kotlin_in_fb4a)|
|CodemodConfig|[fbsource/kotlinator.json](https://www.internalfb.com/codemod_service/fbsource%2Fkotlinator.json)|
|ConfigType|configerator|
Rules run:
- CodemodTransformerFBSourceScript
This diff was created with [CodemodService](https://fburl.com/CodemodService).
Reviewed By: cortinico
Differential Revision: D55725322
fbshipit-source-id: 8f78d221a8f04136019055a6ea64d8ec05bfd8a2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43923
Another round of Kotlin migration.
This time I'm doing `com.facebook.react.views.text.internal.span` which has been recently been annotated as `Nullsafe`
Changelog:
[Internal] [Changed] - Convert the whole `com.facebook.react.views.text.internal.span` package to Kotlin
Reviewed By: tdn120
Differential Revision: D55802155
fbshipit-source-id: 4bed023557f45a43d921df73dfc685e547788fd4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43930
We don't need `libreact_cxxreactpackage.so` as there is nothing to load. I'm moving this to be an INTERFACE library as there is only a Header file now to load.
Move libreact_cxxreactpackage.so to INTERFACE library
Changelog:
[Internal] [Changed] - Move libreact_cxxreactpackage.so to INTERFACE library
Reviewed By: javache
Differential Revision: D55805573
fbshipit-source-id: 9ef99c430c19250439b8ace5d26b0984a8fb759e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43931
RN Tester is crashing on back navigation with this stacktrace:
```
04-05 17:14:22.906 25051 25051 E AndroidRuntime: FATAL EXCEPTION: main
04-05 17:14:22.906 25051 25051 E AndroidRuntime: Process: com.facebook.react.uiapp, PID: 25051
04-05 17:14:22.906 25051 25051 E AndroidRuntime: java.lang.NullPointerException: Parameter specified as non-null is null: method com.facebook.react.devsupport.DoubleTapReloadRecognizer.didDoubleTapR, parameter view
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at com.facebook.react.devsupport.DoubleTapReloadRecognizer.didDoubleTapR(Unknown Source:2)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at com.facebook.react.ReactDelegate.shouldShowDevMenuOrReload(ReactDelegate.java:302)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at com.facebook.react.ReactActivityDelegate.onKeyUp(ReactActivityDelegate.java:158)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at com.facebook.react.ReactActivity.onKeyUp(ReactActivity.java:89)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.KeyEvent.dispatch(KeyEvent.java:2878)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.app.Activity.dispatchKeyEvent(Activity.java:4164)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at androidx.core.app.ComponentActivity.superDispatchKeyEvent(ComponentActivity.java:126)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at androidx.core.view.KeyEventDispatcher.dispatchKeyEvent(KeyEventDispatcher.java:86)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at androidx.core.app.ComponentActivity.dispatchKeyEvent(ComponentActivity.java:144)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at androidx.appcompat.app.AppCompatActivity.dispatchKeyEvent(AppCompatActivity.java:604)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at androidx.appcompat.view.WindowCallbackWrapper.dispatchKeyEvent(WindowCallbackWrapper.java:60)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at androidx.appcompat.app.AppCompatDelegateImpl$AppCompatWindowCallback.dispatchKeyEvent(AppCompatDelegateImpl.java:3413)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at com.android.internal.policy.DecorView.dispatchKeyEvent(DecorView.java:404)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$ViewPostImeInputStage.processKeyEvent(ViewRootImpl.java:6377)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$ViewPostImeInputStage.onProcess(ViewRootImpl.java:6243)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:5725)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:5782)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:5748)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$AsyncInputStage.forward(ViewRootImpl.java:5913)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:5756)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$AsyncInputStage.apply(ViewRootImpl.java:5970)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:5729)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:5782)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:5748)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:5756)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:5729)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:5782)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:5748)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$AsyncInputStage.forward(ViewRootImpl.java:5946)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$ImeInputStage.onFinishedInputEvent(ViewRootImpl.java:6104)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.inputmethod.InputMethodManager$PendingEvent.run(InputMethodManager.java:3159)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.inputmethod.InputMethodManager.invokeFinishedInputEventCallback(InputMethodManager.java:2723)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.inputmethod.InputMethodManager.finishedInputEvent(InputMethodManager.java:2714)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.inputmethod.InputMethodManager$ImeInputEventSender.onInputEventFinished(InputMethodManager.java:3136)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.InputEventSender.dispatchInputEventFinished(InputEventSender.java:154)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.os.MessageQueue.nativePollOnce(Native Method)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.os.MessageQueue.next(MessageQueue.java:335)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.os.Looper.loopOnce(Looper.java:161)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.os.Looper.loop(Looper.java:288)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:7842)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)
```
This is happening because the `view: View` parameter is actually null at that point. I'm fixing it.
Changelog:
[Internal] [Changed] - Fix crash of RNTester on back navigation
Reviewed By: tdn120
Differential Revision: D55805574
fbshipit-source-id: 368109ef70725dad2cf72789b259726f859f05b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43918
Changelog: [Internal]
_____
## Why?
We recommend to use Kotlin for any new code and are actively migrating Java code to Kotlin. This codemod service attempts to migrate existing Java code to Kotlin.
## How was this diff generated?
This codemod service scans through qualified paths and looks for Java modules. Then it runs `kotlinator.sh` on each module, which generated this diff.
## What if I see problems in this diff?
We recommend commandeering and fixing the diff. If you reject or abandon the diff, the codemod service will regenerate it in a few days
- Script for easily commandeer & open diff: In fbandroid, `scripts/commandeer_and_checkout.sh <DIFF>`. It not only commandeer the diff, but also rebase & open diff in Android Studio.
- Report repeating issues in [Kotlinator Papercut](https://fburl.com/papercuts/1g4f4qas)
See more useful tips & scripts in [Kotlin Auto-Conversion Codemod Wiki](https://fburl.com/wiki/c68ka0pu)
_____
## Questions / Comments / Feedback?
**Your feedback is important to us! Give feedback about this diff by clicking the "Provide Feedback" button below.**
* Returning back to author or abandoning this diff will only cause the diff to be regenerated in the future.
* Do **NOT** post in the CodemodService Feedback group about this specific diff.
_____
## Codemod Metadata
NOTE: You won't need to read this section to review this diff.
https://www.internalfb.com/intern/sandcastle/job/1239558926/
|Oncall|[kotlin_in_fb4a](https://our.intern.facebook.com/intern/oncall3/?shortname=kotlin_in_fb4a)|
|CodemodConfig|[fbsource/kotlinator.json](https://www.internalfb.com/codemod_service/fbsource%2Fkotlinator.json)|
|ConfigType|configerator|
Rules run:
- CodemodTransformerFBSourceScript
This diff was created with [CodemodService](https://fburl.com/CodemodService).
Reviewed By: javache
Differential Revision: D55725326
fbshipit-source-id: f0960e42cf248ea78613299c16c6a47aa6169c7a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43844
This converts the last class inside `com.facebook.react.views.modal` to Kotlin
Changelog:
[Internal] [Changed] - Convert ReactModalHostManager to Kotlin
Reviewed By: javache
Differential Revision: D55739386
fbshipit-source-id: 6bf85449c2bfd6d81a2d899bd044835b9b72c185
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43845
This class is quite legacy and requires a couple of eyes before merging it.
I've tested that modals are working fine on RN-Tester both Old & New Arch.
Changelog:
[Internal] [Changed] - ReactModalHostView to Kotlin
Reviewed By: javache
Differential Revision: D55739128
fbshipit-source-id: 740d24df39ceb7b6a8120ae5315cf0684d1e6e27
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43928
This is a patch version for Kotlin, no practical changes expected.
Changelog:
[Internal] [Changed] - Bump Kotlin to 1.9.23
Reviewed By: cipolleschi
Differential Revision: D55803534
fbshipit-source-id: 99fcf444885cbc7b95baec2983303cfee88874a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43859
This frees up the `reactnative` CMake target so we could use it as single .so
for the CMake build.
Changelog:
[Internal] [Changed] - Rename reactnative.a -> react_cxxreact.a
Reviewed By: javache
Differential Revision: D55745640
fbshipit-source-id: 3cad512cc07a277af2a0cea696863c85a17dabc1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43907
JSC is currently instacrashing because we missed a JvmStatic.
Android will attempt to load JSCInstance.initHybrid which is missing unless we specify JvmStatic.
Changelog:
[Internal] [Changed] - Fix Android instacrashing on JSC with NoSuchMethodException
Reviewed By: GijsWeterings
Differential Revision: D55795290
fbshipit-source-id: 5d10344e3f481dc5832706d77ccf2bf163dfb30f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43865
Some of the includes in the task that prepares prefabs are duplicated. Removing the duplication
## Changelog:
[Internal] - Cleanup android prefabs
Reviewed By: cortinico
Differential Revision: D55751660
fbshipit-source-id: 2ea610937f122f82bc91e09fac1a2c78efa83410
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43717
As we are going to bridgeless in new architecture, we want to clean up the usage of RCTBridge to use RCTModuleRegistry to access NativeModule.
Changelog:
[iOS][Breaking] Remove `RCTRedBox` access through `RCTBridge`
Reviewed By: philIip
Differential Revision: D55532209
fbshipit-source-id: 62aa2a24b60ab54d7f3cf25c34beda4449aaeaed
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43824
Changelog: [Internal]
# Feature flag cleanup/migration
This migration is part of the new Feature Flag system built by rubennorte. The goal of this migration is to clean up our Feature Flags and consolidate them into a single place, accessible by all platforms.
# In this diff
Replaced `RCTSetUseNativeViewConfigsInBridgelessMode` and `RCTGetUseNativeViewConfigsInBridgelessMode` with `ReactNativeFeatureFlags.useNativeViewConfigsInBridgelessMode()` and ReactNativeFeatureFlags::override
Reviewed By: javache
Differential Revision: D55705805
fbshipit-source-id: 861675a1a94da0fcef8d8a02ccbd8ecdd97ec700
Summary:
With 0.74.rc-5 one bug which related to errors was fixed (https://github.com/facebook/react-native/issues/41950). However, the fix introduced another one: the shape of Error objects that come from native modules has changed. This PR attempts to fix that, though it's not (yet) doing it in a way that would be 100% compatible with the old arch.
The problem was observed on iOS, not sure what the situation is on Android but believe it's okay there.
edit: on Android, there are no issues but the `message` field is enumerable, so that part is different from ios (see logs below).
Consider this code, where `error` is produced from a promise rejection inside of a native module.
```ts
console.log(
'own properties: ',
JSON.stringify(Object.getOwnPropertyNames(error), null, 2),
);
console.log(
'own enumerable properties: ',
JSON.stringify(Object.entries(error), null, 2),
);
```
These are the results for
<details>
<summary>Old architecture</summary>
```
LOG Running "google-one-tap-example" with {"rootTag":1,"initialProps":{}}
LOG own properties: [
"stack",
"code",
"message",
"domain",
"userInfo",
"nativeStackIOS"
]
LOG own enumerable properties: [
[
"code",
"-5"
],
[
"message",
"RNGoogleSignIn: The user canceled the sign in request., Error Domain=com.google.GIDSignIn Code=-5 \"The user canceled the sign-in flow.\" UserInfo={NSLocalizedDescription=The user canceled the sign-in flow.}"
],
[
"domain",
"com.google.GIDSignIn"
],
[
"userInfo",
{
"NSLocalizedDescription": "The user canceled the sign-in flow."
}
],
[
"nativeStackIOS",
[
"0 ReactTestApp 0x0000000102f4a6d8 RCTJSErrorFromCodeMessageAndNSError + 112",
"1 ReactTestApp 0x0000000102eeedd0 __41-[RCTModuleMethod processMethodSignature]_block_invoke_2.73 + 152",
"2 ReactTestApp 0x0000000102e2ae24 +[RNGoogleSignin rejectWithSigninError:withRejector:] + 548",
"3 ReactTestApp 0x0000000102e2aa8c -[RNGoogleSignin handleCompletion:serverAuthCode:withError:withResolver:withRejector:fromCallsite:] + 184",
"4 ReactTestApp 0x0000000102e2a8e0 -[RNGoogleSignin handleCompletion:withError:withResolver:withRejector:fromCallsite:] + 236",
"5 ReactTestApp 0x0000000102e28628 __40-[RNGoogleSignin signIn:resolve:reject:]_block_invoke_2 + 100",
"6 ReactTestApp 0x0000000102dc9d80 __35-[GIDSignIn addCompletionCallback:]_block_invoke_2 + 132",
...
]
]
]
```
</details>
<details>
<summary>RN 74 rc-5 (with bridgeless on)</summary>
```
(NOBRIDGE) LOG Bridgeless mode is enabled
(NOBRIDGE) LOG Running "google-one-tap-example" with {"rootTag":1,"initialProps":{"concurrentRoot":true},"fabric":true}
(NOBRIDGE) LOG own properties: [
"stack",
"message",
"cause"
]
(NOBRIDGE) LOG own enumerable properties: [
[
"cause",
{
"code": "-5",
"message": "RNGoogleSignIn: The user canceled the sign in request., Error Domain=com.google.GIDSignIn Code=-5 \"The user canceled the sign-in flow.\" UserInfo={NSLocalizedDescription=The user canceled the sign-in flow.}",
"nativeStackIOS": [
"0 ReactTestApp 0x00000001023a7b38 RCTJSErrorFromCodeMessageAndNSError + 112",
"1 ReactTestApp 0x00000001026cf774 ___ZZN8facebook5react15ObjCTurboModule13createPromiseERNS_3jsi7RuntimeENSt3__112basic_stringIcNS5_11char_traitsIcEENS5_9allocatorIcEEEEU13block_pointerFvU13block_pointerFvP11objc_objectEU13block_pointerFvP8NSStringSH_P7NSErrorEEENK3$_0clES4_RKNS2_5ValueEPSQ_m_block_invoke.57 + 332",
"2 ReactTestApp 0x0000000102270958 +[RNGoogleSignin rejectWithSigninError:withRejector:] + 548",
"3 ReactTestApp 0x00000001022705c0 -[RNGoogleSignin handleCompletion:serverAuthCode:withError:withResolver:withRejector:fromCallsite:] + 184",
"4 ReactTestApp 0x0000000102270414 -[RNGoogleSignin handleCompletion:withError:withResolver:withRejector:fromCallsite:] + 236",
"5 ReactTestApp 0x000000010226e15c __40-[RNGoogleSignin signIn:resolve:reject:]_block_invoke_2 + 100",
"6 ReactTestApp 0x000000010220f328 __35-[GIDSignIn addCompletionCallback:]_block_invoke_2 + 132",
...
],
"domain": "com.google.GIDSignIn",
"userInfo": {
"NSLocalizedDescription": "The user canceled the sign-in flow."
}
}
]
]
```
</details>
<details>
<summary>with the diff from this PR</summary>
```
(NOBRIDGE) LOG own properties: [
"stack",
"message",
"code",
"nativeStackIOS",
"domain",
"userInfo"
]
(NOBRIDGE) LOG own enumerable properties: [
[
"code",
"-5"
],
[
"nativeStackIOS",
[
"0 ReactTestApp 0x000000010083b8f8 RCTJSErrorFromCodeMessageAndNSError + 112",
"1 ReactTestApp 0x0000000100b63534 ___ZZN8facebook5react15ObjCTurboModule13createPromiseERNS_3jsi7RuntimeENSt3__112basic_stringIcNS5_11char_traitsIcEENS5_9allocatorIcEEEEU13block_pointerFvU13block_pointerFvP11objc_objectEU13block_pointerFvP8NSStringSH_P7NSErrorEEENK3$_0clES4_RKNS2_5ValueEPSQ_m_block_invoke.57 + 332",
"2 ReactTestApp 0x0000000100704718 +[RNGoogleSignin rejectWithSigninError:withRejector:] + 548",
"3 ReactTestApp 0x0000000100704380 -[RNGoogleSignin handleCompletion:serverAuthCode:withError:withResolver:withRejector:fromCallsite:] + 184",
"4 ReactTestApp 0x00000001007041d4 -[RNGoogleSignin handleCompletion:withError:withResolver:withRejector:fromCallsite:] + 236",
"5 ReactTestApp 0x0000000100701f1c __40-[RNGoogleSignin signIn:resolve:reject:]_block_invoke_2 + 100",
"6 ReactTestApp 0x00000001006a30e8 __35-[GIDSignIn addCompletionCallback:]_block_invoke_2 + 132",
...
]
],
[
"domain",
"com.google.GIDSignIn"
],
[
"userInfo",
{
"NSLocalizedDescription": "The user canceled the sign-in flow."
}
]
]
```
</details>
You see there is a change compared to old arch because `message` is no longer own enumerable property. If that needs to change (I guess it should), it'd be nice if someone more familiar with JSI pointed me in the right direction. Even with this inconsistency, the PR is an improvement and would be nice to have this fix included in the next RC.
This is output from Chrome's console for completeness, just to have something to compare to:
```
let err = new Error('hello')
undefined
Object.getOwnPropertyNames(err)
> ['stack', 'message']
Object.entries(err)
> []
```
bypass-github-export-checks
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [FIXED] - add missing fields to native errors in new arch
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/43649
Test Plan: Tested locally with an example app running RN 74-rc 5
Reviewed By: cortinico
Differential Revision: D55690184
Pulled By: cipolleschi
fbshipit-source-id: 60a857b9871af888dcd526782b5e6b73c07c051a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43851
## Summary
Adds a `react-native.code-workspace` workspace file when using VS Code. This disables the built-in TypeScript Language Service for `.js` files, recommends extensions, enables `formatOnSave`, and configures Flow language support.
We will recommend this workspace config in our contributing guide: https://github.com/facebook/react-native-website/pull/4075.
**Motivation**
This is a DevX benefit for **React Native contributors** using open source VS Code — in particular to help with recent/trivial papercuts in PRs such as inserting a final newline in files (configured by EditorConfig).
**Recommended extensions**
NOTE: The recommended extensions list is currently minimal — happy to extend this now or in future, but let's aim to keep these conservative.
- Flow — language support
- EditorConfig — formatting based on `.editorconfig`, all file types
- Prettier — formatting for JS* files
- ESLint — linter for JS* files
**Why `react-native.code-workspace`?**
`.code-workspace` files have slight extra behaviours over a `.vscode/` directory:
- Allows user to opt-in or skip.
- Allows double-click launching from file managers.
- Allows base folder (and any subfolders in future) to be opened with local file tree scope (useful in fbsource!)
- (Minor point) Single config file over multiple files.
https://code.visualstudio.com/docs/editor/workspaces
Changelog: [Internal]
## Test plan
Aganst a new unconfigured copy of Visual Studio Code Insiders.
**Without workspace config**
❌ `.js` files raise errors by default (built-in TypeScript language service)
{F1478195672}
❌ When using the Flow VS Code extension, the wrong version (global) of Flow is used.
**With workspace config**
✅ Workspace config is suggested when folder is opened in VS Code
{F1478194795}
✅ Dialog is shown on workspace launch with recommended VS Code extensions
{F1478196003}
✅ Built-in TypeScript Language Service is disabled for `.js` files
✅ Flow language support is configured correctly against `flow` version in `package.json`
{F1478291085}
{F1478200649}
Reviewed By: motiz88
Differential Revision: D55698495
fbshipit-source-id: b0b2f459cf05afc3e7862c9845066a66aaa1985b
Summary:
In the Old Architecture and for Swift Libraries, these two methods are used to initialize a new disctionary but their implementation was missing so some libraries like lottie were failig to build.
## Changelog:
[Internal] - Implement missing `count` and `keyEnumerator` methods for RCTComposedViewRegistry
Pull Request resolved: https://github.com/facebook/react-native/pull/43850
Test Plan: Tested locally with the repro provided by SWM
Reviewed By: javache
Differential Revision: D55743648
Pulled By: cipolleschi
fbshipit-source-id: 7bdb92625341cd704b8b09920ab3223a2ca61a54
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43857
Changelog: [Internal]
There seems to be a weird problem with OkHttpCallUtil:
* D55707704 works in fbsource but breaks the CircleCI build with
> using 'dispatcher(): Dispatcher' is an error. moved to val
* D55744165 fixes the CircleCI build but breaks in fbsource with
> cannot access 'dispatcher': it is package-private in 'OkHttpClient'
Not sure what's the real fix to migrate `OkHttpCallUtil` to Koltin but at this point is probably safer to backout the original migration! 😥
Reviewed By: cortinico
Differential Revision: D55745345
fbshipit-source-id: 3ec6e4d99c950098fae974aa5f0e5be0b6663249
Summary:
Working with gabrieldonadel, we realized that static frameworks of the React-RendererRuntime are not following the proper folder structure.
When a user tries to import `ReactCommon/RCTHost` in the app delegate, for example, the user ends up with an error and they can't find the files.
These changes fixes this by establishing the right folder structure in the static frameworks
## Changelog:
[Internal] - Make sure that React-RuntimeCore and JSErrorHandler are created with the proper structure for static frameworks
Pull Request resolved: https://github.com/facebook/react-native/pull/43846
Test Plan:
Tested locally on an app with 0.74.
Before: it failed to build.
After: it build successfully.
Reviewed By: cortinico
Differential Revision: D55741581
Pulled By: cipolleschi
fbshipit-source-id: 11ac0882d3feea05ef8904d55856ba5704b7a3b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43785
Deprecated `UIManager.showPopupMenu()` had success callback that would be triggered on 1) item selection or 2) dismiss.
New `PopupMenuAndroid` only has item selection callback so adding in missing dismiss callback.
Changelog:
[Android][Added] - Add (optional) onPopupDismiss() callback for PopupMenuAndroid
Reviewed By: cortinico
Differential Revision: D55531870
fbshipit-source-id: 26f3992ef6c85fbc6d8dfff00cb723ac4aae3762
Summary:
The React Native ESLint preset currently endorses the Prettier integration that is [explicitly recommended against by Pretier itself](https://prettier.io/docs/en/integrating-with-linters). Notice the difference between these two packages:
- `eslint-config-prettier` is the config that turns off all formatting rules. It's **recommended by Prettier** to be used together with Prettier. You'd still use Prettier itself to actually do the formatting.
- `eslint-plugin-prettier` is a legacy plugin developed a long time ago and that predates most modern Prettier integrations. It runs Prettier as if it were an ESLint rule, applies formatting on `--fix`, and **is not recommended**.
Unfortunately, RN uses the latter one (and always has).
This PR removes `eslint-plugin-prettier` and instead enables `eslint-config-prettier`, as recommended by Prettier.
As a consequence, you'll no longer see squiggly lines in your editor for stuff that isn't actually errors:
<img width="558" alt="Screenshot 2024-04-01 at 20 00 50" src="https://github.com/facebook/react-native/assets/810438/91ae2cec-a9ef-4205-a9ce-6ab858785ed2">
As another consequence, **you'll have to set up your own Prettier step in your pipeline**.
For example, if your precommit hook only contained `eslint --fix`, you'll now also need to run `prettier --write` there as well. Similarly, if you want Prettier to fail CI, you'd need to find where you call `eslint` and also do `prettier --check` there.
Here's an example for how to do it: https://github.com/bluesky-social/social-app/pull/3373
## 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] [BREAKING] - RN ESLint config no longer runs Prettier during ESLint
Pull Request resolved: https://github.com/facebook/react-native/pull/43756
Test Plan:
Tested locally, verified formatting changes no longer get flagged as violations by the RN config.
<img width="470" alt="Screenshot 2024-04-01 at 20 33 55" src="https://github.com/facebook/react-native/assets/810438/515db971-18bc-4625-bb6d-b9d072692923">
Reviewed By: motiz88
Differential Revision: D55643699
Pulled By: yungsters
fbshipit-source-id: 97df774275922086f0356ac857d6425713184e39
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43816
We should not attempt to load generated classes by the Annotation processor in OSS because we simply don't run it, so those classes will fail to load. I'm short-circuiting the logic here.
This is sustainability work as we got a report for this in OSS a while ago and I never got the time to work on it.
Changelog:
[Internal] [Changed] - Do not attempt to call Class.forName in OSS
Reviewed By: rshest
Differential Revision: D55693479
fbshipit-source-id: 3ec84e2c7940011b48f354058b5099b46065166d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43822
Changelog: [Internal]
# Feature flag cleanup/migration
This migration is part of the new Feature Flag system built by rubennorte. The goal of this migration is to clean up our Feature Flags and consolidate them into a single place, accessible by all platforms.
# In this diff
Replaced `ReactFeatureFlags.useNativeViewConfigsInBridgelessMode` with `ReactNativeFeatureFlags.useNativeViewConfigsInBridgelessMode()`
Reviewed By: cortinico
Differential Revision: D55695173
fbshipit-source-id: e5158a9d5606f16f8e333321bad472f7eb315d0b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43811
This class was really old and had a lot of potential NPEs as it was accessing fields that could have been not initialized properly. I'm fixing it here ahead of a Kotlin migration.
Changelog:
[Internal] [Changed] - Mark ReactModalHostView as NullSafe
Reviewed By: fkgozali
Differential Revision: D55690285
fbshipit-source-id: 3e910da6dc43a30f2f86d4f1e9d02ead006a31c1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43814
This is just an example on how to use the NullSafe annotation
Changelog:
[Internal] [Changed] - Annotate AndroidUnicodeUtils as NullSafe
Reviewed By: alanleedev
Differential Revision: D55419929
fbshipit-source-id: 4eac059c5992661ada4ef8d35327dd9a4bc11d25
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43815
This moves a lot of classes from Java to Kotlin from the `package com.facebook.react.views.modal`
Changelog:
[Internal] [Changed] - Convert several classes inside `com.facebook.react.views.modal` to Kotlin
Reviewed By: rshest
Differential Revision: D55692067
fbshipit-source-id: 67e93c9d5d5f58add31ca6726c9f1e4ac2e8ffc3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43789
This diff introduces some changes to React Native needed to enable fragment-based navigation (see next diff for usage).
Fragment-based navigation will enable us to, instead of re-creating the entire main activity on navigation, create a fragment instead - allowing us to bypass a lot of unnecessary onCreate() logic in our main activity to improve user experience and performance.
Changelog:
[Internal] [Changed] - Add option to skip calling delegate on ReactFragment lifecycle events
Reviewed By: keoskate
Differential Revision: D55646221
fbshipit-source-id: 45b148cb9ecdb1484f1ac714ac2b93ce09c52237
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43810
This bot never works because facebook bot is faster.
I'm updating the logic to always publish the thank you message + update the link with the correct one.
Changelog:
[Internal] [Changed] - Always quote the user + add links to the release support policy
Reviewed By: rshest, cipolleschi
Differential Revision: D55643675
fbshipit-source-id: d2e726580c82d7f89b37d17846675b7c4c38e908
Summary:
PR https://github.com/facebook/react-native/issues/43468 landed in main which uses UIMenuAutoFill that is available only in iOS 17.
Despite having the `available` checks, these are only runtime checks. The symbol is not stripped on older versions of Xcode and therefore our jobs which uses older Xcode versions started failing.
This change wraps the offending code in a compilation pragma that strips away the symbol when building with Xcode versions that does not know iOS 17.
## Changelog:
[iOS][Fixed] - wrap UIMenuAutoFill in compilation checks for iOS 17
Pull Request resolved: https://github.com/facebook/react-native/pull/43808
Test Plan: CircleCI is green
Reviewed By: cortinico
Differential Revision: D55688255
Pulled By: cipolleschi
fbshipit-source-id: d69874b60e73da1fbdfc61d594870a48f97c3797
Summary:
This allows build configuration named like `StagingDebug` to match with settings applied to `Debug` This fixes https://github.com/facebook/react-native/issues/43185
Custom build setting were only applied to `Debug` build configurations, preventing configurations named `StagingDebug` or similar to access the new experimental debugger, as reported in https://github.com/facebook/react-native/issues/43185
This now applies the setting to every configuration ending with `Debug`
## Changelog:
[IOS] [CHANGED] - fix: build settings for custom build configuration
Pull Request resolved: https://github.com/facebook/react-native/pull/43780
Reviewed By: dmytrorykun
Differential Revision: D55688996
Pulled By: cipolleschi
fbshipit-source-id: 1f34cd722f6acfaa08d3377e19a04d08af97ed7c
Summary:
Changelog: [iOS][Added]
this creates the RN privacy manifest in the ios build step if user has not created one yet. the reasons have been added for the following APIs:
NSPrivacyAccessedAPICategoryFileTimestamp
- C617.1: We use fstat and stat in a few places in the C++ layer. We use these to read information about the JavaScript files in RN.
NSPrivacyAccessedAPICategoryUserDefaults
- CA92.1: We access NSUserDefaults in a few places.
1) To store RTL preferences
2) As part of caching server URLs for developer mode
3) A generic native module that wraps NSUserDefaults
NSPrivacyAccessedAPICategorySystemBootTime
- 35F9.1: Best guess reason from RR API pulled in by boost
Reviewed By: cipolleschi
Differential Revision: D53687232
fbshipit-source-id: 6dffb1a6013f8f29438a49752e47ed75c13f4a5c
Summary:
Changelog: [iOS][Added]
this change will be included in the RN CLI. so all new apps running the RN CLI to get created will get this manifest. the reasons have been added for the following APIs:
NSPrivacyAccessedAPICategoryFileTimestamp
- C617.1: We use fstat and stat in a few places in the C++ layer. We use these to read information about the JavaScript files in RN.
NSPrivacyAccessedAPICategoryUserDefaults
- CA92.1: We access NSUserDefaults in a few places.
1) To store RTL preferences
2) As part of caching server URLs for developer mode
3) A generic native module that wraps NSUserDefaults
NSPrivacyAccessedAPICategorySystemBootTime
- 35F9.1: Best guess reason from RR API pulled in by boost
Reviewed By: cipolleschi
Differential Revision: D53682756
fbshipit-source-id: 0426fe0002a3bc8b45ef24053ac4228c9f61eb85
Summary:
This pull request resolves the issue https://github.com/facebook/react-native/issues/43452
Previously, when utilizing `contextMenuHidden`, the context menu wasn't entirely hidden as the "AutoFill" option remained visible. However, it's now possible to eliminate it using the menu builder.
## 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] - hide AutoFill from context menu when using `contextMenuHidden`
Pull Request resolved: https://github.com/facebook/react-native/pull/43468
Test Plan:
Manual tests in RNTester:
https://github.com/facebook/react-native/assets/39670088/dc0f828c-f613-412d-b560-f3b795dd3ffb
Reviewed By: javache
Differential Revision: D54902269
Pulled By: tdn120
fbshipit-source-id: e0f3d3b5a0817db1c072caf2f01648432c7d868d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43777
It's best to avoid mutex reentrancy, even when using "read" locks (i.e., std::shared_lock). Since we already have a read lock on the ShadowTree in `UIManager::setNativeProps_DEPRECATED`, we can avoid the reentrancy by grabbing ancestor node from the shadow tree instead of relying on a recursive call to ShadowTreeRegistry::visit
## Changelog
[GENERAL][FIXED] - Avoid ShadowTreeRegistry::mutex_ read lock reentrancy
Reviewed By: rubennorte
Differential Revision: D55640201
fbshipit-source-id: 7a5c6674d290ea280ab584ae734733f12a65f6f8
Summary:
This PR removes forward declaration of `loadSourceForBridge` methods from the RCTRootViewFactory as it was causing an issue on old architecture, where the RedBox wouldn't popup when metro wasn't running.
As stated by Kudo [here](https://github.com/reactwg/react-native-releases/issues/177):
> the problem was coming from the implementation
> https://github.com/facebook/react-native/blob/00725fadff28bb3c7fed65f208e647f0dab69e75/packages/react-native/React/CxxBridge/RCTCxxBridge.mm#L519-L540
>
> we should dynamically override loadSourceForBridge:onProgress:onComplete: and loadSourceForBridge:withBlock: in RCTRootViewFactory only when AppDelegate override it. one way to achieve this might be tricky that we may need to override respondsToSelector:.
>
> otherwise, we could just skip the loadSourceForBridge:onProgress:onComplete: and loadSourceForBridge:withBlock: support.
There is no straight forward solution to implement this without some _hacks_ so I'm removing this forward block for now.
## Changelog:
[IOS] [FIXED] - remove loadSourceForBridge in RCTRootViewFactory
Pull Request resolved: https://github.com/facebook/react-native/pull/43656
Test Plan: CI Green
Reviewed By: rshest
Differential Revision: D55485094
Pulled By: cortinico
fbshipit-source-id: 1e391e0795c3d99686f2805165f64a7715b013f6
Summary:
With D55574528 and D55623682 having landed concurrently, and the latter enabling warnings-as-errors for Kotlin files vs the former having one such warning, this caused a build breakage.
This diff fixes it.
Reviewed By: andrewdacenko
Differential Revision: D55636176
fbshipit-source-id: 781b8cf40a4e9aa8a3da3005d26dca975f146c09
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43706
Changelog: [internal]
Just a small improvement of the UI for the Performance API examples in RNTester.
Reviewed By: christophpurrer
Differential Revision: D55489933
fbshipit-source-id: a1fe4f4962227941827f02cf18a0d4685e18f006
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43701
Changelog: [internal]
We were defining an `UNDEFINED` type of entry that should never happen in practice and we were using unnecessarily to signal "no type" where an optional type would be more suitable. Most importantly, **we were incorrectly allocating a buffer for entries of this type**.
This removes that type and the unnecessary buffer.
Reviewed By: rshest
Differential Revision: D55478890
fbshipit-source-id: 145210a9c4e2614a342f2d913b9eb6b3d62f676f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43702
Changelog: [internal]
Just a minor refactor to use C++20 designated initializers in `PerformanceEntryReporter` and its tests, while removing unnecessary initialization for optional fields.
Reviewed By: rshest
Differential Revision: D55477745
fbshipit-source-id: a643adf7ae48df23c5c383420fd4c4dd550e1322
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43703
Changelog: [internal]
(internal because this API isn't available in OSS yet)
I found a bug in the current implementation of `performance.measure` where the API would use the first `mark` reported under a specific name instead of the last one (found it in the new example in RNTester in D55477746 that re-logs the marks every time we click on a button).
The root cause for this problem is that we were using `insert` from `std::unordered_set` to update the value, but `insert` doesn't modify the value if it's already present.
This fixes the issue by doing a lookup and removing the value prior to inserting it.
Reviewed By: rshest
Differential Revision: D55477743
fbshipit-source-id: e72aa784a936828db64b572988fe0acb2ad78214
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43704
Changelog: [internal]
Adding examples of the rest of APIs in `Performance`/`PerformanceObserver` starting with marks and measures.
Reviewed By: rshest
Differential Revision: D55477746
fbshipit-source-id: 965796b6a97dc527192093e3c93af837a4d5b714
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43752
Gentest tests started failing because Chrome changed behavior of overflowed align-content container. Spec says should fallback to "safe center", which is really just "start", instead of previous "center" behavior. This changes behavior accordingly.
There is one bit where I think we are doing the wrong thing wrt alignment of flex start vs start (which we don't support yet), but couldn't repro a failing chrome test.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D55617689
fbshipit-source-id: 08f23d198c75f2c2f51ccaa8795289e6e4a92cb8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43730
# Changelog:
[Internal] -
As in the title, converts corresponding type declarations in `react/devsupport/LogBox*.java` to Kotlin.
Reviewed By: NickGerleman
Differential Revision: D55574528
fbshipit-source-id: 56cf5de75d18cd73929cb7f0c9375a3f62e83574
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43755
This is another place where the OSS build went ahead of the internal source of truth, which has caused build breaks more than once.
This enables warnings as errors in `rn_android_library` for consistency. This is used for a couple libraries outside of ReactAndroid that might need fixup/suppression.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D55623682
fbshipit-source-id: 37da30c642de2c3d8390334a0d0bff365a4ed7a1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43754
Moves off of deprecated `DisplayMetrics.scaledDensity` API to builtin font scaling API, while still clamping to max multiplier using previous logic.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D55623674
fbshipit-source-id: 2668eea8dbd154cc046e2c515323ad66b289dc64
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43729
# Changelog:
[Internal] -
As in the title, converts corresponding type declarations in `react/uimanager/*Util.kt` to Kotlin.
Reviewed By: tdn120
Differential Revision: D55574531
fbshipit-source-id: 974234bd57c77e863aa723388e48ffc455e73a96
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43728
# Changelog:
[Internal] -
As in the title, converts corresponding type declarations in `react/uimanager/layoutanimation/*Type.kt` to Kotlin.
Differential Revision: D55574530
fbshipit-source-id: 8527b5c9b491435c60ed9c05092ffeccd7552f9c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43727
# Changelog:
[Internal] -
As in the title, converts this one particular Java file to Kotlin.
Reviewed By: arushikesarwani94
Differential Revision: D55574526
fbshipit-source-id: 04af5b870670a5560eaba7ab8c029c580032d09a
Summary:
Fix version checker not considering nightlies:
```
WARNING: You should run npx react-native@latest to ensure you're always using the most current version of the CLI. NPX
has cached version (0.74.0-nightly-20240214-b8ad91732) != current release (0.73.6)
```
## Changelog:
[GENERAL] [FIXED] - Fix version checker not considering nightlies
Pull Request resolved: https://github.com/facebook/react-native/pull/43712
Test Plan: On a recent nightly version, run any cli command.
Reviewed By: rshest
Differential Revision: D55525055
Pulled By: zeyap
fbshipit-source-id: 6dd08e30e542d9ddd191bf95c968a26c0cc14e4e
Summary:
Currently the react-native-gradle-plugin does not allow the "react" plugin extension to already exist when running its apply block. I had a use-case where I wanted to create a new gradle plugin which would take care of applying the react plugin including setting some of its options. Without the change in this PR, this would currently turn into a build failure.
## Changelog:
[ANDROID] [FIXED] - prevent error when the "react" extension was already created by another gradle plugin
Pull Request resolved: https://github.com/facebook/react-native/pull/43694
Reviewed By: rshest
Differential Revision: D55478611
Pulled By: zeyap
fbshipit-source-id: cc743a99cb72ed315d21c52597efd5ee92a3be62
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43677
Remove `RCT_ENABLE_LOADING_FROM_PACKAGER` from `RCTDefines`, as it is not referenced anywhere and does nothing.
Changelog: [Internal]
Reviewed By: hoxyq, realsoelynn
Differential Revision: D55421282
fbshipit-source-id: ae29a8a421a6cc23d863b489eae2175392f684cd
Summary:
## Context
Prior, ReactContext used to implement bridge logic.
For bridgeless mode, we created BridgelessReactContext < ReactContext
## Problem
This could lead to failures: we could call bridge methods in bridgeless mode.
## Changes
Primary change:
- Make all the react instance methods inside ReactContext abstract.
Secondary changes: Implement react instance methods in concrete subclasses:
- **New:** BridgeReactContext: By delegating to CatalystInstance
- **New:** ThemedReactContext: By delegating to inner ReactContext
- **Unchanged:** BridgelessReactContext: By delegating to ReactHost
## Auxiliary changes
This fixes ThemedReactContext in bridgeless mode.
**Problem:** Prior, ThemedReactContext's react instance methods did not work in bridgeless mode: ThemedReactContext wasn't initialized in bridgeless mode, so all those methods had undefined behaviour.
**Solution:** ThemedReactContext now implements all react instance methods, by just forwarding to the initialized ReactContext it decorates (which has an instance).
Changelog: [Android][Removed] Delete ReactContext.initializeWithInstance(). ReactContext now no longer contains legacy react instance methods. Please use BridgeReactInstance instead.
---
Reviewed By: fkgozali
Differential Revision: D55505416
fbshipit-source-id: ce1e3ab379eb788d26130dd44a66544aada3db02
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43697
Currently, messages from a device are handled by async handlers added to a promise chain.
If a handler rejects, the end of the chain becomes a rejected promise, picked up only asynchronously by Metro's global `unhandledRejection` handler.
This triggers a warning from Node.js, and worse, prevents any `then()` callback chained by subsequent messages from being invoked at all.
Handlers *should* attempt to gracefully deal with errors (as we do with source map fetching errors, for example), but this diff adds a catch-all fallback for anything we might've missed (in this case, a frontend socket disconnecting while we're busy fetching a source map). Errors are caught and logged to EventReporter.
**To follow**: Gracefully handle socket disconnections while an async handler is working or queued.
Changelog:
[General][Fixed] Inspector proxy: prevent errors proxying a device message from blocking the handler queue or spamming logs.
Reviewed By: EdmondChuiHW
Differential Revision: D55482735
fbshipit-source-id: bb726218495e105f9cb4f723a1d110c9815abdef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43599
iOS E2E tests non-deterministic rendering happens around examples with a border set to `StyleSheet.hairlineWidth`. That value has special subpixel math, that doesn't seem to render consistently on iOS (this is its own bug).
To unblock adding some new E2E iOS TextInput tests, this removes usage of `hairlineWidth` in styles, and more generally, tries to unify TextInput styles in the examples.
This will break a whole bunch of RNTester Jest E2E baselines on different apps, which I will update from land-time runs or after continuous builds are available for different endpoints.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D55213090
fbshipit-source-id: 6d81b9355adc538a3ade6f50ef93c3ca08782ae7
Summary:
Stacked on top of #28498 for test fixes.
### Don't Rethrow
When we started React it was 1:1 setState calls a series of renders and
if they error, it errors where the setState was called. Simple. However,
then batching came and the error actually got thrown somewhere else.
With concurrent mode, it's not even possible to get setState itself to
throw anymore.
In fact, all APIs that can rethrow out of React are executed either at
the root of the scheduler or inside a DOM event handler.
If you throw inside a React.startTransition callback that's sync, then
that will bubble out of the startTransition but if you throw inside an
async callback or a useTransition we now need to handle it at the hook
site. So in 19 we need to make all React.startTransition swallow the
error (and report them to reportError).
The only one remaining that can throw is flushSync but it doesn't really
make sense for it to throw at the callsite neither because batching.
Just because something rendered in this flush doesn't mean it was
rendered due to what was just scheduled and doesn't mean that it should
abort any of the remaining code afterwards. setState is fire and forget.
It's send an instruction elsewhere, it's not part of the current
imperative code.
Error boundaries never rethrow. Since you should really always have
error boundaries, most of the time, it wouldn't rethrow anyway.
Rethrowing also actually currently drops errors on the floor since we
can only rethrow the first error, so to avoid that we'd need to call
reportError anyway. This happens in RN events.
The other issue with rethrowing is that it logs an extra console.error.
Since we're not sure that user code will actually log it anywhere we
still log it too just like we do with errors inside error boundaries
which leads all of these to log twice.
The goal of this PR is to never rethrow out of React instead, errors
outside of error boundaries get logged to reportError. Event system
errors too.
### Breaking Changes
The main thing this affects is testing where you want to inspect the
errors thrown. To make it easier to port, if you're inside `act` we
track the error into act in an aggregate error and then rethrow it at
the root of `act`. Unlike before though, if you flush synchronously
inside of act it'll still continue until the end of act before
rethrowing.
I expect most user code breakages would be to migrate from `flushSync`
to `act` if you assert on throwing.
However, in the React repo we also have `internalAct` and the
`waitForThrow` helpers. Since these have to use public production
implementations we track these using the global onerror or process
uncaughtException. Unlike regular act, includes both event handler
errors and onRecoverableError by default too. Not just render/commit
errors. So I had to account for that in our tests.
We restore logging an extra log for uncaught errors after the main log
with the component stack in it. We use `console.warn`. This is not yet
ignorable if you preventDefault to the main error event. To avoid
confusion if you don't end up logging the error to console I just added
`An error occurred`.
### Polyfill
All browsers we support really supports `reportError` but not all test
and server environments do, so I implemented a polyfill for browser and
node in `shared/reportGlobalError`. I don't love that this is included
in all builds and gets duplicated into isomorphic even though it's not
actually needed in production. Maybe in the future we can require a
polyfill for this.
### Follow Ups
In a follow up, I'll make caught vs uncaught error handling be
configurable too.
---------
DiffTrain build for commit https://github.com/facebook/react/commit/6786563f3cbbc9b16d5a8187207b5bd904386e53.
Changelog:
[Internal]
Reviewed By: kassens
Differential Revision: D55408481
Pulled By: yungsters
fbshipit-source-id: 598aa306369e21cb3e93ad6041a87bfbaa9eef9e
Co-authored-by: Ricky Hanlon <rickhanlonii@gmail.com>
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43686
Under Node 20, the use of `new Buffer(string)` is deprecated and logs a warning. This replaces it with the recommended `Buffer.from(string)`.
Changelog:
[General][Fixed] FIx "Buffer() is deprecated" warning from debugger proxy.
Reviewed By: huntie
Differential Revision: D55472025
fbshipit-source-id: 8b5af9e2d7e026cbdf6aa68f71ff0f856fb164db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43698
changelog: [internal]
RCTViewComponentView was missing isAccessibilityElement override. Here I add it and use contentView to determine if element is accessible.
Reviewed By: rubennorte
Differential Revision: D55483944
fbshipit-source-id: f29c82a42d17140ae421f27871a3bf6f7f36bc12
Summary:
## Context
Prior, ReactContext used to implement bridge logic.
For bridgeless mode, we created BridgelessReactContext < ReactContext
## Problem
This could lead to failures: we could call bridge methods in bridgeless mode.
## Changes
Primary change:
- Make all the react instance methods inside ReactContext abstract.
Secondary changes: Implement react instance methods in concrete subclasses:
- **New:** BridgeReactContext: By delegating to CatalystInstance
- **New:** ThemedReactContext: By delegating to inner ReactContext
- **Unchanged:** BridgelessReactContext: By delegating to ReactHost
## Auxiliary changes
This fixes ThemedReactContext in bridgeless mode.
**Problem:** Prior, ThemedReactContext's react instance methods did not work in bridgeless mode: ThemedReactContext wasn't initialized in bridgeless mode, so all those methods had undefined behaviour.
**Solution:** ThemedReactContext now implements all react instance methods, by just forwarding to the initialized ReactContext it decorates (which has an instance).
Changelog: [Android][Removed] Delete ReactContext.initializeWithInstance(). ReactContext now no longer contains legacy react instance methods. Please use BridgeReactInstance instead.
Reviewed By: javache
Differential Revision: D53145010
fbshipit-source-id: 2405bc24afb00864117d3c504fc9c4cbffd7203a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43696
This just sets explicitApi to true for every module inside ReactAndroid
Changelog:
[Internal] [Changed] - Flip explicitApi to True for everyone
Reviewed By: tdn120
Differential Revision: D55478674
fbshipit-source-id: c9aeba89ad5b0f88bca7fd480c6aa66e0152a456
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43699
This diff initializes `RELEASE_VERSION` with the value that is provided by the `get_react_native_version` job (it stores its output into `/tmp/react-native-version`).
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D55484988
fbshipit-source-id: f0b5bb473096f3691f50152beb3181a454916fdc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43661
# Changelog: [Internal]
1. Remove `BridgelessDebugReactPackage.java`, this was added in D43407534. Technically, its the same as `DebugCorePackage.java`.
2. `ReactInstance` to add `DebugCorePackage`, so `DebuggingOverlay` view manager will be included in the bridgeless build.
3. Fix `RNTesterApplication.kt` to NOT create `MyLegacyViewManager` for every possible viewManagerName, apart from `"RNTMyNativeView"`, return null instead.
Reviewed By: cortinico
Differential Revision: D55375350
fbshipit-source-id: 1d3cb6b5ad3c0248df1def9f37c8c49b308f4473
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43690
# Changelog: [Internal]
Fixes https://github.com/facebook/react-native/issues/43678.
The issue is that once `getInspectorDataForViewAtPoint` is imported, it should throw if RDT global hook was not injected. ReactDevTools overlay imports `getInspectorDataForViewAtPoint`, this is why it did throw in testing environment.
ReactDevToolsOverlay JSX-element is already gated with RDT global hook check, adding a deferred import, same as it was already implemented for Inspector.
Still unclear to me how this didn't throw all this time while using the Catalyst / RNTester.
Reviewed By: cortinico
Differential Revision: D55474774
fbshipit-source-id: 759e5e8227cc7534193e5b95616b6099c15f5cb5
Summary:
When RN moved Button component from a class component to a function component (https://github.com/facebook/react-native/commit/07e8ae42bed71f54bbe0e786ccad88b2f14648a4) a forwardRef call was not added to the Button control. This caused a set of tests downstream in React Native for Windows to fail because they rely on being able to pass a ref through to the Button control.
## Changelog:
[GENERAL] [FIXED] - Adds forwardRef call to new functional component implementation of Button control.
Pull Request resolved: https://github.com/facebook/react-native/pull/43666
Test Plan: Button render remains the same.
Reviewed By: fabriziocucci
Differential Revision: D55398765
Pulled By: zeyap
fbshipit-source-id: ba32c764c16cb529ab1c92cb7888f2bae0f16f5f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43664
Changelog: [internal]
Now that we have the event loop, we can modify the implementation of `MutationObserver` (which is still not enabled by default) to dispatch the notifications as microtasks, making the API more spec-compliant.
Reviewed By: javache
Differential Revision: D55380178
fbshipit-source-id: f876ffba49f9744f6603053f1485e7c2f43cb230
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43672
Changelog: [internal]
Small cleanup to move the last C++ native module defined in a JS directory to the new directory in `react-native/ReactCommon/react/nativemodule`.
Reviewed By: javache
Differential Revision: D55384106
fbshipit-source-id: 3bf477c2aceab6838f7f8131174b6eb74e890a23
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43663
Changelog: [internal]
We have a new directory for built-in C++ native modules, but the native modules for `MutationObserver` and `IntersectionObserver` were created before we had it.
This moves the native module for `MutationObserver` to `react-native/ReactCommon/react/nativemodule/mutationobserver` to follow the convention.
Reviewed By: javache
Differential Revision: D55380179
fbshipit-source-id: 0c64acbec973f2e5b57a0e38a0992bba49a01a45
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43653
Changelog: [internal]
This will allow us to clean up some code in `UIManager` (using methods in the native module instead) and prepare to use the DOM APIs in OSS behind a feature flag.
This doesn't enable the DOM APIs in OSS, only the native module.
Reviewed By: javache
Differential Revision: D55365252
fbshipit-source-id: 70ec0eb022df586ad554c5b8ce6915b8ceddef5f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43659
Changelog: [internal]
This adds an implementation for the legacy layout measurement methods in React Native (`measure`, `measureInWindow` and `measureLayout`) in the DOM native module, so we can clean up the API from the `nativeFabricUIManager` binding.
Reviewed By: javache
Differential Revision: D55368141
fbshipit-source-id: 196d4d29be3b78ffc22fdc136be6e0cf5ab9dd26
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43679
The current implementation of clear-with-predicate first copies unconsumed
elements and then all others. This works correctly when the buffer is full
(wraps around), but fails if size() < maxSize: add() may no longer insert
an element in the correct position (after the last unconsumed entry; see
new unit test).
Replace it with a loop that iterates over all entries in order, and adjusts
cursorStart and cursorEnd to point to the last numToConsume elements of the
vector.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D55273402
fbshipit-source-id: 647dc35faeb35c7fa99b8113cf85ce7f02f073e5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43676
changelog: [internal]
calling super invalidates eventEmitter. EventEmitter should be invalidated before reseting contentOffset on `_scrollView. Otherwise, UIScrollView::setContentOffset is called and it calls delegate method: `scrollViewDidScroll`.
Reviewed By: javache
Differential Revision: D55375060
fbshipit-source-id: f697805eb1ca05d15cf498ff9e5e06e90eb7ac56
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43538
The Hermes RuntimeConfig for bridgeless accidentally force-disabled ES6Proxy, resulting in https://github.com/facebook/react-native/issues/43523
Let's remove the incorrect override.
To test using RNTester, add the following change:
```
diff --git a/packages/rn-tester/js/RNTesterAppShared.js b/packages/rn-tester/js/RNTesterAppShared.js
index 87cb6b69dfe..f2512d09c5a 100644
--- a/packages/rn-tester/js/RNTesterAppShared.js
+++ b/packages/rn-tester/js/RNTesterAppShared.js
@@ -50,6 +50,8 @@ const RNTesterApp = ({
);
const colorScheme = useColorScheme();
+ new Proxy({}, {});
+
const {
activeModuleKey,
activeModuleTitle,
```
Before this change, RNTester will get an error at start-up. After, the app loads correctly.
Changelog: [General][Fixed] Correctly keep ES6Proxy for bridgeless mode
Reviewed By: cortinico
Differential Revision: D55045780
fbshipit-source-id: 666b99712d35622f87d42f22a4611851df67d905
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43251
Integrates the modern CDP backend with `CatalystInstanceImpl` (the React Native instance implementation) on Android.
This complete the modern CDP integration for Bridge.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D51458010
fbshipit-source-id: 6f73868da9d0d4cc5d086a4569c78444cb1b83ec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43657
This include is not correct and is breaking the OSS build
Changelog:
[Internal] [Changed] - Fix header import inside ReactInstanceManagerInspectorTarget.h
Reviewed By: rshest
Differential Revision: D55368321
fbshipit-source-id: 0530257ad5c548476beb882174d73842775b3726
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43646
PerformanceEntryReporter maintains a buffer of RawPerformanceEntry objects,
as well as a set of _pointers_ to elements within that buffer, used to find
entries by name.
However, those pointers aren't stable: BoundedConsumableBuffer internally uses
a vector, and there are a few cases where existing references get invalidated:
- When the vector's capacity changes (as new entries get inserted) [1]
- After calling clear-with-predicate, which copies elements into a new vector
This causes nameLookup to contain dangling pointers, and subsequent operations
on it can result in use-after-free.
Fix this by having BoundedConsumableBuffer reserve space for maxSize entries
up front (which ensures that existing pointers remain valid after adding new
elements) and by rebuilding nameLookup after clearing entries by name.
Note that reserve() causes the buffer's memory use to be higher than before in
case where the number of elements is small relative to the max size. Given the
(only) existing usage in PerformanceEntryReporter, as well as the property that
consumed elements remain in the buffer, that cost should be minor.
Changelog: [Internal]
[1] https://en.cppreference.com/w/cpp/container/vector/push_back
Reviewed By: rshest
Differential Revision: D55273403
fbshipit-source-id: c8f33203ae32685e29afa7f8e33edf1284d66e0f
Summary:
Small typo I encountered while trying to build custom C++ type converters :)
## 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
-->
[INTERNAL] [FIXED] Fixed a small typo in the "unsupported type" error message
Pull Request resolved: https://github.com/facebook/react-native/pull/43650
Reviewed By: zeyap
Differential Revision: D55364068
Pulled By: cortinico
fbshipit-source-id: 5a1bc9443c82f2473860f379c9ae063cd6e3ceb4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43655
## Changelog:
[Internal] -
The corresponding prop `ScrollBar.persistentScrollIndicator` was only passed to the Android platform code an `ScrollBar.horizontal` wasn't passed to native at all.
On other platforms we need those props to be available on the C++ side, so this exposes them to the corresponding C++ ScrollViewProps.
Reviewed By: sammy-SC
Differential Revision: D55367445
fbshipit-source-id: e8abca3a2b56a8e7c03593a6c4297f90749ac8fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43652
This improves the signature of our existing DOM APIs in 2 ways:
1. It replaces the use of `tuples` in `DOM.{h,cpp}` with safer structs.
2. It removes some unnecessary optionals from the API, returning the default values from the C++ API directly when appropriate.
It still preserves the use of tuples in the native module because objects are not properly supported in the codegen.
Changelog: [internal]
Reviewed By: NickGerleman
Differential Revision: D55316654
fbshipit-source-id: 16ce5ef62ca427cdcd6b9757d77db040e0ccc8b1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43626
The things that create ReactApplicationContext should instead create BridgeReactContext.
Long-term, ReactApplicationContext will be abstract. This diff pulls noise out from that eventual diff.
Changelog: [Internal]
Reviewed By: arushikesarwani94
Differential Revision: D55218591
fbshipit-source-id: d359c794f3da4a1ecb2fa8edbed5eeeb620b137b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43627
Eventaully, ReactApplicationContext.initailizeWithInstance() will be moved to BridgeReactContext.
Doing the migration up-front to remove noise from the eventual diff.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D55218593
fbshipit-source-id: c542c44cf8b36b9dc2a01db2bf6173639fb8698a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43624
Eventually, we will move all bridge methods to BridgeReactContext.
Long-term, ReactApplicationContext and ReactContext will become abstract. And these two contexts will only contain methods common to both modes.
Changelog: [Android][Added] Introduce BridgeReactContext
Reviewed By: cortinico
Differential Revision: D55218592
fbshipit-source-id: 731d4940d492a1ed3f855c9a181d2a6f9eeb9623
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43250
Integrates the modern CDP backend with `ReactInstanceManager` on Android.
`ReactInstanceManager` is equivalent to the CDP page / `HostTarget` concept, therefore we register the `addPage`/`removePage` calls with this object's lifecycle.
Implementation notes:
- `ReactInstanceManagerInspectorTarget` is created to avoid converting `ReactInstanceManager` to JNI (impacting tests).
- Its constructor receives a `TargetDelegate` object, so that we avoid passing the entire `ReactInstanceManager` class through (avoids cyclic dependency from `com.facebook.react.bridge` to `com.facebook.react`).
Changelog:
[Internal] - Register `ReactInstanceManager` with modern CDP backend
Reviewed By: motiz88
Differential Revision: D51456960
fbshipit-source-id: 942255bb2487fdc581eb4fa0903c8e68106f8b35
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43615
This class is used for a one-time setup of bindings into the jsi::Runtime. The lambda will retain ownership of any java components required, and we can rely on the teardown of the JS runtime to clean up any dependencies.
Changelog: [Internal]
Reviewed By: dmytrorykun
Differential Revision: D55241233
fbshipit-source-id: f7541f28277307be9b3a5f4f780c7eca1a467c57
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43614
Storing a global_ref to `jThis` in a JNI hybrid object leads to a reference cycle which cannot be cleaned up by Java GC. The Java object will keep the C++ object alive and vice versa.
In this class, we didn't seem to need this reference anyway.
Changelog: [Internal]
Reviewed By: dmytrorykun
Differential Revision: D55241232
fbshipit-source-id: 933521ed1483c149f693988ca17f4c53565dbfe0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43612
This class is used for a one-time setup of bindings into the jsi::Runtime. The lambda will retain ownership of any java components required, and we can rely on the teardown of the JS runtime to clean up any dependencies.
Changelog: [Internal]
Reviewed By: dmytrorykun
Differential Revision: D55241234
fbshipit-source-id: ee80ca0f91ebe95f8c44874b27912b260f70b572
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43618
Both common and Android implementations of AsyncEventBeat use weak_ptrs
to determine if the object is still valid before invoking the callback.
Move the write to `isBeatCallbackScheduled_` down so it's protected by
that same check.
Changelog: [Internal]
Reviewed By: javache, NickGerleman
Differential Revision: D55226529
fbshipit-source-id: 9e2a34369346d11dcea69d120dfa5935320f9ba1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43639
Currently, the `react-native/dev-middleware` inspector proxy intercepts `Debugger.scriptParsed` notifications from the target and replaces `sourceMapURL` with a data uri, via an async fetch from Metro. During this async fetch, other notifications from the debugger may pass through the proxy, which results in the frontend receiving them before `Debugger.scriptParsed`.
This reordering causes problems in breakpoint resolution and pausing, because `Debugger.breakpointResolved` and `Debugger.paused` events may reference `scriptId`s unknown to the frontend while the corresponding `Debugger.scriptParsed` is delayed.
In particular, breakpoint UI state and backend state can fall out of sync, and breakpoints hit may open to the incorrect source location.
This diff modifies the proxy to use a simple per-target promise queue to ensure messages are handled in the order they were received from the target.
Changelog:
[General][Fixed] Fix breakpoints opening to incorrect location or disappearing from debugger frontend UI.
Reviewed By: motiz88
Differential Revision: D55200617
fbshipit-source-id: 27c95f822266875ed668d0bf8a525da49554cafd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43642
Changelog: [internal]
This change broke some apps at Meta. Reverting until we figure out a safe way to land this.
Reviewed By: rshest
Differential Revision: D55324557
fbshipit-source-id: 684d3dc3780fc41e2e91f367d97fa5cd392e6638
Summary:
Now that RN is providing TS type information, many of those .d.ts files depend on types from react. In modern packagemanagers (Ex: pnpm) types/react will not be available to RN since it does not declare it as a dependency.
I also noticed that the types for react-native-popup-menu-android appear to be pointing to the wrong location.
Add types/react as a peerDependency on the packages that have .d.ts files that import from React.
Add types/react to peerDependencyMeta with optional:true to prevent users not using TS from requiring types/react.
## Changelog:
[GENERAL] [ADDED] Added types/react as an optional peerDependency
Pull Request resolved: https://github.com/facebook/react-native/pull/43509
Reviewed By: cortinico
Differential Revision: D55225940
Pulled By: NickGerleman
fbshipit-source-id: 4cbab071928cb925baec45f55461559acc9a54e6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43578
Changelog: [internal]
We have a feature to do some validation of the mount operations when committing new trees in Fabric. That's very slow but it was ok before because we were only doing this in debug mode and in the JS thread. We're moving some of this work to the UI thread instead and we're seeing an impact on scroll performance.
This disables this feature by default but leaves it in code to enable it when necessary for debugging.
Reviewed By: NickGerleman, sammy-SC
Differential Revision: D55138795
fbshipit-source-id: 45ca47ae2562cecb070691bf33d95c9108a9eca3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43580
Changelog: [internal]
This introduces a new feature flag to commit state updates synchronously from the UI thread (generally) instead of dispatching them to the JS thread to be processed there. We can do this now because we introduced a UI consistency mechanism in D55024832 to JS would see a consistent revision during the execution of a specific task.
Reviewed By: sammy-SC
Differential Revision: D55083029
fbshipit-source-id: 8aa84ddaee383f098252fa679cfb07012ba29bf8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43579
Changelog: [internal]
This updates all the legacy layout APIs in React Native to make use of the UI consistency mechanism introduced in Fabric (if available, otherwise the behavior is the same we have now — we consume the latest version of the tree available).
Reviewed By: sammy-SC
Differential Revision: D55077309
fbshipit-source-id: f6ff2a4f6cd1a2040f0cfeffb1e68f4ec0240f91
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43577
Changelog: [Internal]
This updates all the DOM APIs in React Native (defined in the `NativeDOM` native module) to make use of the UI consistency mechanism introduced in Fabric (if available, otherwise the behavior is the same we have now — we consume the latest version of the tree available).
As part of that work, this creates a new `DOMMethods` class that implements all methods using purely C++ APIs (not JSI), moves a lot of logic that was specific for this functionality from `UIManager` to `DOMMethods` and modifies `NativeDOM` to use this new class.
This should make it easier to add unit tests for `DOMMethods` in the future.
Reviewed By: NickGerleman
Differential Revision: D55077311
fbshipit-source-id: f96bf5f3a97236fd24dbd2315256de4ce979e151
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43581
Changelog: [internal]
This implements a mechanism to ensure that JavaScript tasks have a consistent view of the state of the UI during their execution.
## Context
Fabric allows committing new revisions of the ShadowTree from any thread, but we don't make use of this capability and instead always commit them from the JS thread (e.g.: when we schedule Fabric state updates to update the offset of a list on scroll). This was done to make sure that JS work didn't see changes in the state of the tree at random points during its execution. E.g.:
```
useEffect(() => {
const rect = ref.current.getBoundingClientRect();
// do something
const newRect = ref.current.getBoundingClientRect();
// `rect` and `newRect` should always be the same
}, []);
```
This isn't used by Reanimated at the moment, which means JS can inadvertently see the result of animations in non-specific times during execution.
You can find additional context about this in the [RFC for DOM Traversal & Layout APIs in RN](https://github.com/react-native-community/discussions-and-proposals/blob/main/proposals/0607-dom-traversal-and-layout-apis.md#consistency-and-updates).
This works correctly at the moment, but we introduce a limitation in the execution model to prevent updating the tree synchronously from the main thread. One of the main problems this introduces is that computing intersections (for `IntersectionObserver`) relies on the information in the shadow tree, but this is updated asynchronously on scroll.
There are 2 potential solutions for that problem:
1) Send the timestamp of the scroll even with the state update to backdate the timestamps of the intersections. This could work but introduces more complexity and possibly accuracy problems due to batching those state updates with other changes (e.g.: what happens if we update the state and commit another tree in the same task? should we use the backdated timestamp or wait for mount?).
2) (**Preferred**/ this diff) Allow committing new revisions from any thread, but lock the JS thread into seeing a specific revision, which would only update/progress in specific moments when it's safe. Some of those moments would be:
1) When we start a new JS task.
2) When we commit a new tree from React (JS).
## Changes
This implements the solution outlined in 2), creating a few abstractions to handle what's the current tree that should be visible to JS and to lock/unlock it in specific moments.
More specifically:
* Creates `ShadowTreeRevisionProvider` as an abstract class for APIs consuming the visible revision of the ShadowTree (mainly DOM APIs and layout methods like `measure`, etc.).
* Creates `ShadowTreeRevisionConsistencyManager` as an abstract class to handle what trees are visible (with a `lockRevision` and `unlockRevision` to be called from `RuntimeScheduler` at the beginning and end of each JS task).
* Creates 2 different implementations of these abstractions:
* One that preserves the current behavior (`LatestShadowTreeRevisionProvider`, which just returns the last committed revision at the time of the call).
* One that locks revisions lazily (the first time they're accessed) (`LazyShadowTreeRevisionConsistencyManager`).
Reviewed By: sammy-SC
Differential Revision: D55024832
fbshipit-source-id: b59985bc83714ae7ec915baba72bf92b3d6fa140
Summary:
I found in 0.74.0-rc.x, `ccache_enabled` is introduced. However, it is not being delivered via npm.
fixes https://github.com/facebook/react-native/issues/43633
Changelog: [iOS] [Fixed] - Adding ccache_clang wrapper scripts to package.json for distribution
Pull Request resolved: https://github.com/facebook/react-native/pull/43634
Reviewed By: cortinico
Differential Revision: D55308743
Pulled By: blakef
fbshipit-source-id: e89a4bb3a1fbf8562d880b4c9d25dc9083717ba6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43611
Storing a global_ref to `jThis` in a JNI hybrid object leads to a reference cycle which cannot be cleaned up by Java GC. The Java object will keep the C++ object alive and vice versa.
In this class, we didn't seem to need this reference anyway.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D55240490
fbshipit-source-id: 9ba6f5b4b958cb273ad1923332b7b29a75630aea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43613
Storing a global_ref to `jThis` in a JNI hybrid object leads to a reference cycle which cannot be cleaned up by Java GC. The Java object will keep the C++ object alive and vice versa.
We can replace the reference in this class by using the this pointer passed in when `installJSIBindings` is invoked.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D55241235
fbshipit-source-id: 64883752a87f363a52a9f6661d6ddaa24a56fe62
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43604
Changelog: [Internal]
Syncs the internal and OSS versions of `INTERNAL_CALLSITES_REGEX` in the default RN Metro config.
Reviewed By: robhogan
Differential Revision: D55237394
fbshipit-source-id: 8986a69f8beeafccbab3548d8a2137c0bf19e0b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43605
Changelog: [Internal]
Leverages https://developer.chrome.com/docs/devtools/x-google-ignore-list to mark more internal files as "third party", thus collapsing them by default in stack traces in modern versions of Chrome DevTools. The list of modules to collapse is the same one used by LogBox.
This likely only affects Meta usage, since Metro's default for [`isThirdPartyModule`](https://metrobundler.dev/docs/configuration/#isthirdpartymodule) already excludes all `node_modules`, but I'm making this change across Meta and OSS for consistency and to signal intent.
Reviewed By: huntie
Differential Revision: D55236653
fbshipit-source-id: d777ea31fb3d65608a487247924885c887ebbd94
Summary:
local-cli seems to have not been used, so we request to delete it
## Changelog:
[INTERNAL] [REMOVED] - Delete useless local-cli dir
Pull Request resolved: https://github.com/facebook/react-native/pull/43602
Reviewed By: cortinico
Differential Revision: D55281532
Pulled By: blakef
fbshipit-source-id: 8109222dbf643f1b1c3de491b4f42c07d09d8e13
Summary:
Changelog: [Internal]
fix for part of https://github.com/facebook/react-native/issues/43204
RCTBridge+Private is transitively bringing in boost in 0.74, which is causing build errors for some libs that were originally depending on it. this is because boost is a special pod that needs separate handling to link correctly.
let's simplify this problem by decoupling this header and moving the inspector specific logic into it's own category.
Reviewed By: motiz88, dmytrorykun
Differential Revision: D55228474
fbshipit-source-id: 28dacaf464b98fe1c164418934ab8101b47d7efb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43606
changelog: [internal]
D54805494 broke CircleCI because it didn't list all of the required dependencies in CMakeList.txt
Reviewed By: cortinico
Differential Revision: D55240313
fbshipit-source-id: 7a27b1379831582556ddd72007f17cbd2d507b19
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43609
When users are building from source for React Native they don't have an ndkVersion variable specified. So we want to fallback to the global NDK version we set for the whole build here.
Changelog:
[Android] [Fixed] - Fix build from source for hermes-engine
Reviewed By: dmytrorykun
Differential Revision: D55240603
fbshipit-source-id: 3c725a164b40e176548af8ada9fcb13d391ef017
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43607
PR #43526 was accidentally merged with several changes excluded. I'm following up on those here.
Changelog:
[Internal] [Changed] - Follow-up with Review Feedback on RCTAppDelegate from #43526
Reviewed By: dmytrorykun
Differential Revision: D55240435
fbshipit-source-id: c296a1e14b7032b211551334ca7b5a6824e8d45c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43592
changelog: [internal]
Exposing experimental API EventEmitter::experimental_flushSync to trigger synchronous event from native. The API will be changed in the future, this is exposed only for experimentation.
Reviewed By: javache
Differential Revision: D54805494
fbshipit-source-id: fb395588cf1dc944a920ec4a2257390552850263
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43594
I've been migrating `react-native-view-shot` to Fabric by using the `InteropUiBlockListener`
and I've realized that the interop layer doesn't work well.
1. FabricUIManager needs to implement `UIBlockViewResolver` in order for the interop layer to work correctly.
2. We need to hook `addUIBlock` to the `didDispatchMountItems` callback otherwise the UIBlocks won't be executed at all.
Changelog:
[Android] [Fixed] - Fix InteropUIBlockListener to support react-native-view-shot on Bridgeless
Reviewed By: javache
Differential Revision: D55187939
fbshipit-source-id: d048b4b5eed77fa856fdfac17c0df5f23fd44844
Summary:
This PR adds missing forwarding blocks to RCTRootViewFactory, currently when a user tries to override `sourceURLForBridge` in AppDelegate it isn't overridden.
## Changelog:
[IOS] [FIXED] - add missing forward blocks to RCTRootViewFactory
Pull Request resolved: https://github.com/facebook/react-native/pull/43526
Test Plan: Override: `extraModulesForBridge`, `extraLazyModuleClassesForBridge`, `bridge didNotFindModule`, `sourceURLForBridge:` methods in AppDelegate and check if they are called on old architecture
Reviewed By: philIip
Differential Revision: D55186872
Pulled By: cortinico
fbshipit-source-id: 5988c7bab1439ccc4885b7337336c1e120ba9ea6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43583
Fail during `pod install` if user's version of XCode is too old to avoid cryptic errors (e.g. https://github.com/reactwg/react-native-releases/issues/163).
I reused existing mechanism for version detection, though it may not be reliable for future versions of XCode.
Changelog:
[iOS][Changed] - Warn users during "pod install" if XCode is too old
Reviewed By: dmytrorykun
Differential Revision: D55149636
fbshipit-source-id: 78387ff19a6eb10f3ca0d4aa78e6b934ae3b0711
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43563
Fixes https://github.com/facebook/react-native/issues/42874
## Sumary
D9405703 added some custom logic for Flings, to support FlatList scenarios where content is being added on the fly, during Fling animation. This works by allowing start Fling to not have bounds, then correcting/cancelling Fling when overscroll happens over a bound that would normally be allowed.
This has some math to try to determine max content length, and will clamp to this when scrolling over it. This logic is incorrect when content length is less than scrollview length, and we end up snapping to a negative offset.
This change adds clamping, so that we don't snap to negative position in horizontal scroll view. This clamping was already indirectly present on vertical scroll view. https://www.internalfb.com/code/fbsource/[b43cdf9b2fec71f5341ec8ff2d47e28a066f052e]/xplat/js/react-native-github/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/scroll/ReactScrollView.java?lines=609
## Test Plan
Above issue no longer reproes. Flinging while content is being added to horizontal FlatList still works correctly.
Changelog:
[Android][Fixed] - Fix Android HorizontalScrollView fling when content length less than ScrollView length
Reviewed By: javache
Differential Revision: D55108818
fbshipit-source-id: 7cf0065f9f92832cc2606d1c7534fc150407b9c9
Summary:
- `rrc_textinput` at the moment points to a wrong subdirectory and needlessly adds a prefix path
- `rrc_text` is missing headers for `attributedstring` which it depends on
## Changelog:
[ANDROID] [FIXED] - Fixed prefab header paths for `rrc_text` and `rrc_textinput`
Pull Request resolved: https://github.com/facebook/react-native/pull/43591
Reviewed By: fkgozali
Differential Revision: D55199580
Pulled By: cortinico
fbshipit-source-id: 85126c00943f82e908a52e05587661597761852e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43574
Changelog: [Internal]
Once we start rolling out the Fusebox backend, users might still try to use the debugger frontends they're used to, for which we can't guarantee reliability. Let's detect this and log a message letting them know about the supported Fusebox launch flows.
Reviewed By: huntie
Differential Revision: D55122115
fbshipit-source-id: a17c0c6b9140059f489e0852fe673306fb6ef8f5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43575
Changelog: [Internal]
Adds the `HostAgent::sendConsoleMessage` and `InstanceAgent::sendConsoleMessage` helper methods, allowing the agent implementations to send simple, text-only console messages (using `Runtime.consoleAPICalled`) from the inspector thread, without involving the Runtime (and the JS thread).
We also update the tests to ignore such messages by default, since otherwise we would encounter a lot of unexpected mock calls.
## Context
We currently use `Log.entryAdded` messages for logs generated by the CDP backend itself. This cleanly separates backend-generated messages from app-generated `Runtime.consoleAPICalled` messages (including in tests), and avoids the need to provide an `executionContextId` for protocol compliance.
However, it turns out that frontends don't consistently support the `Log` domain - in particular, `chrome://inspect` doesn't show `Log` messages for targets of type `node` (which is how RN lists itself in the `/json` endpoint). For the majority of our `Log.entryAdded` use cases, this doesn't matter. But it does mean that if we want a log message to be visible regardless of the frontend, we need to send `Runtime.consoleAPICalled` messages instead.
The one concrete use case for this at the moment is detecting non-Fusebox clients and logging an explanatory message to point users to Fusebox. We can likely refactor most *existing* uses of `Log.entryAdded` in our code to use `sendConsoleMessage`, but I've opted not to do that here. Those are primarily useful within our team and can be deleted once Fusebox is out of testing.
Reviewed By: huntie
Differential Revision: D55130368
fbshipit-source-id: 4bc6a91efe63db6753250a3d383fd497c9f5f7b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43532
changelog: [internal]
- use designated initializers.
- make ScrollViewMetrics a struct.
- move ScrollViewMetrics inside of ScrollViewEventEmitter.
This is to be more consistent with other event emitters.
Reviewed By: rubennorte
Differential Revision: D54896331
fbshipit-source-id: 01aecd1835b23bdaccff1355d33eb7b4c5ba8d92
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43589
Changelog: [Internal]
Adds a way of enabling the Fusebox backend in React Native regardless of the corresponding feature flags. This is only supported in the Buck build and not intended for use in OSS.
Reviewed By: huntie
Differential Revision: D55144502
fbshipit-source-id: 116cd30464acfbd3fafc503300f94cb238adeda8
Summary:
Changelog: [internal]
This moves all the new methods that were added to implement the DOM traversal and layout APIs (as per this RFC: https://github.com/react-native-community/discussions-and-proposals/pull/607) to a separate C++ native module to avoid bloating the UIManager interface, initialize lazily, provide automatic caching of methods, simplify the API for implementors, etc.
Pull Request resolved: https://github.com/facebook/react-native/pull/43512
Reviewed By: sammy-SC
Differential Revision: D54903376
fbshipit-source-id: 69daa84c886d1c65dbb0b223dbb7c9077502c6ad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43568
Fixes to restore passing CI checks on main after D55027120.
- Widen validation checks in version utils to accept `0.x.x` (as opposed to `0.[not-'0'].x`).
- Use `tag: test` instead of `tag: latest` for dry run job params.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D55123739
fbshipit-source-id: 9f76dced4e7aa3ce87d6680cd7687ae443305331
Summary:
Changelog: [Internal] Remove console logs from Metro when native Fusebox debugger console is available
React Native currently sends all `console.log` messages to Metro, which prints them to the terminal. This feature has been in place since 2019 (D15559151) but is pretty limited when compared to what's available in modern browsers. Most of the limitations can't really be fixed within the constraints of Metro's relatively simple terminal infrastructure.
With the new React Native debugger (codenamed "Fusebox") we aim to fundamentally elevate the debugging experience by shipping a well-tested version of Chrome DevTools with React Native. Chrome DevTools has a rich, interactive console, as well as a host of other debugging features we want developers to notice and use.
To that end, we plan to **strongly nudge users towards the Fusebox console from day 1**. Specifically, if we detect that Fusebox is available and is using an engine which implements CDP `console` support ( = Hermes only for now), we'll no longer send logs to Metro, and will instead display an explanatory message directing users to Fusebox.
Reviewed By: huntie
Differential Revision: D54829811
fbshipit-source-id: 2b1cdb666094f901ff4e7f42b123271be4ce7d10
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43565
Changelog: [Internal]
Uses https://github.com/facebookexperimental/rn-chrome-devtools-frontend/pull/24 to identify the Fusebox frontend and show a corresponding message in the logs.
Also tweaks the wording and formatting of other messages logged by the Fusebox backend - including removing the "you are using the modern CDP backend" one.
Reviewed By: huntie
Differential Revision: D55075645
fbshipit-source-id: c82670570c79b61efd399f26684139ce97f017ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43537
This file always had a bunch of errors and made it so that actual errors do not show up (too many emitted). It was just because we are not including RawProps.h. I am not sure how it ever got compiled but I guess some header included something that included something etc. Maybe its a vs code issue but this seems like an obvious fix
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D55041883
fbshipit-source-id: 3445770dd25dbe294024649f96f9e3af7777b2b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43554
changelog: [internal]
The prop endDraggingSensitivityVelocityMultiplier makes the API more complicated and provides only limited benefit. Let's remove it for the sake of simplicity.
Reviewed By: christophpurrer
Differential Revision: D53853298
fbshipit-source-id: d2663f2f6eef1dde3136debe8965ee871f4e043d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43534
This is no longer used after switching to the new release workflow, which uses the newer and less error-prone `set-version` script.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D55027122
fbshipit-source-id: faa8cfd2af9b54fab611b108df162793c5768695
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43533
Switch to the new unified release workflow by default, now that this has been validated on the `0.74-stable` branch.
- Remove `--use-new-workflow` flag and remove legacy logic.
- Remove legacy `prepare_package_for_release` CI job, and use `run_new_release_workflow` -> `run_release_workflow` as new workflow condition match.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D55027120
fbshipit-source-id: 7c05cdff95ac369ce6cd1201ccfc5718798c4da6
Summary:
Updated linters, include typings in `package.json` and removed bun from the clean commands.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D54493859
fbshipit-source-id: eb28d208de722c90916b14f56d5a8e847bb3d859
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43530
Fixes and changes following D54956345, encountered during the release process for 0.74 RC4 today.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D55017872
fbshipit-source-id: 616b387088db00c6f076f4571b4ab1541467361c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43520
Refactor ReactDelegate to have a private `getDevSupportManager()` that can also be re-used by `reload()`
This method conditionally provides the correct DevSupportManager in cases of Bridge & Bridgeless
Changelog:
[Internal] internal
Reviewed By: cortinico
Differential Revision: D54967130
fbshipit-source-id: 37d585de33a50b98d01803d3080c5693a8c494b9
Summary:
The [Windows fix](https://github.com/cezaraugusto/chromium-edge-launcher/pull/1) was merged and published. We no longer need to use the fork.
## Changelog:
[INTERNAL] [FIXED] - Fix experimental debugger launch flow with Edge on Windows
Pull Request resolved: https://github.com/facebook/react-native/pull/43524
Test Plan: n/a
Reviewed By: robhogan
Differential Revision: D55013623
Pulled By: motiz88
fbshipit-source-id: bff2aa2801dd0dcdd6975dca0a2ec2aa9864ff6f
Summary:
Minor fix to package.json which newer version of npm warn about when publishing, after running `npm pkg fix -ws` on the workspace.
{F1470070110}
## Changelog: [Internal] npm pkg fix -ws
Pull Request resolved: https://github.com/facebook/react-native/pull/43519
Test Plan: eyescloseddog
Reviewed By: cortinico
Differential Revision: D55012872
Pulled By: blakef
fbshipit-source-id: ff3c63a3eefaf56d369219a3d4b32d44d6d842c9
Summary:
This PR updates `typescript-eslint/eslint-plugin` and `typescript-eslint/parser` to `v7` and `eslint-plugin-jest` to `v27`, removing any dependencies on `typescript-eslint` `v6`, allowing projects using `react-native/eslint-config` to safely update to `typescript-eslint` `v7` without having to worry about duplicate major versions installed
## Changelog:
- [General] [Changed]: Updated `eslint-plugin-jest` to `v27`
- [General] [Changed]: Updated `typescript-eslint` monorepo to `v7`
Pull Request resolved: https://github.com/facebook/react-native/pull/43406
Test Plan: `yarn run lint` executed locally successfully
Reviewed By: robhogan
Differential Revision: D54749676
Pulled By: tdn120
fbshipit-source-id: f6fae92fc95333e28b36a3d2bd8470c8869d38bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43385
`rncore` and `FBReactNativeComponentSpec` contain the same symbols, which leads to conflicts when we try to merge them into a single shared library. Cleanup the duplication and standardize on `FBReactNativeComponentSpec` everywhere. I've left the Android OSS targets as is, to avoid breaking deps.
Changelog: [Internal]
Reviewed By: cortinico, dmytrorykun
Differential Revision: D54630694
fbshipit-source-id: 75cb961ded9fd75508755c0530e29409fef801cf
Summary:
### Context
- Since RN 0.73, in the jest.setup file, methods of the Image module (Image.getSize, Image.resolveAssetSource...) are mocked on the **JS side** (introduced in https://github.com/facebook/react-native/pull/36996)
- It causes issues like https://github.com/facebook/react-native/issues/41907 : `Image.resolveAssetSource` returns nothing in test env with the new JS mock, when some test relies on it.
- On my project, it broke the snapshots : the URL of images disappeared. I use `react-native-fast-image` which uses `Image.resolveAssetSource` to compute URLs.
- I first opened a PR to fix exclusively Image.resolveAssetSource: https://github.com/facebook/react-native/pull/41957. I will close it to focus on this new one.
- As suggested by ryancat and idrissakhi, it should be better to return to the previous mock, where no method is mocked on the JS side, and we can trust the actual JS to work in test.
This is what this PR intends to do.
### Content
Along fixing the Image module mock in jest.setup, this PR :
- adds unit test on each one of the methods, ensuring they have a consistent behavior even when the module is mocked.
- adds 3 missing native mocks for `NativeImageLoader`: `prefetchImageWithMetadata`, `getSizeWithHeaders` & `queryCache`. After this PR, no method from NativeImageLoader remains unmocked.
## Changelog:
[GENERAL][FIXED] - fix jest setup for Image methods (resolveAssetSource, getSize, prefetch, queryCache)
Pull Request resolved: https://github.com/facebook/react-native/pull/43497
Test Plan:
See exhaustive unit tests in PR.
You can re-use the mock with all the methods mocked and see how the new unit tests fail.
I also patched those changes on my project: my snapshot did have their URL back (see demonstrative screenshots in my original PR: https://github.com/facebook/react-native/pull/41957 - NB; fixed mock was different but result was the same -> those screenshots cover only two cases, but anyway they illustrate well the case!)
Reviewed By: ryancat
Differential Revision: D54959063
Pulled By: tdn120
fbshipit-source-id: 837266bd6991eb8292d9f6af1774e897ac7a8890
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43504
Changelog: [internal]
We identified the issue in the experiments already, so we can remove this flag.
Reviewed By: sammy-SC
Differential Revision: D54945099
fbshipit-source-id: 4d547569eb3bbfd011f5d6894d87bfa542cac07b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43503
Changelog: [internal]
## Context
In the experiments to enable mount hooks on Android we saw some crashes that we couldn't reproduce or pinpoint accurately.
We ran another experiment excluding part of the code in one of the variants, and we found that the problem was in this block (only crashes when `skipMountHookNotifications` is false):
https://github.com/facebook/react-native/blob/121b26184acbb77ff4f2360647cb322ff560b145/packages/react-native/ReactCommon/react/renderer/uimanager/UIManager.cpp#L726-L734
Looking more closely at the mounting coordinator code, I realized that some of the methods are not thread-safe, which is likely causing these issues.
~~We're probably only seeing these issues on Android because we have a push model there (we call `pullTransaction` from whatever thread we're committing to, JS thread or Fabric background thread) whereas in the rest of platforms we have a pull model and we always access call `pullTransaction` from the main thread, as we do to report mounts.~~
This is probably fine because both cases are protected by a mutex when accessing through `ShadowTreeRegistry::visit`. But there's a case that doesn't go through it that could be causing the issues: prerendering:
https://github.com/facebook/react-native/blob/121b26184acbb77ff4f2360647cb322ff560b145/packages/react-native/ReactCommon/react/renderer/scheduler/SurfaceHandler.cpp#L289
## Changes
1) Make `getBaseRevision` return a copy of the revision rather than a reference.
2) Make all methods that access `baseRevision_` and `lastRevision_` thread-safe.
Reviewed By: javache
Differential Revision: D54945100
fbshipit-source-id: d8b211137d0eac02a5814cc6c376c22733290eab
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43507
Changelog: [General][Changed] - sync React renderers to 18.3.0-canary-9372c6311-20240315
Syncs React renderers to https://github.com/facebook/react/commit/9372c63116fc1e855c51d93d83f5150661371ec3 which is canary for 18.3.0-canary-9372c6311-20240315.
This includes the necessary changes to enable the use of microtasks for scheduling in Fabric.
Reviewed By: yungsters
Differential Revision: D54947212
fbshipit-source-id: 8fd5def5107d77e6a248f653a9d0260b392fab6b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43518
This is a minimum approach to achieve a **single-command publish flow** for React Native, unifying the previous `yarn bump-all-updated-packages` and `yarn trigger-react-native-release` workflow entry points.
This diff aims to change as little as possible to achieve the above — introducing a new job that merges operations to create the versioning commit. The triggered publish jobs are unchanged. In future, we may follow this change with further simplifications down the workflow tree.
**Key changes**
- Adds a new CircleCI workflow, `prepare_release_new`, which versions **all packages** and writes a single release commit.
- This replaces `yarn bump-all-updated-packages`, now implemented with the newer `set-version` script.
- Wires this up as an experiment within `trigger-react-native-release.js`, conditionally running the new workflow when `--use-new-workflow` is passed.
**Not changed**
- The single release commit written will continue to trigger both of the existing CI workflows on push (`publish_release` and `publish_bumped_packages`), which are unchanged.
- The commit summary now includes the `#publish-packages-to-npm` marker, in order to trigger `publish_bumped_packages`.
- Usage: Release Crew members will continue to use the existing local script entry point (as [documented in the releases repo](https://github.com/reactwg/react-native-releases/blob/main/docs/guide-release-process.md#step-7-publish-react-native)), with the opt in flag.
```
yarn trigger-react-native-release --use-new-workflow [...args]
```
After we're happy with the E2E behaviour of this workflow in the next 0.74 RC, I will follow up by dropping the `--use-new-workflow` flag and removing the old scripts (T182533699).
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D54956345
fbshipit-source-id: 35fd7af8f3e60a39507b5d978ccd97472bf03ddb
Summary:
This is causing Twilight Android app to hang and crash on start
Original commit changeset: 3f24271405f6
Original Phabricator Diff: D54905564
Reviewed By: sammy-SC
Differential Revision: D54960053
fbshipit-source-id: 5c1063f11ae1314e71288905eb6d8da32ddbfadd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43516
As titled. This seems dangerous — removing with the motivation that we'd prefer this script to fail during execution than to succeed in publishing `9999`.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D54956661
fbshipit-source-id: 23f8d49abd300385dde74871b6d2492ef63f058e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43513
The previous `update_podfile_lock.sh` script would fail as executed from the repo root (could not locate RNTester dir). Delete this and replace with direct calls in `prepare-package-for-release.js`, which will fail script on error.
{F1469216632}
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D54949214
fbshipit-source-id: 4f032069e803e84f835c279d01332d16787dfafc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43511
Changelog: [Internal]
This is an attempt to fix [#39783](https://github.com/facebook/react-native/issues/39783).
It seems that when `configureBuildForHermes` runs (as part of `yarn android` in `rn-tester`) cmake may not be available and is not installed automatically:
* for 3p, even after installing the latest Android Studio, cmake 3.22.1 is not available by default but needs to be installed manually
* for Meta employees, same story when looking at the `ANDROID_HOME` set by the `setup_fb4a.sh` in the `.zshrc` file:
```
# added by setup_fb4a.sh
export ANDROID_SDK=/opt/android_sdk
export ANDROID_NDK_REPOSITORY=/opt/android_ndk
export ANDROID_HOME=${ANDROID_SDK}
export PATH=${PATH}:${ANDROID_SDK}/emulator:${ANDROID_SDK}/tools:${ANDROID_SDK}/tools/bin:${ANDROID_SDK}/platform-tools
```
This diff introduces an explicit task to install cmake.
### ALTERNATIVE 1
See D54897379.
### ALTERNATIVE 2
Suggested by cortinico:
> Create a mini module called :packages:react-native:ReactAndroid:hermes-engine:cmake-downloader which just triggers an empty cmake build via Android SDK
Reviewed By: cortinico
Differential Revision: D54859484
fbshipit-source-id: f9ecdf78ff408947b1e85e7da4f112c89d3a8c89
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43506
Changelog: [internal]
We've been making all the built-in C++ TurboModules in RN extend `enable_shared_from_this` because we copied from the same template that needed it, but none of them do. This removes that unnecessary extension.
Reviewed By: sammy-SC
Differential Revision: D54901332
fbshipit-source-id: 795c7696e70041d640399e3b9f177999e22fd90b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43470
Changelog: [internal]
This moves the native code for the Web Performance API to `ReactCommon`, to align with the other default C++ native modules we've defined there.
Reviewed By: sammy-SC
Differential Revision: D54860194
fbshipit-source-id: 32dccb080fb8ebd1e2acbdd59fa2dfe47e372c17
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43482
## Context
We are migrating to the new Hermes `CDPAgent` and `CDPDebugAPI` APIs in the modern CDP server (previously `HermesCDPHandler`).
## This diff
Now that we are confident that `CDPAgent` is stable, switch to it by default and remove the previous integration.
- Drop `inspectorEnableHermesCDPAgent` feature flag.
- Rename and replace `HermesRuntimeAgentDelegateNew` as `HermesRuntimeAgentDelegate`.
- Drop "Hermes integration: CDPAgent" log message.
- Update tests.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D54897841
fbshipit-source-id: 8a5212d27f21c54112c0820a2a3611e05d606880
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43493
This is a bump of one of our external GH custom action
Closes#38046
Changelog:
[Internal] [Changed] - Bump needs-attention to v2.0.0
Reviewed By: GijsWeterings
Differential Revision: D54905530
fbshipit-source-id: 1ecc25926144641bfc080b4ca7b8551a00a0caa1
Summary:
Changelog: [Internal]
TSIA - useful for the `console` test suite I'm currently writing (D54846940) which would be awkward to fit into `JsiIntegrationTest.cpp`.
bypass-github-export-checks
Reviewed By: huntie
Differential Revision: D54846938
fbshipit-source-id: 9e20bfae7c518b3822da468adf484e51cdc4d0b9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43459
Changelog: [General][Changed] - Console polyfill now copies all properties from the existing `console` object
Fusebox now exposes a full WHATWG `console` object integrated directly with CDP debugging (D54826073). Some WHATWG `console` methods are missing from React Native's polyfill/shim, so let's pass those through unmodified so they can still be called.
(Long term, we shouldn't need most of `console.js`, but let's get there gradually as there are many RN users still depending on `nativeLoggingHook` etc.)
NOTE: We also update the "bundled" copy of `console.js` that lives in the jsinspector-modern C++ test suite.
Reviewed By: huntie
Differential Revision: D54827902
fbshipit-source-id: c6c9128903496810192614f4f8d80b68b02e25c4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43495
## Changelog:
[Internal] -
Fixes build regression of RNTester on OSS, coming from D54764898.
NOTE: This is only Android bit for now, looking into the iOS one.
Reviewed By: cortinico
Differential Revision: D54908736
fbshipit-source-id: 70081d1378a56dd0df3f76322377f5a0e6615f80
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43461
Adds a regression test for the duplicate `scriptParsed` bug in Hermes (T182003727). In the process, we enable Hermes lazy compilation in all our CDPAgent JSI integration tests.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D54852326
fbshipit-source-id: 52e23458d3e9e21902c3659fc944ef85c68731ac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43496
This diff adds another sub-sub-spec to React-Fabric pod to fix import paths in `textinput`.
Changelog: [Internal]
Reviewed By: philIip, rshest
Differential Revision: D54918454
fbshipit-source-id: 3949f8b8b201157f4c9eb256f3eb5bd5d66bc228
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43438
changelog: [internal]
EventQueue can now be merged with BatchedEventQueue since there isn't anything else subclassing it.
Reviewed By: javache
Differential Revision: D54687859
fbshipit-source-id: f646583db0e46789b667f8d79d24d0cf9d7fc00c
Summary:
Changelog: [Internal]
We are currently eagerly constructing a `HermesRuntimeTargetDelegate` regardless of whether the Fusebox feature flags are enabled. This can interfere with the legacy CDP backend. Instead, let's lazily construct the target delegate in a code path that only runs when the modern backend is in use.
bypass-github-export-checks
Reviewed By: rozele
Differential Revision: D54907887
fbshipit-source-id: 7dc13506739866ea6690ed21d03d91ad24ef68c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43487
Inconsistent between bridge and bridgeless, but if you forget to implement this interface, ReactDelegate will silently not do anything in bridgeless.
Changelog: [Android] Enforce Activities using ReactDelegate implement DefaultHardwareBackBtnHandler.
Reviewed By: arushikesarwani94
Differential Revision: D54900747
fbshipit-source-id: 5dd31d4f81e4ec37e1c3ee906be836a8a9c6a944
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43491
This diff brings back the `UNSET` constant to `TextAttributeProps`.
The removal of this constant was an unnecessary breaking change, that has broken several third-party libraries.
Changelog: [Android][Fixed] - Bring back the UNSET constant to TextAttributeProps.
Reviewed By: fabriziocucci
Differential Revision: D54899524
fbshipit-source-id: 368bde77d43f310fd458537d0191d09174fa5167
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43456
Changelog: [Internal]
Implements the [WHATWG `console` spec](https://console.spec.whatwg.org/) directly in `RuntimeTarget`, based on the Hermes-powered `addConsoleMessage` method first used in D54494298.
Benefits:
* This allows the console API to work independently of the polyfill shipped in RN, including very early during JS execution.
* It also opens the door to better stack traces (once we start reporting those) and richer functionality in the `console` object itself.
Reviewed By: robhogan
Differential Revision: D54826073
fbshipit-source-id: d5b0bd004bf35c2fce91742ae84ea86225ec1c61
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43486
We use `CopyOnWriteArrayList` in other places across the React Native codebase, as it assumes that reading happens more frequently than updating. This saves us from needing to synchronize and copy when we access the list of listeners.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D54806272
fbshipit-source-id: d1b54d532edb2af3391a7e4fdc758f705621227d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43478
This is rolled out internally already. Also exposing `memoryPressureRouter` to match the ReactInstanceManager interface.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D54802021
fbshipit-source-id: b74dcde71296d3925acfc2171d2a77d90960e15e
Summary:
Changelog: [Internal]
Adds a regression test for a Hermes CDPAgent bug using `JsiIntegrationTest`. See details in comments.
bypass-github-export-checks
Reviewed By: huntie
Differential Revision: D54890188
fbshipit-source-id: 325a32b83b145d2d35f99feaef9988028f15f196
Summary:
I was recently working on an [issue](https://github.com/software-mansion/react-native-reanimated/issues/5715) in Reanimated where z-index of some views was broken after a Layout Animation was used. The issue was that in some cases we were calling the `removeView` function on a already removed view. On plain Android this wouldn't be an issue, since the `removeView` function ignores such calls. Unfortunately, the `ReactViewGroup.java` implementation maintains a counter of views with user defined z-index. This counter is decremented whenever a call to `removeView` is made, even if the view is not a child of this `ViewGroup`. This PR adds an additional check in the `handleRemoveView` function to unify the `removeView` behavior between Android and react-native.
## Changelog:
[ANDROID] [CHANGED] - Changed the `handleRemoveView` function in `ReactViewGroup.java` to ignore calls for `Views` that are not children of this `ViewGroup`
Pull Request resolved: https://github.com/facebook/react-native/pull/43389
Test Plan: I tested if the `rn-tester` app behaves correctly after those changes.
Reviewed By: NickGerleman
Differential Revision: D54874780
Pulled By: javache
fbshipit-source-id: f1a34947419ef6106ee73b196ae99b7f8c2f7a77
Summary:
Implements the RFC which progressively provides warnings to users of the `npx react-native init` command as we gradually deprecate.
Changelog:
[General][Deprecated] - init cli deprecation logging
Reviewed By: cortinico
Differential Revision: D54423109
fbshipit-source-id: 679b6672bdbfc42a9b82a2aad38fd3253c6ea6a2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43357
This diff adds a class to get the needed RenderEffects to support CSS filters on Android. This diff does not add any of the plumbing for it to actually work, that comes in the next diff, but I figured this was complicated and isolated enough to be on its own.
Note that I did not add blur or drop shadow as those are a bit more involved and I plan on adding them later.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D54603892
fbshipit-source-id: 5780d7c846fdb1116e29e0a940ee02da609b01f5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43453
The forward declaration for RCTMountingManager doesn't appear to be used anywhere. It can be deleted.
## Changelog
[Internal]
Reviewed By: NickGerleman
Differential Revision: D54692764
fbshipit-source-id: ba8206408fdd515387a0a6aff6a3e43c51221e57
Summary:
When users create a new app, there is an option: Follow us on Twitter with the description. Twitter is X now.

## Changelog: [Internal]
Replace the Twitter link, title, and description with X.
Pull Request resolved: https://github.com/facebook/react-native/pull/43423
Test Plan: Set the environment for React Native app and then `npx react-native@latest init AwesomeProject`, `npm start`, and `npm run ios`
Reviewed By: cortinico
Differential Revision: D54850199
Pulled By: huntie
fbshipit-source-id: 424cb9212962d78a5b2d93d973f56498ba948136
Summary:
Changelog: [Internal]
Use our build script for packages and to generate the TypeScript types.
bypass-github-export-checks
Reviewed By: huntie
Differential Revision: D54428870
fbshipit-source-id: 2a1666d30ac472300979b2be078a906d390e919a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43460
Currently pressing the menu button (or CMD+M) is broken on Bridgeless mode.
Also pressing RR is not reloading the App.
That's because some Bridgeless API haven't been reimplemented correctly on Android. I'm fixing them here.
Fixes#43451
Changelog:
[Android] [Fixed] - Properly handle RR and CMD+M in Bridgeless Mode
Reviewed By: huntie
Differential Revision: D54852959
fbshipit-source-id: 8fbbdab6818da9177e6db40e45d35258c7f5e236
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43458
The React sync in D54783723 was failing because some tests were relying on `console.error` being called as `console.error('Some message')` but it was refactored as `console.error('%s..', 'Some message')`, making them fail.
This fixes the tests by formatting the arguments passed to the console functions and checking against that instead.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D54849485
fbshipit-source-id: 0648263614725ea3f9c95b9f9bb13005adae46eb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43431
## Changelog:
[Internal] -
This takes all the common props for TextInput between Android and iOS and factors them out into a single, platform independent props data structure, `BaseTextInputProps`.
This way it's both easier to manage the corresponding props, but also making this easier to be used on other platforms.
Reviewed By: sammy-SC
Differential Revision: D54764898
fbshipit-source-id: 224b01c5a67ba5d5216cd5c482bf650a1c2453d5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43441
`RuntimeScheduler::getIsSynchronous` is currently used to check if the current task is being executed on the main thread, to avoid using the background executor. This was part of a test to dispatch events synchronously in an app using background executor.
We're not running that test anymore and this method doesn't make a lot of sense in the first place (it's not checking if the current task is running on the main thread, only if the caller of the task scheduled it synchronously from whatever thread they called from), so we can remove the method.
If this is necessary in the future we should create a method that actually does something useful (like `isCurrentTaskOnMainThread()`).
Changelog: [internal]
I consider this change not to be a breaking change because runtime scheduler wasn't an official public API, and what we want to make public doesn't include this method.
Reviewed By: sammy-SC
Differential Revision: D54804805
fbshipit-source-id: 54b3a6586e08bccc201df848b942fb1fcae29f30
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43446
## Context
We are migrating to the new Hermes `CDPAgent` and `CDPDebugAPI` APIs in the modern CDP server (previously `HermesCDPHandler`).
## This diff
Following D54712525, add a test case that validates `"Debugger.enable"` is persisted between reloads. This has been actioned by creating a further test group, `ModernHermesVariants`, and scoping the existing `ResolveBreakpointAfterReload` to this, with the removed second `"Debugger.enable"` message.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D54808212
fbshipit-source-id: 0775beb85a0907cca4dccbc77ec461d9515ab078
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43448
## Changelog:
[Internal] -
This adds a stub for `TextLayoutManager.measureCachedSpannableById`, as well as a missing explicit dependency to `jni/react/jni` from the `TextInput` implementation on the Android platform.
This is required in order for certain build configurations to compile.
Reviewed By: andrewdacenko
Differential Revision: D54807518
fbshipit-source-id: 206f0edb03a4ed328a962e57d1e791614eb7f851
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43450
Changelog: [Internal]
This is just to make sure that all instances of `LongLivedObjectCollection` map can be safely accessed by multiple threads.
Reviewed By: RSNara
Differential Revision: D54801015
fbshipit-source-id: e0b15bfbeac9ce3a1051f83a59c5513a90ba2a4b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43392
## Context
We are migrating to the new Hermes `CDPAgent` and `CDPDebugAPI` APIs in the modern CDP server (previously `HermesCDPHandler`).
## This diff
Wires up `previouslyExportedState` with `CDPAgent`, and re-enables the `ResolveBreakpointAfterReload` integration test.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D54369985
fbshipit-source-id: 5dcb4fe59b8b36b2db9f0385e8487097822e5704
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43437
## Changelog:
[iOS][Removed] - remove EventPriority class and always use the default EventPriority::AsynchronousBatched. This is potentially a breaking change if something in OSS sets a different priority. If a build fails because of this, simply remove the use of EventPriority.
EventPriority::AsynchronousBatched is the default and none of the other priorities are used anymore. This is the first step of removing this concept from the codebase.
Reviewed By: NickGerleman
Differential Revision: D54684311
fbshipit-source-id: 18240e5ee84f489f43b15fd9aab43f3b1b1b4963
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43398
Implement onWindowFocusChange in Bridgeless by adding it to the ReactHostImpl
Changelog:
[Android][Breaking] Implement onWindowFocusChange in Bridgeless
Reviewed By: javache
Differential Revision: D54670119
fbshipit-source-id: 71f560e5a3bf0e853ac06955e67b8035f1ec0468
Summary:
X-link: https://github.com/facebook/yoga/pull/1593
Pull Request resolved: https://github.com/facebook/react-native/pull/43417
There was a bug where we did not position absolute nodes correctly if the static node had a different main/cross axis from the containing node. This fixes that. The change is somewhat complicated unfortunately but I tried to add sufficient comments to explain what is happening
Reviewed By: NickGerleman
Differential Revision: D54703955
fbshipit-source-id: 096c643f61d4f9bb3ee6278d675ebd69b57350d7
Summary:
## Changelog:
[General][Fixed] - Fix broken native animation in Paper
In Native Animated Paper, `scheduleUpdate` must not be called. In Fabric, the synchronisation between Fiber and Shadow trees is a must but in Paper it sets undesired state.
Reviewed By: javache
Differential Revision: D54799237
fbshipit-source-id: f6b07dc377111ed2f8253ea0c7c7e312168166e8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43444
Re-enable a test now that D54649943 added correct handling of stale execution context IDs.
NOTE: There's a minor difference in returned error code. The test now allows either, though note that the old implementation is more consistent with Chrome itself which returns -32000 (server error). Semantically -32600 (invalid request) seems more appropriate.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D54805777
fbshipit-source-id: eb2baadf6b35319f5331462425eaa38b4edfab28
Summary:
This is a proposal for the `react-native/dev-middleware` package, to allow implementers to extend the CDP capabilities of the `InspectorProxy`. It's unfortunately needed until we can move to the native Hermes CDP layer.
At Expo, we extend the CDP capabilities of this `InspectorProxy` by injecting functionality on the device level. This proposed API does the same, but without having to overwrite internal functions of both the `InspectorProxy` and `InspectorDevice`.
A good example of this is the network inspector's capabilities. This currently works through the inspection proxy, and roughly like:
- Handle any incoming `Expo(Network.receivedResponseBody)` from the _**device**_, store it, and stop event from propagating
- Handle the incoming `Network.getResponseBody` from the _**debugger**_, return the data, and stop event from propagating.
This API brings back that capability in a more structured way.
## API:
```ts
import { createDevMiddleware } from 'react-native/dev-middleware';
const { middleware, websocketEndpoints } = createDevMiddleware({
unstable_customInspectorMessageHandler: ({ page, deviceInfo, debuggerInfo }) => {
// Do not enable handler for page other than "SOMETHING", or for vscode debugging
// Can also include `page.capabilities` to determine if handler is required
if (page.title !== 'SOMETHING' || debuggerInfo.userAgent?.includes('vscode')) {
return null;
}
return {
handleDeviceMessage(message) {
if (message.type === 'CDP_MESSAGE') {
// Do something and stop message from propagating with return `true`
return true;
}
},
handleDebuggerMessage(message) {
if (message.type === 'CDP_MESSAGE') {
// Do something and stop message from propagating with return `true`
return true;
}
},
};
},
});
```
## 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
-->
[GENERAL] [ADDED] - Add inspector proxy device message middleware API
Pull Request resolved: https://github.com/facebook/react-native/pull/43291
Test Plan: See added tests and code above
Reviewed By: huntie
Differential Revision: D54804503
Pulled By: motiz88
fbshipit-source-id: ae918dcd5b7e76d3fb31db4c84717567ae60fa96
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43397
Changelog: [internal]
This migrates the Hermes-specific use of microtasks to an engine agnostic implementation based on the new JSI method to queue microtasks.
Reviewed By: sammy-SC
Differential Revision: D54687056
fbshipit-source-id: b077ba47b80f7b31c77b7e449def8a56061b0b69
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43395
Changelog: [internal]
This moves native module specs to `specs` directory to align with the general convention.
Reviewed By: cortinico
Differential Revision: D54680056
fbshipit-source-id: 8b6ae6187e2ffa9120159b7d1fa25957677e0f4f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43394
Changelog: [internal]
When we built the new feature flag system we added a constraint in the JS API to prevent calling `override` if any of the flags was already accessed from JS.
This is very restrictive because it doesn't allow us to access common flags (like `enableMicrotasks`) set up from native during the initialization of the framework because then applications wouldn't be able to set JS-only overrides.
This relaxes the constraint to disallow accessing JS-only flags before setting JS-only overrides, but accessing common (native) flags before that is ok.
Reviewed By: rshest
Differential Revision: D54687055
fbshipit-source-id: b0716f24baf7d12a5e4a61fba79e6b50ef0ad10a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43393
Changelog: [internal]
The generator doesn't create intermediate directories, which is causing issues now that we're moving the generated native module spec to a new directory.
This fixes that.
Reviewed By: rshest
Differential Revision: D54690126
fbshipit-source-id: 1ba0d821872da7bbe1f6120ef6d0c1f800326778
Summary:
At Expo, we use [Expo Tools](https://github.com/expo/vscode-expo/blob/main/src/expoDebuggers.ts) to connect the [built-in vscode-js-debug](https://github.com/microsoft/vscode-js-debug) to Hermes.
Since there are a few differences in vscode vs chrome devtools, we need to enable a couple of modifications through the [`customMessageHandler` API](https://github.com/facebook/react-native/pull/43291). Unfortunately, vscode itself doesn't set the `user-agent` header when connecting to the inspector proxy. Becuase of that, we'd need a fallback to "manually" mark the debugger as being vscode ([we use this query parameter here](https://github.com/expo/vscode-expo/blob/main/src/expoDebuggers.ts#L208)).
This PR supports setting the `user-agent` through `?userAgent=` when the header is not set.
## 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] [ADDED] - Fallback to query parameter based `user-agent` when header is unset
Pull Request resolved: https://github.com/facebook/react-native/pull/43364
Test Plan:
- Install [Expo Tools](https://marketplace.visualstudio.com/items?itemName=expo.vscode-expo-tools)
- Start Metro with this change.
- Connect a device.
- Run the vscode command `"Expo: Debug Expo app ..."`
- Debugger should connect, and have it's user-agent marked as:
`vscode/1.87.0 vscode-expo-tools/1.3.0`
Reviewed By: huntie
Differential Revision: D54804556
Pulled By: motiz88
fbshipit-source-id: 1ff558ba5350811ad042d08a713438e046759feb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43408
Changelog: [internal]
I think mount operations are taking longer than expected because of a debugging block (that we might remove). This adds some systrace sections to distinguish that from the overall time and confirm this only happens in debug builds.
Reviewed By: sammy-SC
Differential Revision: D54746491
fbshipit-source-id: 317b22b6dcd1ae117ed4a013180df8842bf712f0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43436
## Context
We are migrating to the new Hermes `CDPAgent` and `CDPDebugAPI` APIs in the modern CDP server (previously `HermesCDPHandler`).
## This diff
Expands test coverage for the Hermes `CDPAgent` implementation by enabling in `ReactInstanceIntegrationTest`.
Changelog: [Internal]
bypass-github-export-checks
Reviewed By: motiz88
Differential Revision: D54801168
fbshipit-source-id: 9b71f8e697c7ab24c1383100938b3f648774a106
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43429
changelog: [internal]
these experimental props have served their purpose and can be deleted.
Reviewed By: rubennorte
Differential Revision: D54682805
fbshipit-source-id: aee5072e2aa056c862f369426617d0d51c98997f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43422
After my changes in D54496604, this test now requires the main looper to progress as well, to dispatch the right callback.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D54776392
fbshipit-source-id: ba272a08d4b88d1c3301618eed1a03253e615b84
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43314
Changelog: [Internal]
making call invoker a breaking change to runtime executor in 0.74 seems to be causing a lot of discourse. let's simplify things and first add the callinvoker to the backwards compat layer
Reviewed By: cipolleschi
Differential Revision: D54404845
fbshipit-source-id: 983e86829030557033b95625dab9068492739417
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43410
Changelog:
[General] [Breaking] - Make `LongLivedObjectCollection::get` accept a Runtime reference as parameter.
# Context
Approach 1 as described in [RFC post](https://fb.workplace.com/groups/615693552291894/permalink/1693347124526526/).
# This diff
* Replace the `LongLivedObjectCollection` singleton with a map from `Runtime -> LongLivedObjectCollection` so that each RN instance has its own collection.
* Update MSFT fork accordingly
Reviewed By: javache, RSNara
Differential Revision: D54649209
fbshipit-source-id: ecd2ab3917843ca82388b7b9cce06c05679f2d60
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43420
Calling `mReactDelegate.createRootView` just ends up calling the overridden method in the anonymous inner class. Instead have the base implementation return null, and call super.
Changelog: [Internal]
Reviewed By: jessebwr, janeli-100005636499545
Differential Revision: D54772205
fbshipit-source-id: fc90e6718f9c287e8b86e5768cf7f74d0db06c49
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43391
## Context
We are migrating to the new Hermes `CDPAgent` and `CDPDebugAPI` APIs in the modern CDP server (previously `HermesCDPHandler`).
## This diff
Bootstraps `HermesRuntimeAgentDelegateNew` within `JsiIntegrationTest.cpp`.
Test cases which currently do not pass with `HermesRuntimeAgentDelegateNew` are selectively matched against a new alias to exclude them: `JsiIntegrationHermesLegacyTest`.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D53810357
fbshipit-source-id: 2d7d7446038530d19d93add71361b4bf581cff18
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43405
X-link: https://github.com/facebook/yoga/pull/1592
Fixes https://github.com/facebook/yoga/issues/1590
Yoga may be built with a high warning level. This is helpful in letting Yoga be used in more places, and finding defects. We currently set these in the internal BUCK build, the CMake reference build, and the Yoga Standalone (not RN) CocoaPods build.
Yoga's reference CMake build and spec are consumed today by users of Yoga, instead of just Yoga developers. Here, it makes more sense to avoid anything that could break compiler-to-compiler compatibility.
We default these to a less intense (`-Wall -Werror`). I kept `/W4`, for pragmatic reasons, and since it is relatively standard for MSVC.
We continue to build with strict flags on Buck build on Clang.
Reviewed By: cortinico
Differential Revision: D54735661
fbshipit-source-id: 130e35ac9dcffa2f7e70e48d18770f1275864e2a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43166
# Overview
This diff adds support for symbolicating component stacks that provide the new stack frame formatting. It currently switches between a `componentStackType` value to enable stack frame parsing, but once the feature flag lands we can clean this up so that the type of `ComponentStack` is always just `Array<StackFrame>`
## Screen
### With stack frame component stacks
{F1459181398}
## Legacy version
{F1463451637}
Changelog:
[General][Fixed] - Support component stacks without source info.
Reviewed By: yungsters
Differential Revision: D53984570
fbshipit-source-id: 68afbe70b65c7a8861d049bebe0659dbe1db146f
Summary:
## 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
-->
Changelog: [Internal] Generated changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/43412
Reviewed By: cortinico
Differential Revision: D54753626
Pulled By: huntie
fbshipit-source-id: c0a2348601b3d78b08ccaab570f346716d3793e6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43348
Changelog: [Internal]
Followup from D54585658. Moves the branching on `HERMES_DEBUGGER_ENABLED` into `HermesRuntimeTargetDelegate`, and correspondingly makes `FallbackRuntimeAgentDelegate` private (not exposed directly to integrators).
Reviewed By: huntie
Differential Revision: D54587558
fbshipit-source-id: 554b41356c1421a508c1a788d7c27f53445ecb6b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43338
Reafactor JavaTimerManager so more code is shared between bridge and bridgeless.
Note that HeadlessJSTaskContext is not currently configured when using bridgeless.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D54496604
fbshipit-source-id: 2a61294267df372e69f8316dd8f8059625d0a2bd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43346
Changelog: [Internal]
(Continuing the theme of reducing integration boilerplate from D54537844.)
This diff changes both `JSExecutor` (Bridge) and `JSRuntime` (Bridgeless) to no longer implement `RuntimeTargetDelegate`. Instead, each of them exposes a `getRuntimeTargetDelegate()` method that returns a stable reference to a target delegate that it *owns*.
To facilitate this, we create a new `FallbackRuntimeTargetDelegate` for use in non-Hermes cases. This replaces *almost* all direct uses of `FallbackRuntimeAgentDelegate` outside of `jsinspector`. I'll follow up in a separate diff to deal with the last case and make the fallback agent delegate fully private.
As a result, changing the `RuntimeTargetDelegate` interface (which we'll need to do for console support) becomes much easier: we only have unit test mocks + two concrete `RuntimeTargetDelegate` implementations (one fallback, one Hermes) to update for each API change.
Reviewed By: huntie
Differential Revision: D54585658
fbshipit-source-id: 08b61c74008ddc36c2b134a40755ef8e43ab21ed
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43390
Refactor after D54639775. This avoids the unfortunate side effect where `InspectorFlags::dangerouslyResetFlags()` would immediately reread `ReactNativeFeatureFlags `. This call is now relocated in our test util.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D54684692
fbshipit-source-id: 962c7d78bbf71b1d81af412081d3ef5cfe443fa1
Summary:
The inspector proxy is inlining source maps on `Debugger.scriptParsed` CDP events. The inlining prevents Chrome DevTools from downloading this remotely, as that's not supported in newer versions anymore.
The current implementation locks this inlining mechanism to just `localhost` and/or `127.0.0.1` addresses, making it incompatible with LAN or tunnel device connections.
This PR removes that limitation to allow source map inlining on these LAN and tunnel connections.
## 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] Allow Inspector proxy to inline source maps on LAN connections
Pull Request resolved: https://github.com/facebook/react-native/pull/43307
Test Plan:
- See added test
- Start Metro and connect a device over LAN, open the chrome devtools
Reviewed By: huntie
Differential Revision: D54485247
Pulled By: robhogan
fbshipit-source-id: 6fcb0c6dd762d2f0a013497ba0a1126095b9130b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43384
Changelog: [Internal]
via `js1 upgrade react-devtools -v ^5.0.2`
5.0.1 and 5.0.2 mostly include fixes, biggest change is the way how we find source location of the element and the symbolication.
Backend from `react-devtools-core` 5.0.2 is required for symbolication.
allow-large-files
Reviewed By: huntie
Differential Revision: D54679238
fbshipit-source-id: 13656b2d9bad106246c019e1627b87ffbc2735fe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43376
## Changelog:
[Internal] -
Make it possible to call `emitDeviceEvent` from C++ TurboModules without the need to explicitly provide the reference to `jsi::Runtime`, as in some contexts (when we call e.g. not from the JS thread itself) it may be hard to get hold of.
Reviewed By: rubennorte
Differential Revision: D54643903
fbshipit-source-id: 25cea413e66c6e76c958395879db1169899e3bc9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43375
## Changelog:
[Internal] -
As discussed with the team, it makes more sense to pass the reference to the correct `jsi::Runtime` object as an argument to the ` CallInvoker::invoke*` callbacks, that are provided by the user.
There are various use cases when user would like to get a hold of the `jsi::Runtime` in the callback, and it makes sense, since it is guaranteed to run on the JS thread.
So far people have been coming up with all kinds of workarounds for that, none of them safe enough.
Reviewed By: rubennorte
Differential Revision: D54643171
fbshipit-source-id: 2f6015426a9e29cb9fcf5a9a3e2f6f33ff692538
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43386
Changes:
- fixes `RCTAttributedTextUtils` to set `RCTAttributedStringIsHighlightedAttributeName` attribute according to `isHighlighted` textAttribute value.
- adds block to `drawAttributedString` and passed highlighted bezier curve to it.
- updates `drawRect` to visually highlight selected text.
## Changelog:
[iOS][Fixed] - Fixed text highlighting in the New Architecture
Reviewed By: sammy-SC
Differential Revision: D54594472
fbshipit-source-id: ed454e3a1660fa76d96cb131e33fba1c05f47776
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43378
## Overview
I noticed while running this test, that there's an existing `console.error` to remove a file from the `FILES_WITH_KNOWN_ERRORS` list, but the tests pass despite the error. This happens because the `console.error` throws to fail the test, but this `console.error` is inside a try/catch, so the error is swallowed.
This diff moves the check to a finally, which fails the test.
I also fixed the `FILES_WITH_KNOWN_ERRORS` list.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D54587062
fbshipit-source-id: c46e98326ef6654452871337364d7e66ff204e2c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43353
## Context
We are migrating to the new Hermes `CDPAgent` and `CDPDebugAPI` APIs in the modern CDP server (previously `HermesCDPHandler`).
## This diff
Integrates `HermesRuntimeAgentDelegateNew` (using the new Hermes `CDPAgent` setup) into `HermesRuntimeTargetDelegate` behind a new feature flag, `inspectorEnableHermesCDPAgent`. This completes the initial integration for all platforms.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D54586162
fbshipit-source-id: 5f26c28af4414d961b1c8c9cb4cd7135bd00b410
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43352
## Context
We are migrating to the new Hermes `CDPAgent` and `CDPDebugAPI` APIs in the modern CDP server (previously `HermesCDPHandler`).
## This diff
Adds the `HermesRuntimeAgentDelegateNew` class to provide a swap-in replacement for the existing `HermesRuntimeAgentDelegate` when we enable this via an incoming feature flag.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D53810356
fbshipit-source-id: c63684252230a747ecf0bd8cbb6f4e22052ed9bf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43367
Enable `ReactActivityDelegate` to be used outside of `ReactActivity` as well.
Changelog: [Internal]
Reviewed By: arushikesarwani94
Differential Revision: D54634339
fbshipit-source-id: 977e0da689d5a827feca89a5dcc9416ad5178334
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43374
changelog: [internal]
when animation that uses native driver finishes, it must synchronise the end state with shadow tree.
`onUpdateRef` for native animated is only called when the animation finishes.
Reviewed By: javache, yungsters
Differential Revision: D54582987
fbshipit-source-id: 4320ed172b8bb4b22f82c6e24b47f88f1603e4fb
Summary:
The `react_render_textlayoutmanager` was not exposed via prefab. I'm adding it to make possible for react-native-live-markdown to integrate on top of React Native via prefab. Based on https://github.com/facebook/react-native/issues/36166.
## 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] [CHANGED] - Expose `react_render_textlayoutmanager` via prefab.
Pull Request resolved: https://github.com/facebook/react-native/pull/43381
Reviewed By: javache
Differential Revision: D54676207
Pulled By: cortinico
fbshipit-source-id: 90e3b90ff842250bf1e3abcc0c54f057b68a82fd
Summary:
`registerCallableModule()` was added from 7f549ec7be but no typescript types there. this pr tries to add the corresponding types.
## Changelog:
[GENERAL] [FIXED] - Add missing `registerCallableModule` TypeScript definitions
Pull Request resolved: https://github.com/facebook/react-native/pull/43366
Test Plan: patch locally and try to `import { registerCallableModule } from 'react-native';` in a 0.74.0-rc.2 project
Reviewed By: fabriziocucci
Differential Revision: D54676151
Pulled By: cortinico
fbshipit-source-id: cd01f2ebe2d2516b458fae5b2e83cba3d3794455
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43377
Fixes `VirtualizedList-test.js`, which assumes fake timers (e.g. using `jest.runAllTimers()` and `jest.runOnlyPendingTimers()`) but did not actually use fake timers.
Changelog:
[Internal]
Reviewed By: yungsters
Differential Revision: D54668281
fbshipit-source-id: b14757744bb7a21a4e5573053549c36178826021
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43371
This file has a lot of regexes, let's organize and comment them all.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D54638520
fbshipit-source-id: eed61133758ccefd2a640f121c4da214bcad4880
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43370
Component stacks with files ending in .ts, .tsx, or .jsx were skipped in LogBox reporting. This diff fixes the regex.
Changelog:
[General][Fixed] - Support .tsx, .ts, and .jsx in component stacks
Reviewed By: yungsters
Differential Revision: D54638526
fbshipit-source-id: a5271daaa7b687e8e075be3f94ab9b9c03f79b66
Summary:
Currently, the ability to convert JS values to `UIModalPresentationStyle` is not present directly on `RCTConvert`.
In the RN code base itself, there's not a lot of need to do this type of conversion, but in community modules, presenting ViewControllers can be a fairly common scenario and it'd be nice to be able to use this conversion directly from `RCTConvert`, rather than from `RCTModalHostViewManager`, as it'd improve its "discoverability" and consistency.
If someone relied on this, then it's technically speaking a breaking change but I'd say it's for the better, and searching `#import <React/RCTModalHostViewManager.h>` on github doesn't reveal a lot of results.
## Changelog:
[IOS] [ADDED] - RCTConvert to support UIModalPresentationStyle
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/43297
Test Plan:
Tested using RN Tester
https://github.com/facebook/react-native/assets/1566403/6e62df86-dde3-47b0-b2e9-bb6b483cadf6
Reviewed By: fkgozali
Differential Revision: D54635896
Pulled By: dmytrorykun
fbshipit-source-id: c6747857830762cd0333c31c287954f3f10d4954
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43368
This diff replaces direct invocation of the `cp` command with the platform agnostic `fs.cpSync`.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D54634108
fbshipit-source-id: 41fe7b44b6534026ef1b930da85725bf3eb1e7bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43356
To make it accessible across different dylib/bundle.
Changelog: [Internal]
Reviewed By: d16r
Differential Revision: D54601288
fbshipit-source-id: e65b724b228a680784e81b8c51ecd3f4df3fd668
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43349
Changelog: [internal]
We still haven't found the root cause of some of the crashes we're seeing in the experiments to enable mount hooks on Android.
This adds a new feature flag to skip part of the mount hooks pipeline to see if we can scope the investigation to that specific part (where we query the root tree in the base revision from the mounting coordinator).
Reviewed By: sammy-SC
Differential Revision: D54587739
fbshipit-source-id: 792aa8b06808e96638d1bba072bf4060ec492bd2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43350
Changelog: [internal]
Mount hooks have been shipped on iOS, so this removes the flag for them.
On Android, we're still testing them so it's worth moving them to the new system and scoping them to that platform.
Reviewed By: sammy-SC
Differential Revision: D54587740
fbshipit-source-id: d074927fee1a967bd3928970c31975d07cd393bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43337
Changelog: [internal]
Mount instructions and listeners are only called from the UI thread, so there's no need to have synchronization mechanisms for concurrency.
We're also scheduling mount hooks notifications once, but subsequent calls are ignored instead of accumulated to be notified together. This also changes that to collect all the surface IDs in the array that is read on notification.
Reviewed By: sammy-SC
Differential Revision: D54547194
fbshipit-source-id: a861e3b0113914aae5325c1486bcf8acd50eef79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43340
Adds convenience methods `jsonResult`, `jsonError` and `jsonNotification` for more ergonomic construction of CDP JSON responses. Note that CDP is *loosely* based on [JSON-RPC 2.0](https://www.jsonrpc.org/specification), but differs for example in the omission of `"jsonrpc": "2.0"`.
Before:
```
frontendChannel_(folly::toJson(folly::dynamic::object("id", req.id)(
"error",
folly::dynamic::object("code", -32602)(
"message",
"executionContextName is mutually exclusive with executionContextId"))));
```
After:
```
frontendChannel_(cdp::jsonError(
req.id,
cdp::ErrorCode::InvalidParams,
"executionContextName is mutually exclusive with executionContextId"));
```
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D54202854
fbshipit-source-id: 76a407ae39ff9c2ec79bcaddb6cd4d494afb7693
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43281
## Overview
This diff fixes a bug in the hermes component stack location parser, and fixes the hermes component stack tests which were not using hermes stack parsing, which is why the bug wasn't caught.
The bug fix is that React component stacks may not all have stack frame locations. For example, this stack:
```
at MyComponent (/path/to/filename.js:1:2)
at MyOtherComponent <-- no location
at MyAppComponent (/path/to/app.js:100:20)
```
This can happen when we're unable to make a component throw (e.g. it doesn't use a hook or access props). We have plans to fix these frames, but currently they can exist.
The bug was when `parseHermesStack` finds a frame without an `entry`, it would reset the `entries`. But if entries is already non-null, or if the current frame is a frame without a source, we should continue.
### Caveats
The handling here fixes the behavior to go back to skipping these frames. I'm not sure what the best way to handle these cases are, since these frames do not have source location and should skip symbolication. We should follow up with handling for these frames.
## Why it wasn't caught
In D18627930 we changed the hermes component stack parsing to check `global.HermesInternal`, but the tests for the hermes component stacks were still using the `stacktrace-parser`. I updated the tests to set/reset the global, which caught the bug.
Changelog:
[General][Fixed] - Support hermes component stacks with missing source info.
Reviewed By: yungsters
Differential Revision: D54423252
fbshipit-source-id: 80ded8b99eab919e60f847369dcb1f3afa72b6be
Summary:
This PR further optimizes RCTKeyWindow() for iOS 15+ removing the need for additional loop
bypass-github-export-checks
## Changelog:
[IOS] [ADDED] - optimize RCTKeyWindow() for iOS 15+
Pull Request resolved: https://github.com/facebook/react-native/pull/43066
Test Plan: Launch RNTester, check if proper keyWindow is returned for iOS 15+
Reviewed By: javache
Differential Revision: D54541838
Pulled By: cipolleschi
fbshipit-source-id: be79ff48f825d10c8fd71efc18629377aadc29fd
Summary:
This PR fixes importing RCTAppDelegate, cleans up the imports, and properly sets the background color for bridgeless mode when using `RCTRootViewFactory`.
The issue with importing to Swift was that `RCTTurboModuleManager` has C++ in headers which caused Swift to error out.
bypass-github-export-checks
## Changelog:
[IOS] [FIXED] - Allow importing RCTAppDelegate in Swift
[INTERNAL] [REMOVED] - Remove unnecessary imports in AppDelegate
[INTERNAL] [FIXED] - Properly set background color for bridgeless
Pull Request resolved: https://github.com/facebook/react-native/pull/43339
Test Plan:
- CI Green
- Check if background color is correct
Reviewed By: dmytrorykun
Differential Revision: D54584489
Pulled By: cipolleschi
fbshipit-source-id: cb4b947ca9d0f375b1852dbf5a7d889e920562f7
Summary:
The `rrc_text` was not exposed via prefab. I'm adding it to make possible for react-native-live-markdown to integrate on top of React Native via prefab. Based on https://github.com/facebook/react-native/issues/36166.
## 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] [CHANGED] - Expose `rrc_text` via prefab.
Pull Request resolved: https://github.com/facebook/react-native/pull/43275
Reviewed By: cipolleschi
Differential Revision: D54536468
Pulled By: cortinico
fbshipit-source-id: 8c4ef983467bfc46930f10bf7bd95761c2d11788
Summary:
We should not be publishing the `__tests__` folder to the npm package.
Fixes https://github.com/facebook/react-native/issues/43242
## Changelog:
[INTERNAL] [CHANGED] - Do not publish src/**/__tests__ for react-native
Pull Request resolved: https://github.com/facebook/react-native/pull/43261
Test Plan: Nothing to test
Reviewed By: cipolleschi
Differential Revision: D54540896
Pulled By: cortinico
fbshipit-source-id: 10b557a911b9b17d64c4697724825248a597feae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43334
cortinico flagged that bridge + fabric regressed in 0.74, likely due to D53406841.
Changelog: [Android][Fixed] Fix registration of ViewManagers in new renderer when not using lazyViewManagers.
Reviewed By: fkgozali
Differential Revision: D54551645
fbshipit-source-id: 0783030cd0d2900a3a254ae04c9ea4e51035272a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43328
These have been deprecated since 2019 (D18742620), probably time we remove them.
Changelog: [General][Removed] Removed deprecated methods from Pressability.
Reviewed By: NickGerleman
Differential Revision: D54535029
fbshipit-source-id: 45f85fb002824c94363c839fee2f831c01ad4dbd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43332
Changelog: [Internal]
The Hermes debugger integrations in Bridge/Bridgeless have so far used `MessageQueueThread` directly to schedule work on the JS thread, instead of the Instance-managed executor.
This was always a smell, but is now actively unsafe since the modern CDP backend requires `JSExecutor` / `JSRuntime` to remain alive while work is ongoing on the JS thread. This is not guaranteed when using `MessageQueueThread` directly like we do now, but *is* guaranteed by the Instance-managed `RuntimeExecutor` (see reasoning in D54493456).
We already have access to that executor in `RuntimeTarget`, so here we ensure that it's the one used by the AgentDelegate too and eliminate the direct use of `MessageQueueThread`.
NOTE: It would have been, perhaps, nice to just house the executor inside `JSExecutor` / `JSRuntime` to begin with, instead of adding a parameter to `createAgentDelegate()`. This would require some broader refactoring which I'm choosing to avoid for now.
Reviewed By: huntie
Differential Revision: D54539429
fbshipit-source-id: 6a5ad1c56642d809f6193b230301fa268318bbce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43326
Changelog: [Internal]
Extracts the common parts of `HermesJSRuntime` (Bridgeless) and `HermesExecutor` (Bridge) that pertain to integration with the modern CDP backend into a new `HermesRuntimeTargetDelegate` class. This also makes the `HermesRuntimeAgentDelegate` class fully private.
As a followup, we *might* want to change `JSRuntime` and `JSExecutor` so they don't *implement* `RuntimeTargetDelegate` but are required to expose a `RuntimeTargetDelegate& getRuntimeTargetDelegate()` method instead. That would remove some of the boilerplate required for our current "aggregation" approach.
Reviewed By: huntie
Differential Revision: D54537844
fbshipit-source-id: f8c51fda0dbf28add1daeb95c991a34670f6854f
Summary:
Changelog: [Internal]
Use a gtest assertion to avoid running into an exception (which has worse diagnostics) when dereferencing an `optional` value that's expected to be non-empty.
bypass-github-export-checks
Reviewed By: huntie
Differential Revision: D54578843
fbshipit-source-id: e0269542f80045f02876bda06cb584b6c68e50cd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43329
Improve maintainability of this file, in particular reducing the probability of a merge conflict for new entries.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D54539469
fbshipit-source-id: dc2fca42b4490d87c532b21043b0855d8d1a894d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43195
Right now, the activity indicator is automatically hidden when the view is ready to be shown in bridgeless mode.
There is no way to prevent that the activity indicator is automatically removed.
In OSS, we have libraries (e.g.: `react-native-bootsplash`) that will allow the app to control when and how dismiss the splashscreen, but due to the current automatic behavior on Bridgeless, they stopped working.
***Note:** In the previous implementation, they were working because instead of using the `loadingView` property, they were adding the splashscreen view on top of the existing one. However, with the lazy behavior of the bridgeless mode, this is not working anymore because the RCTMountingManager [expect not to have any subview](https://www.internalfb.com/code/fbsource/[6962fa457dbc74ab3a760cf6090d9643c6748781]/xplat/js/react-native-github/packages/react-native/React/Fabric/Mounting/RCTMountingManager.mm?lines=176) when the first surface is mounted.*
## Changelog
[iOS][Added] - Allow the activityIndicator to be controlled from JS in bridgeless mode
Reviewed By: philIip
Differential Revision: D54191856
fbshipit-source-id: 14738032f04adf7eaf7d200d889acd752aed0ed3
Summary:
Commit https://github.com/facebook/react-native/commit/73664f576aaa472d5c8fb2a02e0ddd017bbb2ea4 broke two jobs in CircleCI that we run using Xcode 14.3.1 because the commit introduced some types that are available only to iOS 17.
The code was wrapped around if(available()) statement, but this does not compile out the code. It is a runtime check and the code needs to build anyway.
This takes effect at compile time as well. However, unlike with #available, the method must type check and compile. The code will always be emitted into your binary: however, it will only be used when the binary is executed on platforms that meet the availability requirements.
source: [forums.swift.org/t/if-vs-available-vs-if-available/40266/2](https://forums.swift.org/t/if-vs-available-vs-if-available/40266/2)
This change should fix it, introducing some compile time pragmas that removes the code if we build with older versions of Xcode
## Changelog:
[IOS] [ADDED] - Compiler conditionals for hover style (cursor: pointer)
Pull Request resolved: https://github.com/facebook/react-native/pull/43331
Test Plan: CI Green
Reviewed By: dmytrorykun
Differential Revision: D54540520
Pulled By: cipolleschi
fbshipit-source-id: 943ac479062e11969efa7645ec0ead26c6866374
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43327
<!-- Thanks for submitting a pull request! We appreciate you spending the time to work on these changes. Please provide enough information so that others can review your pull request. The three fields below are mandatory. -->
## Summary
Swift Pods require the use of [modular headers](https://blog.cocoapods.org/CocoaPods-1.5.0/) to be statically linked. To interop with Objective-C modules, you need to make the Objective-C module "define a Module", that is modular header export.
This is already the case for a few podspecs so they can be consumed in Swift libraries, but `ReactCommon` and `RCT-Folly` don't do this yet and therefore this breaks in a few libraries of mine, for example see this issue: https://github.com/mrousavy/react-native-vision-camera/issues/195.
If I were to include `ReactCommon` or `RCT-Folly` in my Swift library's podspec, the following error arises:
```
[!] The following Swift pods cannot yet be integrated as static libraries:
The Swift pod `VisionCamera` depends upon `RCT-Folly`, which does not define modules.
To opt into those targets generating module maps (which is necessary to import them from Swift
when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or
specify `:modular_headers => true` for particular dependencies.
```
So this PR fixes this issue by allowing Swift libraries to consume the `ReactCommon` and `RCT-Folly` podspecs since they now export modular headers.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General] [Fixed] - Expose Modular Headers for `ReactCommon` podspec
[General] [Fixed] - Expose Modular Headers for `RCT-Folly` podspec
Pull Request resolved: https://github.com/facebook/react-native/pull/31858
Test Plan: * Add s.dependency "ReactCommon" or RCT-Folly to a Swift pod and see what happens. (See https://github.com/mrousavy/react-native-vision-camera/pull/273)
Reviewed By: dmytrorykun
Differential Revision: D54539127
Pulled By: cipolleschi
fbshipit-source-id: 2291cc0c8d6675521b220b02ef0c3c6a3e73be38
Summary:
Bump the version to match RN.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D54538812
fbshipit-source-id: a2e8225ea02fb1e7a69b3b20436c821a857ca1e2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43323
This fixes a seemingly pre-existent misconfiguration within our `test_ios_template` E2E test setup in CircleCI.
**Background**
We call `npx react-native-community/cli init` with the `--skip-install` flag, as part of the bootstrapping logic in `scripts/e2e/init-template-e2e.js`. This is necessary because we later want to explicitly call `npm install` with a custom `--registry` for our locally mirrored packages (via Verdaccio).
For some reason, we were observing unexpected differences when this was run under CircleCI:
1. Runs `yarn init`
2. Runs a `yarn add` (unknown pkg)
{F1464781818}
https://app.circleci.com/pipelines/github/facebook/react-native/42725/workflows/f648468b-e916-4501-887d-ad293aa6fccf/jobs/1398950
This is causing a Yarn-based install ahead of where we want — ignoring the `--skip-install` flag.
*I'm still unsure on the exact LOC cause in CLI* (but most likely, it's around the Yarn v3 move).
**Impact of this fix**
- The above meant that, when we were bootstrapping `test_ios_template` previously, packages weren't being read from Verdaccio, but **instead from npm** — using the `"0.74.0"` versions from the *previous branch cut* ❌.
- After D54006327, this behaviour became breaking 💀 — since for the 0.74 -> 0.75 cut, we no longer physically published `"0.75.0-main"` (new format) packages to npm.
**This change**
I'm passing `--pm npm` to `npx react-native-community/cli init` to skip around any Yarn behaviour. This appears to have removed the erroneous `yarn` invocations ✅.
Changelog: [Internal]
bypass-github-export-checks
Reviewed By: cortinico, cipolleschi
Differential Revision: D54536848
fbshipit-source-id: 473b11924955f5787c82a6c81d4527d77b810aa5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43309
Changelog: [internal]
X-link: https://github.com/facebook/hermes/pull/1336
Add JSI test verifying the behavior of `queueMicrotask` and `drainMicrotasks` in the runtimes that support them.
Reviewed By: neildhar
Differential Revision: D54484771
fbshipit-source-id: e8c0c8e05215d59a0a8c86161452642c41bcdbd7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43311
X-link: https://github.com/facebook/hermes/pull/1337
Changelog: [internal]
We've done this in a separate diff because the changes in Hermes don't propagate immediately to the React Native repository. We need to land the changes in JSI and Hermes first (in a backwards-compatible way) and then land this in a separate commit to make the method mandatory.
Reviewed By: neildhar
Differential Revision: D54413830
fbshipit-source-id: 3b89fe0e6697b0019544b73daa89d932db97b63a
Summary:
This adds the `nativeNetworkInspection` target capability flag, to enable/disable the proxy-side network inspection handling.
## 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][ADDED] Add inspector proxy `nativeNetworkInspection` target capability flag
Pull Request resolved: https://github.com/facebook/react-native/pull/43310
Test Plan:
Once this lands, and is published through `react-native/dev-middleware`, we (Expo) can disable the proxy-side network inspection handling.
See https://github.com/expo/expo/pull/27425/commits/1a1b601a29fbc5766628238db7259121689f6cd6 on PR expo/expo#27425
Reviewed By: christophpurrer, motiz88
Differential Revision: D54486516
Pulled By: huntie
fbshipit-source-id: cc151349c816fb3866d3ec07af1a29a5f4ff9b00
Summary:
This adds support for 64 bit integer (long) values to the Android bridge. Per the wide gamut color [RFC](https://github.com/react-native-community/discussions-and-proposals/pull/738) Android encodes wide gamut colors as long values so we need to update the bridge to support 64 bit integers as well since these classes will soon receive those values from native.
## Changelog:
[ANDROID] [ADDED] - Update bridge to handle long values
Pull Request resolved: https://github.com/facebook/react-native/pull/43158
Test Plan: I added tests where I could for long types and truncation. I would like to add tests for ReadableNativeArray and ReadableNativeMap but I'm not sure how to go about mocking HybridData.
Reviewed By: cipolleschi
Differential Revision: D54276496
Pulled By: NickGerleman
fbshipit-source-id: 1e71b5283f662748beef1bdb34d9c86099baecb0
Summary:
This PR implements `RCTRootViewFactory` a utility class (suggested by cipolleschi) that returns proper RCTRootView based on the current environment state (new arch/old arch/bridgeless). This class aims to preserve background compatibility by implementing a configuration class forwarding necessary class to RCTAppDelegate.
### Brownfield use case
This PR leverages the `RCTRootViewFactory` in `RCTAppDelegate` for the default initialization of React Native (greenfield).
Here is an example of creating a Brownfield integration (without RCTAppDelegate) using this class (can be later added to docs):
1. Store reference to `rootViewFactory` and to `UIWindow`
`AppDelegate.h`:
```objc
interface AppDelegate : UIResponder <UIApplicationDelegate>
property(nonatomic, strong) UIWindow* window;
property(nonatomic, strong) RCTRootViewFactory* rootViewFactory;
end
```
2. Create an initial configuration using `RCTRootViewFactoryConfiguration` and initialize `RCTRootViewFactory` using it. Then you can use the factory to create a new `RCTRootView` without worrying about old arch/new arch/bridgeless.
`AppDelegate.mm`
```objc
implementation AppDelegate
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary<UIApplicationLaunchOptionsKey,id> *)launchOptions {
// Create configuration
RCTRootViewFactoryConfiguration *configuration = [[RCTRootViewFactoryConfiguration alloc] initWithBundleURL:self.bundleURL
newArchEnabled:self.fabricEnabled
turboModuleEnabled:self.turboModuleEnabled
bridgelessEnabled:self.bridgelessEnabled];
// Initialize RCTRootViewFactory
self.rootViewFactory = [[RCTRootViewFactory alloc] initWithConfiguration:configuration];
// Create main root view
UIView *rootView = [self.rootViewFactory viewWithModuleName:@"RNTesterApp" initialProperties:@{} launchOptions:launchOptions];
// Set main window as you prefer for your Brownfield integration.
self.window = [[UIWindow alloc] initWithFrame:[UIScreen mainScreen].bounds];
UIViewController *rootViewController = [UIViewController new];
rootViewController.view = rootView;
self.window.rootViewController = rootViewController;
[self.window makeKeyAndVisible];
// Later in the codebase you can initialize more rootView's using rootViewFactory.
return YES;
}
end
```
bypass-github-export-checks
## Changelog:
[INTERNAL] [ADDED] - Implement RCTRootViewFactory
Pull Request resolved: https://github.com/facebook/react-native/pull/42263
Test Plan: Check if root view is properly created on app initialization
Reviewed By: dmytrorykun
Differential Revision: D53179625
Pulled By: cipolleschi
fbshipit-source-id: 9bc850965ba30d84ad3e67d91dd888f0547c2136
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43305
changelog: [internal]
Originally when I built setNativeProps, I assumed a node is either controlled by handled directly or it is controlled by React. But we can't make sure that's the case, users can do both and control one prop with setNativeProps and the others with React. Additionally, Suspense uses display: none to hide a subtree.
Therefore, React controlled props must not be copied into `ShadowNodeFamily::nativeProps_DEPRECATED`
Reviewed By: javache
Differential Revision: D54453820
fbshipit-source-id: 5b4038f0dd366621d26a92f668d33f27ce60f4b4
Summary:
Changelog: [internal]
Now that `jsi::Runtime::queueMicrotask` is available, we can use it instead of calling an internal Hermes API in `RuntimeSchedulerTest`.
Reviewed By: christophpurrer
Differential Revision: D54416245
fbshipit-source-id: c9cbd3783d9dc1c3df499a7fec7acb6c229ec571
Summary:
Changelog: [internal]
## Context
We want to enable the new React Native event loop by default for all users on the new RN architecture (on the bridgeless initialization path more concretely), which requires support for microtasks in all the JS engines that the support (Hermes already has it, JSC doesn't).
## Changes
This adds initial support for microtasks in JSC, so we can schedule and execute microtasks in this runtime.
One limitation about this approach is that, AFAIK, the public API for JSC doesn't allow us to customize its internal microtask queue or specify the method to be used by its built-in `Promise` or native `async function`, so we're forced to continue using a polyfill in that case (which uses `setImmediate` that will be mapped to `queueMicrotask`).
Reviewed By: NickGerleman
Differential Revision: D54302534
fbshipit-source-id: 47f71620344a81bc6624917f77452106ffbf55a3
Summary:
Changelog: [internal]
## Context
Microtasks are an important aspect of JavaScript and they will become increasingly important in the hosts where we're currently using JSI.
For example, React Native is going to adopt an event loop processing model similar to the one on the Web, which means it would need the ability to schedule and execute microtasks in every iteration of the loop. See https://github.com/react-native-community/discussions-and-proposals/pull/744 for details.
JSI already has a method to execute all pending microtasks (`drainMicrotasks`) but without a method to schedule microtasks this is incomplete.
We're currently testing microtasks with Hermes using an internal method to schedule microtasks (`HermesInternal.enqueueJob`) but we need a method in JSI so this also works in other runtimes like JSC and V8.
## Changes
This adds the `queueMicrotask` to the Runtime API in JSI so we have symmetric API for microtasks and we can implement the necessary functionality.
The expectation for JSI implementations is to queue microtasks from this method and from built-ins like Promises and async functions in the same queue, and not drain that queue until explicitly done via `drainMicrotasks` in JSI.
This also modifies Hermes and JSC to provide stubs for those methods, and the actual implementation will be done in following diffs.
Reviewed By: neildhar
Differential Revision: D54302536
fbshipit-source-id: 25f52f91d7ef1a51687c431d2c7562c373dc72a5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43287
Move react-native-community/cli clean into core per RFC-0759. Provides:
- android
- metro
- npm
- bun
- watchman
- yarn
- cocoapods
These tasks are used to clear up caching artefacts in React Native projects. This is going to be called by the `react-native-community/cli` once we publish these in an npm package.
Changelog:
[General][Added] RFC-0759 Move cli clean into core
Reviewed By: cipolleschi
Differential Revision: D53997878
fbshipit-source-id: 56907be714184abecc8e3ef677ffc83e9ee7b54d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43293
Was debugging this, and found that this exception was being thrown due to `DefaultBindingsInstaller`, which was an invalid hybrid object. The ReactInstance initializer fully supports this being null, so let's use that as default.
Changelog: [Android][Fixed] NullPointerException is no longer ignored in MessageQueueThreadHandler
Reviewed By: sammy-SC
Differential Revision: D54434417
fbshipit-source-id: 52417b390061eface0f0578e32796d3a85303e03
Summary:
The `rrc_textinput` was not exposed via prefab. I'm adding it to make possible for react-native-live-markdown to integrate on top of React Native via prefab. Based on https://github.com/facebook/react-native/issues/36166.
## 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] [CHANGED] - Expose `rrc_textinput` via prefab.
Pull Request resolved: https://github.com/facebook/react-native/pull/43274
Reviewed By: cipolleschi
Differential Revision: D54482657
Pulled By: cortinico
fbshipit-source-id: ca7f4127f1808f841d88925238666e837de75bd0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43268
We previously restricted all copies and moves of SyncCallback, but that led to unsafe calling paths being added instead to AsyncCallback. Instead, allowing moving of SyncCallback, and document the need for the caller to invoke it safely, so can we remove the unsafe path from AsyncCallback.
Changelog: [General][Changed] Allow moving SyncCallback for advanced use-cases
Reviewed By: christophpurrer
Differential Revision: D54381734
fbshipit-source-id: 5fd797cd4541e507aa68f1e4e76a1be5cae20fbe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43294
These are gated by `ReactFeatureFlags.enableBridgelessArchitecture` and are missing support. They should be evaluated for backwards compatibility
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D54422143
fbshipit-source-id: b35b60f17d68d412a354b20e02fb6bbf591c40b0
Summary:
Addresses a gap when using the `set-version` script to update all packages on `main` (i.e. post branch cut):
- Package versions were not being set consistently. It is safe to version all workspace packages, including `"private"`.
- Our publishing workflow is independent from this, and only considers public packages for submission to npm.
- We also need to update the root `package.json`, which includes `devDependencies` referencing workspace dependencies.
Unblocks https://github.com/facebook/react-native/pull/43132.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D54419456
fbshipit-source-id: 93eee669c5cf7c2f16b68a2bf41e9a8ace5521bf
Summary:
Make the snapshot output of this test terser (since `set-version` is a superset of the fully tested `set-rn-version` script). Notably, this removes any instances of `generated` from the snapshot file, which would hide the diff in PRs.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D54420338
fbshipit-source-id: e4a94b1fda34efaedf1b309496954be35acd5f98
Summary:
X-link: https://github.com/facebook/litho/pull/976
X-link: https://github.com/facebook/yoga/pull/1586
Pull Request resolved: https://github.com/facebook/react-native/pull/43299
Add the React Clang Tidy config to Yoga, run the auto fixes, and make some manual mechanical tweaks.
Notably, the automatic changes to the infra for generating a Yoga tree from JSON capture make it 70% faster.
Before:
{F1463947076}
After:
{F1463946802}
This also cleans up all the no-op shallow const parameters in headers.
{F1463943386}
Not all checks are available in all environments, but that is okay, as Clang Tidy will gracefully skip them.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D54461054
fbshipit-source-id: dbd2d9ce51afd3174d1f2c6d439fa7d08baff46f
Summary:
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D54027179
fbshipit-source-id: 4840becb8374ddbf8091be1e5e593289d18c78e0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43296
Fix CI by adding explicit visibility modifier to the newly added `BridgelessCatalystInstance` class. In Kotlin, in explicit API mode, which is usually the default mode for Kotlin, we must explicitly specify one of the modifiers for every declaration to make it clear and explicit.
Changelog:
[Internal] internal
Reviewed By: makovkastar
Differential Revision: D54442485
fbshipit-source-id: 4409ff810a09cc4fadcd2ccf21f7fbac3015f413
Summary:
Inspired by some new C++ code in `RKJSModules` where Clang Tidy could have caught some C++ quirks and shown them in Phabricator, this enables Fabric's Clang Tidy checks in more places, and enables more checks.
1. Hoist the renderer `.clang-tidy` to `xplat/js`, and duplicate to `xplat/ReactNative`
2. Remove all the scattered `.clang-tidy` files in RN which are less aggressive
3. Sort the list of checks
4. Add the following new checks:
1. `bugprone-incorrect-enable-if`
1. `bugprone-infinite-loop`
1. `bugprone-optional-value-conversion`
1. `bugprone-redundant-branch-condition`
1. `bugprone-shared-ptr-array-mismatch`
1. `bugprone-signed-char-misuse`
1. `bugprone-too-small-loop-variable`
1. `bugprone-unique-ptr-array-mismatch`
1. `bugprone-unsafe-functions`
1. `bugprone-unused-raii`
1. `cppcoreguidelines-avoid-const-or-ref-data-members`
1. `cppcoreguidelines-avoid-non-const-global-variables`
1. `cppcoreguidelines-init-variables`
1. `cppcoreguidelines-interfaces-global-init`
1. `cppcoreguidelines-missing-std-forward`
1. `cppcoreguidelines-prefer-member-initializer`
1. `facebook-hte-BadEnum`
1. `facebook-hte-MissingStatic`
1. `misc-header-include-cycle`
1. `misc-misplaced-const`
1. `modernize-use-constraints`
1. `modernize-use-designated-initializers`
1. `modernize-use-starts-ends-with`
I did not auto apply fixes, since even the existing set can sometimes (rarely) generate invalid code.
Changelog: [Internal]
Reviewed By: ksheedlo
Differential Revision: D54411398
fbshipit-source-id: 4958d880969ae07a03fa4f62ba68ee44790487ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43165
Fixes component stacks without source info, and duplication in the error message string.
## Before
No component stacks, and error message duplication:
{F1459400803}
## After
Back to normal, albeit without the component source location:
{F1459401148}
Changelog:
[General][Fixed] - Support component stacks without source info.
Reviewed By: yungsters
Differential Revision: D53981672
fbshipit-source-id: c83455673ce327ed1a4c6cfeb3247e97da9b6a2e
Summary:
Small tweak to #43069 - trim the message to avoid ending with a newline.
Changelog:
[General][Changed] - Trim invalid blob response error message
Reviewed By: christophpurrer
Differential Revision: D54422284
fbshipit-source-id: 53a4e963f8aba36c55e16ad7539b2f2d98c781f8
Summary:
When used with expo, JS code content type is `application/javascript; charset=UTF-8` instead of just `application/javascript`, We have a really large bundle and the application shows stuck at "Bundling 100%" and does not show "Downloading 1..100%".
Here we improve the check for the content type to correctly show the progress.
## Changelog:
[IOS] [FIXED] - Fixed headers content type check for iOS bundle download
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/43262
Reviewed By: huntie
Differential Revision: D54412657
Pulled By: robhogan
fbshipit-source-id: f12e260f1bda36495eb5e6ecd0f66c86f26d4747
Summary:
The RemoveDeleteTree operation assumes it can safely call getChildAt with indices that are out of bounds to find all the children. `getChildAtWithSubviewClippingEnabled` was unnecessarily stricter than `getChildAt` and would crash in such cases.
Changelog: [Android][Fixed] - Fix crash in `getChildAtWithSubviewClippingEnabled`
Reviewed By: NickGerleman
Differential Revision: D54380975
fbshipit-source-id: 17e93c685cd07b02dc20efa2fae89090d6e38457
Summary:
The `scrollEventThrottle` prop is missing in the ViewConfig for ScrollView for the Android platform. Because of that it was ignored by native in the New Architecture.
This diff fixes that.
Changelog: [Android][Fixed] - Add support for scrollEventThrottle for ScrollView on the New Architecture.
Reviewed By: fkgozali
Differential Revision: D54303157
fbshipit-source-id: 824f32c2f9fb3958271b094bbfc770992a4335e1
Summary:
Changelog: [General][Fixed] Re-enable listing Hermes debugger targets in chrome://inspect, broken in 0.74 RC
Fixes https://github.com/facebook/react-native/issues/43259.
Reverts D52958725 and fixes the original `Content-Length` Unicode bug using a different approach.
Reviewed By: fabriziocucci
Differential Revision: D54409847
fbshipit-source-id: ed5bb464ab67f37535947646b124814d8bbf797c
Summary:
In order to make the legacy APIs of Catalyst Instance backwards compatible, introducing a regular class that implements CatalystInstance so as to make these APIs available for folks in Bridgeless mode as well.
Changelog:
[Internal] internal
Reviewed By: RSNara
Differential Revision: D54093013
fbshipit-source-id: f494c05e79f570883f9b5374cd177862970304c0
Summary:
Changelog: [General][Breaking] Native modules using the codegen now throw an error when called with `null` for optional but not nullable arguments.
## Context
Right now, if you have a native module using the codegen with a method like this:
```
someMethod(value?: number): void;
```
And you call it like this:
```
NativeModule.someMethod(null);
```
The app doesn't throw an error, but it should because this method shouldn't accept `null` according to its type definition.
## Changes
This modifies the codegen to only check for `undefined` in those cases, otherwise trying to cast the value to the expected type and failing if it's `null`.
NOTE: this is technically a breaking change, but if people are using Flow or TypeScript in their projects they're very unlikely to hit this case, because they would've complained if you tried to pass `null` in these cases.
Reviewed By: cipolleschi
Differential Revision: D54206289
fbshipit-source-id: 58f2f2f3009d203b96189d3c66d1ae98a9e4fb36
Summary:
Changelog: [internal]
This modifies the method to run microtasks in `RuntimeScheduler_Modern` to align a bit better with the spec. In this case, we'll check if we're already running microtasks when we call that method, and skip if that's the case.
We're not currently calling this method recursively so this shouldn't really be a change with the current logic.
Reviewed By: javache
Differential Revision: D54302537
fbshipit-source-id: ef5e12e68e0c7f8c9258929609c050ef78e4cde5
Summary:
After discussing with mdvacca, we prefer to undo the change of `TurboModule` package to `.internal` as this is a quite aggressive breaking change for the ecosystem.
Moreover: users should not invoke `TurboModule.class.isAssignableFrom` because `TurboModule` is `.internal`. Therefore I'm exposing another API to check if a class is a TurboModule as a static field of `ReactModuleInfo`.
## Changelog:
[INTERNAL] - Do not use TurboModule.class.isAssignableFrom
Pull Request resolved: https://github.com/facebook/react-native/pull/43219
Test Plan: Tests are attached
Reviewed By: mdvacca, cipolleschi
Differential Revision: D54280882
Pulled By: cortinico
fbshipit-source-id: 9443c8aa23cf70dd5cfe574fe573d83313134358
Summary:
Changelog: [internal]
This fixes a crashes during logout on Android and iOS caused by trying to unregister the inspector from instances that were not previously registered. This is because I removed a check in D51459050 that was necessary when the inspector was disabled via the flag (and we call the `unregisterFromInspector` method unconditionally).
This also gates the registration/unregistration on Android properly.
Reviewed By: huntie
Differential Revision: D54357554
fbshipit-source-id: 945288acdabdface324884bee1e832870ec8806f
Summary:
This change moves the prepack script of react-native in a separate script, so we can make sure we execute all the preprocessing we need before packing and publishing React Native to OSS.
## Changelog:
[General][Changed] - Moved the tasks of prepack in a separate node script
Reviewed By: huntie
Differential Revision: D54308411
fbshipit-source-id: 989c2b8c6cf88a1e9d87cf34e43351b5c0e7ea73
Summary:
Added a check to avoid the regeneration of RNCore components in case they have been generated already.
In order to maintain backward compatibility and to make sure not to break internal use cases, I think we should still keep the possibility to generate these components at `pod install` time.
Internal users of RNTester, for example, will not run `yarn prepack` before building react-native using OSS technology.
Notice that, in this specific case, the Codegen generates the file in a path that is not `node_modules`.
## Changelog:
[General][Added] - Skip generation of RNCore if the files have been already generated
Reviewed By: dmytrorykun
Differential Revision: D54308832
fbshipit-source-id: 0b5822a367eb0b191c42bc92f8bff20d541c5b29
Summary:
This change extracts the function to create RNCore components in a separate reusable unit.
RNCore is now generate in the `node_modules` folder when the app runs pod install, which is a problem because there are use cases where it's not possible to modify the `node_modules` folder or the generated files might be lost.
The goal is to:
- extract this function
- execute this function before packing react-native during the release. (see D54308411)
In this way, we are going to generate the RNCore files in the react-native path that will be packaged and then released.
Users of react-native will have the generated code directly in the node_modules with no need to generate it.
## Changelog:
[General][Added] - Add function to only generate RNCore components
Reviewed By: huntie
Differential Revision: D54308713
fbshipit-source-id: 0fa9ab4ba7b66c577663f0c736742c4d5583f617
Summary:
This change factor out in a variable the `libraryName` to avoid verbosity.
## Changelog:
[Internal] - factor out libraryName
Reviewed By: dmytrorykun
Differential Revision: D54308601
fbshipit-source-id: 1a64a6b960cc86a1cff059e3ba6a45c33bf3150e
Summary:
This change refactor the RNCORE_CONFIGS in a separate variable to simplify reuse.
## Changelog:
[Internal] - Refactor code
Reviewed By: dmytrorykun
Differential Revision: D54308346
fbshipit-source-id: b9d7c8e0a9b4042f2ab1adeb7aae875264d22499
Summary:
In OSS we have reports like [this one](https://github.com/facebook/react-native/issues/43241) where env variables from different settings might clash together, making react native apps fail to build hermes.
For example, a team might have defined a BUILD_FROM_SOURCE env variable to build their specific project from source and that will clash with how react native apps installs Hermes.
This change disambiguate the BUILD_FROM_SOURCE flag we have internally, moving to a less likely to clash RCT_BUILD_HERMES_FROM_SOURCE.
## Changelog:
[iOS][Breaking] - Rename BUILD_FROM_SOURCE to RCT_BUILD_HERMES_FROM_SOURCE
Reviewed By: huntie
Differential Revision: D54356337
fbshipit-source-id: 1115e3c22cbcf1d64b7edae30da614d52423123b
Summary:
The current behavior for `maintainVisibleContentPosition` on ScrollView is to pick the first fully visible item as the scroll anchor. This has a number of disadvantages:
* It causes problems for lists with loading indicators and large items. The loading glimmer can be picked as the anchor and pull the scroll down too quickly. This is the case for Marketplace.
* It's inconsistent with the [CSS Scroll Anchoring](https://www.w3.org/TR/css-scroll-anchoring-1/) behavior, which is to pick the first partially visible view.
This change will switch to picking the first partially visible view as the anchor, to align with the CSS implementation.
Discussed the change with yungsters, NickGerleman, and cipolleschi and agreed about the change in behavior.
This also enables `maintainVisibleContentPosition` for Android. After adding it to `validAttributes` for Android it appears to be working well. Previously it was not functional at all on Android, as the property change from React was not passed to ReactScrollViewManager.java.
## Changelog:
[General] [Changed] - maintainVisibleContentPosition property on ScrollView now selects the first partially visible view as the anchor, rather than the first fully visible view.
Reviewed By: NickGerleman
Differential Revision: D54223244
fbshipit-source-id: 05ddfc0bbf16d61f9599b9d8066c0bd21b086301
Summary:
Changelog: [Internal]
Fixes a bug detected by LeakSanitizer: `HostAgent`'s destructor writes to session state, but when the containing `HostTargetSession` is being torn down, the `SessionState` object currently gets destroyed first, resulting in a dangling reference. Reordering the members of `HostTargetSession` results in the correct destruction order.
bypass-github-export-checks
Reviewed By: robhogan
Differential Revision: D54305545
fbshipit-source-id: e91a6f3de5eed327b811524548d01565e26234fa
Summary:
Changelog: [Internal]
This implements the integration of `ReactInstance` with the modern CDP backend.
This is the last missing piece to complete the integration of bridgeless with the modern CDP backend, and now we can test it end to end.
Reviewed By: huntie
Differential Revision: D51459050
fbshipit-source-id: 54e8972ee199cbcc8e5e73d7215a34f008feeaa3
Summary:
Changelog: [Internal]
This implements the integration of `ReactHost` with the modern CDP backend. It handles the registration of pages in CDP when we create new instances of `ReactHost` (which is the equivalent concept in React Native).
The next PR will handle the registration of `ReactInstance` to complete the integration on bridgeless.
Reviewed By: huntie
Differential Revision: D51459049
fbshipit-source-id: 9576c8d8e38ca925035d90f2871bcd7aa534f725
Summary:
Changelog: [internal]
This adds a new type of executor in AndroidExecutors to execute runnables on the UI thread.
If the caller is already on the UI thread it'd call the runnable immediately. Otherwise it'd be scheduled in the UI thread to execute asynchronously.
Reviewed By: huntie
Differential Revision: D53941120
fbshipit-source-id: b68c7a4540be2a12df930e4e52eeb7b7a1aa91d8
Summary:
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D54027184
fbshipit-source-id: 722a7e398849f5d935894f321aa0177167eebaef
Summary:
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D54027180
fbshipit-source-id: bf8875c06c8990172e6b449e12902691131b9cef
Summary:
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D54027186
fbshipit-source-id: 2cee2b598c3ef15641222018703a7d6a467ba30c
Summary:
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: arushikesarwani94
Differential Revision: D54027177
fbshipit-source-id: 13b4352f0b61eec69bfdcb6a3e369faa4dfcc750
Summary:
This PR fixes an issue that `_logWarnIfCreateRootViewWithBridgeIsOverridden` was called in wrong place.
Assuming user overrides this method and call to `[super]`:
```objc
- (UIView *)createRootViewWithBridge:(RCTBridge *)bridge moduleName:(NSString *)moduleName initProps:(NSDictionary *)initProps {
UIView *view = [super createRootViewWithBridge:bridge moduleName:moduleName initProps:initProps];
view.backgroundColor = [UIColor redColor];
return view;
}
```
This method still wasn't called in bridgeless (and not showing the error).
Checking if user overrides this method in `appDidFinishWithLaunching` works every time

## Changelog:
[IOS] [FIXED] - Properly warn about `createRootViewWithBridge` being deprecated
Pull Request resolved: https://github.com/facebook/react-native/pull/43146
Test Plan: Check if warning is shown when message is overridden
Reviewed By: huntie
Differential Revision: D54303506
Pulled By: cipolleschi
fbshipit-source-id: cf30555c791493f28b3015a189cf93b60cace8f8
Summary:
This change align the `getSurfacePresenter` and `getModuleRegistry` to the iOS convention for which these should be computed properties with no `get` prefix in their name.
We want to land this change and to pick it in 0.74 so we can remove the `get` versions in 0.75.
## Changelog:
[iOS][Deprecated] - Deprecate `getSurfacePresenter` and `getModuleRegistry` for `surfacePresenter` and moduleRegistry` props.
Reviewed By: javache
Differential Revision: D54253805
fbshipit-source-id: e9ff7db744a73a3bd0f8ae1d87875e54ddd9a1a4
Summary:
This adds support for 64 bit integer (long) values to MapBuffer. Per the wide gamut color [RFC](https://github.com/react-native-community/discussions-and-proposals/pull/738) Android encodes wide gamut colors as long values so we need to update MapBuffer to support 64 bit integers as well.
## Changelog:
[ANDROID] [ADDED] - Add 64 bit integer (long) value support to MapBuffer
Pull Request resolved: https://github.com/facebook/react-native/pull/43030
Test Plan: I've added a test to the MapBuffer test suite. This new API is otherwise currently unused but will be used in subsequent PRs as part of wide gamut color support changes.
Reviewed By: mdvacca
Differential Revision: D53881809
Pulled By: NickGerleman
fbshipit-source-id: 39c20b93493a2609db9f66426640ef5e97d6e1a8
Summary:
## Changelog:
[Internal] -
Was writing some unit tests, accidentally included `ImageProps.h` twice (once directly and once transitively) and realized that we have a handful of files without `#pragma once`.
This fixes it for header files inside `ReactCommon`.
Reviewed By: zeyap
Differential Revision: D54258058
fbshipit-source-id: 70f4e9935304803187d1affd72ed44157b1d8fb3
Summary:
Changelog: [General][Fixed] Fixed crash when passing fewer arguments than expected in native modules using codegen
## Context
Right now, if you have a native module using the codegen with a method like this:
```
someMethod(value: number): void;
```
And you call it like this:
```
NativeModule.someMethod();
```
The app crashes.
This happens because the codegen tries to cast the value to the expected type without checking if the argument is within the bounds of the arguments array.
## Changes
This fixes that issue with a change in the codegen to guard against this in the generated code (see changes in the snapshot tests).
Reviewed By: RSNara
Differential Revision: D54206287
fbshipit-source-id: 575af462725515928f8634fccc7a9cb51ca0ce4f
Summary:
Changelog: [General][Fixed] Fixed crash when passing non-numeric values where RootTag is expected to methods in native modules using codegen
## Context
Right now, if you have a native module using the codegen with a method like this:
```
someMethod(value: RootTag): void;
```
And you call it like this:
```
NativeModule.someMethod('');
```
The app crashes.
This happens because we cast the JS value to a C++ value using the method that asserts (`toNumber`) instead of the one that throws a JS error (`asNumber`).
## Changes
This fixes the crash by using `asNumber` instead of `toNumber`.
Reviewed By: RSNara
Differential Revision: D54206288
fbshipit-source-id: 9398112667e0f26edaf4f8f3b32e79fa8aafde62
Summary:
This change fixes a couple of issues within the RCTUIManager:
* it calls the right method in the `super` branches (although they should neve be executed)
* it invert the call order between the `_registry` and the `uiManager` to avoid extra calls into the `viewForReactTag`.
## Changelog:
[Internal] - Use the right method in super and invert the order of where we search for views.
## Facebook:
See S397861 and T180527210 for more information.
Reviewed By: javache
Differential Revision: D54246220
fbshipit-source-id: 1c7503ad3e80cf50ecc016a984ca180a19b73cc0
Summary:
This diff removes extra argument from the `extractLibrariesFromJSON` call inside `findLibrariesFromReactNativeConfig`.
This should fix the iOS failurte discribed in https://github.com/facebook/react-native/issues/43204
Changelog: [iOS][Fixed] - Codegen correctly handles react-native.config.js.
Reviewed By: cipolleschi
Differential Revision: D54248400
fbshipit-source-id: 2ae5d0d29f49725877559a5b0edd7d59f8bdefaa
Summary:
This adds initial support for wide gamut (DisplayP3) colors to React Native iOS per the [RFC](https://github.com/react-native-community/discussions-and-proposals/pull/738). It provides the ability to set the default color space to sRGB or DisplayP3 and provides the native code necessary to support `color()` function syntax per the [W3C CSS Color Module Level 4](https://www.w3.org/TR/css-color-4/#color-function) spec. It does _not_ yet support animations and requires additional JS code before fully supporting the `color()` function syntax.
bypass-github-export-checks
## Changelog:
[IOS] [ADDED] - Add basic DisplayP3 color support
Pull Request resolved: https://github.com/facebook/react-native/pull/42830
Test Plan:

Follow test steps from https://github.com/facebook/react-native/issues/42831 to test support for `color()` function syntax.
To globally change the default color space to DisplayP3 make the following changes to RNTester AppDelegate.mm:
```diff
+ #import <React/RCTConvert.h>
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
// ...
+ RCTSetDefaultColorSpace(RCTColorSpaceDisplayP3);
return [super application:application didFinishLaunchingWithOptions:launchOptions];
}
```
Reviewed By: javache
Differential Revision: D53380407
Pulled By: cipolleschi
fbshipit-source-id: 938523958f9021e8d98bdb1d4e254047e3ecdad7
Summary:
## Changelog:
[Internal] -
`view.transformOrigin` prop should be initialized to "center", since this is default [per documentaion](https://reactnative.dev/docs/next/transforms#transform-origin), and it should be treated this way even if the prop is not explicitly set from JS.
Reviewed By: christophpurrer
Differential Revision: D54229772
fbshipit-source-id: 5212792c8dc5db6f4c17d1b2980ac2564c986cd8
Summary:
`Image.getSize/getSizeWithHeaders` are still working in old fashioned "callback" way
```tsx
Image.getSize(uri, function success(width,height) { }, function failure(){ } ); // undefined
Image.getSizeWithHeaders(uri, headers, function success(width,height) { }, function failure(){ } ); // undefined
```
But in 2024 more developers prefer use async/await syntax for asynchronous operations
So, in this PR I added support for Promise API with **backward compatibility**, modern way:
```tsx
Image.getSize(uri).then(({width,height}) => { }); // Promise
Image.getSizeWithHeaders(uri, headers).then(({width,height}) => { }); // Promise
```
bypass-github-export-checks
## Changelog:
[GENERAL] [ADDED] - `Image.getSize/getSizeWithHeaders` method returns a promise if you don't pass a `success` callback
Pull Request resolved: https://github.com/facebook/react-native/pull/42895
Test Plan:
1. ts: New test cases added in typescript tests
2. runtime: you can create a new project and put code from this PR into the next files
a. `node_modules/react-native/Libraries/Image/Image.android.js`
b. `node_modules/react-native/Libraries/Image/Image.ios.js`
Reviewed By: javache
Differential Revision: D53919431
Pulled By: cipolleschi
fbshipit-source-id: 508b201e17e0ffda2e67aa5292bf9906b88d09c5
Summary:
This small PR fixes issue causing `AlertExample` to crash on `login-password` prompt example, as it was trying to render object in `<Text>`
## Changelog:
[INTERNAL] [FIXED] - Prevent alert example from crashing
Pull Request resolved: https://github.com/facebook/react-native/pull/43084
Test Plan: `login-password` prompt example in `AlertExample` doesn't crash when pressing `OK`
Reviewed By: cipolleschi
Differential Revision: D53964494
Pulled By: lunaleaps
fbshipit-source-id: 16a0364d3d65a33956c21a68b121e6c26b41d123
Summary:
This change renames `PopupMenuAndroidNativeComponent.js` to `PopupMenuAndroidNativeComponent.android.js`.
The reason is that, without the suffix, Codegen was reading the NativeComponent spec also for iOS, generating some invalid specs and making RNTester fail.
## Changelog:
[Android][Changed] - Rename `PopupMenuAndroidNativeComponent.js` to `PopupMenuAndroidNativeComponent.android.js`
Reviewed By: cortinico, dmytrorykun
Differential Revision: D54199736
fbshipit-source-id: 7fd67c4d38a69fe3a84c800c8ee5dcbd8c4f9a6c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43101
Extends `ReactInstanceIntegrationTest` to allow varying feature flags in tests, using gtest's parameterised tests.
Exercise this in `ConsoleLogTest` to test against the modern CDP registry, for which we also needed to modify some initialisation logic to account for the fact that under the modern registry, the page is added by the host, rather than by Hermes `DecoratedRuntime`.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D53919148
fbshipit-source-id: 4eb87abf548f30b5483b819a2dadd444d1d5c80d
Summary:
Changelog: [Internal]
Uses the capability introduced in https://github.com/facebookexperimental/rn-chrome-devtools-frontend/pull/4 to avoid repeating the dev server's host:port in the `ws` / `wss` parameter we pass to the Chrome DevTools frontend. This gives us more flexibility to handle port forwarding and redirects outside of `dev-middleware`. This is mostly useful in Meta's internal VS Code remoting setup, but this particular change should work equally well in open source.
Reviewed By: huntie
Differential Revision: D54107316
fbshipit-source-id: 68d4dbf4849ca431274bfb0dc8a4e05981bdd5b5
Summary:
**History:** This component was originally introduced into React Native core in D52712758, to replace UIManagerModule.showPopupMenu().
**Problem:** But, React Native core should be lean. Adding this component to React Native bloats the core.
**Changes:** So, this diff pulls PopupMenuAndroid out into its own package in the react-native GitHub repository.
In the future, this will be migrated to a community package!
Changelog: [Android][Removed] Move PopupMenu out of React Native core
Reviewed By: NickGerleman
Differential Revision: D53328110
fbshipit-source-id: 469d8dc3e756c06040c72e08fa004aafa1bd6e18
Summary:
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: rshest
Differential Revision: D54027183
fbshipit-source-id: b87e3931642abaa22b84fd48f0504f36e9c3621f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43162
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D54027181
fbshipit-source-id: af9f022d36a2e60788d6790525736d1b6cfdf6fa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43161
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
bypass-github-export-checks
Reviewed By: javache
Differential Revision: D54027187
fbshipit-source-id: a25024ba7f7d4893a2b7d083e2ba10c5f2e3a035
Summary:
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
bypass-github-export-checks
Reviewed By: javache
Differential Revision: D54027182
fbshipit-source-id: 946dbf484119890658c68767916fcbf7c66996bc
Summary:
UIManagerListener interface is unstable and not recommended to be consumed externally, this API is likely to change in the future
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D54028407
fbshipit-source-id: c8601451f117226f9e5a4d291307f4a0ac04a10f
Summary:
Those files should not stay in the root `/app` folder but inside the `/app/gradle/wrapper` folder.
I've noticed this in the Upgrade Helper UI hence I'm removing them.
Changelog:
[Internal] [Changed] - Remove accidental files included inside the template
Reviewed By: mdvacca
Differential Revision: D54122995
fbshipit-source-id: 8873a91ffbea20f609c7aabd428a815c77a38db5
Summary:
RN-Tester is currently instacrashing on fast-refresh (pressing r on Metro) as it ends up on `onJSBundleLoadedFromServer`
which throws an exception on Bridgeless mode. I'm fixing it by following the same logic as `onReloadWithJSDebugger`.
Changelog:
[Android] [Fixed] - Do not crash on onJSBundleLoadedFromServer when fast-refreshing on bridgeless mode
Reviewed By: huntie
Differential Revision: D54121838
fbshipit-source-id: 82d98ec0c5b2295f5751525368c956574dd7f3a0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43133
I noticed inconsistent handling of terminating newlines in D54006327@V1, and had also been noticing `yarn build` reformatting unrelated sections of `package.json` files.
For now, this logic isn't moved to a shared util, since there will likely be a higher level abstraction for the release scripts in the next batch of improvements.
Changelog: [Internal]
Reviewed By: lunaleaps, cipolleschi
Differential Revision: D54007565
fbshipit-source-id: 74d58362a85be4fae2f9e058b6c6622a026ff0a0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43157
IViewGroupManager is NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: rshest
Differential Revision: D54034058
fbshipit-source-id: ad317c73d45fdd801aeee65d5308400e2e1c8552
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43156
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D54027185
fbshipit-source-id: f3c337def2d42cf1f6fed2e2eb4938a84a51f8d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43155
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: arushikesarwani94
Differential Revision: D54027178
fbshipit-source-id: 37940ecec4d42f9f5ae7784a865564b0ef80f4a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43159
Changelog: [internal]
This modifies the default `RCTAppDelegate` for iOS apps in OSS to provide an implementation for the C++ native module for feature flags.
In a following diff I'll replace the `React-featureflagsnativemodule.podspec` file with one that includes all built-in C++ native modules.
Reviewed By: RSNara
Differential Revision: D54082349
fbshipit-source-id: 8c4ed7499c6fd35916ba105edcae0e2c85961e1c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43152
Now that 0.74 has been cut, we can drop this warning and let the exception bubble up.
In https://github.com/facebook/react-native/pull/41509 we stopped masking this.
Changelog: [Android][Changed] Throwing IllegalArgumentException from ReactPackage is no longer suppressed
Reviewed By: cortinico, cipolleschi
Differential Revision: D54068429
fbshipit-source-id: c2f780ccfefabf2334c94b632bca93242af86008
Summary:
This diff renames React-Codegen to ReactCodegen. This way we'll no longer have to try both
```
#include <React-Codegen/MyModule.h>
```
and additionally
```
#include <React_Codegen/MyModule.h>
```
for cases with `use_frameworks`.
Changelog: [iOS][Breaking] - Rename React-Codegen to ReactCodegen
Reviewed By: cipolleschi
Differential Revision: D54068492
fbshipit-source-id: dab8ea2034d299266482929061caa14397421445
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43149
Changelog: [internal]
At the moment we're silently falling back to default values when trying to use common feature flags from JS when the native module isn't available. This could lead to unexpected behaviors and it's not immediately obvious, so this logs an error when it happens.
Reviewed By: javache
Differential Revision: D54063391
fbshipit-source-id: 5886754958930b88ef63c24d77a9e8486d92c731
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43135
This change makes the New Architecture the default on both iOS and Android.
This means that new application will be created using the New Architecture by default.
It is still possible to opt out from it.
## Changelog
[General][Changed] - Make the new architecture the default
Reviewed By: cortinico, sammy-SC, dmytrorykun
Differential Revision: D54006751
fbshipit-source-id: bd7de0814925b65ab180105e18c1f6f275ba2672
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43094
Merge the internal `cxxcdp-tester` project into `jsinspector-modern/tests`.
Note: These tests still use RN default feature flags and therefore test against the legacy CDP registry - that's addressed in the next diff.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D53766994
fbshipit-source-id: eec144124b20a4500e28398e98763febaed52748
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43143
AsyncCallback allows storing SyncCallback and invoking it from any thread.
However, there are cases where if you have a mix of sync and async callbacks - you might want to invoke them together in one go, instead of spreading them out across thread invocations.
For those cases - allow invoking any AsyncCallback as a sync one, prefixing it with "unsafe", because it's inherently not a safe operation to perform.
Changelog:
[General][Changed] - Allow invoking the AsyncCallback synchronously to allow for tight performance optimization.
Reviewed By: s-rws
Differential Revision: D54028850
fbshipit-source-id: f6729819f791f1d58d2ca655d4082547f18bdd2d
Summary:
`ndkVersion` is unset when building from source using this guide: https://reactnative.dev/contributing/how-to-build-from-source
## Changelog:
[ANDROID] [FIXED] - Fix `ndkVersion` is unset when building from source
Pull Request resolved: https://github.com/facebook/react-native/pull/43131
Test Plan:
```
git clone https://github.com/microsoft/react-native-test-app.git
cd react-native-test-app
npm run set-react-version nightly
yarn
# Manually apply the patch in node_modules/react-native/ReactAndroid/build.gradle.kts
# Enable building from source
sed -i '' 's/#react.buildFromSource/react.buildFromSource/' example/android/gradle.properties
# Build
cd example/android
./gradlew assembleDebug
```
Reviewed By: christophpurrer
Differential Revision: D54006425
Pulled By: cortinico
fbshipit-source-id: 9ede64bc14af4cf609b7a4c12c5a1082bbc31f09
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43129
## Changelog:
[Internal] -
C++ side expects "source" property to be an up to date, correctly resolved Image source inside `ImageProps`.
Incidentally, it wasn't the case when:
* we build for an Android platform
* the asset is a "packager asset", i.e. bundled by Metro and included in APK
It hasn't been an issue in the case of "pure" Android platform, as it instead uses "src" prop, instead of source on the Java implementation side, ignoring "source" completely, so the fact that "source" wasn't propagated correctly to C++ in some cases didn't affect Android.
However, there are some new use cases where we'd like to have correct "source" value in C++ as well (and ultimately align this between all the platforms, so it's "source" everywhere, but this is a matter of a separate discussion).
Differential Revision: D54000899
fbshipit-source-id: 9bfb9e7c157cf19ddf396c141b03b75f3b2022e8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43130
Various fixes/tweaks to the `test-e2e-local` script, impacted by recent changes, found during the release process:
- Fix typo in variable name for `circleciToken` arg.
- Relocate erroneously positioned `process.exit` call (a force exit around Verdaccio, which we will remove in future).
- Add notice on exit around Verdaccio server not being killed successfully (to do in T179377112).
- Switch from Yarn to npm for test project installation — Yarn 3 is not respecting `npmRegistryServer`, see https://github.com/yarnpkg/yarn/issues/2508.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D53951606
fbshipit-source-id: f6e29ef6c9ab33ebf60124757576fcb54219f339
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43118
While debugging issues with precompiled_headers in Instagram, it became apparent that these RN files don't correctly import the necessary files to make them build on their own. Fix that!
Changelog: [iOS][Fixed] Fixed missing header imports
Reviewed By: fkgozali
Differential Revision: D53963676
fbshipit-source-id: 74e9758153f6176133475e45d27f7644d1a6dece
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43023
Unused mobile config, and is not consistently used across all the many places we can initialize a Hermes instance.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D53761942
fbshipit-source-id: a3e1adae87e41142c337a27b33750f82774cf92c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43114
Changelog: [iOS][Breaking]
PR#42628 introduced new behavior on how the react native infra tracks local notifications that start the app. in this PR, we are officially deleting the old implementation.
Reviewed By: ingridwang
Differential Revision: D52931617
fbshipit-source-id: 3b77479b0aacf239e45cfcc7d7c4b20e82e0b786
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43113
Changelog: [Internal]
Renames the "Page" concept in the modern CDP backend to "Host". Now all the Target types we have are named consistently after React Native concepts (ReactHost, ReactInstance, JSI Runtime) rather than CDP/browser concepts (Page).
Reviewed By: robhogan
Differential Revision: D53945333
fbshipit-source-id: 90e8b914ba8b4927806cbdd072ca36c78fd2093f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43049
This connects the OnLoad.cpp file used by OSS apps with the `rncli_cxxModuleProvider`.
This method is created by the CLI and takes care of querying all the TM CXX Modules discovered and returning them.
This PR is currently waiting on https://github.com/react-native-community/cli/pull/2296
Changelog:
[Internal] [Changed] - Hook the default-app-setup OnLoad.cpp file with the cxxModuleProvider from RNCLI
Reviewed By: cipolleschi
Differential Revision: D53812109
fbshipit-source-id: 47bc0ea699516993070cfa0127de97853acf8890
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43111
When mounting views in the interop layer, we register them in an array `reactSubview` that is added to `UIView`. However, when unmounting them, we were just removing them from the parent view.
This worked fine while the view we were adding to reactSubview was the same that we were adding to hierarchy. However, there are instances where libraries might wrap those views in some custom wrappers. This break the assumption that the same view we are adding to the UI hierarchy is the same view we will remove.
With this change, we make sure to use the same semantic when we add some view and when we remove it.
This also fixes a crash that happens with Mobile home when navigating away from the Ride's Map, using Fabric.
## Changelog
[internal] - Remove views from hierarchy using the view that is added to the `reactSubviews`
Reviewed By: sammy-SC
Differential Revision: D53943728
fbshipit-source-id: 56e669c14db74b6af683384b6ca72ad3f5cfdafe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43099
In all methods of FabricUIManager we check whether it's been destroyed before doing any logic, but we don't in this asynchronous method we're scheduling to report mounts.
This adds the check in that case as well to potentially fix some crashes we're seeing in current experiments for mount hooks on Android.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D53920863
fbshipit-source-id: 3cc18cf5237d4866940739de80cc00604bcd0fb6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43070
**Context**
The `codegenNativeComponent` function is a hint for the codegen that the file that contains it is a Native Component spec. Static ViewConfig codegen overwrites this function call by the generated ViewConfig.
If this function is not overwritten by the codegen, it has runtime behaviour that falls back to `requireNativeComponent`. At the time when this system was built `requireNativeComponent` was not supported in Bridgeless mode because it is relied on some Bridge-only functionality. That's why it outputs error in Bridgeless mode.
---
This is not the case any more, we now have interop layers which provide the functionality needed by `requireNativeComponent`.
The SVC codegen is implemented as [Babel plugin](https://github.com/facebook/react-native/tree/main/packages/babel-plugin-codegen). The are scenarios when it is not run for the native component specs:
- If the plugin is not used for whatever reason.
- If Babel is not used for whatever reason.
In order to not to regress the DevX for such cases, we've turned the error into the warning.
**Note:** we use `console.info('⚠️...` instead of `console.warn('...`. That's because `console.warn` also prints a stack trace in the console, and we didn't want to create too much noise.
Changelog: [General][Changed] - codegenNativeComponent show warning and not error if not code generated at build time.
Reviewed By: huntie, rshest
Differential Revision: D53761805
fbshipit-source-id: c924c7668e6d2e45b920672b8a309221be767a73
Summary:
De-duplicate the logic for counting attachments.
This is a minor improvement in the context of my multi-PR work on https://github.com/react-native-community/discussions-and-proposals/issues/695.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [CHANGE] - De-duplicate the logic for counting attachments
Pull Request resolved: https://github.com/facebook/react-native/pull/42596
Reviewed By: rshest
Differential Revision: D53917281
Pulled By: cipolleschi
fbshipit-source-id: cdb9bc834bddd7deffc60f33578464733982fedf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43105
This is a quality of like improvement for the project we create for the final users.
Codegen generates code in `rncore`, within `node_modules`. This is not the perfect approach but it is working so far.
To make it more robust, we added a small script in React-Fabric podspec to check that codegen run properly when building.
In this way, if a user run `yarn install` and, for any reason, react-native is regenerated, we can provide a better DevX to our users with an actionable message on how to fix the build problem.
##Changelog
[iOS][Added] - Add error message if codegen has not run properly
Reviewed By: cortinico
Differential Revision: D53927788
fbshipit-source-id: a01a33086e4a0a1b0ada6c83283a5fd3fb5ee3eb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43098
Changelog: [Internal]
Wraps Hermes's `CDPHandler::getState()` API in an engine-agnostic abstraction (`RuntimeAgentDelegate::getExportedState`).
An Agent's lifetime ends when its Target is destroyed, but it can occasionally be useful to persist some state for the "next" Target+Agent of the same type (in the same session) to read.
`RuntimeAgentDelegate` is polymorphic and can't just write arbitrary data to SessionState. Instead, it can now *export* a state object that we'll store and pass to the next `RuntimeTargetDelegate::createAgentDelegate` call.
Reviewed By: huntie
Differential Revision: D53919696
fbshipit-source-id: a8e9b921bc8fc2d195c5dddea9537e6ead3d0358
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43054
Changelog: [iOS][Android][Added] Experimental macro to autolink C++ turbomodules
This implementation is inspired by RCT_EXPORT_MODULE on iOS. We keep a global data structure that maps module names to a lambda that returns the C++ turbomodule. This will come with a hit to startup time. the only way to avoid that is a solution that does static analysis of the list of C++ turbomodules being linked to the library.
Reviewed By: fkgozali
Differential Revision: D53602544
fbshipit-source-id: 8ea49fa576dc718f44b1595b68ab7c606c2db605
Summary:
Changelog: [Internal]
Ports RN's Hermes CDP integration tests to `TYPED_TEST` so we can easily run them against a different Hermes engine adapter in another diff.
bypass-github-export-checks
Reviewed By: huntie
Differential Revision: D53810359
fbshipit-source-id: fb9717bbdc1346ed26b9c8796c13bac641bc5a60
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43091
Fix typo in unit test
Changelog:
[Internal] [Changed] - Fix typo in unit test
Reviewed By: mdvacca
Differential Revision: D53918471
fbshipit-source-id: 0453c01fab1dc04397058577ea61b50994124cf0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43090
I'm removing test_windows from CircleCI as the job is often flaky for various reasons.
The cost of maintainaining it is so high at the moment, and it brings little to no value to our developers.
We'll re-evaluate what to do with it once we move to GHA.
Changelog:
[Internal] [Changed] - Remove test_windows from CircleCI
Reviewed By: cipolleschi
Differential Revision: D53918601
fbshipit-source-id: b76c92f1eb3d2302595773dff9f8bbc292c0bfcf
Summary:
Changelog: [Internal]
Hermes:
Adds the missing `validateExecutionContext` call to `Runtime.evaluate`.
React Native:
Adds an integration test case to cover the expected behaviour around targeting `Runtime.evaluate` by execution context.
bypass-github-export-checks
Reviewed By: huntie
Differential Revision: D53776532
fbshipit-source-id: 66676383ba5b373fdbf2deb8c75f22791b07e300
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43075
There is a `\` in the new_architecture.rb file that should not be there.
## Changelog:
[Internal] - remove unnecessary character
Reviewed By: cortinico
Differential Revision: D53886548
fbshipit-source-id: a614368bed9f467b80c3384e4adc4be2cbcaba2d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43081
When Hermes i used, it is hermes that provides JSI to React Native and not React-jsi.
This is required to fix the ODR violatons.
Dynamic frameworks requires that all the dependencies are declared explicitly, and missing the `hermes-engine` dependency was breaking the dependency graph.
## Changelog
[Internal] - Make JSIInspector depends o hermes-engine
Reviewed By: motiz88
Differential Revision: D53901016
fbshipit-source-id: a511719647e6203d082696fd572593fd851a1dde
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43065
Changelog: [Internal]
Implements support for [`Runtime.addBinding`](https://cdpstatus.reactnative.dev/devtools-protocol/tot/Runtime#method-addBinding) in the new RN CDP backend.
This implementation is mostly complete and matches Chrome's behaviour, but does not include the ability to target bindings by execution context (the optional `executionContextId` and `executionContextName` params) - that will come in a separate diff for ease of review/landing.
Incidentally, this diff also introduces the `JsiIntegrationPortableTest::expectMessageFromPage` helper, which allows us to "asynchronously" extract the contents of an expected message. For consistency and clarity, we refactor all the other `EXPECT_CALL(this->fromPage(), onMessage(JsonEq(...)))` assertions to use it as well.
Reviewed By: huntie
Differential Revision: D53266709
fbshipit-source-id: 046326acdf5dacc18e179e43589cdd2d012f353a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43064
Changelog: [Internal]
Aligns React Native's CDP backend with V8's behaviour of assigning a sequential ID (here unique within a given PageTarget) to each execution context.
Reviewed By: huntie
Differential Revision: D53776531
fbshipit-source-id: 950599c323f416e8180e42281d94ae9c00f15fb0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43063
Changelog: [Internal]
Moves the responsibility for managing CDP execution contexts out of the Runtime and into the Instance.
This includes the responsibilities to:
1. Assign execution context IDs/names
2. Emit events when execution contexts are created/destroyed
3. Route CDP messages to the correct Runtime
**Re 1:** We currently assign a *constant* execution context ID, which diverges from V8's implementation but is in line with what Hermes has done so far. I'll follow up separately to assign (locally) unique IDs, since this diff is long enough already.
**Re 3:** Right now, the message routing responsibility is mostly theoretical: only one Runtime exists at a time and "routing" can be done by RuntimeAgent simply deciding whether or not to act on a message (since it receives all messages by default and knows its own `ExecutionContextDescription`). True multi-Runtime / multi-context support is firmly a future concern, and we can revisit this ( = probably hoist more logic into Instance) when we get there.
In the `ExecutionContextNotifications` integration test we can see that a few minor bugs in the current Hermes-based implementation are fixed, and also that execution context management is now engine-agnostic (so we can use `JsiIntegrationPortableTest` instead of `JsiIntegrationHermesTest`).
Reviewed By: huntie
Differential Revision: D53759776
fbshipit-source-id: 50ac126789c95b25f845780df2c3346ec345d5d5
Summary:
While looking at another issue, I realized that in some cases the script was adding the same flags twice and it was leaving the RCT_NEW_ARCH_ENABLED behind.
## Changelog:
[iOS][Fixed] - Pass the right flags to libraries
Pull Request resolved: https://github.com/facebook/react-native/pull/43071
Test Plan: Fixed Unit tests
Reviewed By: huntie
Differential Revision: D53860576
Pulled By: cipolleschi
fbshipit-source-id: 1f6f4852df8d316293b93d7c5fbef09a249893a5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43060
When inestigating the reason why [`react-native-view-shot`]() ws not working, we realized that there are many libraries that follows this pattern:
```objc
[self.bridge.uiManager addUIBlock:^(RCTUIManager *uiManager, NSDictionary<NSNumber *, UIView *> *viewRegistry) {
if (UIView *view = viewRegistry[reactTag]) {
//do something with the View
}
}];
```
The problem is that, with the New Architecture, that view registry is usually empty, because the components are registered and tracked in another place.
This make many libraries stop working when used with the New Architecture.
This change introduces a class that behaves like a dictionary but that forward the calls to retrieve the view to the right place, in order to get the view that is needed.
Noticably, this approach allow us also to remove some shenanigans we were applying to make sure that the interop layer could access the views wrapped in it, so the current solution is more general and should work in multiple situations.
## Changelog
[iOS][Fixed] - Make sure that `addUIBlock` provides a Dictionary-look-alike object that returns the right views when queried.
Reviewed By: sammy-SC
Differential Revision: D53826203
fbshipit-source-id: 08d359676d69777b88fa9b18dc141187ac42dbce
Summary:
This is a preliminary change which converts RCTConvert to an objectiveC++ file. This is required by the next diffs in the stack.
## Changelog
[iOS][Changed] - Make RCTConvert an Objective-C++ (`.mm`) file in prep for DisplayP3 changes
Reviewed By: javache
Differential Revision: D53520228
fbshipit-source-id: cf45c42955401b4e14fe68221129077817b2598e
Summary:
The test_ios_rntester-Hermes which runs in github actions was created to make sure that recent commits on Hermes/main won't be breaking React Native
However, we discovered that the job was using a cached version of hermes and it was't really downloading the latest hermes every time.
With this change, the cocoapods cache will be invalidated whenever there is a commit on hermes/main, forcing the job to reinstall the dependencies when that happens.
bypass-github-export-checks
## Changelog:
[internal] - Fixed GH Action job to properly refetch newest version on Hermes when it changes.
Pull Request resolved: https://github.com/facebook/react-native/pull/43067
Test Plan:
Github Actions must be green and the action should show that a new version of Hermes is downloaded.
The commit is downloaded here:
{F1457505882}
And it is used here, notice the last hash:
{F1457505989}
Reviewed By: motiz88
Differential Revision: D53853963
Pulled By: cipolleschi
fbshipit-source-id: 7a65dd72a21b6da12b826273d1c92bb90b678652
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43053
- Relocate under `scripts/e2e/` (also move util used only by this cript).
- Type as Flow (to catch trivial errors). Some cleanup of `log()` calls as errors.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D53813023
fbshipit-source-id: 05caf415ec0bf3739a6f7fec3afd385a195f42e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43001
More understandable name: ~"React Native init, for E2E testing". Also relocates Verdaccio config and storage location under `scripts/e2e/` (resolving TODO comment).
The intent is for the `scripts/e2e/` dir to also group the existing E2E testing-related scripts — although I will stop here for the current release-related work.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D53609332
fbshipit-source-id: fb2f6502a18c4a4ac2368b46af1e3ee42edbadd6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42899
Updates the `test-e2e-local` script to bootstrap `/tmp/RNTestProject/` using the currently checked out repository as the source of truth for all monorepo packages (previously we only did this for the `react-native` package).
This enables release testers to validate a release **before** physically publishing new dependency versions via `yarn bump-all-updated-packages`.
We are able to reuse the `scripts/template/initialize.js` script that is currently used for E2E validation in CI. This sets up a local Verdaccio server during project install.
NOTE: The time taken for `Build packages` + Verdaccio isn't ideal, I may explore a way to reuse the published package state in a future diff. Until then, this extra time (~1 min) will still be much less pain than the `bump-all-updated-packages` + commit process loop.
Changelog:
[Internal] - Update test-e2e-local to use source monorepo packages for RNTestProject
Reviewed By: lunaleaps
Differential Revision: D53484510
fbshipit-source-id: 600a8a3257a4947d7738ab9d908d6549c38545e6
Summary:
This PR makes `__gitignore` file universal for Apple OOT platforms.
## Changelog:
[GENERAL] [CHANGED] - Make template's .gitignore file universal for OOT platforms
Pull Request resolved: https://github.com/facebook/react-native/pull/42963
Test Plan: CI Green
Reviewed By: NickGerleman
Differential Revision: D53674632
Pulled By: yungsters
fbshipit-source-id: cb510d9bd2ee6f1c39b77a842e7947b67def552a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43039
Changelog: [Internal] - `publish-npm.js` is a [script we call in our CI](https://www.internalfb.com/code/fbsource/[c0b8566ac0d66c2c0282eeb597bfb54bedf757c6]/xplat/js/react-native-github/.circleci/configurations/jobs.yml?lines=1243) to publish the react-native package and others.
Currently, the script leverages `exit/process.exit` to terminate early in a couple of places which makes the code hard to test because our tests don't truly early exit when `exit/process.exit` is called.
This change removes any explicit `exit` calls and instead leverages the uncaught error to terminate the process and set the non-zero exit code. This makes our tests more accurate to the real control flow of the script.
I've also updated the tests to better capture what we're actually testing by mocking at a higher level.
Reviewed By: cipolleschi
Differential Revision: D53792754
fbshipit-source-id: 9293bb9a95430c50052db36c0e6f6c1ba348107f
Summary:
This PR fixes PerfMonitor option not showing on iOS when running bridgeless. The `initialize` method is not called in bridgeless which causes this option to not be added. I've converted this approach to work for both bridgeless and non-bridgeless.
bypass-github-export-checks
## Changelog:
[IOS] [FIXED] - Perf Monitor option not showing in Bridgeless
Pull Request resolved: https://github.com/facebook/react-native/pull/42891
Test Plan: Run RNTester, open Perf monitor
Reviewed By: RSNara
Differential Revision: D53518507
Pulled By: cipolleschi
fbshipit-source-id: c16d41006c5a3f96d53d4f76fd317941a1eb839f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42941
I noticed that programatically running `npm set registry <value>` would fail within the repo root dir (intended run location) (`node` version `18.18.2`).
```
npm ERR! This command does not support workspaces.
```
It turns out this is no longer supported from npm 9.x: https://github.com/npm/cli/issues/6099. **Note**: The workaround discussed in this thread is incompatible/nontrivial with `npx`, so I've opted to remove this behaviour.
**Changes**
- Remove `npm set registry http://localhost:4873` call.
- This is non-breaking due to the [explicit `--registry` arg already present in `run-e2e-ci-tests.js`](https://github.com/facebook/react-native/blob/b366b4b42e0f91eb2b1850c404fadd0f0322fc61/scripts/run-ci-e2e-tests.js#L102). The previous `.npmrc` config value is unnecessary, and probably was being ignored (will be validated for this PR in CircleCI run).
- Add comment against remaining `.npmrc` write, convert to `fs` call.
- Remove unused params on `setupVerdaccio` (moved to constants which will be exported and referenced in the next diff).
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D53609308
fbshipit-source-id: 77d3666b42963cd61f6d3fd0be00cdc19bbb1ec8
Summary:
When analyzing the `hitTest:withEvent` function, I realized that we were not forwarding the touches to the legacy view.
The previous algorithm was returning the InteropLegacyWrapper view itself when the touches were happening in the legacy view, preventing the handlers attached to the legacy view to fire.
With this change, if the legacy view receives a touch, it can handle it.
## Changelog
[iOS][Fixed] - Make sure to forward touches to the wrapped component in the InteropLayer.
Reviewed By: sammy-SC
Differential Revision: D53806218
fbshipit-source-id: 87b0aa6e900935092e6f5e1533b871c1d224b718
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43018
Assuming that if View is a ViewGroup, its ViewManager is a ViewGroupManager is incorrect. Custom ViewManagers may use ViewGroups internally to represent complex views exposed to JS.
Type-check the ViewManager instead to avoid the crash seen in T178300877
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D53586565
fbshipit-source-id: 49408098cebc7f76d8be0e585187ba9b6ca52049
Summary:
This was introduced to support MapBuffer-based view managers (D33735245), but that experiment has been removed from the codebase (D53072714).
This indirection is preventing a proper fix for a crash we're seeing with RemoveDeleteTree (T178300877)
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D53586567
fbshipit-source-id: d391ca56b23fc3dd57429c5ad8a7a405e97a81f2
Summary:
Changelog: [Internal]
Fixes a small omission in D53756996 that will come into play in future diffs.
bypass-github-export-checks
Reviewed By: robhogan
Differential Revision: D53771004
fbshipit-source-id: 4c94db37ef51793420e126a81c5d6c0543493ec7
Summary:
Changelog: [Internal]
Along with all the places using it like the `_debugSource` on Fiber.
This still lets them be passed into `createElement` (and JSX dev
runtime) since those can still be used in existing already compiled code
and we don't want that to start spreading to DOM attributes.
We used to have a DEV mode that compiles the source location of JSX into
the compiled output. This was nice because we could get the actual call
site of the JSX (instead of just somewhere in the component). It had a
bunch of issues though:
- It only works with JSX.
- The way this source location is compiled is different in all the
pipelines along the way. It relies on this transform being first and the
source location we want to extract but it doesn't get preserved along
source maps and don't have a way to be connected to the source hosted by
the source maps. Ideally it should just use the mechanism other source
maps use.
- Since it's expensive it only works in DEV so if it's used for
component stacks it would vary between dev and prod.
- It only captures the callsite of the JSX and not the stack between the
component and that callsite. In the happy case it's in the component but
not always.
Instead, we have another zero-cost trick to extract the call site of
each component lazily only if it's needed. This ensures that component
stacks are the same in DEV and PROD. At the cost of worse line number
information.
The better way to get the JSX call site would be to get it from `new
Error()` or `console.createTask()` inside the JSX runtime which can
capture the whole stack in a consistent way with other source mappings.
We might explore that in the future.
This removes source location info from React DevTools and React Native
Inspector. The "jump to source code" feature or inspection can be made
lazy instead by invoking the lazy component stack frame generation. That
way it can be made to work in prod too. The filtering based on file path
is a bit trickier.
When redesigned this UI should ideally also account for more than one
stack frame.
With this change the DEV only Babel transforms are effectively
deprecated since they're not necessary for anything.
DiffTrain build for commit https://github.com/facebook/react/commit/37d901e2b81e12d40df7012c6f8681b8272d2555.
Reviewed By: kassens
Differential Revision: D53543159
Pulled By: tyao1
fbshipit-source-id: 8e5509a16ea8d3234881e2305149326fb31e3845
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43012
Changelog: [iOS][Added]
This implements the functionality to give access to the jsi::Runtime in iOS in bridgeless. In bridge, this value is a private selector on RCTBridge that is exposed via category. We build this into the backwards compatible RCTBridgeProxy here.
This should work out of the box in bridgeless if you are already retrieveing the pointer via the bridge. However, we recommend users to eventually migrate towards C++ TurboModule or the RuntimeExecutor if possible. This will be removed in the future.
Reviewed By: RSNara
Differential Revision: D53646413
fbshipit-source-id: a5584f22d433a580d537b8780a3bcd503680acb8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43013
Changelog: [Android][Added]
This is a pre-deprecated API to give access to the jsi::Runtime in Android in bridgeless. In bridge, this value is exposed via the ReactContext, but is not implemented in the BridgelessReactContext. We do that here.
This should work out of the box in bridgeless if you are already retrieveing the pointer via ReactContext. However, we recommend users to eventually migrate towards C++ TurboModule or the RuntimeExecutor if possible. This will be removed in the future.
Reviewed By: RSNara
Differential Revision: D53645247
fbshipit-source-id: b98657560c43a625bdf947d19d186952c9b44364
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43035
Changelog: [Internal] - We early-exited because of poor copy-pasta and the fact that our tests don't properly emulate the behavior of mock `exit`
Will try and clean this up in next diff but want to quickly fix so it unbreaks nightlies
Reviewed By: yungsters
Differential Revision: D53779109
fbshipit-source-id: ff56e498344fcb4851729d98625b6c7010c73795
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43027
Changelog: [Internal]
Adds a test suite for the integration between the modern RN CDP backend and Hermes (plus potentially other JS engines), mocking out the rest of RN.
For simplicity, everything is single-threaded and "async" work is actually done through a queued immediate executor ( = run immediately and finish all queued sub-tasks before returning).
The main limitation of the simpler threading model is that we can't cover breakpoints etc - since pausing during JS execution would prevent the test from making progress. Such functionality is better suited for a full RN+CDP integration test (using RN's own thread management) as well as for each engine's unit tests.
## Types of tests in this diff
* `TEST_F(JsiIntegrationHermesTest, ...)` - tests specific to the Hermes integration.
* `TYPED_TEST(JsiIntegrationPortableTest, ...)` - tests that should pass on all engines.
* These use gtest's [typed tests](https://google.github.io/googletest/advanced.html#typed-tests) feature.
* This is a good fit for testing CDP features that have no strict dependency on Hermes (like the upcoming `Runtime.addBinding` support). **Long term**, aspirationally, all tests should be in this category, covering a consistent baseline of CDP features needed for debugging with any supported engine.
* The first "non-Hermes" engine we test against (`GenericEngineAdapter`) is actually Hermes in disguise, minus any Hermes-specific CDP handling. We could conceivably add more engines here, as long as we have the ability to build them (and their JSI bindings) as part of building the tests.
bypass-github-export-checks
Reviewed By: huntie
Differential Revision: D53756996
fbshipit-source-id: fbafb088abd4263ec841bf848185637ec126c6d1
Summary:
Changelog: [Internal]
Update tests to be more resilient against prod changes; and make it easier to read the actual vs expected values upon failure.
Reviewed By: motiz88
Differential Revision: D53762409
fbshipit-source-id: d627d5041295f645ed00aa5d0645419a9ac4a7f8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42687
Changelog: [Internal]
adding an example for if you want to use `getInitialNotification`.
Reviewed By: ingridwang
Differential Revision: D52931618
fbshipit-source-id: 7552c358e5bc98228b7ae74ea1adf450f7b075e6
Summary:
Changelog: [Internal]
I'm updating this API to match the semantics of the other new APIs, namely that they're static methods that don't depend on the instance of the native module. This should help streamline our documentation. Instead of capturing the launch notification as an ivar, we capture it in a static variable that we clear out when the object gets cleared or is invalidated, which is similar to an ivar / property.
Reviewed By: ingridwang
Differential Revision: D53743761
fbshipit-source-id: b6ff048ef8d653e8f4be19194a2211792a542252
Summary:
Changelog: [Internal]
In the past, local notifications were stored in the launch options as UILocalNotification, whereas remote notifications were stored as NSDict. This means that we had different handling in PushNotificationIOS.js. This condition was not handling the differences in local and remote notifications that JS expected, which I'm fixing here.
Reviewed By: ingridwang
Differential Revision: D53734086
fbshipit-source-id: 73ef436a232c16de3b72f7236db94012aafdc434
Summary:
Changelog: [Internal]
Required for landing D53543159.
2 reasons for landing this:
1. Inspector is technically deprecated and will be removed once React DevTools are shipped with Chrome DevTools for RN debugging.
2. Long-term solution for source fetching is lazy loading based on component stacks - https://github.com/facebook/react/pull/28265
Reviewed By: kassens
Differential Revision: D53757524
fbshipit-source-id: cbb2aab79ba40ea66da5c1ddde95d3fe374b6006
Summary:
Changelog: [Internal]
Replaces the copypasta'd `PageTarget::forEachSession`, `InstanceTarget::forEachAgent` and `RuntimeTarget::forEachAgent` with a shared utility class for managing a list of `weak_ptr`s.
In a `WeakList`, elements can only be added (`insert`), iterated over (`forEach`), and counted (`size`, `empty`). Conceptually, elements are automatically removed from the list as soon as they're destroyed, but internally, space is reclaimed *lazily*: the next time we have a reason to iterate over the underlying list, we delete any pointers that are found to be null.
## Naming
This is almost a WeakSet, but we don't bother checking for duplicates, hence "WeakList".
Reviewed By: hoxyq
Differential Revision: D53671483
fbshipit-source-id: 460bfbaa2b8e821281dc352fed0946f99352c9fc
Summary:
Changelog: [Internal]
# This diff
1. Provides all Targets with an `executorFromThis()` method, which can be used from within a Target to access a *`this`-scoped main thread executor* = a `std::function` that will execute a callback asynchronously iff the current Target isn't destroyed first.
2. Refactors how (all) Target objects are constructed and retained, from a plain constructor to `static shared_ptr create()`. This is because `executorFromThis()` relies internally on `enable_shared_from_this` plus two-phase construction to populate the executor.
3. Creates utilities for deriving scoped executors from other executors and `shared_ptr`s.
The concept is very much like `RuntimeExecutor` in reverse: the #1 use case is moving from the JS thread back to the main thread - where "main thread" is defined loosely as "anywhere it's legal to call methods on Target/Agent objects, access session state, etc". The actual dispatching mechanism is left up to the owner of each `PageTarget` object; for now we only have an iOS integration, where we use `RCTExecuteOnMainQueue`.
Coupling the ownership/lifetime semantics with task scheduling is helpful, because it avoids the footgun of accidentally/nondeterministically moving `shared_ptr`s (and destructors!) to a different thread/queue .
# This stack
I'm refactoring the way the Runtime concept works in the modern CDP backend to bring it in line with the Page/Instance concepts.
Overall, this will let us:
* Integrate with engines that require us to instantiate a shared Target-like object (e.g. Hermes AsyncDebuggingAPI) in addition to an per-session Agent-like object.
* Access JSI in a CDP context (both at target setup/teardown time and during a CDP session) to implement our own engine-agnostic functionality (`console` interception, `Runtime.addBinding`, etc).
* Manage CDP execution contexts natively in RN, and (down the line) enable first-class debugging support for multiple Runtimes in an Instance.
The core diffs in this stack:
* ~~Introduce a `RuntimeTarget` class similar to `{Page,Instance}Target`. ~~
* ~~Make runtime registration explicit (`InstanceTarget::registerRuntime` similar to `PageTarget::registerInstance`). ~~
* ~~Rename the existing `RuntimeAgent` interface to `RuntimeAgentDelegate`.~~
* ~~Create a new concrete `RuntimeAgent` class similar to `{Page,Instance}Agent`.~~
* ~~Provide `RuntimeTarget` and `RuntimeAgent` with primitives for safe JSI access, namely a `RuntimeExecutor` for scheduling work on the JS thread.~~
* Provide RuntimeTarget with mechanism for scheduling work on the "main" thread from the JS thread, for when we need to do more than just send a CDP message (which we can already do with the thread-safe `FrontendChannel`) in response to a JS event. *← This diff*
## Architecture diagrams
Before this stack:
https://pxl.cl/4h7m0
After this stack:
https://pxl.cl/4h7m7
Reviewed By: hoxyq
Differential Revision: D53356953
fbshipit-source-id: 152c784eb64e9b217fc2966743b33f61bd8fd97e
Summary:
Changelog: [Internal]
I'm refactoring the way the Runtime concept works in the modern CDP backend to bring it in line with the Page/Instance concepts.
Overall, this will let us:
* Integrate with engines that require us to instantiate a shared Target-like object (e.g. Hermes AsyncDebuggingAPI) in addition to an per-session Agent-like object.
* Access JSI in a CDP context (both at target setup/teardown time and during a CDP session) to implement our own engine-agnostic functionality (`console` interception, `Runtime.addBinding`, etc).
* Manage CDP execution contexts natively in RN, and (down the line) enable first-class debugging support for multiple Runtimes in an Instance.
The core diffs in this stack will:
* ~~Introduce a `RuntimeTarget` class similar to `{Page,Instance}Target`. ~~
* ~~Make runtime registration explicit (`InstanceTarget::registerRuntime` similar to `PageTarget::registerInstance`). ~~
* ~~Rename the existing `RuntimeAgent` interface to `RuntimeAgentDelegate`.~~
* ~~Create a new concrete `RuntimeAgent` class similar to `{Page,Instance}Agent`.~~
* Provide `RuntimeTarget` and `RuntimeAgent` with primitives for safe JSI access, namely a `RuntimeExecutor` for scheduling work on the JS thread. *← This diff*
* We'll likely develop a similar mechanism for scheduling work on the "main" thread from the JS thread, for when we need to do more than just send a CDP message (which we can already do with the thread-safe `FrontendChannel`) in response to a JS event.
## Architecture diagrams
Before this stack:
https://pxl.cl/4h7m0
After this stack:
https://pxl.cl/4h7m7
Reviewed By: hoxyq
Differential Revision: D53266710
fbshipit-source-id: df3a181fcc8e033c37a7f4f430f23a29b326b56a
Summary:
Changelog: [Internal]
Fixed double-encoding for the websocket url.
`URLSearchParams` already encode the values, passing a pre-encoded `encodeUriComponent` string will cause it to double-encode, making the value unreadable when decoding once.
Missed these lines while splitting the initial diff stack.
Added tests now.
Reviewed By: motiz88
Differential Revision: D53721568
fbshipit-source-id: cfaaa7eb50c40364c904e9ffc5698201df8ab22b
Summary:
Changelog: [Internal]
Applies to RuntimeTarget → RuntimeAgent the same pattern we use for InstanceTarget → InstanceAgent (D53266708) and PageTarget → PageTargetSession: the target has `weak_ptr`s to its agents/sessions so it can (1) dispatch events to them and (2) assert that they are destroyed before the target itself is destroyed.
In RuntimeTarget this will primarily serve as an event dispatching mechanism from JS (single target) to CDP (multiple sessions), with the addition of threading abstractions in upcoming diffs.
Reviewed By: hoxyq
Differential Revision: D53266706
fbshipit-source-id: 64d7226a1aebf00e0ad178f28101a568e9bc6c53
Summary:
This is a resubmission of D53266707 with a fix in the OSS version of `HermesExecutorFactory` (it was incorrectly referencing `HermesRuntimeAgent.h` which doesn't exist anymore). The original diff summary follows.
---
Changelog: [Internal]
I'm refactoring the way the Runtime concept works in the modern CDP backend to bring it in line with the Page/Instance concepts.
Overall, this will let us:
* Integrate with engines that require us to instantiate a shared Target-like object (e.g. Hermes AsyncDebuggingAPI) in addition to an per-session Agent-like object.
* Access JSI in a CDP context (both at target setup/teardown time and during a CDP session) to implement our own engine-agnostic functionality (`console` interception, `Runtime.addBinding`, etc).
* Manage CDP execution contexts natively in RN, and (down the line) enable first-class debugging support for multiple Runtimes in an Instance.
The core diffs in this stack will:
* ~~Introduce a `RuntimeTarget` class similar to `{Page,Instance}Target`.~~ (D53233914)
* ~~Make runtime registration explicit (`InstanceTarget::registerRuntime` similar to `PageTarget::registerInstance`).~~ (D53233914)
* Rename the existing `RuntimeAgent` interface to `RuntimeAgentDelegate`. *← This diff*
* Create a new concrete `RuntimeAgent` class similar to `{Page,Instance}Agent`. *← Also in this diff*
* Provide `RuntimeTarget` and `RuntimeAgent` with primitives for safe JSI access, namely a `RuntimeExecutor` for scheduling work on the JS thread.
* We'll likely develop a similar mechanism for scheduling work on the "main" thread from the JS thread, for when we need to do more than just send a CDP message (which we can already do with the thread-safe `FrontendChannel`) in response to a JS event.
## Architecture diagrams
Before this stack:
https://pxl.cl/4h7m0
After this stack:
https://pxl.cl/4h7m7
Reviewed By: EdmondChuiHW
Differential Revision: D53748590
fbshipit-source-id: bd0cf9f74b95abc52b4903f8a7afddcefa303d8a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42769
Changelog: [internal]
These APIs are not currently enabled in OSS, so moving the modules should be safe and not considered a breaking change.
Reviewed By: NickGerleman
Differential Revision: D53267565
fbshipit-source-id: edd3daa7c5043e44e5fd4b1af074093ed3ef4152
Summary:
The `.addUIBlock` and `.prependUIBlock` APIs on UiManagerModule are missing on Fabric.
Here I'm re-implementing them to make migration to Fabric easier.
Set of changes:
- Moved `NativeViewHierarchyManager` to `NativeViewHierarchyManagerImpl` and extracted an interface
- Moved `addUIBlock` and `prependUIBlock` to the shared `UIManager` interface
- Added a `InteropUIBlockListener` class that takes care of executing the UI Blocks, implemented as a `UIManagerListener`
Changelog:
[Android] [Changed] - Changed the API of addUIBlock and prependUIBlock to implement it also in Fabric.
Reviewed By: mdvacca
Differential Revision: D53612514
fbshipit-source-id: 1cddbc391477318064f15c733a380983c3737373
Summary:
Removes the OSS build logic I added in D53377527, to turn Android build green (target not yet used outside tests).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D53746020
fbshipit-source-id: 6e8a8e111a307b955b838c0522d3d0802e3865c3
Summary:
This one snuck in with new OSS buid failures after when we had another change cause a failure. Back it out, to get CI passing.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D53745683
fbshipit-source-id: f889bf7541e6f664053d5c0e4851cb448cdbb615
Summary:
Adds a sparse `CSSDeclaredStyle` structure to represent the collection of declarations from the user, before being further processed/computed. This will later be procssed into computed style.
Also fixes up some bad naming wrt specified value and declared value.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D53696422
fbshipit-source-id: 4258c86a29a0b2251c969b299b5b4703c06696db
Summary:
I originally marked most of this as constexpr, since the code around the variant, and parsing, were already header only and avoiding allocations, and was pretty leaf node.
`reinterpret_cast` and similar is not allowed under constexpr until C++ 26, which `CSSValue` was using. We change our method of storage to a recursively defined union, which is the same underlying implementation of `std::variant` (and is how it is constexpr).
`std::pow` is also not constexpr until C++ 26 which means we can't assign a CSSValue which tokenizes a decimal number... But... constexpr here is more a bonus, and not worth pulling in constexpr math library to do it.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D53696265
fbshipit-source-id: 01442ab9222b3f3ef8ccb01383648fb2e1f747dd
Summary: Didn't have a test for this before. Add one.
Reviewed By: joevilches
Differential Revision: D53537840
fbshipit-source-id: 30872e2dd5b4c35eab7ee66b6f6f322ff0b7735c
Summary:
1. Add "initial" values, and whether the prop should be inherited (currently only applies to direction).
2. Add some more border properties that we can replicate with the current data types we support, that are part of valid CSS. These are in ViewProps today instead of YogaStylableProps, but style computation can read both at once.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D53537101
fbshipit-source-id: cce926ba0caba0467493611e3000d1ba396de19e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42913
This structures properties into a `CSSProp` enum (so that we can have a runtime-key per style prop), associated with a `CSSPropDefinition` structure which groups the supported types and keywords. This has some niceness of removing the macro bits, but more importantly, means we can query parse related information without a field of the value yet existing (need for sparse storage of CSS values). In the future, it will serve as where we define "initial" values, and likely, the processes for interpolation and inheritance.
We restructure `CSSValueVariant` to not always support keywords, as it may not be a valid possibility for computed values (which do not have CSS wide keywords). Computed values themselves may also reduce more keywords than the global ones (e.g. border width computed value absolutizes keywords).
We also flesh out more of the prop definitions, and parsing. All the properties here relay back to YogaStylableProps of today, but I intentionally filled out the prop definitions a bit more than we do anything with right now (will design higher level to ignore unknown props).
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D53518450
fbshipit-source-id: 1b48ae2513a258d15c5e7fd16ef06f1b6be8dab2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42879
Adds support for parsing and storing a component value of the <ratio> CSS basic data type. This would allow removing `processAspectRatio` from viewconfigs later, which we would need for correct substitution of functions/expressions resulting in the ratio numerator/denominator.
This also fleshes out the parser a bit more, and does some renaming, and convention setting.
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D53457930
fbshipit-source-id: bed79e05978ed4152c865cdf90701dea779c8622
Summary:
This adds:
1. `CSSValueVariant`: A union-y type, mapping to a collection of CSS basic data types, and a set of allowed keywords. The aim here is to more closely model the data types after the CSS spec, to allow RN to store them correctly, while not taking up too much space. These types will form the foundation of Yoga prop storage (and probably some other props down the line), so compactness is a priority.
2. `parseCSSValue()`: This uses the previously added Tokenizer, along with parsing rules, to be able to parse a single component value, into a literal keyword, `<length>`, `<length-percentage>`, `<percentage>`, or `<number>`. This will be wired to the props parsing infrastructure.
See D53461299 for an example of what this will look like in props storage.
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D53342595
fbshipit-source-id: 3f00dfd7c0ead3dbef4605a61e9859cf69945fe5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42832
Various analogs to CSS types and utilities currently exist between `core` and `components/view`. These don't really belong well with either, so this adds a top-level "css" library, and moves `CSSTokenizer` there.
This is statically linked into Fabric binary on Android OSS.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D53377527
fbshipit-source-id: e2d3091ecb3533ecde4d0a08084369b4909532c3
Summary:
Changelog: [Internal]
I'm refactoring the way the Runtime concept works in the modern CDP backend to bring it in line with the Page/Instance concepts.
Overall, this will let us:
* Integrate with engines that require us to instantiate a shared Target-like object (e.g. Hermes AsyncDebuggingAPI) in addition to an per-session Agent-like object.
* Access JSI in a CDP context (both at target setup/teardown time and during a CDP session) to implement our own engine-agnostic functionality (`console` interception, `Runtime.addBinding`, etc).
* Manage CDP execution contexts natively in RN, and (down the line) enable first-class debugging support for multiple Runtimes in an Instance.
The core diffs in this stack will:
* ~~Introduce a `RuntimeTarget` class similar to `{Page,Instance}Target`.~~ (D53233914)
* ~~Make runtime registration explicit (`InstanceTarget::registerRuntime` similar to `PageTarget::registerInstance`).~~ (D53233914)
* Rename the existing `RuntimeAgent` interface to `RuntimeAgentDelegate`. *← This diff*
* Create a new concrete `RuntimeAgent` class similar to `{Page,Instance}Agent`. *← Also in this diff*
* Provide `RuntimeTarget` and `RuntimeAgent` with primitives for safe JSI access, namely a `RuntimeExecutor` for scheduling work on the JS thread.
* We'll likely develop a similar mechanism for scheduling work on the "main" thread from the JS thread, for when we need to do more than just send a CDP message (which we can already do with the thread-safe `FrontendChannel`) in response to a JS event.
## Architecture diagrams
Before this stack:
https://pxl.cl/4h7m0
After this stack:
https://pxl.cl/4h7m7
Reviewed By: hoxyq
Differential Revision: D53266707
fbshipit-source-id: e14867931d10e1739e6dab6dbd7d3386c685c3c2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42432
Changelog: [internal]
This feature flag is accessed through `CoreFeatures` but it's initialized a few different ways:
* Android: assigned via `ReactFeatureFlags`, which is overridden by apps.
* iOS: `ReactNativeConfig` that's mapped to a dynamic configuration.
This migrates the flag to the new feature flag system.
Reviewed By: mdvacca, RSNara
Differential Revision: D52810065
fbshipit-source-id: d6fd1e819abbc4c3dee9e6221d8f99384f5197f5
Summary:
Changelog: [Internal] - `get-and-update-packages` was deleted in D53487874 also actually published the monorepo packages.
Update publish-npm to publish the updated nightly monorepo packages
Reviewed By: cipolleschi
Differential Revision: D53697621
fbshipit-source-id: 21facb49739ba64c43b921117356715be3d8868a
Summary:
Autolinking local app fabric component requires user to manipulate the C++ code.
This removes this requirement by generating the code necessary to register all the discovered Fabric Components.
I've updated the RN-Tester Android setup to use this mechanism also.
Changelog:
[Android] [Fixed] - Fix autolinking for local app Fabric components
Reviewed By: cipolleschi
Differential Revision: D53710676
fbshipit-source-id: 667af4bcf7fa99563081330aa64d072faf50863b
Summary:
The recent change to make onDismiss work on Fabric broke the Modal on Paper (see [this comment](https://www.internalfb.com/diff/D52959996?dst_version_fbid=236415652884499&transaction_fbid=896066412296150)).
This change will fix that behavior.
The problem was that we were resetting the `isRendered` state only when the Modal receives the event from the Event emitter AND if it has the `onDismiss` callback set.
However, we should hide the component in any case if the ids match, and invoke the onDismiss if it is set.
## Changelog
[iOS][Fixed] - Make sure that Modal is dismissed correctly in Paper
Reviewed By: janeli-100005636499545
Differential Revision: D53686165
fbshipit-source-id: a1de0b29dca7c099e9fa0282ec80cae9a8fd6bc3
Summary:
RNGP now supports parsing the cxxModule field in codegenConfig and passes it over to codegen.
Changelog:
[Internal] [Changed] - Update RNGP to handle cxxModule in codegenConfig
Reviewed By: cipolleschi
Differential Revision: D53669912
fbshipit-source-id: 702f09ccf793f9205f0c8b54346c5d809695c35d
Summary:
This introduces the `cxxModule` field for RNTester where the local TM-CXX modules
are specified.
Changelog:
[Internal] [Changed] - Add cxxModule to RN-Tester's codegenConfig
Reviewed By: cipolleschi
Differential Revision: D53669913
fbshipit-source-id: 97b9985b94efe79566d2d06f6081e65fb66478ff
Summary:
Changelog: [Internal]
`getInitialNotification` only expect the user info dictionary of the dictionary, not the complete formatted notification.
Reviewed By: cipolleschi
Differential Revision: D53691569
fbshipit-source-id: 9a24629d2e50544c55ea5cd16097bd88dad950ec
Summary:
Changelog: [Internal]
In D53233914 we copied PageTarget's approach for keeping track of its sessions into InstanceTarget (for keeping track of InstanceAgents). Here we complete that pattern by asserting that the agents are destroyed before their respective targets.
NOTE: We might want to encapsulate this pattern in a helper/template class at some point. For now I'm going with the explicit approach.
Reviewed By: hoxyq
Differential Revision: D53266708
fbshipit-source-id: 4a90fde6c68e87d4667c44f81f8578a7a9072474
Summary:
Changelog: [Internal]
I'm refactoring the way the Runtime concept works in the modern CDP backend to bring it in line with the Page/Instance concepts.
Overall, this will let us:
* Integrate with engines that require us to instantiate a shared Target-like object (e.g. Hermes AsyncDebuggingAPI) in addition to an per-session Agent-like object.
* Access JSI in a CDP context (both at target setup/teardown time and during a CDP session) to implement our own engine-agnostic functionality (`console` interception, `Runtime.addBinding`, etc).
* Manage CDP execution contexts natively in RN, and (down the line) enable first-class debugging support for multiple Runtimes in an Instance.
The core diffs in this stack will:
* Introduce a `RuntimeTarget` class similar to `{Page,Instance}Target`. *← This diff*
* Make runtime registration explicit (`InstanceTarget::registerRuntime` similar to `PageTarget::registerInstance`). *← Also in this diff*
* Rename the existing `RuntimeAgent` interface to `RuntimeAgentDelegate`.
* Create a new concrete `RuntimeAgent` class similar to `{Page,Instance}Agent`.
* Provide `RuntimeTarget` and `RuntimeAgent` with primitives for safe JSI access, namely a `RuntimeExecutor` for scheduling work on the JS thread.
* We'll likely develop a similar mechanism for scheduling work on the "main" thread from the JS thread, for when we need to do more than just send a CDP message (which we can already do with the thread-safe `FrontendChannel`) in response to a JS event.
## Architecture diagrams
Before this stack:
https://pxl.cl/4h7m0
After this stack:
https://pxl.cl/4h7m7
Reviewed By: hoxyq
Differential Revision: D53233914
fbshipit-source-id: 166ae3e25059bd9c9c051a0a3312a3ba78a3935a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42923
This Diff implement the logic to:
- Read some lists of class names provided by libraries that conforms to some protocols we defined as extension points.
- Generate a provider in the React-Codegen podspec, whose code lives alongside the app code.
- Glue the app and the generated code together, allowing to link custom protocols
## Changelog
[iOS][Added] - Allow libraries to provide module which conforms to protocols meant to be extension points.
Reviewed By: RSNara
Differential Revision: D53441411
fbshipit-source-id: f53bc6ea0417e6122d8918df2614bcb9937a515a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42962
Autolinking local app fabric component requires user to manipulate the C++ code.
This removes this requirement by generating the code necessary to register all the discovered Fabric Components.
I've updated the RN-Tester Android setup to use this mechanism also.
Changelog:
[Android] [Fixed] - Fix autolinking for local app Fabric components
Reviewed By: RSNara
Differential Revision: D53661231
fbshipit-source-id: 28c376fbd08c326f117f8d420485d63e2b4b1241
Summary:
Those files are stale from Buck OSS. I'm removing them.
I'm also updating the RN-Tester instructions to be up-to-date.
## Changelog:
[INTERNAL] - Cleanup BUCK artifacts
Pull Request resolved: https://github.com/facebook/react-native/pull/42990
Test Plan: Nothing to test
Reviewed By: NickGerleman
Differential Revision: D53705337
Pulled By: cortinico
fbshipit-source-id: 685fc346870c5f123660cb5af2e30fb64842127a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42812
There is a way of defining events where you specify additional string type parameter in the EventHandler in the spec. This additional type parameter is an overridden top level event name, that can be completely unrelated to the event handler name.
More context here D16042065.
Let's say we have
```
onLegacyStyleEvent?: ?BubblingEventHandler<LegacyStyleEvent, 'alternativeLegacyName'>
```
This will produce the following entry in the view config:
```
topAlternativeLegacyName: {
phasedRegistrationNames: {
captured: 'onLegacyStyleEventCapture',
bubbled: 'onLegacyStyleEvent'
}
}
```
This means that React expects `topAlternativeLegacyName`.
But the generated EventEmitter looks like this:
```
void RNTMyNativeViewEventEmitter::onLegacyStyleEvent(OnLegacyStyleEvent $event) const {
dispatchEvent("legacyStyleEvent", [$event=std::move($event)](jsi::Runtime &runtime) {
auto $payload = jsi::Object(runtime);
$payload.setProperty(runtime, "string", $event.string);
return $payload;
});
}
```
The native component will emit `legacyStyleEvent` (`topLegacyStyleEvent` after normalization) that React will not be able to handle.
This issue only happens on iOS because Android doesn't use EventEmitter currently.
To address this issue we'll use `paperTopLevelNameDeprecated` for the generated EventEmitters if it is defined.
Changelog: [iOS][Fixed] - Fixed support for event name override in component specs.
Reviewed By: cortinico, mdvacca, cipolleschi
Differential Revision: D53310654
fbshipit-source-id: 018d5b11d8d36e2ecf900b9d8d6fe3e2ed71f80b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42809
This diff adds a legacy style event to `MyNativeViewNativeComponent`.
This is a way of defining events where you specify additional string type parameter in the EventHandler in the spec. This additional type parameter is an overridden top level event name, that can be completely unrelated to the event handler name.
In this example it is `onLegacyStyleEvent` and `alternativeLegacyName`.
More context here D16042065.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D53310318
fbshipit-source-id: 4dec08c872acdfd09b9939f690fb7bc777149580
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42665
- Replace the internals of `InspectorFlags` to use the new `ReactNativeFeatureFlags` setup.
- Remove call sites to `InspectorFlags::initFromConfig`.
After this diff, all `InspectorFlags` are configured from `ReactNativeFeatureFlags.json`.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D53049790
fbshipit-source-id: 90c2b128a9c316546c3f8f8f88e2c08a9f55ae72
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42642
Removes call to `InspectorFlags::initFromConfig`, since this approach is being replaced with `ReactNativeFeatureFlags`. This change is separated out as it originally made a public API deprecation.
Changelog:
[iOS][Deprecated] - **Un-deprecates** `RCTAppSetupPrepareApp` (reverts #41976)
Reviewed By: motiz88
Differential Revision: D53048207
fbshipit-source-id: 8624020f1e9e19f9f1ee75af9b177e922e36c5d9
Summary:
CI is broken. Let's not bother attempting to fixing it as it's attempting to call `envinfo` on Windows
which no one really looks into.
Also the maintainer is unresponsive: https://github.com/tabrindle/envinfo/issues/238
Changelog:
[Internal] [Changed] - Do not invoke envinfo on windows
Reviewed By: cipolleschi
Differential Revision: D53698194
fbshipit-source-id: db90ae6e773cf0a2f72ca1fc2d5faa3f56ed2edc
Summary:
Changelog: [Internal] - We still use the `dry-run` build variant in template tests on CircleCI
Previous diff migrated `set-rn-version` to `set-version` for dry-run, prealpha, and nightly build types. I didn't realize that template test flow used `dry-run` builds. I thought it was just for commitlies (which are deprecated).
To properly migrate this site, I need to fix the template test flow to accept monorepo packages at the same version as the dry-run react-native version (1000-<commithash>)
For now, let's just make this change more precise, and only update the nightly flow
See this error: {F1455663616}
Template test flow doesn't fake publish the monorepo packages at this version -- they're still using the versions off of main
Reviewed By: mdvacca
Differential Revision: D53688238
fbshipit-source-id: 6b64baca7eac842f2207fe13a3046b18459228da
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42958
Changelog: [Internal] - Add support to `set-version` that we can bump the monorepo packages on main
This should be used after we cut a release branch. The release crew should then run
`yarn set-version 0.next.0-main --skip-react-native-version`
This makes sure we don't update `react-native` on main branch and keep it at 1000.0.0
This essentially replaces:
`yarn bump-all-updated-packages --release-branch-cutoff`
in this step: https://reactnative.dev/contributing/release-branch-cut-and-rc0#12-bump-minor-version-of-all-monorepo-packages-in-main
The reason for this change is to consolidate all the places where we update the version to one place, set-version.
Currently we do this in many fragmented places
* bump-all-updated-packages
* set-rn-version
* get-and-update-packages (deleted in the prev diff)
In the future, I want to get rid of `skip-react-native-version` but we'll need to remove the `1000.0.0` nomenclature. This unblocks us to just use this script for now.
bypass-github-export-checks
Reviewed By: huntie
Differential Revision: D53648688
fbshipit-source-id: 4f76366f8d340ec5aeaba1d3a26eba8b18a0166c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42903
Changelog: [Internal] - Update publish-npm to use `set-version` for nightly builds
Now that `set-version` basically does what `set-rn-version` does, this diff uses this logic for nightlies only (as dry-run/pre-alpha variants are non-functional right now)
This does not change the flow of build-type `'release'` -- that will still use `set-rn-version` via CircleCI ([job](https://fburl.com/code/6xo3ijwg), [script](https://fburl.com/code/bo8np0tb)) We will eventually replace that too but that will be later.
This allows us to delete `get-and-update-packages.js` which was a helper written specifically for updating monorepo packages for nightlies.
The purpose of this is to eventually conform all version updates to use `set-version` in all types of releases (nightlies, stable)
bypass-github-export-checks
Reviewed By: cipolleschi
Differential Revision: D53487874
fbshipit-source-id: 734b528ef5bd095ac68f86701ae105daa30c7d68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42964
We've seen npm publishes fail occasionally in CI as part of this script, most recently in S391653. This change adds a single retry, per package, during the execution of this script, in an attempt to reduce the chance of manual interventions after a broken pipeline.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D53607808
fbshipit-source-id: 526d9c33d51ec57702efba3c199bad313c1bf2d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42944
Updates `find-and-publish-all-bumped-packages` to use the npm registry as the source of truth, similar to tools like Lerna (`lerna publish from-package`). **This enables safe reruns of the publish script**, and replaces the previous Git-diff-detection implementation.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D53607807
fbshipit-source-id: 135808b7ce36cf463c9f53a8059500b83f8b6679
Summary:
This adds `react-native/metro-config` to the monorepo build tool and emits the missing typescript declarations.
Right now, we do have typescript declarations on `metro-config`, but not `react-native/metro-config`. Which makes everything a bit harder extend from "[the default React Native metro config](https://github.com/facebook/react-native/pull/36502)" in Expo.
> Note, I also added the same `exports` block from `react-native/dev-middleware` for conformity.
One open question here is, why aren't we exporting _all_ helper functions from `metro-config`? To me, its a bit weird that we need both `metro-config` _and_ `react-native/metro-config` as `loadConfig` isn't exported.
## Changelog:
[INTERNAL] [FIXED] - Emit typescript declaration files for `react-native/metro-config`
Pull Request resolved: https://github.com/facebook/react-native/pull/41836
Test Plan:
Run the build tool, and check if the typescript declarations are emitted for `react-native/metro-config`.
```
yarn build metro-config
```
Reviewed By: hoxyq
Differential Revision: D51943453
Pulled By: huntie
fbshipit-source-id: cfaffe5660053fc9a9fcbe3dacf7f6ccc2bde01b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42948
Changelog: [Internal]
Refactor URL construction for DevTools.
Next diffs in the stack will add additional URL query params.
Support for both absolute and relative `devServerUrl`s maintained.
Reviewed By: hoxyq
Differential Revision: D53620915
fbshipit-source-id: 4a64c49c3479ede2add9f39a24448787d8609172
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42858
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: cortinico, rshest
Differential Revision: D53393471
fbshipit-source-id: 3f896f7d7c51f276a3f743d39dc851cb47ca538a
Summary:
In setups with `pnpm` `react-native/virtualized-lists` gets bundled incorrectly because of the following error:
`Module not found: Error: Can't resolve 'react'`
As 'react' is used inside of the package, it should declared explicitly, instead of being a phantom dependency.
## Changelog:
[GENERAL] [FIXED] - Declare missing peer dependency `react`
Pull Request resolved: https://github.com/facebook/react-native/pull/42947
Test Plan: not needed
Reviewed By: NickGerleman
Differential Revision: D53617462
Pulled By: cortinico
fbshipit-source-id: 19a8fed94263646b0af93339d5c014e629dfa6b1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42956
In the component codegen system, when the header prefix is an empty string, we generate includes using angle brackets, like this:
```
#include <EventEmitter.h>
```
This fails to compile in buck.
If we instead generate includes using quotations, buck compiles again.
```
#include "EventEmitter.h"
```
So, changes: if the headerPrefix is an empty string, generate includes using quotes.
This is a followup to D51811596.
Changelog: [Internal]
Reviewed By: fkgozali, dmytrorykun
Differential Revision: D53487111
fbshipit-source-id: e90a8b9fd4f8a2a93a0f4ad0ed989af26ad122c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42897
Changelog: [Internal] - Update nightly flow to use set-version
This change fixes `set-version` to update the `packages/react-native` native source and build files (as `set-rn-version` does) -- this was an oversight but not an issue as `set-version` isn't actually used anywhere right now.
Reviewed By: huntie
Differential Revision: D53463414
fbshipit-source-id: d0d9e4bbe246cccb8643a6ebf9794122bc343433
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42927
This bumps Kotlin to 1.9.22 which is the latest in OSS and closer to the version we use inside fbsource.
Turns out that Explicit API mode was not enabled correctly, so I had to go over all the Kotlin classes
and correctly set them to `public` if they were intended to be for public consumption.
I updated some of them to `private` or `internal` but otherwise I've defaulted to `public` which is the default
we have right now.
Changelog:
[Android] [Changed] - Kotlin to 1.9.22
Reviewed By: cipolleschi
Differential Revision: D53576844
fbshipit-source-id: dd8b08ce9bf87f738159f60fd850e3e3bc490ebc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42942
Instance derives from jsinspector_modern::InstanceTargetDelegate, which defines a virtual destructor, but Instance does not mark its destructor with override.
## Changelog [Internal]
Reviewed By: cipolleschi
Differential Revision: D53609922
fbshipit-source-id: b30df7d59478fa72b53ddc2eeb04c291a6f5f9eb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42940
We might have some libraries that goes through the interop layer that are using [RCTBridge currentBridge]. Although this is an API that we would like them not to use, that's the sad reality and if we don't want to force a migration on those libraries, we need to be backward compatible.
This diff sets the `RCTBridgeProxy` as the `currentBridge` in case the app is running in BridgelessMode. This should make Bridgeless backward compatible.
## Changelog
[iOS][Fixed] - Make [RCTBridge currentBridge] work in bridgeless mode
Reviewed By: RSNara
Differential Revision: D53575361
fbshipit-source-id: 179e440662b577954a577e8400e0ce0dc5b4d3ff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42922
changelog: [fix][ios] prevent unwanted border animation
The problem: CALayer and its properties are animatable. If RN applies mutations inside an animation block, it will animate. In this particular example, it was animated because of a transition applied by the library and because we were not creating new views, but recycling views from previous screen.
This caused size of _borderLayer to change from value A to value B inside of animation block. To resolve this, call removeAllAnimations on borderLayer.
Reviewed By: cipolleschi
Differential Revision: D53566886
fbshipit-source-id: 98e0b01a9185046e1ee500665c1832060ecc8884
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42882
Changelog: [Android][Added] - introduce native api to access RuntimeExecutor
This is the android equivalent of [PR#42758](https://github.com/facebook/react-native/pull/42758).
From [PR#42758](https://github.com/facebook/react-native/pull/42758)
> The goal of this API is to provide a safe way to access the jsi::runtime in bridgeless mode. The decision to limit access to the runtime in bridgeless was a conscious one - the runtime pointer is not thread-safe and its lifecycle must be managed correctly by owners.
> However, interacting with the runtime is an advanced use case we would want to support. Our recommended ways to access the runtime in bridgeless mode is either 1) via the RuntimeExecutor, or 2) via a C++ TurboModule.
This diff introduces the API that would allow for 1). because react context can be non-null before react instance is ready, this can still return null. however, the callsite should be cognizant of when this will happen. in the case of expomodules, the runtime should be ready when the module is init, unless it is a eager initialized module
Reviewed By: RSNara
Differential Revision: D53461821
fbshipit-source-id: 69555d0593a59f8655e4dcd2f0ef1f78f4cfff7d
Summary:
Opening the VisionOS fork crashes `tsserver.js` inside VSCode because of some Pods files. This stops `tsserver` from looking at any files inside Pods
[Link to issue](https://github.com/callstack/react-native-visionos/issues/97)
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[GENERAL] [ADDED] - Added a folder inside the `exclude` array inside `tsconfig`
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/42909
Reviewed By: lunaleaps
Differential Revision: D53518533
Pulled By: cipolleschi
fbshipit-source-id: 8d7819ec3ae8f0b413389157a34f49961434037f
Summary: blocks don't capture C++ objects so this will would crash
Reviewed By: sammy-SC, cipolleschi
Differential Revision: D53572123
fbshipit-source-id: 323f29c30d99616080aef6b0a895df4599788395
Summary:
This PR adds check if there are any supported platforms to log.
For built-in modules this was logging empty line (as some of them doesn't contain podspecs):

## Changelog:
[GENERAL] [FIXED] - Log Codegen supported platforms if any are available
Pull Request resolved: https://github.com/facebook/react-native/pull/42819
Test Plan: Run Codegen and check if it prints empty `Supported Apple platforms`
Reviewed By: cortinico
Differential Revision: D53566301
Pulled By: cipolleschi
fbshipit-source-id: 3f6b6d3b44da1ab7174432a5fac7f7d3fde11103
Summary:
CircleCI is failing because chocolatey started asking for user input in CI. This change should allow CI to proceed.
## Changelog:
[Internal] - Fix CI on Windows
Pull Request resolved: https://github.com/facebook/react-native/pull/42926
Test Plan: CircleCI is green
Reviewed By: cortinico
Differential Revision: D53576331
Pulled By: cipolleschi
fbshipit-source-id: 990a195618140263001ffce3e5c17240cc679aa7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42921
I realized that we were missing a bit to properly link app modules on Android.
The `_ModuleProvider` was never linked correctly so the TM won't be loaded at all.
With this change I'm getting the App Target (say `AppModule`) and passing it down to the
default-app-setup with a couple of macros.
This makes sure that if there is a codegen local module, we import the correct header and query the `AppModule_ModuleProvider` correctly.
Changelog:
[Android] [Fixed] - Fix linking of local app modules turbomodules
Reviewed By: cipolleschi
Differential Revision: D53567201
fbshipit-source-id: d14e61b7f2d86f15363600cd9dd1ed1ca27bd1fc
Summary:
This PR adds nullable annotations to `RCTBundleURLProvider` also allowing to return optional (the default that will be returned when metro is not running). Not having this may lead to crashes because Swift will try to unwrap optional with nil when metro is not running.
## Changelog:
[iOS] [Added] - add nullable annotations to RCTBundleURLProvider
Pull Request resolved: https://github.com/facebook/react-native/pull/42293
Test Plan: CI Green
Reviewed By: sammy-SC
Differential Revision: D52797676
Pulled By: cipolleschi
fbshipit-source-id: 98b4f99aa71828f5397276d22f35d24e48657dc8
Summary:
This PR migrates from the deprecated way of retrieving the status bar info. It introduces a helper method `RCTUIStatusBarManager` which gets the `UIStatusBarManager` from the KeyWindow.
It also removes the unused `getHeight` method.
## Changelog:
[IOS] [ADDED] - Add `RCTUIStatusBarManager` and properly retrieve StatusBar style and height
[IOS] [REMOVED] - Remove unused getHeight method from StatusBar
Pull Request resolved: https://github.com/facebook/react-native/pull/42241
Test Plan: CI Green, Ensure that preferredStatusBarStyle and preferredStatusBarHidden is properly retrieved for Modals
Reviewed By: philIip
Differential Revision: D52729974
Pulled By: cipolleschi
fbshipit-source-id: 40adef810c1d419900fb7ba706af6fb095941e10
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42601
After S390064, the OnDismiss event for Modal from D52445670 was reverted.
The diff was too big and caused the SEV, so we are trying to reimplement it gradually to make sure we don't brake anything.
The most important thing for our short term goal is to make the `OnDismiss` work only for iOS (following the official docs, Android never supported it) for Fabric (Bridge and Bridgeless).
We also want to minimize the changes t the JS infrastructure, so we are trying not to alter the JS APIs.
## The Problem:
The reason why the onDismiss event does not work is because, as soon as the `visible` property is turned to `false`, the component is removed by the React tree.
When this happens, Fabric deallocate the ShadowNode and the EventEmitter. Therefore, the event is not fired.
## The Solution:
We made this work by "delaying" when the component need to be removed from the reacat Tree.
Rather then rendering or node or not based on the `visible` props, we are introducing a `State` object that keeps track when the Modal is rendered or not.
The `state.isRendering` property is set to `true` when the `visible` prop is set to `true`.
For iOS, when `visible` prop is set to `false`, instead, we wait for the Native side to actually dismiss the View and to invoke the event. When the event is fired, we manually set the `state.isRendering` property to false and the Modal can be considered dismissed.
Notice that this makes also useless to have the Modal Native's snapshot to simulate that the modal is still presented.
## Changelog:
[iOS][Fixed] - `onDismiss` now work on iOS with Fabric, in both Bridge and Bridgeless mode.
Reviewed By: sammy-SC
Differential Revision: D52959996
fbshipit-source-id: 365ca1d0234e3742df9db87007523d1a4a86079f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42859
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D53393475
fbshipit-source-id: 442439c03e251d018f289ba4bb45dde9e6a0ab7f
Summary:
Currently if the virtualized list content is small `onStartReached` won't be called initially when the list is mounted. This is because when the content is small `onEndReached` will be called initially preventing `onStartReached` from being called. In `_maybeCallOnEdgeReached` calling `onEndReached` and `onStartReached` are in the same conditional so they cannot both be triggered at once. To improve the consistency of `onStartReached` we should call both `onEndReached` and `onStartReached` if needed.
## Changelog:
[GENERAL] [FIXED] - Call onStartReached initially when list is small and `onEndReached` is called
Pull Request resolved: https://github.com/facebook/react-native/pull/42902
Test Plan:
I used this code to test in RN Tester (replace content of RNTesterAppShared.js)
```ts
import React, { useState, useEffect } from "react";
import { StyleSheet, FlatList, View, Text, TouchableOpacity } from "react-native";
function App() {
const [data, setData] = useState(generatePosts(4));
const [idCount, setIdCount] = useState(1);
const renderItem = ({ item }) => <Item data={item} />;
const keyExtractor = (item) => item.id.toString();
console.log("-------")
return (
<View style={{ flex: 1, marginVertical: 20 }}>
<FlatList
key={idCount}
data={data}
renderItem={renderItem}
keyExtractor={keyExtractor}
onEndReachedThreshold={0.05}
onEndReached={() => console.log("onEndReached")}
onStartReachedThreshold={0.05}
onStartReached={() => console.log("onStartReached")}
inverted
/>
<TouchableOpacity style={{height: 50, width: '100%', backgroundColor: 'purple'}} onPress={()=>{
setIdCount(state => state + 1)
setData(generatePosts(2))
}}><Text> Press</Text></TouchableOpacity>
</View>
);
}
function Item({ data }) {
return (
<View style={styles.item}>
<Text style={styles.title}>
{data.id} - {data.title}
</Text>
</View>
);
}
const styles = StyleSheet.create({
item: {
backgroundColor: "#f9c2ff",
padding: 20,
marginVertical: 8,
marginHorizontal: 16,
},
title: {
fontSize: 24,
},
});
const generatePosts = (count, start = 0) => {
return Array.from({ length: count }, (_, i) => ({
title: `Title ${start + i + 1}`,
vote: 10,
id: start + i,
}));
};
export default App;
```
Before the change only onEndReached is called, after the change both onStartReached and onEndReached is called.
Reviewed By: sammy-SC
Differential Revision: D53518434
Pulled By: cipolleschi
fbshipit-source-id: bc34e0d4758df6d5833be7290e5a66efaf252ffd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42908
Changelog: [internal]
Just a small ergonomic improvement to do `ReactNativeFeatureFlags.override` instead of `ReactNativeFeatureFlags.INSTANCE.override` in Java.
We already did this for the methods to access the feature flags in the same class.
Reviewed By: rshest
Differential Revision: D53516254
fbshipit-source-id: cdaa90b3baae4f780a42a96ebb07de78bd968019
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42917
If the app is not connected to Metro, the behavior of the refresh is different between bridgeless and bridge. This is because the `handleReloadJS` is implemented differently between the two support managers. I'm fixing it.
Changelog:
[Android] [Fixed] - Fix Reload behavior being different on Bridgeless
Reviewed By: cipolleschi
Differential Revision: D53526369
fbshipit-source-id: 63509b5595c3738a1d6d9eb4352036c174643770
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42906
Makes way to relocate repo E2E testing + Verdaccio logic under `scripts/e2e/`. The contents of this script are minimal and are better located with `rn-tester-e2e`.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D53516117
fbshipit-source-id: e7e50af0383788f2219da190bf921ea93a6455eb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42733
When we fixed the race condition between A11yManager and RCTUIManager, we did it by moving the A11yManager on a background queue.
In the old architecture, this was raising a warning which our users might find confusing. Plus, that change was not aligned with what the A11yManager declared in its configuration because we are actually initializing it starting from a BG queue.
{F1405693310}
With this change we anticipate the initialization of the module in a place where:
1. We know we are in the main queue
2. We know we are going to need it (so it is not violating the lazy load principle)
3. We know it is safe.
This should allow us to also remove the feature flag of `RCTUIManagerDispatchAccessibilityManagerInitOntoMain` because now it is safe to use the main_queue as requested by the module.
## Changelog:
[iOS][Fixed] - Initialize the A11yManager in the main queue and when we need it.
Reviewed By: philIip
Differential Revision: D53225120
fbshipit-source-id: fa6ef7fac380e17684cc02de0b4a46504b26bb3d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42896
Changelog:
[General][Fixed] Fix order of Metro hotkey console messages
# Existing
Key handler is printing messages to the console _after_ it has been processed, this causes error messages to appear before the `info` message.
# In this PR
The `info` messages are logged before the event is processed.
Reviewed By: GijsWeterings
Differential Revision: D53479732
fbshipit-source-id: 25af47450662de4eb03d0dfd52af5af014ef3e49
Summary:
For Bridgeless mode we set `fabric` and `concurrentRoot` property for newly initialized views. This example overwrites those properties. I think we should Instead copy previous dictionary and only overwrite `color` key.
This issue results in a warning: "Using Fabric without concurrent root is deprecated. Please enable concurrent root for this application."
Note: This Example crashes on Bridgeless but my other PR https://github.com/facebook/react-native/issues/42263 fixes it.
## Changelog:
[INTERNAL] [FIXED] - UpdatePropertiesExampleView to mutate existing `appProperties` instead of overwriting
Pull Request resolved: https://github.com/facebook/react-native/pull/42634
Test Plan:
1. Wait for this example to get fixed for Bridgeless
2. Click the button to update props
3. Check if there is no warning
Reviewed By: cortinico
Differential Revision: D53126953
Pulled By: cipolleschi
fbshipit-source-id: fa0e8bda50a47696467d279845616c2ba51fe310
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42821
As the title says, we want `concurrentRoot iif fabric`.
This makes sure we invoke renderApplication correctly.
Changelog:
[Internal] [Changed] - Set concurrentRoot to true whenever Fabric is used in renderApplication
Reviewed By: sammy-SC
Differential Revision: D53353017
fbshipit-source-id: 8de88adf528eb71f233233bd85c2c6ef9430fb16
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42892
## Changelog:
[Internal]-
This adds an ability to have multiple custom source transformers when resolving asset sources, which is beneficial in some scenarios.
The transformers are chained, being executed in order they are registered, until one of them returns a non-null value.
If none does, then the default one is returned.
Reviewed By: GijsWeterings
Differential Revision: D53472320
fbshipit-source-id: ed9baf8789b8bd41c8ce78eed71ebb65868cf178
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42829
This is the base query method that we can wrap to use specific matchers like `findByTestID` or `findByRole`
Changelog: [internal]
Reviewed By: noahlemen
Differential Revision: D53359005
fbshipit-source-id: d1ac9c503b05d479567b6ced71d4517d5bc55b0b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42873
Changelog:
[iOS][Fixed] Disable the "Open Debugger" item from dev menu if packager is disconnected
# Existing
In our dev menu, the "Open Debugger" menu item is shown even if the packager isn't connected.
{F1434746954}
# In this PR
The "Open Debugger" menu item is disabled when the packager is disconnected.
{F1451344668}
# Reference
* Also on Android: D53428914
Reviewed By: robhogan
Differential Revision: D53354110
fbshipit-source-id: 6eb4e826fe9317798c704a5441b5e462edab1c4b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42885
## Context
We're introducing the concept of **capability flags** to provide granular control of behaviours in the Inspector Proxy, to replace the recently added `type: 'Legacy' | 'Modern'` target switch.
A capability flag disables a specific feature/hack in the Inspector Proxy layer by indicating that the target supports one or more modern CDP features.
## This diff
Following D53355413, we're now able to remove the previous `type: 'Legacy' | 'Modern'` page concept, implemented in this diff.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D53358480
fbshipit-source-id: 62e53a1bd60760291ada3479121dfca9e1f6edbc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42884
## Context
We're introducing the concept of **capability flags** to provide granular control of behaviours in the Inspector Proxy, to replace the recently added `type: 'Legacy' | 'Modern'` target switch.
A capability flag disables a specific feature/hack in the Inspector Proxy layer by indicating that the target supports one or more modern CDP features.
## This diff
This updates the pages response in `jsinspector-modern` to send a capability flags configuration, replacing `InspectorPageType`/`"type"`.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D53355413
fbshipit-source-id: 710f9eb11fcc61ab06bfc3051517dd4dd204c68a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42818
## Context
We're introducing the concept of **capability flags** to provide granular control of behaviours in the Inspector Proxy, to replace the recently added `type: 'Legacy' | 'Modern'` target switch.
A capability flag disables a specific feature/hack in the Inspector Proxy layer by indicating that the target supports one or more modern CDP features.
## This diff
Implements a second granular flag, `nativeSourceCodeFetching`, and adds tests for this.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D53352242
fbshipit-source-id: 94b62d84c731c903c5f99f8206d5c91bc501d030
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42817
## Context
We're introducing the concept of **capability flags** to provide granular control of behaviours in the Inspector Proxy, to replace the recently added `type: 'Legacy' | 'Modern'` target switch.
A capability flag disables a specific feature/hack in the Inspector Proxy layer by indicating that the target supports one or more modern CDP features.
## This diff
- Implements capability flags in `InspectorProxy`, via an optional `"capabilities"` key returned by a device's CDP server.
- Wires up an initial flag, `nativePageReloads`, to disable the legacy "React Native Experimental (Improved Chrome Reloads)" page and emulated page reload behaviour.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D53352244
fbshipit-source-id: 622fc6028174919b9bf776e3ac52724d97ca2734
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42758
Changelog: [iOS][Added] - introduce native api to access RuntimeExecutor
The goal of this API is to provide a safe way to access the `jsi::runtime` in bridgeless mode. The decision to limit access to the runtime in bridgeless was a conscious one - the runtime pointer is not thread-safe and its lifecycle must be managed correctly by owners.
However, interacting with the runtime is an advanced use case we would want to support. Our recommended ways to access the runtime in bridgeless mode is either 1) via the RuntimeExecutor, or 2) via a C++ TurboModule.
This diff introduces the API that would allow for 1). The integration consists of these parts:
- wrapper object for RuntimeExecutor access, `RCTRuntimeExecutor`. The NSObject wrapper is necessary so we can make it the property of a swift module
- new protocol API,`RCTRuntimeExecutionModule`, for modules to access the RuntimeExecutor block
- integration within the bridgeless infrastructure
Reviewed By: javache
Differential Revision: D53256188
fbshipit-source-id: 8fadbe8f760cdb8928bbf3f7e4829e27b7617b9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42860
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D53393473
fbshipit-source-id: 93e6be94cee4f852c85464ce151670b1c8f1f913
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42857
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: rshest
Differential Revision: D53393472
fbshipit-source-id: 717507391623d67d03d83bf344475a4a830504a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42861
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: rshest
Differential Revision: D53393474
fbshipit-source-id: 4bbdf72729d3a84ad90a3071d8abcedefbe89878
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42856
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D53393476
fbshipit-source-id: b2278befdbfa45209acf36c8c73b276bb897ac8f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42853
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D53393135
fbshipit-source-id: 74a7f710eb7bf5a2e2b39e07ee4b026a425f521c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42855
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D53393136
fbshipit-source-id: 29884933200a5f9251954fc3488828767a4013fa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42854
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D53393141
fbshipit-source-id: a83840a904ba06f4dfbded2480c19d1457566f4c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42852
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D53393137
fbshipit-source-id: 9ed2d2b28d3ad6ecb644eeb494ac2511e3b2397e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42848
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D53393140
fbshipit-source-id: 90e64c746a1d72cfd91876082bdc9642c72fd896
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42825
This makes overrides for feature flags more predictable by only allowing a single point of overrides per app.
The previous behavior was:
* Common flags: the last override would win.
* JS flags: overrides would be combined and the last definition for each flag would win.
The new behavior, both for common flags and for JS flags, is to only have a single override.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D53360609
fbshipit-source-id: 7e299d74fada188beb1bf17eb7e25ff97015781e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42820
The feature flag system generates a significant amount of files. This reduces that number to remove noise from diffs/PRs by eliminating a file that could be defined privately within another one.
Changelog: [internal]
Reviewed By: huntie
Differential Revision: D53352391
fbshipit-source-id: 51fccb3c1bb09ef3503cd34334d28c1021bd1b25
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42815
Feature flags were originally defined in a JSON file for easier interoperability but we're only using the definitions in JS anyway, so having the definitions in a JS file is more flexible (e.g.: adding comments).
Changelog: [internal]
Reviewed By: huntie
Differential Revision: D53351483
fbshipit-source-id: 23fe0a3898b4facf2f2cf9645f78c45d78937f31
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42871
Minor improvements:
* Removed unused imports
* No longer need to use `static const *` because now we don't rely on pointer equality (we specify the index of the array where to write now).
Changelog: [internal]
Reviewed By: javache
Differential Revision: D53416934
fbshipit-source-id: 9ea12b8398688666e6b76768d3f8fb4e1aad5d1c
Summary:
`react-native/community-cli-plugin` is unable to resolve out-of-tree platforms in monorepos because the package may not be hoisted to the same location. For example, if `react-native/community-cli-plugin` was hoisted:
```
/~/node_modules/react-native/community-cli-plugin/dist/utils
```
It may never find `react-native-macos` if it wasn't hoisted:
```
/~/packages/my-app/node_modules/react-native-macos
```
## Changelog:
[GENERAL] [FIXED] - Fix `react-native/community-cli-plugin` is unable to resolve out-of-tree platforms in monorepos
Pull Request resolved: https://github.com/facebook/react-native/pull/42875
Test Plan: Tested in an internal project.
Reviewed By: cipolleschi
Differential Revision: D53426607
Pulled By: robhogan
fbshipit-source-id: 29b9fe92d5773d0160bba375d2e92ec688652e3e
Summary:
Original commit changeset: 32898e1ba30b
Original Phabricator Diff: D52998256
[General][Removed] - Back out: Gradle plugin for resolving node_modules packages.
Backing this (my own diff) out as it breaks CI - I'm not sure why it landed.
Reviewed By: cipolleschi
Differential Revision: D53427912
fbshipit-source-id: baec254a463e3f7827d6a8675499aab34069ddd1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42823
This is a tiny new Gradle plugin intended to be published to the Gradle Plugin Portal independently of React Native. It's only function is to resolve `node_modules` package roots using a sufficient subset of the Node JS resolution algorithm - e.g, we can use it to find `react-native` itself from a user's project, whatever package manager or workspace setup they're using, in a Gradle-friendly, cacheable manner.
The plugin is both a `Settings` plugin and a `Project` plugin, so that it may be used from both `settings.gradle` (where we need it to resolve `react-native`) and `app/build.gradle` (which currently applies from `cli-platform-android`).
The setup is mostly `gradle init` with a few modifications (eg, Kotlin JVM version) to stay close to the setup for `react-native-gradle-plugin`. I think it's easier to reason about this currently as an entirely separate Gradle project, but we may be able to merge the two and reduce some duplication once it's proven.
Changelog:
[General][Added] - Gradle plugin for resolving node_modules packages.
Reviewed By: cortinico
Differential Revision: D52998256
fbshipit-source-id: 32898e1ba30bccabca11b623f03959a51898afe8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42870
This refactors `ReactNativeFeatureFlagsAccessor` in C++ to improve its thread-safety:
* It makes all cached feature flags atomic to prevent data corruption when writing them concurrently.
* It refactors the list of accessed feature flags to be an array of atomic character pointers instead of a vector.
Performance-wise, this is lock-free so it would still be fast enough for our use cases.
Semantic-wise, this implementation could lead to feature flags being initialized more than once (if 2 threads happen to access the same feature flag before it has been initialized), but that's ok. The only consequence of this would be accessing the provider twice, but the end state of the accessor is the same (the same value would be cached and the flag would still be marked as accessed).
Changelog: [internal]
Reviewed By: javache
Differential Revision: D53406924
fbshipit-source-id: 1023673c40f9da43a51c5f96354d4c458c9d14d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42869
`DefaultReactNativeHost` builds a `ViewManagerRegistry` based on a list of ViewManagers, which is inefficient, as we have to allocate them all ahead of time (defeating the purpose of `ViewManagerOnDemandReactPackage`). Instead provide a `ViewManagerResolver`which lazily resolves them.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D53406841
fbshipit-source-id: be8437e2127fb6741d1948cecbcf5c3d9f8de268
Summary:
This PR fixes a specific case pointed out by dmytrorykun, where there might be no platform or `deployment_target` specified at all and in that case we assume that this library supports every platform (same as Cocoapods).
## Changelog:
[IOS] [FIXED] - Don't add compiler conditionals when no platforms are specified
Pull Request resolved: https://github.com/facebook/react-native/pull/42867
Test Plan:
Test running codegen when library doesn't specify a `platform`:
```
require 'json'
package = JSON.parse(File.read(File.join(__dir__, 'package.json')))
Pod::Spec.new do |s|
s.name = 'OSSLibraryExample'
s.version = package['version']
s.summary = package['description']
s.description = package['description']
s.homepage = package['homepage']
s.license = package['license']
s.author = 'Meta Platforms, Inc. and its affiliates'
s.source = { :git => package['repository'], :tag => '#{s.version}' }
s.source_files = 'ios/**/*.{h,m,mm,cpp}'
install_modules_dependencies(s)
end
```
Check generated `RCTThirdPartyFabricComponentsProvider`
Reviewed By: cortinico
Differential Revision: D53405625
Pulled By: dmytrorykun
fbshipit-source-id: 0f6917c56b84f0fa29807f516acdbd8d15aa5b46
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42822
The conversion to string was introduced in D45043929. It was supposed to fix command execution for `MyLegacyNativeComponent` in RNTester on Android/Old Architecture.
At the same time it introduced a regression on iOS, since we have [different code path](https://www.internalfb.com/code/fbsource/[ffee789cab9514c0a15b8a63869cbfdf4e534a56]/xplat/js/react-native-github/packages/react-native/React/Modules/RCTUIManager.m?lines=1088-1092) for string commands in iOS, where we expect command name, and not command number converted to string.
I tried to remove that conversion, did local tests, and saw no issues with executing commands on Android.
Looks like the underlying issue has been fixed in some other way.
So let's just remove those conversions.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D53123956
fbshipit-source-id: 968e35277e01215bd6fc1282c78f04666453317d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42811
changelog: [internal]
Attempt to fixing a crash in ReactViewGroup when removeClippedSubviews is enabled.
The implementation of removeClippedSubviews in ReactViewGroup is stateful and must be in sync between children of view and [member variables in ReactViewGroup](https://fburl.com/code/l22wewzc) that keep reference to all children. When it gets out of sync, it manifests itself as `java.lang.IndexOutOfBoundsException` crash.
The mounting layer counts on the fact that view hierarchy will never be directly mutated and all mutations will go through [ReactClippingViewManager](https://fburl.com/code/esl3vqhh). ReactClippingViewManager, if clipping is enabled, calls appropriate methods on ReactViewGroup to make sure member variables to manage clipping are in sync with view hierarchy.
This is true, except for a retry mechanism in SurfaceMountingManager. The retry mechanism tries to manually reconciliation the state with android view hierarchy. It bypasses ReactClippingViewManager in the process.
Reviewed By: javache, mdvacca
Differential Revision: D53348831
fbshipit-source-id: b6b190781a7c85ee4dfd7cb9bc74fd3a55466e45
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42688
X-link: https://github.com/facebook/yoga/pull/1567
We are planning on overhauling NodeToString to output JSON instead of HTML for the purposes of better benchmarking and capturing trees in JSON format to benchmark later. This gives us a bit of a headache as we have to revise several build files to ensure this new library works, ensure that it is only included in certain debug builds, and deal with the benchmark <-> internal cross boundary that arises as the benchmark code (which is a separate binary) tries to interact with it.
On top of it all this is really not used at all.
The plan is to rip out this functionality and just put it in a separate binary that one can include if they really want to debug. That means that it cannot exist in the public API, so I am removing it here.
Private internals come next
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D53137544
fbshipit-source-id: 7571d243b914cd9bf09ac2418d9a1b86d1bee64a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42828
Updates to toJSON:
- return object tree instead of formatted snapshot string. Applying the `'react.test.json'` symbol lets Jest do the formatting work for us
- Source props from `pendingProps` on `instanceHandle`. This adds props such as `pointerEvents` and `style` which were present on RTR's snapshots but don't get included in the node's `props` collection
- Render text node as text value, instead of RCTRawText like `<RCTRawText text="Hello" />`
Changelog: [internal]
Reviewed By: kassens
Differential Revision: D53321821
fbshipit-source-id: 033637b9152441c318c9c797aa9223ff15768873
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42827
This is a simple snapshot test using ReactTestRender's toJSON. We have almost the same functionality in RNTR already, so let's see if we can support tests like this.
Merging the new setup and environment with the existing configuration (https://fburl.com/code/s85sma77) still causes issues so here we add unmocking and new setup inline. Added task T177114228 to track following up on this
Note that some formatting is changed and props are dropped on the snapshot. This is resolved with refactor in next diff
Changelog: [internal]
Reviewed By: yungsters
Differential Revision: D53321823
fbshipit-source-id: a20f77c29fefb9172f8a8189bd821dd202b2ff02
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42826
yungsters debugged the failing test library import and found that we don't yet support package exports. Switching this to main with an index file allows us to import the library in other places.
Changelog: [internal]
Reviewed By: yungsters
Differential Revision: D53240712
fbshipit-source-id: 046a7d1678cbca181e4a4de607a9c0e7490ef047
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42790
A tiny bit of refactoring to unify the setup
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D53313332
fbshipit-source-id: 4642f7d1dee8adf821b06c2ed25be09fd5dce098
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42747
Changelog: [Internal]
Implements a `RuntimeAgent` (D51231326) for Hermes for the modern CDP backend, based on the `CDPHandler` API that Hermes exposes currently.
## A note on `console`
We unfortunately have to disable `console` interception (D51234334 / equivalently D52971652) because `CDPHandler`'s current implementation is not aligned with the Agent concept:
* Agents are only created once a session has started, but the `console` interceptor needs to be injected at VM startup.
* Agents should not clobber each other's shared state (nor consume excessive resources per Agent), but each `CDPHandler` would install its own independent `console` interceptor if enabled.
We will enable CDP `console` support in the modern backend in future work. This will require either some additional plumbing in RN (e.g. to safely access JSI from an Agent/Target) or some additional work in Hermes.
## Conditional compilation based on `HERMES_ENABLE_DEBUGGER`
`HermesRuntimeAgent.cpp` compiles both with and without `-DHERMES_ENABLE_DEBUGGER`, which is the flag Hermes uses to control the availability of `CDPHandler` (and its containing Buck library).
If the debugger is not enabled, `HermesRuntimeAgent` reduces to a `FallbackRuntimeAgent`. In either case, no Hermes debugger headers leak into `HermesRuntimeAgent.h`, so callers don't need to check `#ifdef HERMES_ENABLE_DEBUGGER`, and the overall CDP backend infra is not gated on whether the Hermes debugger is compiled in.
Reviewed By: huntie
Differential Revision: D51234333
fbshipit-source-id: ccbca443560308c5edba4b9689501d01059fdd94
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42725
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D53200097
fbshipit-source-id: dad54f5bf03967b5d4126757ab0d5424534af888
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42723
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D53200099
fbshipit-source-id: a5b244da401fb23c9579728c7261312ab200d623
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42724
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D53200100
fbshipit-source-id: e6355af332c601e0d61e698d2fa0506c6a293989
Summary:
This PR removes the TypeScript entry for `UIManager.takeSnapshot()`. This function does not appear to be implemented anywhere, and calling it throws `TypeError: _reactNative.UIManager.takeSnapshot is not a function (it is undefined)`.
I think this functionality is still supported by [react-native-view-shot](https://github.com/gre/react-native-view-shot) for anyone who needs it!
## 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] [Removed] - Removed type definition `UIManager.takeSnapshot()`
Pull Request resolved: https://github.com/facebook/react-native/pull/42779
Test Plan: Ran TypeScript checks.
Reviewed By: cipolleschi
Differential Revision: D53307137
Pulled By: NickGerleman
fbshipit-source-id: 2e65c58c77bcde4f36f5065295d15757c519239d
Summary:
The previous typing of FlatList and VirtualizedList did not convey any information on the type of the items passed in to `onViewableItemsChanged`, but instead the type was set to `any`. This PR adds the type information.
I set a default type `any` for thy ViewToken, because the type is exported and not having it would be a breaking change if that type is used. Like this it gracefully falls back to the default behavior of the `any` type.
Notice: I don't know how typing in "flow" works, but the same "issue" seems to be in there as well. Maybe someone with more flow experience can fix that as well:
https://github.com/facebook/react-native/blob/ae42e0202de2c3db489caf63839fced7b52efc5d/packages/virtualized-lists/Lists/ViewabilityHelper.js#L19-L20
## Changelog:
[GENERAL] [FIXED] - Add type information for items of VirtualizedList in `onViewableItemsChanged` signature
[GENERAL] [FIXED] - Add type information for items of FlatList in `onViewableItemsChanged` signature
Pull Request resolved: https://github.com/facebook/react-native/pull/42773
Test Plan:
Without the changes, typecheck of the project was fine, but with the changes applied to the node_modules/react-native copy a type error was found:
```
$ npm run typecheck
> my-project@1.0.0 typecheck
> tsc --skipLibCheck
src/MyComponent.tsx:385:29 - error TS2345: Argument of type '(string | number)[]' is not assignable to parameter of type 'number[]'.
Type 'string | number' is not assignable to type 'number'.
Type 'string' is not assignable to type 'number'.
385 viewableItems
~~~~~~~~~~~~~
386 .filter(
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Reviewed By: rozele
Differential Revision: D53276749
Pulled By: NickGerleman
fbshipit-source-id: 3fa5c65b388a59942c106286ac502a85c583da50
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42745
Changelog: [Internal]
Creates the `FallbackRuntimeAgent` class and uses it (as the name would suggest) as a fallback in cases where no other suitable `RuntimeAgent` implementation is available.
`FallbackRuntimeAgent`'s only feature is logging a message explaining that the runtime isn't debuggable. In the final product, users shouldn't get this far into launching the debugger if they're not using a compatible engine like Hermes, but this is a nice touch in case they do. (It's also useful for testing while we're working on landing the actual Hermes integration.)
Reviewed By: huntie
Differential Revision: D51449229
fbshipit-source-id: 3b3455a8b482b33bccbb6cc90083aad15052a3e5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42746
Changelog: [Internal]
Formally introduces the concept of "session state" to the modern CDP backend, with the simplest possible implementation:
* `PageTargetSession` has a mutable `SessionState` member.
* All agents receive the same `SessionState&` in their constructor (with `SessionState`'s lifetime being the caller's responsibility).
* It's only legal to read/write to `SessionState` on the thread where requests are handled and Agents are created (the "main" thread).
* Agents are expected to play nice and not clobber each other's state in `SessionState`; this is *not* protected with visibility or `const`ness, however.
* We'll probably want to come up with some API-level mechanism to control this as the complexity of our agents grows.
## Current use case: `<Domain>.enable`
The first use case for session state is to let `PageAgent` manage the `Log.enable` and `Runtime.enable` state for the session. This will allow agents created later in the session (or recreated as part of a reload) to emit Log and Runtime notifications without waiting for additional `enable` messages (that the client is not required to send).
We'll likely want to generalise this design to arbitrary domains in some way (e.g. add a top-level domain router that agents register with explicitly?) but I went with the simplest implementation for our current needs.
NOTE: The CDP spec doesn't state this explicitly, but it's clear from Chrome's behaviour that a `<Domain>.enable` command is intended to be session-scoped and survive reloads.
## Future use case: Instance/Runtime state persistence
The `<Domain>.enable` use case could have been solved with passing *immutable* state to Agents (`const SessionState&`). We make the state mutable in anticipation of `HermesRuntimeAgent` needing to store its own state in the session down the line, which we know is going to be needed in order for breakpoints to survive reloads.
Agents that never need to mutate state SHOULD only store this as a const reference.
Reviewed By: huntie
Differential Revision: D53006916
fbshipit-source-id: a0443c507294faa94efdf25b2f1670129774dc78
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42635
Changelog: [Internal]
Adds a RuntimeAgent interface to the modern CDP backend, plus an `InstanceTargetDelegate::createRuntimeAgent()` method. This allows the RN integration to provide an engine-specific CDP implementation.
This diff includes all the plumbing in Bridge and Bridgeless to route `createRuntimeAgent()` calls to the right place - ending up at `JSExecutor::createRuntimeAgent()` and `JSIRuntimeHolder::createInspectorAgent` respectively - at which point we currently return `nullptr` to signify that JS debugging isn't supported.
## Next steps
In upcoming diffs we'll add concrete implementations of `RuntimeAgent`, and teach both Bridge and Bridgeless to create them as appropriate:
* `HermesRuntimeAgent` for Hermes
* `FallbackRuntimeAgent` for all other JS engines (JSI or not)
We'll also (likely) add assertions to ensure that any JSI runtime that reports itself as "inspectable" (a flag used to control some of the in-app debugging UI) comes with a non-default `createRuntimeAgent()` implementation. We avoid this for now to prevent crashing the modern backend on Hermes.
NOTE: Like the rest of the modern CDP backend, the `RuntimeAgent` API is 100% experimental and subject to change without notice. A *future* version of this API will allow out-of-tree JSI engines to integrate with the modern CDP backend. Either way, it is intended strictly for the use case of integrating with a JS engine, not for adding any other framework-level CDP functionality.
Reviewed By: huntie
Differential Revision: D51231326
fbshipit-source-id: 81e87c5134df73cc4aac0f9d5793a5236b5720d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42783
This change will fix the publishing of Nightlies for React Native with the right version
## Changelog:
[Internal] - Update the package.json of react native correctly.
Reviewed By: cortinico, huntie
Differential Revision: D53309082
fbshipit-source-id: 2fa4d4fdf4f984603c6b3d3690fa3c464ee6d030
Summary:
On latest `main`, RN Tester was crashing for me just after loading the JS bundle with `java.lang.UnsatisfiedLinkError: dlopen failed: library "libreactfeatureflagsjni.so" not found`
It seems to be named `featureflagsjni` instead in [here](https://github.com/facebook/react-native/blob/main/packages/react-native/ReactAndroid/src/main/jni/react/featureflags/CMakeLists.txt#L11)
## Changelog:
No changelog needed
Pull Request resolved: https://github.com/facebook/react-native/pull/42770
Test Plan:
```bash
./gradlew :packages:rn-tester:android:app:installHermesDebug -PreactNativeArchitectures=arm64-v8a
```
Then run the app, the app was crashing before the fix, not crashing now
Reviewed By: javache
Differential Revision: D53268873
Pulled By: cortinico
fbshipit-source-id: f098ca12baadab358f72b1c9d5720123248b8e1a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42774
Reorganise release scripts so that command entry points are grouped based on execution context, which also reflects dependencies between scripts.
Also:
- Document the current behaviours of these scripts.
- Relocate utils out of the root contents.
- Replace `exec` call to `set-rn-version` script with function import.
NOTE: `yarn trigger-react-native-release` (documented command in release process) is unchanged, since this is aliased from `package.json`.
```
├── releases
│ ├── templates/
│ ├── utils/
│ ├── remove-new-arch-flags.js
│ ├── set-rn-version.js
│ └── update-template-package.js
├── releases-ci
│ ├── prepare-package-for-release.js
│ └── publish-npm.js
└── releases-local
└── trigger-react-native-release.js
```
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D53274341
fbshipit-source-id: eec2befc43e7a47fd821b2e2bcc818ddffbb6cf7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42781
Change in [31cf4c4ead](https://github.com/facebook/react-native/commit/31cf4c4eada59bde62f30e14024719779fc23a91) broke the template for bridgeless as we changed the signature of a method in the header of `RCTAppDelegate`.
This change aligns the API between RCTAppDelegate and the template's AppDelegate
## Changelog:
[iOS][Fixed] - Align the the bundleURL API from `RCTAppDelegate` to template's `AppDelegate`
Reviewed By: cortinico, dmytrorykun
Differential Revision: D53274434
fbshipit-source-id: 25bad702ba05db2e3a6a9449abbda7d8e2fdb8a0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42771
This feature was first introduced here https://github.com/facebook/react-native/pull/34580
And then removed here https://github.com/facebook/react-native/pull/41654
The motivation for its removing was that Node resolver should handle all those cases for which `react-native.config.js` was used. But it turns out that it fails for the setup that `react-native-builder-bob` has.
This diff brings back support for defining external libraries in `react-native.config.js`.
Changelog: [iOS][Fixed] - Bring back support for defining external libraries in react-native.config.js
Reviewed By: cipolleschi
Differential Revision: D53267857
fbshipit-source-id: 7625dfe7b4a4651eb60eaec725f94f222a244e30
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42777
During view preallocation eventEmitter information is not being passed to the platform. This causes bugs with emision of events during initial rendering when using the new Fabric Event dispatching system.
e.g. Rendering a TextInput that has 'onFocus' event and also has autoFocus enabled.
The new Fabric Event dispatching system dispatch events earlier (this is expected)
In this diff I'm fixing this issue by ensuring that all preallocated views have an eventEmitter (when its shadowNode has an eventEmitter)
This was actually implemented in the past, but in order to optimize, we run an experiment (D29117957) and it was later deleted.
(D40356386). I didn't find details of the results of the experiment.
We could run another experiment to understand potential negative perf impact of this change, although I believe it's the right thing to do here.
Changelog: [Android][Fixed] Fix delivery of events during initial rendering in new architecture
Reviewed By: sammy-SC
Differential Revision: D53108114
fbshipit-source-id: 0b56b7495db63e4a478f4b34e91f4bcbf452ef92
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42748
React Native has globally enabled RTTI within `rn_xplat_cxx_library`, ahead of RTTI being forced on (regardless of flag) in Android apps (it was previously enabled everywhere but Android, which has caused us no small share of headaches, with public JSI APIs designed around clients using RTTI).
This diff:
1. Mechanically replaces usages of `traitCast` with equivalent calls to `dynamic_cast` or `dynamic_pointer_cast`
1. These have similar semantics as current iteration of `traitCast`, where we return `nullptr` for pointer form, or throw on invalid cast for reference form.
2. Removes `IdentifierTrait` as a requirement to cast to a ShadowNode
3. Removes the ShadowNode traits used solely as cast identities
This enables consistent usage of `dynamic_cast` (including for user defined ShadowNodes), and also exposes some places where `traitCast` allowed implicit const conversion.
The OSS builds should already have RTTI on, and will be able to use `dynamic_cast` on RN provided types (`traitCast` is not extendable).
Changelog:
[General][Breaking] - Delete traitCast and identifier traits
Reviewed By: sammy-SC
Differential Revision: D53215009
fbshipit-source-id: d20cbf66b725f5565fa5d03332010d87f2b08b61
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42721
If left and right are swapped, this code assumes every yoga layoutable shadownode is a view, and mutates its props as if they were ViewProps. This is not safe, and could lead to memory corruption.
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D53213652
fbshipit-source-id: c43e0f80fdd5889761317c1243ccc0ab392e3443
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42719
The task T175989432 started firing on October 30 2020, which correspond to the landing of D24512203. I believe disabling CustomDrawOrder could be a potential cause of T175989432, that's why in this diff I'm creating an experiment to understand what is the impact (negative or positive) of re-enabling CustomDrawOrder in RN Android
Original diff: D24512203
Changelog: [Internal] internal
Reviewed By: javache
Differential Revision: D53150292
fbshipit-source-id: f0abbc7d175c2cd717ce87bbe69aeaf3db0b0e5c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42776
Changelog: [Internal] set all monorepo packages (including react-native) to one version and update all inter-dependencies (including the template)
Reviewed By: huntie
Differential Revision: D53251917
fbshipit-source-id: 95330ca66dcb7234a3f09752ecc3ed9087ced4bf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42744
This adds a nightlies-feedback workflow, which our partners can get permission to mirror the results of their nightlies CI workflows. We do this to use our internal tools that are restricted to Meta owned Github projects.
The benefit to partners is that they can add this step to their workflow:
```
- if: ${{ success() || failure() }}
env:
OUTCOME: ${{ contains(steps.*.conclusion, 'failure') && 'fail' || 'pass' }}
run: |
curl -X POST \
-H "Accept: application/vnd.github.v3+json" \
-H "Authorization: token ${{ secrets.GITHUB_TOKEN }}" \
https://api.github.com/repos/facebook/react-native/actions/workflows/nightlies-feedback.yml/dispatches \
-d "$(printf '{"ref":"main","inputs":{"outcome":"%s","stage":"needs_an_action","link":"http://github.com/some/action","version":"%s"}}' "$OUTCOME" "${{ inputs.version }}" )"
```
### Feedback:
It's complicated, but there are ways to simplify this for our users. I'd like to prove out that it's valuable first with Expo.
### Limits:
There's certainly a lot of room for improvement, which we could provide with a published action (populate the ref correctly, simplify gathering the outcome, labelling of failing step correctly, etc...).
### Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D53229996
fbshipit-source-id: 10e4ba5b5fd85935b1b03aaafa41ef8b96d2faca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42743
When working on Mobile Home, we found a component (RNCSafeAreaView) that was going through the interop layer.
The component eits an event as soon as its content view changes, but this is too early: the block that emits the event is still nil at that point in time and that makes the app crash.
There might be other components with similarbehavior, therefore, we are fixing it at the interop layer, setting the props immediately after the component is created.
## Changelog:
[iOS][Fixed] - Immediately set props of Components that goes through the interop layer
Reviewed By: sammy-SC
Differential Revision: D53230471
fbshipit-source-id: 90a19e0e87fea381b348b5a7e723ab8b416b828c
Summary:
## Changelog:
Changelog: [Internal] Generated 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
Pull Request resolved: https://github.com/facebook/react-native/pull/42759
Reviewed By: cortinico
Differential Revision: D53268094
Pulled By: huntie
fbshipit-source-id: a18d513df4614be1b7715c9c69d8de58baac9548
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42762
This renames `performance.reactNativeStartupTiming` as `performance.rnStartupTiming` to align with the recommended vendor prefix for React Native.
This API is still private, so it's safe to rename.
Changelog: [internal]
Reviewed By: javache
Differential Revision: D53264515
fbshipit-source-id: 6e7a222901071594cac0ca8a0ac78e56e60ab132
Summary:
Some jobs are failing because we moved a file and we did not update the CI with the new path
## Changelog:
[Internal] - Update path to relocated file in CI
Pull Request resolved: https://github.com/facebook/react-native/pull/42767
Test Plan: CircleCI is green (a part from test_android, fixed by another PR)
Reviewed By: huntie, dmytrorykun
Differential Revision: D53266042
Pulled By: cipolleschi
fbshipit-source-id: 7e611b96c204cdbbf794a731fe0db58cb31657fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42720
The request ID was used for in-memory request caching purpose only. There wasn't much reason to use the sophisticated monotonic number, so let's just use a static 64-bit unsigned int counter. With the more-or-less unique UUID prefix, this should have an extremely low chance of collision.
Changelog: [Internal]
Reviewed By: philIip, sammy-SC
Differential Revision: D53205641
fbshipit-source-id: e6da12029624058dc877e9cbe2000af4df938870
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42727
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D53200096
fbshipit-source-id: 2d965ebcb568e7bbff4b37db11070c5079fa6394
Summary:
The goal is to provide testing utilities that use Fabric and concurrent rendering by default to support the new RN architecture. Currently most testing is done through ReactTestRenderer, which is an overly-simplified rendering environment, non-concurrent by default, and over exposes internals. A dedicated RN environment in JS can allow for more realistic test execution.
This is the initial commit to create the `react-native-test-renderer` package. It currently only offers a simple toJSON() method on the root of a test, which is used for snapshot unit tests. We will be iterating here to add a query interface, event handling, and more.
## Changelog:
[GENERAL] [ADDED] - Added react-native-test-renderer package for Fabric rendered integration tests
Pull Request resolved: https://github.com/facebook/react-native/pull/42644
Test Plan:
```
$> cd packages/react-native-test-renderer
$> yarn jest
```
Output:
```
PASS src/renderer/__tests__/render-test.js
render
toJSON
✓ returns expected JSON output based on renderer component (7 ms)
Test Suites: 1 passed, 1 total
1 passed, 1 total
Snapshots: 1 passed, 1 total
Time: 2.869 s
```
Reviewed By: yungsters
Differential Revision: D53183101
Pulled By: jackpope
fbshipit-source-id: 8e29ba35f55f6c4eb2613ab106bc669d72f33d1d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42740
Follow-up to a CircleCI breakage introduced by D53001971.
This was missed by both the typechecker (no Flow in file) and CI (no PR-time jobs covering this script).
Changelog: [Internal]
Reviewed By: cortinico, GijsWeterings, cipolleschi
Differential Revision: D53228096
fbshipit-source-id: fbbe1538ee52b8452399d86489239434d3a068be
Summary:
When we changed dark mode, the semantic color was not applied because we use color components, it's not dynamic. So let's store the `UIColor` for semantic color directly.
https://github.com/facebook/react-native/assets/5061845/bd6d15fe-01eb-4ad7-9844-a19ef8585dae
## Changelog:
[IOS] [FIXED] - [Fabric] Fixes semantic color not work when dark mode changed
Pull Request resolved: https://github.com/facebook/react-native/pull/42737
Test Plan: semantic color changed when switch dark mode.
Reviewed By: christophpurrer
Differential Revision: D53226806
Pulled By: cipolleschi
fbshipit-source-id: 66d5417fa1bb6a5da498e903675a93b20d920c0a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42636
Changelog: [Internal]
Models the Native instance lifecycle in the modern CDP backend, by:
1. Registering the instance, once created, with `PageTarget`.
2. While an instance is registered, delegating messages from `PageAgent` to an internal `InstanceAgent`.
3. Unregistering the instance once it is invalidated and about to be destroyed.
We use this infrastructure to implement two simple behaviours that will be superseded in future diffs (mainly by delegating work to the JSVM), but that are useful as stubs for testing:
* Sending [`Runtime.executionContextDestroyed`](https://cdpstatus.reactnative.dev/devtools-protocol/tot/Runtime#event-executionContextDestroyed), [`Runtime.executionContextsCleared`](https://cdpstatus.reactnative.dev/devtools-protocol/tot/Runtime#event-executionContextsCleared), and [`Runtime.executionContextCreated`](https://cdpstatus.reactnative.dev/devtools-protocol/tot/Runtime#event-executionContextCreated) events to the frontend when reloading the instance.
* Implementing a toy version of [`Runtime.getHeapUsage`](https://cdpstatus.reactnative.dev/devtools-protocol/tot/Runtime#method-getHeapUsage) (that always reports zero memory usage) to exercise the Page→Instance message dispatching logic.
iOS Bridge/Bridgeless and `PageTargetTest` are the only integrations that exist as of this diff, and are all updated here; Android will follow later.
## Object lifetimes
* PageTarget owns an InstanceTarget that it creates (in `registerInstance`) and destroys (in `unregisterInstance`).
* `registerInstance` returns a raw `InstanceTarget&` reference, which becomes invalid upon calling `unregisterInstance`. It's the caller's responsibility to stop using the reference at the point of calling `unregisterInstance`.
* InstanceTarget holds a raw `InstanceTargetDelegate&` reference. It's the caller's responsibility to keep this reference valid at least until `unregisterInstance` returns.
## Thread safety
* As with PageTarget's constructor and destructor, It's the caller's responsibility to invoke `registerInstance` and `unregisterInstance` on the main thread (or using appropriate synchronisation).
* `InstanceAgent` handles messages on the same thread as `PageAgent` (typically the platform-specific main thread) and receives a copy of the same thread-safe `FrontendChannel` for sending messages back.
Reviewed By: huntie
Differential Revision: D51214056
fbshipit-source-id: 2dc2ff30d2dda6887871831a818aa117ca3e6e91
Summary:
Internally, we synched the windows folders in react-native. This added the `windows` folder in the `platform` folder of react/graphics.
This breaks the build for iOS internally as the `React-graphics` pod is now importing both the `ios` and the `windows` folders, but, of course, some of the Windows headers are not available to iOS.
This change excludes the windows folder from the iOS Pod, when building for Meta engineers.
## Changelog:
[internal] - exclude the `plafrom/windows` folder from the `React-graphics` pod.
Reviewed By: motiz88
Differential Revision: D53228890
fbshipit-source-id: 2be5b71f6556e5da76496f0d64a98318477ad3c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42731
This matches the behaviour we have for DefaultTurboModuleManagerDelegate, where we handle the lack of this being set gracefully. It's probably worth still logging this, as it may point at an incorrectly configured app.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D53048064
fbshipit-source-id: 3ef10da3a7779a1274a1a1793387cf8cdf36c535
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42735
This realigns the NDK versions used to build the two tools.
Changelog:
[Internal] [Changed] - Bump FBJNI to 0.6.0
Reviewed By: cipolleschi
Differential Revision: D53223301
fbshipit-source-id: 640e9008ed460e58423fb26b6e7030e264ef9320
Summary:
After update to the latest `react-native` version
we discover that we are unable to use `number%` value for `translate*` props :
```tsx
StyleSheet.create({
root: {
transform: [
{ translateX: '-50%' },
// ^^^^^^ TS Error: Type string is not assignable to type AnimatableNumericValue | undefined
],
}
});
```
---
percentage values are supported, demo: https://snack.expo.dev/retyui/test-tstransform
## Changelog:
[GENERAL] [FIXED] - Update typescript definition of `translateX` & `translateX` to be able to use percentage values
Pull Request resolved: https://github.com/facebook/react-native/pull/42671
Test Plan: `yarn tsc --noEmit`
Reviewed By: rozele, cortinico
Differential Revision: D53146046
Pulled By: NickGerleman
fbshipit-source-id: 3486e7a9b55b98c36cc96b2bca4bb27841061e80
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42730
Reviewing and modernising this script as part of simplifying our release publish workflow.
- Drop unused `--dependency-versions` arg from CLI entry point
- Simplify templating approach
- Type as Flow
- Drop dependencies on `shelljs` and `yargs`
- Relocate under `scripts/releases/`
- Rewrite tests as snapshot tests
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D53001971
fbshipit-source-id: e55a71a0bb37e3e18ba1e582a5c46ddd58823d81
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42699
Changelog: [internal]
The test was fine on C++. The reason is probably that C++ destroys the process between tests (effectively resetting singletons) while iOS doesn't.
This fixes the test by implementing a correct `TearDown` method to reset the flags.
Reviewed By: rshest
Differential Revision: D53178474
fbshipit-source-id: 6a0f67f1a59fe47f73a495344d4c0daa8eafa3c4
Summary:
This PR resolves issues with retrieving appearance in multi-window apps by calling `RCTKeyWindow()` instead of retrieving the AppDelegate window property. It also does small optimization in the RCTAlertController.
## Changelog:
[IOS] [FIXED] - Fix retrieving current appearance in multi-window apps
Pull Request resolved: https://github.com/facebook/react-native/pull/42231
Test Plan: CI Green, it should work the same as before
Reviewed By: NickGerleman
Differential Revision: D52802756
Pulled By: cipolleschi
fbshipit-source-id: 60b5f7045f41be19caae5102f0dc321d4ecdcd2f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42714
For 0.74, we would like to have Bridgeless as the default when the New Architecture is enabled.
## Changelog:
[Android][Breaking] - Make bridgeless the default when the New Arch is enabled
Reviewed By: cortinico
Differential Revision: D52600227
fbshipit-source-id: 0d967c73cd805710c501c020ad892f059a0fb117
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42182
For 0.74, we would like to have Bridgeless as the default when the New Architecture is enabled.
## Changelog:
[iOS][Breaking] - Make bridgeless the default when the New Arch is enabled
Reviewed By: cortinico
Differential Revision: D52598104
fbshipit-source-id: a551bbdda7f7b76d1647036137983e39e612ea45
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42708
When pressing `r` on simulator in Bridgeless mode, we have a race condition between:
- RCTKeyCommands evaluating the blocks to be invoked
- ReactNative invalidating the DevMenu with the list of RCTKeyCommands (on which ReactNative is iterating).
The fix checks which commands need to be executed, stores them in an array and then iterates on the array, which is local to the function call, avoiding any concurrency issue.
## Changelog:
[iOS][Fixed] - Refactored RCT_handleKeyCommand to avoid concurrency issues
Reviewed By: motiz88
Differential Revision: D53186262
fbshipit-source-id: 60ae8974a9df7289395c8a9e9abe2e34e4c40309
Summary:
This API is better implemented as a component: PopupMenuAndroid. Please see the ancestor diff D52712758.
Changelog: [Android][Deprecated] Deprecate UIManager.showPopupMenu, and UIManager.dismissPopupMenu
Reviewed By: mdvacca
Differential Revision: D52887565
fbshipit-source-id: 42da6bdaa707395c5694ec8ae3eb77b64cdefb69
Summary:
In React Native 0.75, we will remove UIManager.showPopupMenu(), UIManager.dismissPopupMenu().
To replace that API, we are introducing this <PopupMenuAndroid> component. This component works in both Fabric and Paper!
For the usage, please see PopupMenuAndroidExample.js.
Changelog: [Android][Added] - Introduce PopupMenuAndroid to replace UIManager.showPopupMenu()
Reviewed By: mdvacca
Differential Revision: D52712758
fbshipit-source-id: a87628a168d64fabbcc4d0f7b694fa639a927448
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42716
Migrates this to the new flag system just added.
Made a quick change to the Android template, to mark Kotlin accessors as `JvmStatic` to make calling from Java more idiomatic.
Next diff will wire to MC.
Changelog: [Internal]
Reviewed By: rubennorte, mdvacca
Differential Revision: D53198874
fbshipit-source-id: 6ab5b279d9ac59733c6e820c25be72383ce0e54a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42626
Right now this is done by some combination of string splitting, JS side regexing, etc. This will not scale for math expressions, and gets more and more annoying when we try to add more.
In preparation for adding more units, this adds a tokenizer/lexer for a subset of CSS grammar, based on the spec. This is not hooked up to anything yet, and doesn't add a parser.
The algorithm uses a subset of the comprehensive instructions provided at https://www.w3.org/TR/css-syntax-3/#tokenizer-algorithms as a reference, with some major simplifications.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D53030661
fbshipit-source-id: c48bc572c5e02daee0b05e91830f2441528193d1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42651
Lots of boilerplate to define hash functions for different enums, so we can use them in `hash_combine`. This should not be needed, and seems like it might have been an artifact of older C++ version of standard library with bugs.
https://en.cppreference.com/w/cpp/utility/hash
> In addition to the above, the standard library provides specializations for all (scoped and unscoped) enumeration types. These may be (but are not required to be) implemented as std::hash<std::underlying_type<Enum>::type>.
Also moves `hash_combine` SFINAE to concepts for clarity and better error messages.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D53074535
fbshipit-source-id: 5fcb653dbe4aa51aa3d9d96f1511da3b7541270d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42694
D53115471 commited all the automatically fixable lints by `ANDROIDLINT`. When I looked again, closer, there was one automatic fix that I'm fairly sure is incorrect.
Before:
`outTransform.postTranslate((int) (dx + 0.5f), (int) (dy + 0.5f));`
After:
`outTransform.postTranslate((dx + 0.5f), (dy + 0.5f));`
I think the linter did this because the underlying API accepts a float, so this was (incorrectly) seen as an extraneous cast causing precision loss, but the previous behavior was using the cast and addition to round the float, instead of adding 0.5 to it.
This replaces the call with an explicit rounding, for the same behavior as before (though, I'm not sure if the rounding is intentional, since in and out are both fp).
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D53158801
fbshipit-source-id: d268a5c429663dd7da0bfce2d717589986601196
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42616
PropsParserContext is an entity in Core with a lot of baggage. We used it in graphics only to access the `surfaceId` and the `contextContainer`. We don't need to bring to graphics the whole dependencies of core due to these two parts.
This change break the dependency by passing along only the elements that we actually need.
## Changelog
[Internal] - break dependencies between graphics and core by removing the include of the PropsParserContext
Reviewed By: sammy-SC
Differential Revision: D52999204
fbshipit-source-id: a4b92fc11238f5caa63e39a6e286273ab671c8de
Summary:
## Changelog: [Internal] Generated 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
Pull Request resolved: https://github.com/facebook/react-native/pull/42709
Reviewed By: huntie
Differential Revision: D53188549
Pulled By: blakef
fbshipit-source-id: 4d5eab7d393777d14c2848b33626dfa7c3be5b02
Summary:
fixed homepage url in package.json file of community cli plugin.
## Changelog:
[GENERAL][CHANGED] - changed community cli plugin homepage url.
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/42696
Test Plan: community-cli-plugin homepage url must be opened correctly.
Reviewed By: rubennorte
Differential Revision: D53179709
Pulled By: huntie
fbshipit-source-id: 7949a897d4fe1da228fce323fa8bb32640194273
Summary:
Just small fix for those who are copy & pasting commands from error message.
## Changelog:
[INTERNAL] [CHANGED] - Update erorr message to use `npx` when calling `react-native`
Pull Request resolved: https://github.com/facebook/react-native/pull/42691
Test Plan: _
Reviewed By: cipolleschi
Differential Revision: D53177186
Pulled By: cortinico
fbshipit-source-id: e680cde81fde1f560dfeb1a85c8ad90090d69653
Summary:
Cocoapods 1.15 (https://github.com/facebook/react-native/issues/42698) current breaks the build, limit to version >= 1.13 & < 1.15
This is currently broken and affecting users, we'll remove this limit once Cocopods fixes the regression. It's currently blocking 0.73.3.
## Changelog:
[iOS][Fixed] don't allow cocoapods 1.15.
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/42702
Test Plan:
```
bundle exec pod install
```
Reviewed By: cipolleschi
Differential Revision: D53180111
Pulled By: blakef
fbshipit-source-id: 4c5dd11db6d208e8d71249443a8f85e601913abd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42690
Issues triggered by `InspectorProxy*` tests under `packages/dev-middleware` (T169943794) can be root-caused to `dev-middleware` performing Babel registration within a test run, after Jest has hooked its own transformer.
Babel registration is only required when running this code (`dev-middleware`, etc) directly from source - we already have the `BUILD_EXCLUDE_BABEL_REGISTER` mechanism to strip it out from production builds, but we currently don't prevent registration under tests, where Jest's transformer should be allowed to do its work.
This adds the same `babel-plugin-transform-define` mechanism that we use for production builds to the Jest transformer.
Changelog:
[Internal] Prevent inadvertent Babel registration during running of repo tests
Reviewed By: huntie
Differential Revision: D53125777
fbshipit-source-id: 1f0a20315c96edaf79054e29a80c7a9561e5b352
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42681
CI failures in Windows JS tests recently (https://github.com/facebook/react-native/pull/41463) were caused by the triggering of Babel registration during tests, due to an import of `packages/dev-middleware` (index), breaking subsequent transformation of other tests.
## Root cause
Example of a problematic import:
https://github.com/facebook/react-native/blob/a5d8ea4579c630af1e4e0fe1d99ad9dc0915df86/packages/dev-middleware/src/__tests__/ServerUtils.js#L15
..which triggers a Babel registration:
https://github.com/facebook/react-native/blob/a5d8ea4579c630af1e4e0fe1d99ad9dc0915df86/packages/dev-middleware/src/index.js#L16-L18
That registration behaves differently on Windows due to the `ignore: [/\/node_modules\/\]`, which doesn't match against Windows path separators - Babel matches against system separators.
In particular, this changed whether `node_modules/flow-parser` was transformed when loading the RN Babel transformer. Transforming this file causes a `console.warn` from Babel due to its size:
> [BABEL] Note: The code generator has deoptimised the styling of /Users/robhogan/workspace/react-native/node_modules/flow-parser/flow_parser.js as it exceeds the max of 500KB.
This throws due to our setup:
https://github.com/facebook/react-native/blob/a5d8ea4579c630af1e4e0fe1d99ad9dc0915df86/packages/react-native/jest/local-setup.js#L27
This all manifests as the first test following a Babel registration (within the same Jest worker) that requires the RN Babel transformer throwing during script transformation.
## This change
This is the minimally disruptive change that makes Babel registration behaviour consistent between Windows and other platforms. The more durable solution here would be *not* to rely on any Babel registration for Jest, which has its own `ScriptTransformer` mechanism for running code from source. Given the fragile way our internal+OSS Babel set up hangs together that's a higher-risk change, so I'll follow up separately.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D53124578
fbshipit-source-id: 074a8e139e506a5dceec13f07d412599fb292d92
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42675
`ANDROIDLINT` config now has a base setup for RN. This enables it in arc linter, and fixes automatically fixable issues.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D53115471
fbshipit-source-id: 2556c21770f7c7ca54d1bccfff527d39df20101e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42686
D53072714 accidentally removed this call, which sets the values for props which have duplicates, and some precedence between them.
This organization is janky, and will be removed in D53073913 where we decuple the props from Yoga style (so the precedence and parsing order becomes a lot more sane).
Changelog:
[Android][Fixed] - Restore missing call to `convertRawPropAliases`
Reviewed By: mdvacca
Differential Revision: D53144603
fbshipit-source-id: 85da722b23992ea75fb681f1db15e62a0daa2a51
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42685
This diff fixes the TextInput-textStyles-e2e test.
The rootcause of this issue is that we were updating the lineHeight of ReactEditText (AppCompatEditText) when lineHeight is set as a prop from React.
This is a problem, because one one side lineHeight is managed by React Native (setting styles in the spannables) and on the other side we ar calling setLineHeight on AppCompatEditText, which breaks the rendering.
We should only manage lineHeight using RN styles, that's why I'm removing call to super.setLineHeight()
Changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D53142429
fbshipit-source-id: cedf803171a490afa67252e9e7f83749502326e6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42628
Changelog: [iOS][Deprecated] Retrieving initial notification requires UNUserNotificationCenterDelegate setup instead of reading UIApplicationLaunchOptionsLocalNotificationKey
# how to migrate:
if you are currently using `getInitialNotification` to check the notification on an app start (warm or cold), you will need to do a migration.
have an object become the delegate of `UNUserNotificationCenterDelegate`. you can use your app's `AppDelegate` to do this.
then, override `userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:`. in the implementation, add these lines:
if ([response.actionIdentifier isEqualToString:UNNotificationDefaultActionIdentifier]) {
id module = _reactHost ? [[_reactHost getModuleRegistry] moduleForName:"PushNotificationManager"]
: [_bridge moduleForClass:[RCTPushNotificationManager class]];
if ([module isKindOfClass:[RCTPushNotificationManager class]]) {
RCTPushNotificationManager *pushNotificationManager = (RCTPushNotificationManager *)module;
pushNotificationManager.initialLocalNotification = response.notification;
}
}
# reasoning:
when you start an app from a push notification, the `UIApplicationLaunchOptionsLocalNotificationKey` in `application:didFinishLaunchingWithOptions:` will contain the notification metadata that started the app. additionally, this was stored on the bridge, which is not compatible with the new architecture. however, `UIApplicationLaunchOptionsLocalNotificationKey` has been deprecated since iOS 10, which this PR aims to address.
apple's supported API to do this is `userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:` which is on `UNUserNotificationCenterDelegate`. this is a significant change from a pull to push model. in order to make this change without having to rearchitect the product layer, we're going to store the notification on the notification native module.
another caveat is that the API follows the delegation pattern, not the listener pattern. that means we can't make our notificaiton native module the delegate here - the app will probably need `UNUserNotificationCenterDelegate` to be a top level object - usually the scope of the app delegate.
in future, i actually think we need to unify this with `handleLocalNotificationReceived:`, but right now there's forked handling between platforms and some product code is only using the pull model, so this is still the minimum change in the product layer.
Reviewed By: ingridwang
Differential Revision: D52897071
fbshipit-source-id: 579578d1b3128c5f7e81249c75cf7655b8e360e2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42684
This addressed threading issue like this:
```
Attempting to set an overrideUserInterfaceStyle from a background thread. Modifying a view controller from a background thread is not supported
```
Changelog: [iOS][Fixed] Fixed potential threading issues accessing UIKit from background in RCTAlertManager
Reviewed By: philIip
Differential Revision: D52999194
fbshipit-source-id: 8ce8a89ef932ca9b75cb93d3c9f102a6b0494580
Summary:
Move all `ReactSpan` subclasses to a separate folder.
This is a minor improvement in the context of my multi-PR work on https://github.com/react-native-community/discussions-and-proposals/issues/695.
I'm adding a new span class later, which was the direct motivation for this change.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [CHANGE] - Move all `ReactSpan` subclasses to a separate folder
Pull Request resolved: https://github.com/facebook/react-native/pull/42594
Reviewed By: mdvacca
Differential Revision: D53123733
Pulled By: cortinico
fbshipit-source-id: 10db214a520d157c231e6f3b97948b4209a7ad4b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42678
Changelog: [internal]
This is a re-application of https://github.com/facebook/react-native/pull/42430, which had to be reverted because of crashes in optimized builds on Android:
```
Abort Reason: terminating due to uncaught exception of type facebook::jni::JniException: java.lang.ClassNotFoundException: com.facebook.react.internal.featureflags.ReactNativeFeatureFlagsProvider
```
The root cause of that was that that class was removed because it wasn't statically referenced from Kotlin/Java, but it was dynamically referenced from C++ (in `ReactNativeFeatureFlagsProviderHolder.cpp`).
This applies the same changes + adds `DoNotStrip` annotations for the affected class and all its methods.
Reviewed By: huntie
Differential Revision: D53122992
fbshipit-source-id: efc4d5636a3f2d39b86e9c098bff408b6688b80b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42656
I'm bumping the NDK to 26.1. As we already have a bump lined up to 26.0 on main,
it makes sense to go to .1 as it's declared the LTS:
https://github.com/android/ndk/wiki
Changelog:
[Android] [Changed] - Android NDK to 26.1
Reviewed By: NickGerleman
Differential Revision: D53083606
fbshipit-source-id: 12290efcfa8a72ab88c21ffe9507d08d5512d61b
Summary:
We are making some decently large changes around here, to transition Fabric away from Yoga's private API, and add new units, and CSS properties. Even confined to Fabric, we have a large matrix of different paths for parsing.
This change consolidates layout props parsing to a single, tested path, used everywhere.
Concretely, this means removing:
1. MapBuffer for ViewProps
2. Iterator style props parsing (for layout props only)
MapBuffer for ViewProps to my understanding is not currently used at all, and has been live to edits, but untested, for quite some time. Iterator style props parsing is still enabled in some configurations, but we don't want to broadly ship its current form, and haven't been able to prioritize shipping it.
Both MapBuffer, and iterator style props parser, are performance wins. If we look at seriously shipping one of these again, we should look at swapping out the current path.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D53072714
fbshipit-source-id: 0a737c8c8f50b1f2c5c0b7ff0415e84a26a06abb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42673
Fix rendering of textInput using lineHeight in android API level <28 by removing call to ReactEditText.setLineHeight.
ReactEditText.setLineHeight was introduced in API level 28 and we actually don't need to call this method
changelog: [Internal] internal
Differential Revision: D53105649
fbshipit-source-id: f2d81cfea10de84bd47efbfeac1e21837fd49a11
Summary:
If Flow can be trusted, getConstantsForViewManager always gets called with a non-null string:
1. The only call-site to getConstantsForViewManager is getViewManagerConfig: [PaperUIManager.js](https://github.com/facebook/react-native/blob/822bf52c29729d25b2bfb31655cf773609a9283d/packages/react-native/Libraries/ReactNative/PaperUIManager.js#L36-L80)
2. And getViewManagerConfig always passes in a non-null string.
So, let's just make the native argument type a non-nullable string.
Thoughts?
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D52628937
fbshipit-source-id: 0ca68b38253cf134af29974af9e36380d66895a1
Summary:
This API was used by the old architecture to lazily register/load components:
1. Load a ViewManager's class from the disk
2. Register the ViewManager's class with React Native
See: [RCTUIManager lazilyLoadView](https://github.com/facebook/react-native/blob/822bf52c29729d25b2bfb31655cf773609a9283d/packages/react-native/React/Modules/RCTUIManager.m#L1546-L1591)
The new architecture **does not** support lazy loading of **legacy** modules/components.
Therefore, let's leave this API unimplemented until we decide to implement lazy loading of legacy stuff in new architecture.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D52677515
fbshipit-source-id: 8d49a0b54f901a3e9b3e8a9578ebb0c81de522d8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42434
Changelog: [internal]
The flags for the event loop were set up using different mechanisms due to the limitations of the previous feature flags systems. Now we can centralize on the new system and use them consistently on Android and iOS.
Reviewed By: RSNara
Differential Revision: D52819137
fbshipit-source-id: e30a6f2e12b4a027a906502b80a70dd48bb657b6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42430
This PR creates a new internal feature flags system for React Native. This is only meant to be used internally within the framework, but we might expose it externally in some form in the future to allow customizing specific feature flags in frameworks and applications.
Features:
* 2 types of flags:
* Common: can be overridden from native and are accessible from all layers of the stack (Objective-C/Swift, Java/Kotlin, C++ and JavaScript).
* JS-only: flags that can only be defined and accessed from JS (to allow things like hot reloading without a native build).
* 1 source of truth for each flag.
* Feature flags are application/process scoped (using C++ singletons).
See the `README.md` file in this PR for additional information.
This also adds modifies `run-ci-javascript-tests` to run a new check to make sure that the generate files are in sync with the JSON file that contains the definitions.
Changelog: [internal]
Reviewed By: huntie
Differential Revision: D52806730
fbshipit-source-id: 0ba95803f61ec2f05266ee535921321bf6d3dc6a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42655
This bug is caused by a caching issue: when the user enters a new character into the textInput: ReactTextInput 1) caches the Spannable entered by the user and 2) it updates internal Fabric state, which triggers the measurement of the TextInput component using the cached Spannable.
The problem is that the Spannable entered by the user has the wrong "styles" for the text input. Since measurement is using the cached Spannable, then the measurement of the TextInput ends up being is incorrect.
In this diff I'm fixing the bug by updating the styles (lineHeight) of the cached spannable that is cached when the user updates the TextInput.
The styles weren't updated correctly because mTextAttributes didn't have the proper style props set
Changelog:
[Android][Fixed] - Fix incorrect measurement of TextInput when new architecture is enabled
Reviewed By: javache, sammy-SC
Differential Revision: D52924982
fbshipit-source-id: ced9f2c348bdb9bf706028b1063858cebd5a071a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42659
Those folders for Java don't exist anymore, I'm removing this as it's unnecessary and will default to only src/main/java.
For resources instead, I'm using `setSrcDirs` as it will replace the default, while `srcDirs()` will add those folders.
We need to replace the default res folder as we need to follow the resource folder structure of BUCK
Changelog:
[Internal] [Changed] - Cleanup srcSet for java and res
Reviewed By: cipolleschi
Differential Revision: D53083677
fbshipit-source-id: 4dc42c700ea5446bbd49c63fc43b58ba316f4944
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42600
Disentangled the logic for emitting touches to JS on Android. `receiveTouches` should never be used as a public API, as TouchEvents can be dispatched just like any other event, and receiveTouches is an internal helper for `TouchEvent`.
Changelog: [Android][Removed] Updated migrated guidance for EventEmitter and reduced visibility of internal TouchesHelper methods
Reviewed By: cortinico
Differential Revision: D52907393
fbshipit-source-id: a8207039c863ab23a1d93dd2d2f28e8a274c8ecf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42660
Calling `maybeLoadSoLibrary` from init is too late, as we call `initHybrid` before `init`. Instead use a static initializer.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D53048065
fbshipit-source-id: dfd2957fd9209e02c498ee08e9cbd7c7a1a83c3e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42657
When the RCT_DEV flag is turned on, we force the eager initialization of the DevMenu at startup.
The initialization was happening in a method of the `CxxBridgeDelegate` protocol.
In bridgeless mode, we don't have the bridge, hence we don't call this method.
I need to put the initialization code in the `RCTIntance` because the only way I found to eagerly initialize a module was to tap into the `RCTTurboModuleManager` and, in Bridgeless mode, that's seemed to be the only way.
I'm open to move the code to a better place, anyway!
## Changelog:
[Internal] - Enable the DevMenu eagerly in Bridgeless mode
Reviewed By: sammy-SC
Differential Revision: D53083637
fbshipit-source-id: 219698eab77ed115ab0f4ea43911ae883a4c9e8a
Summary:
`RCTAttributedTextUtils.mm`: Split `NSAttributedString` creation to functions in preparation for adding new logic here.
This is a minor improvement in the context of my multi-PR work on https://github.com/react-native-community/discussions-and-proposals/issues/695.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [CHANGE] - Refactor `NSAttributedString` creation in `RCTAttributedTextUtils.mm`
Pull Request resolved: https://github.com/facebook/react-native/pull/42595
Reviewed By: cipolleschi
Differential Revision: D53001495
Pulled By: sammy-SC
fbshipit-source-id: 52d28e48f0a9d88d44325a73c64737fc7ac97781
Summary:
Increase the readability of `CustomLineHeightSpan` by making the logic less stateful.
This is a minor improvement in the context of my multi-PR work on https://github.com/react-native-community/discussions-and-proposals/issues/695.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [CHANGED] - Increase the readability of `CustomLineHeightSpan`
Pull Request resolved: https://github.com/facebook/react-native/pull/42592
Test Plan:
- Prove the equivalence of the old and the new logic
- Test that the behavior of `lineHeight` doesn't change
Reviewed By: NickGerleman
Differential Revision: D53028467
Pulled By: mdvacca
fbshipit-source-id: d533bb77c8e10c29d8f2acc8cc39565d0013b03b
Summary:
Changelog: [General][Added] Enable setNativeProps in animations in the New Architecture
Pull Request resolved: https://github.com/facebook/react-native/pull/42603
Enabling setNativeProps in animations on by default.
Reviewed By: mdvacca
Differential Revision: D52962882
fbshipit-source-id: 67921c8e36e97b7b1315dfa0d5f3bd708ccb0079
Summary:
`TextLayoutUtils`: Use named arguments to ensure same-type arguments (like `start`/`end`) are not confused
This is a minor readability follow-up to https://github.com/facebook/react-native/pull/39630.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [CHANGED] - Increase the `TextLayoutUtils` readability slightly
Pull Request resolved: https://github.com/facebook/react-native/pull/42593
Reviewed By: NickGerleman
Differential Revision: D53028402
Pulled By: mdvacca
fbshipit-source-id: 39e99ba70b93eecfc51bda19d30a5b1977cfe406
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42638
Enables these modules to be covered by `public-api-test`.
- Standardise as CommonJS modules, fixing compatibility with [`flow-api-translator`](https://www.npmjs.com/package/flow-api-translator).
- Use explicit object type in generated file template.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52963967
fbshipit-source-id: c9f3e35f70859c1b99b7297228ee2498f91d9041
Summary:
With the current ways metro location is determined, when we want to use a different metro port this requires app to be rebuild as the port and location are stored in resource file that gets compiled to R.class. The only way to avoid app rebuild due to a port change is to use shared preferences that can be accessed from dev menu, where metro URL can be specified. However, due to a separate code-paths for retrieving bundle location and for `/inspector/device` calls, the setting only applies to the former. As a consequence, you can change metro URL in the shared preferences, but debugging would only work if you use the default port or you rebuild the app with the correct port number.
This PR removes the separate code-path for retrieving inspector URL including all the dependencies scattered across different files including the gradle plugin. We then replace calls to `PackagerConnectionSettings.getInspectorServerHost` with `PackagerConnectionSettings.getDebugServerHost` which respects the shared preferences and other possible ways of configuring the port.
I decided to remove the separate inspector URL code path, as the resource value for inspector port added in https://github.com/facebook/react-native/issues/23616 was never functioning properly due to a bug. In the said PR introduced a bug in [AndroidInfoHelpers.java](https://github.com/facebook/react-native/blob/a13d51ff1c38ea85e59f4215563c0dd05452f670/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/modules/systeminfo/AndroidInfoHelpers.java#L77) where `react_native_dev_server_port` was used instead `react_native_inspector_proxy_port`. As a result the added resource value was never read.
This can be potentially a breaking change as I'm removing some public methods. However I think it is unlikely anyone relied on said methods. As a part of this PR I'm also changing occurences of removed methods from ReactAndroid.api – I don't know how to test those changes since I don't understand how this file is used as it doesn't have any references in public code.
## Changelog:
[ANDROID] [FIXED] - Make Android respect metro location from shared preferences for the debugger workflow
Pull Request resolved: https://github.com/facebook/react-native/pull/42617
Test Plan:
1. Run android app on emulator using default port
2. Check the debugger works when using "Open Debugger" option from dev menu
3. Restart metro with custom port (`--port 9090`) while keeping the app running
4. Open dev menu, click "Settings" then "Debug server host & port", put "10.0.2.2:9090" there
5. Reload the app
6. Before this change things like hot reload would continue to work while "Open Debugger" option would do nothing
7. After this change both reloading and debugging will work
Important: I haven't tested changes made to ReactAndroid.api as I don't know what this files is used for with no references in the codebase.
Reviewed By: cortinico
Differential Revision: D53010023
Pulled By: huntie
fbshipit-source-id: cc8b9c5c7e834ec9ea02b1ed5acf94f04f7b7116
Summary:
since https://github.com/facebook/react-native/commit/32dab7a63fd0795c3aaefa766aa9f818428ed2de, `DoubleConversion` is now added as an implicit dependency for 3rd party module and it breaks swift integration. this pr tries to add the `DEFINES_MODULE` to DoubleConversion.
## Changelog:
[IOS] [FIXED] - Fixed `DoubleConversion` build error from Swift integration
Pull Request resolved: https://github.com/facebook/react-native/pull/42591
Test Plan:
i'll need to test this on expo latest and react-native nightly build
```sh
# pull latest expo repo and get template tarball
$ git clone --depth 1 https://github.com/expo/expo.git
$ cd expo
$ yarn install
$ cd templates/expo-template-bare-minimum
$ npx pack --pack-destination ../../
# now create an expo app
$ yarn create expo -t blank@sdk-50 sdk50
$ cd sdk50
$ yarn add react-native@nightly
$ jq '.expo.runtimeVersion = { "policy": "appVersion" }' app.json > app.json.tmp && mv app.json.tmp app.json
$ npx expo prebuild -p ios --template /path/to/expo/expo-template-bare-minimum-50.0.17.tgz
$ cd ios
$ pod install
```
then it will show the error message:
```
[!] The following Swift pods cannot yet be integrated as static libraries:
The Swift pod `ExpoModulesCore` depends upon `DoubleConversion`, which does not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies.
```
Reviewed By: cortinico
Differential Revision: D53048352
Pulled By: cipolleschi
fbshipit-source-id: b1e27d3d26e8543a4cb2e8062c93c68543a051c5
Summary:
This PR removes the `apply_ats_config` function of ReactNativePodsUtils that was used inside `react_native_post_install` because it was preventing users from configuring `NSAllowsArbitraryLoads` to true in their projects, especially when building in CI as the plist file would be reset after running pod install.
## Changelog:
[IOS] [CHANGED] - Remove ATS config patch from react_native_post_install
Pull Request resolved: https://github.com/facebook/react-native/pull/42637
Test Plan: Edit `Info.plist`, run `pod install` and check if changes have not been overwritten
Reviewed By: cortinico
Differential Revision: D53048299
Pulled By: cipolleschi
fbshipit-source-id: 8dc335fae2e05a62daf931a50fa3f7a314e76a2e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42639
When I reverted part of the deprecation of `RCT_NEW_ARCH_ENABLED`, I forget a little bit which was breaking RCTFabric podspec.
This diff fixes that.
## Changelog:
[Internal] - Bring back `RCT_NEW_ARCH_ENABLED` to Fabric to make the `RCTThirdPartyFabricComponentsProvider` work again.
Reviewed By: cortinico
Differential Revision: D53048270
fbshipit-source-id: d21e833c10b332fb70147cc65b690f88016655e6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42396
Cmmunity reported [#42120](https://github.com/facebook/react-native/issues/42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating.
Upon investigation, I realized that:
1. The RCTDeviceInfo module is never invalidated
2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up.
This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers.
## Changelog:
[iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge
Reviewed By: RSNara
Differential Revision: D52912604
fbshipit-source-id: 1727bcdef5393b1bd5a272e2143bc65456c2a389
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42619
This is a workaround to prepare for the next diff in the stack and make sure that the modal works correctly
## Changelog
[iOS][Changed] - Add the for the dismissal snapshot only when we need it.
Reviewed By: sammy-SC
Differential Revision: D53003657
fbshipit-source-id: 6d6cc85946b1beb8e784e08a650d1247cf780228
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42587
Changelog: [Internal]
* Introduces the Target Delegate and Target Controller concepts (see `CONCEPTS.md`).
* Introduces the `PageTargetDelegate` interface and `PageTargetController` class (see doc comments).
* Uses the above infra to implement support for the `Page.reload` CDP command. Each integration provides its own `PageTargetDelegate` that knows how to trigger a reload in a platform- and architecture-specific way.
* iOS Bridge/Bridgeless and `PageTargetTest` are the only integrations that exist as of this diff, and are all updated here; Android will follow later.
NOTE: `RCTBridge` = iOS Bridge, `RCTHost` = iOS Bridgeless.
## Object lifetimes
`PageAgent` holds a raw `PageTargetController&` reference to a member of `PageTarget`, through which it gets access to that target's `PageTargetDelegate&` (another raw reference).
Here's what makes this safe:
1. **`PageTargetDelegate` outlives `PageTarget`** - this is the responsibility of the platform integration ( = the code that instantiates `PageTarget`).
2. **`PageTarget` outlives its Sessions and Agents** - this is `PageTarget`'s "moral" responsibility, even though it doesn't own its Sessions outright (`InspectorPackagerConnection` does). We add an assertion in `PageTarget`'s destructor to catch violations, and document that the integrator must call `getInspectorInstance().removePage` (which terminates all remaining sessions) before destroying the corresponding `PageTarget`.
NOTE: In upcoming diffs we'll use the new Target→Session references, currently used only for the assertion in (2), to power actual functionality (e.g. dispatching CDP events to the frontend when some imperative method is called on `PageTarget`).
## Thread safety
`PageTargetDelegate::onReload` is guaranteed to be called synchronously on the thread where messages are dispatched to `PageTargetSession`, which on iOS is the main (UI) thread.
Reviewed By: huntie
Differential Revision: D51164125
fbshipit-source-id: 4c3eeb81a8df9677c173588eb5acfd686722c3c9
Summary:
Bumping the Docker image we use to build Android from Ubuntu 20.04 to 22.04
## Changelog:
[INTERNAL] - Build Android on Ubuntu 22.04
Pull Request resolved: https://github.com/facebook/react-native/pull/42618
Test Plan: CI
Reviewed By: NickGerleman
Differential Revision: D53003492
Pulled By: cortinico
fbshipit-source-id: 547d19628e67aeb7a6d32e0a006673c909b55f32
Summary:
Clean up the function naming in `TextMeasureCache.h`. One name was clearly a human mistake. Make the naming consistent.
This is a minor improvement in the context of my multi-PR work on https://github.com/react-native-community/discussions-and-proposals/issues/695.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [CHANGE] - Clean up the function naming in `TextMeasureCache.h`
Pull Request resolved: https://github.com/facebook/react-native/pull/42598
Reviewed By: NickGerleman
Differential Revision: D52960435
Pulled By: sammy-SC
fbshipit-source-id: 01327610446933972e8dc87e1b6e2950b7c706d2
Summary:
### The problem
1. We have a library that's supported on iOS but doesn't have support for visionOS.
2. We run pod install
3. Codegen runs and generates Code for this library and tries to reference library class in `RCTThirdPartyFabricComponentsProvider`
4. Example:
```objc
Class<RCTComponentViewProtocol> RNCSafeAreaProviderCls(void) __attribute__((used)); // 0
```
This is an issue because the library files are not linked for visionOS platform (because code is linked only for iOS due to pod supporting only iOS).
### Solution
Make codegen take Apple OOT platforms into account by adding compiler macros if the given platform doesn't explicitly support this platform in the native package's podspec file.
Example generated output for library supporting only `ios` and `visionos` in podspec:

I used compiler conditionals because not every platform works the same, and if in the future let's say react-native-visionos were merged upstream compiler conditionals would still work.
Also tvOS uses Xcode targets to differentiate which platform it builds so conditionally adding things to the generated file wouldn't work.
## Changelog:
[IOS] [ADDED] - make codegen take OOT Apple platforms into account
Pull Request resolved: https://github.com/facebook/react-native/pull/42047
Test Plan:
1. Generate a sample app with a template
5. Add third-party library (In my case it was https://github.com/callstack/react-native-slider)
6. Check if generated codegen code includes compiler macros
Reviewed By: cipolleschi
Differential Revision: D52656076
Pulled By: dmytrorykun
fbshipit-source-id: c827f358997c70a3c49f80c55915c28bdab9b97f
Summary:
Those scripts are all dead, and should not be used anymore.
I'm removing them.
## Changelog:
[INTERNAL] - Remove dead android scripts
Pull Request resolved: https://github.com/facebook/react-native/pull/42612
Test Plan: n/a
Reviewed By: cipolleschi
Differential Revision: D52997852
Pulled By: cortinico
fbshipit-source-id: cf57177eedb8bc0f40daf7c6c5fcd1d5ba89ba32
Summary:
Extract fragment conversions to separate functions to make refactoring easier and simplify reasoning about the code.
This code is being modified later.
This is a minor improvement in the context of my multi-PR work on https://github.com/react-native-community/discussions-and-proposals/issues/695.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [CHANGE] - Extract fragment conversions to separate functions
Pull Request resolved: https://github.com/facebook/react-native/pull/42597
Reviewed By: NickGerleman
Differential Revision: D52960655
Pulled By: robhogan
fbshipit-source-id: 0df62b9980c06a1c2fc113d645ba8b6b668fa394
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42411
X-link: https://github.com/facebook/yoga/pull/1562
I added a small regression D52605596, where negative border would not be correctly floored. This fixes that, and starts adding tests specifically targeting the computed style API, now decoupled from the yoga node.
Reviewed By: joevilches
Differential Revision: D52930827
fbshipit-source-id: e165dade705a8de54c92d65f3664c9081137788c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42410
Changelog: [Internal]
Properly compiling these files out so we don't need to pull in SocketRocket to startup
Long term, we need to lift DevSupport and Inspector directories out of ReactInternal target
Reviewed By: fkgozali
Differential Revision: D52890707
fbshipit-source-id: efe59092d8f5487ab3f62ffb4ebd2b8aa58399fe
Summary:
X-link: https://github.com/facebook/yoga/pull/1561
Back when I introduced the inline functions that would get the edge according to the writing direction I swapped some instances of `setLayoutPosition` which wrote to the flexStart edge erroneously. We should basically never read from some inline style and write to the flex edge. This changes them all to use the flex values.
Reviewed By: NickGerleman
Differential Revision: D52921401
fbshipit-source-id: 92b74d652018596134c91827806272ed7418ef6c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42400
Changelog: [Internal]
TSIA - iOS counterpart of D52040149 on Android.
The overarching principle is that nothing outside of an Agent should be doing anything with the CDP message stream. Here we have a case of `RCTInspectorDevServerHelper` basically impersonating the CDP frontend in order to paper over an apparent lifetime management bug in the old backend; this gets in the way of implementing reloads natively so we disable it under the new backend.
NOTE: I'm gating out both the call site in `RCTBridge` (to signal intent) *and* the actual body of `disableDebugger` (in case any out-of-tree code happens to be using this method).
Reviewed By: voideanvalue
Differential Revision: D50967799
fbshipit-source-id: 759718bf155b8b16c7db54ac2d2507bc71c93436
Summary:
This change removes Content-Length header from proxy inspector response.
The presence of this header was resulting in the response being cropped under some circumstances because of erroneously calculated length.
The `Content-Length` header value represents the number of bytes in the response. In the code, `string.length` was used to calculate that value, but in JavaScript it gives the number of characters in a string instead of its size in bytes. Specifically, if there are some UTF characters in the string that occupy more than byte, there would be a mismatch in this size. This mismatch resulted in the response being cropped.
The easiest way to reproduce this problem is to set the simulator name to contain a two-byte UTF character.
This change works according to the HTTP spec, which states that when Content-Length is not present, the end of the response stream indicates the end of the response. Since in the code `response.end(data)` is use, it terminates the stream and hence there is no need to provide the length in the header.
## Changelog:
[GENERAL] [FIXED] - fix issue with debugger not working when device name contain two-byte UTF characters
Pull Request resolved: https://github.com/facebook/react-native/pull/42590
Test Plan:
1. Change your iOS simulator name to contain some two-byte UTF character (for example this one: "–")
2. Run metro and connect your app with it
3. Go to http://localhost:8081/json/list in your browser – see the response being marked invalid as it is cropped
4. Apply the change and see that the resulting JSON in the response is now correct
5. Open debugger workflow to confirm it sees the connected device
Reviewed By: robhogan
Differential Revision: D52958725
Pulled By: motiz88
fbshipit-source-id: 92c32893cbbf8552237585d824e4a44737fa3968
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42388
This was our last call site still using the legacy `dispatch` API.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D52906894
fbshipit-source-id: b1c838ee695ce4c60aaed409e7dc46a0dd3f6c2e
Summary:
Over in React Native macOS land, I opened https://github.com/microsoft/react-native-macos/pull/2030 to update our mono repo to use Yarn 4. As a side effect, all the `package.json` files are formatted as a side effect of running `yarn install`. So that React Native macOS doesn't maintain this diff (and because they should only be good / no harm), let's upstream the formatting changes.
## Changelog:
[INTERNAL] [CHANGED] - Format package.json files in the monorepo
Pull Request resolved: https://github.com/facebook/react-native/pull/42256
Test Plan: This change should be a no-op, CI should pass.
Reviewed By: cortinico
Differential Revision: D52727623
Pulled By: huntie
fbshipit-source-id: 67862b16d576b0903abd91e016d7add4c19853dc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42394
Changelog: [Internal][iOS] - Enable stub modern CDP backend in Bridge behind a feature flag
Minimally integrates the stub native CDP backend implementation (D50936932) into iOS Bridge.
This integration registers itself as a "Modern" target (D50967794, D50967795) to instruct `inspector-proxy` to disable its CDP hacks related to source map fetching, reloads, etc. This gives us a mostly-clean slate on which to develop and test native CDP functionality.
Reviewed By: huntie
Differential Revision: D50951138
fbshipit-source-id: 8c5ad9207e73265595884380c91e38f8d0ead84d
Summary:
Changelog: [Internal][iOS] - Enable stub modern CDP backend in Bridgeless behind a feature flag
Minimally integrates the stub native CDP backend implementation (D50936932) into iOS Bridgeless.
This integration registers itself as a "Modern" target (D50967794, D50967795) to instruct `inspector-proxy` to disable its CDP hacks related to source map fetching, reloads, etc. This gives us a mostly-clean slate on which to develop and test native CDP functionality.
Pull Request resolved: https://github.com/facebook/react-native/pull/42393
Test Plan:
1. `js1 run`
2. Enable the modern CDP backend by grafting D52844391
3. Enable Bridgeless in RNTester by grafting D52910646
4. `buck2 install rntester-ios`
5. Dev Menu -> Open Debugger
6. Observe console message self-identifying the backend + iOS Bridgeless
7. Observe that the debugger stays connected when the app is reloaded (albeit without doing anything very interesting just yet)
{F1329876835}
Reviewed By: huntie
Differential Revision: D50936931
Pulled By: motiz88
fbshipit-source-id: ff8f919d0370266aea2916da349520bc76d690ab
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42294
This changes enables the Fabric Intrerop Layer automatically for all the users.
Practically I'm removing the fallback `ComponentDescriptor` inside the `ComponentDescriptorRegistry` so that if a component hasn't been automatically registered by a user, instead of showing the UnimplementedView, it loads a `UnstableLegacyViewManagerAutomaticComponentDescriptor`.
This ComponentDescriptor is built starting from the legacy component name, and responds with correct `ComponentName` and `ComponentHandle` (similarly to the `UnstableLegacyViewManagerInteropComponentDescriptor` but without using C++ templates).
Changelog:
[Internal] [Changed] - Fabric Automatic Interop for Android
Reviewed By: sammy-SC
Differential Revision: D52663244
fbshipit-source-id: f466486c638bb1362ef59128cd69bb9731bb9739
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42402
Now that we have 2 top level directories for JS files in the `react-native` package, we need to choose where to put the native module and native component specs, because our current infra only supports a single directory.
The options we had are:
1. Keep specs in the current directory (`Libraries`). This is a problem because it encourages us to keep adding modules in this "deprecated" directory.
2. Move specs to the new `src` directory. This requires moving the current files, but from now only we can create new specs in a private directory.
3. Modify the infra to allow multiple directories. This changes the public API for something it's likely only going to be used here.
In this PR I went for option 2) because it's the most future-proof, even though it requires a little bit more work now. I created a script to automatically copy all the specs for modules and components to `src/private/specs/components` and `src/private/specs/modules`, and changed their current locations to serve as a proxy for the new location (to avoid breaking a potentially public API).
`src/private/specs` isn't meant to be their final location. We should probably still colocate native module/component specs with the rest of their code, but we can do so when we move the code from `Libraries` to `src/private`.
Changelog: [internal]
Reviewed By: cortinico
Differential Revision: D52919566
fbshipit-source-id: 6de8a2d2b6077e4f884386567721c6bd2b88a5d3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42386
The new DOM APIs are completely private at the moment, so they make them a good candidate to test the new directory structure (and make sure everything works correctly in CI, etc.). This moves those files to `src/private/dom`.
Changelog: [internal]
Reviewed By: huntie
Differential Revision: D52875998
fbshipit-source-id: c6c96eedcc54d47e3afff98fa2d912f9d83f3460
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42385
This adds support for having JS files in a `src` directory within the `react-native` package. The plan is to have 2 subdirectories there:
* `react-native/src/private` for private modules, with any nested directories (e.g.: `react-native/src/private/dom/nodes/ReadOnlyNode.js`).
* `react-native/src/public` for public modules, without nested directories. The plan is that the individual modules created in this directory will be public through the index module or directly via something like `react-native/View` (mapped to `react-native/src/public/View`, or a `dist` directory in the published npm package—details TBD).
The enforcement of private modules being inaccessible from outside the `react-native` package will be added soon by huntie.
Changelog: [internal]
Reviewed By: huntie
Differential Revision: D52875999
fbshipit-source-id: 914ed806f2cb86857e2cb7b760292c2190b5b14e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42585
Just a minor bump of AGP to 8.2.1
Changelog:
[Internal] [Changed] - Bump AGP to 8.2.1
Reviewed By: NickGerleman
Differential Revision: D52912324
fbshipit-source-id: 2856861f2ccedb3470a0fa548a31dd36252924c3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42131
X-link: https://github.com/facebook/yoga/pull/1534
Now that the storage method is a hidden implementation detail, this changes the underlying data structure used to store styles, from `CompactValue` (a customized 32-bit float with tag bits), to `StyleValuePool`.
This new structure operates on 16-bit handles, and a shared small buffer. The vast majority of real-world values can be stored directly in the handle, but we allow arbitrary 32 bit (and soon 64-bit) values to be stored, where the handle then becomes an index into the styles buffer.
This results in a real-world memory usage win, while also letting us store the 64-bit values we are wanting to use for math function support (compared to doubling the storage requirements).
This does seem to make style reads slower, which due to their heavy frequency, does have a performance impact observable by synthetics. In an example laying out a tree of 10,000 nodes, we originally read from `StyleValuePool` 2.4 million times.
This originally resulted in a ~10% regression, but when combined with the changes in the last diff, most style reads become simple bitwise operations on the handle, and we are actually 14% faster than before.
| | Before | After | Δ |
| `sizeof(yoga::Style)` | 208B | 144B | -64B/-31% |
| `sizeof(yoga::Node)` | 640B | 576B | -64B/-10% |
| `sizeof(YogaLayoutableShadowNode) ` | 920B | 856B | -64B/-7% |
| `sizeof(YogaLayoutableShadowNode) + sizeof(YogaStylableProps)` | 1296B | 1168B | -128B/-10% |
| `sizeof(ViewShadowNode)` | 920B | 856B | -64B/-7% |
| `sizeof(ViewShadowNode) + sizeof(ViewShadowNodeProps)` | 2000B | 1872B | -128B/-6% |
| "Huge nested layout" microbenchmark (M1 Ultra) | 11.5ms | 9.9ms | -1.6ms/-14% |
| Quest Store C++ heap usage (avg over 10 runs) | 86.2MB | 84.9MB | -1.3MB/-1.5% |
Reviewed By: joevilches
Differential Revision: D52223122
fbshipit-source-id: 990f4b7e991e8e22d198ce20f7da66d9c6ba637b
Summary:
A first step in my work on https://github.com/react-native-community/discussions-and-proposals/issues/695
De-duplicate the code for creating `Spannable` on Android. I'm planning to add quite serious new features to this module. This would be really hard with the current level of code duplication.
## Changelog:
[INTERNAL] [CHANGED] - De-duplicate building `Spannable` on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/39630
Test Plan: I tried to ensure that the refactored code is relatively easy to prove to be equivalent to the original duplicated one, but there's always a risk of a human mistake in this process. So far, I have been testing this by ensuring that nothing broke in the `Text` example section in RNTester.
Reviewed By: mdvacca
Differential Revision: D51016244
Pulled By: NickGerleman
fbshipit-source-id: e9f873c01b2af0685c7b0943aebea170c997d22e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42399
Mark CallInvokerHolder APIs as FrameworkAPI only, these APIs are meant to be used only for partner frameworks
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D52913739
fbshipit-source-id: 5a2c8be629e90a33e0cfb66b28e0171c71f5940d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42387
Changelog: [Internal]
Documents that it's legal for a Page's connection function to return null, and adds new logic to `InspectorPackagerConnection` (NOTE: to the C++ implementation *only*) to handle this case without crashing.
The legacy RN CDP backend (`ConnectionDemux`) has a case similar to this that causes crashes depending on the timing of connection requests.
Reviewed By: cortinico
Differential Revision: D52905490
fbshipit-source-id: 2102adc859d1509647a31f92737a1e164781fadf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42384
Changelog: [Internal]
Similar to D52894171, adds a console log message identifying the specific CDP backend integration, based on an optional `SessionMetadata` object passed to `PageTarget::connect()`. This is helpful during development+rollout as we will have 4+ such call sites (iOS/Android, Bridge/Bridgeless).
Reviewed By: huntie
Differential Revision: D52905488
fbshipit-source-id: d26aae1d07c2c42965498a81f03d826de98fa222
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42383
Changelog: [Internal]
During development / experimental rollout of the modern CDP backend, it can be helpful to have a user-visible message that makes it clear that the new backend is in use. Here, we add one using the [`Log.entryAdded`](https://chromedevtools.github.io/devtools-protocol/tot/Log/#type-LogEntry) CDP event. We also add some styling using [ANSI escape sequences](https://developer.chrome.com/docs/devtools/console/format-style#style-ansi) to make the message stand out from normal application logs.
We could have used [`Runtime.consoleAPICalled`](https://chromedevtools.github.io/devtools-protocol/tot/Runtime/#event-consoleAPICalled) instead, but:
1. `Runtime.consoleAPICalled` requires an `executionContextId` which is not available at the `Page` level (it is a concept that's managed closer to the instance/VM), and it's slightly cleaner if we don't have to send a fake context ID.
2. It's slightly easier to follow the CDP dispatching logic / grep for relevant code if we use `Log` for "system logs" (from the Page) and reserve `Runtime` for real application logs from the instance/VM.
NOTE: We'll probably want to remove this before the stable release.
Reviewed By: huntie
Differential Revision: D52894171
fbshipit-source-id: 3208e01f2ee31acef2e8cd58767f40ad724c9a39
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42397
Changelog: [Internal]
Adds a stub `PageTarget` class to serve as the entry point to the modern CDP backend in React Native.
The primary method exposed by `PageTarget` is `connect()` which is designed to fit directly as a connection callback passed to `InspectorPackagerConnection::addPage()`. This constructs a `PageTargetSession` containing a `PageAgent` where the actual CDP message handling/routing will occur. For now, `PageAgent` implements no CDP methods, and always responds with a "not implemented" error.
Basic unit tests are included, though we might want to migrate to a more integration-style test suite (with fewer mocks and real bindings to RN) once we've implemented more of the protocol.
## What is a Page
In Chrome's implementation of CDP, a Page represents a single browser tab. A Chrome DevTools session connects to one Page at a time (though it can potentially inspect multiple JavaScript contexts owned by that Page, such as those found in frames and workers).
In our system, a Page will correspond 1:1 to React Native's concept of a *Host* (implemented as `RCTHost`, `RCTBridge`, `ReactHostImpl` or `ReactInstanceManager`, depending on the platform). In all cases, the Host is the object that has a stable identity across reloads, and manages the lifetime of an *Instance* where the JSVM and other application state lives. There can be multiple Hosts in a React Native process, though this is somewhat unusual; those would be treated as independent "tabs" from the perspective of the debugger.
NOTE: The concepts of Target, Session and Agent are new (to this codebase) and are *broadly* inspired by the [corresponding Chromium / V8 concepts](https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/public/devtools_protocol/#Agents_Targets-and-Sessions), though some details differ.
## Next steps
Each core platform implementation in React Native (iOS Bridgeless, iOS Bridge, Android Bridgeless, Android Bridge), as well as out-of-tree platforms that want to support the new debugger, will need to create and register a `PageTarget` instance. We'll do this piecemeal in subsequent diffs.
We'll also gradually add APIs and logic to `PageTarget` / `PageAgent` to allow us to implement some "interesting" CDP methods - some of them directly (e.g. handling reload commands) and others by dispatching to nested agents (e.g. a JS debugging agent powered by Hermes).
Reviewed By: huntie
Differential Revision: D50936932
fbshipit-source-id: ebe5856d7badb361d4971dd9aabeb9982f8aed1b
Summary:
Recently inside React Native Community CLI we added bumping Yarn version inside `init` command, more information here: https://github.com/react-native-community/cli/pull/2134. In this Pull Request I added required rules in `.gitignore` for new projects created.
## Changelog:
[GENERAL] [ADDED] - Add Yarn files to `.gitignore` in template
Pull Request resolved: https://github.com/facebook/react-native/pull/42313
Test Plan:
1. Follow [Contributing guide](https://github.com/react-native-community/cli/blob/main/CONTRIBUTING.md) from React Native Community CLI repository to setup locally newest version of CLI.
2. Run this command:
```sh
node /path/to/react-native-cli/packages/cli/build/bin.js init --template path/to/template
```
3. Appropriate should be ignored.
Reviewed By: NickGerleman
Differential Revision: D52907962
Pulled By: cortinico
fbshipit-source-id: f12dce8836e7e94257f8c690434b11227aa46446
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42254
X-link: https://github.com/facebook/yoga/pull/1550
This change aims to simplify how we resolve edges. This operation happens many, many times, and has gotten complex and slow when paired with StyleValuePool.
This starts reshaping so that `yoga::Style` can resolve a style prop for a given edge. This is closer to the ideal computed style API to avoid recalcing this so many times, but doesn't address that.
This relies on removing the errata related to row-reverse, and cleans up the removal started in the last change.
This has no measurable perf effect under CompactValue, but has a >10% uplift in perf when using StyleValueHandle, where we can trivially check if a handle points to a defined value without resolving it, but only within `yoga::Style` since we don't expose the handle outside of it.
More quantifiably, we go from 2.35 million StyleValuePool reads to 993k. The rest are checks on the handle.
Reviewed By: joevilches
Differential Revision: D52605596
fbshipit-source-id: 0b366963a899e376f99ce3d75cd5f14a25d60cec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42314
X-link: https://github.com/facebook/yoga/pull/1555
The next diff moves a bunch of methods to `yoga::Style`. This renames the function to be a tad bit shorter, for more readable callsites. It also makes it more consistent with style property getters.
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D52803393
fbshipit-source-id: 557df34a9f0fb0ee42ad23b1fda99c1e0eb1d4e3
Summary:
This removes the 4 ineffective and redundant entries from the `exclude` list in `tsconfig.json` (`typescript-config` package).
These entries have no effect as they are relative to the typescript-config package. Explained in detail here: https://github.com/tsconfig/bases/issues/207
A newly generated RN app shows this config:
```
$ yarn tsc --showConfig | grep -A 5 exclude
"exclude": [
"node_modules/tsconfig/react-native/node_modules",
"node_modules/tsconfig/react-native/babel.config.js",
"node_modules/tsconfig/react-native/metro.config.js",
"node_modules/tsconfig/react-native/jest.config.js"
]
```
Clearly, none of these files exist, therefore to remove ambiguity and reduce the complexity of the config, they should be removed.
## Changelog:
[GENERAL] [REMOVED] - Remove ineffective excludes from typescript-config
Pull Request resolved: https://github.com/facebook/react-native/pull/42375
Test Plan:
- Create new RN app (`npx react-native init`), install dependencies, run `yarn tsc`
- It works
- Recreate config, but _without_ the `exclude` section
- Everything works exactly the same
Reviewed By: huntie
Differential Revision: D52904713
Pulled By: NickGerleman
fbshipit-source-id: d1d6f65b164053f9a1e611022178ced032a38aef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42390
Changelog: [Internal]
Add an optional mechanism for inspector pages to be registered with the "modern" or "legacy" type (defaulting to legacy). This is aligned with the inspector-proxy implementation of the `type` property in D50967795.
NOTE: This mechanism is experimental, only takes effect if `InspectorPackagerConnection.cpp` is in use, and will likely evolve before the RN 0.74 branch cut.
Reviewed By: huntie
Differential Revision: D50967794
fbshipit-source-id: e7521267dfc0b0811c4d369e63f4f1756ce22d60
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42380
Changelog: [Internal]
Makes it explicitly legal to call `IRemoteConnection`'s methods from any thread when used as part of the C++ implementation of `InspectorPackagerConnection`.
Implementation details:
* This relies on `InspectorPackagerConnectionDelegate::scheduleCallback` being thread-safe and handling any necessary synchronisation (which is already required for the existing `reconnect()` use case).
* We add *very basic* tracking of *sessions* within `InspectorPackagerConnection` to make sure events don't leak from one `RemoteConnection` instance to the next.
* In the future we'll want to build on this to properly allow multiple concurrent sessions to a single page. That's not the primary goal here though.
Reviewed By: rubennorte
Differential Revision: D52807388
fbshipit-source-id: 6900386a1f047c99f15dc91597f308c82adf5281
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42362
This undos a change of CallInvokerHolder bringing it back in the public package: https://github.com/facebook/react-native/commit/b7191cde4e36
The problem is that if a developer wants to use the C++ CallInvokerHolder to schedule work on the JS thread from C++, they're forced to import the `.internal`
Java/Kotlin class.
Plus this is going to be a massive breaking change for the ecosystem:
https://github.com/search?type=code&q=%2Fimport.*CallInvokerHolderImpl%2F
So unless we come with a clear deprecation/replacement path, I'm undoing this change for now.
Changelog:
[Internal] [Changed] - Undo move of CallInvokerHolder to `.internal`
Reviewed By: cipolleschi
Differential Revision: D52873256
fbshipit-source-id: 900c3170ed2100ec706b03112bc23a0ba0171bcc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42358
Just converting those two classes to Kotlin as I was going over them.
Changelog:
[Internal] [Changed] - Convert InteropEvent and InteropEventEmitter to Kotlin
Reviewed By: javache
Differential Revision: D52869490
fbshipit-source-id: 2d585dd3d21dc89c5e55de645e9519d36f67b849
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42360
In cases where you merge out-of-tree platforms like react-native-windows with react-native mobile JS files, codegen awareness of the Windows suffix is useful. This helps prevent the creation of generated code for iOS and Android in mixed out-of-tree platform folders.
## Changelog
[Internal]
Reviewed By: mdvacca
Differential Revision: D52873212
fbshipit-source-id: ad6b1471e63d68057f54c79141123fb15f8aab5e
Summary:
X-link: https://github.com/facebook/yoga/pull/1558
Pull Request resolved: https://github.com/facebook/react-native/pull/42318
AbsolutePositioning -> AbsolutePositioningCatchAll
A bit more clear. This errata is for various issues with positioning absolute nodes. There really isn't a clear description as to what specifically this enables/disables, so I just opted to say "catch all" to indicate that this controls various bugs
Reviewed By: NickGerleman
Differential Revision: D52820117
fbshipit-source-id: 80b77832baf65e68e57ca523c418422dd346ef0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42317
Added a complicated zIndex test and corresponding screenshot test for it.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52439963
fbshipit-source-id: 54bc8cfc9aa2e3c985279fe43027b3db88057c68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42316
We need to change the typing to allow for 'static'. An issue here is that Paper will not have `static` due to missing z-index logic. Unfortunately, we cannot create a fabric-only version of the typing as we cannot have conditional elements of the same name in ts. To remedy this we took out the parsing of the string 'static' in Paper. Instead we will just emit a warning and default to `relative`.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D51431524
fbshipit-source-id: 0444b2f8432f172b2e8a084b307b0e624dba8085
Summary:
X-link: https://github.com/facebook/yoga/pull/1556
Pull Request resolved: https://github.com/facebook/react-native/pull/42315
Since we aim to ship static to all users of yoga (not just XPR), we need to remove the errata that is gating most of the features. This should be a non breaking change. To ensure that, I added a new errata which, if on, will use the inner size of the containing node as the containing block. This is how it has been for a while and resolving this is risky and time consuming so for the time being we will stick with that.
Reviewed By: NickGerleman
Differential Revision: D52706161
fbshipit-source-id: 30a93f29cb0d97b20b2947eaa21f36cdc78c4961
Summary:
X-link: https://github.com/facebook/yoga/pull/1549
Pull Request resolved: https://github.com/facebook/react-native/pull/42253
This experimental feature is always false, and with the next diff I will be deleting the branch that actually calls into this. Separating this diff out to simplify the review process.
Reviewed By: NickGerleman
Differential Revision: D52705765
fbshipit-source-id: 705f4aa297eae730af9b44753eb01c9dec385dcf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42308
Changelog: [Internal]
Guarantees cleanup of `ILocalConnection` when the associated page is unregistered from `IInspector`.
NOTE: This only applies to the C++ version of `InspectorPackagerConnection`. The legacy pure-Java and pure-ObjC implementations are of this class are unchanged.
In the upcoming modern CDP backend architecture, this will help guarantee the validity of Target references (specifically PageTarget) held by Agents (specifically PageAgent), without introducing unnecessary shared ownership and dynamism.
Reviewed By: hoxyq
Differential Revision: D52786331
fbshipit-source-id: 162425d6435246a95ac9c076bc5c59a34f331f16
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42304
Changelog: [Internal]
Light refactor of `InspectorImpl`'s storage from two separate maps (one of them with tuples for values!) to a single map of objects.
Reviewed By: hoxyq
Differential Revision: D52786335
fbshipit-source-id: a49466ed7189fd032e486319bbdf77097a30885f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42301
Changelog: [Internal]
To simplify testing and rolling out the modern CDP backend in React Native, let's require the use of the C++ version of `InspectorPackagerConnection` whenever the modern CDP backend is in use, regardless of the `InspectorPackagerConnection` rollout setting.
Reviewed By: hoxyq
Differential Revision: D52786334
fbshipit-source-id: 5c12794e3faa2c094a23f69a5677f66905d1763e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42355
`RemoveDeleteTreeUIFrameCallback` operated directly on the view to clean up its children, which does not correctly account for subviews which have been clipped because they're outside the visible frame.
Changelog: [Android][Added] Added `removeAllViews` to IViewGroupManager.
Reviewed By: jehartzog, sammy-SC
Differential Revision: D52834835
fbshipit-source-id: fb7f07a17d07467eecd3ce9721afc2f3abcc0caa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42302
Changelog: [Internal][Added] Support launching experimental debugger frontend for CDP targets marked as "modern"
See the definition of "modern" targets in D50967795.
Reviewed By: hoxyq
Differential Revision: D52786332
fbshipit-source-id: 13718e9ddf3ec050049ef7ec9a77f6cf1a7f82ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42303
Changelog: [Internal]
Adds a coarse-grained mechanism to `inspector-proxy` for distinguishing between legacy and modern debug targets. The guiding principles are:
1. `inspector-proxy` does not interfere in the CDP message stream between the debugger frontend and a modern target, or in the lifecycle of a target.
2. Legacy runtimes (current React Native, React Native Desktop, etc) that rely on `inspector-proxy`'s existing invasive semantics must continue to work seamlessly for now. We'll decide on the right time to deprecate/remove this legacy code in the future.
NOTE: This is an experimental addition to the proxy protocol that may be replaced at any time.
Reviewed By: hoxyq
Differential Revision: D50967795
fbshipit-source-id: bb9c39a8fe755ef3661e2c61507dd324d8dc8894
Summary:
Added `--custom-resolver-options` to `--bundle` command. This options is also [available](https://github.com/facebook/metro/blob/main/docs/CLI.md#options) in Metro's CLI.
## Changelog:
[INTERNAL] [ADDED] - Add `--resolver-options` to `bundle` command
Pull Request resolved: https://github.com/facebook/react-native/pull/42333
Test Plan:
1. Build all packages by running `yarn build` in the root
2. Go to `packages/rn-tester` and run `npx react-native bundle --custom-resolver-options key=value` and the options should be passed to the Config.
Reviewed By: blakef
Differential Revision: D52869452
Pulled By: huntie
fbshipit-source-id: 9a2c2d94b72cfb47477cf58b9c0472c5a8551c84
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42282
Changelog: [Internal] `inspector-proxy` now assumes each app will report pages with locally unique IDs.
In order to simplify some upcoming logic changes in `inspector-proxy`, in this diff we begin to enforce the assumption that each app ( = platform-specific implementation of `InspectorPackagerConnection`) assigns a locally unique ID to each inspector page. The inspector proxy will silently drop page descriptors that have conflicting IDs, and log a message to `debug()`.
NOTE: As an implementation detail, integrators may use `DEBUG=Metro:InspectorProxy` to see debug messages from `inspector-proxy`.
Reviewed By: huntie
Differential Revision: D50969752
fbshipit-source-id: a4e6faa91d97594fc5343ce4bee66233523cd175
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42271
Changelog: [Internal]
Adds a util function to determine the `TurboModuleMethodValueKind` based on the `jsi:Value` type
Reviewed By: javache
Differential Revision: D52761045
fbshipit-source-id: de937cda67198aad962e63f41ccd42be6c00c0b8
Summary:
`UIMenuController` is deprecated as of iOS 16. https://github.com/facebook/react-native/commit/e08a1973f67d85acc157111c749c43572469e4c2 migrated a usage into an `available` check. However, it does not properly fall back to the deprecated API in the "else" block of the availability check, instead it uses an early return. It seems this means Xcode still sees the API as used, and spits out a deprecated warning. Let's just refactor the code so we don't have that anymore.
## Changelog:
[IOS] [FIXED] - Remove an early return to suppress a deprecated API warning for `UIMenuController`
Pull Request resolved: https://github.com/facebook/react-native/pull/42277
Test Plan: CI should pass.
Reviewed By: cipolleschi
Differential Revision: D52785488
Pulled By: sammy-SC
fbshipit-source-id: 0b47e8aa8d7c94728e3d68332fbb8f97f8ded34e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42328
This method was deprecated in 0.72. We're going to remove it in 0.74
Technically a breaking change, but users should not be using this method at all at this point.
Changelog:
[Android] [Removed] - Remove deprecated DefaultNewArchitectureEntryPoint.load overload
Reviewed By: mdvacca
Differential Revision: D52802644
fbshipit-source-id: f7c1db783959d93b81407847377f805d7ee2602d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42329
As the title says, this checks against illegal configurations of ReactFeatureFlags in DefaultNewArchitectureEntrypoint
and let the app crash if the user specified and illegal configuration
Changelog:
[Internal] [Changed] - Prevent illegal configurations of ReactFeatureFlags in DefaultNewArchitectureEntrypoint
Reviewed By: mdvacca
Differential Revision: D52802609
fbshipit-source-id: 7bc0a08c17430d7fd2448f65838ce47fad738883
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42327
This diff is the result of running
`buck2 run //xplat/js/scripts/rn-api:generate-rn-api-metadata`
After this lands, `react-native-android-breaking-change-detector` will actually be green again, after the previous diff fixed the infra setup.
Changelog: [General][Fix] Update stale ReactAndroid.api values after CI breakage
Reviewed By: cortinico, mdvacca
Differential Revision: D52800160
fbshipit-source-id: b96533baa1cb704ad43482d7a52db50e6dce9821
Summary:
This PR introduces the `vision` interfaceIdiom to check if the app runs on visionOS.
An update to the documentation should follow this change.
## Changelog:
[IOS] [ADDED] - Introduce `vision` interfaceIdiom
Pull Request resolved: https://github.com/facebook/react-native/pull/42243
Test Plan: This change has been used in `react-native-visionos` and the interfaceIdiom changes **only** when running in the non-compatibility mode. But it's still useful to have this upstream if at some point React native would compile to visionOS natively
Reviewed By: cortinico
Differential Revision: D52730028
Pulled By: cipolleschi
fbshipit-source-id: 711c5c2c6c7fe05b3ff8da7383b5e63e9e04acfa
Summary:
X-link: https://github.com/facebook/yoga/pull/1553
Pull Request resolved: https://github.com/facebook/react-native/pull/42274
Separate from `YGConfigSetPrintTreeFlag` we have a public API `YGNodeSetPrintFunc` which sets a function called, if you manually change a constant in source code during debugging.
This is not debug-only, is exposed as part of the public API (without a way to turn it on from the public API), and takes up a pointer per node doing nothing.
I'm not aware of anyone recently using the capability, and the tracing/event related work done since then would be more powerful for this anyway.
Remove the API.
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D52767445
fbshipit-source-id: f72927b47cffa4fe6fe886b42f07cc1ba55f141e
Summary:
1. Modal onDismiss is not working on iOS (Fabric).
2. Modal onDismiss is currently only available on iOS. On Android, we don't have a way to know when exactly a modal is dismissed.
Currently, the onDismiss is emitted using a device event as a workaround to the RCTModalHostView unable to receive the component event as it's already unmounted when visible is false.
This PR removes the workaround and keeps RCTModalHostView mounted until the onDismiss event is emitted from the host and sends the onDismiss event on Android.
bypass-github-export-checks
## Changelog:
[ANDROID] [ADDED] - Added support for Modal onDismiss prop
[IOS] [FIXED] - Fix onDismiss is not working on Fabric
[General][Breaking] - The public API of Modal has changed. We don't have anymore a NativeModalManger turbomodule; RCTModalHostViewNtiveComponent's Prop does not require to pass an identifier anymore.
Pull Request resolved: https://github.com/facebook/react-native/pull/42014
Test Plan:
1. Run rn-tester
2. Open the Modal example
3. The second example shows the counter for the show and dismiss count
4. Show and dismiss the modal and verify the count is incremented correctly
https://github.com/facebook/react-native/assets/50919443/108bfb26-c8f6-43b2-ac40-f0b46e48771b
Reviewed By: javache, sammy-SC
Differential Revision: D52445670
Pulled By: cipolleschi
fbshipit-source-id: f419164032c3bef67387200778b274299bf0659f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42306
Internally, we have some computationally expensive checks in Debug mode when running Fabric.
However, these are not very useful in OSS and they were the cause of some issues which generated noise.
With this change, we are enabling those checks only in the Meta specific builds and making sure that the OSS won't incur in that cost.
## Changelog
[Internal] - Disable expensive Fabric checks when running Fabric in OSS
Reviewed By: cortinico, sammy-SC
Differential Revision: D52543696
fbshipit-source-id: 697f14fd21e884f293ea7cee8ee16fff73764996
Summary:
There seems to be a lot of `TARGET_OS_UIKITFORMAC` macro in React Native that don't need to be there. Let's remove them.
First off, what is `TARGET_OS_UIKITFORMAC` targeting? You might think it's [Mac Catalyst](https://developer.apple.com/mac-catalyst/), if you look at the [commit](https://github.com/facebook/react-native/commit/3724810d2168eb182db24acf9e741775df27ae13) introducing the ifdefs. However.. that doesn't seem right because `TARGET_OS_MACCATALYST` exists, and is used elsewhere in the codebase. In fact, if you look at this handy comment inside `TargetConditionals.h` (the file that defines all these conditionals), `TARGET_OS_UIKITFORMAC` is not even on there!
```
/*
* TARGET_OS_*
*
* These conditionals specify in which Operating System the generated code will
* run. Indention is used to show which conditionals are evolutionary subclasses.
*
* The MAC/WIN32/UNIX conditionals are mutually exclusive.
* The IOS/TV/WATCH/VISION conditionals are mutually exclusive.
*
* TARGET_OS_WIN32 - Generated code will run on WIN32 API
* TARGET_OS_WINDOWS - Generated code will run on Windows
* TARGET_OS_UNIX - Generated code will run on some Unix (not macOS)
* TARGET_OS_LINUX - Generated code will run on Linux
* TARGET_OS_MAC - Generated code will run on a variant of macOS
* TARGET_OS_OSX - Generated code will run on macOS
* TARGET_OS_IPHONE - Generated code will run on a variant of iOS (firmware, devices, simulator)
* TARGET_OS_IOS - Generated code will run on iOS
* TARGET_OS_MACCATALYST - Generated code will run on macOS
* TARGET_OS_TV - Generated code will run on tvOS
* TARGET_OS_WATCH - Generated code will run on watchOS
* TARGET_OS_VISION - Generated code will run on visionOS
* TARGET_OS_BRIDGE - Generated code will run on bridge devices
* TARGET_OS_SIMULATOR - Generated code will run on an iOS, tvOS, watchOS, or visionOS simulator
* TARGET_OS_DRIVERKIT - Generated code will run on macOS, iOS, tvOS, watchOS, or visionOS
*
* TARGET_OS_EMBEDDED - DEPRECATED: Use TARGET_OS_IPHONE and/or TARGET_OS_SIMULATOR instead
* TARGET_IPHONE_SIMULATOR - DEPRECATED: Same as TARGET_OS_SIMULATOR
* TARGET_OS_NANO - DEPRECATED: Same as TARGET_OS_WATCH
*
* +--------------------------------------------------------------------------------------+
* | TARGET_OS_MAC |
* | +-----+ +------------------------------------------------------------+ +-----------+ |
* | | | | TARGET_OS_IPHONE | | | |
* | | | | +-----------------+ +----+ +-------+ +--------+ +--------+ | | | |
* | | | | | IOS | | | | | | | | | | | | |
* | | OSX | | | +-------------+ | | TV | | WATCH | | BRIDGE | | VISION | | | DRIVERKIT | |
* | | | | | | MACCATALYST | | | | | | | | | | | | | |
* | | | | | +-------------+ | | | | | | | | | | | | |
* | | | | +-----------------+ +----+ +-------+ +--------+ +--------+ | | | |
* | +-----+ +------------------------------------------------------------+ +-----------+ |
* +--------------------------------------------------------------------------------------+
*/
```
Going even deeper into `TargetConditionals.h`, you will see `TARGET_OS_UIKITFORMAC` defined... and it's always 1 when `TARGET_OS_MACCATALYST` is 1, making it feel even more redundant. My current conclusion is it's either another variant of Mac Catalyst (the one where they just run unmodified UIKit maybe..), or it's an older macro back from when Catalyst was still experimental.
Either way, it's pretty obvious nobody is running or testing this codepath, and it adds bloat, especially to React Native macOS where we have extra ifdef blocks for macOS support (and eventually visionOS support). Let's remove it.
Another change I made while we're here:
I've seen this lingering TODO to replace setTargetRect:InView: / setMenuVisible:animated: (deprecated as of iOS 13, below our minimum OS requirement) with showMenuFromView (deprecated as of iOS 16, in line with the availability check). Let's just.... do that?
## Changelog:
[IOS] [REMOVED] - Remove TARGET_OS_UIKITFORMAC macros
Pull Request resolved: https://github.com/facebook/react-native/pull/42278
Test Plan:
RNTester with Mac Catalyst still compiles:

Reviewed By: cipolleschi
Differential Revision: D52780690
Pulled By: sammy-SC
fbshipit-source-id: df6a333e8e15f79de0ce6f538ebd73b92698dcb6
Summary:
This PR adds `get_folly_config()` to RCTAppDelegate, it was recently introduced here: https://github.com/facebook/react-native/issues/42153
## Changelog:
[INTERNAL] [CHANGED] - Unify folly version and compiler flags for RCTAppDelegate
Pull Request resolved: https://github.com/facebook/react-native/pull/42281
Test Plan: CI Green
Reviewed By: NickGerleman
Differential Revision: D52783503
Pulled By: cipolleschi
fbshipit-source-id: d1497371e84618f93abe8f7fab7ee0cdf5296d27
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42291
In case someone tries to inline out-of-tree platform files with react-native JS Libraries files, it's useful to suppress issues with public API tests, as the public APIs are not intended to match yet.
## Changelog
[Internal]
Reviewed By: christophpurrer
Differential Revision: D52790636
fbshipit-source-id: 7bbaf8ae6d9571ed7d81d06ab4b82f67f518c5a0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42300
Changelog: [Internal]
The version of the `keyword-spacing` lint rule we have installed is apparently buggy. Either way it's unnecessary since we use Prettier.
Reviewed By: christophpurrer
Differential Revision: D52799550
fbshipit-source-id: 2e199938d45c554039b2117163fd403f236bf752
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42267
In case anyone was to try linting the react-native repo with desktop out-of-tree platform files there, this makes things easier.
## Changelog
[Internal]
Reviewed By: christophpurrer
Differential Revision: D52746379
fbshipit-source-id: d59a1c1f9c84c6bee529d6bdd151a7ba680b6680
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42119
Changelog: [Internal]
- Updated spec for native commands of the DebuggingOverlay to have `Array` annotation instead of a workaround with string (and serialization)
- Removed serialization in JS and deserialization on native
Reviewed By: javache
Differential Revision: D51985222
fbshipit-source-id: 3dc5a049ae4984565df9ea32fa181c5885b79539
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41842
Changelog: [Internal]
- bumps `react-devtools-*` packages to 5.0.0 across xplat
- added support for highlighting multiple host components, when hovering over component, which is represented by multiple host fibers.
See test plan, this can be reproduced with a named component, which renders multiple host components inside a React Fragment:
```
<>
<View />
<View />
<View />
</>
```
Reviewed By: gsathya
Differential Revision: D51888628
fbshipit-source-id: 2bd2d9fa50c24f478aa9406ee6bb42a47168bf13
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41843
Changelog:
[General] [Fixed] - inspected elements from React DevTools are now correctly highlighted on a relevant surfaces
For cases when DOM Node APIs are not available (Paper or Fabric without these APIs), we will use newly added `isChildPublicInstance` from renderer.
Similarly to D51713089, this updates implementations to highlight elements only on a single AppContainer.
Reviewed By: javache
Differential Revision: D51822874
fbshipit-source-id: d5992abed5ec6f11f04d2e1e6e6928c2a66aef7c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41818
Changelog: [Internal]
Use `parentElement` API to find lowest AppContainer ancestor, which will be responsible for highlighting an inspected element or rendering trace updates frames on the screen.
Reviewed By: sammy-SC
Differential Revision: D51713089
fbshipit-source-id: d6d07481679484a518a05b58d4394999876ea7d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41816
Changelog: [Internal]
Forking implementations for trace updates and element highlights from React DevTools: modern and legacy.
Both implementations will later solve the same problem of highlighting the component only on a single AppContainer, but with different approaches:
- Modern will be based on DOM Node APIs: `getBoundingClientRect` and `parentElement`.
- Legacy will be based on `isChildInstance` from renderer and `measure`.
All corresponding API call will be added in a separate diff later on top of these changes.
Reviewed By: sammy-SC
Differential Revision: D51713087
fbshipit-source-id: 1c840d711a541085b1075711f737a8dbc1e31637
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41749
Changelog: [Internal]
- Each trace update frame will have its own unique id, which will be the react tag of the corresponding host fiber.
- Based on these ids, previous frames will be rerendered, not
just removed once new frames are sent from React DevTools.
- Imagine a case when there are 2 components on the screen: the first one rerenders once in a second and the second component rerenders much more frequently, each 5 milliseconds. With our previous implementation, update frames for first component will be removed once the second component has been rerendered.
- Each frame will have a lifetime for 2 seconds, it resets if frame with the same id was sent again from JS (basically component rerendered again, while we were highlighting it).
Android demo:
https://pxl.cl/3Vllz
Reviewed By: sammy-SC
Differential Revision: D51708054
fbshipit-source-id: 7abff9c1a334dccb3a1c08a46487d4bb99cdc448
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41746
Changelog: [Internal]
Now using previously added `highlightElements` and `clearElementsHighlights` commands.
[Improvement] Since DebuggingRegistry is a singleton, it will only subscribe to the React DevTools events once and not *number-of-rendered-AppContainers* times.
All required functionality for highlighting elements on a single AppContainer will be added in one of the next diffs of this stack, changes are incremental.
Reviewed By: sammy-SC
Differential Revision: D51708053
fbshipit-source-id: f94a1bb1f5b876a153d305eeacf65b8a5eca2a08
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41745
Changelog: [Internal]
Support `highlightElements` and `clearElementsHighlights` commands in `DebuggingOverlay` native components.
These later will be used for highlighting inspected component in React DevTools. These commands unblock highlighting elements on the native side, currently we do it on JS side and it mutates the React tree.
We still need to serialize the array before passing it to the native command, because codegen doesn't support it yet.
Reviewed By: javache
Differential Revision: D51603861
fbshipit-source-id: da837b0fc32e36980f207166a679fb8124ff6100
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41744
Changelog: [Internal]
With these changes:
- DebuggingRegitry is responsible for listening to the events from React DevTools and
- AppContainer renders DebuggingOverlay component and subscribes with its reference to the DebuggingRegistry
- [Improvement] Since DebuggingRegistry is a singleton, it will only subscribe to the React DevTools events once and not *number-of-rendered-AppContainers* times
All required functionality for highlighting elements on a single AppContainer will be added in one of the next diffs of this stack, changes are incremental.
Reviewed By: sammy-SC
Differential Revision: D51603860
fbshipit-source-id: 92b029eb54ef63b27af970770eb522915578a0b9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41743
Changelog: [Internal]
There will be a single DebuggingRegistry instance per runtime, which will be responsible for finding lowest AppContainer ancestor for highlighted component.
It will receive refs to root views (ancestors, AppContainers) as subscriptions and later will call all necessary methods.
In the next series of diffs, subscriber will also provide reference to the DebuggingOverlay, on which DebuggingRegistry can call all necessary methods to highlight elements.
Reviewed By: rshest
Differential Revision: D51536787
fbshipit-source-id: e89f9d466a7e7833733981ff0d3ce2dbe349aaaa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42249
Changelog: [Internal]
Manually patching public React renderers artifacts to include `isChildPublicInstance` method, which was added in https://github.com/facebook/react/pull/27783.
To identifly the required changes in code I've ran a diff for 2 commits:
1. The one with the changes
2. Its parent
FB implementation were synced in D51816108.
Reviewed By: sammy-SC
Differential Revision: D52697885
fbshipit-source-id: c62af6e89e8da3ee6f6c7264bacf6e96030e9db8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42285
Changelog: [Internal]
Having a static import of `ReactFabric` blocks from using `ReactNativeElement` class for Paper-only applications.
Although DOM Node APIs are Fabric-only, the ability to use `instanceof ReactNativeElement` is a nice tool for gating purposes, which currently can't be used because of the static import.
Reviewed By: rubennorte
Differential Revision: D52784886
fbshipit-source-id: 705c6ce0b5912d9857d730ebf1e1ecf629e2b8af
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42247
With this change I make `ReactNativeConfig` a JNI class loaded at Fabric Loading time.
This removes the default from `EmptyReactNativeConfig.java` and makes sure we do read the defaults from C++ `ReactNativeConfig.cpp` file.
Changelog:
[Internal] [Changed] - Make ReactNativeConfig a JNI Class
Reviewed By: motiz88
Differential Revision: D52696653
fbshipit-source-id: 99d5e37c65e0e59efcee2c857bb94194fb40d87d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42287
Changelog: [Internal]
`run-ci-e2e-tests.js` currently skips past package build errors and tries to keep going. At best, this fails somewhere downstream of a build error (without any clear diagnostics as to why). At worst, this can miss errors entirely.
Here we extend the script's existing error handling behaviour to cover errors during the build script. It's probably worth following up to make sure all unexpected failures bubble up and stop the script, as opposed to the current error-swallowing default.
Reviewed By: hoxyq
Differential Revision: D52785131
fbshipit-source-id: 08deedfdf5b3d3cb63e77c74b47eb75570a58fbb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42248
I'm duplicating the AndroidManifest.xml file internally/externally as Gradle is really unhappy with it (and gets really noisy):
- It contains a package declaration which should be removed
- It contains a uses-sdk which should also be removed
Changelog:
[Internal] [Changed] - Fix AndroidManifest.xml for RN-Tester in OSS
Reviewed By: christophpurrer
Differential Revision: D52694108
fbshipit-source-id: bb88e6f58cc8cf3a624be4b58bb409535a283a77
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42265
Adds a snapshot test against the `react-native` package which emits the shape of all Flow-typed modules under `Libraries/`, as an approximation of the public JS API.
This provides:
- Visibility for maintainers on any PR which changes the shape of the public API.
- An at-a-glance diff of changed APIs between React Native versions (useful for library integrators and the Release Crew).
Note — **workflow change**: Maintainers modifying public files/function signatures under Libraries/ will need to run `yarn jest -u` and commit the updated snapshot changes.
Changelog: [Internal]
Reviewed By: TheSavior, philIip, mdvacca
Differential Revision: D52729777
fbshipit-source-id: 90ca2924b50205485b6d49e52a2889d8e00a43b9
Summary:
X-link: https://github.com/facebook/yoga/pull/1547
Pull Request resolved: https://github.com/facebook/react-native/pull/42251
Yoga has an odd behavior, where `start`/`end` edges under row-reverse are relative to flex-direction, instead of writing direction.
While Yoga doesn't actually document what this behavior is supposed to be, it goes against CK documentation, historic RN documentation, and the behavior valid on the web. It is also applied inconsistently (e.g. sometimes only on container, sometimes on child). It really is a bug, instead of an intended behavior.
We changed the default behavior for Yoga, but left the existing one behind an errata (so existing fbsource users got old behavior). We have previously seen this behavior show up in product code, including CK when running on FlexLayout.
`row-reverse` is surprisingly uncommon though:
1. Litho has <40 usages
2. RN has ~40 usages in `RKJSModules`,~30 in `arvr/js`, ~6 in `xplat/archon`
3. CK has ~80 usages
4. NT has ~40 usages
There are few enough, mostly simple components, that we can inspect through each of them, looking for signs they will hit the issue (at the potential chance of missing some).
CK accounts for 10/14 usages that I could tell would trigger the issue, since it only exposes start/end edge, and not left/right. It might make sense to make it preserve behavior instead, to reduce risk a bit.
FlexLayout is now separately powering Bloks, which wasn't surveyed, so I didn't touch CK behavior under Bloks.
There could also be other usages in other frameworks/bespoke usages, and this has implications for OSS users. But based on our own usage, of many, many components, this seems rare.
Changelog:
[General][Breaking] - Make `start/end` in styles always refer to writing direction
Reviewed By: pentiumao, joevilches
Differential Revision: D52698130
fbshipit-source-id: 2a9ac47e177469f30dc988d916b6c0ad95d53461
Summary:
Original commit changeset: 9305bc56ba6b
Original Phabricator Diff: D52642168
bypass-github-export-checks
changelog: [Android][Fix] Backout fix that prevented scroll event in nested scroll when scrollEnabled = false, due to causing bugs when interacting with keyboard events
Reviewed By: bvanderhoof, arushikesarwani94
Differential Revision: D52736596
fbshipit-source-id: fa8c5c598e049cc58410892813825852c431eee4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41978
I'm revering the removal of ReactModule codegen.
We are postpoinging the removal of the codegen for the future, the reasons are:
- resources: the experiment that removes the codegen shows neutral metrics, but the codegen is shared between bridge and bridgeless, so we will need to implement and test the removal for bridge and we don't have the time to do this right now.
- reduce fragmentation: we don't want to fragment NativeModules configuration between bridge and bridgeless, doing so will bring a lot of confusion to developers
- we don't want to introduce a public APIs in 0.73 that we know they are not used in production for now, we better remove these "unstable" apis before 0.74 cut
Note: I'm updating ReactAndroid.api because this is an intended change of APIs which were not part of 0.73 and we don't want them to be part of 0.74.
changelog: [internal] internal
Reviewed By: RSNara
Differential Revision: D52223650
fbshipit-source-id: 681bf5e4aab776505f64b1972a6ace6340db4587
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42259
At the end of last year, we reduce build fragmentation in iOS making sure that we were always building both architecture.
In the process, we break the semantic od RCt_NEW_ARCH_ENABLED flag, making several libs stop working in one of the two archs.
This change should restore the semantic, so libraries that were using RCT_NEW_ARCH_ENABLED to run conditional code will still work in the same way. While doing so, I also removed the new USE_NEW_ARCH as we don't want unnecessary flags
## CHANGELOG:
[iOS][Fixed] - Bring the old RCT_NEW_ARCH_ENABLED semantic back for compatibility
Reviewed By: cortinico
Differential Revision: D52727792
fbshipit-source-id: e211b10e7885eada83dd2886375575133ca76c8c
Summary:
Yesterday we landed a change that removed tests for the Old Architecture for RNTester.
That was the right call as there are no build differences in RNTester between the two architectures. But we do have runtime differences, and we had an integration test running on RNTester that we deleted with the previous PR.
This change restores that test, adding this only new job to run that test
## Changelog:
[Internal] - Add back an old arch integration test
Pull Request resolved: https://github.com/facebook/react-native/pull/42262
Test Plan: CircleCI is green
Reviewed By: cortinico
Differential Revision: D52730661
Pulled By: cipolleschi
fbshipit-source-id: 10fbc2540abeebc72f635451f6f650827cf20041
Summary:
This PR fixes issue in `RNTester` causing labels and image background to not be visible in dark mode in `SnapshotExample`
It also fixes issue with description in `Header` not being visible in other components examples when using dark mode
Before & After
<img width="505" alt="image" src="https://github.com/facebook/react-native/assets/56474758/ce87df69-4b79-48a0-b9be-4a7335329b78">
## Changelog:
[INTERNAL] [FIXED] - Fix dark mode in SnapshotExample in RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/41222
Test Plan:
1. Launch `RNTester` with dark mode enabled
2. Open `Snapshot / Screenshot` example
3. All labels should be visible, image background should have white color
Reviewed By: cortinico
Differential Revision: D52685754
Pulled By: NickGerleman
fbshipit-source-id: 72f79be45d9c65e307553832592563461a64ff1d
Summary:
As discussed with cipolleschi, RNTester shouldn't be tested for Old Arch. This PR removes those unnecessary pipeline runs
## Changelog:
[INTERNAL] [REMOVED] - remove old architecture pipeline for RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/42245
Test Plan: CI Green
Reviewed By: cortinico
Differential Revision: D52694176
Pulled By: cipolleschi
fbshipit-source-id: a607bac4659b0611d5f49b5e45134f896bb96a91
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42230
While developing Xcode 15, Apple reimplemented the linker.
In Xcode 15.0, the linker was making old iOS (< 15) crash when they were built using Xcode 15.
To fix that, we make Apple create new compiler flags (`-ld_classic`) to have a backward compatible linker.
In Xcode 15.1, Apple fixed that behavior, so the flags should not be required anymore.
But now, if we pass `-ld_classic` to the linker and we have an app that is using `use_framworks!`, that app crashes at startup.
This change remove the flags if the Xcode that is used is 15.1 or greater.
*Note:* The previous change added the flags to Hermes as well. I tested this fix in a configuration where Hermes has the flags and React Native does not, and it works. So we are removing the flags only from React Native.
This Fixes https://github.com/facebook/react-native/issues/39945
## Changelog:
[Internal] - Do not add the `-ld_classic` flag if the app is built with Xcode 15.1 or greater.
Reviewed By: cortinico
Differential Revision: D52658197
fbshipit-source-id: 37d6bc895921c0fc3661f301870477191e7e42b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42185
We've rolled out some changes to the behavior here, mainly that throttling no longer happens by default on iOS.
This updates the documentation, in concert with https://github.com/facebook/react-native-website/pull/3971
Changelog:
[General][Changed] - Update API docs for scrollEventThrottle
Reviewed By: javache
Differential Revision: D52516092
fbshipit-source-id: 7be1d6e1bc62f38c795b64ad4be5d5c1b23bb742
Summary:
## Stack
These can suss out some real bugs, and helps further avoid mismatch with downstream MSVC on /W4 as used by MSFT.
I enabled the families of warnings, but suppressed some major individual warnings that weren't clean. But I did clean some up, notably, missing initializer, and shortening 64 bit to 32 bit. We can do some of the rest incrementally (e.g. `-Wunused-parameter` has a fixit).
This change illuminates that MapBuffer is missing 64 bit integer support, but we often pass 64 bit counters to it, which is a bug. For now I just left TODOs around those.
`rn_xplat_cxx_library` is used for external libraries interfacing with RN, which we probably don't want to police, so I structured these stricter warnings as an opt-in flag, only enabled for our own rules.
## Diff
This fixes up source code to avoid emitting the extra warnings now enforced. Of what is enabled, this is mostly shortening 64 to 32, or missing field in initializer.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D52589303
fbshipit-source-id: 11cb778d065799fd0ead3ae706934146d13500bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42214
These methods are only used in the legacy React renderer. The Fabric renderer calls into different methods. So, let's just leave these unimplemented.
NOTE: I introduced the warning back into clearJSResponder, because I couldn't find the internal call-site to it.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D52449787
fbshipit-source-id: bd001c0ca4a3e64aaaf6328b3322025b09ee6da9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42218
## Changes
This diff makes the native view config interop layer on Android lazy.
As in: ViewManagers that were registered lazily with React Native will no longer be eagerly initialized by the nvc interop layer.
Changes to UIManager apis:
- UIManager.getConstants() now **only** contains the view configs for the eager view managers.
- UIManager.getConstantsForViewManager(name): lazily load view configs for lazy components
- UIManager.getDefaultEventTypes(): load default event types
- UIManager.getConstants().LazyViewManagersEnabled: true, if there are lazy view managers
- UIManager.getConstants().ViewManagerNames: a list of the lazy view managers
Changelog: [Internal]
Reviewed By: dmytrorykun
Differential Revision: D52399280
fbshipit-source-id: d9cd46de0507ecfe6cca5595a237e1063f60fa62
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42213
This improves resiliency of the native view config interop layer.
In open source, some packages might provide ViewManagers eagerly, while others might them lazily.
This also fixes another problem: Prior, eager view managers would be created **then destroyed *wastefully*** by the native view config interop layer.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D52399003
fbshipit-source-id: 3345c82789f1ed8e613139a8323dac4b4a01d173
Summary:
This diff should not change any behaviour.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D52399000
fbshipit-source-id: 976f5740c53d58ceead7d2bc4c9e0eb3f97ebb4e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42215
This diff should not change any behaviour.
**Why:** This logic is only used once from the UIConstantsProviderManager. So, let's just inline it. Inlining this method will make ReactInstance.java have fewer private methods, which'll make ReactInstance.java easier to read.
**Concern:** Inlining this method into ReactInstance's constructor will make the constructor too hard to read.
- I think it'll be fine: we will simplify this method significantly in D52399003.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D52399002
fbshipit-source-id: 8c0dc69af86109da8144546347eecd2e01c0e0be
Summary:
When a FlatList is in side a scroll view (think Netflix style navigation), the DPAD up/down fires on the scroll view, despite scrollEnabled={false} being set. This additiontially conflicts with any custom scroll event that has been created.
## Changelog:
[Android] [Fixed] - fix: prevent scroll event in nested scroll when scrollEnabled={false}
Pull Request resolved: https://github.com/facebook/react-native/pull/42219
Test Plan:
I tested this by making a ScrollView with FlatList of opposite scrolling direction inside with basic card layouts.
Both had scrollEnabled={false}
I scrolled the ScrollView myself as it has multiple rows using:
```
const scrollToItem = React.useCallback(
(itemIndex: number): void => {
const targetScrollY = itemIndex * height
scrollViewRef.current?.scrollTo({ y: targetScrollY, animated: true })
},
[height]
)
React.useEffect(() => {
// Row 0, is global nav, but it's also the first row of cards
// when we scroll to "1" what we mean is global nav is hidden
// we should still be showing the first row of items.
scrollToItem(rowIndex <= 1 ? 0 : rowIndex - 1)
}, [rowIndex, scrollToItem])
```
Reviewed By: NickGerleman
Differential Revision: D52642168
Pulled By: mdvacca
fbshipit-source-id: 9305bc56ba6b03b04b9f69a14d433593cab2025e
Summary:
`compose-source-maps.js` fails if `-o` is not specified when it should output the composed source map.
## Changelog:
[GENERAL] [FIXED] - Fix `compose-source-maps.js` failing if `-o` is not specified when it should output the composed source map
Pull Request resolved: https://github.com/facebook/react-native/pull/42203
Test Plan:
Tested this in an internal repo. This was the output before this fix:
```
% node node_modules/react-native/scripts/compose-source-maps.js dist/main.jsbundle.map dist/main.jsbundle.hbc.map
node:internal/streams/writable:472
throw new ERR_INVALID_ARG_TYPE(
^
TypeError [ERR_INVALID_ARG_TYPE]: The "chunk" argument must be of type string or an instance of Buffer or Uint8Array. Received undefined
at _write (node:internal/streams/writable:472:13)
at Writable.write (node:internal/streams/writable:494:10)
at Object.<anonymous> (/~/node_modules/.store/react-native-virtual-c8e66dddc1/node_modules/react-native/scripts/compose-source-maps.js:64:20)
at Module._compile (node:internal/modules/cjs/loader:1376:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1435:10)
at Module.load (node:internal/modules/cjs/loader:1207:32)
at Module._load (node:internal/modules/cjs/loader:1023:12)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:135:12)
at node:internal/main/run_main_module:28:49 {
code: 'ERR_INVALID_ARG_TYPE'
}
Node.js v20.10.0
```
Reviewed By: christophpurrer
Differential Revision: D52650438
Pulled By: arushikesarwani94
fbshipit-source-id: b8f8f01fb6d843887d874a7283a1a6807c7762e7
Summary:
Dependency on `chalk` was introduced in https://github.com/facebook/react-native/pull/37510, but was never declared. In pnpm setups, the CLI fails to run because of this.
This needs to be picked to 0.73.
## Changelog:
[GENERAL] [FIXED] - Declare missing dependency `chalk`
Pull Request resolved: https://github.com/facebook/react-native/pull/42235
Test Plan: n/a
Reviewed By: huntie
Differential Revision: D52660337
Pulled By: cortinico
fbshipit-source-id: 1cd45fcff72045c127773566a27103f1b38262b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42233
This diff removes the need for providing the `ios_folder` argument to `use_react_native`. We no longer do any manual path tranformations to get the iOS project root.
Instead we use `Pod::Config.instance.installation_root` which always points to the correct directory.
Changelog: [iOS][Breaking] - CocoaPods: remove the `ios_folder` argument from the `use_react_native` function.
Reviewed By: cipolleschi
Differential Revision: D52659429
fbshipit-source-id: 67c79cd9d74a0351ad2c242b74cbd48b6bd2dc94
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42207
In open source, with the new architecture, layout animations are **always** enabled.
They cannot be disabled.
Therefore, when this UIManagerModule method is called with false, just report an error. That way, if layout animations were explicitly disabled on Android, the developer will know, when they try to enable the new architecture.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D52349297
fbshipit-source-id: 7969bd7294ce7369643004e5ff7e0c1ed4a59cd6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41998
Now the error message propts people to turn on the interop layer.
And, it adds more details to the suggestion to use hasViewManager(viewManagerName).
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D52002909
fbshipit-source-id: 80ea60b4f6a5fe15d773bb1f3f41de5ce43d6652
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42067
These methods should not be implemented in the new architecture.
The **only** code that called these UIManagerModule methods was the paper renderer. And the New Architecture should instead use the Fabric renderer.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D52345416
fbshipit-source-id: 76511aa97e5dfa938aca658af03fb43122547df1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41997
Many methods on PaperUIMangaer are iOS only.
Many methods on PaperUIManager are Android only.
This diff makes sure that BridgelessUIManager only exports Android methods on Android, and iOS methods on iOS.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D52012876
fbshipit-source-id: 6527048083eae93577a58d4b77f0645fab84217f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42200
Changelog: [Internal]
Quick hack to make it easy to determine whether a given build of React Native is using the C++ implementation of InspectorPackagerConnection or the legacy platform-specific implementation.
For now, we just append this information to the `title` field. Ultimately, rather than polluting the title, this should be an inert capability flag that gets reported via `inspector-proxy`. I'm not doing that yet since we have work in the pipeline to set up a proper capability flag system soon.
Reviewed By: huntie
Differential Revision: D52629415
fbshipit-source-id: a4e873f4be78ae49b35b94fd5d41d0e2efc02dbe
Summary:
PR https://github.com/facebook/react-native/pull/42159 was working but it was the wrong fix.
The right fix is to use the `"PUBLIC_HEADERS_FOLDER_PATH"` Xcode build setting instead.
bypass-github-export-checks
## Changelog:
[iOS][Changed] - Revert "Update Yoga.podspec: fixes archiving for macos catalyst on react-native 0.73.1 in xcode"
## Facebook:
Original commit changeset: 21b9b3568986
Original Phabricator Diff: D52624342
Reviewed By: arushikesarwani94
Differential Revision: D52656133
fbshipit-source-id: 84a37fe3fca57d5e34139c17c6c1957fe8d40aaf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42165
This will help avoid a name collision when we remove the new suffix from newGetOrCreateReactInstanceTask.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D52495532
fbshipit-source-id: 79a04cff51eef07b91876a1351b8444654a79274
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42187
Updates the docblocks for `Pressability` and `usePressability`, as suggested in the code review for {D52388699}.
Changelog:
[General][Changed] Updated Pressability/usePressability Docblocks
Reviewed By: sammy-SC
Differential Revision: D52604388
fbshipit-source-id: e82dd6caa46fe69281e996cbdb8b8e5105b46955
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42194
Apps that have multiple concurrently running React instances may suffer from issues where tearing down one instance affects the bindings / LongLivedObjectCollection instance of another due to the use of static getter for LongLivedObjectCollection. This should allow host platforms, e.g., react-native-windows (which still forks the TurboModuleBinding C++ files [here](https://github.com/microsoft/react-native-windows/tree/main/vnext/ReactCommon/TEMP_UntilReactCommonUpdate/react/nativemodule/core/ReactCommon) for the reasons already mentioned) to manage per instance LongLivedObjectCollections.
## Changelog
[Internal]
Reviewed By: christophpurrer
Differential Revision: D52581170
fbshipit-source-id: 791e3baeefaf23f544eeddd5a216735535523a9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42037
Creates an Objective-C wrapper around the C++ version of `InspectorPackagerConnection` (introduced in D52134592), and uses it in React Native iOS apps (behind an internal flag that is off by default).
In future work, the flag will be turned on by default, then deleted, and eventually the legacy `RCTInspectorPackagerConnection` code will be deleted from React Native.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D52225495
fbshipit-source-id: f1b9657ef0d665cf7892c15c34c5104e2777ec43
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42018
Creates an JNI wrapper around the C++ version of `InspectorPackagerConnection` (introduced in D52134592), and uses it in React Native Android apps (behind an internal flag that is off by default).
In future work, the flag will be turned on by default, then deleted, and eventually the legacy `InspectorPackagerConnection.java` code will be deleted from React Native.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D52231237
fbshipit-source-id: 5a0e3bd8b2b711c1c592db15c51df4c3cc89aaad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42197
Some std::ranges functions don't work well (or at all) when using
clang, eg see
https://fb.workplace.com/groups/474291069286180/posts/9724112847637243
This works in clang 16, but not clang 15 which fbcode is on. Note that more complicated parts of ranges work, but not these simpler helpers, funnily enough :).
As I'm trying to make RN compile in fbcode, I need clang to work.
Moving them back to iterators, but using rbegin/rend making it fairly readable still.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52481786
fbshipit-source-id: f37d4e1912b33eee392061dc787afaacd9554409
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42153
This non functional change unifies Folly version and compiler flag in a single function, so that it would be easier to update it in the future.
## Changelog:
[Internal] - Unify folly version and compiler flags
Reviewed By: cortinico
Differential Revision: D52564771
fbshipit-source-id: 9b4b50560ddee05ce50465b6854666572148cb25
Summary:
This PR tries to fix a build error when `import <React/RCTAppSetupUtils.h>` from *.m files. Since the `[[deprecated("")]]` syntax is a C++14 feature and it was placed inside the `RCT_EXTERN_C_BEGIN` block. If the file in imported from Objective-C *.m files or Swift files, it will have a syntax error. Instead of using the C++ syntax, this PR uses the `__deprecated_msg()` statement that is also used in other code in react-native and that is C supported syntax.
bypass-github-export-checks
## Changelog:
[IOS] [FIXED] - Fix RCTAppSetupPrepareApp.h import error from Objective-C *.m files
Pull Request resolved: https://github.com/facebook/react-native/pull/42172
Test Plan:
- test building and importing **RCTAppSetupPrepareApp.h** from a *.m file
- test `RCTAppSetupPrepareApp(application, turboModuleEnabled)` will show a compile warning
Reviewed By: arushikesarwani94
Differential Revision: D52603421
Pulled By: cipolleschi
fbshipit-source-id: bfec8d0ba6378a265ad30dd8ca1d3ab15cff96ed
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42191
X-link: https://github.com/facebook/yoga/pull/1539
React native supports transforms and if a node has a transform it will [form a containing block for absolute descendants regardless of position type](https://developer.mozilla.org/en-US/docs/Web/CSS/Containing_block#identifying_the_containing_block). So we need to pass that information into Yoga to ensure this happens.
The verbiage for the field "alwaysFormsContainingBlock" is very specific. In a vacuum a node cannot simply "form a containing block". It only forms a containing block in reference to a different node. This can be illustrated in a scenario where we have a static node that is a flex container which has 1 absolute child and 1 relative child. This static node will form a containing block for the relative child but not the absolute one. We could just pass the information on rather something has a transform or not but Yoga is not supposed to know about transforms in general. As a result we have a notion of "always" forming a containing block. Since Yoga is a flexbox spec, non-absolute nodes' containing blocks will ways be their parent. If we add something like a transform to a node then that will also apply to absolute nodes - hence we can say the node will **always** form a CB, no matter who is the descendant.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52521160
fbshipit-source-id: bab9319ffddec617f5281823930f2a00cc2967f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42190
Essentially undoing D51182861 that was put in place to support adding a default position type to Fabric. Previously I had already removed the code that set the default to something other than Yoga default, but I did not remove all this extra code that allows you to do that. Since we no longer need this we should remove it so as not to encourage messing with the defaults in such a way that they differ from Yoga defaults.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52515993
fbshipit-source-id: fb4ab726cf73bf08fd6aa44b99196962a9839694
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42189
tsia, we had the equality op defaulted so might as well do this for inequality
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52515802
fbshipit-source-id: ce31a00eddda991221c91364508fed6df78fd5b4
Summary:
Adds changelog for the 0.73.2 release.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [CHANGED] - Add changelog for the 0.73.2 release.
Pull Request resolved: https://github.com/facebook/react-native/pull/42186
Test Plan: Read the changelog 🤞
Reviewed By: huntie
Differential Revision: D52604441
Pulled By: lunaleaps
fbshipit-source-id: 3d67da6d8ff1e3afe9a875bd38eb851fc28cd7ac
Summary:
In my mac, I use a case-sensitive volume and when I build a react-native 0.73 project it failed with an error that can't find the hermes release tarball to extract:
```
Node found at: /usr/local/bin/node
Preparing the final location
Extracting the tarball
tar: Error opening archive: Failed to open '/Volumes/Workspace/meet-art-link/ios/Pods/hermes-engine-artifacts/hermes-ios-0.73.1-Release.tar.gz'
```
Note the `...-Release.tar.gz` in the error. In the disk it's `...-release.tar.gz`.
The build fails in after download the release tarball in release mode because the hermes tarball name in the `replace_hermes_version.js` build script is capitalized, while the file is lowercase on disk.
The fix is to ensure the hermes tarball name's "build type" is lowercase just like the function that creates the tarballs in react-native release located in `hermes_utils.js` in `getHermesPrebuiltArtifactsTarballName()`.
Perhaps it's better to retrieve the tarball name from the same method it's generated? E.g.:
```js
const { getHermesPrebuiltArtifactsTarballName } = require('react-native/scripts/hermes/hermes-utils');
const tarballName = getHermesPrebuiltArtifactsTarballName(`${version}-${configuration}`);
const tarballURLPath = `${podsRoot}/hermes-engine-artifacts/${tarballName}`;
```
If yes, let me know to update the PR.
## 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] - Fix release build error due to a casing issue in hermes tarball path after download prebuilt tarball
Pull Request resolved: https://github.com/facebook/react-native/pull/42160
Test Plan: Use a case sensitive volume or system and build react-native 0.73 in release mode, it will fail. Apply the patch in this PR and it will work fine.
Reviewed By: cortinico
Differential Revision: D52603439
Pulled By: cipolleschi
fbshipit-source-id: 41ed8d8202874f338e4aa3af88d9d28ec1b8b3d5
Summary:
Closes https://github.com/facebook/react-native/issues/42164
## Changelog:
[IOS] [FIXED] - Fixes `with-environment.sh` script for the case when Node can't be found prior to loading `.xcode.env`
Pull Request resolved: https://github.com/facebook/react-native/pull/42184
Test Plan: This is a trivial update, no need for much testing.
Reviewed By: cortinico
Differential Revision: D52602653
Pulled By: cipolleschi
fbshipit-source-id: 0881456bf165d895252ae38cb7c7aee945cfaf52
Summary:
Currently our CI will auto-tag any `npm publish` as `latest` for the monorepo packages. This is because [we do not specify a tag](https://github.com/facebook/react-native/blob/main/scripts/monorepo/find-and-publish-all-bumped-packages.js#L104), so npm will [default to `latest`](https://docs.npmjs.com/cli/v10/commands/npm-dist-tag#description). We encountered a similar issue for `react-native` awhile ago and fixed that with [always specifying a tag](https://github.com/facebook/react-native/blob/main/scripts/npm-utils.js#L84), with the explicit opt-in for `latest`.
yarn and npm will resolve `*` dependencies using `latest`. This will be a problem for any React Native version that uses `*` deps. We have actively tried to remove these `*` versions but older patches may still contain them.
When we do a monorepo package bump, it may be for 0.71 and for a user who is initializing a 0.72 version project (that still has * deps), they will receive monorepo packages of version `0.71.x`, which is not compatible. (React Native monorepo packages do not faithfully follow semver)
This change allows us to specify what tags to use and suggest tags based on what branch you are on and asks for confirmation
```
> branch 0.73-stable
? Select suggested npm tags. (Press <space> to select, <a> to toggle all, <i> to invert selection)
❯◉ "0.73-stable"
◉ "latest"
? Confirm these tags for *ALL* packages being bumped: "0.73-stable","latest" (Y/n)
> branch 0.72-stable
? Select suggested npm tags. (Press <space> to select, <a> to toggle all, <i> to invert selection)
❯◉ "0.72-stable"
◯ "latest"
? Confirm these tags for *ALL* packages being bumped: "0.72-stable" (Y/n)
> branch main
? Select suggested npm tags. (Press <space> to select, <a> to toggle all, <i> to invert selection)
❯◉ "nightly"
? Confirm these tags for *ALL* packages being bumped: "nightly" (Y/n)
```
## Changelog:
[INTERNAL] [CHANGED] - Support dist-tags in publishing monorepo packages to avoid default "latest" tag.
Pull Request resolved: https://github.com/facebook/react-native/pull/42146
Test Plan: `yarn test scripts/`
Reviewed By: NickGerleman
Differential Revision: D52551769
Pulled By: lunaleaps
fbshipit-source-id: 52f923464387cffdc6ca22c6f0a45425965a3680
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42158
Changelog: [Internal]
* Ports an existing Java/ObjC InspectorPackagerConnection behaviour to the C++ implementation: socket errors should trigger a reconnection. This was a simple omission in D52134592.
* Clarifies the relationship between the `didFailWithError` and `didClose` methods on `IWebSocketDelegate`: calling either one will terminate the connection (and trigger a reconnection), and it's legal to call `didClose` after `didFailWithError`.
* I'm also adding logic to ensure we don't double-schedule reconnections if both methods are called.
* Cleans up the scaffolding comments from D52134592
Reviewed By: huntie
Differential Revision: D52576727
fbshipit-source-id: 07e5a5c36222dc7bede8bcb17a1f3ced2788736b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42118
JFrog CDN periodically gives us headaches when downloading boost.
this change moves from JFrog to the official CDN by boost.
## Changelog
[Internal] - Download boost directly from boost archives
Reviewed By: cortinico
Differential Revision: D52479171
fbshipit-source-id: a53a9cb2ea6dfdf2b82b3c8e69c697b24cc40cf2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42156
changelog: [internal]
Add a missing nullptr check to prevent crash if called after component was reused
Reviewed By: fkgozali
Differential Revision: D52572807
fbshipit-source-id: 1b5b26996e562abbcb986865299e02df20b58043
Summary:
https://github.com/facebook/react-native/commit/f7219ec02d71d2f0f6c71af4d5c3d4850a898fd8 deprecated some of the methods in `RCTBundleURLProvider, and is part of React Native version 0.73. Let's remove the deprecated options for React Native 0.74+
bypass-github-export-checks
## Changelog:
[IOS] [REMOVED] - Remove deprecated RCTBundleURLProvider options
Pull Request resolved: https://github.com/facebook/react-native/pull/42114
Test Plan: CI should pass.
Reviewed By: huntie
Differential Revision: D52537732
Pulled By: cipolleschi
fbshipit-source-id: ea5d17c7c66a60bceb2a12f2e17e39be4c56d422
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42022
Some tests to ensure that the order of nodes is correct as defiend by order index that is derived from zIndex + positioning. These tests do not ensure that the native platform then goes and lays them out correctly. That will be done later with e2e tests on catalyst
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52295063
fbshipit-source-id: 8ae29fc50ad65db8e5c0ab28a132546d8489dffe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42021
# Context
A while ago D48905010 was committed that set the CALayer's zPosition equal to the zIndex passed in via props. This was to avoid an issue like: https://pxl.cl/40F72
where the rotating view would clip into the background.
There are a few issues here.
* The current zIndex code is designed to be cross platform on the C++ layer and not the native layer. This diverges from the Android behavior and adds a special case for this platform when we have the ability to share all of this logic
* Static nodes will apply a zIndex when they shouldn't. This code pre-empts the static check [here](https://www.internalfb.com/code/fbsource/[cf8ad268b4cf]/xplat/js/react-native-github/packages/react-native/ReactCommon/react/renderer/components/view/ConcreteViewShadowNode.h?lines=98) that zeroes out the "order index" for static nodes
* As a result of the above, static nodes can eclipse their children which should never happen because static nodes ignore zIndex values
# Reason for the clipping
The reason this clipping is happening is because the red/blue views share the same stacking context as the white background (as indicated by the vertical black line). {F1175070418}
This in combination with the fact that our zIndex implementation will NOT set iOS's zPosition means that these three views (red view, blue view, white background view) all have the same zPosition (0) and will be laid out in the order described by the orderIndex mentioned earlier. This index essentially just changes the document order that is used for tiebreakers when zPosition is tied.
So, all the views are on the same stacking context and they all have no zPosition set. Add the rotation that the colored views are doing and you get this clipping. Apple will change the "zPosition" in a sense for the parts of the view that should be perceived as "further away" due to the rotation. So, we clip into our background which has a lower order index but the same zPosition.
# This change
The fix here just makes it so that the rotating views are not on the same stacking context as the background so the changing zPosition from the rotation does not matter. This can be achieved by setting the zIndex of the container to any number (among other things). Note that this is only the case because the default position type is relative in this stack. Otherwise you would also need to set the position type as well. Now the stacking context looks like: {F1175083828} and the problem is solved!
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52181701
fbshipit-source-id: 580f860273b9c8470181d92d7ad542546664ed77
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42064
# Context
Dealing with how we should stack Views in a world with static is actually a bit complicated, despite the fact that static cannot get zIndex. The outline of everything can be found in this spec: https://www.w3.org/TR/CSS21/zindex.html. That is a bit dense, but mainly because there is much more functionality to consider in the browser than we need to in RN (like block layout, inline, floats, etc). Basically it comes down to this order, with larger numbers stacked on top of smaller ones:
1) Root
2) Negative zIndex positioned nodes (ties in document order)
3) Non positioned nodes in document order
4) Positioned nodes with no zIndex (or 0) in document order*
5) Positioned nodes with positive zIndex (ties in document order)
Document order is a pre-order traversal of the tree. The asterisk on 4 is where it gets a bit complicated. Even though there is no zIndex set, you should still treat these nodes as if they form a stacking context - with their descendants stacked relative to the parent stacking context like normal if they have zIndex set. Essentially what this means in our world is that a static child will not come before (under) a positioned parent if they share the same stacking context. Without this, you would need to form a stacking context on all positioned nodes with static children if you wanted them to appear at all since static comes before (under) positioned nodes.
# Implementation
Implementing this was a bit tricky. We had to go in pre-order traversal of the tree, but if we see a relative node it needs to form a "pseudo-stacking-context" to allow static to show over it, but if any of those descendants have a zIndex set, that should be relative to the parent stacking context like normal, not this "pseudo-stacking-context". Without static we take care of this just fine because it just ends up being a pre-order traversal of the tree, then sort by zIndex.
My approach was to ignore zIndex's at first and gather all nodes that share the same stacking context in an array as if none of them had any zIndex set. After that was gathered, then sort by zIndex to get the final order for said stacking context. The second part was already implemented. For the first part I just did a pre-order traversal of the tree (stopping at nodes that form stacking contexts) and:
* If a node was non static, add to the end of the list
* If a node was static, insert into the list right after the previously inserted static node that shares the same "psuedo-stacking-context", or the parent if there were none.
* Since inserting into arrays is slow, I opted to use `std::list`
In effect this was a pre-order traversal where static nodes are "sorted" to come first in the list of children, which is what we want since these nodes should come under non-positioned nodes that have the same "pseudo-stacking-context".
My implementation is a bit slower. The previous one just visits all nodes once with a pre-order traversal. This will also do that and thanks to `std::list`, we have no non-constant time operations while coming in that order. After the fact, however, we need to convert back to `std::vector` which is the type used across the mounting layer, so we have to iterate over this list again. I think this is the fastest we can do this and it is optimized for a world where most nodes are relative (since it will be the new default).
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52103057
fbshipit-source-id: 0b3fb28530cfc8ef248dbdc564b5c4b4a82045a4
Summary:
This PRs refactors `RCTKeyWindow()` to be more resilient and work in multi-window apps. After my recent PR got merged (https://github.com/facebook/react-native/issues/41935) it significantly reduced the number of calls to `RCTKeyWindow()` and now it's called only when necessary. So this PR makes this function a bit more resource intensive but it guarantees that we will find current scene's key window.
This would also fix some brownfield scenarios where React Native is working in multi-window mode and in the future allow us to more easily adopt `UIWindowSceneDelegate`
bypass-github-export-checks
## Changelog:
[IOS] [CHANGED] - refactor `RCTKeyWindow` to be more resilient and work in multi-window apps
Pull Request resolved: https://github.com/facebook/react-native/pull/42036
Test Plan:
Checkout RNTester example for Alerts and LoadingView.
https://github.com/facebook/react-native/assets/52801365/8cf4d698-db6d-4a12-8d8d-7a5acf34858b
Reviewed By: huntie
Differential Revision: D52431720
Pulled By: cipolleschi
fbshipit-source-id: 0d6ef1d46b2428c30c9f64dae66b95dbc69f0a3b
Summary:
This PR resolves the potential problem of misconfiguration of components after being recycled. Some of them have custom, sometimes native (e.g. connected to VCs) logic that messes up with the concept of recycling.
bypass-github-export-checks
## Changelog
Added `shouldBeRecycled` field checking to `RCTComponentViewClassDescriptor `, a check for it in `_enqueueComponentViewWithComponentHandle:(ComponentHandle)componentHandle
componentViewDescriptor:(RCTComponentViewDescriptor)componentViewDescriptor` method, and a default implementation in `RCTComponentViewDescriptor` returning `YES` in order not to change the default behavior.
[iOS] [Added] - Add `shouldBeRecycled` method on `iOS`.
Pull Request resolved: https://github.com/facebook/react-native/pull/35378
Test Plan: Override this method in your custom `componentView` and see that the component is not recycled.
Reviewed By: javache
Differential Revision: D41381683
Pulled By: cipolleschi
fbshipit-source-id: 10fd1e88f99b3608767c0b57fad462837924f02a
Summary:
Bump folly version to 2024.01.01.00. Actually we need a version newer than v2023.08.14.00 with the https://github.com/facebook/folly/commit/c52d4490bf1e0cf117a71342b427984f9ffc316e fix. That will fix build error on Android:
```
In file included from /Users/kudo/expo/expo/node_modules/react-native-reanimated/android/src/main/cpp/NativeProxy.cpp:3:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/jsi/include/jsi/JSIDynamic.h:10:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/dynamic.h:1310:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/dynamic-inl.h:22:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/Conv.h:124:
In file included from /Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/Demangle.h:19:
/Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/FBString.h:1721:19: error: no member named 'strong_ordering' in namespace 'std'
return std::strong_ordering::equal;
~~~~~^
/Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/FBString.h:1723:19: error: no member named 'strong_ordering' in namespace 'std'
return std::strong_ordering::less;
~~~~~^
/Users/kudo/.gradle/caches/transforms-3/dd158a7d05d059a173ae31ca6d78ac49/transformed/jetified-react-android-0.74.0-nightly-20240103-0e533f308-SNAPSHOT-debug/prefab/modules/folly_runtime/include/folly/FBString.h:1725:19: error: no member named 'strong_ordering' in namespace 'std'
return std::strong_ordering::greater;
~~~~~^
3 errors generated.
```
## Changelog:
[GENERAL] [CHANGED] - Bump folly version to 2024.01.01.00
Pull Request resolved: https://github.com/facebook/react-native/pull/42145
Test Plan: ci passed
Reviewed By: cortinico, cipolleschi
Differential Revision: D52546945
Pulled By: NickGerleman
fbshipit-source-id: 64aacb1d310062dddf987c7b95f10a477e293693
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42144
D51895785 changed several CMake libraries from shared to static, including `jsinspector`. This happens to be semantically incorrect in the case of `jsinspector`, as the library contains singletons which can be inadvertently duplicated due to static linking. As a result, different parts of the code can end up accessing different instances of a supposed singleton, leading to bugs.
Here we revert the change to `jsinspector` (only) and add an explanatory comment to signpost this for future readers.
## More context & general principle
While nothing is broken today, allowing static libraries to contain global state is brittle and breaks in surprising ways:
* The upcoming diff D52231237 introduces a new dependency on `jsinspector` which builds cleanly, but causes debugging to stop working because of the duplicated singleton.
* The only reason debugging currently works in the CMake build of Bridgeless is by a happy accident: the shared library `hermesinstancejni` depends on `reactnativejni` through a chain of three other libraries unrelated to debugging, and as a result, can access `reactnativejni`'s copy of `jsinspector` (see graph).
{F1237835169}
It seems that the safest rule of thumb, given the way React Native is currently structured, is that **singletons should live in their own shared libraries** so no call site can cause them to be duplicated through static linking. (It's reasonable to revisit this guidance if we manage to consolidate React Native into one monolithic shared library, eliminating the footgun at the source.)
Changelog:
[Internal] [Changed] - Change jsinspector back to a shared library in the CMake build.
Reviewed By: cortinico, NickGerleman
Differential Revision: D52541488
fbshipit-source-id: 502210add0b734a9bbc470bdf38fb70a41e149a9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42136
`Wpedantic` flags usage of variadic macros with zero arguments. This is widely supported by different compilers (including MSVC), but was previously forbidden by the standard.
C++ 20 explicitly allows them, so, theoretically Clang should know not to warn about these now. Let's try that.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D52534129
fbshipit-source-id: e27a75081fac6b4196c6dbb5242812877b0bd679
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42133
## Changelog:
[General][Fixed] - TouchableBounce, TouchableHighlight and TouchableNativeFeedback dropping touches with React 18.
TouchableBounce, TouchableHighlight and TouchableNativeFeedback do not trigger onPress when used with React 18. This is because it resets its pressability configuration in `componentWillUnmount`. This is fine, we want to stop deliver events and restart all timers when component is unmounted.
```
componentWillUnmount(): void {
this.state.pressability.reset();
}
```
But TouchableBounce, TouchableHighlight and TouchableNativeFeedback were not restarting the pressability configuration when component was mounted again. It was restarting the configuration in `componentDidUpdate`, which is not called when component is unmounted and mounted again.
Reviewed By: fkgozali
Differential Revision: D52514643
fbshipit-source-id: 0d6ae4bb7c2a797cc443181459c5614da0ecfc7a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42062
We have had relative as the default for a few big frameworks/apps right now (Fabric FB iOS, Fabric FB Android, OSS, Litho, CK) and have not run into issues. Seems it is safe to pull the trigger here and put everything on relative 🎉
This also fixes a test that relied on this default, changes the layout metrics default, and removes the gating plumbing that was in place earlier.
Lastly, a few animation tests start failing after this change. Seems that there is an animation bug with relative trees that would have existed already, so this is merely discovering that that bug exists, not causing any extra issues. Since that test is a set of random trees with random props it is very hard to debug and I am just adding skips to the failing ones.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52137858
fbshipit-source-id: 6856bc608b8211c868c9ee81fc92e005ec3d2faa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42020
I added position type in D51412428 (https://github.com/facebook/react-native/pull/41819). I didn't notice this == override which makes it so position type in layout metrics will not be updated if it changes.
To use this cpp 20 feature we needed to change a few buck files which is also done here
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52339890
fbshipit-source-id: e77ee092477dbf786e4a72e6a33138ccbc450645
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42122
This diff introduces the `TypeUtils` directory where we can put platform-specific, context-independent type transformations.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D52291837
fbshipit-source-id: 561b9c494aab5bfee3b3c668d3346bbd320e5266
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42128
Scroll view was not emitting the `onScrollToTop` event when the user tapped on the status bar.
This change fixes this by adding the event to the C++ Event Emitter and by invoking it into the `RCTScrollViewComponentView`
## Changelog
[iOS][Added] - Add onScrollToTop event in Fabric
Reviewed By: sammy-SC
Differential Revision: D52509919
fbshipit-source-id: 7b72c927823fa971be99c4da4b0287d4e23a02b6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42127
The current scrollViewExamples does not trigger the OnScrollToTop event.
This change for Paper adds that and refactors the codebase to isolate that example.
## Changelog:
[Internal] - Improve RNTester ScrollView example adding OnScrollView event.
Reviewed By: sammy-SC
Differential Revision: D52509669
fbshipit-source-id: 8fd0fcca7153ba41bf054832928e661ef7dff3fe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42113
For easier testing/debugging, log something if bridgeless is enabled for the app. This log will show up only once.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D52464640
fbshipit-source-id: 5019a1a6bf4f171a5f1dc4b3b2692db9e07ff43c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42073
This moved various Meta-internal runtime setup off AppDelegate.mm to reduce the #if checks throughout the file.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D52424748
fbshipit-source-id: b53799c8bb1544dbbb429cea811861ae52125641
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42086
Changelog: [General][Changed] - Update monorepo dependency versions to remove ^
This change will remove the caret for now as we already perform an "align" step everytime we bump a monorepo library. This prevents monorepo library updates to affect existing releases.
The "align" step updates all monorepo libraries to use the updated bumped version: https://fburl.com/code/xfistiph
Reviewed By: huntie
Differential Revision: D52440454
fbshipit-source-id: ff071032f04bc554903dde153c594991163dfe2f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42121
## Changelog:
[General][Fixed] - TouchableWithoutFeedback and TouchableOpacity dropping touches with React 18.
TouchableWithoutFeedback and TouchableOpacity do not trigger onPress when used with React 18. This is because it resets its pressability configuration in `componentWillUnmount`. This is fine, we want to stop deliver events and restart all timers when component is unmounted.
```
componentWillUnmount(): void {
this.state.pressability.reset();
}
```
But TouchableWithoutFeedback and TouchableOpacity were not restarting the pressability configuration when component was mounted again. It was restarting the configuration in `componentDidUpdate`, which is not called when component is unmounted and mounted again.
Reviewed By: fkgozali
Differential Revision: D52388699
fbshipit-source-id: ef13194c6581c5d31d0f1cb465bfd0cf98d672ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42090
This change is the last pieces of removing `RCT_NEW_ARCH_ENABLED` flag and defragmenting the build setup on iOS.
Before, 3rd party libraries had to use the `#if RCT_NEW_ARCH_ENABLED` flag to compile in and out segment of code depending on whether the new architecture was turned on or not.
After the recent changes, we can now expose the `RCTIsNewArchEnabled()` function to read whether the New Arch is enabled at runtime or not.
This will promote better code practices as we can replace ugly, compile time, `#if-#else-#endif`s with a more readable and natural regular obj-c code.
We can also use inheritance to have different implementation based on the architecture.
To use the new function, a 3rd party library have to:
1. `#import <React/RCTUtils.h>` (if they use the `install_modules_dependencies` function we provide, they can already do it)
2. invoke `RCTIsNewArchEnabled()` which returns a BOOL.
3. implement the code accordingly, depending on the New arch state.
**Note:** we implemented also the `RCTSetNewArchEnabled` function. This is called as soon as React Native is initialized in the `RCTAppDelegate`. The method can be called only once per React Native lifecycle. Subsequent calls to that method are ignored.
## Changelog:
[iOS][Added] - Added the `RCTIsNewArchEnabled()` to check whether the New Arch is enabled at runtime.
Reviewed By: cortinico
Differential Revision: D52445107
fbshipit-source-id: 1b432832912d33c85687b4c37f9e360ce9699f59
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42088
This change adds an extra function to customise the RootView in both Bridge and Bridgeless mode.
To nudge users in a migration, we also add a warning message for next version that should push our users to migrate away from the old implementation to the new one.
*The Warning is shown ONLY when the user do customise the rootView*. For users which were not customising the Root View, the warning will not appear.
The documentation of the new method plus the warning should guide the users toward the right migration path.
## Changelog
[iOS][Added] - Added the customiseRootView method which is called in both bridge and bridgeless. Added also a warning for 0.74 with instructions on how to migrate.
Reviewed By: cortinico
Differential Revision: D52442598
fbshipit-source-id: 8b99b67f4741ee61989a8659a3d74c1eba27bc5b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42097
Since we switched all apps from `getJSIModule()` to `getFabricUIManager()` from `ReactContext` and it's subclasses it's safe to delete this method.
NOTE: The fallback for FabricUIManager is still catalystInstance.getJSIModule() that's still there for backwards comptability just deleting the indirection through ReactContext
Changelog:
[Internal] Internal
Reviewed By: christophpurrer
Differential Revision: D51748655
fbshipit-source-id: dbf1a661f9e380307614662dd6079110f878d143
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42072
This existing flag was for experimental (WIP) purpose only, and is undocumented, by design. Let's rename it so to make it clear. Libraries/Apps should not use this flag.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D52424750
fbshipit-source-id: 742fc6e31d1887e68439849e157dd23aaa054e36
Summary:
See https://github.com/facebook/react-native/issues/41929 for an issue on multiple monorepo packages being installed. The reason is that `*` resolves to whatever is tagged `latest` on npm.
We still need to fix the fact that our monorepo publish script will update the latest tag everytime we publish. For now, we should remove these from `main` and we will also update this in the 0.73 release branch.
I've left the two peer dependencies on `react-native` to keep at `*`.
```
virtualized-lists/package.json
30: "react-native": "*"
rn-tester/package.json
32: "react-native": "*"
```
As a peer-dependency this won't be a problem in terms of installing a second `react-native`. I thought about updating these to `nightly`, but that would install multiple nightly react-natives as the tag will be updated with each nightly release. I think for now this is fine and something we can revisit.
Things left to do
[ ] Fix monorepo publish script to not update `--latest`
[ ] Remove ^ dependencies on monorepo packages: https://github.com/facebook/react-native/pull/41958
[ ] Re-evaluate how we bump and align monorepo packages when we cut a release branch. I forget if we manually update this when we cut or if there is a script. We may want to change the script and have `main` dependencies point to some fake version like `1000.0.0` and only update these on nightly publishes. Regardless, this will need some discussion.
## Changelog:
[GENERAL] [CHANGED] - Be explicit about what monorepo versions we are using
Pull Request resolved: https://github.com/facebook/react-native/pull/42081
Test Plan: N/A
Reviewed By: cortinico, cipolleschi
Differential Revision: D52435234
Pulled By: lunaleaps
fbshipit-source-id: 67da029d2b637e3997c12c21fe2a9ab9bc344399
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42085
Deprecating the old JSI module APIs: `getJSIModule(JSIModuleType moduleType)`, `addJSIModules(List<JSIModuleSpec> jsiModules)` and `setTurboModuleManager(JSIModule getter)` to further delete them in future release. Deprecating them as of now to cater the OSS use-cases
Changelog:
[Internal] internal
Reviewed By: christophpurrer
Differential Revision: D50927292
fbshipit-source-id: 1d25f9f28b8aaf34979a90e4792317b263ae1714
Summary:
This is a continuation of my [last PR](https://github.com/facebook/react-native/pull/40914) which improved the symbolication of unhandled promise rejections.
While I was developing another library I noticed I still got an error stack of the log adding and not of the error itself. The library I'm trying to debug does not throw a standard error object but rather a custom one, but it still contains the stack field. By passing this stack field to the logbox call I was able to get a better symbolicated stack trace. The exact line of the failure is not displayed but at least the correct file is.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[GENERAL] [ADDED] - Unhandled promise rejection - attach non-standard Error object stack info if possible
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/42079
Test Plan:
Test any unhandled promise rejection with a non-standard error (line 23, toString must not return `[object Error]`) and see if the correct (or at least a better) stack trace is shown.
Here is the one I got before and after this change:
<img src="https://github.com/facebook/react-native/assets/1634213/3d07faad-9535-42c9-8032-b4d8fe407e88" width="200" />
<img src="https://github.com/facebook/react-native/assets/1634213/2c39bd82-c7a1-4f58-8ac4-5c479bb96b6e" width="200" />
Reviewed By: huntie
Differential Revision: D52431711
Pulled By: cipolleschi
fbshipit-source-id: be2172d3b1e2fc3f72812faac372c83bc6dface2
Summary:
Building native modules from source, may take a long time. Xcode already helps bring this down, by providing incremental builds, as long as the user doesn't delete their `ios/build` directory. But in some situations, i.e. when iterating the native code of an app or library or when the developer need to delete that `ios/build` directory, it's advantageous to use a compiler cache, such as ccache. This is already outlined in our ["Speeding up your Build phase"](https://reactnative.dev/docs/build-speed#xcode-specific-setup) guide.
But setting up an Xcode project to use Ccache with the correct configuration, isn't trivial in a way that doesn't require symlinking `clang` and `clang++` or passing configuration via environment variables on every `npm run ios` invokation.
This PR takes its inspiration from the existing guide on [setting up Ccache for Xcode](https://reactnative.dev/docs/build-speed#xcode-specific-setup), but applies the build settings only if an installation of `ccache` is detected and the feature is explicitly opted into via an argument to the `react_native_post_install` function or a `USE_CCACHE` environment variable. It uses two shell scripts to wrap the call to `ccache`, which both injects a default `CCACHE_CONFIGPATH` environment variable (i.e. it won't override this if already provided, to allow for customisations on CI), pointing to a `ccache.config` which works well with React Native projects (it has the same values as the guide mentions).
For context, I posted about this change in the ios channel of the contributors Discord server, where I discussed it with cipolleschi and saadnajmi
### Additional output printed when running `pod install`
#### When `ccache_available and ccache_enabled`
```
[Ccache]: Ccache found at /opt/homebrew/bin/ccache
[Ccache]: Setting CC, LD, CXX & LDPLUSPLUS build settings
```
#### When `ccache_available and !ccache_enabled`
```
[Ccache]: Ccache found at /opt/homebrew/bin/ccache
[Ccache]: Pass ':ccache_enabled => true' to 'react_native_post_install' in your Podfile or set environment variable 'USE_CCACHE=1' to increase the speed of subsequent builds
```
#### When `!ccache_available and ccache_enabled`
```
[!] [Ccache]: Install ccache or ensure your neither passing ':ccache_enabled => true' nor setting environment variable 'USE_CCACHE=1'
```
#### Otherwise
If the user doesn't have ccache installed and doesn't explicitly opt into this feature, nothing will be printed.
bypass-github-export-checks
## Changelog:
[IOS] [ADDED] - Added better support for `ccache`, to speed up subsequent builds of native code. After installing `ccache` and running `pod install`, the Xcode project is injected with compiler and linker build settings pointing scripts that loads a default Ccache configuration and invokes the `ccache` executable.
Pull Request resolved: https://github.com/facebook/react-native/pull/42051
Test Plan:
I've tested this manually - would love some inspiration on how to automate this, if the reviewer deem it needed.
To test this locally:
1. Install Ccache and make sure the `ccache` executable is in your `PATH` (verify by running `ccache --version`)
2. Create a new template app instance and apply the changes of this PR to the `node_modules/react-native` package.
3. Set the `USE_CCACHE` environment variable using `export USE_CCACHE=1`.
4. Run `pod install` in the `ios` directory.
5. Check the stats of Ccache (running `ccache -s`).
6. Run `npm run ios` or build the project from Xcode.
7. Check the Ccache stats again to verify ccache is intercepting compilation ("Cacheable calls" should ideally be 100%).
8. To check the speed gain:
a. Delete the `ios/builds` directory
b. Zero out the ccache stats (by running `ccache -z`)
c. Run `pod install` again (only needed if you ran the initial `pod install` with new architecture enabled `RCT_NEW_ARCH_ENABLED=1`).
d. Run `npm run ios` or build the project from Xcode.
e. This last step should be significantly faster and you should see "Hits" under "Local storage" in the ccache stats approach 100%.
Reviewed By: huntie
Differential Revision: D52431507
Pulled By: cipolleschi
fbshipit-source-id: 6cfe39acd6250fae03959f0ee74d1f2fc46b0827
Summary:
This PR contains the changes from https://github.com/facebook/react-native/pull/30981 that got closed due to inactivity.
Many thanks to nickdowell for this bug report & fix. We encountered this error in our project when we had an Xcode scheme that contains a space (like `AppName alpha`).
This change fixes the generation of source maps for Xcode projects where the output path contains spaces.
The `EXTRA_ARGS` environment variable, being a plain string, would be split into arguments by whitespace - so a path containing spaces was being treated as several arguments rather than one.
This change uses an array to contain the arguments instead, allowing the proper handling of arguments that may contain spaces.
bypass-github-export-checks
## Changelog:
[iOS] [Fixed] - Fix support for --sourcemap-output path containing spaces
Pull Request resolved: https://github.com/facebook/react-native/pull/40937
Test Plan:
Tested using a sample project with the following "Bundle React Native code and images" Xcode build phase
```
export SOURCEMAP_FILE="$CONFIGURATION_BUILD_DIR/$UNLOCALIZED_RESOURCES_FOLDER_PATH/main.jsbundle.map"
set -e
export NODE_BINARY=node
../node_modules/react-native/scripts/react-native-xcode.sh
```
and a `CONFIGURATION_BUILD_DIR` that contains spaces - `~/Library/Xcode/Derived Data`. **You can also try an XCode-scheme that contains a space.**
### Before
```
+ EXTRA_ARGS=
+ case "$PLATFORM_NAME" in
+ BUNDLE_PLATFORM=ios
+ EMIT_SOURCEMAP=
+ [[ ! -z /Users/nick/Library/Developer/Xcode/Derived Data/RN064-cpnwckdferodycbevupbrkjydate/Build/Products/Release-iphonesimulator/RN064.app/main.jsbundle.map ]]
+ EMIT_SOURCEMAP=true
+ PACKAGER_SOURCEMAP_FILE=
+ [[ true == true ]]
+ [[ '' == true ]]
+ PACKAGER_SOURCEMAP_FILE='/Users/nick/Library/Developer/Xcode/Derived Data/RN064-cpnwckdferodycbevupbrkjydate/Build/Products/Release-iphonesimulator/RN064.app/main.jsbundle.map'
+ EXTRA_ARGS=' --sourcemap-output /Users/nick/Library/Developer/Xcode/Derived Data/RN064-cpnwckdferodycbevupbrkjydate/Build/Products/Release-iphonesimulator/RN064.app/main.jsbundle.map'
+ node /Users/nick/Desktop/RN064/node_modules/react-native/cli.js bundle --entry-file index.js --platform ios --dev false --reset-cache --bundle-output '/Users/nick/Library/Developer/Xcode/Derived Data/RN064-cpnwckdferodycbevupbrkjydate/Build/Products/Release-iphonesimulator/main.jsbundle' --assets-dest '/Users/nick/Library/Developer/Xcode/Derived Data/RN064-cpnwckdferodycbevupbrkjydate/Build/Products/Release-iphonesimulator/RN064.app' --sourcemap-output /Users/nick/Library/Developer/Xcode/Derived Data/RN064-cpnwckdferodycbevupbrkjydate/Build/Products/Release-iphonesimulator/RN064.app/main.jsbundle.map
Welcome to Metro!
Fast - Scalable - Integrated
info Writing bundle output to:, /Users/nick/Library/Developer/Xcode/Derived Data/RN064-cpnwckdferodycbevupbrkjydate/Build/Products/Release-iphonesimulator/main.jsbundle
info Writing sourcemap output to:, /Users/nick/Library/Developer/Xcode/Derived
```
Note the incorrect sourcemap output path.
### After
```
+ EXTRA_ARGS=()
+ case "$PLATFORM_NAME" in
+ BUNDLE_PLATFORM=ios
+ EMIT_SOURCEMAP=
+ [[ ! -z /Users/nick/Library/Developer/Xcode/Derived Data/RN064-cpnwckdferodycbevupbrkjydate/Build/Products/Release-iphonesimulator/RN064.app/main.jsbundle.map ]]
+ EMIT_SOURCEMAP=true
+ PACKAGER_SOURCEMAP_FILE=
+ [[ true == true ]]
+ [[ '' == true ]]
+ PACKAGER_SOURCEMAP_FILE='/Users/nick/Library/Developer/Xcode/Derived Data/RN064-cpnwckdferodycbevupbrkjydate/Build/Products/Release-iphonesimulator/RN064.app/main.jsbundle.map'
+ EXTRA_ARGS+=("--sourcemap-output")
+ EXTRA_ARGS+=("$PACKAGER_SOURCEMAP_FILE")
+ node /Users/nick/Desktop/RN064/node_modules/react-native/cli.js bundle --entry-file index.js --platform ios --dev false --reset-cache --bundle-output '/Users/nick/Library/Developer/Xcode/Derived Data/RN064-cpnwckdferodycbevupbrkjydate/Build/Products/Release-iphonesimulator/main.jsbundle' --assets-dest '/Users/nick/Library/Developer/Xcode/Derived Data/RN064-cpnwckdferodycbevupbrkjydate/Build/Products/Release-iphonesimulator/RN064.app' --sourcemap-output '/Users/nick/Library/Developer/Xcode/Derived Data/RN064-cpnwckdferodycbevupbrkjydate/Build/Products/Release-iphonesimulator/RN064.app/main.jsbundle.map'
Welcome to Metro!
Fast - Scalable - Integrated
info Writing bundle output to:, /Users/nick/Library/Developer/Xcode/Derived Data/RN064-cpnwckdferodycbevupbrkjydate/Build/Products/Release-iphonesimulator/main.jsbundle
info Writing sourcemap output to:, /Users/nick/Library/Developer/Xcode/Derived Data/RN064-cpnwckdferodycbevupbrkjydate/Build/Products/Release-iphonesimulator/RN064.app/main.jsbundle.map
```
sourcemap output path fixed 🎉
Reviewed By: arushikesarwani94
Differential Revision: D52431057
Pulled By: cipolleschi
fbshipit-source-id: 528217c84fe3f467a30baa15cfa4dcb2ed713165
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42060
For removal of JSIModule getting rid of the inheritance relationship b/w interfaces TurboModuleManager & JSIModule by directly defining `invalidate()`. `initialize()` here isn't being used hence not defining it.
Changelog:
[Internal] internal
Reviewed By: philIip, mdvacca
Differential Revision: D49977957
fbshipit-source-id: 8de644b1f344d8ce8d4a78655556829f860a2b10
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41802
Those tests are not executing at all, they're just compiled.
Our internal infra is still depending on some bits of it though, so I'm moving them to `fbandroid/java/com/facebook/fbreact
Changelog:
[Internal] [Changed] - Move legacy tests from OSS to fbandroid/java/com/facebook/fbreact
Reviewed By: rshest
Differential Revision: D51805702
fbshipit-source-id: 2c5cec68efa9854184e981220202d8f356ff690a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42078
Resubmit of D51891716 and D52033328
I'm doing a pass and converting the last Java Unit Tests we had to Kotlin
I've also re-enabled multiple tests that were disabled in the past.
Changelog:
[Internal] [Changed] - Convert the last Unit Tests to Kotlin
Reviewed By: rshest
Differential Revision: D52430728
fbshipit-source-id: e6b4a6ed88d852024d959cf5148e992e97a84434
Summary:
I noticed this comment is still in Java in the Kotlin template. It also doesn't really work anymore since there is no packages variable.
To fix it I completed the comment with all code needed for it to work in kotlin. I think an older version of the template used to be more like:
```kotlin
val packages = PackageList(this).packages
// packages.add(MyReactNativePackage())
return packages
```
But then it requires adding a lint suppress annotation since packages variable can be simplified. I think this is simpler even if it makes the comment a few more lines.
## Changelog:
[GENERAL] [FIXED] - Fix comment about adding packages in android template
Pull Request resolved: https://github.com/facebook/react-native/pull/41856
Test Plan: Tested that uncommenting that code works
Reviewed By: cipolleschi
Differential Revision: D51987483
Pulled By: cortinico
fbshipit-source-id: d0135b5b536960017ccc7b25f92c75b3bd863cd9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42076
## Changelog:
[Internal] -
In https://github.com/facebook/react-native/pull/41519 we introduced usage of C++20s range operations, which broke MacOSX desktop builds for the x86_64 targets (e.g. on Intel Mac laptops).
This appears to be a [known issue](https://stackoverflow.com/questions/73929080/error-with-clang-15-and-c20-stdviewsfilter), fixed in the later clang versions, however we need to support the earlier ones as well.
This changes the code to use the good old imperative style to do the same thing, but without using `std::views::filter`, thus working around the problem.
Reviewed By: christophpurrer
Differential Revision: D52428984
fbshipit-source-id: 6d0a390549c462b7040b5c0e669c00932bd99af7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42059
Getting rid of old APIs in FabricUIManagerProvider and also clearing it of the inheritance dependency it has on JSIModule post it's references have been cleared.
Reviewed By: christophpurrer
Differential Revision: D51001239
fbshipit-source-id: c3d4650c292e957e9f939304662932c11af7a24f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42069
Refactor React to get rid of JSIModule and its dependencies now that the changes are rolled out for all internal apps.
Changelog:
[Internal] Internal
Reviewed By: christophpurrer
Differential Revision: D51058885
fbshipit-source-id: 07a7335235605fbc07657f8da8588ec548bce797
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42068
These methods are overriden in UIManager.js
Let's pull them out, so that we don't get distracted by them.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D52350348
fbshipit-source-id: 3d4b446c40be9d8797ec787f45335f42f8982956
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41999
Just a cosmetic change, that will remove noise from the subsequent diffs.
Now, all the raiseSoftError are on similar columns in the file.
Changelog: [internal]
Reviewed By: cortinico
Differential Revision: D52041976
fbshipit-source-id: bc22add358becf1ad8d5f7602253e2af28697d42
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42071
Proxying background handling to set up Meta internal test infra.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D52420805
fbshipit-source-id: a68645b7b630f976dfd9e863b0c985c738c658ec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42000
I think this makes BridgelessUIManager easier to read: if the getUIManagerConstants method exists, get the cached constants.
Also, this unifies the nomenclature between PaperUIManager and BridgleessUIManager. That way, it's easy to compare/constrast the two files.
Changelog: [Internal]
Reviewed By: dmytrorykun, luluwu2032
Differential Revision: D52002910
fbshipit-source-id: 01bfbd5fedbe3f995b4a1f68309714d84027133b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42001
## Rational
Every call-site was calling into console.error.
Some call-sites were using string concatination.
This diff introduces a new error reporting method: raiseSoftError, that hides all the string concatination and console.errors.
I believe this makes the error reporting logic within BridgelessUIManager more readable.
Changelog: [Internal]
Reviewed By: luluwu2032
Differential Revision: D52002911
fbshipit-source-id: 186842a4835ca65f326dda35b1c0db50f8ff149c
Summary:
The Android minSdk has been bumped in https://github.com/facebook/react-native/pull/38874 but not in the README.
## Changelog:
[General] [Fixed] - Updated docs to match Android 6.0 (API 23) minimum requirement.
Pull Request resolved: https://github.com/facebook/react-native/pull/42034
Test Plan: N/A
Reviewed By: fkgozali
Differential Revision: D52364522
Pulled By: arushikesarwani94
fbshipit-source-id: b04b5aa94b629380b559b2717e12a882f8817a6f
The internal and external repositories are out of sync. This Pull Request attempts to brings them back in sync by patching the GitHub repository. Please carefully review this patch. You must disable ShipIt for your project in order to merge this pull request. DO NOT IMPORT this pull request. Instead, merge it directly on GitHub using the MERGE BUTTON. Re-enable ShipIt after merging.
Summary:
X-link: https://github.com/facebook/yoga/pull/1533
Pull Request resolved: https://github.com/facebook/react-native/pull/42031
I have some reservations about some of the conditional setting of trailing position in general, and some of the repeated transformations that neccesitates this, but these functions don't belong in `CalculateLayout.h`. For now, just move these to their own header.
Reviewed By: joevilches
Differential Revision: D52292121
fbshipit-source-id: 4a998a4390a8d045af45f5424adaf049ed635e7a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41519
Changelog: [Internal] - Refactor hover tracking logic to the shared c++ renderer
This diff refactors our hover tracking logic out of the platform (in this case only iOS, integrating Android is going to require extra work due to their pointer events being untyped) and puts it into the event intercepting infra in Fabric's C++ core. This is a big-ish diff so I'm going to try my best to use this summary to guide you through the changes.
To begin with — the changes inside `RCTSurfacePointerHandler.mm` are mostly about removing the existing hover tracking logic. The logic of the hover tracking is largely the same between the objective-c and c++ implementations with minor tweaks in order to be a better citizen when it comes to storing node references. One small "addition" to this file is explicitly firing a `pointerleave` event from the iOS layer when we detect that the pointer has left the app entirely because the C++ would otherwise not know when the pointer leaves the app. We don't need to include a special case for `pointerenter` because we can derive that in C++ from the first `pointermove` event that gets sent once the pointer re-enters the app's root view.
Next I think it makes most sense to continue onto the `PointerEventsProcessor.h/mm` which is the central class we're working in. One small change is adding a flag to the `ActivePointer` struct (`shouldLeaveWhenReleased`) which we will set during `ActivePointer` registration — setting to false if the pointer in question exists in the (also) newly added `previousHoverTrackersPerPointer_` registry. This logic is primarily used for knowing later when the pointer is released and whether we should emit the synthetic leave/out event on release. If the pointer existed in `previousHoverTrackersPerPointer_` **before** the `ActivePointer` registration that implies that the pointer is capable of hovering to some degree and we should **not** emit those leave/out events yet.
The real meat & potatoes of this diff is the `handleIncomingPointerEventOnNode` method which matches the `handleIncomingPointerEvent` method we removed from `RCTSurfacePointerHandler.mm`. This method derives the enter/leave/over/out pointer events by comparing the current event's target path (list of nodes from the root node to the target node of the event) to the previously recorded event target path. The representation of this event path is through the new `PointerHoverTracker` class which stores a pointer to just the root node and the target node as we can recreate the entire event path from these.
For over/out events all that matters is when the deepest-most target changes which is checked in `handleIncomingPointerEventOnNode` by leveraging `PointerHoverTracker`'s `hasSameTarget` method. For enter/leave events we need to fire discrete events for every node in the path which has either been removed or added, so the `diffEventPath` method was introduced on `PointerHoverTracker` to provide that.
Reviewed By: yungsters
Differential Revision: D51317492
fbshipit-source-id: e15ac3a396d5afa7ab921e4589861b43b07a33b5
Summary:
We have 1 coordinator per class but 1 adapter per instance.
Currently, the `oldProps` are stored in the coordinator and not into the adapter.
Therefore, when we create multiple instances of the same legacy component, the props might get messy or not updated properly.
This change moves the `oldProps` and the diffing code to the Adapter rather than to the coordinator, making them instance-specific.
## Changelog:
[iOS][Fixed] - Move old props and prop diffing to the interop layer adapter
Reviewed By: sammy-SC
Differential Revision: D52368222
fbshipit-source-id: 0f0c47b586fe61404250c5bfe51a7e2c63012815
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41925
This diff introduces the `npx react-native codegen` command.
It runs the codegen for the `package.json` file in current working directory.
Changelog: [General][Added] - Introduce "npx react-native codegen" command.
Reviewed By: cipolleschi
Differential Revision: D51495465
fbshipit-source-id: 1fd4c3645235a12f68f9032349a443b92b4764b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42012
Up until now `generate-codegen-artifacts.js` has been iOS only. But its logic is actually quite general, and this diff makes it platform agnostic.
Changelog: [General][Added] - Introduce the "platform" option to generate-codegen-artifacts.js
Reviewed By: RSNara
Differential Revision: D52257542
fbshipit-source-id: b7e698c779f7c6dae9b0de98a19ba452111fea5e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42016
changelog: [internal]
TouchableWithoutFeedback is broken with React 18. Before we fix it, let's use Pressable in tests.
Reviewed By: fkgozali
Differential Revision: D52328529
fbshipit-source-id: 1d7d5032ffaf7f8ff5ffa47af2a87b733fd2e840
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42035
In upcoming diffs we will begin integrating the new C++ `InspectorPackagerConnection` (D52134592) into React Native on Android and iOS. This diff adds a shared C++ flag that is the source of truth for whether the new implementation should be enabled.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D52335446
fbshipit-source-id: 7f16ffc1728c8de7d4fbf090268ffed6fbaa879f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42026
Previously, the examples allow overriding the testIDs for each inner example from ViewExample.js in RNTester. However, that setup relies on another infra/abstraction to inject the testIDs properly. For simplicity, let's just make them hardcoded using the pattern view-test-<example-name>.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52349100
fbshipit-source-id: 09d51935318d0592a9aae7da61cab0c87ac69152
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41987
Previously, the examples allow overriding the testIDs for each inner example from BorderExample.js in RNTester. However, that setup relies on another infra/abstraction to inject the testIDs properly. For simplicity, let's just make them hardcoded using the pattern `border-test-<example-name>`.
Changelog: [Internal]
Reviewed By: NickGerleman, mdvacca
Differential Revision: D52282922
fbshipit-source-id: 8fdc3d799befddbbb9bd8e60c8a904670c035d59
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41981
Improved RNTester URL deeplink support to cover:
* `rntester://example/<moduleKey>`
* `rntester://example/<moduleKey>/<exampleKey>`
Extra details:
* For example modules that do not specify `showIndividualExamples: true`, allow deeplink URL with the specific exampleKey to only render the specific example, instead of all of them.
* Added flexibility for moduleKey: search for optional suffixes ("Index", "Example").
* Adjusted Back button action to properly go back to the root after a deeplink.
* Added `example-container` generic testID on the example wrapper component.
Changelog: [Internal]
Reviewed By: yungsters, NickGerleman
Differential Revision: D52227013
fbshipit-source-id: 4ba050592f39d6895f5124fa25c77f2d0199aa3f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42019
Removes the following deprecated properties from React Native:
- `Image.propTypes`
- `Text.propTypes`
- `TextInput.propTypes`
- `ColorPropType`
- `EdgeInsetsPropType`
- `PointPropType`
- `ViewPropTypes`
The deprecation history for these prop types is not super obvious, so here is a summary:
- `react@15.5` extracted `prop-types` into a separate package to reflect that not everybody uses them.
- `react-native@0.68` added a deprecation warning to built-in prop types. (https://github.com/facebook/react-native/commit/3f629049ba9773793978cf9093c7a71af15e3e8d)
- `react-native@0.69` removed built-in prop types. (https://github.com/facebook/react-native/commit/3e229f27bc9c7556876ff776abf70147289d544b)
- `react-native@0.71` restored built-in prop types, along with bug fixes to isolate deprecated usage. (https://github.com/facebook/react-native/commit/b966d297245a4c1e2c744cfe571396cfa7e5ffd3)
We believe that by the next public release, enough time will have passed for the community to be able to upgrade without patching React Native or otherwise working around the removal of these deprecated prop types.
**If anyone has trouble identifying the source of a deleted prop types usage, please file an issue so we can help track it down with you.**
Changelog:
[General][Removed] - Removed deprecated prop types
Reviewed By: lunaleaps, NickGerleman
Differential Revision: D52337762
fbshipit-source-id: 9731f7e1dec29f3df535ab75cc50bed001fdfa0b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42017
Changelog: [Internal]
C++ unit tests for D52134592. The tests heavily use gtest / gmock features to mock the various interfaces associated with `InspectorPackagerConnection` (see `InspectorMocks.h`) and to make it easy to write complex assertions on dynamic and JSON values (see `FollyDynamicMatchers.h`).
To simplify access to the mock objects while they are owned by the `InspectorPackagerConnection` under test, I've also created the `UniquePtrFactory` helper (see doc comments and unit tests that fully explain its functionality).
Reviewed By: huntie
Differential Revision: D52134593
fbshipit-source-id: 23b8098232898be7e5cbd9b31b3358640c5e5eec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41977
Changelog: [Internal]
Adds a new C++ implementation of `InspectorPackagerConnection`, intended to eventually replace `RCTInspectorPackagerConnection` on iOS and `InspectorPackagerConnection.java` on Android.
The main *new* abstraction in the C++ version is the `InspectorPackagerConnectionDelegate` interface, which will allow each platform to plug in its own scheduler and WebSocket implementation
This is almost entirely a direct translation of the Objective-C implementation to C++, so I've modelled it as a file copy in source control for ease of review. We may iterate further on the API at a later date, especially once the old implementations are gone.
Reviewed By: huntie
Differential Revision: D52134592
fbshipit-source-id: b4778b9c4fd424c4fa8d23bb9171629874e50e73
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41975
The version of `inspector-proxy` included with React Native has not used the `isLastBundleDownloadSuccess` and `bundleUpdateTimestamp` properties in years. This diff removes the backend support for reporting them (in preparation for a C++ rewrite of this infrastructure). We can consider bringing a similar feature back in the future on top of the modern CDP infra (which we are currently building).
Changelog: [General][Breaking] Remove APIs for reporting bundle download status to inspector-proxy, which does not use this information.
Reviewed By: huntie
Differential Revision: D52258567
fbshipit-source-id: e810278f949d8ab7dbc660cdc036a0f8464727f6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41956
By default, generated Cxx sources for components all end up in same directory. However the include declarations in them look like this:
```
#include <react/renderer/components/${libraryName}/ShadowNodes.h>
```
And not like this:
```
#include "ShadowNodes.h"
```
This works fine with Buck because it supports header prefixes.
To get this working with CocoaPods we define additional `HEADER_SEARCH_PATHS` for our `React-Codegen` pod.
This approach will not work if we want to generate code at the library level and check in the artifacts. That's because we don't have control over the Podspec there, and can't inject those additional `HEADER_SEARCH_PATHS`.
This diff adds the `headerPrefix` argument to the codegen entry point. It is `react/renderer/components/${libraryName}` by default, but can become empty if we want to generate code at the library level, and don't want to deal with this nested header structure.
*Note:* `RNCodegen` runs all the generators [in a loop](https://github.com/facebook/react-native/blob/main/packages/react-native-codegen/src/generators/RNCodegen.js#L263-L275), assuming that the all have same function signature So I had to add the `headerPrefix` argument to all the generators, even to the ones that don't really need it.
Changelog: [General][Added] - Introduce "headerPrefix" codegen option.
Reviewed By: zeyap
Differential Revision: D51811596
fbshipit-source-id: c5c3e1e571c7c4ea2f5354eb9a7b0df6b917fc0c
Summary:
Adds changelog for the 0.72.8 release.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [CHANGED] - Add changelog for the 0.72.8 release.
Pull Request resolved: https://github.com/facebook/react-native/pull/42011
Test Plan: Read the changelog 🤞
Reviewed By: christophpurrer
Differential Revision: D52325318
Pulled By: huntie
fbshipit-source-id: 377a81f255c909b7da9370d6e3856265e2081b46
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41974
Changelog: [Internal]
Switches `RCTInspectorPackagerConnection` to use the recommended and type-safe `didReceiveMessageWithString` method to receive messages from SRWebSocket.
Reviewed By: huntie
Differential Revision: D52257082
fbshipit-source-id: ce1233a06b15a353500f81ae5a7730422c668be7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41971
Original commit changeset: 29e1aba9c4ea
Original Phabricator Diff: D49956535
D49956535 added the new behaviour of logging helpful messages to the CDP console when the app is backgrounded/foregrounded. The underlying UX issue is legitimate: how do we reinforce the mental connection between the debugger frontend and the app being debugged, when they might be running in different windows or even machines, and particularly when the app might be backgrounded while the debugger frontend remains active.
However, this implementation is too closely coupled to the socket management layer, and is iOS-specific to boot. I'm removing it here to simplify porting `RCTInspectorPackagerConnection` to C++. We can revisit this UX problem later - preferably by investigating how it's handled in the case of Chrome Android and a remote DevTools client.
This feature has not been included in an OSS release of React Native yet, so very few users will be affected by its removal.
Changelog: [iOS][Removed] - Revert D49956535; remove console.log notification in DevTools if app transitions between back/foreground.
Reviewed By: blakef
Differential Revision: D51468311
fbshipit-source-id: b875d6cf03d3521c8e876c358b2299f20d395400
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41984
Changelog: [Internal]
this is unused anywhere, delete. for some reason we only have the spec file in oss but no native implementation
Reviewed By: christophpurrer
Differential Revision: D51968870
fbshipit-source-id: a4931d08c50954bfa557451e5e4d79a10dfeaefe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41976
Progress towards an opt-in setup for our new CDP backend.
- Wires up D51563107 to conditionally disable the legacy Hermes debugger via `ReactNativeConfig`.
- **Configuration covered**: iOS, for the `RCTAppDelegate` code path.
- Create C++-only overload of `RCTAppSetupPrepareApp`, deprecate the previous function.
Changelog:
[iOS][Deprecated] - Deprecate `RCTAppSetupPrepareApp`, replaced with C++ overload
Reviewed By: motiz88
Differential Revision: D51589221
fbshipit-source-id: 1688f97c69abb06d271b4d26b875365a8d86ba77
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42002
Adds an E2E test on top of the RNTester example for this (as a practice we should probably do this for new examples).
I didn't add unit tests for this originally, but probably should do that as well if it gets more interesting...
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D51639134
fbshipit-source-id: 379d95dfc676252e10b7076e294ac5534c6f06bf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41994
X-link: https://github.com/facebook/yoga/pull/1529
Reorganizes the header according to common C++ convnetions. Public first, then private. Constructors, then functions, then member variables.
Reviewed By: joevilches
Differential Revision: D52106056
fbshipit-source-id: 0095cf7caa58dc79c1803b3b231911e4fc66ddaf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41995
X-link: https://github.com/facebook/yoga/pull/1526
This function has made quite the journey from something that originally made more sense. This renames, refactors, and adds documentation for what it actually does.
This should eventually make its way into `yoga::Style` once computed style is moved into that structure.
bypass-github-export-checks
Reviewed By: joevilches
Differential Revision: D52105718
fbshipit-source-id: 6492224dd2e10cef3c5fc6a139323ad189a0925c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41939
X-link: https://github.com/facebook/yoga/pull/1520
This code originates as `YGValueResolve`, used to compute a YGValue to a length in points, using a reference for 100%.
This moves it to `Style::Length`, so we can encapsulate parts of it (for style value functions), and make the API more cohesive now that we can do C++ style OOP with it.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D51796973
fbshipit-source-id: a7c359c7544f4bd2066a80d976dde67a0d16f1dd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41776
X-link: https://github.com/facebook/yoga/pull/1492
# Summary
In preparation to replace `CompactValue`, this fully encapsulates it as an implementation detail of `yoga::Style`.
The internal API now always operates on `Style::Length`, converted to `YGValue` at the public API boundary.
In the next step, we can plug in a new representation within `Style`, which should enable 64 bit values, and lower memory usage.
# Test Plan
1. Existing tests (inc for style, invalidation, CompactValue) pass
2. Check that constexpr `yoga::isinf()` produces same assembly under Clang as `std::isinf()`
3. Fabric Android builds
4. Yoga benchmark does style reads
# Performance
Checking whether a style is defined, then reading after, is a hot path, and we are doubling any space style lengths take in the stack (but not long-term on the node). After a naive move, on one system, the Yoga benchmark creating, laying out, and destroying a tree, ran about 8-10% slower in the "Huge nested flex" example. We are converting in many more cases instead of doing undefined check, but operating on accessed style values no longer needs to do the conversion multiple times.
I changed the `CompactValue` conversion to YGValue/StyleLength path to check for undefined as the common case (since we always convert, instead of calling `isUndefined` directly on CompactValue. That seemed to get the difference down to ~5-6% when I was playing with it then. We can optimistically make some of this up with ValuePool giving better locality, and fix this more holistically if we reduce edge and value resolution.
On another machine where I tested this, the new revision went the opposite direction, and was about 5% faster, so this isn't really a cut and dry regression, but we see different characteristics than before.
# Changelog
[Internal]
Reviewed By: rozele
Differential Revision: D51775346
fbshipit-source-id: c618af41b4882b4a227c917fcad07375806faf78
Summary:
This PR optimises RCTKeyWindow() calls in `RCTForceTouchAvailable` method. This method was calling RCTKeyWindow hundreds of times while scrolling on the screen.
Before:
On the video you can see that this function is being called **350 times** just from simple list scrolling. RCTKeyWindow is looping over app windows so it's not a cheap operation.
https://github.com/facebook/react-native/assets/52801365/5b69cbd6-d148-4d06-b672-bd7b60472c13
After: the function is called only few times at the start of the app to get initial layout measurements.
Solution: I think we can check just once for the force touch capabilities as devices can't change it on the fly
bypass-github-export-checks
## Changelog:
[IOS] [FIXED] - Optimise RCTKeyWindow() calls in RCTForceTouchAvailable method
Pull Request resolved: https://github.com/facebook/react-native/pull/41935
Test Plan: CI Green
Reviewed By: dmytrorykun
Differential Revision: D52172510
Pulled By: cipolleschi
fbshipit-source-id: 881a3125a2af4376ce65d785d8eee09c7d8f1f16
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41655
This diff adds support for checked-in codegen artifacts for libraries.
It introduces a new property to `codegenConfig`, called `includesGeneratedCode`. If codegen sees `includesGeneratedCode: true` in a project's dependency, it assumes that the library has codegen artifacts in it, and will not generate any code.
Changelog: [General][Added] - Introduce "codegenConfig.includesGeneratedCode" property.
Reviewed By: cipolleschi
Differential Revision: D51207265
fbshipit-source-id: 65855fd846e24a53cb18008839121e99eeb59309
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41924
`utils.parseArgs` are only available in Node >=18.3, we can't use this function because we target Node >=18.0.
This diff replaces `utils.parseArgs` with `yargs`.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D52117818
fbshipit-source-id: 79223997874b6cfdea2ce38243b615a0dbb704a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41982
Moving the check for Fabric i.e. `ReactFeatureFlags.enableFabricRenderer` to old JSI Module path logic instead of new UIManagerProvider path for Fabric initialization and changing the default of UIManagerProvider from `null` -> `reactApplicationContext -> null;` since we are adding null check on the returned `UIManager`
Slight change of design of API for JSI Module in order to address the issues faced due to `ReactFeatureFlags.enableFabricRenderer`,
1. Getting rid of this check for the new Fabric initialization and keeping the old JSI Module path intact.
2. Allowing the UIManager to be nullable so as to allow Twilight surface not have UIManager set even though they it succeeds in initializing the TwilightJSIModule.
3. As made the UIManager nullable, added the null check for the same.
4. This eradicates the dependency on this flag for Anna as well.
Reviewed By: christophpurrer
Differential Revision: D52273097
fbshipit-source-id: bdf8b1de3771250c987c8f8bd4e48192f67a1afa
Summary:
Passed `--mode HermesDebug` to `run-android` command when running from watch mode by pressing `a` on terminal running a dev server. The flag is the same as in the `package.json`:
https://github.com/facebook/react-native/blob/27f38f6f0647ec1809ee0a0d8e9da3a77a9115b1/packages/rn-tester/package.json#L17
## Changelog:
[INTERNAL] [CHANGED] - Add missing params when running Android app from watch mode by pressing `a`
Pull Request resolved: https://github.com/facebook/react-native/pull/41979
Test Plan: Run `yarn start` press `a` in the watch mode, and Android app should be build and launch correctly.
Reviewed By: cipolleschi
Differential Revision: D52265462
Pulled By: lunaleaps
fbshipit-source-id: b2fbe6c889d8067876e160a8ce64dedcc4ce24d7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41656
This change makes all the legacy components to go through the interop layer.
It also introduce the `RCTFabricInteropLayerEnabled()` and the `RCTEnableFabricInteropLayer(BOOL)` functions to work as feature flags behind the change to completely disable the Interop layer.
## Changelog
[iOS][Changed] - Make the Fabric Interop Layer automatic when the Nw architecture is enabled.
Reviewed By: cortinico
Differential Revision: D51586461
fbshipit-source-id: 8f92a76e6dbbee93055a1ebe49779dd64e484d95
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41972
This diff adds the `DoubleConversion` dependency to the `install_modules_dependencies` function, that installs all the dependencies that third-party libraries might need.
The libraries will need the `DoubleConversion` pod if they include the generated Fabric files.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D51848314
fbshipit-source-id: ae2ce022c6f51ce392852494c61e26ff810d30d0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41936
This argument was removed in D51303793. This diff removes all remaining usages of it.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D52035346
fbshipit-source-id: 99886be7ed810f58d8fb31fb22a44b2471e974ce
Summary:
Adds changelog for the 0.73.1 patch.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Add 0.73.1 changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/41970
Reviewed By: christophpurrer
Differential Revision: D52253474
Pulled By: huntie
fbshipit-source-id: 18fb45afcbb4fa0f864916922c0e9d69cc6d213f
Summary:
I believe it's valuable to be able to initialise the React Native template into a mono-repo and have it work with zero updates to the configuration.
In its current form the template's Xcode project makes assumptions on the relative location of the `react-native` package, while it could instead use the `REACT_NATIVE_PATH` variable set in the `scripts/cocoapods/utils.rb` script:
https://github.com/facebook/react-native/blob/2441fa284716ef782ec12dd0c2801548f8c47339/packages/react-native/scripts/cocoapods/utils.rb#L82
via
https://github.com/facebook/react-native/blob/2441fa284716ef782ec12dd0c2801548f8c47339/packages/react-native/template/ios/Podfile#L35
## Changelog:
[IOS] [ADDED] - Add use of the `REACT_NATIVE_PATH` in the "Bundle React Native code and images" shell script build phase. This will help apps initialized into a mono-repo which hoists the `react-native` package.
Pull Request resolved: https://github.com/facebook/react-native/pull/41968
Test Plan: I initialized the React Native template into an NPM workspaces mono-repo and experienced a failure running the script phase. I updated it to the code in this PR, which resolved the issue.
Reviewed By: christophpurrer, cipolleschi
Differential Revision: D52240559
Pulled By: robhogan
fbshipit-source-id: 1c5710c8ffe9d289f32c5ed83cb58ae27f3c931a
Summary:
X-link: https://github.com/facebook/yoga/pull/1525
Accidentally left this inconsistent with some of the refactoring. Rename the lone usage of `Length` within Style class to `Style::Length` to match the rest of the code.
This is functionally identical as before.
Changelog: [Internal]
bypass-github-export-checks
Reviewed By: yungsters
Differential Revision: D52096820
fbshipit-source-id: d6c569a02fb27a6e7548a9c12ff764afb823a282
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41964
X-link: https://github.com/facebook/yoga/pull/1524
D52087013 (#1513) fixed some issues, including where measuring under max-content or fit-content, align-content stretch would consume the entire available cross-dimensions, instead of only sizing to definite dimension, like the spec dicates.
I missed a case, where flexbox considers a container as having a definite cross-size if it is being stretched, even if it doesn't have a definite length.
https://www.w3.org/TR/css-flexbox-1/#definite-sizes
> 3. Once the cross size of a flex line has been determined, items in auto-sized flex containers are also considered definite for the purpose of layout;
> 1. If a single-line flex container has a definite cross size, the outer cross size of any stretched flex items is the flex container’s inner cross size (clamped to the flex item’s min and max cross size) and is considered definite.
We handle `align-items: stretch` of a flex container after cross-size determination by laying out the child under stretch-fit (previously YGMeasureModeExactly) constraint. This checks that case, and sizing the line container to specified cross-dim if we are told to stretch to it.
We could probably afford to merge this a bit with later with what is currently step 9, where we end up redoing some of this same math.
Reviewed By: yungsters
Differential Revision: D52234980
fbshipit-source-id: 475773a352fd01f63a4b21e93a55519726dc0da7
Summary: I've noticed that Bridge and Bridgeless initialize the list of ReactPackages using a different order, we are fixing it in this diff
Reviewed By: philIip
Differential Revision: D52145148
fbshipit-source-id: 6ad85bd0903f9beab455783e8deaf5c529b87a2e
Summary:
Since yesterday evening (why it is always friday evening???) CircleCI or Gem decided to update the default bundler version that is installed with `gem bundle install`.
Therefore, CI for iOS stopped working.
This change installs bundler's versions so that they are compatible with the Ruby version.
## Changelog:
[Internal] - Fix CI for iOS installing versions of bundler that are compatible with Ruby
Pull Request resolved: https://github.com/facebook/react-native/pull/41962
Test Plan: CircleCI is green
Reviewed By: GijsWeterings
Differential Revision: D52230544
Pulled By: cipolleschi
fbshipit-source-id: 2f96e16ecb94159953056e8de757ea4d249f80f0
Summary:
X-link: https://github.com/facebook/yoga/pull/1513
Pull Request resolved: https://github.com/facebook/react-native/pull/41916
Fixes https://github.com/facebook/yoga/issues/1300
Fixes https://github.com/facebook/yoga/issues/1008
This fixes a smattering of issues related to both sizing and aligment of multi-line-containers:
1. We were previously incorrectly bounding the size of each flex line to the min/max of the entire container.
2. Per-line leads were sometimes incorrectly contributing to alignment within the line
3. The cross dim size used for multi-line alignment is not correct, or correctly clamped. If the available size comes from a max constraint, that was incorrectly used instead of a definite size, or size of content. Leads were entirely skipped for min constraint.
Need to test how breaking this is, to see if it might need to go behind an errata.
See related PRs:
1. https://github.com/facebook/yoga/pull/1491
2. https://github.com/facebook/yoga/pull/1493
3. https://github.com/facebook/yoga/pull/1013
Changelog:
[General][Fixed] - Fix Yoga sizing and alignment issues with multi-line containers
Reviewed By: joevilches
Differential Revision: D52087013
fbshipit-source-id: 8d95ad17e58c1fec1cceab9756413d0b3bd4cd8f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41931
`GenericStyleProp` is defined as
```
type GenericStyleProp<+T> =
| null
| void
| T
| false
| ''
| $ReadOnlyArray<GenericStyleProp<T>>;
```
and `____FlattenStyleProp_Internal` is designed to reverse it. We can use conditional type to achieve it instead of $Call:
`null | void | false | ''` doesn't contribute to anything doing reversal, so they are mapped to empty. When we encounter $ReadOnlyArray, we recursively apply `____FlattenStyleProp_Internal`. Otherwise, we return the input type.
Changelog: [Internal]
Reviewed By: jbrown215
Differential Revision: D52142082
fbshipit-source-id: 590c71c6400498730675e20c67b173c3bc285d00
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41782
This diff adds `outputDir` property to `codegenConfig`.
Now codegen output dir is resolved like this:
1. It is set to `outputDir` argument of `generate-codegen-artifacts.js` if it is present.
2. *[New]* It is set to `outputDir` property of `codegenConfig` if it is present.
3. It is set to the project root.
Changelog: [General][Added] - Introduce "outputDir" property of "codegenConfig"
Reviewed By: cipolleschi
Differential Revision: D51494009
fbshipit-source-id: 0f6e3607b29a3c6d228a88a9460d55bb65c7e55a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41944
Changelog: [iOS][Deprecated]
i think we can now communicate the deprecation of this selector.
after removing all of the synthesize methodQueue callsites in our codebase, our native modules are still stable, save for one native module, RCTNetworking. so i feel comfortable recommending users to create their own queues.
and after removing `methodQueue` overrides to support synchronous void methods, those modules are also still stable, so i'm also comfortable we can recommend handling the dispatch_async in the product layer.
Reviewed By: arushikesarwani94, cipolleschi
Differential Revision: D52150696
fbshipit-source-id: ff6b90fc685796e5560167f1377a76526ee07744
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41942
Previously, every time a component was updated, we were passing all the props to the interoperated component.
With this change, we are going to only pass the props that are changed.
As a safety feature, if the new codepath is not able to detect the type of the prop properly, it will fall back to the previous behavior.
## Changelog:
[Internal] - Only pass props to the interoperated component when they changes
Reviewed By: sammy-SC
Differential Revision: D51755764
fbshipit-source-id: 0185d2cceeab2a1e45b87d5a1e82ab06e00aa82d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41941
While working on the interop layer, I realized that htis code is duplicated.
## Changelog
[Internal] - Use the same method for View And ShadowView in the Interop layer
Reviewed By: sammy-SC
Differential Revision: D51752171
fbshipit-source-id: 579652de262fea7edb13a1329cb07683eab78124
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41923
Changelog: [Internal][BREAKING] Use C++ enum classes in C++ Turbo Modules
Problem:
Using **C styles** `enums` can easily cause compiliation errors if symbol names collide. This code does not compile:
```
enum CustomEnumInt { A = 23, B = 42 };
static int A = 22;
```
This **C++ code**, using `enum classes` compiles:
```
enum class CustomEnumInt : int32_t { A = 23, B = 42 };
static int A = 22;
```
Reviewed By: rshest
Differential Revision: D52098598
fbshipit-source-id: c919bd2e41970c83a032fec91b0537cd6fae8397
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41903
These offset methods are supposed to be in reference to the node's nearest positioned (non-static) ancestor: https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/offsetParent. Right now, because static did not exist, they return the offset from the parent. This changes it so that the API is spec compliant and will look at the position of its ancestors before settling on the right offset. I added a helper `getNewestPositionedAncestorOfShadowNode` to get the correct node. Then I use that to calculate the proper offset
Changelog: [Internal]
Reviewed By: rubennorte, NickGerleman
Differential Revision: D51414950
fbshipit-source-id: ebc8de1d3a0f3e9485f63e792b5bef5b9151460d
Summary:
When using `RCT_EXTERN_REMAP_MODULE` a warning is produced with the following message: "A function declaration without a prototype is deprecated in all versions of C". This warning can be silenced by setting the `CLANG_WARN_STRICT_PROTOTYPES ` build setting. However this PR addresses the underlying problem resulting in no warning messages.
## Changelog:
[IOS] [FIXED] - Fixed strict prototype warning when using the RCT_EXTERN_REMAP_MODULE macro.
Pull Request resolved: https://github.com/facebook/react-native/pull/41805
Reviewed By: NickGerleman
Differential Revision: D51891880
Pulled By: dmytrorykun
fbshipit-source-id: 7804d624b248b568643956a8a7b7e0f8540b5ae2
Summary:
When publishing my RN fork I hit this issue where a RCTThirdPartyFabricComponentsProvider module would end up in the npm tarball which causes build issues. This file is generated by codegen and should never be included.
## Changelog:
[INTERNAL] [FIXED] - Ignore RCTThirdPartyFabricComponentsProvider for npm publish
Pull Request resolved: https://github.com/facebook/react-native/pull/41868
Test Plan: Tested that the file is no longer included when publishing my RN fork
Reviewed By: christophpurrer
Differential Revision: D52032223
Pulled By: dmytrorykun
fbshipit-source-id: a846813176d60119d97261131fd9d9a6aa919e62
Summary:
The height returned by TextInput's 'onContentSizeChange' callback method is incorrect
Because, the borderwidth and horizontal padding are not subtracted from the content width used to calculate the height of the text.
I have seen many people in the same situation in many issues. When I solved, some people suggested I submit a PR.
More information can be found here [https://github.com/facebook/react-native/issues/35234](https://github.com/facebook/react-native/issues/35234#issuecomment-1831141903)
## Changelog:
[IOS] [FIXED] - the wrong height result of onContentSizeChange callback
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/41803
Test Plan: CI Green
Reviewed By: NickGerleman
Differential Revision: D51891909
Pulled By: dmytrorykun
fbshipit-source-id: fa297155ebdfc933cf0ea6bcdab37d7410809e8c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41914
If the user does not specify which engine they're using, we still default to loading JSC first and then attempting to load Hermes.
This has a small performance hit (as we attempt to load an existing library) + it prints an inactionable log for the user every time.
Changelog:
[Android] [Fixed] - Update getDefaultJSExecutorFactory to load Hermes first and fallback to JSC
Reviewed By: luluwu2032
Differential Revision: D52080545
fbshipit-source-id: 95f37304d713da7d7079eabbd2dfdf230d29a1b9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41912
Progress towards an opt-in setup for our new CDP backend.
- For `DevSupportManagerBase` on Android: Conditionally omit sending `Debugger.disable` CDP message when new CDP backend is enabled.
Reviewed By: motiz88
Differential Revision: D52040149
fbshipit-source-id: 452f46395261d2d9670bd38192d06e6fa8e1f93f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41913
Progress towards an opt-in setup for our new CDP backend.
- Adds and configures an [fbjni](https://github.com/facebookincubator/fbjni) interface for reading `jsinspector_modern::InspectorFlags`, allowing access in Java contexts.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D52040150
fbshipit-source-id: 5459eda2747279633a8312a3979ba29a1e0d1bde
Summary:
There is currently an error when building in release on iOS when using asset catalogs (experimental feature that is partially merged https://github.com/facebook/react-native/pull/30129)
This was probably incorrectly migrated from the community cli repo. `.imageset` is actually folders so it needs to be removed with `{recursive: true, force: true}`. I also renamed the variable `files` which is confusing since its folders.
## Changelog:
[IOS] [FIXED] - Fix cleanAssetCatalog error
Pull Request resolved: https://github.com/facebook/react-native/pull/41865
Test Plan: Tested in an app that uses asset catalogs
Reviewed By: NickGerleman
Differential Revision: D52032258
Pulled By: huntie
fbshipit-source-id: 1dc0ca09e0da0d514b03d7d72707bdcaef03301d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41831
The build is currently firing several build warnings due to the Groovy -> Kotlin migration.
I've fixed them all over here.
Changelog:
[Internal] [Changed] - Resolve several Gradle build warning
Reviewed By: mdvacca
Differential Revision: D51890225
fbshipit-source-id: 4a2ff9dc168fca62893db704e282793e0bf03653
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41832
I'm removing the `installArchives` task and all the setup to publish
the Maven Local inside the NPM package as we're not using this entirely
and we won't be able to use it anyway (as the Maven Local is too big to fit an NPM package).
Changelog:
[Internal] [Changed] - Remove the installArchives task
Reviewed By: GijsWeterings
Differential Revision: D51890224
fbshipit-source-id: 3ffdc67a9fe931118596f6f74a5a2df0313ca3f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41834
I'm updating other two `build.gradle` to `build.gradle.kts` files.
The only functional change I made was to remove the function to check if major >= 1 and turn on New Architecture. This needs to be moved to RNGP as Kotlin doesn't have dynamic accessors to Object so we can't convert that function.
Changelog:
[Internal] [Changed] - Convert ReactAndroid and RN-Tester to Kotlin DSL
Reviewed By: mdvacca
Differential Revision: D51856356
fbshipit-source-id: ef75579cd3ec121ef6ac9a357c1e10bcf9995432
Summary:
The logic to constrain the last spacer size is incorrect in some cases where the spacer is the last spacer, but not the last section in the list.
For more context, the role of spacer constraining is explained in this comment:
```
// Without getItemLayout, we limit our tail spacer to the _highestMeasuredFrameIndex to
// prevent the user for hyperscrolling into un-measured area because otherwise content will
// likely jump around as it renders in above the viewport.
```
For example it is incorrect in the case where we have:
ITEMS
SPACER
ITEMS
In this case the spacer is not actually the tail spacer so the constraining is incorrectly appied.
This causes issues mainly when using `maintainVisibleContentPosition` since it will cause it to scroll to an incorrect position and then cause the view that was supposed to stay visible to be virtualized away.
## Changelog:
[GENERAL] [FIXED] - Fix last spacer constrain logic in VirtualizedList
Pull Request resolved: https://github.com/facebook/react-native/pull/41846
Test Plan:
Tested using https://gist.github.com/janicduplessis/b67d1fafc08ef848378263208ab93d4c in RN tester, before the change content will jump on first click on add items.
Tested using the same example and setting initial posts to 1000, then we can see our content view size is still constrained properly (see scrolling indicator as reference).
Reviewed By: yungsters
Differential Revision: D51964500
Pulled By: NickGerleman
fbshipit-source-id: 4465aa5a36c95466aef6571314973c1e2c9a0f2c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41672
Progress towards an opt-in setup for our new CDP backend.
- Adds `InspectorFlags.h`, a singleton intended to allow convienient access to static boolean feature flags for the new CDP backend/inspector features across platforms. This will be written to in upcoming diffs, with the accessor for `enable_modern_cdp_registry` soft-defaulting to `false` here.
- References this to conditionally disable legacy ~CDP registration in `HermesExecutorFactory` (Bridge) and `HermesInstance` (Bridgeless) code paths.
- Stubs a `false` value for `react_native_devx:enable_modern_cdp_registry` in `EmptyReactNativeConfig` (documentation/convenience point for open source partners and integrators).
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D51563107
fbshipit-source-id: 446f319228ec627fdc0ecba9517a1a3faad9d262
Summary:
X-link: https://github.com/facebook/yoga/pull/1497
The lowest common denominator we have had for Yoga has been Clang 12 + MSVC 2017 stdlib. This has allowed Yoga to use C++ 20 language features, but not library features. React Native for mobile has not been bound to this restriction.
Builds using that toolchain are being updated to latest MSVC 2019 stdlib (which has good C++ 20 library support), along with Clang 17 (or maybe a stop at 15) pending projects using `-fcoroutines-ts` being migrated to C++ 20.
This tests out some C++ 20 standard library usages against the current Clang 12 + MSVC 2019 stdlib toolchain that didn't work before, and adds a couple concepts for better constraints/compiler error messages if misused.
This bumps min-tested XCode (and minimum required) version to 14.3, matching a similar change for React Native. This should probably be bumped to 15 sometime before Apple starts requiring 15+ to go out to the iOS app store.
We are approaching a practical support range of:
1. XCode >= 14.3
2. NDK >= 26
3. Clang/libc++ >= 14
4. GCC/libstdc++ >= 11
5. MSVC >= 16.11 (VS 2019)
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D51604487
fbshipit-source-id: d394d0d86672b69781b8ae071d87adcf944ddc72
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41866
Direct recursive member types require infinite memory and aren't possible with current hardware.
Throw parser error to make this visible.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D51999832
fbshipit-source-id: 671f87325f33dd24f70ff3e2229c9d0b888d7445
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41471
Changelog: [Internal] - Clean up eventTarget retaining logic in the pointer event processor
This refactors calls to EventTarget::retain/release to occur in the actual methods that require the event target to be retained instead of expecting the caller to manage that which should be more maintainable.
Reviewed By: sammy-SC
Differential Revision: D51279974
fbshipit-source-id: db7251504a44ca59e4475928af7e6cf993cfa6e3
Summary:
Why ignore for now?
- It only happen once during initialization and doesn't cause any breakages for RNTester
- The race condition happens in Android System code which is hard to tackle:
```Exception in native call
java.lang.NullPointerException: java.lang.NullPointerException
at com.facebook.jni.NativeRunnable.run(Native Method)
at android.os.Handler.handleCallback(Handler.java:958)
at android.os.Handler.dispatchMessage(Handler.java:99)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:30)
at android.os.Looper.loopOnce(Looper.java:205)
at android.os.Looper.loop(Looper.java:294)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:235)
at java.lang.Thread.run(Thread.java:1012)
```
From stack trace message.callback is checked in
```at android.os.Handler.dispatchMessage(Handler.java:99)```
but becomes null in
```at android.os.Handler.handleCallback(Handler.java:958)```
[Android source code](https://l.facebook.com/l.php?u=https%3A%2F%2Fandroid.googlesource.com%2Fplatform%2Fframeworks%2Fbase%2F%2B%2Fmaster%2Fcore%2Fjava%2Fandroid%2Fos%2FHandler.java&h=AT1aQS0Vmknao8kLbYE_hhLj1G3idUf69jFQE3ZLAqjrbcMX4OdQUV1dzZpAkAvLaZ9HAOanpsKCC8z59Ce9XJa6cOhQL2L95gM9iMrSr7FbrpTKPLKbWjDmTz89WUL2pQprnBVKyA8) of Handler.
Reviewed By: cortinico
Differential Revision: D51550240
fbshipit-source-id: 6288e196da1da88a37f5c69bfce82e3e09c6f106
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41819
This will be needed in order to access the position type while implementing offsetLeft/Top, which needs to know if a node is static or not to get the proper offset. This is simply making the position type available to be read from LayoutMetrics.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D51412428
fbshipit-source-id: b101d8065ddfe0322f77f64d1de0f9ead3975c60
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41889
Resubmit of D51891716
I'm doing a pass and converting the last Java Unit Tests we had to Kotlin
I've also re-enabled multiple tests that were disabled in the past.
Changelog:
[Internal] [Changed] - Convert the last Unit Tests to Kotlin
Reviewed By: GijsWeterings
Differential Revision: D52033328
fbshipit-source-id: fabe19f88129f5c4b1d77d45cf5089117aed439e
Summary:
This PR fixes https://github.com/facebook/react-native/issues/41874.
## 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] - Fix NSAppTransportSecurity being overwritten during pod install
Pull Request resolved: https://github.com/facebook/react-native/pull/41875
Test Plan:
1. Delete the whole `NSAppTransportSecurity` in Info.plist and run `pod install`: `NSAllowsArbitraryLoads` and `NSAllowsLocalNetworking` are added as expected.
2. Modify `NSAppTransportSecurity` to only contain `NSExceptionDomains` and run `pod install`: `NSAllowsArbitraryLoads` and `NSAllowsLocalNetworking` are added, and `NSExceptionDomains` is still there.
3. Run `pod install` again: nothing changes.
Reviewed By: christophpurrer
Differential Revision: D52032400
Pulled By: dmytrorykun
fbshipit-source-id: 48cf29809c283af80613ffbf1ac0dc663a0a2fb5
Summary:
Bridgeless dev menu couldn't open due to self.bridge being null here.
Changelog:
[Android][Changed] - Fix dev menu not open for Bridgeless
Reviewed By: cortinico
Differential Revision: D51746610
fbshipit-source-id: 2e9bab686c965271bbfad264ff22ff61e28849c3
Summary:
To unlock ~~certain OOT platform capabilities~~ seamless `init` integration for out-of-tree platforms with CLI, we need to pass the package name to it. This change landed on 0.73 branch already: https://github.com/facebook/react-native/pull/41530
Depends on https://github.com/facebook/react-native/issues/41722
## Changelog:
[INTERNAL] [ADDED] - Fix init for out-of-tree platforms by passing name to CLI
Pull Request resolved: https://github.com/facebook/react-native/pull/41723
Test Plan: CI green
Reviewed By: christophpurrer
Differential Revision: D51979329
Pulled By: dmytrorykun
fbshipit-source-id: 451f70dc42ae0667bc65cba2e77898c9eec8d9ec
Summary:
Small edit to point to the newer React Native docs guide for Metro, which includes more clarity on the `metro.config.js` file setup in React Native projects.
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/41855
Test Plan: —
Reviewed By: christophpurrer
Differential Revision: D52031862
Pulled By: huntie
fbshipit-source-id: 705418f35e5f6a3eddbec129e283773bb9d0f89c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41880
Pull Request resolved: https://github.com/facebook/react-native/pull/41664
Moving the check for Fabric i.e. `ReactFeatureFlags.enableFabricRenderer` to old JSI Module path logic instead of new UIManagerProvider path for Fabric initialization
Reviewed By: philIip
Differential Revision: D51610399
fbshipit-source-id: 1d868111dd2b65ac8d69198f7ab115ac8a2b43ec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41852
I'm doing a pass and converting the last Java Unit Tests we had to Kotlin
I've also re-enabled multiple tests that were disabled in the past.
Changelog:
[Internal] [Changed] - Convert the last Unit Tests to Kotlin
Reviewed By: mdvacca
Differential Revision: D51891716
fbshipit-source-id: 7f953cf039a7b45bd773d1995253b4db262f8d22
Summary:
This PR adds build generated files to *ignore config files. This allows to locally run `yarn lint`
## Changelog:
[INTERNAL] [ADDED] - Add build generated files to local config files
Pull Request resolved: https://github.com/facebook/react-native/pull/41826
Test Plan: CI Green
Reviewed By: huntie
Differential Revision: D51939024
Pulled By: cortinico
fbshipit-source-id: cfd6c1c13dd23c692859cd06fa5955024fafc522
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41835
This removes internal usages of `onCatalystInstanceDestroy`.
The method is still available inside `NativeModule` but is `Deprecated(forRemoval = true)` so we're getting warning of its usages all over the places.
Changelog:
[Internal] [Changed] - Remove internal references of onCatalystInstanceDestroy()
Reviewed By: hoxyq
Differential Revision: D51589276
fbshipit-source-id: 84ed4d099a444977b95b4ef00e53750b79018e6f
Summary:
X-link: https://github.com/facebook/yoga/pull/1490
Pull Request resolved: https://github.com/facebook/react-native/pull/41692
In the previous diffs I fixed problems with justifying absolute nodes. The same issues plague aligning so I fixed them in the same way. Added tests that were failing before but now passing
Reviewed By: NickGerleman
Differential Revision: D51404489
fbshipit-source-id: 604495d651eb67cfdcca40df9d8d3a125c5741a8
Summary:
X-link: https://github.com/facebook/yoga/pull/1487
Pull Request resolved: https://github.com/facebook/react-native/pull/41691
The code here was just wrong. I changed it to be the same logic as the Justify:FlexStart case, but with the flex end sides. Then I get the position for the opposite edge since we need to write to flex start side.
Reviewed By: NickGerleman
Differential Revision: D51383792
fbshipit-source-id: 372835a44edff361dbd84dd92ff9f2ec844b9f9c
Summary:
X-link: https://github.com/facebook/yoga/pull/1489
Pull Request resolved: https://github.com/facebook/react-native/pull/41690
Centering involves centering the margin box in the content box of the parent, and then getting the distance from the flex start edge of the parent to the child
Reviewed By: NickGerleman
Differential Revision: D51383625
fbshipit-source-id: 6bbbace95689ef39c35303bea4b99505952df457
Summary:
X-link: https://github.com/facebook/yoga/pull/1485
Pull Request resolved: https://github.com/facebook/react-native/pull/41686
The size of the containing block is the size of the padding box of the containing node for absolute nodes. We were looking at `containingNode->getLayout().measuredDimension(Dimension::Width)` which is the border box. So we need to subtract the border from this.
Added a test that was failing before this change as well
Reviewed By: NickGerleman
Differential Revision: D51330526
fbshipit-source-id: adc448dfb71b54f1bbed0d9d61c5553bda4b106c
Summary:
X-link: https://github.com/facebook/yoga/pull/1482
Pull Request resolved: https://github.com/facebook/react-native/pull/41685
This is the final step (that I know of) to get the core features of static working. Here we turn on all of the tests and pass down the correct owner size for the call to `calculateLayoutInternal` that is in `layoutAbsoluteChild`
Reviewed By: NickGerleman
Differential Revision: D51293606
fbshipit-source-id: 972259e7ebecb19b55aef2ef866bd7cb57aaf0ca
Summary:
X-link: https://github.com/facebook/yoga/pull/1481
Pull Request resolved: https://github.com/facebook/react-native/pull/41684
Absolute nodes can be laid out by themselves and do not have to care about what is happening to their siblings. Because of this we can make `positionAbsoluteChild` the sole place where we handle this logic. Right now that is scattered around algorithm with many `if (child is absolute)` cases everywhere. This makes implementing position static a lot harder since we are relying on the CB to do all this work, not the parent.
With this change the only time we set position for an absolute node and it matter (i.e. not overwritten) is in `positionAbsoluteChild`
Reviewed By: NickGerleman
Differential Revision: D51290723
fbshipit-source-id: 405d81b1d28826cbb0323dc117c406a44d381dff
Summary:
This enables the network panel/inspector by passing the `unstable_enableNetworkPanel=true` to the React Native JS Inspector. (See https://github.com/facebookexperimental/rn-chrome-devtools-frontend/pull/2)
By setting this inside the `experiments`, we can enable/disable network related CDP handlers within the proxy.
## Changelog:
[GENERAL] [ADDED] - Add `enableNetworkInspector` experiment to enable Network panel and CDP handlers in inspector proxy
Pull Request resolved: https://github.com/facebook/react-native/pull/41787
Test Plan: TBD, will provide a repository using an Expo canary / RN 0.73.0-rc release.
Reviewed By: NickGerleman
Differential Revision: D51811892
Pulled By: huntie
fbshipit-source-id: 541d96b6f0735104a4050a24a152e1158871ed1d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41828
Bumping the docker image used inside CircleCI to v12
This image contains NDK 26.0.10792818 which was bumped recently.
Without it the CI will attempt to download it everytime consuming time and bandwidth
Changelog:
[Internal] [Changed] - Bump Android Docker Image to v12
Reviewed By: NickGerleman
Differential Revision: D51897068
fbshipit-source-id: a510568efc2574917d94371eeab6f0a53550bc1d
Summary:
This PR convert `ReactPropForShadowNodeSetterTest` to kotlin as part of https://github.com/facebook/react-native/issues/38825
## Changelog:
[INTERNAL] [CHANGED] - Convert ReactPropForShadowNodeSetterTest to kotlin
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/41774
Test Plan:
```
./gradlew :packages:react-native:ReactAndroid:test
```
Reviewed By: NickGerleman
Differential Revision: D51882685
Pulled By: cortinico
fbshipit-source-id: ff1cce824dc342200f1f5ccbb297b955747b10c8
Summary:
As the title says, if we discover that an issue needs a repro, then we should also apply
the "Needs: Author Feedback" as that will make the issue stale quicker (30 days) rather than (90)
Changelog:
[Internal] [Changed] - Adds "Needs: Author Feedback" if "Needs: Repro" is applied
Reviewed By: NickGerleman
Differential Revision: D51895945
fbshipit-source-id: 3ed651aec96795ada3e7c28b0f1e68d68f7fc870
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41815
Our Apps in OSS ends up shipping with too many .so files.
I'm attempting to move several libraries from dynamic to static.
This is a first round of it affecnting only libraries which are not
exposed via prefab and that are not having an OnLoad method
Changelog:
[Internal] [Changed] - Move several libraries to static linking
Reviewed By: NickGerleman
Differential Revision: D51895785
fbshipit-source-id: 1ba2dbbbae6b6c2639ba0e064f1b331b2a157f03
Summary:
Adds changelog for the 0.73.0 release. The changelog was generated using the following command: `npx rnx-kit/rn-changelog-generator --base v0.73.0-rc.4 --compare v0.73.0-rc.8`
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [CHANGED] - Add changelog for the 0.73.0 release.
Pull Request resolved: https://github.com/facebook/react-native/pull/41741
Test Plan: Read the changelog 🤞
Reviewed By: rubennorte
Differential Revision: D51892080
Pulled By: huntie
fbshipit-source-id: 191ece6dbb1a65210efb16e13fdab49b55b84145
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41806
Changelog: [Internal]
Adds `isChildPublicInstance` to renderers implementations, which makes it available for usage from `RendererProxy`.
Reviewed By: rubennorte
Differential Revision: D51822905
fbshipit-source-id: 3ac92ead9d31dd3c7e5e7764daf27fe5f0eca942
Summary:
Apple will require XCode 15 next year to ship to the app store, and it aligns with how we build and test React Native internally.
XCode 15 and 14.3 add support for a lot of [missing C++ 20 features](https://developer.apple.com/xcode/cpp/#c++20) from earlier versions as well.
Last I was aware, Riccardo was onboard with bumping min supported in 0.74 to XCode 15. This change does a slightly more conservative bump to min 14.3, and main of 15.0 (though we might want to move these before 0.74 comes out).
All of this will get migrated over to GHA soon enough as well, but... formalizing this is the only thing blocking usage of C++ 20 ranges today.
Changelog:
[ios][breaking] - Require XCode >= 14.3
Pull Request resolved: https://github.com/facebook/react-native/pull/41798
Test Plan:
1. CircleCI Passes
2. Can still boot RNTester from XCode with code signing related changes.
Reviewed By: cortinico
Differential Revision: D51840617
Pulled By: NickGerleman
fbshipit-source-id: 58f8951a436eb7c892a00432a8aad0ddd0a49da1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41812
# Changelog:
[Internal]-
This makes sure that unit tests that use okhttp, do consistently use okhttp v4 for both gradle and buck based workflows when running tests.
Reviewed By: christophpurrer
Differential Revision: D51864344
fbshipit-source-id: 7fd80fd1e7e9ccdc5ec75a41c5dd03f9fc2751a0
Summary:
Changelog: [Internal]
This makes a couple objects more exact. Nothing critical, just noticed
this old branch I had created when doing some Flow upgrades in the past.
DiffTrain build for commit https://github.com/facebook/react/commit/f498aa299292d4d1e999f66d1c769440ad10d57c.
Reviewed By: hoxyq
Differential Revision: D51824015
Pulled By: kassens
fbshipit-source-id: ecadc98ffb233d6458c65c38150a29ff65a10121
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41811
In this diff I'm extracting binaryCompatibilityValidator configuration into gradle.properties file. The goal is to reuse these properties from BUCK
changelog:[Internal] internal
Reviewed By: cortinico
Differential Revision: D51402033
fbshipit-source-id: 9b585dd07c5c00a39caadac47a2f0d605c5419f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41804
Those 4 tests are Ignored since a while and I haven't found a easy way to re-enable them. I believe we can safely delete them.
Changelog:
[Internal] [Changed] - Remove dead unit tests related to text/layout property settings.
Reviewed By: sammy-SC
Differential Revision: D51848089
fbshipit-source-id: 89880f5402774cb0560ac8fe4ba21e1e44c24889
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41800
I've cleaned up the new issue template:
1. Added Expo to the template selector list
2. Added a short blurb with relevant links at the beginning of every issue template
3. I've added a dedicated field for reproducer and one for extra
4. I've added rendering to the react-native info block
5. I've added another rendered blog for stacktraces.
6. I've added a drop-down item for affected platform
Changelog:
[Internal] [Changed] - Refresh the New Issue template
Reviewed By: GijsWeterings
Differential Revision: D51847659
fbshipit-source-id: 565a2dcab4913825f441e2315ae9b4dd34fd2f4f
Summary:
X-link: https://github.com/facebook/yoga/pull/1494
Pull Request resolved: https://github.com/facebook/react-native/pull/41788
Those tests are currently disabled due to Yoga attempting to do JNI calls.
I've added infra to bypass .so loading during tests, and we should be good to re-enable those tests by now.
Changelog:
[Internal] [Changed] - Re-enabled disabled tests ReactPropForShadowNodeSpecTest and ReactPropForShadowNodeSetterTest
Reviewed By: NickGerleman
Differential Revision: D51814491
fbshipit-source-id: adbbace19c94a0c6d8947f61221fafafd7797ac8
Summary:
X-link: https://github.com/facebook/yoga/pull/1495
Pull Request resolved: https://github.com/facebook/react-native/pull/41794
This is a copy of D51369722 to make it so that it preserves the file history
CalculateLayout.cpp is massive and approaching 3k lines. I added a few large functions dealing with layout of absolute nodes and was thinking it would be nice if that logic was just in its own file so it was more isolated and easier to reason about. So I made AbsoluteLayout.cpp and AbsoluteLayout.h to house this logic. In order for this to work I had to expose calculateLayoutInternal in CalculateLayout.h as layoutAbsoluteChild calls it. This is unideal and I would like to find a better way...
I also make LayoutUtils.h to house misc small helper methods as they are called in AbsoluteLayout.cpp and CalculateLayout.cpp
Reviewed By: NickGerleman
Differential Revision: D51824115
fbshipit-source-id: 9b27449e3c1516492c01e6167a6b2c4568a33807
Summary:
X-link: https://github.com/facebook/yoga/pull/1479
Pull Request resolved: https://github.com/facebook/react-native/pull/41682
There are two ways to get the value of a style for a specific edge right now:
1) From the inline start/end edge which is determined via the writing direction (ltr or rtl), assuming you do not have errata on
2) From the flex start/end edge which is determined via the flex direction (row, row-reverse, column, column-reverse)
There is a weird curiosity in the second case: you can define a style to be on the "start" or "end" edge when writing the stylex/css. The physical edge that this refers to is dependent on the writing direction. So `start` would be `left` in `ltr` and `right` in `rtl`, with `end` the opposite. It is **never** determined via the flex direction. Additionally, `start`/`end` takes precedence over the physical edge it corresponds to in the case both are defined.
So, all of this means that to actually get the value of a style from the flex start/end edges, we need to account for the case that one of these relative edges was defined and would overwrite any physical edge. Since this mapping is solely determined by the writing direction, we need to pass that in to all the flex start/end getters and do that logic. This is done in `flexStartRelativeEdge`/`flexEndRelativeEdge` which was added earlier but for some reason only being used on border.
Reviewed By: NickGerleman
Differential Revision: D51293315
fbshipit-source-id: 26fafff54827134e7c5b10354ff9bfdf67096f5b
Summary:
X-link: https://github.com/facebook/yoga/pull/1473
Pull Request resolved: https://github.com/facebook/react-native/pull/41491
To simplify the logic a bit I introduce a new function called `positionAbsoluteChild`. This function will, eventually, be the **sole function that matters** when determining the layout position of an absolute node. Because [absolute nodes do not participate in flex layout](https://drafts.csswg.org/css-flexbox/#abspos-items), we can determine the position of said node independently of its siblings. The only information we need are the node itself, its parent, and its containing block - which we have all of in `layoutAbsoluteChild`.
Right now, however, this is purely a BE change with no functionality different. There was a big set of if statements at the end of `layoutAbsoluteChild` that would position the node on the main and cross axis for certain cases. The old code had it so that the main and cross axis had basically the same logic but the code was repeated. This puts that logic, as is, in `positionAbsoluteChild` and calls that from `layoutAbsoluteChild`.
I will soon edit this function to actually do what it is envisioned to do (i.e. be the sole place that position is set for absolute nodes).
Reviewed By: NickGerleman
Differential Revision: D51272855
fbshipit-source-id: 68fa1f0e0f4d595faf2af1d9eaceb467382ca406
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41490
X-link: https://github.com/facebook/yoga/pull/1472
This change has most of the logic needed for supporting `position: static`. We do two things here that fix a lot of the broken static test:
1) We pass in the containing node to `layoutAbsoluteChild` and use it to properly position the child in the case that insets are defined.
2) We rewrite the absolute child's position to be relative to it's parent in the event that insets are defined for that child (and thus it is positioned relative to its CB). Yoga's layout position has always be relative to parent, so I feel it is easier to just adjust the coordinates of a node to adhere to that design rather than change the consumers of yoga.
The "hard" part of this algorithm is determining how to iterate the offset from the containing block needed to do this translation described above. That is handled in `layoutAbsoluteDescendants`.
Reviewed By: NickGerleman
Differential Revision: D51224327
fbshipit-source-id: ae6dc54fe2a71bebb4090ba21a0afb0125264cbc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41489
X-link: https://github.com/facebook/yoga/pull/1471
If we are going to allow the containing block to layout its absolute descendants and NOT the direct parent then we need to change step 11 which is concerned with setting the trailing position in the case we are row or column reverse. This is the very last step in the function and is positioned that way because it operates on the assumption that all children have their position set by this time. That is no longer a valid assumption if CBs layout their absolute children. In that case the CB also needs to take care of setting the position here.
Because of this problem I moved some things around. It now works like:
* If errata is set, the direct parent will set trailing position for all non absolute children in step 11
* If errata is set the CB will set trailing position of absolute descendants after they are laid out inside of layoutAbsoluteDescendants
Reviewed By: NickGerleman
Differential Revision: D51217291
fbshipit-source-id: a7eea0d3623f9041b73d609a1de2bfb0f0343a26
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41488
X-link: https://github.com/facebook/yoga/pull/1470
The way we plan on implementing `position: static` is by changing how we lay out absolutely positioned nodes. Instead of letting their direct parent lay them out we are going to let their containing block handle it. This is useful because by the time the containing block gets to this step it will already know its size, which is needed to ensure that absolute nodes can get the right value with percentage units. Additionally, it means that we can "translate" the position of the absolute nodes to be relative to their parent fairly easily, instead of some second pass that would not be possible with a different design.
This change just gets the core pieces of this process going. It makes it so that containing blocks will layout out absolute descendants that they contain. We also pass in the containing block size to the owner size args for `layoutAbsoluteChild`. This new path will only happen if we have the errata turned off. If there is no positioned ancestor for a given node we just assume the root is. This is not exactly how it works on the web - there is a notion of an initial containing block - but we are not implementing that as of right now.
Reviewed By: NickGerleman
Differential Revision: D51182593
fbshipit-source-id: 88b5730f7f4fec4f33ec64288618e23363091857
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41771
Changelog: [Internal]
Since we are already enforcing C++20 (and 17), we can set the namespace declaration to the C++17 style
Reviewed By: NickGerleman
Differential Revision: D51789991
fbshipit-source-id: 165d7d4e652d60ab200e2355e084010a02f470a4
Summary:
In this diff I'm integrating 'org.jetbrains.kotlinx.binary-compatibility-validator' into RN Android build gradle system.
The tool allows dumping binary API of a JVM part of a Kotlin library that is public in the sense of Kotlin visibilities and ensures that the public binary API wasn't changed in a way that makes this change binary incompatible
More context on https://github.com/Kotlin/binary-compatibility-validator#building-the-project-locally
bypass-github-export-checks
Reviewed By: cortinico
Differential Revision: D51262577
fbshipit-source-id: 1894f4e55a4019e3ce1585e9df12dee69944e5ce
Summary:
When working with Verdaccio (testing the template, releasing packages) - I've stumbled upon a lot of changes in the repo:

## Changelog:
[INTERNAL] [ADDED] - Add verdaccio generated files to .gitignore
Pull Request resolved: https://github.com/facebook/react-native/pull/41783
Test Plan: CI Green
Reviewed By: christophpurrer
Differential Revision: D51808583
Pulled By: huntie
fbshipit-source-id: fec2a13883590d0c6af179c3804fba9d4235dde2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41767
Changelog: [Internal]
Adds a simple example showing a direct recursive node in a Cxx TM.
Currently we can't auto-generate [the necessary C++ Types](https://reactnative.dev/docs/next/the-new-architecture/cxx-custom-types#struct-generator) - but we can add it later if this scenarios becomes really common.
Direct recursive nodes, can't be value types - it would require infinite memory. Hence they are nullable and managed by a smart pointer.
Reviewed By: rshest
Differential Revision: D51784136
fbshipit-source-id: f6f0710d03583bdf1e6e72ba42d8df7f8ff8d915
Summary:
Was stepping with debugger through the code & noticed few typos.
## 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] - Typos in `ReactCompoundViewGroup` comments
Pull Request resolved: https://github.com/facebook/react-native/pull/41729
Test Plan: Typos in docs
Reviewed By: cortinico
Differential Revision: D51753447
Pulled By: arushikesarwani94
fbshipit-source-id: b373d67ca8b6c9f22d80ea1ccee98ecc5151b325
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41733
I am currently implementing position: static in Yoga. I have a huge stack of changes that is ready to ship but we are waiting on the default position type to be relative before shipping. The reason being, my changes will affect a whole ton of styles where there is no position set so if we can make static no longer the default we can safely ship this new code. However, this will take a while and keeping up with this stack of diffs though merge conflicts, flakey tests, and general slowness for my IDE is getting annoying. So a solution here is to ship that stack and make it so that no one gets this functionality by changing the strict layout conformance to include the errata that is gating my changes. The end result being that the code can be shipped but will have no affect at the time being.
Right now, because that code is in a different branch and not on prod, this change will do nothing.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D51731778
fbshipit-source-id: f0b7fd8559adb19e1658b3ac64fcfc4c5f8ecdf7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41739
Refactoring `DefaultReactNativeHost` to use the new way of Fabric initialization through `FabricUIManagerProviderImpl`
Reviewed By: philIip
Differential Revision: D51719555
fbshipit-source-id: bad471a8a273accecb0641ccaa77223534cd45fd
Summary:
iOS?ios?android?Android?
Always making typos when using the local testing script with the platform argument... No more!
## Changelog:
[INTERNAL][ADDED] - Improved E2E local testing script to be more flexible
Pull Request resolved: https://github.com/facebook/react-native/pull/41751
Reviewed By: cortinico
Differential Revision: D51758529
Pulled By: huntie
fbshipit-source-id: d9e633567a59fcfac1057cf1f21714ccef27ebb2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41738
Replacing the callsite to `context.getFabricUIManager()` in UIManagerHelper instead of `getJSIModule()`
Fixing the crash by directly making `getFabricUIManager()` of `ReactContext` independent of the assertion.
Reviewed By: philIip
Differential Revision: D51719040
fbshipit-source-id: f9118b16614724a1d6dabe59d5c4d25dd4bdbc73
Summary:
Currently React Native defines `NDEBUG` flag for all pods in Fabric only. This is useful for other libraries, like Reanimated, because they have no easy way of defining their compilation flags (at least none that I know of). Therefore defining `NDEBUG` for both architectures would be beneficial.
## Changelog:
Pick one each for the category and type tags:
[IOS] [CHANGED] - Add `NDEBUG` flag for Release builds for both architectures
Pull Request resolved: https://github.com/facebook/react-native/pull/41715
Test Plan:
Run ruby test suite.
## Notes
For the time being I just copied
`prepare_pod_target_installation_results_mock`
and
`def prepare_installer_for_cpp_flags`
to `utils-test.rb` since I wasn't sure how to handle the installer mock.
Reviewed By: cortinico
Differential Revision: D51708382
Pulled By: cipolleschi
fbshipit-source-id: ff206f8fc151934dbae89aacd1bc69c57b4f28ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41720
We currently go via the UI thread, so we can use AsyncTask to schedule the final bit of async ReactContext destruction. This is a requirement for the AsyncTask API, which is also deprecated. We should figure out a better way to schedule and re-use threads across React Native Android, but until then, we can just create a new Thread here, which is also what we do for instance creation.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D51706689
fbshipit-source-id: cf17e20e91b195b956b1701e6d91d563fdba4d15
Summary:
This PR fixes typo in CircleCI config
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [FIXED] - Typo in circleci config
Pull Request resolved: https://github.com/facebook/react-native/pull/41727
Test Plan: CI Green
Reviewed By: cipolleschi
Differential Revision: D51748329
Pulled By: cortinico
fbshipit-source-id: 99f54c5b9ec4113205642076c010b748ab6229f6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41728
Adding APIs for `getFabricUIManager()` to ReactContext and it's subclasses. This will replace the `getJSIModule()` post JSI module deletion.
Reviewed By: philIip
Differential Revision: D51718430
fbshipit-source-id: c897ab0ee9e755e3fdb3d1e5629177818870f293
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41732
Was reading the code in this file and noticed that this comment is no longer true after D51068417 (https://github.com/facebook/yoga/pull/1460). Updated the comment to reflect the current state of things
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D51730986
fbshipit-source-id: beaa5de9576d86e56def35f6e970376c7be8f7ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41712
I fixed the const correctness of YGConfigGetErrata a while back when fixing up other YGConfig accessors.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D51689323
fbshipit-source-id: 1af3deb44ec03a8a65643fa1496c534ac8f6d057
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41436
Add a JSI API for associating some native memory with a JS object. This
is intended to provide a mechanism to trigger more frequent garbage
collection when JS retains large external memory allocations, in order
to avoid memory buildup.
This diff just adds the JSI method, without any implementations.
Changelog:
[General][Added] - Added JSI method for reporting native memory to the GC.
Reviewed By: tmikov
Differential Revision: D50524912
fbshipit-source-id: c8df0e18b0415d9523e0a00f6d0ed2faa648ac68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41719
We leak ReactInstanceManager into a static singleton in `ReactCxxErrorHandler.setHandleErrorFunc`. Clean it up in `destroy()`.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D51706624
fbshipit-source-id: 642825ba14ff0a9710b4435f5fb6026b3a81b711
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41704
`mOnViewAttachItems` was set to be be concurrent, but this would be unexpected, as all mount item operations occur solely on the main thread.
Simplify this to be just a LinkedList and annotate the methods as being UI thread only.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D51662154
fbshipit-source-id: 9fe5784bce8a38d1339b5e3675791414676b6f4d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41711
We want the default position to be relative for a number of reasons. This should be fine for the most part but putting a killswitch around this change just in case things blow up.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D51643446
fbshipit-source-id: 4f7d1e498eb663801ef6d88ba9cd9b64c781d66b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41709
We shipped these new create()/reload()/destroy() methods to the Facebook app:
- Part 1: D50802718
- Part 2: D50803283
This diff just enables them everywhere, by default.
Created from CodeHub with https://fburl.com/edit-in-codehub
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D51590843
fbshipit-source-id: 02abeea78b7b7b844552989ad58d0a2f048424ad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41700
The type definition of `useMergeRefs` is incorrect, which forces all callsites to use `$FlowFixMe`. This fixes the definition and removes all the `$FlowFixMe`s caused by it.
Changelog: [internal]
Reviewed By: javache
Differential Revision: D51660716
fbshipit-source-id: 4d4d3a72bdca8c409fd1dda59cc2c94113b024bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41701
I did a hotfix for this logic in D51618512. This does a small refactor to improve the code (moving more shared code to the hook and avoiding creating a closure unnecessarily in every call to it).
Changelog: [internal]
Reviewed By: javache
Differential Revision: D51660288
fbshipit-source-id: 472836840b19958402bd0de3e2c09c7cec004156
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41695
When I went to update documentation, I kinda internalized how inconsistent the API is if we don't change iOS Paper.
The potential for breaks is if an iOS-specific component ignores a warning, and uses `onScroll` without `scrollEventThrottle`, then relies on `onScroll` only being called once.
It didn't seem like we hit this scenario in practice when migrating Fabric ComponentView behavior, and components will need to support it in new arch anyway, so this change takes the less conservative option of unifying the behavior everywhere.
Changelog:
[iOS][Changed] - scrollEventThrottle no longer needs to be set for continuous scroll events
Reviewed By: cipolleschi
Differential Revision: D51647202
fbshipit-source-id: e2a57f3501b9096e4033cb198bbc214d53e9913c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41681
## Rationale
Make initHybrid static. So that the derived class can initialize the C++ part with constructor arguments.
**Note:** This diff just applies the fix from D51550623. into CxxReactPackage.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D51642219
fbshipit-source-id: 095e452e03848379288af960969789aa5e9c0542
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41708
RN-Tester is currently instacrashing due to a method accepting a `Float?` rather than a `Float`.
`Float` from Kotlin gets converted to Java's `float`, while `Float?` gets converted to the boxed type, which is not recognized by the framework and is making the app crash.
On top of this, the implementation of `setColor` was wrong as we don't properly handle the null case. Fixing it here as well.
Changelog:
[Internal] [Changed] - Fix broken RN Tester custom ViewManager
Reviewed By: NickGerleman
Differential Revision: D51667346
fbshipit-source-id: b7498a520936f81a0524ba53dc7230ad7ef57bf8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41706
This change introduces a ReadME in the CircleCI folder.
This can be used as documentation to learn more about our CircleCI setup and will also help GitHub employees in executing the migration.
## Changelog:
[Internal] - Add CircleCI documentation
Reviewed By: cortinico
Differential Revision: D51665453
fbshipit-source-id: f61325ed26572c4a8d4a68db1cca5934d3d968fb
Summary:
Currently, when we have an additional platform in `react-native.config.js`, users cannot use custom `resolver.resolveRequest` functions as they are overwritten by `reactNativePlatformResolver`. Goal of this PR is to allow OOT platforms to use additional custom resolvers besides remapping react native imports.
## Changelog:
[GENERAL] [FIXED] - Allow Out Of Tree platforms to pass custom resolvers
Pull Request resolved: https://github.com/facebook/react-native/pull/41697
Test Plan:
1. Add additional platform in `react-native.config.js`
2. Pass custom resolver to `metro.config.js`:
```js
resolveRequest: (context, moduleName, platform) => {
console.log('resolveRequest', moduleName, platform);
return context.resolveRequest(context, moduleName, platform);
}
```
3. Check if user's `resolveRequest` function is called.
Reviewed By: huntie
Differential Revision: D51659721
Pulled By: robhogan
fbshipit-source-id: 952589b59a6fa34e9406d36c900be53a7c1a79c3
Summary:
This is my proposed solution to https://github.com/facebook/react-native/issues/41677.
Fixes https://github.com/facebook/react-native/issues/41677.
## Changelog:
[ANDROID] [FIXED] - Fix android root view group removal during instance re-creation
Pull Request resolved: https://github.com/facebook/react-native/pull/41678
Test Plan:
Both with fabric enabled and disabled (new architecture):
1. Clone repro repo: https://github.com/wschurman/rn-reload-repro
2. Build and run on android (I use android studio)
3. Click reload button, see timestamp doesn't change (indicating that the view is not removed)
4. Apply this PR as a patch.
5. Re-build and run.
6. Click reload button, see view is correctly disposed of and the new view is set.
Reviewed By: cortinico
Differential Revision: D51658524
Pulled By: javache
fbshipit-source-id: d9a026cde677ad1ec113230bc31bd9297bca8bfc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41698
With the previous changes on the Pod configuration, the build setup for the New and Old architecture are the same.
The only observable difference happens at runtime.
This change:
1. Removes the build job that are split by architecture (which is now duplicated work)
2. Add two more test jobs to run runtime tests (unit and integration test) to make sure that the two architectures continue working.
## Changelog:
[Internal] - [CI] Remove duplicated build jobs, add tests jobs
Reviewed By: cortinico
Differential Revision: D51659275
fbshipit-source-id: 769c9ee004e7f4f1a7444f39c02b7083e007b780
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41669
In some previous changes ([a607692](https://github.com/facebook/react-native/commit/a6076924bf43dff6cf4d38d51df279edba3882d0) and [6b53205](https://github.com/facebook/react-native/commit/6b5320540adfe16803ef41353f23115d08819309)) we make sure to always include all the pods (including Fabric) and we unify codegen to run in the same way on both architectures.
While doing so, we enabled codegen to run on libraries tat already migrated to Fabric.
These makes those libraries to fail when building as they were not including the Fabric code when the New Architecture is disabled.
This change will make sue that the code is always included, thus the library should always build, and it also make sure that we can control the New/Old Architecture at build time.
## Changelog
[iOS][Changed] - Make sure that libraries always include Fabric code also in the old architecture
Reviewed By: dmytrorykun
Differential Revision: D51617542
fbshipit-source-id: 883d1e258c341feb0405ad389bb8af34d64b59b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41496
Refactoring `DefaultReactNativeHost` to use the new way of Fabric initialization through `FabricUIManagerProviderImpl`
Reviewed By: christophpurrer
Differential Revision: D51224854
fbshipit-source-id: 2af8021404365fa2adc9388f44bcc7c6301137dc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41676
This has been used in a significant amount of production for about 2 months, with no consistently statistically significant metric impact. Let's ship it.
Note that we would not want to keep this change in a holdout if we remove the warning, since new usages could be added that relied on the behavior not in the holdout.
It didn't seem worth the churn to make the same change to Paper, which leaves a question on how to handle the JS-side warning. Instead of jimmying in impl detection, I thought it might be more sane to remove the warning, though that also has a potential hit to Paper DevX.
Changelog:
[iOS][Changed] - `scrollEventThrottle` no longer needs to be set for continuous scroll events when using the new architecture.
Reviewed By: javache
Differential Revision: D51608970
fbshipit-source-id: 193019de208f3088519e6f6333dbec4e6b45a1eb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41693
This diff fixes app warm start time. Before this change, we cache the first time when app start timing is logged, and ignore future loggings. Some apps are warm started and the startup time should be updated.
Reviewed By: dmitry-voronkevich
Differential Revision: D50481710
fbshipit-source-id: 03e00b75ee7ac578209ae3478adabe567e92a950
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41480
X-link: https://github.com/facebook/yoga/pull/1469
The previous version of static didn't do anything inside of Yoga. Now that we're making it do something, this changes the default back to relative so that users with no errata set don't see their deafult styles changing.
Reviewed By: joevilches
Differential Revision: D51182955
fbshipit-source-id: c0ea357694e1367fb6786f1907dfff784b19a4bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41481
This will allow us to keep RN on it's "pseudo-static" mode, while changing the Yoga default back to relative, to avoid breaking existing layouts.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D51182861
fbshipit-source-id: 25489d7f0642c4ff78340438c2b266e95a5fb207
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41506
Adding APIs for `getFabricUIManager()` to ReactContext and it's subclasses. This will replace the `getJSIModule()` post JSI module deletion.
Thereby replacing the callsite to context.getFabricUIManager() in UIManagerHelper.
NOTE: This still has fallback to getJSIModule() in case the UIManagerProvider is not set
Changelog:
[Internal] internal
Reviewed By: philIip
Differential Revision: D50926218
fbshipit-source-id: f311affb0f82895b254fd4664aa8ea23ab31bac0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41575
We currently do not validate the incoming native exception message
before passing it to the char* constructor of TwineChar16.
Treat it as UTF-8 and convert it to UTF-16 before creating the
JavaScript exception.
Changelog: [Internal]
Reviewed By: tmikov
Differential Revision: D49551640
fbshipit-source-id: 762f8038b29818d804bda5a7f3b4762621c94336
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41680
Just like how React Native can have n ReactPackages, it will support n CxxReactPackages.
This way, many applications can share common CxxReactPackages.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D51484844
fbshipit-source-id: b9b70cab719e80a7ff7e635057d710f1a86fb1c9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41679
This fixes a bug in the original implementation of image attached callbacks (still experimental). The problem was that we were unconditionally caching the ref passed to the underlying image component, which meant that whenever users passed new ref setters we wouldn't call them again.
This fixes that by forcing the creation of a new ref value whenever a new ref is passed to the image component.
Changelog: [internal]
Reviewed By: jehartzog
Differential Revision: D51618512
fbshipit-source-id: ac15160c528563c2131e8b3444dea4a6096f20bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41673
## The Problem
The cxxReactPackage property isn't initialized by the time initHybrid was executed. So, initHybrid was being called with null as the cxxReactPackage.
Why;
1. The default turbomodule manager delegate receives cxxReactPackage as a constructor param.
2. Java then executes all the constructors of the class hierarchy. This executes initHybrid.
3. Java finally initializes the properties of the derived class: default tmmd.cxxReactPackage (i.e: the parameter to initHybrid). **This is too late**
## The Fix
Refactor the code such that hybrid data creation doesn't depend on property initialization:
1. Create a static initHybrid method in default tmmd.
2. Call this static method with the cxxReactPackage, and assign the resultant HybridData to mHybridData (in tmmd).
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D51550623
fbshipit-source-id: ed2b7587351cfca408cda3c8cef4dcf7547e5f1e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41674
The problem: The Java runtime couldn't find CatalystCxxReactPackage.initHybrid.
Why: I think is because CxxReactPackage loads CatalystCxxReactPackage's so in its constructor. This might be too late to load the derived class's so.
So, I just switched derived delegates to load the so in the static initializer (i.e: the recomended approch for so loading):
https://www.internalfb.com/code/fbsource/[91c4e41c49ed191ac864250ccaec52c01ddaeccc]/fbandroid/libraries/soloader/java/com/facebook/soloader/SoLoader.java?lines=52-54%2C60-61%2C63-67
This way:
1. The So's are loaded plenty early (the method not found error went away).
2. We don't create our own so loading infra, which complicates this abstraction, and makes it harder to work with, even more.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D51550622
fbshipit-source-id: f4782d6fa9387f21fbf611191e9483e2a58b3a34
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41675
FBJni expects the HybridData object to exist on the mHybridData property of the java object. So, we have to call this propery mHybridData.
Otherwise, this fbjni class just won't work.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D51550621
fbshipit-source-id: d169266474717f0a38799ede7c07af57461012b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41667
changelog: [internal]
I made a mistake during refactor in D51471667 where I removed the check if rawProps is nullptr. We must check if props are empty during `UIManager::clone`, leaving the check for `ConcreteComponentDescriptor::cloneProps` does not lead to the same result.
There is a deeper problem here that needs to be analysed but this should resolve the lunch blocker.
Reviewed By: javache
Differential Revision: D51614396
fbshipit-source-id: 055694c4a71a914d8732a3632c50026cc24cbe7d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41660
While working on other things, I noticed those warnings firing on console which I'm fixing here.
Changelog:
[Internal] [Changed] - Fix several build warnings on RN Tester Android
Reviewed By: cipolleschi
Differential Revision: D51589072
fbshipit-source-id: 1ddb29afd0d150f1ccbc7a8def9f27ecedb69724
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41661
This aligns the Kotlin version used inside fbsource to the one used for React Native GitHub
Changelog:
[Internal] [Changed] - Kotlin to 1.8.22
Reviewed By: NickGerleman
Differential Revision: D51587726
fbshipit-source-id: 5f985bd50c7688e4d369184b79dbf1bdc799876e
Summary:
While working in an app I kept getting these `View X of type Y has a shadow set but cannot calculate shadow efficiently. Consider setting a background color to fix this` warnings even though I had added a background color to that view. Upon inspecting RCTView.m I notice that what is actually required to fix this is a solid background
To make this a bit clearer to developers I believe we should update this log message to explicitly say "solid background" instead of "background"
## Changelog:
[IOS] [CHANGED] - Update 'cannot calculate shadow efficiently' log message to explicitly say solid background
Pull Request resolved: https://github.com/facebook/react-native/pull/39700
Test Plan: N / A
Reviewed By: christophpurrer
Differential Revision: D51584574
Pulled By: javache
fbshipit-source-id: b1741f7002ebb876e4a50959bef7f39df76a5c3c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41394
X-link: https://github.com/facebook/yoga/pull/1463
Now that are enums are unsigned, and we don't have BitfieldRef, we can convert the last remaining user of NumericBitfield to a plain old bitfield, for better readability (e.g. the default values), debugability, and less complexity. We also break a cycle which lets us properly group public vs private members.
Reviewed By: joevilches
Differential Revision: D51159415
fbshipit-source-id: 7842a8330eed6061b863de3f175c761dcf4aa2be
Summary:
This PR removes duplicated `pod 'Yoga'` as it is already declared in `use_react_native`.
## Changelog:
[INTERNAL] [REMOVED] - duplicated pod 'Yoga' in RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/41627
Test Plan: CI Green
Reviewed By: christophpurrer
Differential Revision: D51603340
Pulled By: NickGerleman
fbshipit-source-id: 89e77e5a544cb54d77b969462130725853b36d5d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41658
changelog: [internal]
FabricEventDispatcher does not need to run on every frame. Whenever a new event is added to Fabric's event queue, it will call `FabricUIManager.onRequestEventBeat` in Java. This in turn calls `FabricEventDispatcher.maybePostFrameCallbackFromNonUI` and adds a frame callback on the Choreographer.
This makes code simpler, as we do not need to manage the frame callback subscription.
Reviewed By: sammy-SC
Differential Revision: D50604303
fbshipit-source-id: ce2c7b77678bfc14aa7ecac71e40f78263c7036a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41625
To tell React Native whether we are building with hermes or not on iOS, we were using 2 different build time flags:
- USE_HERMES
- RCT_USE_HERMES
The first was widely used by the OSS use case, while the latter was set internally.
Worse than that, their default values were the opposite and we were never setting the RCT_USE_HERMES explicitly with Cocoapods, while there was some piece of code that was trying to "smartly" detect whether Hermes was included or not.
This change unifies the behavior, removing the "smartness" in favor od a declarative approach.
## Changelog:
[Internal] - Unify the USE_HERMES flags
Reviewed By: christophpurrer
Differential Revision: D51549284
fbshipit-source-id: 829ad361e185d5b4fa227605523af3a8e590e95c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41626
In the codebase, we never set the RCT_USE_HERMES flag.
When we install the pods, we use the USE_HERMES flag and we set USE_HERMES as a build setting. So, the RCT_USE_HERMES flag will always be not set for the OSS.
https://pxl.cl/3RRxr
## Changelog:
[iOS][Fixed] - use the right USE_HERMES flag
## Facebook:
This change was incorrect as in OSS we never set the RCT_USE_HERMES flag, while we actually set the USE_HERMES one.
I will align the BUCK RNTester setup in the next diff of the stackog:
Reviewed By: dmytrorykun
Differential Revision: D51547810
fbshipit-source-id: 1da5b3a48a83a8ba49cf65382927bed2f9fc893d
Summary:
changelog: [internal]
From sammy-SC, we would like to minimize the number of times that React Native schedules Choreographer calls. For animations, we do not need choreographer running on every frame, it only needs to run on frames that have an animation active. This diff modifies the frame callbacks such that Choreographer calls are only enqueued if there is an ongoing animation.
Reviewed By: sammy-SC
Differential Revision: D50647971
fbshipit-source-id: d77b246beafc5c658c738e574b0e02dd68fadce9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41560
This diff gives some functions and variables more accurate names:
1. `appRoot` -> `projectRoot`
2. `handleThirdPartyLibraries` -> `findExternalLibraries`
3. `handleLibrariesFromReactNativeConfig` -> `findLibrariesFromReactNativeConfig`
4. `handleInAppLibraries` -> `findProjectRootLibraries`
It also removes `isAppRootValid` check that checks that `appRoot != null`, it is redundant since `appRoot`(now `projectRoot`) is required by the CLI.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D51309027
fbshipit-source-id: c5e34c2aa788a7795c68697a0fa9ddf0163cec0e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41558
Now that the previous diff in the stack (D51303793) provides proper dependency path resolution, we can process `react-native` as a normal dependency, and remove a special code path for it.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D51256764
fbshipit-source-id: 2a11641e9362d7bfad1ff9995b4f3bb4c92d9c0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41654
This diff removes support for defining external codegen targets in `react-native.config.js` for iOS. Now you can simply add your external dependency to the project's `package.json` and it will be resolved as a normal Node packages.
## Motivation
The need for defining external codegen targets in `react-native.config.js` historically appeared due to limitations of how codegen searched for external dependencies. Basically we performed search only in the project directory. External dependency paths had to be listed in `react-native.config.js`.
After D51303793 has landed we don't need this any longer. We can simply rely on Node resolution to find those external dependencies.
Changelog: [iOS][Breaking] - Defining external codegen targets in `react-native.config.js` is not supported anymore. Define them as normal dependencies in `package.json`.
Reviewed By: cipolleschi
Differential Revision: D51308595
fbshipit-source-id: 97841a3a8c295aa717c577bb188d48373b04ba38
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41645
Right now, when defining concrete structs and Bridging headers for Cxx TMs we need to define their member types twice:
```
using ConstantsStruct =
NativeCxxModuleExampleCxxBaseConstantsStruct<bool, int32_t, std::string>;
template <>
struct Bridging<ConstantsStruct>
: NativeCxxModuleExampleCxxBaseConstantsStructBridging<
bool,
int32_t,
std::string> {};
```
Now we only need to define those once
```
using ConstantsStruct =
NativeCxxModuleExampleCxxConstantsStruct<bool, int32_t, std::string>;
template <>
struct Bridging<ConstantsStruct>
: NativeCxxModuleExampleCxxConstantsStructBridging<ConstantsStruct> {};
```
This change keeps the existing base types untouched - but they will be removed in the next RN version.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D51571453
fbshipit-source-id: 2783bd48bf786ffa80d322d06456b5d6f2d7ba8a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41391
X-link: https://github.com/facebook/yoga/pull/1461
Converts usages of `YGEdge` within internal APIs to `yoga::Edge` scoped enum.
With the exception of YGUnit which is in its own state of transition, this is the last public yoga enum to need to be moved to scoped enum form for usages internal to the Yoga public API.
Changelog: [internal]
Reviewed By: rshest
Differential Revision: D51152779
fbshipit-source-id: 06554f67bfd7709cbc24fdd9a5474e897e9e95d8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41390
X-link: https://github.com/facebook/yoga/pull/1460
Yoga passes `MeasureMode`/`YGMeasureMode` to express constraints in how a box should be measured, given definite or indefinite available space.
This is modeled after Android [MeasureSpec](https://developer.android.com/reference/android/view/View.MeasureSpec), with a table above `calculateLayoutImpl()` explaining the CSS terms they map to. This can be confusing when flipping between the spec, and code.
This switches internal usages to the CSS terms, but leaves around `YGMeasureMode` since it is the public API passed to measure functions.
Reviewed By: joevilches
Differential Revision: D51068417
fbshipit-source-id: 0a76266a4e7e0cc39996164607229c3c41de2818
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41392
X-link: https://github.com/facebook/yoga/pull/1458
We're moving `CompactValue` to be an internal detail of `yoga::Style`, where users outside of the style will be dealing with a resolved/non-compact representation.
This change renames usages of `CompactValue` to `Style::Length`, which will be Yoga's representation for CSS input lengths. Right now one is just a type alias of the other, but this will let us change the internals of CompactValue with the rest of the world looking the same.
A few factory functions are added to `yoga::value` for creating CSS values. There are some shenanigans around how we want to represent CSS pixels (one YGUnitPoint), when we also end up adding CSS points (slightly larger than one YGUnitPoint). For now, I reused `point` until making other changes.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D51000389
fbshipit-source-id: 00f55e72bfb8aa291b53308f8a62ac8797be490f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41640
react-native-svg reported that the SVG library was not building on the latest RC of React Native because Codegen was not finding the proper files.
By inspecting an example app with SVG, we realized that React-Codegen was not depending on `React-FabricImage`, while having access to their headers.
We added the dependency, but them the build was failing due to a circular dependency because the `React-ImageManager` was dependeing on `React-RCTImage`.
This dependency is conceptually wrong (a piece of Core should not depend on Library which depends on Core... 😑) and I verified that by removing that dependency the framework continue to build.
## Changelog:
[Internal] - Fixed dependencies of Codegen on React-Image
Reviewed By: cortinico
Differential Revision: D51564037
fbshipit-source-id: 8e7108b83f878be1063df5562311d862d4998121
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41643
Code in `AndroidTextInputComponentDescriptor` will rewrite Yoga props for padding based on Android theme, if a value isn't supplied. It determines this by adding props in `AndroidTextInputProps` which reads Yoga RawProps to tell if they were set.
RawProps are keyed using separate prefix/name/suffix, instead of the combined string name of the prop. This means that searching for the name `paddingLeft`, would be different from reading one with a name of `padding` and a suffix of `Left`.
This updates the keying, based on the changes in D51510562.
We should refactor this in the future (D20109605, introducing this code, admitted as much). We already have a phase, for aliased props, where we transform input props into the Yoga style (they don't need to be 1:1). This doesn't depend on RawProps, extra props, or prop mutations.
Changelog:
[Android][Fixed] - Fix AndroidTextInputProps Detection of Padding
Reviewed By: GijsWeterings
Differential Revision: D51566900
fbshipit-source-id: ca744b23d71382941903da42d86ad3eef7b65de8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41549
Changelog: [Internal]
Introduces the `JSRuntime` interface as a straightforward wrapper around `jsi::Runtime`, and refactors `ReactInstance` to hold a `JSRuntime` instead of a `jsi::Runtime`. In an upcoming diff we'll add debugging-related methods to `JSRuntime` and specialise their implementations for Hermes.
NOTE: `JSRuntime` is somewhat analogous to `JSExecutor` in the Bridge architecture.
Reviewed By: huntie
Differential Revision: D51447934
fbshipit-source-id: cfcab9ae0dd3d2a34c064abaac6cb676f435e216
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41642
This allows opening an example within RNTester without tapping the module card. If the app receives an openURL request with the format `rntester://example/<key>`, open that example (if exists) directly. Such URL request may come from various sources (e.g. custom test run, etc).
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D51543385
fbshipit-source-id: f9a01963cefb4602b629da0b01be6e334c28a912
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41623
`static` fields require additional code to ensure the field is only ever initialized once. We already have a static "default props" field in the shadow node, so let's reuse that as much as possible.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D51547638
fbshipit-source-id: e4957ffb0f9352847b8cd8dc3a010dcfac8be699
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41628
# Changelog:
Even though `onClick` is used on Android (e.g. via Pressability), the fact of having the handler registered didn't get through to the C++ side on New Architecture, because of being filtered out via the corresponding static view config.
As the result, there was no way to know on C++ side whether the corresponding event handler is registered for the view or not. Dynamic updates to the prop also wouldn't correctly propagate to C++, which may be a problem if a view gets e.g. the handler dynamically added.
Reviewed By: javache
Differential Revision: D51551255
fbshipit-source-id: 0783f5a27c7250f83fb357173bbe5be6213277e5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41613
Changelog: [Internal]
We were keeping ref in the AppContainer's state before migrating these components to functions.
We actually need a real ref here, so we can use `useImperativeHandle` on it later. These refs will be passed as an argument for DebuggingRegistry subscription, whichi will call them on all necessary AppContainers to highlight required components.
Reviewed By: javache
Differential Revision: D51536772
fbshipit-source-id: d49035874ce3c9b1acf08d5ab666886f68e6f40e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41562
Changelog: [Internal]
We will use this native component as a single layer for drawing debugging information: both for trace updates and inspected components from React DevTools.
Reviewed By: javache
Differential Revision: D51470789
fbshipit-source-id: 6c4633d2b70c2c2635a2bbfcd7adf1c727b73585
Summary:
Several deprecation warning messages related to components that were removed from `react-native` were outdated.
Some repositories have been moved, some packages were renamed/re-published under new names. A couple **never existed** (`react-native-community/segmented-checkbox` and `react-native-community/react-native-image-picker`).
This updates all messages to include links to the latest repositories and references to npm packages.
Because `react-native-community/art` is deprecated I've also slightly amended the message with the suggestion from its [repo readme](https://github.com/react-native-art/art#deprecated---this-package-is-deprecated-if-you-need-a-similar-package-please-consider-using-react-native-svg).
## Changelog:
[GENERAL] [FIXED] - Update pkg/repo names in deprecation messages
Pull Request resolved: https://github.com/facebook/react-native/pull/41618
Test Plan: No code change, just documentation/text.
Reviewed By: cipolleschi
Differential Revision: D51546345
Pulled By: cortinico
fbshipit-source-id: 5d7176a70d94c8b1e8111f4d84fba89eacde456a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41621
Currently, if you have a dependency that is alphabetically smaller than `app`, it's evaluation will happen before `app`.
This means that the namespace auto-discovery and the JVM toolchain configuration won't be working and the project will fail to buid.
This fixes it by introducing a root-project Gradle Plugin that takes care of enforcing the evaluation order on the `app` project.
Fixes#41620
Changelog:
[Android] [Fixed] - Fix projects being broken on dependencies starting with `a..`
Reviewed By: huntie
Differential Revision: D51547294
fbshipit-source-id: 65df7149548b7087dd8928e556fb803b3baf7b79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41557
The `configFileDir` CLI argument is used to help to find paths to the 3rd party dependencies of the app. Since we only care about dependencies listed in the root `package.json`, we can use `node` resolution instead of having to construct paths manually. In that case `configFileDir` becomes redundant.
Changelog: [iOS][Breaking] - Delete configFileDir CLI argument.
Reviewed By: cipolleschi
Differential Revision: D51303793
fbshipit-source-id: 46cb61197ddf51515af634c8fc6b85a8d218c51e
Summary:
This PR addresses the problem raised in the https://github.com/facebook/react-native/issues/41004 issue.
The current logic is that `selectionColor` on iOS sets the color of the selection, handles, and cursor. On Android it looks similar, while it doesn't change the color of the handles if the API level is higher than 27. In addition, on Android there was an option to set the color of the cursor by `cursorColor` prop, but it didn't work if the `selectionCursor` was set.
## 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] [ADDED] - Make same behavior of the `selectionColor` prop on Android as iOS
[ANDROID] [ADDED] - Introduced `selectionHandleColor` as a separate prop
[ANDROID] [CHANGED] - Allowing `cursorColor` and `selectionHandleColor` to override `selectionColor` on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/41092
Test Plan:
Manual tests in rn-tester:
### `selectionColor` same as iOS, sets selection, handles and cursor color
_There is a way to set only "rectangle" color by setting other props as null_

### `selectionHandleColor`

### `cursorColor`

Reviewed By: NickGerleman
Differential Revision: D51253298
Pulled By: javache
fbshipit-source-id: 290284aa38c6ba0aa6998b937258788ce6376431
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41609
Aggregate edges will no longer be exposed. Inline debugStringConvertibleItem string printing for it.
Previously included in D50998164
Changelog:
[Internal]
Reviewed By: joevilches
Differential Revision: D51510790
fbshipit-source-id: aaabaa4fdd899bd9c602b9a5ab5dd35265c7269b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41611
Aggregate edges will no longer be exposed. Inline the convertRawProp parsing functions for it.
This is a little bit more code, but subjectively easier to reason about.
Previously included in D50998164
Changelog:
[Internal]
Reviewed By: joevilches
Differential Revision: D51510562
fbshipit-source-id: 30440e19422a3a3fb49a754b5ecd8279ce1521a2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41612
We never use the position edges for Yoga style. We should not keep extra props, and instead just parse directly into the Yoga style.
Previously included in D50998164
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D51508217
fbshipit-source-id: ff28cf7168446068b10901fbba258414b561f07f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41614
Fixes https://github.com/facebook/react-native/issues/41545
SafeAreaView works by adding padding in order to shift content out of the safe area. This may change the layout dimensions of the SafeAreaView, in turn effecting its safe area insets.
This can cause layout results to change, which in turn changes the inset value. Because of this, there is a tolerance, where safe area inset changes do not trigger a new update.
Yoga is instructed to round layout dimensions to the closest physical pixel, so a very small difference in layout may result being off by about a pixel. Right now the tolerance is exactly one physical pixel, and if there is FP error here, we may not pass the test, and start oscillating with different layout values.
After changing affected ShadowNode order to always be root-first, the first call to set the frame of the `SafeAreaView` happens when a non-zero-sized RootView is present, which I think may lead to a safe area inset update communicated that wasn't before? Or other cosmic butterflies. Layout rounds to one physical pixel in difference, and our tolerance is `0.00001` dips off (not helped that 1/3 screen scale cannot be represented as decimal, even without FP error).
This adds a small tolerance beyond just the pixel boundary, matching the logic in Fabric, which seems to resolve the issue.
Changelog:
[iOS][Fixed] - FP Tolerance in iOS Paper SafeAreaView debouncing
Reviewed By: philIip
Differential Revision: D51539091
fbshipit-source-id: 88bddc38c7cd8d93feef5f12da64b124af22f46d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41599
Changelog: [iOS][Breaking]
this is not used in our framework, delete. feel free to fork this implementation if you are using it or interested in using it
Reviewed By: cipolleschi
Differential Revision: D51516680
fbshipit-source-id: 4ca23a5b78bf18a84ea0ab4fe16419db7aea03d9
Summary:
Adding `initialize()` to FabricUIManager just as was done by JSIModule
Without this change switching to UIManagerProvider would cause the UI to be Frozen and the events not correctly registered.
Pull Request resolved: https://github.com/facebook/react-native/pull/41594
Reviewed By: javache
Differential Revision: D51456979
fbshipit-source-id: 8d97533340a88ec6bb2bf0f257b6acfaa59da471
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41466
## Context
In open source, all apps use the same turbomodulemanager delegate (i.e: the default delegate).
This diff introduces the buck infra that makes the oss default delegate work for meta apps.
Concretely, we are going to make React Native use the same delegate for **all** Meta apps.
Each Meta app will:
1. At build time, generate a unique TMProvider map
2. At app init time, initialize the default delegate with the TMProvider map.
## Implementation
**Step #1:** At build time, generate a unique TMProvider map
**Insight:** Buck genrules can accept, as input, the output of a buck query.
So, here's how we get this done:
1. Buck query (i.e: input to Genrule): Given the app's deps, query all the schemas in the app.
2. Genrule: Read the schemas to generate the TMProvider map. The TMProvider map will also contain **all** the app's C++ module codegen.
Concretely:
1. This diff introduces a macro: rn_codegen_appmodules(deps).
2. rn_codegen_appmodules(deps) generates appmodules.so, which contains the TMProvider map.
**Step #2:** At app init time, initialize the default delegate with the TMProvider map.
This is how we'll initialize the DefaultTurboModuleManagerDelegate:
1. DefaultTurboModuleManagerDelegate will load appmodules.so during init.
2. When loaded, appmodules.so will assign the code-generated TMProvider map to DefaultTurboModuleManagerDelegate.
## Impact
This should allow us to:
1. Get one step closer to getting rid of the `js1 build turbomodule-manager-delegates --target <app>` script
3. Remove the TurboModuleManagerDelegate from React Native's public API. (Because we use one delegate for all React Native apps in Meta and OSS)
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D50988397
fbshipit-source-id: 0ca5dec14e2dae89ec97f5d39a182c7937c5c7bf
Summary:
Bitfield enums are not sequential, so use of these functions on these enums would be invalid.
I looked at whether we could trivially move `bitCount` to template based on `ordinalCount`. `bitCount` must be constexpr, since we use it directly as a bit-field size constant. `log2` and `ceil` to be constexpr, which isn't here until C++ 26.
Reviewed By: javache
Differential Revision: D51518899
fbshipit-source-id: 256f15bbed517be6f90bf43baa43ce96e9259a71
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41555
This diff splits `generateNativeCodegenFiles` into two simpler steps: `generateSchemaInfos` and `generateCode`. `SchemaInfo` is a (library, schema) pair, it is convenient for further transformations.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D51204077
fbshipit-source-id: 8a1f585a79a2a0241b544a8a131b59250d803e2e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41554
This diff removes inefficiency where we first write schema to disk in `combine-js-to-schema.js`, and then read it from disk in `generate-specs-cli-executor.js`. With this change we can just pass it as an argument.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D51161162
fbshipit-source-id: 35d14ca3e53e4bf999520c635c66909c20081096
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41534
This diff deletes calls to `node` from `generate-artifacts-executor.js`, and replaces them with normal `requires` of JS sources.
This is a squashed version of (D51116291 ... D51158799).
The following sequence of changes has been made:
1. Require and directly invoke `generate-specs-cli-executor` instead of using `node`.
2. Use `codegen-util` to get `RNCodegen` in `generate-provider-cli.js`.
3. Use `RNCodegen` directly instead of using `node`.
4. Move all implementation code from `combine-js-to-schema-cli.js` to `combine-js-to-schema.js`.
5. Decouple building the codegen from getting the codegen CLI.
6. Use `combine-js-to-schema` directly instead of using `node`.
7. Delete unit test that was testing node invocation.
8. Delete `nodeBinary` argument form `generate-codegen-artifacts.js` and its callsites.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D51158845
fbshipit-source-id: 5e039801c8045a42349f7cb6ca28e2df24634589
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41603
changelog: [internal]
`ShadowNode::IdentityTrait` was already a thing. Let's make it available in ConcreteComponentDescriptor.
Reviewed By: rshest
Differential Revision: D51471666
fbshipit-source-id: 7919a9b7238d766ee3913a5ab239bf254fab0996
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41589
This is a cleanup diffs that removes some of the usages of RCT_NEW_ARCH_ENABLED.
Now that we are shipping all the pods, there is no need to conditionally compile-out part of the codebase depending on whether the new architecture is running or not.
This change will not alter the behavior of the app.
## Changelog:
[iOS][Breaking] - Remove some usages of RCT_NEW_ARCH_ENABLED. The change should be transparent BUT some **Swift** libraries might get broken by this change.
Reviewed By: dmytrorykun
Differential Revision: D51498730
fbshipit-source-id: c83416480eea1f7bbc55f72c31e7b69ad0e9e01a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41588
This change always installs all the Pods for both architecture.
This unify the behavior between iOS and Android.
## Changelog:
[Internal] - Always install all the pods
## Facebook:
The inly four pods that are changed when flipping between the new and the old arch with RNTester are:
- MyNativeView
- NativeCxxModuleExample
- React-RCTAppDelegate
- ScreenshotManager
The only change there is the RCt_NEW_ARCH_ENABLED flag being set or not in those pods
Reviewed By: dmytrorykun
Differential Revision: D51494498
fbshipit-source-id: 4cafdef4a4c2b86381067373aed27ed18524e4be
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41579
This change remove a flag that is unused.
## Changelog
[Internal] - Remove unused Flag
Reviewed By: dmytrorykun
Differential Revision: D51493765
fbshipit-source-id: f8cbce991d80d4f51363cdd4f379e6b214b2b2df
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41561
The RN_FABRIC_ENABLED has been deprecated and superseded by the RCT_NEW_ARCH_ENABLED for a while now.
This change removes it, from the codebase as now we always have the Fabric pod available to the codebase.
## Changelog
[Internal] - Remove RN_FABRIC_ENABLED flag
Reviewed By: dmytrorykun
Differential Revision: D51468332
fbshipit-source-id: 6b2fc554e6bf5ac748b9e45d7c14f9ba9b57820c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41595
Instead of having to select between Enable/Hide the Element Inspector String, let's just use "Toggle".
Changelog:
[Internal] [Changed] - Update Element Inspector string to "Toggle"
Reviewed By: cipolleschi
Differential Revision: D51503403
fbshipit-source-id: 2ad24df8324eb789b0016fe7ac5d439cba6f5952
Summary:
This diff is reverting D51346658
D51346658: [RN][Android] Handle all incoming Inspector messages on main thread, downgrade some errors to logs by motiz88 has been identified to be causing the following test failure:
Tests affected:
- [xplat/endtoend/jest-e2e/apps/facebook_xplat/ReactNativeTTRCTester/__tests__/ReactNativeTTRCTester-storeOrNetworkWithoutCachedContent-android-e2e.js](https://www.internalfb.com/intern/test/281475019301167/)
Here's the Multisect link:
https://www.internalfb.com/multisect/3539088
Here are the tasks that are relevant to this breakage:
We're generating a revert to back out the changes in this diff, please note the backout may land if someone accepts it.
If you believe this diff has been generated in error you may Commandeer and Abandon it.
bypass-github-export-checks
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D51512872
fbshipit-source-id: 8bc8e12b651f91a6f74243a0a85fca7fd1953bdb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41598
This code merges native, Android provided theme text input padding, with Yoga style. We are removing operations on all edges as aggregate, so this replaces that.
This was previously part of D50998164
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D51503493
fbshipit-source-id: c6e2f3183a05861745fdd8f044d12e3dd8205804
Summary:
X-link: https://github.com/facebook/yoga/pull/1475
Pull Request resolved: https://github.com/facebook/react-native/pull/41568
Removes cases where we rely on comparing composite of Yoga edges, since we are removing that internal API (public API is already one at a time). Extracted from D50998164, with more sound facility for looping through edges.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D51478403
fbshipit-source-id: 162170b91345ff86db44a49a04a2345f0fbd0911
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41590
Causing a small leak while we wait for the surface to be fully destroyed.
Changelog: [Internal]
Reviewed By: fabriziocucci
Differential Revision: D51499256
fbshipit-source-id: 8f9e65898dcb9e0261502028874378ec9cc0f3fc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41582
# Changelog:
This will allow to have custom `ImageManager` implementations on new platforms.
Reviewed By: christophpurrer
Differential Revision: D51495143
fbshipit-source-id: bbd03bdad1b87fd53e70a886f1fdc74f371987c8
Summary:
Changelog: [Internal]
* Updates `InspectorPackagerConnection.java`, `DevServerHelper.java` and `DevSupportManagerBase.java` to perform all connection management and message dispatching for the inspector socket on the main thread. This is in support of a new CDP implementation in React Native that will strictly assume it's called on the main thread (thus avoiding the need for explicit locking in many places).
* Downgrades JSON parsing errors and duplicate connection errors from exceptions to logs, matching the [iOS implementation](https://github.com/facebook/react-native/blob/main/packages/react-native/React/Inspector/RCTInspectorPackagerConnection.m).
Reviewed By: javache
Differential Revision: D51346658
fbshipit-source-id: 3d0d5588a824c1b28da5499ef9d040998a941288
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41581
# Changelog:
There was nothing platform-specific in `ImageRequest` implementation, defined on iOS, so might as well share across platforms.
Reviewed By: christophpurrer
Differential Revision: D51495144
fbshipit-source-id: ef15c5c8c6b07c1a87ca83eb15b5997ba703fbcc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41567
Sometimes `createNode` calls into is throwing `std::out_of_range_error` or `std::length_error` in response to both vector and string operations.
Instead of propagating `std::logic_error`, which indicates a defect in native code, terminate, so we can get an actionable native stack trace.
`createNode` and `cloneNode` also both ocasionally see `bad_alloc`, but this is not usually an instance of a defect at the allocation-site, and throwing would be more graceful.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D51463600
fbshipit-source-id: 870cbf3538d8ccbc01ded2868781a63ba12a941c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41548
`JSEngineInstance` is a misnomer - this interface actually creates `jsi::Runtime`s and doesn't represent an "instance of a JS engine". This diff renames it to `JSRuntimeFactory`.
Changelog: [Internal]
Reviewed By: huntie, arushikesarwani94
Differential Revision: D51447882
fbshipit-source-id: e118fe5c202607500a62d8e15afec088c4946969
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41577
# Changelog:
[Internal]-
The change is equivalent in terms of API, however this makes it work nicer with C++ codegen and easier to use with a pure C++ implementation of the native module.
Reviewed By: GijsWeterings
Differential Revision: D51493466
fbshipit-source-id: bf9105670ae56a191ab2e6c8cfb794c2fecd4809
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41533
This diff removes `configFilename` and `configKey` arguments from iOS codegen CLI. Now we always expect them to be `package.json` and `codegenConfig` respectively.
## Motivation
The existing implementation expects every library to have its codegen config in a file with `configFilename` name. `configFilename` is passed as a single CLI argument and applied to every app dependency. I.e. if `configFilename = codegen.config.json` then we expect to find this file in *every* third-party library. That is weird expectation. This customisation option is unsound. Same with `configKey`. It is much simpler to just stick with convention that `configFilename = "package.json"` and `configKey = "codegenConfig"`.
Changelog: [General][Breaking] - Delete `configFilename` and `configKey` arguments from iOS codegen CLI. Now we always expect them to be `package.json` and `codegenConfig` respectively.
Reviewed By: cipolleschi
Differential Revision: D51256486
fbshipit-source-id: fe190b514be7c4e489c7be01294958cf3254602a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41531
This diff converts in-out `libraries` argument of codegen library lookup functions to a normal return value. This makes these functions simpler to reason about, and simplifies subsequent refactors.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D51111416
fbshipit-source-id: 12b5dda4d326e3f1c866c16f7bcd17080be54b58
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41503
Changelog: [Internal]
Updates RCTInspectorPackagerConnection to dispatch all messages on the main thread (which is SocketRocket's default behaviour). This is in support of a new CDP implementation in React Native that will strictly assume it's called on the main thread (thus avoiding the need for explicit locking in many places).
Reviewed By: javache
Differential Revision: D51346659
fbshipit-source-id: c529b0aea97f7732cea58a4dc66993c5c8259958
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41570
## Changelog:
[Internal] -
This fixes a subtle problem whereas an update to `Image.source` (or `Image.src`) prop on JS side may not end up getting propagated to the C++ side, with New Architecture.
As the result, this can lead to some weird corner cases, whereas e.g. layout doesn't update after the image's size changes.
Differential Revision: D51479305
fbshipit-source-id: 72afb7dfd0ba32f96af4f9a6564b3b8121a597c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41509
We currently ignore `IllegalArgumentException` being thrown from TurboModule getters, as it was deemed acceptable to use that to signal a Package didn't have that module. This however can mask legitimate errors thrown during a TurboModule constructor.
TurboReactPackage#getModule is already marked as allowing nullable returns, so let's leave the use of exceptions for exceptional scenarios.
Changelog: [Android][Changed] Use null to signal a missing TurboModule instead of IllegalArgumentException.
Reviewed By: RSNara
Differential Revision: D51395165
fbshipit-source-id: 1eea1db6c7e3313a36d24e7837b36a3d0fccc718
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41495
Fix ReactInstanceManager for adding the callsite of `getJSIModule()` as an alternate path to new way of Fabric initialization in order to make Catalyst and RN-Tester work with the changes for Fabric initialization
Reviewed By: javache
Differential Revision: D51338036
fbshipit-source-id: 49badac52f1032f1032a989b76dd422e3cf7582f
Summary:
This PR fixes a typo in `cli.js`.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [FIXED] - typo in react-native/cli.js
Pull Request resolved: https://github.com/facebook/react-native/pull/41523
Test Plan: Not needed
Reviewed By: christophpurrer
Differential Revision: D51452866
Pulled By: arushikesarwani94
fbshipit-source-id: 61f1da70621bfe1a159ec63da0014141b182c5ac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41464
Now, DefaultTurboModuleManagerDelegate can be created with a CxxReactPackage.
If it exists, DefaultTurobModuleManager will use the CxxReactPackage to create C++-only turbo modules.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D51166524
fbshipit-source-id: 2fdc404e79213d685c4f41b2a152b68226bb71b2
Summary:
CxxReactPackage is supposed to be the way apps register C++-only turbo modules with React Native.
Applications are meant to subclass this jni::HybridObject.
Since this is a jni::HybridObject, applications are meant to create this CxxReactPackage in java, and initialize it with java dependencies.
React Native will reach into its c++ part, and use it create C++-only turbo modules.
NOTE: This is a **temporary** abstraction meant to unblock the stable API effort of removing the turbomodulemanagerdelegate builder from ReactHostDelegate:
https://www.internalfb.com/code/fbsource/[e7efced3018f6178b7187a2358f3b76d40e2b43c]/xplat/js/react-native-github/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/runtime/ReactHostDelegate.kt?lines=50-51
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D51166523
fbshipit-source-id: 51a22411239fbba32f3a70cc363e59947c2782dc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41467
Make the DefaultTurboModuleManagerDelegate and the DefaultComponentRegistry load their own so's when they're created.
**Motivation:** We are going to use these two classes in Meta apps. And Meta apps will not invoke DefaultNewArchitectureEntryPoint.load.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D51036133
fbshipit-source-id: 5ebd4d3b85f435229c9b5950493310aa7fa36ba0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41544
## Change
Extend DefaultTurboModuleManagerDelegate's API so that it specify which modules should be eagerly initialized.
## Rationale
This information was originally stored on the module's ReactModuleInfo object.
But, we're running an experiment (i.e: lazy mode) that gets rid of the ReactModuleInfo object. See D51093697 for more details.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D51307434
fbshipit-source-id: 6d867436588de2f9b8dd084327e74bd51ed61a2d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41468
Currently ReactPackageTurboModuleManagerDelegate uses ReactModuleInfos to create turbo modules. We want to see if it's possible to remove ReactModuleInfo from React Native's public API.
Therefore, we are forking the implementation of each each method inside ReactPackageTurboModuleManagerDelegate:
- **lazy mode:** doesn't use ReactModuleInfo
- **control:** uses ReactModuleInfo
This optimization was previosuly implemented outside of ReactPackageTurboModuleManagerDelegate. But, to simplify things, we are just pulling it inside the ReactPackageTurboModuleManagerDelegate.
Changelog: [Internal]
Reviewed By: philIip, mdvacca
Differential Revision: D51093697
fbshipit-source-id: 6eb11020e0bf87eb704b35b990a0f14f157eea66
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41415
Changelog: [iOS][Deprecated]
an example of RCT_DEPRECATION in action. you will get a build time warning if `RCT_DEPRECATED_DECLARATIONS` is enabled.
Reviewed By: cipolleschi
Differential Revision: D51184572
fbshipit-source-id: a0bcb4c69e63620bbdf2e2a7afb25c649fcaa100
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41416
Changelog: [Internal]
cocoapods boilerplate to integrate the first RCTFoundation library. decided to split this up so we can reference it easily in the future when adding new libs
Reviewed By: cipolleschi
Differential Revision: D51184321
fbshipit-source-id: 28696f0a8e43e0bcd24a37956823fb544ecd84be
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41417
Changelog: [Internal]
BUCK boilerplate to integrate the first RCTFoundation library. decided to split this up so we can reference it easily in the future when adding new libs
Reviewed By: cipolleschi
Differential Revision: D51101009
fbshipit-source-id: fe828b64c7fd939f8576a496478b6a401bfae69c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41418
Changelog: [iOS][Added]
creating a top level directory for shared lightweight utility functions
open to suggs on naming and rules we want to enforce
Reviewed By: shwanton, christophpurrer
Differential Revision: D51170983
fbshipit-source-id: 8bc0a193b486f5a0653ad58d92a034cacede2d61
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41419
Changelog: [iOS][something]
Creating a new top level directory for Apple platform specific code.
Reviewed By: christophpurrer
Differential Revision: D51170984
fbshipit-source-id: 1a453c9ae9142167afef5ac4a348c644fa6f1ab3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41535
## Context
**Remote JS Debugging removal**
In React Native 0.73, we have deprecated Remote JS Debugging (execution of JavaScript in a separate V8 process) and also removed the Dev Menu launcher (https://github.com/facebook/react-native/pull/36754).
## This diff
Follows D46187942 — this option wasn't correctly removed for Android when running JSC. This is now consistent with iOS.
Changelog:
[Android][Changed] "Open Debugger" is no longer available for remote JS debugging from the Dev Menu (non-Hermes). Please use `NativeDevSettings.setIsDebuggingRemotely()`.
Reviewed By: blakef
Differential Revision: D50555095
fbshipit-source-id: 1aeb48ab1390dc12ce300d6f321c30de5343cf0a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41537
# Changelog:
[Internal] -
This allows to optionally provide a custom list of component/api test clauses into `RNTesterApp`.
Reviewed By: christophpurrer
Differential Revision: D51429407
fbshipit-source-id: 3ee35f13f6156fd055f6e0cbc788b7cf01c22b36
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41529
# Changelog:
[Internal]-
The change is equivalent in terms of API, however this makes it work nicer with C++ codegen and easier to use with a pure C++ implementation of the native module.
Reviewed By: christophpurrer
Differential Revision: D51426015
fbshipit-source-id: aae4d91bb93834e1a9c14a21417724a348de0bd7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41526
CI failures in Windows JS tests recently (https://github.com/facebook/react-native/pull/41463) were caused by the triggering of Babel registration during tests, due to an import of `packages/dev-middleware` (index), breaking subsequent transformation of other tests.
## Root cause
Example of a problematic import:
https://github.com/facebook/react-native/blob/a5d8ea4579c630af1e4e0fe1d99ad9dc0915df86/packages/dev-middleware/src/__tests__/ServerUtils.js#L15
..which triggers a Babel registration:
https://github.com/facebook/react-native/blob/a5d8ea4579c630af1e4e0fe1d99ad9dc0915df86/packages/dev-middleware/src/index.js#L16-L18
That registration behaves differently on Windows due to the `ignore: [/\/node_modules\/\]`, which doesn't match against Windows path separators - Babel matches against system separators.
In particular, this changed whether `node_modules/flow-parser` was transformed when loading the RN Babel transformer. Transforming this file causes a `console.warn` from Babel due to its size:
> [BABEL] Note: The code generator has deoptimised the styling of /Users/robhogan/workspace/react-native/node_modules/flow-parser/flow_parser.js as it exceeds the max of 500KB.
This throws due to our setup:
https://github.com/facebook/react-native/blob/a5d8ea4579c630af1e4e0fe1d99ad9dc0915df86/packages/react-native/jest/local-setup.js#L27
This all manifests as the first test following a Babel registration (within the same Jest worker) that requires the RN Babel transformer throwing during script transformation.
## This change
This is the minimally disruptive change that makes Babel registration behaviour consistent between Windows and other platforms. The more durable solution here would be *not* to rely on any Babel registration for Jest, which has its own `ScriptTransformer` mechanism for running code from source. Given the fragile way our internal+OSS Babel set up hangs together that's a higher-risk change, so I'll follow up separately.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D51424802
fbshipit-source-id: 8b733c0c159ee84690aef04abced682d126c6d27
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41525
This creates an experimental mechanism to get notifications when image instances are created anywhere in the app.
This can be useful to set up things like image performance tracking automatically without having to use a custom component and manually access refs from image components.
Changelog: [internal]
Reviewed By: oprisnik
Differential Revision: D49962063
fbshipit-source-id: b991a808aaa723bea98c27812892cfa468f025a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41500
Right now, the old architecture uses Codegen in a slightly different way w.r.t. the New Architecture.
In the Old Architecture, codegen is used to generate some basic TM and components that are part of Core.
Both architectures use the same scripts that actually generates the code, but they are invoked differently.
This is causing some maintenance costs that we would like to reduce.
## Changelog:
[Internal] - Defragment how Codegen is run between old and new architecture
Reviewed By: dmytrorykun
Differential Revision: D51349874
fbshipit-source-id: 188d3ed436a30a77bd42a26306d4a08666d3a00b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41516
This cleans up some dead code in animated components (some wrappers that actually don't do anything), which in this case leads to component names being properly defined for debugging in React DevTools, etc.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D51401568
fbshipit-source-id: 0de43f526b77a6b83e66e03f0ffa8d42c2b77112
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41507
Noticed we were creating this in various places and could consolidate it. This shouldn't have any perf impact since all of these use the same Handler.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D51348699
fbshipit-source-id: b11799f64cad3e9c1122e074954fce60e586d00d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41508
```
> Task :packages:react-native:ReactAndroid:compileDebugKotlin FAILED
e: warnings found and -Werror specified
w: file:///root/react-native/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/touch/JSResponderHandler.kt:55:38 The corresponding parameter in the supertype 'OnInterceptTouchEventListener' is named 'view'. This may cause problems when calling this function with named arguments.
```
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D51394096
fbshipit-source-id: ff322a10121b529c9a39b800e16a1a8cc5977d4a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41499
After D48152876 we consume JSI from `ReactCommon/jsi`, and ignore JSI that is distributed with `hermes-engine`.
This diff removes `include/jsi` from `source_files` of `hermes-engine` so we don't get two sets of JSI headers - one from `ReactCommon`, and the other one from `hermes-engine`.
This diff also fixes accidental breakage of ODR violation. We will no longer compile JSI into `react-native` when linking against `hermes-engine`, which already has JSI in it.
Changelog: [iOS][Fixed] - Exclude JSI headers when using hermes-engine prebuilt.
Reviewed By: cipolleschi
Differential Revision: D51347562
fbshipit-source-id: 6e4b9940c43d74d227a05999926b8752d7685670
Summary:
Adds changelog for the 0.72.7 release.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [CHANGED] - Add changelog for the 0.72.7 release.
Pull Request resolved: https://github.com/facebook/react-native/pull/41474
Test Plan: Read the changelog 🤞
Reviewed By: christophpurrer
Differential Revision: D51344851
Pulled By: huntie
fbshipit-source-id: a142a76ba75665fd0e6c7104ffb008f0f4ff3c95
Summary:
NotThreadSafeViewHierarchyUpdateDebugListener is not implemented in the new architecture because it is not relevant. That's why I'm marking NotThreadSafeViewHierarchyUpdateDebugListener as deprecated in new architecture
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: rshest
Differential Revision: D51262576
fbshipit-source-id: 05022f7605ffc9f9aee3dbb0652f331849db82e0
Summary:
com/facebook/react/surface package only contains one file (ReactStage), this annotation is only used internally by the framework and it fit better in uimanager package.
In this diff we are:
- deleting com/facebook/react/surface package
- moving ReactStage to com/facebook/react/uimanager
- Properly using ReactStage in ReactRoot and ReactRootView
This is a backward compatible change because ReactStage is only used in the internals of React Native
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: rshest
Differential Revision: D51262575
fbshipit-source-id: 34c140fbd0868a5a95489ee51b3262263b33ca69
Summary:
The new architecture will only support Fabric UIManager, that's why we will just deprecate UIManagerType as part of the new architecture
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: rshest
Differential Revision: D51262582
fbshipit-source-id: ff918ff760e95bbda39f5010b141a542c9171517
Summary:
This diff marks uimanager annotations as deprecated in new architecture becasue we've decided the native codegen will not be addopted in new architecture
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: rshest
Differential Revision: D51262580
fbshipit-source-id: 1248117ca697c612c89062fcee56788cce40a1ae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41484
## Changelog:
[Internal] -
Uses mount hooks to report "paint time" via the Event Timing API - i.e. "duration" now corresponds not the the JS dispatch end point, but to the moment when the corresponding mount ("paint") happened on the native side.
This feature is disabled by default for now, but can be enabled via `NativePerformanceObserver.setIsReportingEventPaintTime(true);`.
Reviewed By: rubennorte
Differential Revision: D51313902
fbshipit-source-id: b15fed772056bb3af619496f805e45dd9222426d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41485
Now that React-Hermes does not depends on folly::Futures anymore, we can safely delete the `libevent` dependency.
This will speedup the pod install step and potentially also the bundle size (to be tested)
## Changelog
[Android][Removed] - Remove libevent dependency
Reviewed By: javache
Differential Revision: D51319583
fbshipit-source-id: 155cc3632b005074c43565e7281c9873ab046f0d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41486
Now that React-Hermes does not depends on folly::Futures anymore, we can safely delete the `libevent` dependency.
This will speedup the pod install step and potentially also the bundle size (to be tested)
## Changelog
[iOS][Removed] - Remove libevent dependency
Reviewed By: javache
Differential Revision: D51307333
fbshipit-source-id: 029c1d6aaad46fc261502241f7df28b4d5f59eb9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41037
Build JSI as a shared library by default. This avoids running into a
problem with duplicate JSI when building against `libhermes` as a
shared library. This is already the case for React Native on Android.
For RN's iOS builds, explicitly specify that JSI should be statically
linked.
Changelog: [Internal]
Reviewed By: dannysu
Differential Revision: D50294405
fbshipit-source-id: 5e77e6d4ab77f8e338ca5ca4154e879eb3d616d7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41347
X-link: https://github.com/facebook/yoga/pull/1453
This follows the previous patterns used for `Gutters` and `Dimension`, where we hide CompactValue array implementation from `yoga::Style` callers.
This allows a single read of a style to only need access to the resolved values of a single edge, vs all edges. This is cheap now because the interface is the representation, but gets expensive if `StyleValuePool` is the actual implementation.
This prevents us from needing to resolve nine dimensions, in order to read a single value like `marginLeft`. Doing this, in the new style, also lets us remove `IdxRef` from the API.
We unroll the structure dependent parts in the props parsing code, for something more verbose, but also a bit clearer.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D50998164
fbshipit-source-id: 248396f9587e29d62cde05ae7512d8194f60c809
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41443
changelog: [internal]
instanceHandle is retained by UIManager::createNode. Let's make that obvious in the API.
Reviewed By: NickGerleman
Differential Revision: D51233821
fbshipit-source-id: b97ad80d3ac31a7830c24c8900caa723ca0e9c20
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41448
This was possible before due to precision problems with `double` (we were seeing values like 1.000000002). This is an easy way to prevent that problem.
Changelog: [internal]
Reviewed By: rshest
Differential Revision: D51230183
fbshipit-source-id: 757ef181fe369d525831faf8a6d907467efc544c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41454
Yet another problem caused by React being too aggressive cleaning up detached fibers. This fixes a problem in `IntersectionObserver` when trying to `unobserve` detached targets. In that case we didn't have access to its shadow node anymore, so we didn't have a way to unobserve in native. This keeps an additional mapping in JS to do the conversion even after detached.
Changelog: [internal]
Reviewed By: rshest
Differential Revision: D51257960
fbshipit-source-id: 25edc9afd2108e141d178dd4939fc2de8286342b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41449
`IntersectionObserver` was incorrectly throwing errors when reporting entries for detached targets. The problem was that we were deriving the target instance from the instance handle that we keep in native, but React removes the connection between them when the instance handle is unmounted.
This fixes the problem by keeping an internal mapping between instance handle and target internally in the intersection observer manager.
Changelog: [internal]
Reviewed By: rshest
Differential Revision: D51210456
fbshipit-source-id: 7c4a03c14c7f756191f395e0178eadc979cce146
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41450
`IntersectionObserver` shouldn't report entries for targets that are no longer being observed by the observer. This wasn't the case before because it was possible to create an intersection observer entry, then unobserve the target and then dispatch the pending entries (including the unobserved target). This fixes that issue to align with Web browsers.
Changelog: [internal]
Reviewed By: rshest
Differential Revision: D51256827
fbshipit-source-id: 28035f00bcb05a8ca53140719019032b3399436c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41451
After [this change in React](https://github.com/facebook/react/pull/27687), `ReactFabric.getPublicInstanceFromInternalInstanceHandle` can return `null` if the instance handle is a fiber that was unmounted (before that PR, it would throw an error).
This modifies the DOM traversal API to gracefully handle that case.
Changelog: [internal]
Reviewed By: rshest
Differential Revision: D51210455
fbshipit-source-id: 05de682d840eed7f22473800efe5fb910c8f3a0d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41473
This removes a legacy behavior in React Native to use the native module for MobileConfig to create `ReactNativeConfig`. It now uses the same implementation that the native module uses so we don't depend on TurboModule infra and we can instantiate `ReactNativeConfig` before that infra is ready.
Changelog: [internal]
Reviewed By: christophpurrer
Differential Revision: D51268579
fbshipit-source-id: 6b4860b064b45115e9c43997134e9aa771f330ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41423
X-link: https://github.com/facebook/yoga/pull/1466
Right now Yoga's main branch says it's 2.0.0, and RN's dirsync says its 1.14.0, but the code is really closer to what will be Yoga 3.0.0.
This changes trunk builds to "0.0.0" for clarity, which will be assigned a real version number the first time publishing a new Yoga branch.
This is separately a good practice to prevent the chance of accidental publishes causing damage.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D51236778
fbshipit-source-id: 06cac89bcca1c707ce5c00f9c346f627eef6b4bc
Summary:
This PR removes some jobs we don't need right now
## Changelog:
[Internal] - remove unnecessary jobs
Pull Request resolved: https://github.com/facebook/react-native/pull/41453
Test Plan: CircleCI stays green
Reviewed By: NickGerleman
Differential Revision: D51257788
Pulled By: cipolleschi
fbshipit-source-id: e348a7ef7af469ba019b2ccc33feed79a9d4febe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41463
S378983 Circle CI tests have been red for 5 days. There's a test setup issue somewhere in this test suite, until motiz88 can determine where exactly, let's disable them
T169943794 filed to follow up
Changelog: Internal
Reviewed By: cipolleschi
Differential Revision: D51271630
fbshipit-source-id: 7dbc61bb4c8df0d5360ba239a1f00c4270a691f3
Summary:
CircleCI was broken since Friday because a change broke JS tests on Windows only.
The test_windows job didn't run on those changes because they were JS changes only, therefore won't affect the build of React Native on Windows.
The `test_windows` was listed among the various `test_android` jobs, but it is not actually building React Native android on windows machines.
Instead, the test_windows jobs is actually only running JS tests on a windows machines. Therefore, it makes more sense to have this test under the test_js group.
bypass-github-export-checks
## Changelog:
[Internal] - Move the test_windows job under the testJS configuration
Pull Request resolved: https://github.com/facebook/react-native/pull/41455
Test Plan:
CircleCI is green.
test_windows run together with the JS tests
Reviewed By: mdvacca
Differential Revision: D51258120
Pulled By: cipolleschi
fbshipit-source-id: a523c48f697b64620433ec9672f13baa308d75a8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41410
Changelog: [Internal]
I am planning some changes in this component. No functional changes in this diff.
Reviewed By: robhogan
Differential Revision: D50644901
fbshipit-source-id: 5464640d64bf2e50696d7e579b30985b6ceaef5a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41411
Changelog: [Internal]
I am planning some changes in this component. No functional changes in this diff, except for the `panelContainerStyle` change for iOS to fix top gap.
Reviewed By: robhogan
Differential Revision: D50644902
fbshipit-source-id: 3111da100261552c89d0cd4eae724500c446cdfd
Summary:
`build_codegen!` currently assumes that `react-native/codegen` gets installed next to `react-native`. In a pnpm setup, it's found under `/~/react-native/node_modules/react-native/codegen` instead.
However, as dmytrorykun pointed out, we don't actually need to build it outside of this repository.
## Changelog:
[GENERAL] [FIXED] - `react-native/codegen` shouldn't be built unless it's in the repo — fixes `pod install` failures in pnpm setups
Pull Request resolved: https://github.com/facebook/react-native/pull/41399
Test Plan: We have a patched version of `react-native` working in a pnpm setup here: https://github.com/microsoft/rnx-kit/pull/2811
Reviewed By: dmytrorykun
Differential Revision: D51201643
Pulled By: cipolleschi
fbshipit-source-id: 53767ae08686a20f03b3b93abcbc7d5383083872
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41420
X-link: https://github.com/facebook/yoga/pull/1465https://yogalayout.com now redirects to https://yogalayout.dev
This replaces references to "yogalayout.com" with "yogalayout.dev", the same website, with a new domain. This includes:
1. Code comments
2. Yoga website config (publish action CNAME, Docusaurus config)
3. Documentation URLs in Yoga packages
Changelog:
[General][Fixed] - "yogalayout.com" to "yogalayout.dev"
Reviewed By: christophpurrer
Differential Revision: D51229587
fbshipit-source-id: b1c336a52aab5e02565071b61430d5435381dc0a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41412
The PR https://github.com/facebook/react-native/pull/39682
moved all TurboModule classes into the folder com/facebook/react/internal/turbomodule/core/interfaces/TurboModule. The reasoning is TurboModule classes are internal implementation of RN and they shouldn't be part of the public API.
Later we realized that com.facebook.react.internal.turbomodule.core.interfaces.TurboModule interface is actually being used by OSS developers too implement the TurboReactPackage.getReactModuleInfoProvider() method:
https://reactnative.dev/docs/next/the-new-architecture/pillars-turbomodules#updating-the-calculatorpackagejava
In this diff I'm re-introducing the com.facebook.react.turbomodule.core.interfaces.TurboModule interface jus for backward compatibility.
Since the plan is to delete the TurboReactPackage.getReactModuleInfoProvider method in the next few months, the plan is:
- Iterate on the experiments to remove TurboReactPackage.getReactModuleInfoProvider method
- Once TurboReactPackage.getReactModuleInfoProvider method is ready to be deleted, there's no need to expose TurboModule interface anymore, so we will delete 'com.facebook.react.turbomodule.core.interfaces.TurboModule' and 'TurboReactPackage.getReactModuleInfoProvider' method
- com.facebook.react.internal.turbomodule.core.interfaces.TurboModule will still remain in the codebase, but this will be an internal API
changelog: [Android][Changed] Fix backward compatibility breakage
Reviewed By: fkgozali
Differential Revision: D51168413
fbshipit-source-id: 921475f4beee7c6f04912558204a1911cd74b5ca
Summary:
X-link: https://github.com/facebook/yoga/pull/1451
Pull Request resolved: https://github.com/facebook/react-native/pull/41327
The special meaning of `0.0` is now explained in the function header, and we aren't doing any sort of insensitive compare here, so the code after should be equivalent and a bit simpler.
Reviewed By: yungsters
Differential Revision: D51014264
fbshipit-source-id: 60f4a2df039f74089d5c7fabd4b7d8ac6234ba72
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41317
X-link: https://github.com/facebook/yoga/pull/1449
This aims to clean up the public Yoga C API, by:
1. Documenting public YGNode, YGValue, YGConfig APIs
2. Splitting APIs for specific objects into different header files (because Yoga.h was big enough without documentation)
3. Reordering headers and definitions for consistent grouping
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D50963424
fbshipit-source-id: 45124b7370256fc63aefd6d5b7641466e9a79d3b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41402
Changelog: [Internal]
UIActionSheet was deprecated in iOS 8.3.
The RCTActionSheetManager class listed the UIActionSheetDelegate as an adopted protocol but none of the protocol methods were implemented.
Reviewed By: sammy-SC
Differential Revision: D50732844
fbshipit-source-id: e954f1e9a03e80561b3b066557e56c7f3d3589d4
Summary:
React Native, the text inline is made versatile by design. Being managed in an alien layout logic (i.e., text paragraph), inline views work seamlessly as if in normal **flex** layout. The capacities such as animation and relayout, however, requires extra efforts on native layer.
This PR fixed one critical issue for inline, i.e., `setState()` is not working when inline contains nested views.
Closes https://github.com/facebook/react-native/issues/41348
Demo (Fixed)
https://github.com/facebook/react-native/assets/149237137/2b42d657-4024-476b-bf0c-be25ef4f8c0c
## Problem in technical:
This issue is caused by a bug in `RCTShadowView::sizeThatFitsMinimumSize()` which accidentally unlink children (of yoga nodes) with their parent (owner). More specifically, on the critical path, it
1. first **shallow** clones the current node
```
YGNodeRef clonedYogaNode = YGNodeClone(self.yogaNode);
```
2. then calls `YGNodeCalculateLayout()` using the cloned node
3. deallocate the cloned node `YGNodeFree()`
One unseen implication of `YGNodeFree()` is to unlink all its children (because of the **shallow** clone)
```
for (size_t i = 0; i < childCount; i++) {
auto child = node->getChild(i);
child->setOwner(nullptr);
}
```
Next, let's examine,
**How nullptr of owner can cause the broken `setState()` of nested inline views**
The orphan children has two consequences:
**a**. the changes on child node (`setState()`) cannot be propagated to the parent (`YGNodeMarkDirty` -> `node->markDirtyAndPropagate();`);
**b**. `YGNodeCalculateLayout()` (`yoga::calculateLayoutImpl`) will create new children instances when orphan is detected (see below)
```
node->cloneChildrenIfNeeded(); // line 1599 # CalculateLayout.cpp
```
Both compounded are contributing the failed `setState()`. Respectively,
**a** causes early return of `YGNodeCalculateLayout()` because parent is recognized as not *dirty*;
**b** clones a new *dirty* node which replaces the child which is supposed to be *cleaned* within `YGNodeCalculateLayout()`. And this is the *dirty* node detected by the assertion mentioned in the issue description https://github.com/facebook/react-native/issues/41348.
## The fix:
The fix introduced in this PR is to relink the children with their parent in `RCTShadowView::sizeThatFitsMinimumSize()`
## Changelog:
[IOS] [FIXED] - `setState` is not working for nested inline views in text
Pull Request resolved: https://github.com/facebook/react-native/pull/41352
Test Plan:
Test directly in rn-tester
TBD
Reviewed By: yungsters
Differential Revision: D51071338
Pulled By: NickGerleman
fbshipit-source-id: 1f3d8a3e1e03cb11577f903e43f2c2cce9e07b6e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41408
When FabricRenderer is used during jests it will currently error out since `nativeFabricUIManager` is nog a configured global.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D51198314
fbshipit-source-id: 4db1450f6b36699311692c2cd467184f6abea518
Summary:
The goal for this PR is to further remove references for `[UIScreen mainScreen]` and migrate them to use trait collections. This helps out of tree platforms like visionOS (where the `UIScreen` is not available).
bypass-github-export-checks
## Changelog:
[INTERNAL] [CHANGED] - use currentTraitCollection for FBSnapshotTestController.m
[IOS] [CHANGED] - use key window width to assign the correct width for RCTDevLoadingView
Pull Request resolved: https://github.com/facebook/react-native/pull/41388
Test Plan:
– Check if tests passes
- Check if `RCTDevLoadingView` shows up correctly.
Screenshot:

Reviewed By: javache
Differential Revision: D51156230
Pulled By: cipolleschi
fbshipit-source-id: bbe711e0281046a082fd1680b55e2d117915ad00
Summary:
Recently, both `metro-inspector-proxy`(https://github.com/facebook/react-native/pull/39045) and `react-native-community/cli-plugin-metro`(https://github.com/facebook/react-native/pull/38795) were moved to this repo and in the process of moving these packages, the `exports` field inside package.json was added, only exporting the `index.js` file.
The problem is that Expo CLI (and possibly other community packages) rely on functions and classes that are not exported in the `index.js` file, e.g. Importing the InspectorProxy class from `react-native/dev-middleware/dist/inspector-proxy/InspectorProxy`. Normally this wouldn't be a problem and we would just import from `dist/` but due to the `exports` field, attempting to import from any other file not specified on this field will result in a `ERR_PACKAGE_PATH_NOT_EXPORTED` error.
As a short-term fix, we should create `unstable_`-prefixed exports of individual features Expo currently depends on.
## Changelog:
[INTERNAL] [CHANGED] - Expose unstable_InspectorProxy and unstable_Device from `react-native/dev-middleware`
Pull Request resolved: https://github.com/facebook/react-native/pull/41370
Test Plan: N / A
Reviewed By: robhogan
Differential Revision: D51163134
Pulled By: blakef
fbshipit-source-id: e67adaedc4fc64131e4c9dd8383c9877b8202283
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41374
Refactoring `DefaultReactNativeHost` to use the new way of Fabric initialization through `FabricUIManagerProviderImpl`
Changelog:
[Internal] internal
Reviewed By: philIip, luluwu2032
Differential Revision: D50926872
fbshipit-source-id: be2bcea7b2ce7cb1b3f903dc92fcd2c91be267da
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41313
Refactor ReactNativeHost, ReactInstanceManager & Builder of `react-native-github` to use the new way of fabric initialization using the newly added class `FabricUIManagerProviderImpl.java` instead of JSIModule and thereby also refactoring the call site in FbReactInstanceHolder.java
Changelog:
[Internal] internal
Reviewed By: philIip
Differential Revision: D50783751
fbshipit-source-id: 0a9d3412bc995834cafa8fbaec2ff17e321d9906
Summary:
In pnpm setups, codegen will fail during build because it cannot find its dependencies. Some of the dependencies it relies on at runtime are currently declared under `devDependencies`. This change moves them to `dependencies`.
## Changelog:
[GENERAL] [FIXED] - Fix `react-native/codegen` not being able to resolve dependencies in pnpm setups
Pull Request resolved: https://github.com/facebook/react-native/pull/41398
Test Plan: We are currently trying to [enable pnpm mode](https://github.com/microsoft/rnx-kit/pull/2811) in rnx-kit and hit this issue. We've patched this package locally and it works.
Reviewed By: christophpurrer
Differential Revision: D51169116
Pulled By: NickGerleman
fbshipit-source-id: 28906a0de412c660d2fc42f62deaf77240d27a58
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41385
Changelog: Internal
Adding a Cxx TM example which adds a listener and returns a subscription to remove that listener from the TM.
You should be able to use this with React Hooks - https://legacy.reactjs.org/docs/hooks-reference.html
E.g.
```
useEffect(() => {
const subscription = NativeCxxModuleExample.setValueCallbackWithSubscription(
callbackValue => // use it
);
return subscription;
});
```
Reviewed By: shwanton
Differential Revision: D50473063
fbshipit-source-id: 4e9b92aeccff1771eb4ffad6bdaa20ba7f18435f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41360
Changelog: [Internal]
This is Flipper-only, React DevTools inject these internals in `connectToDevTools` call
Mostly for 2 reasons:
- For React DevTools' hook being accessed only in one place (AppContainer-dev)
- This logic is not related to Inspector itself
Reviewed By: GijsWeterings
Differential Revision: D50559547
fbshipit-source-id: 2127f3a20b71261858fdfc004a372d1d95ced164
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41291
Changelog: [Internal]
We have the same logic in 3 different places, encapsulating access to React DevTools hook in one place, all other components that require agent will get it as a prop.
Reviewed By: GijsWeterings
Differential Revision: D50559550
fbshipit-source-id: f3667a82ca48a36032c60c730df8f661098401ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41307
Changelog: [Internal]
To be able to use it in other possible places.
Reviewed By: javache
Differential Revision: D50952773
fbshipit-source-id: f21f4553e7f51ab0683a6adb834dc5c90c33c927
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41285
Changelog: [Internal]
I have an ongoing work on improving debugging overlays, lots of changes in these files are planned.
- Split `AppContainer` into 2 implementations: DEV and PROD
- Rewrite to functional components
Reviewed By: javache
Differential Revision: D50559549
fbshipit-source-id: 3790f149d504bd45be78c6f3103e05677f3a107d
Summary:
https://github.com/facebook/react-native/issues/41308 introduce the possibility to run e2e tests if a commit contains #run-e2e-tests in the commit message.
This PR builds on top of that, and let users to run e2e tests by adding a comment with with #run-e2e-tests
## Changelog:
[Internal] - Allow to run e2e tests from comments
Pull Request resolved: https://github.com/facebook/react-native/pull/41311
Test Plan: Not sure it can be tested until the PR is merged... ¯\_(ツ)_/¯
Reviewed By: dmytrorykun
Differential Revision: D51111543
Pulled By: cipolleschi
fbshipit-source-id: e6c55950552f03830fa35c89d385ab9b17f8facb
Summary:
This PR aims to make scripts building hermes locally more extensible for out-of-tree platforms. It will make it easier for forks like visionOS to add additional `elif` statements.
As a side benefit this PR fixes Hermes builds for MacOS 😄 (I've checked that it now builds correctly)
## Changelog:
[IOS] [ADDED] - make build-hermes-xcode.sh more extensible for out-of-tree platforms
Pull Request resolved: https://github.com/facebook/react-native/pull/41387
Test Plan: Run the local Hermes build by running `USE_HERMES=1 bundle exec pod install` and check if it runs smoothly. Also, a CI check should be sufficient.
Reviewed By: dmytrorykun
Differential Revision: D51156307
Pulled By: cipolleschi
fbshipit-source-id: 1c65b84b16fc8bd0552037c6ef558543cbe03889
Summary:
Enable Flow `casting_syntax=both` in fbsource, before the announcement so that when people see it they can check it out without rebasing.
bypass-github-export-checks
bypass-lint
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D51097870
fbshipit-source-id: dfcb04000df26140c971422389b6fce0b1ba51e7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41381
Noticed that when scrolling VirtualizedList's CellRenderer was re-rendering due to `onCellFocusCapture` not having a stable identify. Change the interface to CellRenderer to pass in the `cellKey` in the callback to save on creating new callbacks.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D51112928
fbshipit-source-id: 3fcb974d9b5585403895746fbc45f2cf5a9fa6b1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41342
While rewriting `Debugger.getScriptSource` messages to fetch code and source map over HTTP, we weren't checking the status code of the fetch calls. This diff fixes that and adds corresponding tests (as well as for the filesystem error case).
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D51013054
fbshipit-source-id: 58e7bb9fcd6a3cf92329b43fb8a139093c80d305
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41341
* Extends `dev-middleware`'s test utilities to enable testing against an HTTPS server with a self-signed cert.
* Runs the CDP transport integration tests (D51002261) using both HTTP and HTTPS.
* Adds a test to explicitly cover the `ws=...` / `wss=...` variation in `devtoolsFrontendUrl` first introduced in D49158227.
Changelog: [Internal]
Reviewed By: blakef
Differential Revision: D51006835
fbshipit-source-id: df3db8cd865898248cd0d8f307f75949a7f313fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41335
`inspector-proxy` has special behaviour to allow a debugger connection to persist across app reloads.
In the React Native runtime, a reload is modelled as the creation of an entirely new "page" with its own ID. To insulate the debugger from this detail, the proxy advertises a separate, synthetic page on each device, with ID `-1`, that always maps to the latest React Native page reported by that device.
Here we test the message forwarding part of this functionality. The proxy also injects CDP messages (in both directions) as part of simulating a reload, but that will be tested in a separate diff.
Changelog: [Internal]
Reviewed By: blakef
Differential Revision: D51002262
fbshipit-source-id: 296135177321a511ebbe7d9696e4e7a61275aa32
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41343
Changelog: [Internal]
Adds basic tests for two-way communication between a debugger (frontend) and a target (backend) using CDP over `inspector-proxy`.
Reviewed By: blakef
Differential Revision: D51002261
fbshipit-source-id: 44e571f89437c26e76ef6e6192b2bf6244665cf0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41331
`inspector-proxy`'s `Device` class currently leaks a `setInterval` handle. This is mostly harmless in current usage. In the test suite added up the stack, it shows up as a leak that prevents Jest from exiting cleanly, so let's clean it up properly.
Changelog: [Internal]
Reviewed By: blakef
Differential Revision: D51002263
fbshipit-source-id: ca36797ce1196aa049ceb3a8e96ee53d34893fdc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41314
Changelog: [Internal]
Adds the beginning of a test suite for `inspector-proxy`. For maintainability, we only test functionality exposed from the `dev-middleware` boundary rather than instantiating `InspectorProxy` directly.
In this diff, the test coverage is far from complete, but this is a first stab at covering some basics. `InspectorProxyHttpApi-test` exercises the HTTP GET endpoints (`/json/list` and `/json/version`) as well as some device registration logic through the `/inspector/device` WebSocket. Some reusable helpers for server setup and device mocking are included in separate files.
As an overall strategy, I'm planning to add multiple test files that share helpers between them, not build out one massive test file with all the helpers inline. There will likely be some verbose tests when we start covering debugger-to-device communication, and I want to keep them as readable as possible.
Reviewed By: blakef
Differential Revision: D50980467
fbshipit-source-id: 962dae5a380451d6dac57eac23c4436550a39cf8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41359
This change migrates the remaining podspecs to the new functions, so we do not depend on hardcoded values anymore and we can scale the solution to other platforms.
## Context
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51068403
fbshipit-source-id: 4c0455543363ccf4272d5e8590a7c663d9c33e8b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41358
This change expose a missing function to create Header Search Paths when a podspec can't depend on another one explicitly.
This also migrate the ruby code to this new function.
## Context
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51068390
fbshipit-source-id: ba9e09cd2f0671a9f3f00cc72496a0d5682eeb90
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41357
This change migrate React-RCTBlob to the new add_dependency to improve its compatibility with macOS and to remove some maintenance burden.
## Context
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51030365
fbshipit-source-id: c4b9037d6d0223052d659c04a1f494508944ed2a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41356
React-Core does not depends on any bit of ReactCommon, React-RCTFabric or React-NativeModuleApple, so I'm cleaning that up.
## Context
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51030115
fbshipit-source-id: f87dbfe99e90d52cf8c07057be22cd024e38db42
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41355
This change expose a new API to react_native_pod to add dependencies that automatically configure their search paths when using frameworksa and with multiple Apple platforms.
It also migrates React-RCTAppDelegate to this new mechanism to test that it works.
## Context
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51029484
fbshipit-source-id: 77dfe85419d495f7327a2f484d33f9ed8701e00d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41354
In order to make the infra scalable and avoid a maintenance nightmare for macOS and future platform, we are introducing this function that automate adding a dependency to a podspec and it generates the required search paths.
## Context
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51027343
fbshipit-source-id: 33ac4c07112eacb08067220397e38db0a19240fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41353
Last week I helped macOS to work with static framework.
When multiple platforms are specified, frameworks are build in two variants, the iOS and macOS one.
This break all the HEADER_SEARCH_PATHS as now we have to properly specify the base folder from which the search path is generated.
See also [this PR](https://github.com/microsoft/react-native-macos/pull/1967) where I manually make MacOS work with `use_framewroks!`
In order to make the infra scalable and avoid a maintenance nightmare for macOS and future platform, we are introducing this function that should factor out the platforms from the generation of header search paths.
## Changelog:
[Internal] - Add helper function to create header_search_path
Reviewed By: shwanton
Differential Revision: D51026356
fbshipit-source-id: 7cf03601d94d7680f3fdfcaf52b2fd6bcd48c5b4
Summary:
This change allow our CI to run E2E tests using a specific tag in the commit message
## Changelog:
[Internal] - Allow to run e2e test using a specific tag in the last commit message
Pull Request resolved: https://github.com/facebook/react-native/pull/41308
Test Plan:
CircleCI is green
Tested interacting with the PR/branch
Reviewed By: NickGerleman
Differential Revision: D50975588
Pulled By: cipolleschi
fbshipit-source-id: 6318800d7e86e1cab394af2b320e280304189dd2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39036
Changelog: [General][Changed] Use `hermes-parser` instead of `flow-parser` to parse Flow Codegen specs.
`hermes-parser` is a WASM build of the Hermes parser (plus supporting code), maintained by the Flow and Hermes teams. It is the recommended way of parsing Flow code in Node and its benefits (compared to `flow-parser`) include better performance and improved type safety.
Here we update `react-native/codegen` to use `hermes-parser` instead of `flow-parser`. Both parsers produce ASTs that conform to the ESTree spec so this is mostly a drop-in replacement.
In future work we should be able to use the improved AST types available in `hermes-estree` to improve type safety within `react-native/codegen` itself.
Reviewed By: huntie
Differential Revision: D48384078
fbshipit-source-id: 310ad150ec62671ba395b0e2f6415ccae97ac04d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39035
Changelog: [General][Fixed] Flow syntax errors in Codegen specs are no longer ignored.
Instead of throwing errors like most parsers, the `flow-parser` package returns errors as part of the AST (along with a best-effort parse). It turns out that `react-native/codegen` ignores such errors and only detects a subset of them after the fact. Here we change the behaviour to immediately throwing a descriptive error message (containing the file name and a code frame).
**This change is theoretically breaking** for any published packages that already contain broken Flow code (that somehow doesn't happen to affect the Codegen output today). Hopefully, anyone using Flow-flavoured RN Codegen is also typechecking with Flow and/or building with Metro (which would both flag the same errors), so the impact should be fairly contained.
Reviewed By: huntie
Differential Revision: D48385786
fbshipit-source-id: c7e1f5fb64a61fb0eb9e9f8f7501b43264c9626c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41346
X-link: https://github.com/facebook/yoga/pull/1452
This removes the last remnant from `Yoga-interna.h`, `YGNodeDellocate()`. The API is renamed to `YGNodeFinalize` to give it the explicit purpose of freeing the node from a garbage collector, and made public with that documented contract.
With that, every top-level header is now a public API, and Yoga's JNI bindings do not need to rely on private headers anymore.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D51014340
fbshipit-source-id: 553f04b62c78b76f9102cd6197146650955aeec5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41305
X-link: https://github.com/facebook/yoga/pull/1448
This should not be part of Yoga's API. If benchmarks want to do this, they still can (though I don't know the ones we have for it are super valuable).
Reviewed By: javache
Differential Revision: D50963933
fbshipit-source-id: 6482bd269928188b6469a358ffde5c4f9f5f9527
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41301
Adding the new API for creating UIManager(`FabricUIManager`) for Fabric initialization:
```
createUIManager(ReactApplicationContext reactApplicationContext)
```
and `FabricUIManagerProviderImpl()` and making it also implement the `UIManagerProvider` interface
NOTE:
Letting the older implementations in place and will be removed once the references have been removed from the apps and similarly for old constructor `FabricUIManagerProviderImpl()` and similarly for old implement relationship with `JSIModuleProvider`
Changelog:
[Internal] internal
Reviewed By: javache, philIip, mdvacca
Differential Revision: D50783295
fbshipit-source-id: 767f27c7f0d42840a5dad693e98cf5b6a243f933
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41296
As part of adding new implementation for `FabricUIManagerProviderImpl` APIs renaming the old class `FabricJSIModuleProvider` -> `FabricUIManagerProviderImpl` so as to add the new APIs later and preserve history.
Changelog:
[Internal] internal
Reviewed By: philIip
Differential Revision: D50949208
fbshipit-source-id: b833c4783b383c175fa682c558d31d8ecfa9f0ac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41364
Initializing UndefinedColor on iOS and Android is trivial because the platform color is an int32_t. On platforms where the HostPlatformColor header defines a color as a struct (e.g., Windows) it is less trivial to compose a constexpr for the undefined color representation to initialize this static const value with.
As it turns out, UndefinedColor is only used for operator bool in SharedColor, so it's reasonably safe to remove this "public" API (also good to limit the surface of SharedColor).
## Changelog:
[Internal]
Reviewed By: sammy-SC
Differential Revision: D51073395
fbshipit-source-id: 375e43aa9a30d394d35ce2946224563738d8973c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41330
D41564032 made `console.log` (as well as `debug` and `info`) a noop in tests within the React Native repo. Here we allow them through while still throwing errors on `console.error` and `console.warn`.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D51002264
fbshipit-source-id: 44ca8bef38695dd76fe509341adced887bef2e6b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41293
X-link: https://github.com/facebook/yoga/pull/1446
NickGerleman pointed out that my recent changes to fix the slew of row-reverse problems in Yoga actually ended up regressing some parts. Specifically, absolute children of row-reverse containers would have their insets set to the wrong side. So if you set left: 10 it would apply it to the right.
Turns out, in `layoutAbsoluteChild` there were cases where we were applying inlineStart/End values to the flexStart/End edge, which can never be right. So I changed the values to also be flexStart/End as the fix here.
Reviewed By: NickGerleman
Differential Revision: D50945475
fbshipit-source-id: 290de06dcc04e8e644a3a32c127af12fdabb2f75
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41209
X-link: https://github.com/facebook/yoga/pull/1439
There are so many instances in this code base where we use the double negative of `!yoga::isUndefined(<something>)`. This is not as easy to read since because of this double negative imo. Additionally, sometimes we have really long chains like `!longVariableName.longFunctionName(longArgumentName).isUndefined()` and it is hard to see that this undefined is inverted.
This just replaces all instances of inverted `isUndefined()` with `isDefined()` so its easier to read.
Reviewed By: NickGerleman
Differential Revision: D50705523
fbshipit-source-id: edc7d3f2cbbae38ddaeb2030a419320caf73feff
Summary:
X-link: https://github.com/facebook/yoga/pull/1437
Pull Request resolved: https://github.com/facebook/react-native/pull/41208
Reading through the sizing logic and this seemed a bit redundant/confusing. Lets use the same function we just used for the main axis for the cross axis as well so people do not think its special. Also we will need one less variable. The reason this was done it seems is because we need the leading padding + border elsewhere so this is technically a few less steps but this is cleaner
Reviewed By: NickGerleman
Differential Revision: D50704177
fbshipit-source-id: 1a091edbfee6482a2bf472aca2980702bd75ad94
Summary:
When bridgeless is enabled, RN Tester New Architecture examples crashed with a StackOverflow Exception
The root cause of this issue is that MyLegacyViewManager is sending an event to JS during the execution of MyLegacyViewManager.createViewInstance() method.
This is a problem because the delivery of events depend on the "id" of the view, but the "id" of the view is set after MyLegacyViewManager.createViewInstance() finishes executing.
The documentations "implicitly" mentions to not set props during the execution of the ViewManager.createViewInstance() method:
https://reactnative.dev/docs/native-components-android#2-implement-method-createviewinstance
To fix this issue I'm removing the execution of the method that triggers the event.
bypass-github-export-checks
changelog: [Android][Fix] Fix rendering of 'RN Tester New Architecture examples' when bridgeless is enabled
Reviewed By: fkgozali
Differential Revision: D51047007
fbshipit-source-id: 17be493f79114fa402029063e79fabc1d90efc17
Summary:
`Activity` is the current candidate name. This PR starts the rename work
by renaming the exported unstable component name.
NOTE: downstream consumers need to rename the import when updating to
this commit.
DiffTrain build for commit https://github.com/facebook/react/commit/ce2bc58a9f6f3b0bfc8c738a0d8e2a5f3a332ff5.
Reviewed By: tyao1
Differential Revision: D50945046
Pulled By: kassens
fbshipit-source-id: be9b3254c7a98840b0769135770e9bf7858cf1a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41345
## Changelog:
[Internal] -
This API was already accessible on the Android platform, now other platforms (C++) would benefit from having it available as well.
Arguably, it's perfectly fine to have it as public class members - based on empiric experience with the use case we have had.
Reviewed By: christophpurrer
Differential Revision: D51031340
fbshipit-source-id: 0426deede5d9e5c552c92f8a25d30fe2274a1941
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41333
Enables the `sort-imports` lint rule introduced in D39907799 in ~all files, rather than just in `react-native/Libraries`.
We exclude only `packages/react-native/template`, in order to (1) minimise noise for projects that are tracking updates to the template, (2) avoid the possibility of something breaking if the `react-native` import isn't at the top of `template/index.js`, (3) avoid leaking a reference to `lint/sort-imports` to the template (which doesn't ship with this rule) via an ESLint suppression comment.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D51025811
fbshipit-source-id: a62b0d6ebc5323116a4b2f1b69c4e8d48cde3215
Summary:
Though not currently in use in the RN code, when `react-native-windows` tried to integrate changes up to 7/28/23 (see PR https://github.com/microsoft/react-native-windows/pull/11970) there happened to be a `??=` operator in the `virtualized-lists` package (see [diff here](https://github.com/facebook/react-native/compare/ccc50ddd2...c168a4f88#diff-abeff2daf5909e54a23562e43569de1d5b8db1d7170119eed485b618cdf04ec7R322)). (The offending line was removed in a later commit).
The default RNW engine is still Chakra and it couldn't handle the syntax. It looks like the `babel/plugin-proposal-nullish-coalescing-operator` plugin only handles `??`, so to handle `??=` I've added `babel/plugin-proposal-logical-assignment-operators`, which also happens to handle the logical assignment operators `||=` and `&&=`.
Closes https://github.com/facebook/react-native/issues/31704
## Changelog:
[GENERAL] [FIXED] - Add detection of logical assignment operators to `react-native-babel-preset`
Pull Request resolved: https://github.com/facebook/react-native/pull/39186
Test Plan: We started using these plugins in RNW's babel config to resolve the issue in our integrate PR.
Reviewed By: motiz88
Differential Revision: D50936554
Pulled By: rozele
fbshipit-source-id: 0a924b6085524d8c9551a158b91195b1f7448c19
Summary:
Last week, I modified the e2e script to make sure it was working properly with 0.73.
This change backport those changes in main
## Changelog:
[Internal] - Backport e2e script changes
Pull Request resolved: https://github.com/facebook/react-native/pull/41332
Test Plan: Tested locally
Reviewed By: dmytrorykun
Differential Revision: D51025796
Pulled By: cipolleschi
fbshipit-source-id: 89ecd3701eaac4ba4bdde2c640df45a158329158
Summary:
This PR fixes a small typo in `build-ios-framework.sh`
## Changelog:
[INTERNAL] [FIXED] - Typo in `build-ios-framework.sh`
Pull Request resolved: https://github.com/facebook/react-native/pull/41325
Test Plan: Check if correct error message is printed out
Reviewed By: dmytrorykun
Differential Revision: D51022361
Pulled By: cipolleschi
fbshipit-source-id: 93c3e85eff8e410bcb18302dcb3ac76583d6e304
Summary:
zfrankdesign reported that in RN 0.72.6, they receive warnings that some new props listed in the documents are missing:
View tabIndex https://reactnative.dev/docs/view#tabindex-android and Text userSelect https://reactnative.dev/docs/text#userselect. It seems the components accept these props but they were not typed.
## Changelog:
[GENERAL] [FIXED] - Missing typings for the props `tabIndex` for **View** and `userSelect` in the **Text** props were added.
Pull Request resolved: https://github.com/facebook/react-native/pull/41312
Test Plan:
1. Instantiate a component of type View
1.1. Should add the property tabIndex to the View component.
1.2. Should not see a warning about the missing tabIndex property.
2. Instantiate a component of type Text
2.1. Should add the property userSelect to the Text component.
2.2. Should not see a warning about the missing userSelect property.
Reviewed By: NickGerleman
Differential Revision: D50982156
Pulled By: lunaleaps
fbshipit-source-id: 75b55cfb897738be0cf426912a7c10c7412d5032
Summary:
Closes https://github.com/facebook/react-native/issues/41236
`setState` is not working properly for text inline image
## Fixed demo (please see the animation as in rendering pass rather than re-mounting pass)
https://github.com/facebook/react-native/assets/149237137/d4b894bf-2283-4963-8dc7-b8f5a9f81315
## How it works
**Background**
Inline views are not included in the Yoga node tree, rather, they are retained as attachments of `NSAttributedString` and are managed by the respective text fragment (`RCTTextShadowView`) that includes them (Code snippet 1).
```
<div layout="width: 393; height: 852; top: 0; left: 0;" style="" >
<div layout="width: 393; height: 852; top: 0; left: 0;" style="flex: 1; " >
<div layout="width: 393; height: 852; top: 0; left: 0;" style="flex: 1; " >
<div layout="width: 393; height: 241; top: 0; left: 0;" style="padding-top: 59px; " >
<div layout="width: 393; height: 50; top: 59; left: 0;" style="width: 100%; height: 50px; " >
<div layout="width: 393; height: 17.3333; top: 0; left: 0;" style="" has-custom-measure="true"></div>
</div>
<div layout="width: 393; height: 50; top: 109; left: 0;" style="width: 100%; height: 50px; " >
<div layout="width: 393; height: 17.3333; top: 0; left: 0;" style="" has-custom-measure="true"></div>
</div>
/* Text node that does not contain inline view that is supposed to be there */
<div layout="width: 393; height: 74.3333; top: 167; left: 0;" style="margin-top: 8px; " has-custom-measure="true"></div>
</div>
</div>
</div>
</div>
```
**Code snippet 1, output of YGNodePrint() in _normal layout_ flow**
The layout of such node is handled ad-hoc (_inline layout_) inside `RCTTextShadowView` (Code snippet 2)
```
/* Inline node is calculated on its own */
<div layout="width: 48; height: 48; top: 0; left: 0;" style="overflow: hidden; width: 48px; height: 48px; min-width: 0px; min-height: 0px; " ></div>
```
**Code snippet 2, output of YGNodePrint() in _inline layout_ flow**
**Problem description**
The issue happens when the sizes given by `setState()` are smaller than those in the last round `setState()`. Since the `min-width` and `min-height` are already populated (Code snippet 3) with greater values, the new layout pass gives rather a `noop`.
```
/* min sizes are greater than them in the new style */
<div layout="width: 48; height: 48; top: 0; left: 0;" style="overflow: hidden; width: 32px; height: 32px; min-width: 48px; min-height: 48px; " ></div>
```
**Code snippet 3, output of YGNodePrint() in _inline layout (issue)_ flow**
**Fix description**
This biased `min-width` and `min-height` are given using the **current frame size** (i.e., sizes set in the last round `setState()`) in the _inline layout_ (in `RCTTextShadowView` § Background), whilst the same parameters are given as ~~CGSizeZero~~ `_minimumSize` in _normal layout_ (§ Background).
The change of this PR is to unify this behavior of _normal layout_ by using ~~CGSizeZero~~ `_minimumSize` as the input also for _inline layout_.
## Changelog:
[IOS] [FIXED] - `setState` is not working properly for text inline image
Pull Request resolved: https://github.com/facebook/react-native/pull/41287
Test Plan:
- Using **rn-tester** for basic verification
- Complete plan: https://docs.google.com/spreadsheets/d/1QLuqNvqX0dM4K68ygRoHDR3S0wcK5umptmjoR7KtkaY/edit?usp=sharing
Reviewed By: cipolleschi
Differential Revision: D50967547
Pulled By: NickGerleman
fbshipit-source-id: b3b6d6919fd9d3302977dc771a41c22f7b796ba5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41309
Changelog: [Internal][Removed] CxxModuleWrapper.makeDSO is not actively used and has been replaced by TurboModule infra.
Reviewed By: NickGerleman
Differential Revision: D50878589
fbshipit-source-id: 9fd11c1ee860ea65f1e985a132de3216ed042752
Summary:
We're logging a systrace section that for some reason is breaking the data in application traces. That section isn't especially relevant so we can just remove it.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D50939346
fbshipit-source-id: 350a528d83c6fe6e7100275644d3d02a96700e59
Summary:
This PR updates the internal version of cocoapods to 1.13, template already uses this version. I've also removed the root folder Gemfile as it's not necessary anymore.
## Changelog:
[INTERNAL] [CHANGED] - Update RNTester Cocoapods to 1.13
Pull Request resolved: https://github.com/facebook/react-native/pull/41248
Test Plan:
Check if cocoapods installs correctly by running:
1. `bundle install`
2. `bundle exec pod install`
Reviewed By: dmytrorykun
Differential Revision: D50972135
Pulled By: cipolleschi
fbshipit-source-id: b7d6a4671e641b7b8f50242a3374f623e023daf4
Summary:
This is not supported by any native implementation.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D50641812
fbshipit-source-id: e90a1998d2239b6f96c0c4db7b112f7e75cfc6dc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41299
## Changelog:
It makes sense to keep Web Performance logging mechanism separate from the GlobalPerformanceLogger, removing.
Reviewed By: rubennorte
Differential Revision: D50930312
fbshipit-source-id: 3b76ff28eae8c5a2bf41faceb33cf188d8318610
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41294
Changelog: [Internal]
i believe this warning is outdated, i don't think having a custom initializer or exporting constants means that your module needs to be setup on main.
Reviewed By: cipolleschi
Differential Revision: D50919152
fbshipit-source-id: dc91af5fc88eca4f07a5f35adb888160b978cc38
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41295
Changelog: [Internal]
modules will be setup on main queue for any the following criteria:
- override requiresMainQueueSetup and set it to yes
- have a method that starts with `init`
- have `constantsToExport` implemented
these methods return `NO` but don't fulfill the latter criteria, so we should just delete them
Reviewed By: cipolleschi
Differential Revision: D50919151
fbshipit-source-id: 662bd067a1bae0f81acfabfc95b2a2af0c0a3180
Summary:
## Changelog:
[Internal] -
There is no need for this feature flag anymore, cleaning up.
Reviewed By: rubennorte
Differential Revision: D50925309
fbshipit-source-id: 39ff3d1f85c1df5ba2be287d4b7df2a4222acdba
Summary:
Expose JSEngineResolutionAlgorithm into ReactHost interface
This is another step to reduce visibility of ReactHostImpl class and rely only on ReactHost
changelog: [internal] internal
Reviewed By: philIip
Differential Revision: D50910031
fbshipit-source-id: da893ef0574c26bc90867f45b55d5b1e244885fc
Summary:
Update various scripts to support AsExpressions, found by looking for scripts currently handling `TypeCastExpression`
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D50822952
fbshipit-source-id: c88c04a507d94ddbc6458a68fd36509463e91953
Summary:
Consolidate JSException and JavaScriptException. `JSException` was only ever created by `JMessageQueueThread`.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D50641818
fbshipit-source-id: 46686468891fe1498e17f3b40b619e8c2324d7a9
Summary:
When the proximity sensor is engaged and it detects "close", the screen is disabled so timers stop working. Treat the close proximity status as if the app went into the background so CADisplayLink based timers are not used.
bypass-github-export-checks
## Changelog:
[iOS] [Fixed] - Fix running timers when the proximity sensor detects close
Pull Request resolved: https://github.com/facebook/react-native/pull/41262
Reviewed By: dmytrorykun
Differential Revision: D50839017
Pulled By: cipolleschi
fbshipit-source-id: 3f7dc47d346eb88b687c8219fc905cf2a42262fe
Summary:
Fixes Dev menu pop up multiple times when Tap command `D` continuously, demo like below:
https://github.com/facebook/react-native/assets/5061845/b4c2b38d-ece6-4d4e-a823-23eaa7cad001
## Changelog:
[IOS] [FIXED] - Fixes Dev menu pop up multiple times when Tap command `D` continuously
Pull Request resolved: https://github.com/facebook/react-native/pull/41234
Test Plan: Press `D` continuously, the menu pop up and dismiss correctly.
Reviewed By: cipolleschi
Differential Revision: D50925959
Pulled By: blakef
fbshipit-source-id: 50fac9b4cea94c15a06ebc1b6092ebc9909cd9d2
Summary:
Follow up of https://github.com/facebook/react-native/pull/41284#issuecomment-1789516046
We should not rely on checking if the `React-hermes` pod is present to determine if hermes is enabled
## Changelog:
[IOS] [CHANGED] - Update ios pod post_install logic for detecting if hermes is enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/41286
Test Plan: Run `use_react_native!(hermes => false)` should not add `USE_HERMES = true;` to `project.pbxproj`
Reviewed By: blakef
Differential Revision: D50899654
Pulled By: cipolleschi
fbshipit-source-id: a5ab5b0117c61014e77b780c50bf349da92c6342
Summary:
Changing interface of UIManagerProvider to be a [functional(SAM) interface](https://kotlinlang.org/docs/fun-interfaces.html) for the return type of getUIManagerProvider() to be used in various apps for clarity.
Changelog:
[Internal] internal
Reviewed By: javache
Differential Revision: D50846818
fbshipit-source-id: c22977b45b0118d70b994e14ff79ea8990248e3c
Summary:
There is a problem in the way that we check if Fabric is enabled inside `react_native_post_install`.
https://github.com/facebook/react-native/blob/899e7cdb55197fc17a96a93af4f8bcc7519553c2/packages/react-native/scripts/react_native_pods.rb#L239
We're determining if fabric is enabled by checking if the `React-Fabric pod `is present, but since we always call `setup_fabric!(:react_native_path => prefix)` (https://github.com/facebook/react-native/pull/39057) inside `use_react_native` the `React-Fabric` pod is always present causing the `-DRN_FABRIC_ENABLED` flag to always be added to `project.pbxproj` even if the new arch is disabled.
## Changelog:
[IOS] [FIXED] - Fix ios pod post_install logic for detecting if fabric is enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/41284
Test Plan: Run `use_react_native!(fabric => false)` should not add the `-DRN_FABRIC_ENABLED` flag to `project.pbxproj`
Reviewed By: fkgozali
Differential Revision: D50896487
Pulled By: cipolleschi
fbshipit-source-id: 78154407ce52b09fd3a317b7dc64bd4bba56363e
Summary:
UIManagerProvider.java -> UIManager.kt so as to take advantage of Functional SAM interfaces of Kotlin for simplication
Changelog:
[Internal] internal
Reviewed By: rshest
Differential Revision: D50855256
fbshipit-source-id: 352edb39f019446c2ddae88a914c898f46239fce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41251
Changelog: [Internal]
remerge of https://github.com/facebook/react-native/pull/41183
>in my quest to get rid of all synthesized methodQueues, we have RCTNetworking which uses it internally as well as exposes its underlying execution queue. in this diff, i add a config that replaces that queue with one that is managed by the module itself instead of the one generated by the infra.
this is the last one!
Reviewed By: cipolleschi
Differential Revision: D50764523
fbshipit-source-id: 442f3a9f112409f2f05c69c0aa8391c04e8b0173
Summary:
Windows had to remove some previously suppressed compiler warnings and fork `ShadowNode.cpp` and `RawPropsParser.cpp` (See: https://github.com/microsoft/react-native-windows/issues/12300) to fix them. This PR adds the right data types and static casts to get rid of the compiler warnings.
## Changelog:
[GENERAL] [FIXED] - Fix windows 4018 and 4244 compiler warnings
Pull Request resolved: https://github.com/facebook/react-native/pull/41254
Test Plan: tested in RNW Repository
Reviewed By: rshest
Differential Revision: D50820705
Pulled By: rozele
fbshipit-source-id: fa61f7ca428d31fc6be56c80215246ee2bdfc67c
Summary:
Starting from Monday, Ruby jobs using Xcode 14.1 started failing on PRs but not on main.
While CircleCI is investigating why this is happening, we found a way to make sure that we can install Ruby even when the cache misses.
## Changelog:
[Internal] - Make sure we can install ruby 3.2.0 when rbenv cache misses.
Pull Request resolved: https://github.com/facebook/react-native/pull/41263
Test Plan: CircleCI is green
Reviewed By: blakef
Differential Revision: D50885897
Pulled By: cipolleschi
fbshipit-source-id: 9a452fd24d779cc14c86c7a8a4e3bf8ec62d0ceb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41280
This is probably just an old Flow artifact?
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D50879201
fbshipit-source-id: da7dec248e8dd50b8e824b09ed8f37294b69ed98
Summary:
This has been fully rolled out internally.
Changelog: [Fixed] Rolls out rounded view rendering improvements introduced in D39979567
Reviewed By: NickGerleman
Differential Revision: D50641814
fbshipit-source-id: 8e4dc470ca8716444c5bd88ae0e76754dc7acf37
Summary:
Instruction to install node on Debiam machine [has changed](https://github.com/nodesource/distributions#new-update-%EF%B8%8F) and the previous script cannot be used anymore.
This change updates it.
## Changelog:
[Internal] - Fix CI
Pull Request resolved: https://github.com/facebook/react-native/pull/41274
Test Plan: CircleCI is green
Reviewed By: rshest
Differential Revision: D50879481
Pulled By: cipolleschi
fbshipit-source-id: a1d2a3b06c42587e168d66746e2ccb2959c0f9e0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41270
`scheduleCellsToRenderUpdate()` is called in response to new measurements, or component changes. It has logic to decide whether to immediately calculate new state, or to defer it until a later batched period.
It will not immediately update state if we don't yet have measurements for cells, but this condition is after another which calculates priority, relying on these measurements. These are garbage if we don't yet have measurements, and trigger an invariant violation in horizontal RTL.
This switches around the conditions, to avoid offset resolution if we don't yet have valid measurements.
I suspect some "hiPri" renders where cells shift are bugged right now when we update state in response to content size change, before we have new corresponding cell layouts.
Changelog:
[General][Fixed] - Bail on hiPri render on missing layout data before checking priority
Reviewed By: yungsters
Differential Revision: D50791506
fbshipit-source-id: 8dbffc37edd2a42f7842c0090d344dcd6f3e3c6d
Summary:
As per https://github.com/facebook/react-native/issues/41079, we're outputting ASCII encoded data URIs to `FileReader.readAsDataURL` due to lack of native `ArrayBuffer` support and unclear use of encoding to align with web. I'll revisit this at a later point with a better testing strategy once we have a good idea of how this should behave internally.
Aside from purely reverting https://github.com/facebook/react-native/issues/39276, I've kept the use of `ArrayBuffer.isView(part)` to the previous `part instanceof global.ArrayBufferView` since it is more correct.
## Changelog:
[INTERNAL] [REMOVED] - Revert Blob from ArrayBuffer
Pull Request resolved: https://github.com/facebook/react-native/pull/41170
Test Plan:
Run the following at the project root to selectively test changes:
`jest packages/react-native/Libraries/Blob`
Reviewed By: cipolleschi
Differential Revision: D50601036
Pulled By: dmytrorykun
fbshipit-source-id: 0ef5c960c253db255c2f8532ea1f44111093706c
Summary:
Further propagating extension to the Android choreographer, now allowing to override it from the perspective of ReactNativeHost/ReactInstanceManager(Builder).
Changelog:
[Android][Added] ReactChoreographer can now use an implementation substitution instead of relying on android.view.Choreographer directly.
Reviewed By: javache
Differential Revision: D50827973
fbshipit-source-id: 42efaa3ece2c2b45fe4ee04a4bbc87c9d59132c8
Summary:
We want to have an extension point for choreographer, so we can override default behavior and have either rate-limiting, or testing or other form of manual control.
For all those cases allow substitution of choreographer that ReactChoreographer would use by default with a custom one.
Changelog:
[Android][Added] ReactChoreographer can now use an implementation substitution instead of relying on android.view.Choreographer directly.
Reviewed By: javache
Differential Revision: D50827975
fbshipit-source-id: 0fd78e1f4f96ffd832e5d8cdc6c805f9a9e272cf
Summary:
After disabling the E2E tests, we lost a test that was verifying that Hermes works well with the latest version of React Native for iOS
This change introduce this test back in GH actions
## Changelog:
[Internal] Add tests for Hermes-Xcode integration to GH Actions
Pull Request resolved: https://github.com/facebook/react-native/pull/41187
Test Plan: CI is green 🤞
Reviewed By: NickGerleman
Differential Revision: D50737860
Pulled By: cipolleschi
fbshipit-source-id: f4bc09be879af7aba0ca42f1b7e407a5d5dc0986
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41260
This was introduced some experiments which are no longer relevant.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D50736166
fbshipit-source-id: 7c9ff571112127e6a9e317113c05c30483626076
Summary:
The current ReactModalHostView implementation incorrectly applies system bar appearances by providing the wrong mask to the `setSystemBarsAppearance` method invocation. Per [this issue comment](https://github.com/facebook/react-native/issues/34350#issuecomment-1760339877), jaydonlau correctly identified that when the status bar is set to `light-content` (light icons, dark background), the function is called with both a `0` appearance and `0` mask, which should instead be provided with the `APPEARANCE_LIGHT_STATUS_BARS` mask.
The first pass at this PR attempted to pull out the entire appearance from the activity, compare it against the dialog's appearance, and only use a mask of differing bits (see the `appearanceMask` variable). However, if the `android:windowLightStatusBar` attribute is ever set to true, this does not impact the appearance of the status bar but rather the system UI visibility. As a result, the derived mask from system bars appearance would be 0 since both the activity and dialog would have appearances of 0.
Rather than try and "future-proof" this implementation for other uses of system bar appearance, this change is directed only at updating the `APPEARANCE_LIGHT_STATUS_BARS` bit in the dialog's system bar appearance. The only other native code that touches status bars is the `StatusBarModule` and that only touches this flag.
This is a follow-up to https://github.com/facebook/react-native/issues/34899.
## 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] - Fixed an issue where the status bar colors would not match when opening modals
Pull Request resolved: https://github.com/facebook/react-native/pull/40979
Test Plan:
First test:
- Replace the `RNTesterAppShared` implementation with the implementation from [this Expo snack](https://snack.expo.dev/abbondanzo/status-bar-tester)
- Toggle the status bar to show dark icons, open the modal and ensure that dark icons are displayed
- Toggle the status bar to show light icons, open the modal and ensure that light icons are displayed
Second test:
- Set the `android:windowLightStatusBar` attribute to true in the `AppTheme`
- Follow the steps from the First test above, guaranteeing that status bar appearance overrides the theme
Reviewed By: NickGerleman
Differential Revision: D50329714
Pulled By: luluwu2032
fbshipit-source-id: 26ecaca05f8e00a52e13767e468b552ac167fc98
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41239
The experiment this covered was backed out and never re-landed (see D40387938).
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D50641810
fbshipit-source-id: 6f92c46a37a07029ef2aa56ebf9b69e0503bb2cd
Summary:
Hermes supports arrows. I assume the only reason the transform wasn't dropped is due to the scary TODO.
Originally, the arrow transform was conditional like this:
```js
if (isNull || src.indexOf('=>') !== -1) {
extraPlugins.push(es2015ArrowFunctions);
}
```
I made it unconditional in https://github.com/facebook/metro/commit/beb3d1ab5dc46a856e0810f3c0787f8885c8f654 (D15947985) to work around an issue where React Refresh Babel plugin emitted arrow functions. However, I fixed that plugin to _not_ emit arrow functions a long time ago in https://github.com/facebook/react/pull/15956. So this TODO is effectively solved, and has been, for ages.
In this commit, we:
- Skip the transform for Hermes altogether
- For non-Hermes, revert to the old conditional behavior
Possible alternatives:
- We could skip it for Hermes but apply unconditionally otherwise (a bit simpler)
- Or, if all target non-Hermes runtimes already support it natively, we could completely remove it
## Changelog:
[GENERAL] [CHANGED] - Apply Babel arrow transform only on non-Hermes
Pull Request resolved: https://github.com/facebook/react-native/pull/41253
Test Plan: Run fbsource tests (that's for you, not for me :)
Reviewed By: NickGerleman
Differential Revision: D50818568
Pulled By: robhogan
fbshipit-source-id: ad96540bb7778792d38a6ddec06999d2acf620d0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41095
I'm deleting this class becase ReactInstancePackage has been deprecated since 2018 and I analyzed internal meta codebase and OSS codebase and it seems it's not being used.
changelog: [Android][Breaking] Delete ReactInstancePackage
Reviewed By: philIip
Differential Revision: D50338299
fbshipit-source-id: 2824e58ff3bf9d17b605239dd9c9bea0adba93b8
Summary:
changelog: [internal]
It is redundant to schedule frame callback if there is no work to do. Let's remove it.
Reviewed By: javache
Differential Revision: D50494928
fbshipit-source-id: fce7d9a84eb2486dc01d4bff98540c128b91969d
Summary:
changelog: [internal]
For constrained environments, we want to lower cpu usage of RN when the app is idle. `UIViewOperationQueue` and `EventDispatcherImpl` are not used in Fabric and therefore they do not need to run on each frame.
Reviewed By: javache
Differential Revision: D50741161
fbshipit-source-id: aa605893f1c8a4ac97a49bb7a6de2e2637a0832e
Summary:
When opening `RCTRedBox` on an iPad (and also visionOS) there was an issue with buttons width going out of screen. When changing screen orientation, RedBox wasn't recalculating view positions.
**Root cause**: Getting frame of root view to display this modal and basing all calculations on it.
**Solution**: Use Auto Layout to build UI that responds to orientation changes and device specific modal presentation.
I've also tested it with adding custom buttons to RedBox and it works properly.
## Changelog:
[IOS] [FIXED] - adjust RCTRedBox to work for iPad and support orientation changes
Pull Request resolved: https://github.com/facebook/react-native/pull/41217
Test Plan:
Launch the app without metro running and check out RedBox that's shown there. Also change screen orientation to see proper recalculation of view positions.
### Before
https://github.com/facebook/react-native/assets/52801365/892dcfe7-246f-4f36-be37-12c139c207ac
### After
https://github.com/facebook/react-native/assets/52801365/dfd0c3d8-5997-462d-97ec-dcc3de452e26
Reviewed By: GijsWeterings
Differential Revision: D50734569
Pulled By: javache
fbshipit-source-id: 51b854a47caf90ae46fcd32c4adcc64ec2ceb63f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41206
Root cause: Currently Bridgeless only support FabricUIManager and the legacy UIManager is not supported
Next steps: check for other places where legacy UIManager is not supported
Changelog:
[Android][Changed] - Bridgeless: Add support for legacy UIManager in UIManagerHelper
Reviewed By: cortinico
Differential Revision: D50694805
fbshipit-source-id: 93eba1eb3106d4aa8dccf8be761d97ced778cf67
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41096
LazyReactPackage.getReactModuleInfoProviderViaReflection was deprecated in 0.72, I'm just deleting it.
There are no usages internally or externally
changelog: [Android][Breaking] Delete deprecated method LazyReactPackage.getReactModuleInfoProviderViaReflection
Reviewed By: arushikesarwani94
Differential Revision: D50338302
fbshipit-source-id: 02fe91d5da8d6f01b8d3852aced90034a1a5c8e8
Summary:
The goal of this PR is to migrate deprecated `UIMenuController` to `UIEditMenuInteraction`. `UIMenuController` has been deprecated in iOS 16 and for that reason it's not available for VisionOS.
## Recording
https://github.com/facebook/react-native/assets/52801365/fed994be-d444-462a-9ed0-39b50531425d
bypass-github-export-checks
## 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] [CHANGED] - Migrate RCTTextView to UIEditMenuInteraction
Pull Request resolved: https://github.com/facebook/react-native/pull/41125
Test Plan: Launch RNTester and check for "Selectable Text" example and check that it works for iOS 16/17.
Reviewed By: javache
Differential Revision: D50551016
Pulled By: cipolleschi
fbshipit-source-id: 558ecc5a04a5daa9c4360fabddcab28fba72a323
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41219
Bump to the latest Metro release. This includes minor breaking changes to Metro subpackages that should *not* be visible to RN users.
Metro release notes: https://github.com/facebook/metro/releases/tag/v0.80.0
## Moving to unpinned versioning
Metro is a multi-package project, and not pinning to an exact version means multiple versions of `metro*` packages may appear in an RN project.
This isn't unusual in the NPM ecosystem and *shouldn't* be a problem, but historically has caused issues (eg https://github.com/facebook/react-native/issues/34714, https://github.com/facebook/metro/issues/1017). The root cause of all of these issues, as far as we know, was fixed in https://github.com/facebook/metro/commit/6d46078e74ae9a43aa90bed46dbd6610e2696cd0, a bug where Node hierarchical resolution was effectively sidestepped via a relative worker path, resulting in a mismatch between transformer and host process.
In addition, the fact that `react-refresh`, `metro-react-native-babel-transformer` and `metro-react-native-babel-preset` are now fully moved into the `react-native/` scope and versioned with React Native means there are no circular dependencies between React Native and Metro, explicit or implicit, and we're much more clearly decoupled.
So, we're moving to caret versioning to allow React Native users to pick up Metro fixes and features without requiring React Native releases and user upgrades.
Changelog:
[General][Changed] - Update Metro to ^v0.80.0, stop pinning to an exact version
Reviewed By: GijsWeterings
Differential Revision: D50731999
fbshipit-source-id: 57b07bf73c0b31f392c4d36376ca48b48a8bd598
Summary:
This should fix
https://github.com/facebook/react-native/issues/37905#issuecomment-1774851214
When working on react-native-fast-image, we realized that the interop layer does not work for components where the exported name is different from the iOS class.
To fix this, we can use the Bridge to retrieve the actual view manager, given the component name.
This solution should be much more robust than making assumptions on the ViewManager name, given the ComponentName.
On top of that, we realized tha the interop layer was not calling `didSetProps` after setting the props, so we are invoking that.
bypass-github-export-checks
## Changelog:
[iOS][Fixed] - Add support for Components with custom names in the interop layer.
Pull Request resolved: https://github.com/facebook/react-native/pull/41207
Test Plan: Tested locally on an app created in 0.72 and 0.73 in Bridge and Bridgeless mode.
Reviewed By: cortinico
Differential Revision: D50698172
Pulled By: cipolleschi
fbshipit-source-id: 49aee905418515b0204febbbe6a67c0114f37029
Summary:
While releasing RN 0.73.0-RC3, we relaized that the e2e test script was bugged for Android when used to test RNTestProject with the `-c` option.
There were 2 problems:
- The downloaded maven-local was not actually used because it doesn't work with a zip. (We were always downloading a version from Maven)
- The versions of React Native between maven-local and the locally packaged React Native were different.
This change fixes the script by:
- Downloading maven-local
- Unzipping maven-local and passing the new folder to the Android app
- Downloading the React Native version that has been packaged in CI
By unzipping maven-local and using the unzipped folder, we make sure that Android is actually using the local repository.
By downloading both the packaged react native and the maven-local from the same CI workflow, we ensure that the versions are aligned.
This also speeds-up further the Android testing.
While running this change, we also moved the `pod install` step inside the `if (iOS)` branch, so we do not install Cocoapods if we need to test
Android.
## Changelog:
[Internal] - Fix Android E2E test script when downloading artefacts from CI
Pull Request resolved: https://github.com/facebook/react-native/pull/41172
Test Plan: Tested locally on both main and 0.73-stable, on both Android and iOS
Reviewed By: cortinico
Differential Revision: D50651448
Pulled By: cipolleschi
fbshipit-source-id: 70a9ed19072119d19c5388e8a4309d7333a08e13
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41049
Similarly to D50319914, simplify the careful logic we have with CallbackWrapper and RCTBlockGuard and instead rely on bridging's `AsyncCallback` so safely handle jsi::Function for us.
The underlying issue causing memory corruption has been addressed in D50286876.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D50319913
fbshipit-source-id: e422518b9a647b7daa0b75eae529a8b04ce1c22b
Summary:
Changelog: [Internal]
in the future, all void native module methods will execute synchronously.
currently, many modules override the methodQueue selector to return the main queue so their async methods will be executed on the main thread by our infra. now that void methods are executing synchronously, this override will be ignored, thus causing unpredictable behavior for those methods that do depend on being run on main thread to behave correctly.
the migration in this stack will prevent bugs caused by this behavioral change by explicitly dispatching execution onto the main thread.
Reviewed By: mdvacca
Differential Revision: D50635827
fbshipit-source-id: 384ee2f0237a49dc4f50e4171092c864f2f55327
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41165
Currently Bridgeless forces lazy view manager loading, each ReactPackage must implement ```ViewManagerOnDemandReactPackage```. This can bring extra hassle for OSS users in migration.
This diff add backward compatibility by falling back to eager view manage loading, after detecting any ReactPackage of current application NOT a subclass of ```ViewManagerOnDemandReactPackage```.
Changelog:
[Android][Changed] - Fall back to eager view manage loading for Bridgeless
Reviewed By: cortinico
Differential Revision: D50556405
fbshipit-source-id: 32357d1934068d0fa0f2b7cb46b54f2f41b3e24f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41175
This will make sure that if you specify a maven local folder with `react.internal.mavenLocalRepo`
you're not attempting to fetch artifacts from Maven Central.
Changelog:
[Internal] [Changed] - Do not attempt to query Maven Central if project has react.internal.mavenLocalRepo
ignored-github-export-checks
bypass-github-export-checks
Reviewed By: mdvacca
Differential Revision: D50600815
fbshipit-source-id: f429c2ae9d7204e4aa2cb29357983c0dc3a1aab6
Summary:
Since yesterday, Chocolatey is pulling in Node 20 rather than Node 18 for tests.
It ends up that mock-fs is not working with Node 20, so, for the time being, we are going to keep 18.
## Changelog:
[Internal] - Use node 18 instead of 20 for Test Windows
Pull Request resolved: https://github.com/facebook/react-native/pull/41200
Test Plan: CircleCI is green
Reviewed By: hoxyq
Differential Revision: D50690846
Pulled By: cipolleschi
fbshipit-source-id: 505b8e8f90b46019d8e582cc8dad2e2d1edffd54
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41197
As part of https://github.com/facebook/react-native/pull/40775 we marked TurboReactPackage as DeprecatedInNewArchitecture introducing the new class BaseReactPackage.
In this diff I'm replacing usages of TurboReactPackage by BaseReactPackage to make sure new usages of BaseReactPackage work as expected.
changelog: [internal] internal
Reviewed By: arushikesarwani94
Differential Revision: D50611382
fbshipit-source-id: 867c5949463cb5537960a346099e687379baeb73
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41195
Changelog: [Internal]
in PR 41183 , i introduced a new method to retrieve the RCTNetworker's execution queue. i missed updating a few of these asserts
Reviewed By: fkgozali
Differential Revision: D50680549
fbshipit-source-id: ac88382e13ade4434abbb7d6cbca168117df492e
Summary:
As stated here https://github.com/react-native-community/discussions-and-proposals/issues/671 React Native 0.73 will depend on Android Gradle Plugin (AGP) 8.x which requires all libraries to specify a namespace in their build.gradle file, even though this issue was raised many months ago, lots of libraries have not been updated and don't specify a `namespace` inside their build.gradle files
## Changelog:
[ANDROID] [CHANGED] - Ensure namespace is specified for all the 3rd party libraries
Pull Request resolved: https://github.com/facebook/react-native/pull/41085
Test Plan:
Run RNGP tests and test building rn-tester after doing the following procedure
1. Remove `namespace "com.facebook.react"` from react-native/packages/react-native/ReactAndroid/build.gradle
2. Add `package="com.facebook.react"` to react-native/packages/react-native/ReactAndroid/src/main/AndroidManifest.xml
3. Build rn-tester
Also tested this using [BareExpo](https://github.com/expo/expo/tree/main/apps/bare-expo) with AGP 8.1.1 and all libraries that were missing the `namespace` compiled correctly
Reviewed By: cipolleschi
Differential Revision: D50556667
Pulled By: cortinico
fbshipit-source-id: 3d75ec0a8b82427ff0ede89aa7bc58b28b288945
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41192
We currently don't have visibility on what the native module thread is doing when it's busy (on Android). This adds Systrace blocks to at least know the native module and the method we're running there.
Changelog: [internal]
Reviewed By: ryancat
Differential Revision: D50645557
fbshipit-source-id: 5cb6a7f1166bfd50c28f0aba634552c35a34c941
Summary:
This PR removes some unused RNTester assets that were left during removal of slider and removal of Bookmarks feature in RNTester.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [REMOVED] - Removed unused images from RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/41186
Test Plan: Not needed
Reviewed By: shwanton
Differential Revision: D50649244
Pulled By: cortinico
fbshipit-source-id: 5203b446108c04619c8cc57ec56f2d5e8455df2b
Summary:
Bumping Fresco to the latest version (3.1.3)
## Changelog:
[ANDROID] [FIXED] - Bump Fresco to 3.1.3
Pull Request resolved: https://github.com/facebook/react-native/pull/41190
Test Plan: CI Should be green
Reviewed By: lunaleaps
Differential Revision: D50650250
Pulled By: cortinico
fbshipit-source-id: ab8151e882300849ef27ec14c4adc77fdf8503e6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41191
In dev mode, display a Redbox for the first fatal error during RN initialization. So if the first fatal error is Metro not connected that will be displayed via Redbox.
Changelog:
[Android][Changed] - Fix RNTester not showing Redbox when Metro is not connected
Reviewed By: cortinico
Differential Revision: D50600631
fbshipit-source-id: f269091c1745a76b49e72d9051c4836a39fded12
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41183
Changelog: [Internal]
in my quest to get rid of all synthesized methodQueues, we have RCTNetworking which uses it internally as well as exposes its underlying execution queue. in this diff, i add a config that replaces that queue with one that is managed by the module itself instead of the one generated by the infra.
this is the last one!
Reviewed By: cipolleschi
Differential Revision: D50588308
fbshipit-source-id: 98fa54a2b5851898a4514b1fb7feaf586cfdbb0c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41182
Changelog: [Internal]
in my quest to get rid of all synthesized methodQueues, we have RCTBlobManager which exposes its underlying execution queue. in this diff, i add a config that replaces that queue with one that is managed by the module itself instead of the one generated by the infra.
Reviewed By: cipolleschi
Differential Revision: D50587693
fbshipit-source-id: 993a13c617afe48c3989d8cd5ad5fbda050603f4
Summary:
We don't need to get oldChildShadowView when we handle the insert mount. So we can remove it.
## Changelog:
[IOS] [CHANGED] - Fabric: clean up oldChildShadowView when handling Insert mount
Pull Request resolved: https://github.com/facebook/react-native/pull/41155
Test Plan: None.
Reviewed By: sammy-SC
Differential Revision: D50554037
Pulled By: javache
fbshipit-source-id: 3250b6bbe119d800f05f39f790dc6949357d4f27
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41181
The goal of this refactor is to ensure that LazyTurboModuleManagerDelegate doesn't hold references to TurboModules.
EveryTime that LazyTurboModuleManagerDelegate.getModule is called, it will create a new TurboModule. This 'should' be fine because the references to already created TurboModules are held on
TurboModuleManager.mModuleHolders.
As part of this diff I'm also throwing an exception when the method LazyTurboModuleManagerDelegate.unstable_isModuleRegistered is called. This should be fine because I ensured that
"LazyTurboModuleManagerDelegate.unstable_isModuleRegistered' is not called for this experiment.
changelog: [internal] internal
Reviewed By: RSNara
Differential Revision: D50610163
fbshipit-source-id: 8d9d808b9b637c8e9bc3fd9c2502793161cac42c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41178
Changelog: [Internal]
in my quest to get rid of all synthesized `methodQueue`s, we have `RCTImageStoreManager` which uses this throughout. in this diff, i add a config that uses a queue that is managed by the module itself instead of the one generated by the infra.
Reviewed By: cipolleschi
Differential Revision: D50585904
fbshipit-source-id: a33f8a4844fe3ef861bf1c3a7b87a9ed4b24d13f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41157
This is internal until we're ready to test this outside of Meta.
Changelog: [internal]
## Context
In the new architecture, every time we commit a new tree in React we send a transaction to the host platform to make all the necessary mutations in the underlying native views.
This can be bad for user experience, because the user might see quick changes to the UI in succession for related changes. It also breaks the semantics of things like layout effects and ref callbacks, which are core to the React programming model and should work across all platforms.
The main semantic that this behavior breaks in React Native is that layout effects are supposed to be blocking for paint. That means that any state updates (or UI mutations) done in layout effects should be applied to the UI atomically with the original changes that triggered them, so users see a single update where the final state is applied. This doesn't work in React Native as none of the commits coming from React are blocked waiting for effects, and instead they're all mounted/applied as they come.
This isn't only a problem for React, but also for future Web-like APIs that rely on microtasks. Those are also assumed to block paint in browsers, and we don't support that behavior either.
## Changes
Now that we're adding support for a well-defined event loop in React Native, we can add a new step to notify UI changes to the host platform in specific points in time, after macrotasks and microtasks are done (the "Update the rendering" step defined on the [Web specification](https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model)).
This implements that step in the new `RuntimeScheduler`. This works by batching all the notifications from the `UIManager` to `MountingCoordinator` and calling all those methods from `RuntimeScheduler` at the right time.
There will be cases where the notifications will be to mount the same tree multiple times, but the mounting coordinator already handles this correctly (would mount the last version of the tree for each surface ID the first time, and be a no-op the other times).
This change will reduce the amount of mount operations we do on the main thread, which means that we could potentially remove the push model from Android if performance is acceptable with this.
NOTE: This only works with the modern runtime scheduler, and only makes sense when used with microtasks enabled too and background executor disabled.
Reviewed By: javache
Differential Revision: D49536327
fbshipit-source-id: fabcbd6a6fb89a851f4c2b4ebefbb330a6ad3a18
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41168
This API is just used to send callbacks from C++ to Java and is completely internal.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D50226596
fbshipit-source-id: f521ae1f35cc31e8e8aeab66b41fd3e95d9467cb
Summary:
Currently `autoscrollToTopThreshold` does not work correctly, it will scroll to top even when the scroll position is past the `autoscrollToTopThreshold` value.
The value of x/y is taken before we adjust the scroll position so we do not need to subtract the delta.
Note that this was already fixed when I ported this code to fabric, so this fix is only needed in the old arch code.
bypass-github-export-checks
## Changelog:
[IOS] [FIXED] - Fix autoscrollToTopThreshold on iOS old arch
Pull Request resolved: https://github.com/facebook/react-native/pull/38245
Test Plan:
In RNTester example, threshold is set to 10, so it should not scroll to top if we are further than 10px from the top of the list.
Before:
https://github.com/facebook/react-native/assets/2677334/13723787-1bc4-4263-9bcb-91ddf7454de3
After:
https://github.com/facebook/react-native/assets/2677334/a8cfdaac-59fc-40de-970a-ff992366e25f
Reviewed By: rshest
Differential Revision: D50447644
Pulled By: cipolleschi
fbshipit-source-id: b21f1836db293120a7a795c8f8f6dd54887495a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41148
changelog: [internal]
RN moved away from using folly::hash. These are a few places missed during the migration.
Reviewed By: cipolleschi
Differential Revision: D50540176
fbshipit-source-id: 497c13032c23c5b2dfab9e3d6f226f596b90761e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41101
The goal of this diff is to move NativeMethod out of NativeModule, in this case I'm moving it to JavaModuleWrapper.
We could also do a bigger refactor and just remove it, but since the usages of NativeMethod are not part of public API and these classes will dissapear in the new architecture, I opted for reducing risk a do a minor refactor.
Why I'm doing this: because I'm migrating NativeModule to kotlin and don't want to expose NativeMethod in the kotlin public API
This is not a breakage of compatibility because NativeMethod has package visibility.
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: luluwu2032
Differential Revision: D50294833
fbshipit-source-id: 1c7933e666c24df662649a01e1251c74414b5345
Summary:
X-link: https://github.com/facebook/yoga/pull/1434
Pull Request resolved: https://github.com/facebook/react-native/pull/41130
I will use this errata to gate my changes that actually make position: static behave like the web. We have future plans to make position: relative the default again but users could still have declared certain nodes as position: static, so I think this is needed regardless.
Reviewed By: NickGerleman
Differential Revision: D50506915
fbshipit-source-id: b0d9e6883167de6ff002352c9288053324464cb9
Summary:
I wanted to add a new iOS prop, but noticed this, got distracted, fixed it up, and here we are 😅
There are a few Android/iOS specific props that have been added to `ViewProps` instead of `ViewPropsAndroid` or `ViewPropsIOS`. Let's just move around some props to clean that up, in both Flow and TypeScript.Specifically:
- Moved `needsOffscreenAlphaCompositing` to shared as it's implemented on both iOS and Android
- Moved `accessibilityLiveRegion` / `aria-live` / `accesbilityLabelledBy` / `aria-labelledBy` to Android
- While at it, I also updated the comment definition so that `accessibilityLabelledBy` and `aria-labelledBy` because it just maps to the same thing in native code.
- Moved `accessibilityLanguage` to iOS only
## Changelog:
[GENERAL] [FIXED] - Move iOS/Android specific prop types appropriate types
Pull Request resolved: https://github.com/facebook/react-native/pull/40978
Test Plan: CI should pass
Reviewed By: NickGerleman
Differential Revision: D50372564
Pulled By: vincentriemer
fbshipit-source-id: ba947c15ffdd4d84d3424b4274afdcbf130adad4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41162
"The C++ standard forbids containers of const elements because allocator<const T> is ill-formed."
We have a few other callsites for std::vector<const ...>, but the const values are always const pointers, which I guess are okay?
Suffice to say, this doesn't compile with Microsoft STL headers unless you remove const.
## Changelog
[Internal]
Reviewed By: javache
Differential Revision: D50563174
fbshipit-source-id: 96053baedc41237d8d27a1e01ac94ce5abd6c768
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41136
Changelog: [iOS][Breaking] You cannot call methodQueue on RCTHTTPRequestHandler
the `synthesize methodQueue` API is confusing, it looks like an API only for use within native module implementation, but it's actually needed to create a selector that corresponds to the property declared in the `RCTBridgeModule` public protocol.
no one is using the `methodQueue` on `RCTHTTPRequestHandler`, so let's get rid of the public access to it.
Reviewed By: javache, cipolleschi
Differential Revision: D50525900
fbshipit-source-id: f83738491d0eadc71a6dc3194ee16fe7c8748263
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41090
This propagates to enable the use of microtasks in the React reconciler, Runtime Scheduler and Hermes.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D50177355
fbshipit-source-id: 6cf23cf72b63d19f50453d3e4cc4ac1b056dbd92
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41084
Adds support for executing microtasks in `RuntimeScheduler`, the same way we did in `JSIExecutor` before (removed in D49536251 / https://github.com/facebook/react-native/pull/40870) but now after each actual task in the scheduler.
When we use microtasks in the scheduler, we ignore calls to execute expired tasks (which was used to call "React Native microtasks" that we had before). Those should now be regular microtasks in the runtime.
This is gated behind a feature flag until we've tested this broadly.
This is going to be tested in Hermes but we need to add support for microtasks in JSC (which has a no-op in its JSI interface).
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D49536262
fbshipit-source-id: 8f7ce54c266d1f25312a641abc4ef073d019281f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41082
We're testing a method to access `ReactNativeConfig` without a dependency on native modules, so we can access it before that infra is initialized in places like Hermes or RuntimeScheduler.
When we're in that variant, this passes the configuration to Hermes so we can use it to set flags in the runtime (like enabling microtasks in D50177355).
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D50450488
fbshipit-source-id: 77f0369f93bb7175c569d51b0569669552a13acf
Summary:
When creating the react root for Logbox, we do not pass the concurrentRoot option leading to a warning because it is using Fabric.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D50558855
fbshipit-source-id: ed4399293ca4001bf4e0e059a0eb73481bcf4832
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41158
This feature flag was just a killswitch for OSS. As we don't need it anymore, I'm removing it.
I've also discussed with Expo so they remove any usages of this in their codebase.
Changelog:
[Internal] [Changed] - Remove unnecessary unstable_useRuntimeSchedulerAlways Feature Flag
Reviewed By: rubennorte
Differential Revision: D50554334
fbshipit-source-id: b2346654ad543c1350f2f2cae078900abf39d41c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39540
This simplifies the use of Codegen when creating dev builds of `rn-tester` in the monorepo. It now runs from source for this internal scenario, and this package is now built using the shared monorepo build setup.
Changes:
- Migrate `packages/react-native-codegen` to the shared `yarn build` setup.
- Update package to use `"exports"` field and wrap entry point modules with `babel-register` (NOTE: This is only required for each entry point internally used in the monorepo).
- Fixup small Flow syntax quirks that fail under `hermes-parser`.
- Remove `BuildCodegenCLITask` task from Android build.
- Remove Codegen `build.sh` call from iOS build, use `require.resolve` for `combine-js-to-schema-cli.js` entry point.
Externally significant FYIs:
- `react-native/codegen` is converted to use the `"exports"` field — it should export all `.js` files, as before.
- `codegenPath` is now ignored and marked as deprecated on `ReactExtensions.kt`.
NOTE: TypeScript auto-generation is not yet enabled on this package, since it uses CommonJS `module.exports` syntax (unsupported by `flow-api-translator`).
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D49370200
fbshipit-source-id: 992913155169912ea1a3cb24cb26efbd3f783058
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41159
Changelog: [Internal]
Cleanup from D48966244. The deprecated `jsinspector` files are no longer used by any code in either fbsource or `react-native`.
Reviewed By: hoxyq
Differential Revision: D50530796
fbshipit-source-id: b539b097cb6caf6c50a482fa93bf5d7886e76e52
Summary:
E2E tests in OSS are expensive and flaky.
They already prevented some broken changes to land on main, but as of today:
- they are always green, so they are not bloking
- nobody is looking at the reporting job
- the reporting job takes a lot of time to run and prevent other useful signals to be available soon
- it is expensive
So we decide to disable them for the time being, while we iterate on those with Callstack and MSFT.
## Changelog:
[Internal] - Disable E2E tests
Pull Request resolved: https://github.com/facebook/react-native/pull/41153
Test Plan: CircleCI stays green
Reviewed By: cortinico
Differential Revision: D50552818
Pulled By: cipolleschi
fbshipit-source-id: 7160a8074492c3c9a55485d8a17a6883eb4b35b5
Summary:
This is a small fix to update line number pointing to `fabric_enabled` line number
## Changelog
[Internal] [Fixed] - Update line number in RNTester README
Pull Request resolved: https://github.com/facebook/react-native/pull/41145
Test Plan: Not needed
Reviewed By: rshest
Differential Revision: D50551044
Pulled By: cipolleschi
fbshipit-source-id: bed88c54f3b2718ca4cdb08e66fed2d7e4cac7ab
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41081
It turns out that Bridgeless for RN-Tester release is still broken.
This fixes it by making sure we actually `DoNotStrip` the missing constructor
Changelog:
[Android] [Fixed] - Fix crash with `java.lang.NoSuchMethodError` for Bridgeless
Reviewed By: RSNara
Differential Revision: D50455967
fbshipit-source-id: eae971fceeb863d8a400e9de1d2467637d59d2b0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41152
Building on byCedric's approach in https://github.com/facebook/metro/pull/991, and on D49954920, this diff passes stable, unique *logical device IDs* to the debugger connection infrastructure from Android and iOS.
See D49954920 for the precise stability and uniqueness requirements that these IDs meet.
Changelog:
[Changed][General] - Automatically reconnect to an existing debugger session on relaunching the app
Reviewed By: huntie
Differential Revision: D49954919
fbshipit-source-id: d4d918f0cbfd9df426e888845817e00410efb9d3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41154
Pull Request resolved: https://github.com/facebook/react-native/pull/41080
Building on byCedric's approach in https://github.com/facebook/metro/pull/991, adds support for passing a `device=...` argument to `/open-debugger` for more precise targeting.
Changelog: [Internal]
---
## Note on what "device" means in this context
In `dev-middleware` / `inspector-proxy`, "device" is something of a misnomer. It refers to a *logical device* containing one or more *pages*. In React Native, each app process forms its own logical device in which individual VMs register themselves as pages. An instance of `inspector-proxy` connects one or more *debuggers* (frontends) to one or more logical devices (one frontend to one page on one device).
The intent of the logical device ID is to help with target discovery and especially *re*discovery - to reduce the number of times users need to explicitly close and restart the debugger frontend (e.g. after an app crash).
If provided, the logical device ID:
1. SHOULD be stable for the current combination of physical device (or emulator instance) and app.
2. SHOULD be stable across installs/launches of the same app on the same device (or emulator instance), though it MAY be user-resettable (so as to not require any special privacy permissions).
3. MUST be unique across different apps on the same physical device (or emulator).
4. MUST be unique across physical devices (or emulators).
5. MUST be unique for each concurrent *instance* of the same app on the same physical device (or emulator).
NOTE: The uniqueness requirements are stronger (MUST) than the stability requirements (SHOULD). In particular, on platforms that allow multiple instances of the same app to run concurrently, requirements 1 and/or 2 MAY be violated in order to meet requirement 5. This will be relevant, for example, on desktop platforms.
In an upcoming diff, we will pass device IDs meeting these criteria from both iOS and Android.
Reviewed By: huntie, blakef
Differential Revision: D49954920
fbshipit-source-id: 45f2b50765dece34cbb93fa32abcdf3b0522391c
Summary:
App can be submitted to the app store by using Xcode 14.1 as min Xcode version.
Right now we are testing everything against the latests Xcode, but it would be good to have some tests to check that we don't break the flow for people stuck on older Xcodes.
We already had issues like these in the past, unfortunately.
Plus, we are making some changes using C++20 which we don't know whether they are properly supported by older versions of Xcode.
This change should give us confidence on those changes too.
## Changelog:
[Internal] - Use Xcode 14.1 for some tests
Pull Request resolved: https://github.com/facebook/react-native/pull/39602
Test Plan: CircleCI is green
Reviewed By: NickGerleman
Differential Revision: D49540292
Pulled By: cipolleschi
fbshipit-source-id: 71c07293598fd5b1f73f6d7d9425f385aa12fc4e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41113
changelog: [internal]
We must prevent VirtualizedList._onContentSizeChange from being triggered by a conflicting bubbling onContentSizeChange event.
For TextInput, we change the event onContentSizeChange from bubbling to direct (https://github.com/facebook/react-native/commit/744fb4a0d23d15a40cd591e31f6c0f6cb3a7f06b). To make this safer, we need to filter out any `onContentSizeChange` event since we can't control 3rd party components from dispatching onContentSizeChange as bubbling event.
Reviewed By: NickGerleman
Differential Revision: D50451232
fbshipit-source-id: b7a446e4efc9c45024d37f35cb53f2fcbb28799f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41114
changelog: [internal]
MountItemDispatcher integrates with FabricUIManager in a non-obvious ways. This diff documents some of that.
Reviewed By: NickGerleman
Differential Revision: D50494929
fbshipit-source-id: ed3c1748765ca4590035be20f045ecfb14af86c2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41043
Changelog: [Internal]
in this change, we create an config pipeline to set `_enableSharedModuleQueue` in TMM
Reviewed By: cipolleschi
Differential Revision: D50398636
fbshipit-source-id: cd8c210ad2ae4774ceb10130a8b80e500d17986a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41042
Changelog: [Internal]
currently, each native module creates a new module queue if `methodQueue` is not overridden in the native module.
we want to see if we can use a single execution queue for a few reasons:
- parity with android's queue model
- performance: creating so many queues... for what? the overhead of this feels like it exceeds any potential benefit
- set us up to remove the assocs from the module to the method queue, which will allow us to deprecate `synthesize methodQueue` and `-(dispatch_queue_t)moduleQueue` API.
in this QE, we just start with replacing the KVO assoc'd queue with the shared module queue.
Reviewed By: cipolleschi
Differential Revision: D50398635
fbshipit-source-id: 0b194a5ae5269e843c7c537a973ee1d345ce1df4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41086
In this diff I'm fixing the lookup of ReactModuleInfoProvider instance for CoreReactPackage. It is searching for the wrong class.
changelog: [internal] internal
Reviewed By: RSNara
Differential Revision: D50338304
fbshipit-source-id: 840d1d018cc0f9df8a64fd09a851d8a87f5a1f15
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41083
All callsites for `useImperativeHandle` have been removed, so we can also remove the import from react.
## Changelog
[General][Internal]
Reviewed By: mogers
Differential Revision: D50457268
fbshipit-source-id: befa08cf7173a8d02800fa2447dbcd8a9ce874de
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41039
## Changelog:
[iOS][Breaking] - repeatInterval is deprecated in PushNotificationIOS. Use fireDate and the new fireIntervalSeconds.
Reviewed By: philIip
Differential Revision: D50277316
fbshipit-source-id: ddcc2d2fc9d89d2bacac296848109e98c95c0107
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41118
Updates the release process and guidance for `debugger-frontend`, now that the source [facebookexperimental/rn-chrome-devtools-frontend](https://github.com/facebookexperimental/rn-chrome-devtools-frontend) repo is published.
The `sync-and-build` script now requires a `--branch` argument, allowing us to match release branches across repos for hotfixes (e.g. `0.73-stable`).
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D50496327
fbshipit-source-id: 671fd1581e23032eec0a419a6e50dac6c76feeb0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39163
Changelog: [Internal]
Flow knows about `util.parseArgs` now and has [really nice types for it](https://github.com/facebook/flow/commit/dc5c06a7cbf4b326bd1582b91c5cd0ed65a705bb), so let's update the type definitions for the `pkgjs/parseargs` shim to use those. The updated types use conditional and mapped types to generate a more precise return type for `parseArgs`, based directly on the provided config object.
Reviewed By: huntie
Differential Revision: D48683091
fbshipit-source-id: c0c8fe655a595e6f2f5cf1d4fc1ff0163ed3635f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41126
Long term, we'll want to flow check React Native desktop code, but in the near term, we can side step flow issues entirely by denylisting the desktop forked files in .flowconfig [ignore]. In fact, we don't do any flow checks on react-native desktop today 😬.
For the most part, the .macos.js and .windows.js forked files will be trivial changes to existing modules from react-native-github, and they will be kept in sync in an automated way, so there's an argument that the value of flow checks on these files is pretty limited.
However, at least until flow supports sub-directory multi-platform extensions and interface type hierarchies, we'll need to have entirely separate .flowconfigs for mobile and desktop (as desktop adds APIs to react-native mobile for things like keyboard input and navigation on arbitrary views).
These desktop .flowconfigs will come in a later diff.
## Changelog
[General][Internal]
Reviewed By: shwanton
Differential Revision: D50426512
fbshipit-source-id: f174268468056d510be0993ef619469c9cee3b4e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39480
Changelog:
[Internal] - Separate the time series data and renderer logic from performance monitor overlay so that it can be swapped later to C++ for cross-platform support.
Reviewed By: rshest
Differential Revision: D49321748
fbshipit-source-id: fbb781ef710b134130bfd80dada00748e73d5f24
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41087
CoreModulesPackage is not being used outside of its package (neither in OSS or at Meta), I'm reducing its visibiity to package.
If you are using this class, please contact us and we will consider increasing visibiity again.
bypass-github-export-checks
changelog: [Android][Breaking] Reduce visibility of CoreModulesPackage class
Reviewed By: christophpurrer
Differential Revision: D50338546
fbshipit-source-id: 3f0ce4dd22ddfa6743760ad378e7c6e45ab58127
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41088
This was probably caused by a copy paste, I'm fixing the log message to describe the proper class.
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: RSNara
Differential Revision: D50338296
fbshipit-source-id: 28657009ae7f9467d29eecd9b68c1f9541696350
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41014
DebugCorePackage is only used from com.facebook.react, there are no interesting usages internally at Meta or in OSS, so I'm reducing the visibility to package.
bypass-github-export-checks
changelog: [Android][Breaking] Reducing visibility of DebugCorePackage
Reviewed By: christophpurrer
Differential Revision: D50338294
fbshipit-source-id: db9b3be3b1899733a2f9d5f1cbeb314c2d350b57
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41072
As part of the new architecture rollout, we want to simplify our set of supported configurations. Right now it is possible to use Fabric / new architecture without using concurrent root, which prevents us from bringing the new concurrent capabilities to these applications and holds back React renderer code.
Changelog: [Deprecated] Using the new architecture without concurrent root will soon not be supported.
Reviewed By: rubennorte, sammy-SC
Differential Revision: D50425540
fbshipit-source-id: 1ec4c8202074e6ea98178f1a07311fda35b1951b
Summary:
In one of the latests commits on main, Hermes failed somehow to build dSYMs in some slices.
However, the slices were cached (so the cache is poisoned) and the overall process failed.
With this change, we aim to make the slice's build process fail if the dSYM or the actual framework is not built properly, before caching, so they are not poisoned
## Changelog:
[Internal] - Fail the build if dSYM or hermes.frameworks are not built
Pull Request resolved: https://github.com/facebook/react-native/pull/41076
Test Plan: CircleCI is green
Reviewed By: huntie
Differential Revision: D50453598
Pulled By: cipolleschi
fbshipit-source-id: 06bf16ef1472bd9bc9825977b817445272477a10
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41048
Reapplies D49792717
AsyncCallback and SyncCallbacks are better primitives for jsi::Function handling. The code is simpler and requires less manual argument passing. See in D49684248 how the API was extended to support more use-cases.
The underlying issue causing memory corruption has been addressed in D50286876.
Changelog: [Deprecated] AsyncCallback replaces RAIICallbackWrapperDestroyer as a safer way to manage jsi::Function memory ownership.
Reviewed By: rshest
Differential Revision: D50319914
fbshipit-source-id: e038813cad85c47be1f004bc2ea1fdaf0eee9094
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41061
changelog: [internal]
Method `dispatchCommandMountItem` only calls `addViewCommandMountItem` without adding anything on top of it. The name is inaccurate because it doesn't dispatch mount item, it queues it.
Let's remove one of them to simplify the API.
Reviewed By: javache
Differential Revision: D50408576
fbshipit-source-id: 3a4871c38e7b081a5e27aba211d61254075e76cd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41060
changelog: [internal]
The return value is never consumed, let's remove it.
Reviewed By: rubennorte
Differential Revision: D50407732
fbshipit-source-id: 8a363d874b4e1eb7852a9fefb3b511f66d3fdbe9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39943
When the user attaches a debugger, and the app moves to the background the debugging session persists. This
sends a CDP console.info so the debugging user is aware of the app's state. It is an easy state to get into
when debugging on multiple emulators.
Changelog: [iOS][Added] - Add console.log notification in DevTools if app transitions between back/foreground.
Reviewed By: dmytrorykun
Differential Revision: D49956535
fbshipit-source-id: 29e1aba9c4eaeba072fe04f2b932a3e04c96d081
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41055
This should fix the issue highlighted in [this comment](https://github.com/reactwg/react-native-releases/discussions/64#discussioncomment-7271155).
Basically, before the fix, we were not supporting flavours correctly, as we assumed that only Debug and Release were available.
With this change, we infer whether we have to fetch Hermes for Debug or Release based on the actual flags that are passed. In this way, the users can customize their app's flavors more freely.
## Changelog:
[Internal] - Support multiple flavors when downloading Hermes
Reviewed By: huntie
Differential Revision: D50408381
fbshipit-source-id: 6990218b286b4dd823323bc63de90279efc9e74e
Summary:
X-link: https://github.com/facebook/yoga/pull/1431
Pull Request resolved: https://github.com/facebook/react-native/pull/41041
The last of the row-reverse issues hurray!
The position insets were broken with row-reverse since we were using the main-start/main-end edges to inset from and NOT the inline-start/inline-end edges as we should. This made it so that inset in left and right were swapped and same with top and bottom (with column-reverse). The solution here is the same as the previous ones were we are migrating to using inline-start/end as the leading/trailing edge now.
Reviewed By: NickGerleman
Differential Revision: D50390543
fbshipit-source-id: b714deab8489fbe11f7f6db21e4aad3b3aa314b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41044
The reference Clang/GCC build has a pretty strict set of warnings enabled. The reference MSVC build has less strict warnings, which can be a problem for MSVC users building at higher warning levels (e.g. React Native for Windows in OSS uses `/W4` as its baseline warning level).
This bumps up the MSVC warning level to `/W4`, since we are nearly clean already.
There are some limitations. E.g. we don't test binary with MSVC (some issues I didn't work out), and only test building statically linked. But but we do have a minimal C benchmark we compile with MSVC.
X-link: https://github.com/facebook/yoga/pull/1432
Test Plan: GitHub Actions running benchmark MSVC build.
Reviewed By: yungsters
Differential Revision: D50398443
Pulled By: NickGerleman
fbshipit-source-id: 6616034d79b1a308b32d5d3387bae70f40b7b5ab
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41067
Bump `hermes-parser` packages to the latest released version.
Changelog: https://github.com/facebook/hermes/blob/main/tools/hermes-parser/js/CHANGELOG.md
Notable changes:
- Added parsing support for `as` expressions as well as `renders*` and renders?`.
- Updated internal prettier version to `3.0.3`.
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D50395762
fbshipit-source-id: 8a9131ea1b0683e79c7bc74b4df9deafac7450f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41056
As the title says,
I accidentally included this as the diff on top of it that would have made this flag toggleable was abandoned.
Changelog:
[Internal] [Changed] - Revert accidental bridgelessEnabled=true for RN Tester
Reviewed By: luluwu2032
Differential Revision: D50409804
fbshipit-source-id: 0e17883094f90e397544b2be0daee5f6cacd8756
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41058
Glog has a piece of code which looks like this:
```
namespace google {
// They need the definitions of integer types.
#include "glog/log_severity.h"
#include "glog/vlog_is_on.h"
```
This fragment is:
- Always valid when the pod does not define a module
- Valid for Xcode >= 14.3, when the pod do define a module
- Invalid for Xcode < 14.3, when the pod do define a module
Modules are required to support Swift, so, in the long run, we want to have `DEFINES_MODULE` set to `YES` for `Glog`.
This is a temporary workaround to keep supporting older versions of Xcode while Apple keeps allowing to use Xcode 14.1 to submit apps to the store.
Historically, Apple pushes the minimum version of Xcode every April, so we expect to be able to remove this workaround in April 2024.
## Changelog:
[Internal] - Make Glog work with older versions of Xcode
Reviewed By: cortinico
Differential Revision: D50410487
fbshipit-source-id: 96145cdf9ba1bc75622403d3c06454d6d4bfd967
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40948
## Changelog:
[iOS][Breaking] alertAction is deprecated in PushNotificationIOS. getScheduledLocalNotifications now uses new iOS APIs which do not expose this property.
Reviewed By: cipolleschi
Differential Revision: D50275541
fbshipit-source-id: e4ecad858cd06350c749e7f5a837f36316656183
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41063
Some tests for RuntimeScheduler broke because we used uninitialized values incorrectly (they're initialized with 0 on Android but with something like `0101010101...` on iOS).
This fixes the tests by assigning the right initial value.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D50413220
fbshipit-source-id: e1fc223e795e2ae01d6e3ba3bc32bd052c8fc2f3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41052
When we animate an Animated.Value that has multiple components (eg Animated.Color, AnimatedXY), we have no guarantee that the animation callbacks will be processed in a single React commit. Previously, we attempted to work around this by ignoring these updates in `__findAnimatedPropsNodes`, but that leads to other issues.
Instead, force all animation completions that happen in a single frame to be processed together by emitting them as a single event (Note: this only works when using the singleOpBatching flag for Animated which hasn't been rolled out)
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D50366676
fbshipit-source-id: 613920056113b6515792e80e06254b92061bc335
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40999
Fast refresh banner for Android was introduced for Bridge-only (D42286425), in this diff we enable it for Bridgeless as well.
Changelog:
[Android][Changed] - Enable fast refresh banner for Bridgeless
Reviewed By: cortinico
Differential Revision: D50318991
fbshipit-source-id: 08e3cda5e4cc6e9b7319db57627c1e6bf7fcc67b
Summary:
We've been using SocketRocket 0.7.0 (to pick up a few bug fixes) without issue in React Native macOS. Might as well bump it upstream before 0.73 if we can.
## Changelog:
[IOS] [CHANGED] - Update SocketRocket to 0.7.0
Pull Request resolved: https://github.com/facebook/react-native/pull/39571
Test Plan: CI should pass
Reviewed By: cortinico
Differential Revision: D50411361
Pulled By: cipolleschi
fbshipit-source-id: 93ab571dcfd23e699f1c066bf7aaf737e1f2d18b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41028
This removes misleading `const` modifiers from some methods in `RuntimeScheduler` that shouldn't really use it, and removes the `mutable` modifiers that were only necessary because of that.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D50364626
fbshipit-source-id: 28ed9fa923f8e787166f702ccaecd41a635d3b3a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40945
This adds some temporary logic to configure the use of the modern version of RuntimeScheduler based on values coming from the app configuration.
This logic is centralized in `ReactInstance` so from that point the code is completely cross-platform.
This doesn't use `ReactNativeConfig`/`CoreFeatures` because they're initialized after the point where we need to access them for this use case. This way is a bit uglier but this isn't intended to live for long (only until we verify this doesn't have regressions in a complex app).
Changelog: [internal]
---
Reviewed By: sammy-SC
Differential Revision: D50171297
fbshipit-source-id: 8d96e228550cc6112ffe2abec4d531514b052f82
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40944
## Summary
This creates a new version of `RuntimeScheduler` that's intended to be backwards compatible but with a few notable changes:
1. `scheduleTask` is now thread-safe.
2. `scheduleWork` is now just an alias of `scheduleTask` with immediate priority (to preserve the yielding semantics it had over other tasks).
3. Yielding mechanism has changed, to make lower priority tasks to yield to higher priority tasks, instead of just yielding to `scheduleWork` and `executeNowOnTheSameThread`.
We don't expect this to have any impact in performance or user perceivable behavior, so we consider it a short-lived refactor. When we validate this assumptions in a complex application we'll delete the old version and only keep the fork.
## Motivation
The main motivation for this refactor is to reduce the amount of unnecessary interruptions of running tasks (via `shouldYield`) that are only used to schedule asynchronous tasks from native.
The `scheduleWork` method is the only available mechanism exposed to native APIs to schedule work in the JS thread (as the existing version of `scheduleTask` is only meant to be called from JS). This mechanism **always** asks for any running tasks in the scheduler to yield, so these tasks are always considered to have the highest priority. This makes sense for discrete user events, but not for many other use cases coming from native (e.g.: notifying network responses could be UserBlocking, Normal or Low depending on the use case).
We need a way to schedule tasks from native with other kinds of priorities, so we don't always have to interrupt what's currently executing if it has a higher priority than what we're scheduling.
## Changes
**General APIs:**
This centralizes scheduling in only 2 APIs in `RuntimeScheduler` (which already exist in the legacy version):
* `scheduleTask`, which is non-blocking for the caller and can be used from any thread. This always uses the task queue in the scheduler and a new yielding mechanism.
* `executeNowOnTheSameThread`, which is blocking for the caller and asks any task executing in the scheduler to yield. These tasks don't go through the task queue and instead queue through the existing synchronization mechanism in `RuntimeExecutor`. The yielding mechanism for these tasks is preserved.
`scheduleWork` will be deprecated and it's just an alias for `scheduleTask` with an immediate priority (to preserve a similar behavior).
**Yielding behavior:**
Before, tasks would only yield to tasks scheduled via `scheduleWork` and `executeNowOnTheSameThread` (those tasks didn't go through the task queue).
With this implementation, tasks would now yield to any task that has a higher position in the task queue. That means we reuse the existing mechanism to avoid lower priority tasks to never execute because higher priority tasks never stop coming.
All tasks would yield to requests for synchronous access (via `executeNowOnTheSameThread`) as did the current implementation.
Changelog: [internal]
Reviewed By: javache, sammy-SC
Differential Revision: D49316881
fbshipit-source-id: 046afc8b6f510a8608ef3da6e27b2663d861f1b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40875
This introduces a proxy for RuntimeScheduler so we can select between 2 different implementations at runtime (current implementation vs. new implementation, done in D49316881).
Changelog: [internal]
Reviewed By: javache, sammy-SC
Differential Revision: D49316880
fbshipit-source-id: 4035ed6ba641a2316f2efb7cf4a0a86270d6ae23
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40870
This removes an old experiment to implement microtasks in React Native (which is incorrect now that the runtime scheduler executes multiple tasks per runtime executor "task"). `drainMicrotasks` is a no-op at the moment in Hermes because the flag isn't set, so this code is essentially dead.
We'll add the new iteration of microtasks in a following PR.
Changelog: [internal]
Reviewed By: christophpurrer
Differential Revision: D49536251
fbshipit-source-id: b8efba2d0310b9e33e65b79c60ad2db1c8109def
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41054
changelog: [internal]
Avoid going into a while loop if there are no preMountItems.
Reviewed By: javache
Differential Revision: D50407034
fbshipit-source-id: 5c163e02303c331b8fff46fb9a955f88f72a529c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41051
Strictifies flow to flow strict-local in files where doing that doesn't cause new flow errors.
Changelog: Internal
Reviewed By: yungsters
Differential Revision: D50369011
fbshipit-source-id: b4a5a26b839b7327a3178e6f5b35246dea365a38
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41047
Array events are currently broken in the sample for RN Tester. This is because the event name is not registered correctly.
I'm updating the event registration to be correct.
Changelog:
[Internal] [Changed] - Make IntArray events work on Bridgeless for RN-Tester
Reviewed By: cipolleschi
Differential Revision: D50266485
fbshipit-source-id: 13bbce91a41281383d4857048e573b6d9cc5387b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41020
This adds Fabric and Paper bindings to support `alignContent: "space-evenly"` as implemented in https://github.com/facebook/yoga/pull/1422
Changelog:
[General][Added] - Bindings for `alignContent: "space-evenly"`
Reviewed By: yungsters
Differential Revision: D50347978
fbshipit-source-id: 44df3b8ddc7171cddf56957c11ac7d975f706f9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41019
### Changes made
- Regenerated tests (as some aspect ratio tests seem to be out of date compared to the fixtures)
- Added SpaceEvenly variant to the "Align" enums (via enums.py)
- Implemented `align-content: space-evenly` alignment in CalculateLayout.cpp
- Added generated tests `align-content: space-evenly`
- Updated NumericBitfield test to account for the fact that the Align enum now requires more bits (this bit could do with being reviewed as I am not 100% certain that it's valid to just update the test like this).
### Changes not made
- Any attempt to improve the spec-compliance of content alignment in general (e.g. I think https://github.com/facebook/yoga/pull/1013 probably still needs to happen)
X-link: https://github.com/facebook/yoga/pull/1422
Reviewed By: yungsters
Differential Revision: D50305438
Pulled By: NickGerleman
fbshipit-source-id: ef9f6f14220a0db066bc30db8dd690a4a82a0b00
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41023
X-link: https://github.com/facebook/yoga/pull/1426
Just like D50140503 where marginStart and marginEnd were not working with row reverse, paddingStart and paddingEnd are not working either with row reverse either. The solution is similar - we were checking the flex item layout starting/ending edges and not the general layout starting/ending edges. This change makes it so that we look at the proper edge according to what direction is set.
One caveat is that in the case of padding (and also border) there is a callsite that actually wants to get the flex item layout's leading/trailing padding and not the one dictated by direction. So, I made a new function to accommodate this and just swapped that callsite out.
Reviewed By: NickGerleman
Differential Revision: D50348995
fbshipit-source-id: 85717df23de7cf5f66b38d3ff28435b053a4e68e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41022
X-link: https://github.com/facebook/yoga/pull/1425
Just like D50140503 where marginStart and marginEnd were not working with row reverse, borderStart and borderEnd are not working either with row reverse either. The solution is similar - we were checking the flex item layout starting/ending edges and not the general layout starting/ending edges. This change makes it so that we look at the proper edge according to what direction is set.
One caveat is that in the case of border (and also padding) there is a callsite that actually wants to get the flex item layout's leading/trailing border and not the one dictated by direction. So, I made a new function to accommodate this and just swapped that callsite out.
Reviewed By: NickGerleman
Differential Revision: D50348085
fbshipit-source-id: eca2702c1753dbebb503034e2f0732684ad6c56e
Summary:
X-link: https://github.com/facebook/yoga/pull/1423
Pull Request resolved: https://github.com/facebook/react-native/pull/41017
Before resolving https://github.com/facebook/yoga/issues/1208 yoga was in a state where "leading" and "trailing" only referred to the main-start and main-end directions ([definition in spec](https://drafts.csswg.org/css-flexbox/#box-model)). That is, the start/end of the layout of flex items in a container. This is distinct from something like inline-start/inline-end which is the [start of text layout as defined by direction](https://drafts.csswg.org/css-writing-modes-3/#inline-start).
The bug linked above happened because "leading" and "trailing" functions are referring to the wrong directions in certain cases. So in order to fix this we added a new set of functions to get the "leading" and "trailing" edges according to what inline-start/inline-end would refer to - i.e. those defined by the direction (ltr | rtl). In this state I think it is confusing to understand which function refers to which direction and more specific names could help that.
This diff just renames the following 4 FlexDirection.h functions:
* **leadingEdge** -> **flexStartEdge**
* **trailingEdge** -> **flexEndEdge**
* **leadingLayoutEdge** -> **inlineStartEdge**
* **trailingLayoutEdge** -> **inlineEndEdge**
The spec calls the start/end directions as dictated by the flex-direction attribute "main-start" and "main-end" respectively, but mainStartEdge might be a bit confusing given it will be compared to a non-flexbox-specific name in inlineStartEdge. As a result I landed on flexStart/flexEnd similar to what values are used with alignment attributes (justify-content, align-content).
I chose to get rid of the "leading" and "trailing" descriptors to be more in line with what terminology the spec uses.
Next diff will be to rename the functions in Node.cpp to adhere to the above patterns.
Reviewed By: NickGerleman
Differential Revision: D50342254
fbshipit-source-id: 1e83a885876af9cf363822ebdbb64537f4784520
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41033
This has been rolled out with the false value (previous client-default of false). The open-source value was already false.
Changelog: [Internal]
Reviewed By: NickGerleman, sammy-SC
Differential Revision: D50362517
fbshipit-source-id: 577a2ead047b30d196409a26fd5385f333f20b18
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41036
Changelog:
[Added] - Shipping the new event dispatching pipeline that immediately moves events over to the C++ queue. This should unblock useDeferredValue + useTransition interruptibility on Android.
Reviewed By: javache
Differential Revision: D50365981
fbshipit-source-id: ecf60e5bc29fb4568463568a6ede4330e0294fd3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41016
This hasn't been very useful since AsyncStorage/persistence was removed, but takes up a good amount of usable screen real-estate for information in the center of the screen. Remove it.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D50297980
fbshipit-source-id: 296a377dffc89c5c203ca6264351a2a1a8281cc3
Summary:
… request to local pathname comparator variables to fix issue with other rightward elements of url such as query or fragment entering the comparison and causing 404 errors for key debugging routes.
A change in Chromium appended the query "?for_tabs" to the /json/list request made by Chrome DevTools to find remote debugger targets.
The current comparison in InspectorProxy.js compares the entire node IncomingMessage url field to the local pathname constants. The issue arises as url can also contain the query and fragment portions so the original comparison of "/json/list" === "/json/list" which resolved as true would become "/json/list?for_tabs" === "/json/list" and evaluate to false ultimately resulting in a 404 for the request.
In summary, all these changes/issues caused remote debugging of Hermes code in React Native apps to become unavailable, greatly impacting developer experience.
## Changelog:
[GENERAL] [FIXED] JS Debugging: Fix inspector-proxy to allow for DevTools requests with query strings
Pull Request resolved: https://github.com/facebook/react-native/pull/41005
Reviewed By: NickGerleman
Differential Revision: D50342265
Pulled By: robhogan
fbshipit-source-id: a65f2908f0bea9fc15e1e3e4e6d31a3b9598e81f
Summary:
Fix https://github.com/facebook/react-native/issues/40560
## Changelog:
[ANDROID] [FIXED] - Ensure that `configureJavaToolChains` is only executed once during configuration
Pull Request resolved: https://github.com/facebook/react-native/pull/40757
Test Plan:
- Create a fresh `react-native@0.73.0-rc.1` project
- Install `react-native-webview`
- Apply [this patch](https://github.com/react-native-webview/react-native-webview/pull/3175/files) for `react-native-webview` (caused by another issue https://github.com/facebook/react-native/issues/40559)
- Edit `android/gradle.properties` and set `newArchEnabled` to true
- Build application
- (Expected) Application fail to build
- Apply this PR
- (Expected) Application build successfully
**Additional explanation:**
According to the implementation of `configureJavaToolChains`, all the subprojects (both the app and the libraries) will have their toolchains setup in one execution of the method. Therefore, it is okay for the method to be invoked only when configuring the plugin for the app.
On the other hand, invoking the method for more than one time will cause the issue stated in https://github.com/facebook/react-native/issues/40560.
Reviewed By: cipolleschi
Differential Revision: D50361871
Pulled By: cortinico
fbshipit-source-id: bd5e18df97988122788d0482dba954e517a0cb5c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41009
This change should fix [#39971](https://github.com/facebook/react-native/issues/39971), computing the relative path from the App path to the pod installation root and using that instead of the absolute path to the `react-native.config.js` file
## Changelog
[Internal] - Stabilize RCTAppDelegate podspec
Reviewed By: cortinico
Differential Revision: D50323710
fbshipit-source-id: e29e62228d08c752e822d7a9ab5b1a2b5dcd6eb4
Summary:
Problem Causes: In ReactViewGroup, there is a conflict between the zIndex attribute and the removeClippedSubviews optimization attribute. When both are used at the same time, the array mDrawingOrderIndices in ViewGroupDrawingOrderHelper that records the rendering order of subviews is not reset when super is called in the updateSubviewClipStatus method to add and remove subviews.
Solution:�Because there are many third-party components that inherit from or depend on ReactViewGroup, all methods for adding and removing subviews in ViewGroup need to be override in ReactViewGroup, and ViewGroupDrawingOrderHelper corresponding to handleAddView and handleRemoveView needs to be called in these methods. And all the precautions for directly calling super to add and remove subviews are changed to calling the overridden method by ReactViewGroup.
Special Note: All addView related methods in ViewGroup will eventually be called to the addView(View child, int index, LayoutParams params) method, except addViewInLayout. Regarding the method of adding subviews, we only need to override addView(View child, int index, LayoutParams params) and addViewInLayout(View child, int index, LayoutParams params,boolean preventRequestLayout) in ReactViewGroup.
## Changelog:
[Android] [Fixed] - Fix the crash in ReactViewGroup of https://github.com/facebook/react-native/issues/30785
Pull Request resolved: https://github.com/facebook/react-native/pull/40859
Reviewed By: NickGerleman
Differential Revision: D50321718
Pulled By: javache
fbshipit-source-id: 7fa7069937b8c2afb9f30dd10554370b1be5d515
Summary:
For a very long time when a promise rejects without an attached catch we get this warning screen without a correct stack trace, only some internal calls to the RN internals.
<img src="https://github.com/facebook/react-native/assets/1634213/75aa7615-ee3e-4229-80d6-1744130de6e5" width="200" />
I created [an issue for discussion](https://github.com/react-native-community/discussions-and-proposals/discussions/718) in the react-native-community repo and we figured out it was only a matter of symbolication. While it cannot be done on release without external packages and source maps, at least while developing we can provide a symbolicated stack-trace so developers can better debug the source of rejected promise.
I got the stack trace symbolicated and the correct code frame. I'm missing some help trying to display it in the warning view but at the very least I can now correctly show the line of the error and log the codeframe to the console.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[GENERAL] [FIXED] - Show correct stack frame on unhandled promise rejections on development mode.
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/40914
Test Plan:
I simply created a throwing function on a dummy app, and checked the output of the console and the warning view:
```ts
import React from 'react';
import {SafeAreaView, Text} from 'react-native';
async function throwme() {
throw new Error('UNHANDLED');
}
function App(): JSX.Element {
throwme();
return (
<SafeAreaView>
<Text>Throw test</Text>
</SafeAreaView>
);
}
export default App;
```
Here is the output
<img src="https://github.com/facebook/react-native/assets/1634213/2c100e4d-618e-4143-8d64-4095e8370f4f" width="200" />
Edit: I got the warning window working properly:
<img src="https://github.com/facebook/react-native/assets/1634213/f02a2568-da3e-4daa-8132-e05cbe591737" width="200" />
Reviewed By: yungsters
Differential Revision: D50324344
Pulled By: javache
fbshipit-source-id: 66850312d444cf1ae5333b493222ae0868d47056
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40941
Events are currently not working for Fabric Interop on Bridgeless. That's because the `BridgelessReactContext` is not checking for interop modules on `getJsModule` calls, so the `InteropEventEmitter` is never returned.
This extends `BridgelessReactContext` so that `InteropEventEmitter` is returned if the Interop Layer is turned on.
Changelog:
[Internal] [Changed] - Make events work for Fabric Interop on Bridgeless
Reviewed By: cipolleschi
Differential Revision: D50266484
fbshipit-source-id: 0188d71bdc7acc8c188d886d45f0258914ad7af7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41003
Following up the deprecation of Flipper in 0.73 and preparing for the removal of Flipper in 0.74, we are removing Flipper integration from the CI.
## Changelog:
[Internal] - Remove the Flipper integration from CI
Reviewed By: dmytrorykun
Differential Revision: D50321335
fbshipit-source-id: 04885d3dbaab9b2834c9461e0580dfbef386244f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41002
Following up the deprecation of Flipper in 0.73 and preparing for the removal of Flipper in 0.74, we are removing Flipper integration from the Codebase.
## Changelog:
[iOS][Breaking] - Remove the Flipper integration
Reviewed By: dmytrorykun
Differential Revision: D50321255
fbshipit-source-id: d2f4488ada7acdbd3687f54db4204ba7f09370af
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40895
This is a long running debug assert due to a race condition with BE. I have at times wanted to try to add a lock to protect this, and measure impact, but really it will go away when we get rid of BE anyway, and any strategy I have come up with to lock gets hairy quickly.
This change does not impact RN in OSS, where BE is already disabled.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D50247680
fbshipit-source-id: d004fc7db24f1f0b7c3ea8756d4678ce41579712
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40970
This cleans up https://github.com/facebook/react-native/commit/94972039571e1f3b387e0f63227a6ad13740eaf3 a bit, after I did some debugging and looking through Android source code.
1. `getRootView()` gives us constant-time access to root hierarchy, and we don't need to do instanceof check once per level. It also, at least in the sample activity I tried, gives us the Window's `LayoutParams`.
2. The root of the hierarchy is documented in code to do what we want. https://github.com/facebook/react-native/commit/94972039571e1f3b387e0f63227a6ad13740eaf3
3. Calling `getRootView().getLayoutParams()`, then casting to `WindowManager.LayoutParams`, seems to show up in a lot of other widgets (inc Unity, RoboElectric), as a solution to getting this information. https://github.com/search?q=getRootView%28%29.getLayoutParams%28%29&type=code
This still feels like not a 100% documented contract, so I added an assertion so we can catch if the contract isn't valid somewhere now or in the future, instead of silently breaking keyboard events.
Note that this code only runs on SDK 30+ (Android 11+).
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D50297761
fbshipit-source-id: f97fb6ea1bcdb1b8e8dfcdcc178625efc0bb6b4a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41011
changelog: [internal]
topContentSizeChange should be a direct event. Otherwise it collides with ScrollView's `onContentSizeChange` any may break FlatList
Reviewed By: javache
Differential Revision: D50323281
fbshipit-source-id: dd8713acfdd5158ac8175b8efe5027d06cd0d0a8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40968
Enable Explicit API mode warning to let product developers get notified of Explicit API checks (similar to deprecation mechanism). Explicit API mode will be enabled as strict in a future version
more details: https://kotlinlang.org/docs/whatsnew14.html#explicit-api-mode-for-library-authors
changelog: [Android][Changed] Enabling Explicit API warning, this will be changed as Strict in a future version
Reviewed By: cortinico
Differential Revision: D50295069
fbshipit-source-id: 41f7eb823ef8cfb4266dfa2d927f54c7dab9193a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40929
This diff reduces the footprint that bridgeless is imposing on the new app template. Specifically:
- I've created a `.toReactHost` method that converts a DefaultReactNativeHost to a DefaultReactHost
- I've updated RN Tester to use the same setup as the New App template which reduces code duplication.
I also had to remove a couple of `UnstableReactNativeAPI` as those were bleeding in the new app template.
I don't think we should ask users to opt-in in `UnstableReactNativeAPI` in the New App template itself as
this means that all the apps will get this opt-in.
Instead we should keep it only for specific APIs that we want the users to opt into.
Changelog:
[Internal] [Changed] - Simplify new app template for bridgeless
Reviewed By: cipolleschi, luluwu2032
Differential Revision: D50227693
fbshipit-source-id: e86c54d5156cc27f1f898b43ca89c57d5cf148b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40866
This type doesn't do anything, and we can replace it with a `jsi::Function` inside `UIManagerBinding`.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D50176084
fbshipit-source-id: 1c782f3e4d212f1d956451fd650d3ed5ed8f0d71
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40942
The Fabric Interop example for Android is broken. This is due to the Kotlin conversion which moved the `Color.colorToHSV(color, hsv)` statement *after* the HSV array is read so the array is always [0,0,0].
I'm fixing it here.
Changelog:
[Internal] [Changed] - Fix broken Fabric Interop example
Reviewed By: cipolleschi
Differential Revision: D50264766
fbshipit-source-id: 27ae5289408c7c23c667d6d7112437fa7ebe36d5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40873
Some host platforms may require the LayoutContext for computing the size of text, e.g. to read the pointScaleFactor value. This change passes the LayoutContext to TextLayoutManager so it can be used during text measurement.
Please note, for now, this does not wire any fields from LayoutContext through to the TextMeasureCache, TextLayoutManager::getHostTextStorage, or TextLayoutManager::measureCachedSpannableById (on Android).
## Changelog:
[General] [Internal]
Reviewed By: rshest
Differential Revision: D50227592
fbshipit-source-id: 37ec16a4828c6cef4a1c1f01d144a86dd29dec29
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40940
Currently the `onIntArrayChanged` event is invoked
only once inside RN Tester. I'm changing the logic to make sure it fires whenever we click "Set Opacity"
Changelog:
[Internal] [Changed] - Make sure onIntArrayChanged is invoked on RN Tester
Reviewed By: mdvacca, dmytrorykun
Differential Revision: D50264765
fbshipit-source-id: 93a60fd1b657c3d8b8182cab6bb7cd4368ac9a42
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41001
I believe this is due to a race condition between VM teardown and callback invocation. Because we were previously retaining the CallbackWrapper across the invokeAsync call, we may potentially have been holding onto the JSI::Function after it was already destroyed.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D50286876
fbshipit-source-id: 1277a9f37166da59ebb2169fe8d5a6fabce82f1b
Summary:
…king root view frame changes
Looking through where this was introduced (https://github.com/facebook/react-native/pull/37649), it seems the notification went from tracking root view size changes to window size changes. However, it was not renamed. I was using it for root view changes in RN-macOS, which.. I guess I'll refactor. Meanwhile, let's update the name?
## Changelog:
[IOS] [CHANGED] - Rename `RCTRootViewFrameDidChangeNotification` as it's not tracking root view frame changes
Pull Request resolved: https://github.com/facebook/react-native/pull/39835
Test Plan: CI should pass
Reviewed By: cipolleschi
Differential Revision: D50173742
Pulled By: javache
fbshipit-source-id: 4651696174c439800984a5e6cf642200bb9c4f3c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40998
changelog: [Android] Add back interface FabricViewStateManager to unblock 0.73
I incorrectly deleted FabricViewStateManager in D47993140. This is a breaking change even for old architecture. Let's add it back and mark it as deprected so we can remove it later on.
This interface is not used in react-native anymore.
We are removing FabricViewStateManager because it simply wraps StateWrapper and provides no additional anymore.
Reviewed By: cortinico
Differential Revision: D50318633
fbshipit-source-id: aeb1c66c35018e336339616b564dee6f3156b54b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40943
We should enable antialiasing when it's necessary, as it's an expensive property. Scale and Translate transforms shouldn't enable it.
Source: https://github.com/facebook/react-native/pull/32920
Changelog: [iOS][Changed] Matched behaviour for allowsEdgeAntialiasing to old architecture.
Reviewed By: sammy-SC
Differential Revision: D50270444
fbshipit-source-id: 8a08039c42f8fb855db2ace140124c33f18dc3bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40936
Found a couple of places where we were accidentally copying Props structs. These can be big, so we should avoid doing so.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D50263678
fbshipit-source-id: f60a0370df9b7f3f146988148d5192d3cc32fb4e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40935
This is scheduled to land in 0.74, so I'm removed the native integration as this is not needed anymore.
The only thing I left is a stub class to ease the migration out of `ReactNativeFlipper`.
Changelog:
[Android] [Removed] - Remove ReactNative/Flipper Integration
Reviewed By: mdvacca, huntie, cipolleschi
Differential Revision: D50259817
fbshipit-source-id: 28427425340896635607202cd78936f6030e78e0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40862
The last usages of Folly Futures were deleted in D49073914, so we can remove this dependency from React Native.
## Changelog:
[Internal] - remove folly usage in React-hermes
Reviewed By: NickGerleman, cipolleschi
Differential Revision: D50223640
fbshipit-source-id: 792fd7696c1463a81e25dbef7713620486cc94c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39364
Once ConnectionDemux.* and Registration.* finish migrating to the new Hermes CDPHandler, there aren't any usage of the other stuff left over in inspector-modern. They can be safely removed.
Changelog: [Internal]
Reviewed By: mattbfb
Differential Revision: D49073914
fbshipit-source-id: bc60a3da85a00ac86beeebd098d7c3566a7c56dd
Summary:
Every file in the react-native-github repo should have the right copyright header. This was missed for this file.
Changelog: Internal
Reviewed By: rubennorte
Differential Revision: D50319271
fbshipit-source-id: 77c20fa4d3679eb5573ce61fd1c9cba60386ee21
Summary:
CircleCI is red because verdaccio fails to publish `normalize-colors`.
For some old dependencies, normalize-colors has been published on the official npmjs with the version we needs.
In order to mitigate the RN red ci, we can consume them directly from NPMJS.
As a followup, we created a task to investigate it next week.
## Changelog:
[Internal] - Skip publishing or normalize colors
Pull Request resolved: https://github.com/facebook/react-native/pull/40977
Test Plan:
Tested locally, running verdaccio and simulating CI. It worked.
CircleCI is green
Reviewed By: robhogan
Differential Revision: D50300449
Pulled By: cipolleschi
fbshipit-source-id: 2259b450deff15a117d1de4690bcfe8a9ba7d115
Summary:
To address the root cause of a recurring issue (https://github.com/facebook/react-native/issues/40797, https://github.com/facebook/react-native/issues/39692) where breaking changes to `react-native/normalize-colors` would be pulled into old versions of `deprecated-react-native-prop-types`, we recently change the dependency in the latter to use a semver range (https://github.com/facebook/react-native-deprecated-modules/pull/27, https://github.com/facebook/react-native/pull/40869).
For CI, we generally force `react-native/*` to be resolved only from Verdaccio locally published packages - ie, the current versions at source. The source version (currently `0.74.1`) isn't semver-compatible with `deprecated-react-native-prop-types`'s dependency (`^0.73.0`), so `npm install` was failing in CI with "no package found". We should be getting `0.73.2` from the public registry in this case.
This restores a previous workaround added in https://github.com/facebook/react-native/pull/34571 but not updated since https://github.com/facebook/react-native-deprecated-modules/pull/11 meant the dependency was now on the pluralised package. We have no dependency on the old non-plural package any more.
## Changelog:
[INTERNAL] [FIXED] - CI/Verdaccio: Proxy `react-native/normalize-colors` from NPM for the `deprecated-react-native-prop-types` dependency.
Pull Request resolved: https://github.com/facebook/react-native/pull/40971
Test Plan: CI
Reviewed By: cipolleschi
Differential Revision: D50298291
Pulled By: robhogan
fbshipit-source-id: 4bf6503108335ffa52654346d1874c217071ff91
Summary:
Fixes https://github.com/facebook/react-native/issues/40754
Hi all!
We noticed that our app started to crash after bumping to RN v0.71.13, anyways after a deeper investigation we also found that the crash occurs in the latest version as well.
Crash log:
```
E FATAL EXCEPTION: main
Process: com.nfl.fantasy.core.android.debug, PID: 6034
java.lang.ClassCastException: android.app.ContextImpl cannot be cast to android.app.Activity
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.getActivity(ReactRootView.java:926)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.checkForKeyboardEvents(ReactRootView.java:946)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.onGlobalLayout(ReactRootView.java:912)
at android.view.ViewTreeObserver.dispatchOnGlobalLayout(ViewTreeObserver.java:1061)
```
The code which causes ClassCastException is following [here](https://github.com/facebook/react-native/blob/ea88fbe229e1d276753ee8e118184274fc872138/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/ReactRootView.java#L864).
In this code explicit type conversion to Activity is not safe because it's not guaranteed by the compiler that context will be compatible with Activity type.
The appropriate issue [has been filed](https://github.com/facebook/react-native/issues/40754).
## 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] - Fixed crash occurring in certain native views when keyboard events are fired.
Pull Request resolved: https://github.com/facebook/react-native/pull/40755
Test Plan:
Tested it manually with the [reference application](https://github.com/kot331107/rnCrashReproducer). Repro steps are as follows:
- Build and run the app on Android
- Tap the button "Open Modal"
- You should see the red popup fragment to the bottom of the screen
- Tap on the text input to open software keyboard
- Expected: it should show the keyboard and no crash happens.
Reviewed By: arushikesarwani94
Differential Revision: D50198424
Pulled By: NickGerleman
fbshipit-source-id: a5a6d86334856f4ffbe818150da5793380da4702
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40947
This shows up as this.context shows up as 1 sometimes. Let's just hard-code this to 11, to make the test more reliable.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D50253990
fbshipit-source-id: 1da75e5e5f3226676f9af67fc329a70079eed59e
Summary:
Currently, the template has a `buildToolsVersion = '34.0.0'` specified in the top level .gradle file but it's not currently using it.
This is causing the build to fallback to the default version provided by AGP which is 33.x
This is also causing the CI to download buildtools 34.0.0 as they're not in the container (causing network flakyness).
## Changelog:
[INTERNAL] [FIXED] - Make sure template is consuming the right buildToolsVersion
Pull Request resolved: https://github.com/facebook/react-native/pull/40938
Test Plan: CI should be green
Reviewed By: cipolleschi
Differential Revision: D50270482
Pulled By: cortinico
fbshipit-source-id: 09fdc66fe24f1cae760d07e4a2f044793a66cafc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40934
The previous `packages/normalize-color` directory name could be confusing, given we have previously published a `react-native/normalize-color` package in addition to the current `react-native/normalize-colors`. After this change, the directory name and `package.json` `"name"` field are aligned.
Changelog: [Internal]
Reviewed By: cortinico, NickGerleman
Differential Revision: D50229030
fbshipit-source-id: 63854140bf61d7d1d3f1270ed05a2ba76f8c5b0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40939
Currently some libs on RN 0.73 are broken as the default for Build Config generation changed
from true to false since AGP 8.x. This reverts the behavior to the old flag.
Closes#40791Closes#40559
Changelog:
[Internal] [Changed] - Make sure buildConfig is turned on for all the 3rd party libraries
Reviewed By: mdvacca
Differential Revision: D50270382
fbshipit-source-id: 02dcb031c577f65be2f41d9da0334c1b3d89e4c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40869
Bumps DRNPT to v5 - the significant change is that this one depends on `react-native/normalize-color: ^0.73.0`, instead of `*`, so is protected from future breaking changes to that package.
NOTE: We can't safely include `react-native/normalize-color: ^0.74.0` in the dependency range of DRNPT because `0.74.0` isn't a semver-compliant release (0.74 isn't cut yet), so this will pull 0.73.2 from NPM, which is fine. We may need to publish DRNPT@6 if 0.74 final turns out to contain breaking changes (eg, a Node 20 bump).
Changelog:
[General][Fixed] Update `deprecated-react-native-prop-types` to remove fragile transitive `*` dependencies.
Reviewed By: huntie
Differential Revision: D50228564
fbshipit-source-id: 01aafafad40d9a93d00de2b5f45d2796620b9b5d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40933
This enables us to have lint coverage (and others) for these files. Visibility is none, so it won't be pulled in to anything.
Also removed no-op JSITracing implementation.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D50262377
fbshipit-source-id: 6218c7a79b5c0328bed8472590cff9e92006b86e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40882
This header has not been used since facebook/react-native#110b191b landed, generalizing the way props map buffers are initialized.
# Changelog
[General][Internal]
Reviewed By: christophpurrer
Differential Revision: D50237390
fbshipit-source-id: f0f532c59c53b1df5d363cfd49f950697df37128
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40881
Some host platforms (e.g., Windows) may have different semantics for accessibility props. For example, not setting `accessibilityState` at all is different from setting all accessibilityState values to false.
Similarly, setting AccessibilityState::expanded to false is different than not setting AccessibilityState::expanded at all because Windows inverts the AccessibilityState::expanded value for it's semantics: an explicitly false value for AccessibilityState::expanded sets the component to a collapsed accessibility state.
## Changelog
[General][Internal]
Reviewed By: NickGerleman
Differential Revision: D50236747
fbshipit-source-id: 2131824d14e38e1ed08a80e8b0e311fc6b02d1f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40880
The isPressable prop was previously added to TextAttributes. It also needs to be parsed from RawProps in BaseTextProps for platforms to use it.
## Changelog
[General][Internal]
Reviewed By: javache
Differential Revision: D50235306
fbshipit-source-id: 101aded2af5889c739ed06af7511bd34a2683dfc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40861
Reference `jobj_` from the async callback is unsafe, as the Java counterpart may have been deallocated by the time it's executed. Instead move the async call to Java.
Note that this method doesn't actually do anything in Fabric, it's used by the old renderer only.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D50224974
fbshipit-source-id: c848b177753643febac1d6646d62a27ebace9238
Summary:
## Summary
When transpiling `react-native` with `swc` this file caused some trouble
as it mixes ESM and CJS import/export syntax. This PR addresses this by
converting CJS exports to ESM exports. As
`ReactNativeViewConfigRegistry` is synced from `react` to `react-native`
repository, it's required to make the change here. I've also aligned the
mock of `ReactNativeViewConfigRegistry` to reflect current
implementation.
Pull Request resolved: https://github.com/facebook/react-native/pull/40787
Test Plan: Sandcastle tests
Reviewed By: noahlemen
Differential Revision: D50229257
Pulled By: javache
fbshipit-source-id: 2e848a1ac434c45e219876c1042aacb42c77cb6f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40885
We no longer need this hotfix since the native fix has been stable for some time now. Cleans up the feature flags and forced `collapsable={false}` prop in View.
## Changelog
[General][Internal]
Reviewed By: yungsters, NickGerleman
Differential Revision: D50241092
fbshipit-source-id: 57a3121356736bd6633e3672e6a8369067e45811
Summary:
X-link: https://github.com/facebook/litho/pull/962
Pull Request resolved: https://github.com/facebook/react-native/pull/40804
X-link: https://github.com/facebook/yoga/pull/1420
This stack is ultimately aiming to solve https://github.com/facebook/yoga/issues/1208
**The problem**
Turns out that we do not even check direction when determining which edge is the leading (start) and trailing (end) edges. This is not how web does it as the start/end is based on the writing direction NOT the flex direction: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_flexible_box_layout/Basic_concepts_of_flexbox#start_and_end_lines. While web does not have marginStart and marginEnd, they do have margin-inline-start/end which relies on the writing mode to determine the "start"/"end": https://developer.mozilla.org/en-US/docs/Web/CSS/margin-inline-start.
This means that if you do something like
```
export default function Playground(props: Props): React.Node {
return (
<View style={styles.container}>
<View style={styles.item} />
</View>
);
}
const styles = StyleSheet.create({
container: {
marginEnd: 100,
flexDirection: 'row-reverse',
backgroundColor: 'red',
display: 'flex',
width: 100,
height: 100,
},
item: {
backgroundColor: 'blue',
width: 10,
},
});
```
You get {F1116264350}
As you can see the margin gets applied to the left edge even thought the direction is ltr and it should be applied to the right edge.
**The solution**
I ended up fixing this by creating a new `leadingLayoutEdge` and `trailingLayoutEdge` function that take the flex direction as well as the direction. Based on the errata, the a few functions will use these new functions to determine which `YGEdge` is the starting/ending.
You might be wondering why I did not put this logic inside of `leadingEdge(flexDirection)` / `trailingEdge(flexDirection)` since other areas could potentially have the same bug like `getLeadingPadding`. These functions are a bit overloaded and there are cases where we actually want to use the flexDirection to get the edge in question. For example, many of the calls to `setLayoutPosition` in `CalculateLayout.cpp` call `leadingEdge()` / `trailingEdge()` to set the proper position for cases like row-reverse where items need to line up in a different direction.
Reviewed By: NickGerleman
Differential Revision: D50140503
fbshipit-source-id: 5b580c7570f6ae1e2d031971926ac4e8f52dd362
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40879
Introduce StableReactNativeAPI annotation, the goal of this annotation is to describe classes, interfaces and members that are considered Stable and will remain part of the new architecture of React Native
changelog: [internal] internal
Reviewed By: arushikesarwani94
Differential Revision: D50195996
fbshipit-source-id: a64a27217a6fd885d2c188a6847565b3413bb232
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40860
This diff adds support for the `AS` expression in TS sources. The following codegen declaration should work now:
```
export default codegenNativeComponent<NativeProps>(
'MyComponentView',
) as HostComponent<NativeProps>;
```
Changelog: [General][Added] - Handle TSAsExpression when looking for the codegen declaration
Reviewed By: shwanton
Differential Revision: D50225241
fbshipit-source-id: 247a3d341d742b548e82318d0fa21dff9884d2bd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40871
If we pass isPressable to the native props object (via TextAttributes), we can use this information to bypass hit testing on some spans. This is rather important on some platforms where pointerenter/pointerleave/ mousemove events force frequent hit testing.
## Changelog:
[General] [Internal]
Reviewed By: javache
Differential Revision: D50228473
fbshipit-source-id: 4fce85f4b18617fbe10d3c804e943484bf990664
Summary:
Adds changelog for the 0.71.14 version.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [CHANGED] - Add 0.71.14 changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/40863
Reviewed By: robhogan
Differential Revision: D50228147
Pulled By: huntie
fbshipit-source-id: cb6ad2abac53825a935205fb7646d8fa32ba8302
Summary:
The reference to runtime assumes the queue will ensure references to runtime are valid when invoked. This
isn't the case if you create a breakpoint, Hermes hit that breakpoint and your refresh the app. This consistently
will crash the app.
The fix is to not assument this, similar to ReactCommon/react/runtime/hermes/HermesInstance.cpp
Reviewed By: javache
Differential Revision: D50225678
fbshipit-source-id: b45cae1f5f687bc8c699fd74b187376a547012c5
Summary:
## Changelog:
[Internal] - Fix Nighlties that were broken due to changes for double publishing
Reviewed By: cortinico
Differential Revision: D50225219
fbshipit-source-id: dd1b96a956bb282caa40bd6f99b9a82554958746
Summary:
I'm removing the node >= 18 restriction on react-native/normalize-colors as that's unnecessary
as is currently breaking the ecosystem for users on Node 16 on previous versions of React Native.
Changelog:
[General] [Fixed] - normalize-colors should not impose node >= 18
Reviewed By: robhogan
Differential Revision: D50215144
fbshipit-source-id: cdfb90f4274754ad5b04fa2cad339419d45bbcba
Summary:
## Changelog:
[Internal] - Run all the tests in CI when not on a PR
Reviewed By: cortinico
Differential Revision: D50220596
fbshipit-source-id: be1a30d713e9d427858cf22bd3ca9549ad513057
Summary:
This is just a type refactoring to make the typing of the `defaultSource` prop of the Image component more explicit and descriptive (using the `ImageRequireSource` type makes it more clear that we can use the require statement to set an image asset as default source) and this is also more consistent with the `source` prop typing.
Currently :
- The typing of default source is `ImageURISource | number | undefined`
- The typing of source is `ImageSourcePropType` which is equal to `ImageURISource | ImageURISource[] | ImageRequireSource` and `ImageRequireSource` is equal to `number`.
In this PR we change the typing of default source to `ImageURISource | ImageRequireSource | undefined` to make more clear that the number of the default source prop refers to the use of the require statement with an asset file.
## Changelog:
[GENERAL] [CHANGED] - use ImageRequireSource instead of number for the defaultSource prop typing of the Image component
Pull Request resolved: https://github.com/facebook/react-native/pull/40801
Test Plan: No one required since it's a small typing refactoring.
Reviewed By: christophpurrer
Differential Revision: D50209922
Pulled By: NickGerleman
fbshipit-source-id: c25f3c6f145f357ff1cb0b1c7b54a19bf1dec824
Summary:
It looks like objects properties aren't guaranteed to have a stable order. Sort them, before we serializae and print them to the screen in the interop test. This should reduce interop test flakyness.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D50148860
fbshipit-source-id: a6ed1433d4dd35cafa5c9f7d09c4cca194c31d81
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40792
Similarly to D49792717, simplify the careful logic we have with CallbackWrapper and RCTBlockGuard and instead rely on bridging's `AsyncCallback` so safely handle jsi::Function for us.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D49862756
fbshipit-source-id: 289f2d5ef622f47eb3fccf0cc7a52cc13a83b028
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39952
AsyncCallback and SyncCallbacks are better primitives for jsi::Function handling. The code is simpler and requires less manual argument passing. See in D49684248 how the API was extended to support more use-cases.
Changelog: [General] Deprecated RAIICallbackWrapperDestroyer. Use AsyncCallback instead for safe jsi::Function memory ownership.
Reviewed By: RSNara
Differential Revision: D49792717
fbshipit-source-id: 9f2f3b00c71ad1b86427dee3749c6d98ef0f5678
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40794
I accidentally stumbled upon the `UIManager` object on JS side and realised it was being exported as `any`. So I've extracted the interface `UIManagerJSInterface` and applied where it seems to make sense, although, after chatting with javache it could be useful to further narrow down the interface given what's currently implemented by the `BridgelessUIManager`.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D50137691
fbshipit-source-id: ccc746fa1dfbb3290e0b73dfa14c65833b238e07
Summary:
Currently, the template has a `buildToolsVersion = '34.0.0'` specified in the top level .gradle file but it's not currently using it.
This is causing the build to fallback to the default version provided by AGP which is 33.x
This is also causing the CI to download buildtools 34.0.0 as they're not in the container (causing network flakyness).
I'm also bumping the docker container to v12 as we bumped NDK 26 which is missing in the v11 container.
## Changelog:
[INTERNAL] [FIXED] - Make sure template is consuming the right buildToolsVersion
Pull Request resolved: https://github.com/facebook/react-native/pull/39956
Test Plan: CI should be green
Reviewed By: christophpurrer
Differential Revision: D50019777
Pulled By: cortinico
fbshipit-source-id: a2ab7a7bd7c55624d5c050b45e69086c5f25ba6a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40767
Fix the following issue:
```Invariant Violation: TurboModuleRegistry.getEnforcing(...):
'ExceptionsManager' could not be found. Verify that a module by this name is registered in the native
binary.Bridgeless mode: true. TurboModule interop: true. Modules loaded: {"NativeModules":[],"TurboModules":
["PlatformConstants","AppState","SourceCode","BlobModule","WebSocketModule","DevSettings","DevToolsSettingsManager","LogBox","Networking","Appearance","DevLoadingView","DeviceInfo","DeviceEventManager",
"SoundManager","ImageLoader","DialogManagerAndroid","NativeAnimatedModule","I18nManager","AccessibilityInfo","StatusBarManager","StatusBarManager","IntentAndroid","ToastAndroid","ShareModule","Vibration"],
"NotFound":["NativePerformanceCxx","NativePerformanceObserverCxx","RedBox","BugReporting","HeadlessJsTaskSupport","FrameRateLogger","KeyboardObserver",
"AccessibilityManager","ModalManager","LinkingManager","ActionSheetManager","ExceptionsManager"]}
```
Changelog:
[Android][Changed] - Add Add ExceptionsManagerModule to CoreReactPackage
Reviewed By: cortinico
Differential Revision: D50017783
fbshipit-source-id: 8642bb23bdae50a1e702f5e0586b0ede80007bb1
Summary:
Currently, when we build the app in production mode the `DevtoolsOverlay` & `TraceUpdateOverlay` are bundle
## Changelog:
[GENERAL][REMOVED]: removed `DevtoolsOverlay` & `TraceUpdateOverlay` from production bundle
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/40749
Test Plan:
1. Build the app in production mode
2. Check that both `DevtoolsOverlay` & `TraceUpdateOverlay` are included in the bundle
Reviewed By: robhogan, NickGerleman
Differential Revision: D50121208
Pulled By: hoxyq
fbshipit-source-id: 3e1fb506c679ec79b116dea9772d372cd2ea9ca9
Summary:
Commit 8b88883071 broke the Cache for RNTester because the cached version of the pods does not know about the exitence of SocketRocket 6.1.0
Bumping the keys should force a redownload of the cocoapods specs repo
## Changelog:
[Internal] - Bump RNTester cache keys
Pull Request resolved: https://github.com/facebook/react-native/pull/40789
Test Plan: CircleCI is green
Reviewed By: GijsWeterings
Differential Revision: D50169281
Pulled By: cipolleschi
fbshipit-source-id: 83e251495bfa43d62384470efe97c5505d76684f
Summary:
The SocketRocket version was upgraded to 0.6.1 on the 0.72-stable branch but for some reason it was not updated in main, causing a downgrade when running `pod install` with 0.73.0 RC1
Original commit bumping SocketRocket -> https://github.com/facebook/react-native/commit/8ce471e2fa802cc50ff2d6ab346627cb5f6d79b4
## Changelog:
[IOS] [CHANGED] - Bump SocketRocket to 0.6.1
Pull Request resolved: https://github.com/facebook/react-native/pull/40774
Test Plan: Run rntester locally
Reviewed By: cipolleschi
Differential Revision: D50137261
Pulled By: arushikesarwani94
fbshipit-source-id: dfc2760f5d5611881126ad114d8f6ada23630a29
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39988
Changelog: [Internal]
in this pr, we integrate the sync void configuration with our feature flag infra
Reviewed By: luluwu2032
Differential Revision: D50030743
fbshipit-source-id: 03505e5e1f74aa90dc16f33fa4e93f9de9660dae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39989
Changelog: [Internal]
we need some configuration path to turn on the sync void method execution behavior, doing that here
Reviewed By: luluwu2032
Differential Revision: D50028200
fbshipit-source-id: a2501b622685e4bafa5e2a5031275cc8bc5050b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39970
Changelog: [Internal]
in this diff, i add the logic that makes void return values run synchronously
Reviewed By: javache
Differential Revision: D49613770
fbshipit-source-id: ef840fb3ee130430505d000a7cf74e094f9d1405
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40777
In this diff I'm removing the deprecation of NativeModule.onCatalystInstanceDestroy() method, changing it to DeprecatedInNewArchitecture
changelog: [Android][Breaking] Mark NativeModule.onCatalystInstanceDestroy() method as deprecated in new architecture
Reviewed By: christophpurrer
Differential Revision: D50141027
fbshipit-source-id: a4c4911bdadc27f981f3af0522317e6dd08d9344
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40775
In this diff I'm introducing the BaseReactPackage class to the public API of React Native Android. the goal is for this class to replace TurboReactPackage, which will be Deprecated in the New Architecture
changelog: [internal] internal
Reviewed By: christophpurrer
Differential Revision: D50128456
fbshipit-source-id: a65e1eb0d81b94e442799226784f73f489eabb73
Summary:
X-link: https://github.com/facebook/hermes/pull/1151
Pull Request resolved: https://github.com/facebook/react-native/pull/40746
This feature was missing in JSC's JSI implementation, which is preventing from rolling out NativeState-based features in React Native.
Changelog: [General][Added] JSC support for the NativeState API in JSI
Reviewed By: neildhar
Differential Revision: D49229022
fbshipit-source-id: 1787c1d1b4803212d84da8f55b7d5a460a9d33c2
Summary:
Very simple change, there's a typo in the word "perspective" whilst naming the possible transform property types.
## Changelog:
[INTERNAL] [FIXED] - Fix typo in PerspectiveTransform type
Pull Request resolved: https://github.com/facebook/react-native/pull/40771
Test Plan: -
Reviewed By: javache
Differential Revision: D50133297
Pulled By: arushikesarwani94
fbshipit-source-id: bd742b1bccc5d015e5e8095b1d2b83765fee3d6b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40751
In D48379915 I fixed inverted `contentOffset` in `onScroll` events on iOS. I thought I tested on Paper, but I think this was during a period where the Paper route in Catalyst was actually launching Fabric (oops).
In Paper, at least under `forceRTL` and English, `[UIApplication sharedApplication].userInterfaceLayoutDirection` is not set to RTL. We instead have a per-view `reactLayoutDirection` we should be reading.
This sort of thing isn't currently set on Fabric, which checks application-level RTL. This seems... not right with being able to set `direction` in a subtree context, but Android does the same thing, and that would take some greater changes.
Changelog:
[iOS][Fixed] - Fix iOS Paper Scroll Event RTL check
Reviewed By: luluwu2032
Differential Revision: D50098310
fbshipit-source-id: e321fca7b2f7983e903e23237bc2d604c72f98a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39646
We can dramatically simplify this code and remove quirks/hacks, now that we can assume layout events are always fired top down.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D49628669
fbshipit-source-id: 7de5bbc4597eba1c59aaa7672c70e76d2786c7ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40748
The ordering of `onLayout` events is non-deterministic on iOS Paper, due to nodes being added to an `NSHashTable` before iteration, instead of an ordered collection.
We don't do any lookups on the collection, so I think this was chosen over `NSMutableArray` for the sake of `[NSHashTable weakObjectsHashTable]`, to avoid retain/release. Using a collection which does retain/release seems to cause a crash due to double release or similar, so those semantics seem intentional (though I'm not super familiar with the model here).
We can replicate the memory semantics with ordering by using `NSPointerArray` (which is unfortunately not parameterized). This change does that, so we get consistently top-down layout events (matching Fabric, and Android Paper as of D49627996). This lets us use multiple layout events to calculate right/bottom edge insets deterministically.
Changelog:
[iOS][Changed] - Deterministic onLayout event ordering for iOS Paper
Reviewed By: luluwu2032
Differential Revision: D50093411
fbshipit-source-id: f6a9d5c973b97aede879baa8b952cc1be2447f28
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40768
The task referenced is 4 years old and it doesn't seem to be relevant anymore given that:
* `addRootView` has been marked as deprecated
* there is an explicit check in `addRootView` mentioning:
> Do not call addRootView in Fabric; it is unsupported. Call startSurface instead
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D50122192
fbshipit-source-id: fe02d481b47663f5bdf4fb7527e480117f00be47
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40766
This changeset allows users to opt into the new debugger frontend experience by passing `--experimental-debugger` to `react-native start`. **We are defaulting this option to `true`** for now, but will continue to evaluate this feature before 0.73 ships. It restores Flipper (via `flipper://`) as the default handling for `/open-debugger` (matching 0.72 behaviour) when this flag is not enabled.
Detailed changes:
- Replaces `enableCustomDebuggerFrontend` experiment in `dev-middleware` with `enableNewDebugger`. The latter now hard-swaps between the Flipper and new launch flows.
- Removes now-unused switching of `devtoolsFrontendUrl`.
- Implements `deprecated_openFlipperMiddleware` (matching previous RN CLI implementation).
- Disables "`j` to debug" key handler by default.
- Marks "`j` to debug" and `/open-debugger` console logs as experimental.
Changelog:
[Changed][General] Gate new debugger frontend behind `--experimental-debugger` flag, restore Flipper as base launch flow
Reviewed By: motiz88
Differential Revision: D50084590
fbshipit-source-id: 5234634f20110cb7933b1787bd2c86f645411fff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40728
Just improving type safety of a bunch of modules in the `Image` directory.
Changelog: [internal]
Reviewed By: NickGerleman
Differential Revision: D50080136
fbshipit-source-id: cbfb89aa01cad3882aa08a8ba637e561017d5db6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40730
This way of injecting the decorator is safer and more convenient to have the proper types inferred by Flow in the injected function.
Changelog: [internal]
Reviewed By: NickGerleman
Differential Revision: D50011840
fbshipit-source-id: 760812fc407d3e39fc7601d17488e3f2032a7065
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40729
This improves the type definition of the `Image` modules (the common module interface, the platform-specific implementations and the shared types module). It makes them `flow strict-local` and explicitly defines the type signature of some functions typed as `any` before.
Changelog: [internal]
Reviewed By: sullenor
Differential Revision: D50014569
fbshipit-source-id: f1eced43edf84c84bbcb10a3a2d2de27e3d5e374
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40731
The type definitions for `Image` are unnecessarily complicated, and got even more complicated after the changes for the new multiplatform support in Flow.
We had a `Image.js.flow` and a `Image.flow.js` files (which was confusing) and duplicated type definitions in `Image.js.flow`, `Image.android.js` and `Image.ios.js` because all type definitions in the shared module signature must be defined in the platform-specific modules as well.
This moves all type helpers to a new `ImageTypes.js.flow` file, simplifies the common `Image` module interface (to only define the default export type that the platform-specific module must define) and simplifies the Android and iOS specific versions.
As an added benefit, this also improves Flow type coverage by removing a bunch of FlowFixMe comments.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D50011839
fbshipit-source-id: 9da1c0467630bebf73855f5f9f771a2325adbced
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40744
The Podfile.lock was not aligned properly with the versions of the Pods on main.
## Changelog:
[Internal] - Align the Podfile.lock with the status of podspecs on main
Reviewed By: luluwu2032
Differential Revision: D50084954
fbshipit-source-id: 1cfad35262b2b57ad9ac33f494c7a2f0b723368f
Summary:
Both `hermes` and `JSC` supports `Object.{values & entries}`, so this polyfills aren't used any more.
## Changelog:
[GENERAL][REMOVED]: removed `Object.{values & entries}` from polyfills
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/40747
Test Plan:
1. We can confirm with `hermes` tests: https://github.com/facebook/hermes/blob/main/test/hermes/object-functions.js#L256
2. Remove this polyfills and check that the code runs as expected.
3. You can also run: `console.log(Object.entries.toString());` and verify that this is `[native code]`
Reviewed By: christophpurrer
Differential Revision: D50100639
Pulled By: robhogan
fbshipit-source-id: b1cea88bd984e99f304a3a063e985eecff8831dd
Summary:
All "https://react.dev/link" links give a 404 and are deprecated. I replaced all URLs with new ones or, if this was not possible, replaced them with a link to legacy documentation.
## Changelog:
[INTERNAL] [FIXED] - Fixed links to React documentation
Pull Request resolved: https://github.com/facebook/react-native/pull/40095
Test Plan: All of the old links didn't work. I tried to match the content of the errors to the new documentation as best as possible. Current links have been tested and direct you to the most relevant article section.
Reviewed By: christophpurrer
Differential Revision: D50094451
Pulled By: arushikesarwani94
fbshipit-source-id: 79fd9e729495cadfb067d94fb58acb30ca308347
Summary:
This pull request addresses two key issues. Firstly, it adds a missing docstring to the `dismissActionSheet` function within the `ActionSheetIOS` object. Secondly, it introduces TypeScript typings for the `dismissActionSheet` function.
## Changelog:
[iOS] [Added] - Add missing docstring to the `dismissActionSheet` function in `ActionSheetIOS`.
[iOS] [Added] - Add TypeScript typings for the `dismissActionSheet` function in `ActionSheetIOS`.
Pull Request resolved: https://github.com/facebook/react-native/pull/40012
Test Plan:
To ensure the code is solid, I followed these steps:
1. Ran Flow to verify that there were no errors.
2. Added a TypeScript test related to the `dismissActionSheet` function to ensure it's typed as expected.
Reviewed By: NickGerleman
Differential Revision: D50097458
Pulled By: arushikesarwani94
fbshipit-source-id: 63348239dfe19e3a07f94e5a7b59ae43a47c1975
Summary:
When we download the `hermes` repo, we also include its tests, so `jest` try to run them.
## Changelog:
[INTERNAL][FIXED]: don't run `hermes` specific tests.
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/40734
Test Plan:
1. Build the project
2. yarn test
3. See the failing tests running from the `sdks` directory.
Reviewed By: arushikesarwani94
Differential Revision: D50087482
Pulled By: robhogan
fbshipit-source-id: 012672d69c98d8b8e60012d83470cda45edc2fc6
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
bypass-github-export-checks
changelog: [Android][Changed] Reducing visibility of FrescoBasedReactTextInlineImageSpan
Reviewed By: arushikesarwani94
Differential Revision: D49803287
fbshipit-source-id: 1b00fbcf5f61af96fe7a182d40b985b7ce71a872
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
bypass-github-export-checks
changelog: [Android][Changed] Reducing visibility of FrescoBasedReactTextInlineImageShadowNode
Reviewed By: arushikesarwani94
Differential Revision: D49803295
fbshipit-source-id: 9273607af351b85800e37800941039ccf10eef76
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
bypass-github-export-checks
changelog: [Android][Changed] Reducing visibility of RefreshEvent
Reviewed By: arushikesarwani94
Differential Revision: D49803298
fbshipit-source-id: f8edfd256b3afc82bb02789b34748abb3132cce1
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
bypass-github-export-checks
changelog: [Android][Changed] Reducing visibility of VelocityHelper
Reviewed By: arushikesarwani94
Differential Revision: D49803269
fbshipit-source-id: 6b9dcf39979c8b4da5f736ba4fce3d495245755d
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
bypass-github-export-checks
changelog: [Android][Changed] Reducing visibility of ReactScrollViewAccessibilityDelegate
Reviewed By: arushikesarwani94
Differential Revision: D49803288
fbshipit-source-id: 5a4d9e7feda26501c8a82a0efb0ad28ff68a3157
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
bypass-github-export-checks
changelog: [Android][Changed] Reducing visibility of MaintainVisibleScrollPositionHelper
Reviewed By: arushikesarwani94
Differential Revision: D49803271
fbshipit-source-id: ebc43e60dea8de5ef5c21deb623351e0c8ed00b7
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
bypass-github-export-checks
changelog: [Android][Changed] Reducing visibility of ScaleTypeStartInside
Reviewed By: arushikesarwani94
Differential Revision: D49803276
fbshipit-source-id: 11ea67cc976a09634293219d0c0933036f34b6ff
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
bypass-github-export-checks
changelog: [Android][Changed] Reducing visibility of ReactImageDownloadListener
Reviewed By: arushikesarwani94
Differential Revision: D49803289
fbshipit-source-id: 19d4c3403449dd9b928963b274362662375b7545
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
bypass-github-export-checks
changelog: [Android][Changed] Reducing visibility of ReactEventEmitter
Reviewed By: arushikesarwani94
Differential Revision: D49803292
fbshipit-source-id: 5c49555ce35ad10ee46bc3db3bc3bc83d8486a0d
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
bypass-github-export-checks
changelog: [Android][Changed] Reducing visibility of YogaNodePool
Reviewed By: arushikesarwani94
Differential Revision: D49803281
fbshipit-source-id: 092826dcd4b7c9858240b760e87eb87a32e54a25
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
bypass-github-export-checks
changelog: [Android][Changed] Reducing visibility of ViewHierarchyDumper
Reviewed By: arushikesarwani94
Differential Revision: D49803266
fbshipit-source-id: e6a3f5f915975979759b7134a486d96db974703d
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
bypass-github-export-checks
changelog: [Android][Changed] Reducing visibility of ShadowNodeRegistry
Reviewed By: arushikesarwani94
Differential Revision: D49803275
fbshipit-source-id: a2796a1e125f0399418aa56cce6eafe7c0509eeb
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
bypass-github-export-checks
changelog: [Android][Changed] Reducing visibility of NoSuchNativeViewException
Reviewed By: arushikesarwani94
Differential Revision: D49803297
fbshipit-source-id: d2c3e6a2243f6c80db0658c81c44c2d2bbedab5b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39823
In this diff I'm refactoring BaseJavaModule and ReactContextBaseJavaModule to simplify class hierarchy.
ReactContextBaseJavaModule will be deprecated in the new architecture
bypass-github-export-checks
Reviewed By: cortinico
Differential Revision: D49930340
fbshipit-source-id: 602b5f3d2d926956c52b96b28815dae687fdad87
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40739
Adding support for grouped accessibility focus on switch. This is when the switch itself shouldn't be directly focusable. Instead, the parent element should be focusable, including announcing the switch role and state changes, e.g. "on" and "off".
Fix this issue in a couple ways:
1. Make sure to set the proper role for switch in FbReactSwitchCompat.java.
2. Set the state description in SwitchCompat.java so that uses the correct announcement of "off" and "on" instead of "checked" and "unchecked".
Reviewed By: blavalla
Differential Revision: D50068169
fbshipit-source-id: 0c4133377f7a29da9cadb730399bdbedd58c26ae
Summary:
The current comments explaining the various StyleSheet methods and are misleading, often referencing the removed `StyleSheetRegistry` and old behavior related to it.
## Changelog:
Per https://github.com/facebook/react-native-website/pull/3872/files, updates comments to reflect the fact that the `StyleSheetRegistry` has been removed.
[INTERNAL] [REMOVED] - Removed comment references to `StyleSheetRegistry` and style sheet `ID`s
Pull Request resolved: https://github.com/facebook/react-native/pull/39990
Test Plan: `console.log(StyleSheet.create({ testClass: { color: "red" } }))` outputs `{ testClass: { color: "red" } }`
Reviewed By: NickGerleman
Differential Revision: D50076737
Pulled By: javache
fbshipit-source-id: edc3c9f63f9963c17b1a2c1a898badf1b87183e4
Summary:
When upgrading ESLint to latest, the RN plugin fails to run because of a deprecated API:
```
Error: Parsing error: DeprecationError: 'originalKeywordKind' has been deprecated since v5.0.0 and can no longer be used. Use 'identifierToKeywordKind(identifier)' instead.
```
## Changelog:
- [GENERAL] [FIXED] Updated ESLint version to fix `originalKeywordKind` deprecation error
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/39654
Test Plan: Run CI and Lint
Reviewed By: NickGerleman
Differential Revision: D49634978
Pulled By: robhogan
fbshipit-source-id: f65f0d56053acf1c877fe0f368a7f4e13c8c57d1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40233
changelog: [internal]
This is a reland of D49355595 and D49358327.
the problem was using two different hashing functions in place where they must be the same.
Reviewed By: javache
Differential Revision: D50020135
fbshipit-source-id: 1cec6bc385077d371b024a0fb5d9c64ba1f6269c
Summary:
It seems this method is not referenced by anything anymore. I think https://github.com/facebook/react-native/pull/35017 made it redundant. Let's remove it?
I can also do the whole "Deprecate for one version, remove in the next" since this was publicly exported.
## Changelog:
[iOS] [REMOVED] - Remove RCTGetMultiplierForContentSizeCategory
Pull Request resolved: https://github.com/facebook/react-native/pull/39617
Test Plan: CI should pass
Reviewed By: dmytrorykun
Differential Revision: D49618166
Pulled By: cipolleschi
fbshipit-source-id: fb72e961d2a1eb9977944fea3ee4deeab46b946b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39955
Align `RCTRequired` to the rest of the targets in `react-native-github/packages/react-native/Libraries`.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D50009827
fbshipit-source-id: c2ec9eb9e5fb081a2e2e8f53d33bc21dcf95b279
Summary:
X-link: https://github.com/facebook/yoga/pull/1411
Pull Request resolved: https://github.com/facebook/react-native/pull/39796
X-link: https://github.com/facebook/yoga/pull/1414
GCC flags that `isUndefined()` is not declared `constexpr` but that `unwrapOrDefault()` is. `std::isnan` is not constexpr until C++ 23 (because we cannot have nice things), so I made `yoga::isUndefined()` constexpr, using the same code `std::isnan()` boils down to. I then made `FloatOptional` depend on `Comparison.h` (instead of the other way around), so we can use it.
Note that the use of the `std::floating_point` concept here requires the libc++ bump in the previous diff in the stack.
Reviewed By: yungsters
Differential Revision: D49896837
fbshipit-source-id: 61e2bbbfedecffd007a12d42d998e43d3cf5119c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39959
We're still accessing project.buildDir which will be removed in Gradle 9.0
I'm cleaning it up here.
Changelog:
[Internal] [Changed] - Fix compilation warnings introduced by Gradle 8.4
Reviewed By: yungsters
Differential Revision: D50016573
fbshipit-source-id: de7a725f61b503f08991ebf85b9a002cefab221a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39960
This is our usual round of bumps just after the branch cut.
Changelog:
[Android] [Changed] - Bump Gradle to 8.4
Reviewed By: yungsters
Differential Revision: D50016574
fbshipit-source-id: 781eb906f6b12f76f673e38bdcf099c9b7cefade
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39958
I'm reverting the change of AGP from 8.2 beta to 8.1 as we don't need 8.2
Using 8.2 beta forces us to use Android Studio beta, which is actually not necessary.
Changelog:
[Android] [Changed] - Bump AGP to 8.1.2
Reviewed By: yungsters
Differential Revision: D50016572
fbshipit-source-id: 6c36df0568a1f867dac3c335abbaabb990e55491
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39953
This was added to support Fabric codegen, but is no longer referenced.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D50011688
fbshipit-source-id: 30867f719dbcbc447e10226787ce7407503a1c7d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39951
## Changelog:
[Internal] -
This makes PerformanceObserver API more robust in regards of telling which exactly types of the performance entries are supported.
At this point, we either tell that we support mark/measure/event ones on the New Architecture, or none otherwise. The source of truth of this information should be on the native side.
Reviewed By: rubennorte
Differential Revision: D50010982
fbshipit-source-id: ad7bce279a58eac232b7c26f8d8c2bd1cde51e3c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39833
Reland of D49642047 which got reverted because of a CI infra error.
---
It's currently possible for RN to crash the dev server by sending down an exceptionally large CDP response/event. Instead of making assumptions on the protocol spoken over the proxy, let's assume clients on either side of the proxy can be trusted to be well behaved (and to degrade gracefully when a large message is encountered).
Changelog: [General][Fixed] JS debugging: prevent dev server crash when a large CDP payload is returned from the device
Reviewed By: huntie
Differential Revision: D49955025
fbshipit-source-id: aa5b8b55c885e26dd5b8170660603173cfe54de0
Summary:
On Android 13 Devices, we are seeing `NullPointerException`, which should be handled with this
## Changelog:
[ANDROID] [FIXED] - Handle Crash for onRequestPermissionsResult
Pull Request resolved: https://github.com/facebook/react-native/pull/39715
Reviewed By: NickGerleman
Differential Revision: D49965583
Pulled By: javache
fbshipit-source-id: 8a39049675510f9cca8141c893d93fdb04ba0e25
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39613
In this diff I'm removing TurboModuleManager from ReactHostDelegate. The goal is to stop exposing TurboModuleManager and TurboModuleRegistry
Developers should use ReactContext.getNativeModule to retrieve native modules instead of TurboModuleManager or TurboModuleRegistry
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D49483636
fbshipit-source-id: 6c2e29d83700bebf05475875edad6d5c0877d9df
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
bypass-github-export-checks
changelog: [Android][Changed] Reducing visibility of UnobservedTaskException
Reviewed By: cortinico
Differential Revision: D49803272
fbshipit-source-id: cbd9bd285ba4c2ce5b3e77885da37f125517fac9
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
bypass-github-export-checks
If you are using this class or interface please comment in this PR and we will restate the public access.
changelog: [Android][Changed] Reducing visibility of ExecutorException
Reviewed By: cortinico
Differential Revision: D49803280
fbshipit-source-id: 140b5bcd41b1a16ed84196021305a4d27f8cc24a
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
bypass-github-export-checks
changelog: [Android][Changed] Reducing visibility of Capture
Reviewed By: cortinico
Differential Revision: D49803273
fbshipit-source-id: 5c57f7865b4d2b58b3a8ffcde8c424c0a65ee7d2
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
bypass-github-export-checks
changelog: [Android][Changed] Reducing visibility of CancellationTokenRegistration
Reviewed By: arushikesarwani94
Differential Revision: D49803300
fbshipit-source-id: c7992bdaa0994c1035894a15af1e9d0bf7ebd204
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
bypass-github-export-checks
changelog: [Android][Changed] Reducing visibility of AggregateException
Reviewed By: arushikesarwani94
Differential Revision: D49803279
fbshipit-source-id: f3b6488789485ed87fd724f950eb0c2e34c38cc6
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
bypass-github-export-checks
changelog: [Android][Changed] Reducing visibility of ProgressiveStringDecoder
Reviewed By: arushikesarwani94
Differential Revision: D49803293
fbshipit-source-id: 93d28f579d51e220c46e74d264f84c5dce743e72
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
bypass-github-export-checks
changelog: [Android][Changed] Reducing visibility of ProgressRequestBody
Reviewed By: arushikesarwani94
Differential Revision: D49803278
fbshipit-source-id: d049b97dbb0124274830a14d18c30d0574f04532
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
bypass-github-export-checks
changelog: [Android][Changed] Reducing visibility of HeaderUtil
Reviewed By: arushikesarwani94
Differential Revision: D49803294
fbshipit-source-id: 01ec431cf2addc8c0df0d729f5cc15c0334b4762
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
bypass-github-export-checks
changelog: [Android][Changed] Reducing visibility of CountingOutputStream
Reviewed By: arushikesarwani94
Differential Revision: D49803284
fbshipit-source-id: fb411c6f6335c0bf4b42f8b87c4cdb3e01fc6e7c
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
bypass-github-export-checks
changelog: [Android][Changed] Reducing visibility of DidJSUpdateUiDuringFrameDetector
Reviewed By: arushikesarwani94
Differential Revision: D49803285
fbshipit-source-id: e9312a7fbf86ae75bdc4b50922676ab8d1140be7
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
changelog: [Android][Changed] Reducing visibility of AnimationsDebugModule
bypass-github-export-checks
Reviewed By: arushikesarwani94
Differential Revision: D49803302
fbshipit-source-id: 4c5f51d44c0d21e024d1a411fa425302372456eb
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
changelog: [Android][Changed] Reducing visibility of NoRetryPolicy
bypass-github-export-checks
Reviewed By: arushikesarwani94
Differential Revision: D49803301
fbshipit-source-id: 47d350663470e7d6d27f5bfcf9c5576f9ad41987
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
changelog: [Android][Changed] Reducing visibility of SendAccessibilityEvent
bypass-github-export-checks
Reviewed By: arushikesarwani94
Differential Revision: D49803277
fbshipit-source-id: 24a55ae7f7ca1218aad2db95fee87d316f0d073f
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
changelog: [Android][Changed] Reducing visibility of ViewHierarchyUtil
bypass-github-export-checks
Reviewed By: arushikesarwani94
Differential Revision: D49803291
fbshipit-source-id: 929608f71ce3c5af842616add21ac9077239e109
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
changelog: [Android][Changed] Reducing visibility of RedBoxDialogSurfaceDelegate
bypass-github-export-checks
Reviewed By: arushikesarwani94
Differential Revision: D49803299
fbshipit-source-id: d3d5a6a61c4541503552c27bf940531c2e27f5ce
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
changelog: [Android][Changed] Reducing visibility of MultipartStreamReader
bypass-github-export-checks
Reviewed By: arushikesarwani94
Differential Revision: D49803274
fbshipit-source-id: 7bcbf032b9ce59cd624e782ee81f69dad747bf8e
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
changelog: [Android][Changed] Reducing visibility of LogBoxDialogSurfaceDelegate
bypass-github-export-checks
Reviewed By: arushikesarwani94
Differential Revision: D49803282
fbshipit-source-id: 51594dc7d2eda47f4673874cf83d77a1a6d8007b
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
changelog: [Android][Changed] Reducing visibility of LogBoxDialog
bypass-github-export-checks
Reviewed By: arushikesarwani94
Differential Revision: D49803290
fbshipit-source-id: 17a301fd758bf3fcfb880b2647a7fd53bf7781a7
Summary:
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
changelog: [Android][Changed] Reducing visibility of FpsView
bypass-github-export-checks
Reviewed By: arushikesarwani94
Differential Revision: D49803286
fbshipit-source-id: 2c4b7349de755d02a29cfdb97820b7af07709528
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39762
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
changelog: [Android][Changed] Reducing visibility of UIManagerProvider
bypass-github-export-checks
Reviewed By: cortinico
Differential Revision: D49803268
fbshipit-source-id: 8bc261115beae8fe0666ed95b65b01c1772a5d15
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39834
Bridgeless is instacrashing on fast-refresh. This fixes it.
Changelog:
[Android] [Fixed] - Fix instacrash on bridgeless due to calling showMessage on null instance
Reviewed By: cipolleschi
Differential Revision: D49929822
fbshipit-source-id: a2ce65797abd34d6a3e2b7f2c50d38a62ea8bdea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39819
Bump `hermes-parser` packages to the latest released version.
Changelog: https://github.com/facebook/hermes/blob/main/tools/hermes-parser/js/CHANGELOG.md
Notable changes:
- Upgraded to the lastest version of emscripten for the parser.
- The babel interop logic now more closely matches babel's AST.
- The biggest change is we now add the `extra.raw` properties to literal nodes, which results in Babel more closely outputting literal sources. e.g. previously the following would happen `1.0` -> `1`, `'foo'` -> `"foo"` and `1n` -> `1` but now the raw source value is preserved.
- Upgraded `prettier-plugin-hermes-parser` to use the latest prettier formatting logic, which causes some minor formatting changes.
- `hermes-parser` no longer fails when the `component` name is used within a function type, e.g. `type Foo = (component: string) => void`.
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D49935231
fbshipit-source-id: a905838396fdd7281442c211970e0caa773a1256
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39830
## Changelog:
[Internal] -
Add `QuickPerformanceLogger.isMarkerOn` API, which allows to check whether the given QPL marker is going to be sent to the server or not (the latter may happen due to e.g. downsampling).
This allows to avoid some extra unneeded overhead when logging QPL events in some heavily sampled scenarios.
Reviewed By: rubennorte
Differential Revision: D49949527
fbshipit-source-id: 9d7f93beee45d498c799a94b16cd7c68ec1a9340
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39780
This diff removes flags and setups from the files to turn on and off the new architecture. The script is meant to run only on pre-alpha builds.
## Changelog:
[Internal] - Add script to remove prealpha flags
Reviewed By: cortinico
Differential Revision: D49376471
fbshipit-source-id: 754bf6f9d5b94da77111798200bbaaa3347fb678
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39810
Two issues will be fixed:
- Bridgeless has lazy view manager loading by default so the React Package that provides view managers must implement ViewManagerOnDemandReactPackage, we might could refactor the design of package classes later
- ThemedReactContext should **NOT** be used directly to call function ```getJSModule```, since it doesn't overrides ```getJSModule``` for Bridgeless, we can use it's internal variable ```meactApplicationContext``` which should be an instance of BridgelessReactContext
Reviewed By: cortinico
Differential Revision: D49912656
fbshipit-source-id: a0bdd717612398e8d7a6f36d36dba241a3b06bd7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39828
Active Suppert released a new Gem which is incompatible with Cocoapods 1.13.0, the latest release, as they removed a method used by cocoapods.
This fix ensures that we install compatible versions of the Gem.
## Changelog:
[iOS][Fixed] - Set the max version of Active support to 7.0.8
Reviewed By: hoxyq
Differential Revision: D49949782
fbshipit-source-id: 278097502d3a416567cc8c0b90090fee4fb21503
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39795
X-link: https://github.com/facebook/yoga/pull/1412
Android NDK 25 uses a version of libc++ that is more than three years old, missing a lot of basic features of C++ 20. This is rectified in NDK 26 (latest LTS NDK), which brings us up to date with latest Clang (17, released this year), and adds a new policy where future NDK versions will bump libc++ as part of bumping LLVM/Clang.
This requires an a beta AGP version (and corresponding Android Studio Preview). Based on how far we are historically, it wouldn't be a surprise if we see the stable release this month (well before the RN 0.74/Yoga 3.0 cut, even in the worse case).
Changelog:
[Android][Changed] - Use NDK 26
Reviewed By: yungsters
Differential Revision: D49895949
fbshipit-source-id: 37bb4d1fdf81137be7f14f6675b4e079c6f861e4
Summary:
This bumps folly, to absorb https://github.com/facebook/folly/commit/45fffa629d6bf7321391222d40613d75e8e067d7 which fixes warnings in XCode 15, and NDK 26 (treated as error bc we have better hygiene there). We then bump a little bit further to get past a new warning added, then fixed later.
Need to manually set `FOLLY_HAVE_GETTIME` on Apple because of the silliness described in https://github.com/facebook/folly/issues/1470#issuecomment-1746035194
There is not a combination of Folly, and Android libc++, that has fixes for warnings, but doesn't require the new libc++ in NDK 26. It is expected then that this commit will fail the build, but the next should succeed, and the two must be landed at the same time.
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/39798
Reviewed By: fkgozali
Differential Revision: D49897681
Pulled By: NickGerleman
fbshipit-source-id: 52b97ed5b302abf9e27f38dc655207827852dcc3
Summary:
This is what Folly is built against internally. Bump the version we use, and the standard we compile with, to take some different paths, and see if we fix some warnings caused by FMT with the ndk bump.
Changelog:
[General][Breaking] - Bump fmt to 9.1.0
Pull Request resolved: https://github.com/facebook/react-native/pull/39799
Test Plan: Passes in CircleCI
Reviewed By: cortinico, yungsters
Differential Revision: D49900112
Pulled By: NickGerleman
fbshipit-source-id: 3f11080555ef20aeb9291d1096ffa6077b3b3bbd
Summary:
Changelog: [Internal]
sync void execution is now hooked up to mc
Reviewed By: mdvacca
Differential Revision: D49854130
fbshipit-source-id: fb4241b11a80d44318b382e2757fe7fcbfba4fb1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39759
Changelog: [Internal]
as part of the sync void tm methods test, there are some modules that do not behave correctly when trying to execute their methods on the js thread.
this module accesses UIKit, so we explicitly dispatch async to the main thread
Reviewed By: mdvacca
Differential Revision: D49835587
fbshipit-source-id: 30b5b58b6df4686bd81dbf8dbeaae275c98fa2e1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39761
Changelog: [Internal]
as part of the sync void tm methods test, there are some modules that do not behave correctly when trying to execute their methods on the js thread.
to maintain the old behavior, we dispatch them explicitly in the implementation.
Reviewed By: mdvacca
Differential Revision: D49693966
fbshipit-source-id: 870118d0aeb5cfb4155eebf6afa7dfc724d4cecc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39760
Changelog: [Internal]
void functions are kinda special right now for the following reasons:
- they can be executed async or sync right now
- they don't return any value
thus, it makes sense for us to separate the invocation logic out and clean up the logic for retrieving return values specifically.
Reviewed By: javache
Differential Revision: D49652998
fbshipit-source-id: 7dba03adb8154e73ed75f8c2864294215c748107
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39805
## Changelog:
[Internal] -
This makes corresponsing text measure methods inside `TextLayoutManager` overridable, so that it can be substituted with a custom implementation without introducing a new "platform".
Rationale: CXX platform is rather general and less specific than Android or iOS, so we may potentially have multiple alternative implementations of text layout there.
An alternative could be making `TextLayoutManager` an interface across all the platforms, and actual implementations called e.g. `TextLayoutManagerImpl` in each of them, however this would be quite a bit bigger blast radius without much added benefit for Android/iOS.
Reviewed By: christophpurrer
Differential Revision: D49907594
fbshipit-source-id: dc8213ddb2313adaa86c2852d23bb038d80ac244
Summary:
We don't need this if-than-else because the initializeFlipper already checks if we're on bridgeless or not
Changelog:
[Internal] [Changed] - Do not guard initializeFlipper for bridgeless for RN Tester
Reviewed By: NickGerleman
Differential Revision: D49881903
fbshipit-source-id: e6bfc941b43382580bd418a5f27ad9426d300c69
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39809
It's currently possible for RN to crash the dev server by sending down an exceptionally large CDP response/event. Instead of making assumptions on the protocol spoken over the proxy, let's assume clients on either side of the proxy can be trusted to be well behaved (and to degrade gracefully when a large message is encountered).
Changelog: [General][Fixed] JS debugging: prevent dev server crash when a large CDP payload is returned from the device
Reviewed By: huntie
Differential Revision: D49642047
fbshipit-source-id: 07b134c9fa6aba7ce2208f71981d6d862281395f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39791
Bump `hermes-parser` packages to the latest released version.
Changelog: https://github.com/facebook/hermes/blob/main/tools/hermes-parser/js/CHANGELOG.md
Notable changes:
- Upgraded to the lastest version of emscripten for the parser.
- The babel interop logic now more closely matches babel's AST.
- The biggest change is we now add the `extra.raw` properties to literal nodes, which results in Babel more closely outputting literal sources. e.g. previously the following would happen `1.0` -> `1`, `'foo'` -> `"foo"` and `1n` -> `1` but now the raw source value is preserved.
- Upgraded `prettier-plugin-hermes-parser` to use the latest prettier formatting logic, which causes some minor formatting changes.
- `hermes-parser` no longer fails when the `component` name is used within a function type, e.g. `type Foo = (component: string) => void`.
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D49838842
fbshipit-source-id: ebfd2f89852d1bd3b1671ce77f58240d7e17cfbb
Summary:
Add support for `Platform.isMacCatalyst`
By default, Mac catalyst reports the idiom as an iPad, but you can check if it is Mac catalyst with a macro
There is technically the possibility to have the idiom return as a Mac, but that's not the default and almost definitely doesn't work in RN
ignore-github-export-checks
## Changelog:
[IOS] [ADDED] Add support for `Platform.isMacCatalyst`
Pull Request resolved: https://github.com/facebook/react-native/pull/38187
Test Plan: It compiles
Reviewed By: cortinico
Differential Revision: D47664425
Pulled By: cipolleschi
fbshipit-source-id: 09f43694aa9b5f980204474f0e07779acd5ed2c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39787
I've realized that some of the DevMenu strings were missing the `project="catalyst" translatable="false"`
tags so they ended up being fed to the translation pipeline.
We don't need those strings to be translated so I'm cleaning this up.
Changelog:
[Internal] [Changed] - Do not attempt to translate devsupport strings
Reviewed By: arushikesarwani94
Differential Revision: D49870688
fbshipit-source-id: 14188f4d391c7f8e2e6e92a394d85c58c8fbcf95
Summary:
https://github.com/facebook/react-native/commit/5f40f0800e64b4380d7897b2e8b9ff561d84b97c added a new prop and corresponding RCTConvert method for transformOrigin. Strangely, it added the RCTConvertMethod to a `RCTConvert+UIAccessibilityTraits` category.. which feels like the wrong spot for it. Let's just add it to the existing `RCTConvert+Transform` category. This also means we can get rid of the header if we move the `RCTTransformOrigin` struct into UIView+React (where it is used).
## Changelog:
[IOS][CHANGED] - Move `[RCTConvert RCTTransformOrigin:]` out of UIAccessibilityTraits category
Pull Request resolved: https://github.com/facebook/react-native/pull/39758
Test Plan:
Transform Origin example still works.
<img width="559" alt="Screenshot 2023-10-02 at 11 26 17 AM" src="https://github.com/facebook/react-native/assets/6722175/c7b863cc-3595-430d-8579-f8ce8e73c4f4">
Reviewed By: javache
Differential Revision: D49867993
Pulled By: NickGerleman
fbshipit-source-id: 1b2d5a9d08f0231040e7449f2eb75860f08bafa5
Summary:
This PR is in response to https://github.com/facebook/react-native/pull/39758#discussion_r1344839022 .
`RCTConvert.h` currently takes an import of `<Webkit/Webkit.h>` for... one enum: `WKDataDetectorTypes`. This has a few problems:
1) RCTConvert is JS engine agnostic, it shouldn't be depending on Webkit
2) As far as I can tell, this code is dead, we also define (and use) the UIKit equivalent `UIDataDetectorTypes`.
Let's just combine the two, update some JS typing, and get rid of the Webkit header import.
## Changelog:
[IOS] [CHANGED] - Remove `<Webkit/Webkit.h>` import in `RCTConvert.h`
Pull Request resolved: https://github.com/facebook/react-native/pull/39794
Test Plan: CI should pass
Reviewed By: rshest
Differential Revision: D49898701
Pulled By: NickGerleman
fbshipit-source-id: 5420cb62317e1186426aae019bcc43d27c49ea26
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39806
Same issue of the previous fix: jobs do not run by default on tagged build. I forgot to add the filter parameter in the jobs that build the slices for Hermes and packages it and therefore the build failed.
I added those filters, so now we should be able to release RC.1.
What puzzles me is how it is possible that the publish-npm jobs even started, given that it was set up to depends on a job called build_hermes_macos which was not executed in the pipeline. 🤔https://pxl.cl/3w2rr
## Changelog:
[Internal] - Make sure that the Hermes jobs starts when releasing
Reviewed By: dmytrorykun
Differential Revision: D49906898
fbshipit-source-id: ebbceb6cbc4dcd2ac22445610da1c52000c8ae2a
Summary:
Rewrite `RNTesterApplication` to Kotlin as per [Help us Kotlin-ify React Native tests - Round 2](https://github.com/facebook/react-native/issues/38825)
## Changelog:
[ANDROID] [CHANGED] - Rewrite RNTesterApplication to Kotlin, add AnnotationTarget property.
Pull Request resolved: https://github.com/facebook/react-native/pull/39557
Test Plan:
`yarn && yarn android` ✅
The only thing I'm kinda unsure of is whether `AnnotationTarget.PROPERTY` should be added, but it didn't let me annotate `reactHostInterface` without that and didn't compile.
<img width="637" alt="image" src="https://github.com/facebook/react-native/assets/33528752/8bc84870-f3f2-4a46-b076-6ee7e38bd735">
cortinico mdvacca
Reviewed By: cortinico
Differential Revision: D49598401
Pulled By: mdvacca
fbshipit-source-id: 105ae0c13c93dae0eeb2b6fa9040f03f42d2736a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39788
Hotfix for exiting `npx react-native start` when a session is connected. Partially reverts D49422206.
This lines back up with the original RN CLI and Expo implementations — explicitly calling `process.exit()`. We still aim to follow this up with graceful server shutdown.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D49880226
fbshipit-source-id: d2c76b2de21b9172dfd892141d1f679b808e043d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39595
X-link: https://github.com/facebook/yoga/pull/1404
These functions all ensure their returns are defined, but return FloatOptional anyway, making their callers have to deal with that possibility. Return `float` instead of `FloatOptional`, and do some additional cleanup.
Reviewed By: rshest
Differential Revision: D49531421
fbshipit-source-id: 95b21cade74e501dd54c7b6ca667c8c3859c5dae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39644
This makes Android Paper/Classic renderer fire `onLayout` events top down, like in Fabric/new Architecture. This gives a much more sane model for using layout events to calculate bottom/right-edge insets.
I was under the impression that Paper in general was bottom-up, but it turns out that is only true for Android and Windows (iOS seems totally deterministic).
This is a behavior change, but to my knowledge was never hit during the Fabric migration, and any JS code already written for both Android and iOS cannot make assumptions here anyways.
Changelog:
[General][Changed] - Make layout events top-down on Android classic renderer
Reviewed By: mdvacca
Differential Revision: D49627996
fbshipit-source-id: 29964b421dd420681d45348c7db16f211a6c087f
Summary:
The Loading.../Refreshing... indicator is currently broken on Android.
The reason is related to D42599220
We used to have a Toast shown to users on Android as a fallback, but as the
DevLoadingView is not always loaded as a module in the core package, this ends up in the banner never beign shown to the user (on RN Tester or template apps).
Changelog:
[Android] [Fixed] - Fix broken Loading/Refreshing indicator on Android
Reviewed By: cipolleschi
Differential Revision: D49876757
fbshipit-source-id: 400e002327ebca908e3e7a7f81c5066888ac4e9b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39591
Changelog: [Internal]
I'm refactoring this for a couple of reasons:
1) it isolates the void execution path, which we are changing now
2) switch case is safer than if else, in the future if we introduce new return types
Reviewed By: RSNara
Differential Revision: D49521866
fbshipit-source-id: 451c846ca15cc470cfeb5b2326d6eb2ffec74b25
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39589
Changelog: [Internal]
currently, turbomodule void methods run async by default, unless the consumer returns `RCTJSThread` in the `methodQueue` API.
we're looking to update this, so i'm introducing a flag at the module level that allows us to configure this behavior.
Reviewed By: RSNara
Differential Revision: D49521864
fbshipit-source-id: a6c61eb420b72199426e3dfdaec5fd090847efa5
Summary:
While inspecting the pipelines for the template, I realized that the caching was failing because the keys were malformed.
This PR fixes the malformed keys adding the missing "
## Changelog:
[Internal] - Fix cache keys for the Template
Pull Request resolved: https://github.com/facebook/react-native/pull/39786
Test Plan: The template jobs should not fail with `error computing cache key: template: cacheKey:1: unterminated quoted string`
Reviewed By: cortinico
Differential Revision: D49874270
Pulled By: cipolleschi
fbshipit-source-id: 5a23237ba826e87f2cd15566e63a1316291af595
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39597
X-link: https://github.com/facebook/yoga/pull/1406
Similar in vain to D49362819, we want to stop exposing pre-resolved CompactValue, and allow enum class usage without becoming annoying.
This also simplifies gap resolution a bit. I moved this to Style, to make it clear we aren't relying on any node state. I plan to do some similar cleanup for other resolution later.
Reviewed By: rshest
Differential Revision: D49530923
fbshipit-source-id: 47b06a7301fb283acc493dba159f496159d59580
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39775
ChoreographerCompat existed to support JellyBean, but given we target Android SDK 23+ now, this is safe to remove.
Changelog: [Android][Removed] Deprecated ChoreographerCompat.FrameCallback, use Choreographer.FrameCallback
Reviewed By: mdvacca
Differential Revision: D49826889
fbshipit-source-id: 5158c470553327b70a199168f5b7ed7071cc8c48
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39717
AsyncCallback is a better abstraction than the current usage of WeakCallbackWrapper and RAIICallbackWrapperDestroyer, and has way fewer gotchas. Making a few changes here to make it easier to use in various scenarios and match the behaviour we're already seeing in CallbackWrapper.
1) Remove the explicit copy constructor, since this prevents an automatic move constructor from being generated
2) Add a call variant which takes a lambda, for callers which need to manually create JSI arguments
3) Ignore AsyncCallback invocations when the underlying runtime has gone away.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D49684248
fbshipit-source-id: 8b49ec22cc409572ead80a85b10a190994bf0dd5
Summary:
If the first element of a line is not contributing (e.g. position absolute), an additional gap will be added to the line, because the first gap element of the line is never identified (wrong start index).
Fix: raise the index of the first line element until we find an element that is contributing to the line.
X-link: https://github.com/facebook/yoga/pull/1408
Reviewed By: yungsters
Differential Revision: D49722065
Pulled By: NickGerleman
fbshipit-source-id: 1068cb0b11ae4b04ec8d063e70540cce06181d5a
Summary:
CircleCI does not run jobs on tags by default. However, when we release a new version of React Native, we push a tag and we want to create a release from that tag only ([CircleCI Docs](https://circleci.com/docs/workflows/#executing-workflows-for-a-git-tag)).
The release job is already configured to run on tag. However, in August, we moved to the CircleCI continuation APIs and the starting job of the pipeline was not set up to run
also on tags.
This change fixes the issue, making the Choose CI Job run also on tags.
## Changelog:
[Internal] - Make the Choose CI Job run also on tags
Pull Request resolved: https://github.com/facebook/react-native/pull/39776
Test Plan:
Tested manually on CircleCI in a separate branch with a test tag (which have been then removed).
See commit history in this PR: https://github.com/facebook/react-native/pull/39774
Reviewed By: dmytrorykun
Differential Revision: D49863095
Pulled By: cipolleschi
fbshipit-source-id: 89c4eaa9903c02322056a4b57f56a24865a58b46
Summary:
These tests seem to have been deprecated for years, let's just remove them.
## Changelog:
[IOS] [REMOVED] - Remove deprecated Snapshot tests
Pull Request resolved: https://github.com/facebook/react-native/pull/39720
Test Plan: CI should pass
Reviewed By: cipolleschi
Differential Revision: D49809496
Pulled By: NickGerleman
fbshipit-source-id: d79f0a0896b190d071bda1eb837b3efa10dbbf3b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39771
We now support SDK 23 as a minimum. That means we can drop JS side checks.
Because Android has `Platform.Version` as a number, and iOS as a string, it's common to do an Android check before checking version, even if in Android only code. I tried to remove those where it was super clear the code was Android only (i.e. the file is `.android.js`), but otherwise leave the Android platform check to not give the possibility of changing behavior.
Changelog:
[Internal]
Reviewed By: luluwu2032
Differential Revision: D49814610
fbshipit-source-id: f28b09db7091598e187fee0f383561e1c1993e9a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39755
The goal of this diff is to fix:
```
JNI DETECTED ERROR IN APPLICATION: JNI NewGlobalRef called with pending exception java.lang.NoSuchMethodError: no static or non-static method
"Lcom/facebook/react/jscexecutor/JSCExecutor;.initHybrid(Lcom/facebook/react/bridge/ReadableNativeMap;)Lcom/facebook/jni/HybridData;"
```
changelog: [internal] internal
Reviewed By: luluwu2032
Differential Revision: D49831595
fbshipit-source-id: 9ce22cdccdd02af74edb27be2df72a469d3166c9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39704
Default to native view configs in bridged mode and to static view configs in bridgeless mode.
Remove `setRuntimeConfigProvider` calls from RNTester and from the Template.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D49687252
fbshipit-source-id: 140e1c510ba3fbc153978b59c8bb4b4e35bc7571
Summary:
Changelog: [Internal] - Set the hermes value as specified by the test-e2e-local script flag. Right now, the script incorrectly ignores the flag
By default, the template project has `hermesEnabled=true`
Reviewed By: cipolleschi
Differential Revision: D49831355
fbshipit-source-id: 7fb8613fa86f2c6140b7d25b16aeb583e6e26c12
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39751
There doesn't seem to be an easy way to drop `folly::makeMoveWrapper` for the reasons explained in below in the diff.
To unblock the folly deprecation in the RN codebase, we are copying the `MoveWrapper` class within the RN codebase.
Changelog: [Internal]
Reviewed By: sammy-SC, cipolleschi
Differential Revision: D49423389
fbshipit-source-id: 8abaa95a6d675b069be8e74933aa8c63f4ea43ee
Summary:
Addresses this issue: https://github.com/facebook/react-native/issues/39708
The embedded docs for `PixelRatio.getFontScale` haven't been updated in a while and it is still claiming lack of support for iOS when this is not the reality anymore. This was confusing for me when looking for docs through my local workspace.
## Changelog:
[INTERNAL] [CHANGED] - Updated PixelRatio.getFontScale docs to match the latest website
Pull Request resolved: https://github.com/facebook/react-native/pull/39709
Test Plan: N/A
Reviewed By: rshest
Differential Revision: D49752103
Pulled By: NickGerleman
fbshipit-source-id: 1b220bc0210639d7863b6961f665aab2cba52889
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39746
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
changelog: [Android][Changed] Reducing visibility of PerformanceCounter
Reviewed By: arushikesarwani94
Differential Revision: D49803283
fbshipit-source-id: 46d041f632f06a98392f4a67c839266010a1c68d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39744
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
changelog: [Android][Changed] Reducing visibility of NativeArrayInterface
Reviewed By: arushikesarwani94
Differential Revision: D49803296
fbshipit-source-id: b0065d3df8ef5f20b71f66caf45856440dd61d80
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39736
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
changelog: [Android][Changed] Reducing visibility of NativeArgumentsParseException
Reviewed By: RSNara
Differential Revision: D49752145
fbshipit-source-id: 0ceb560a9be7d162b6856d90f57f6bda3888c6e7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39738
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
changelog: [Android][Changed] Reducing visibility of JSInstance
Reviewed By: RSNara
Differential Revision: D49752139
fbshipit-source-id: b56667a91abd16d15a321dfc3e83026b596eaad3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39740
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
changelog: [Android][Changed] Reducing visibility of JSIModuleRegistry.
Reviewed By: RSNara
Differential Revision: D49752138
fbshipit-source-id: 9878a3c2c431a2a84d4985812605032ed0d2d2d8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39741
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
changelog: [Android][Changed] Reducing visibility of JSIModuleHolder
Reviewed By: RSNara
Differential Revision: D49752136
fbshipit-source-id: a2b525e6fe18f2ceabbe8775d6841807d73cdc86
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39737
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
changelog: [Android][Changed] Reducing visibility of JSCJavaScriptExecutorFactory
Reviewed By: RSNara
Differential Revision: D49752141
fbshipit-source-id: 77039a3b4c3d12f3c98e3659518e9ef10c66a29e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39739
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
changelog: [Android][Changed] Reducing visibility of DynamicFromMap
Reviewed By: RSNara
Differential Revision: D49752137
fbshipit-source-id: 6bc8623ca1a8479401b4d8314916f968d708f40c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39735
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
changelog: [Android][Changed] Reducing visibility of DynamicFromArray
Reviewed By: RSNara
Differential Revision: D49752134
fbshipit-source-id: 818a2cb0f4cafaad9c13c9b623505f32fb1ebcfe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39565
CompositeReactPackage is not used at Meta neither in github public repositories, we are deprecating it in v0.73 with the goal to remove it in v0.74
changelog: [Android][Breaking] Deprecate CompositeReactPackage from RN Android
Reviewed By: christophpurrer
Differential Revision: D49440130
fbshipit-source-id: 6a9c220f57fd29f7a530db79c4f76ef169744fba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39726
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
changelog: [Android][Changed] Reducing visibility of DecayAnimation
Reviewed By: javache, RSNara
Differential Revision: D49752144
fbshipit-source-id: 94b69f3f2d780aff55f0dbcf030d15199b703abd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39730
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
changelog: [Android][Changed] Reducing visibility of AnimatedNodeWithUpdateableConfig
Reviewed By: RSNara
Differential Revision: D49752143
fbshipit-source-id: 023fb7657d922b2bd7ad8e12640e67bc82c96185
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39727
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
changelog: [Android][Changed] Reducing visibility of AnimatedNodeValueListener
Reviewed By: RSNara
Differential Revision: D49752131
fbshipit-source-id: 153cf0cb97ceadfd4c6acde1e1b51d4243eb5df6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39728
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
changelog: [Android][Changed] Reducing visibility of ReactPackageHelper
Reviewed By: RSNara
Differential Revision: D49752142
fbshipit-source-id: d21812609a946faf2f9183993f28192dda34e132
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39729
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
changelog: [Android][Changed] Reducing visibility of ReactTextInputKeyPressEvent
Reviewed By: RSNara
Differential Revision: D49752135
fbshipit-source-id: 0d00d6558c3e259977c26a53cbb8fe7c5ae6235d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39731
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
changelog: [Android][Changed] Reducing visibility of ReactAndroidHWInputDeviceHelper
Reviewed By: RSNara
Differential Revision: D49752132
fbshipit-source-id: 3eadc01f05f5ce49b4019fa8c3dafe8d5f5fc1f3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39732
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
changelog: [Android][Changed] Reducing visibility of EagerModuleProvider
Reviewed By: RSNara
Differential Revision: D49752133
fbshipit-source-id: 3d24d471753bbf3857ecf6105a95f90305ac492d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39725
In an attempt to reduce footprint of React Native Android public APIs we are reducing visibility of classes and interfaces that are not meant to be used publicly OR are public but have no usages.
As part of our analysis, which involved looking for usages inside the Meta codebase and code search in OSS, we've detected that this class/interface is public but it's not used from other packages.
If you are using this class or interface please comment in this PR and we will restate the public access.
changelog: [Android][Changed] Reducing visibility of CanvasUtil
Reviewed By: RSNara
Differential Revision: D49752146
fbshipit-source-id: 26fbcd20b7a9db52043978ca86879c6f6cd7a8db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39678
Since minsdk version was increased to 23, we are deleting code using Android APIs < 23 for class ReactViewManager
bypass-github-export-checks
changelog: [Android][Breaking] Remove support for Android API < 23 in ReactViewManager
Reviewed By: NickGerleman
Differential Revision: D48545513
fbshipit-source-id: fba0212cc832b6b309ae0bfb45c0e08bf79bd5d1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39667
Since minsdk version was increased to 23, we are deleting code using Android APIs < 23 for class ReactDrawableHelper
bypass-github-export-checks
changelog: [Android][Breaking] Remove support for Android API < 23 in ReactDrawableHelper
Reviewed By: NickGerleman
Differential Revision: D48545508
fbshipit-source-id: df15ad8dcf0ec94abd8291b8cb180be18771809d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39686
Since minsdk version was increased to 23, we are deleting code using Android APIs < 23 for class ReactTextInputShadowNode
changelog: [Android][Breaking] Remove support for Android API < 23 in ReactTextInputShadowNode
Reviewed By: NickGerleman
Differential Revision: D48545503
fbshipit-source-id: f3b4fb696c3abf1f20ab00a89e786b3787c1b0e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39670
Since minsdk version was increased to 23, we are deleting code using Android APIs < 23 for class ReactTextInputLocalData
bypass-github-export-checks
changelog: [Android][Breaking] Remove support for Android API < 23 in ReactTextInputLocalData
Reviewed By: NickGerleman
Differential Revision: D48545510
fbshipit-source-id: 8601a30a58d0e74c51b7d5dc8cec9e92e65344d8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39671
Since minsdk version was increased to 23, we are deleting code using Android APIs < 23 for class ReactEditText
changelog: [Android][Breaking] Remove support for Android API < 23 in ReactEditText
Reviewed By: NickGerleman
Differential Revision: D48545507
fbshipit-source-id: 98be52ba36248962864e99e80ff648bbb351ff61
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39677
Since minsdk version was increased to 23, we are deleting code using Android APIs < 23 for class TextLayoutManagerMapBuffer
bypass-github-export-checks
changelog: [Android][Breaking] Remove support for Android API < 23 in TextLayoutManagerMapBuffer
Reviewed By: NickGerleman
Differential Revision: D48545518
fbshipit-source-id: fe64730c40ddf42aab0a7f5a19e51eecea4c4bcd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39679
Since minsdk version was increased to 23, we are deleting code using Android APIs < 23 for class TextLayoutManager
bypass-github-export-checks
changelog: [Android][Breaking] Remove support for Android API < 23 in TextLayoutManager
Reviewed By: NickGerleman
Differential Revision: D48545502
fbshipit-source-id: b478013bfaf71264a1009669a10d9e8dfb396802
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39674
Since minsdk version was increased to 23, we are deleting code using Android APIs < 23 for class TextAttributeProps
bypass-github-export-checks
changelog: [Android][Breaking] Remove support for Android API < 23 in TextAttributeProps
Reviewed By: NickGerleman
Differential Revision: D48545514
fbshipit-source-id: 38e5560fdb24f1807abc6f458b882d1a5d6d051c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39666
Since minsdk version was increased to 23, we are deleting code using Android APIs < 23 for class ReactTextView
bypass-github-export-checks
changelog: [Android][Breaking] Remove support for Android API < 23 in ReactTextView
Reviewed By: NickGerleman
Differential Revision: D48545504
fbshipit-source-id: a37d8532f879ff32626b256c9c1386d04e27cbcd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39675
Since minsdk version was increased to 23, we are deleting code using Android APIs < 23 for class ReactTextShadowNode
bypass-github-export-checks
changelog: [Android][Breaking] Remove support for Android API < 23 in ReactTextShadowNode
Reviewed By: NickGerleman
Differential Revision: D48545511
fbshipit-source-id: c0462ee72746be73bb3acdf0c2336353e65da57a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39710
Last week Apple released Xcode 15, which required us to ship a workaround for the new linker.
Unfortunately, the previous fix was not good enough and there were some edge cases that were not covered.
For example, in some occasions the flags are read as an array and the `-Wl` and the `-ld_classic` flags were separated and not properly removed when moving from Xcode 15 to Xcpde 14.3.1.
This change fixes those edge cases, with a more robust solution where:
- We convert the flags to a string.
- We trim the string and the values properly.
- We add the flags when running `pod install` with Xcode 15 as the default iOS toolchain.
- We remove the flags when running `pod install` with Xcode <15 as the default iOS toolchain.
## Changelog:
[Internal] - Make the Xcode 15 workaround more robust.
Reviewed By: dmytrorykun
Differential Revision: D49748844
fbshipit-source-id: 34976d148f123c5aacba6487a500874bb938fe99
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39598
X-link: https://github.com/facebook/yoga/pull/1403
Replaces all usages of YGDimension with Dimension.
Adds `yoga::to_underlying` to act like `std::to_underlying`, added in C++ 23.
This enum is oddly only used internally, and is never an input to the public API, but it handled as any other public generated enum. Potentially some more cleanup to do there.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D49475409
fbshipit-source-id: 7d4c31e8a84485baea0dab50b5cf16b86769fa07
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39701
TextInput already uses Pressability, but doesn't expose the onPress prop. Link:https://github.com/facebook/react-native/blob/main/packages/react-native/Libraries/Components/TextInput/TextInput.js#L1381-L1414.
Currently TextInput only exposes the onPressIn() and onPressOut() props from Pressability. While onPressOut() can serve the same purpose as onPress() in most cases, it doesn't fare well with PanResponder...say a swipe gesture implemented using PanResponder.
When the pointer/cursor exits the hit test bounds of TextInput, onPressOut() will be triggered even though the desired behavior could be that we only want to invoke the event handler when the user lifts their finger from the screen (while still in the hit test bounds of the TextInput).
Example of TextInput in a PanResponder:
https://snack.expo.dev/jambalaya/panresponder
Changelog: [General][Added] Add onPress prop to TextInput
Reviewed By: NickGerleman
Differential Revision: D49653011
fbshipit-source-id: 28477416c6c0f17a0737986cab49e51a55094ba7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39676
Since minsdk version was increased to 23, we are deleting code using Android APIs < 23 for class ReactTextAnchorViewManager
changelog: [Android][Breaking] Remove support for Android API < 23 in ReactTextAnchorViewManager
Reviewed By: NickGerleman
Differential Revision: D48545519
fbshipit-source-id: 4eca438fa9b33314c495f2181559c8f0ce6fd93f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39665
Since minsdk version was increased to 23, we are deleting code using Android APIs < 23 for class ReactBaseTextShadowNode
changelog: [Android][Breaking] Remove support for Android API < 23 in ReactBaseTextShadowNode
Reviewed By: NickGerleman
Differential Revision: D48545509
fbshipit-source-id: 2bd1c74251c8af92013b065daafbab3d96a05a2e
Summary:
Thanks for working through Xcode 15 compatibility issues!
I reviewed the diff of the PR (https://github.com/facebook/react-native/issues/39474) that altered Xcode 15 settings for react-native release 0.72.5 and I noticed that
- everything looked great (worth saying)
- there was a grammatical error in another of the method names
Trivial errors but, as long as I was in there, thought I'd submit a PR
## Changelog:
[IOS] [FIXED] - fix grammar in Xcode 15 helper method name
Pull Request resolved: https://github.com/facebook/react-native/pull/39658
Test Plan: CI should catch it of course, but in general I did a full grep for the name and changed everything / typical method name refactor
Reviewed By: cortinico
Differential Revision: D49641551
Pulled By: cipolleschi
fbshipit-source-id: d77d33bbd6941f039dd30766e1308d5c4c4a6ca8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39669
Since minsdk version was increased to 23, we are deleting code using Android APIs < 23 for class StatusBarModule
changelog: [Android][Breaking] Remove support for Android API < 23 in StatusBarModule
Reviewed By: NickGerleman
Differential Revision: D48545516
fbshipit-source-id: ff79ac0d515b9a731c1c4ed861a73ce7998cb7f8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39680
Since minsdk version was increased to 23, we are deleting code using Android APIs < 23 for class PermissionsModule
changelog: [Android][Breaking] Remove support for Android API < 23 in PermissionsModule
Reviewed By: NickGerleman
Differential Revision: D48545517
fbshipit-source-id: 1ead079689aee5fd42d2b0bc530b7f69780938ff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39672
Since minsdk version was increased to 23, we are deleting code using Android APIs < 23 for class RequestBodyUtil
changelog: [Android][Breaking] Remove support for Android API < 23 in RequestBodyUtil
Reviewed By: NickGerleman
Differential Revision: D48545515
fbshipit-source-id: 8cc82a234cdb37304ad0d383ad57a7ce0de50a0e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39673
Since minsdk version was increased to 23, we are deleting code using Android APIs < 23 for class WindowOverlayCompat
changelog: [Android][Breaking] Remove support for Android API < 23 in WindowOverlayCompat
Reviewed By: NickGerleman
Differential Revision: D48545505
fbshipit-source-id: 51246bbe5c78efc3cf7d3f1cf0a4ab31cb9c0b5c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39664
Since minsdk version was increased to 23, we are deleting code using Android APIs < 23 for class DebugOverlayController
changelog: [Android][Breaking] Remove support for Android API < 23 in DebugOverlayController
Reviewed By: NickGerleman
Differential Revision: D48545520
fbshipit-source-id: 3a1140a46310c617610ff1e0c40b02427357087a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39668
Since minsdk version was increased to 23, we are deleting code using Android APIs < 23 for class ReactFragment
changelog: [Android][Breaking] Remove support for Android API < 23 in ReactFragment
Reviewed By: NickGerleman
Differential Revision: D48545506
fbshipit-source-id: 9b5e335eae8ca11aac580c14c31431ca87eb11a2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39663
Since minSDK was bumped to Android API 23 we are removing support of code using Android API <23 in
changelog: [Android][Breaking] Remove support for Android API < 23 in
Reviewed By: NickGerleman
Differential Revision: D48545501
fbshipit-source-id: fa0dd69c3506e80eb1a4353d497b911b5d43c8c8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38874
In this diff I'm increasing the minSdk of RN Android to 23 to keep it in sync with Meta min sdk
changelog: [Android][Breaking] Increase min sdk version of RN Android to 23
Reviewed By: fkgozali, NickGerleman
Differential Revision: D48177965
fbshipit-source-id: 79f46f6e1674fe9d38dc9dfbe8f0f9a43f39a712
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39690
This diff re-introduces the test for the TurboModule interop layer.
This test was originally reverted in D49200360, because it was broken.
***New:*** This test runs in Bridgeless mode, with the interop layer enabled. (Catalyst is now native mobileconfig ready).
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D49208528
fbshipit-source-id: 3109d7826e7024fd7a1074321d4aab8f3a489609
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39696
`Commands` and `Constants` should be set in native only if component data is instantiated via native view config interop layer.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D49684166
fbshipit-source-id: ceaa29c2ed3336aa6e21a116a3f5f94e03c225c1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39611
I'm renaming onCatalystInstanceDestroy -> invalidate, this is necessary to converge TurboModuleRegistry -> turboModuleManager in the next diffs of the stack
changelog: [intenral] internal
Reviewed By: arushikesarwani94
Differential Revision: D49469208
fbshipit-source-id: 877c5af6ad0fc378ec9cbd952f33db0ea08f761c
Summary:
This diff is reverting D49509633
D49509633: [react-native][PR] fix: Text cut off issues when adjusting text size and font weight in system settings by ryancat has been identified to be causing the following test or build failures:
Tests affected:
- [xplat/endtoend/jest-e2e/apps/facebook_xplat/ReactNativeTTRCTester/__tests__/ReactNativeTTRCTester-errorReportedManually-android-e2e.js](https://www.internalfb.com/intern/test/281475019301157/)
Here's the Multisect link:
https://www.internalfb.com/multisect/3131615
Here are the tasks that are relevant to this breakage:
We're generating a revert to back out the changes in this diff, please note the backout may land if someone accepts it.
If you believe this diff has been generated in error you may Commandeer and Abandon it.
Reviewed By: NickGerleman
Differential Revision: D49645585
fbshipit-source-id: 414531e067cffa109d0663d6af185dcaf8fb9c4e
Summary:
Fix https://github.com/facebook/react-native/issues/31537: [Android] React Native strips non-ASCII characters from HTTP headers
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Changed] - Allow non-ascii header values on Android and add utf-8 filename fallback in FormData
Pull Request resolved: https://github.com/facebook/react-native/pull/35060
Test Plan:
1. Clone the `react-native` repo.
2. Build the rn-tester app.
3. Prepare tests
1. Add `android:usesCleartextTraffic="true"` to AndroidManifest.xml
2. Use the following code as a server:
```javascript
const http = require('http');
const requestListener = function (req, res) {
// raw header value
console.log(req.headers['content-disposition']);
// nodejs assumes the header value is ISO-8859-1 encoded
console.log(Buffer.from(req.headers['content-disposition'], 'latin1').toString('utf-8'));
// decode encoded header value if it's sent as UTF-8
console.log(decodeURI(req.headers['content-disposition']));
res.writeHead(200);
res.end();
};
const server = http.createServer(requestListener);
server.listen(3000);
```
3. Run `adb reverse tcp:3000 tcp:3000` to connect the 3000 port on the emulator if necessary.
4. Edit `RNTesterAppShared.js` to include test code:
```javascript
useEffect(() => {
fetch('http://localhost:3000/', {
headers: {
'Content-Type': 'multipart/form-data; charset=utf-8',
'Content-Disposition': `attachment; filename*=utf-8''${encodeURI(
'filename测试abc.jpg',
)}`,
},
}).then(res => {
console.log(res.ok);
});
fetch('http://localhost:3000/', {
headers: {
'Content-Type': 'multipart/form-data; charset=utf-8',
'Content-Disposition': `attachment; filename="filename测试abc.jpg"`,
},
}).then(res => {
console.log(res.ok);
});
}, []);
```
5. Both requests should succeed; without the fix, the second request received by the server will not have the utf-8 characters "测试" in the header value.
Reviewed By: NickGerleman
Differential Revision: D40639985
Pulled By: cortinico
fbshipit-source-id: 005f2481976046a92a26239ad704780ac58d4a44
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39638
# Changelog:
[Internal] - Removing usage of stringByAddingPercentEscapesUsingEncoding
Per deprecation message:
> 'stringByAddingPercentEscapesUsingEncoding:' is deprecated: first deprecated in iOS 9.0 - Use -stringByAddingPercentEncodingWithAllowedCharacters: instead, which always uses the recommended UTF-8 encoding, and which encodes for a specific URL component or subcomponent since each URL component or subcomponent has different rules for what characters are valid.
Reviewed By: cipolleschi
Differential Revision: D49610243
fbshipit-source-id: 7c40ce9f6b643851c8aae8149acde2c435c06a76
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39593
Looking into a crash leads by assertion error in this line, I talked to NickGerleman and we think there might be some case when ContentView is not rendered, so it would have 0 child. Changing the assertion to allow 0 child.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D49508540
fbshipit-source-id: 43c50814ead24332c1b24ff2dea50d564519034b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39662
Hermesc is built with the build script that is executed by Xcode as a "Run script" build phase. For every build Xcode configures environment based on the build target. The Hermesc build script runs in that environment.
**The problem**
If we build for iPhone of iPhone Simulator, then the environment is configured for these platforms, but Hermesc must always be built for macosx.
**The old solution**
Previously we experimentally determined what envvars should be changed for Hermesc build to succeed. But it is not robust, because this may change with new Xcode releases.
**The new solution**
We clear the entire environment and only define `SDKROOT`. This is equivalent to running Cmake outside of Xcode.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D49639599
fbshipit-source-id: f8d8fccb0e61605b1fef9927dc4a3fdf79e4f212
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39640
changelog: [internal] internal
Reducing visibility from public to package only for `ReactHostImpl.getDefaultHardwareBackBtnHandler()` since it's only used within package
Reviewed By: mdvacca
Differential Revision: D49612859
fbshipit-source-id: 3c40888da732f33dc046d9363b08119e707f4ea4
2023-09-26 07:30:41 -07:00
4786 changed files with 289391 additions and 199193 deletions
This directory is home to the Circle CI configuration file. Circle is our continuous integration service provider. You can see the overall status of React Native's builds at https://circleci.com/gh/facebook/react-native
You may also see an individual PR's build status by scrolling down to the Checks section in the PR.
This directory was home to the Circle CI configuration files.
In July 2024 we moved to GitHub Actions, and week this folder for backward compatibility, as we want to keep on using Circle CI for the release of React Native <= 0.74.
description:Report a reproducible bug or regression in React Native.
labels:["Needs: Triage :mag:"]
body:
- type:markdown
attributes:
value:"## Reporting a bug to React Native"
- type:markdown
attributes:
value:|
Please provide all the information requested. Issues that do not follow this format are likely to stall.
Thank you for taking the time to report an issue for React Native, your contribution will help
make the framework better for everyone.
Before you continue:
* If you're using **Expo** and you're noticing a bug, [report it here](https://github.com/expo/expo/issues).
* If you're found a problem with our **documentation**, [report it here](https://github.com/facebook/react-native-website/issues/).
* If you're having an issue with **Metro** (the bundler), [report it here](https://github.com/facebook/metro/issues/).
* If you're using an external library, report the issue to the **library first**.
* Please [search for similar issues](https://github.com/facebook/react-native/issues) in our issue tracker.
Make sure that your issue:
* Have a **valid reproducer** (either a [Expo Snack](https://snack.expo.dev/) or a [empty project from template](https://github.com/react-native-community/reproducer-react-native).
* Is tested against the [**latest stable**](https://github.com/facebook/react-native/releases/) of React Native.
Due to the extreme number of bugs we receive, we will be looking **ONLY** into issues with a reproducer, and on [supported versions](https://github.com/reactwg/react-native-releases#which-versions-are-currently-supported) of React Native.
- type:textarea
id:description
attributes:
label:Description
description:Please provide a clear and concise description of what the bug is. Include screenshots if needed. Test using the [latest React Native release](https://github.com/facebook/react-native/releases/latest) to make sure your issue has not already been fixed.
description:A clear and concise description of what the bug is.
validations:
required:true
- type:textarea
id:reproduction
attributes:
label:Steps to reproduce
description:The list of steps that reproduce the issue.
placeholder:|
1. Install the application with `yarn android`
2. Click on the button on the Home
3. Notice the crash
validations:
required:true
- type:input
id:version
attributes:
label:React Native Version
description:What is the latest version of react-native that this issue reproduces on? Please only list the highest version you tested. Bear in mind that only issues on [supported versions](https://github.com/reactwg/react-native-releases#which-versions-are-currently-supported) will be looked into.
placeholder:ex. 0.71.0
description:The version of react-native that this issue reproduces on. Bear in mind that only issues on [supported versions](https://github.com/reactwg/react-native-releases#which-versions-are-currently-supported) will be looked into.
placeholder:"0.73.0"
validations:
required:true
- type:dropdown
id:platforms
attributes:
label:Affected Platforms
description:Please select which platform you're developing to, and which OS you're using for building.
multiple:true
options:
- Runtime - Android
- Runtime - iOS
- Runtime - Web
- Runtime - Desktop
- Build - MacOS
- Build - Windows
- Build - Linux
- Other (please specify)
validations:
required:true
- type:textarea
@@ -26,23 +71,53 @@ body:
attributes:
label:Output of `npx react-native info`
description:Run `npx react-native info` in your terminal, copy and paste the results here.
placeholder:|
Paste the output of `npx react-native info` here. The output looks like:
...
System:
OS: macOS 14.1.1
CPU: (10) arm64 Apple M1 Max
Memory: 417.81 MB / 64.00 GB
Shell:
version: "5.9"
path: /bin/zsh
Binaries:
Node: ...
version: 18.14.0
...
render:text
validations:
required:true
- type:textarea
id:reproduction
id:stacktrace
attributes:
label:Steps to reproduce
description:Provide a detailed list of steps that reproduce the issue.
label:Stacktrace or Logs
description:Please provide a stacktrace or a log of your crash or failure
render:text
placeholder:|
Paste your stacktraces and logs here. They might look like:
at com.facebook.soloader.SoLoader.g(Unknown Source:341)
at com.facebook.soloader.SoLoader.t(Unknown Source:124)
at com.facebook.soloader.SoLoader.s(Unknown Source:2)
at com.facebook.soloader.SoLoader.q(Unknown Source:42)
at com.facebook.soloader.SoLoader.p(Unknown Source:1)
...
validations:
required:true
- type:input
id:reproducer
attributes:
label:Reproducer
description:A link to a Expo Snack or a public repository that reproduces this bug, using [this template](https://github.com/react-native-community/reproducer-react-native). Reproducers are **mandatory**.
about:Please report documentation issues in the React Native website repository.
- name:📦 Metro Issue
url:https://github.com/facebook/metro/issues/new
about:|
If you've encountered a module resolution problem, e.g. "Error: Unable to resolve module ...", or something else that might be related to Metro, please open an issue in the Metro repo instead.
description:Report a reproducible bug or a build issue when using the New Architecture (Fabric & TurboModules) in React Native.
labels:["Needs: Triage :mag:","Type: New Architecture"]
body:
- type:markdown
attributes:
value:"## New Architecture Related Bugs"
- type:markdown
attributes:
value:|
Please provide all the information requested. Issues that do not follow this format are going to be closed.
This issue report is reserved to bug & build issues for users on the New Architecture. If you're not using
the New Architecture, please don't open issues on this category.
Thank you for taking the time to report an issue for [the New Architecture of React Native](https://reactnative.dev/docs/the-new-architecture/landing-page),
your contribution will help make the framework better for everyone.
If you're **NOT** using the New Architecture, please use this [other bug type](https://github.com/facebook/react-native/issues/new?template=bug_report.yml).
Do not attempt to open a bug in this category if you're not using the New Architecture as your bug will be closed.
Make sure that your issue:
* Have a **valid reproducer** (either a [Expo Snack](https://snack.expo.dev/) or a [empty project from template](https://github.com/react-native-community/reproducer-react-native).
* Is tested against the [**latest stable**](https://github.com/facebook/react-native/releases/) of React Native.
Due to the extreme number of bugs we receive, we will be looking **ONLY** into issues with a reproducer, and on [supported versions](https://github.com/reactwg/react-native-releases#which-versions-are-currently-supported) of React Native.
- type:textarea
id:description
attributes:
label:Description
description:|
Please provide a clear and concise description of what the bug or issue is. Include screenshots if needed.
Please make sure you check the New Architecture documentation first, as your issue might
already be answered there - https://reactnative.dev/docs/next/new-architecture-intro
description:A clear and concise description of what the bug is.
validations:
required:true
- type:textarea
id:reproduction
attributes:
label:Steps to reproduce
description:The list of steps that reproduce the issue.
placeholder:|
1. Install the application with `yarn android`
2. Click on the button on the Home
3. Notice the crash
validations:
required:true
- type:input
id:version
attributes:
label:React Native Version
description:What is the latest version of react-native that this issue reproduces on? Please test against the latest stable version, and list only the highest version you tested. Bug reports against older versionsare more likely to stall.
placeholder:ex. 0.71.0
description:The version of react-native that this issue reproduces on. Bear in mind that only issues on [supported versions](https://github.com/reactwg/react-native-releases#which-versions-are-currently-supported) will be looked into.
placeholder:"0.73.0"
validations:
required:true
- type:dropdown
id:platforms
attributes:
label:Affected Platforms
description:Please select which platform you're developing to, and which OS you're using for building.
multiple:true
options:
- Runtime - Android
- Runtime - iOS
- Runtime - Web
- Runtime - Desktop
- Build - MacOS
- Build - Windows
- Build - Linux
- Other (please specify)
validations:
required:true
- type:dropdown
id:areas
attributes:
label:Areas
description:Which areas of the New Architecture are affected by this bug report?
multiple:true
options:
- Fabric - The New Renderer
- TurboModule - The New Native Module System
- JSI - Javascript Interface
- Bridgeless - The New Initialization Flow
- Codegen
- Other (please specify)
validations:
required:true
- type:textarea
@@ -31,23 +83,53 @@ body:
attributes:
label:Output of `npx react-native info`
description:Run `npx react-native info` in your terminal, copy and paste the results here.
placeholder:|
Paste the output of `npx react-native info` here. The output looks like:
...
System:
OS: macOS 14.1.1
CPU: (10) arm64 Apple M1 Max
Memory: 417.81 MB / 64.00 GB
Shell:
version: "5.9"
path: /bin/zsh
Binaries:
Node: ...
version: 18.14.0
...
render:text
validations:
required:true
- type:textarea
id:reproduction
id:stacktrace
attributes:
label:Steps to reproduce
description:Provide a detailed list of steps that reproduce the issue.
label:Stacktrace or Logs
description:Please provide a stacktrace or a log of your crash or failure
render:text
placeholder:|
Paste your stacktraces and logs here. They might look like:
at com.facebook.soloader.SoLoader.g(Unknown Source:341)
at com.facebook.soloader.SoLoader.t(Unknown Source:124)
at com.facebook.soloader.SoLoader.s(Unknown Source:2)
at com.facebook.soloader.SoLoader.q(Unknown Source:42)
at com.facebook.soloader.SoLoader.p(Unknown Source:1)
...
validations:
required:true
- type:input
id:reproducer
attributes:
label:Reproducer
description:A link to a Expo Snack or a public repository that reproduces this bug, using [this template](https://github.com/react-native-community/reproducer-react-native). Reproducers are **mandatory**.
Please use this form to file an issue if you have upgraded or are upgrading to [latest stable release](https://github.com/facebook/react-native/releases/latest) and have experienced a regression (something that used to work in previous version).
- type:input
id:new-version
attributes:
label:New Version
description:This is the version you are attempting to upgrade to.
placeholder:ex. 0.66.1
validations:
required:true
- type:input
id:old-version
attributes:
label:Old Version
description:This is the version you were on where the behavior was working.
placeholder:ex. 0.65.1
validations:
required:true
- type:input
id:target
attributes:
label:Build Target(s)
description:What target(s) are encountering this issue?
placeholder:iOS simulator in release flavor
validations:
required:true
- type:textarea
id:react-native-info
attributes:
label:Output of `react-native info`
description:Run `react-native info` in your terminal, copy and paste the results here.
validations:
required:true
- type:textarea
id:reproduction
attributes:
label:Issue and Reproduction Steps
description:Please describe the issue and list out commands run to reproduce.
description:Which JavaScript engine to use. Must be one of "Hermes", "JSC".
default:Hermes
use-frameworks:
description:The dependency building and linking strategy to use. Must be one of "StaticLibraries", "DynamicFrameworks"
default:StaticLibraries
architecture:
description:The React Native architecture to Test. RNTester has always Fabric enabled, but we want to run integration test with the old arch setup. Must be one of "OldArch" or "NewArch"
default:OldArch
ruby-version:
description:The version of ruby that must be used
default:2.6.10
flavor:
description:The flavor of the build. Must be one of "Debug", "Release".
body: `This pull request was successfully merged by ${authorName} in **${sha}**\n\n<sup>[When will my fix make it into a release?](https://github.com/reactwg/react-native-releases/blob/main/docs/faq.md#when-will-my-fix-make-it-into-a-release) | [How to file a pick request?](https://github.com/reactwg/react-native-releases/blob/main/docs/faq.md#how-to-open-a-pick-request)</sup>`
});
// If the PR has already been processed (labeled as Merged), skip it
body: `This pull request was successfully merged by ${authorName} in **${sha}**.\n\n<sup>[When will my fix make it into a release?](https://github.com/facebook/react-native/wiki/Release-FAQ#when-will-my-fix-make-it-into-a-release) | [Upcoming Releases](https://github.com/reactwg/react-native-releases/discussions/categories/releases)</sup>`
stale-issue-message:'This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.'
stale-pr-message:'This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.'
stale-issue-message:'This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.'
stale-pr-message:'This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.'
stale-issue-message:"This issue is waiting for author's feedback since 24 days. Please provide the requested feedback or this will be closed in 7 days."
stale-issue-message:"This issue is waiting for author's feedback since 24 days. Please provide the requested feedback or this will be closed in 7 days."
- name:Build the Helloworld application for ${{ matrix.flavor }} with Architecture set to ${{ matrix.architecture }}, and using the ${{ matrix.jsengine }} JS engine.
shell:bash
run:|
cd packages/helloworld/android
args=()
if [[ ${{ matrix.architecture }} == "OldArch" ]]; then
needs:[prepare_hermes_workspace, build_hermes_macos]# prepare_hermes_workspace must be there because we need its reference to retrieve a couple of outputs
needs:[prepare_hermes_workspace, build_hermes_macos]# prepare_hermes_workspace must be there because we need its reference to retrieve a couple of outputs
@@ -67,7 +67,7 @@ React Native is developed and supported by many companies and individual core co
## 📋 Requirements
React Native apps may target iOS 13.4 and Android 5.0 (API 21) or newer. You may use Windows, macOS, or Linux as your development operating system, though building and running iOS apps is limited to macOS. Tools like [Expo](https://expo.dev) can be used to work around this.
React Native apps may target iOS 13.4 and Android 6.0 (API 23) or newer. You may use Windows, macOS, or Linux as your development operating system, though building and running iOS apps is limited to macOS. Tools like [Expo](https://expo.dev) can be used to work around this.
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.