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:
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
Oskar Kwaśniewski
Pieter De Baets
Ruslan Shestopalyuk
Phillip Pan
Rick
David Vacca
George Zahariev
Sunbreak
Saúl Ibarra Corretgé
zhongwuzw
Gabriel Donadel
Arushi Kesarwani
Intl Scheduler
TatianaKapos
Gijs Weterings
Fabrizio Cucci
Nick Gerleman
Cody Bennett
Nikita Lutsenko
Samuel Susla
Riccardo Cipolleschi
Ruslan Lesiutin
Peter Abbondanzo
dan
Shivam Shashank
tarunrajput
Lulu Wu