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