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