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:
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:
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:
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:
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
