Summary:
I was seeing a SoftException in our apps due to this method being called as part of ReactInstanceManager's init. It seems inconsistent that we would call this from a background thread when all other `onHost*` methods are marked as confined to the UI thread.
Changelog: [Internal]
Reviewed By: ryancat
Differential Revision: D34340210
fbshipit-source-id: 0104eda66b2ca6bb315e64e806e9a30409d0d45c
Summary:
This diff integrates DeviceConfig into ReactNativeConfig used by ReactNativePanelApps. The goal is to be able to control Fabric MCs using GKs and QEs in RN VR apps
I did an audit of the MCs that were used by RNPanelApps:
```
"react_fabric:enabled_android_fabric_logs": -> will get data from GK (disabled by default)
"react_fabric:disable_virtual_node_preallocation": -> does not exist in code anymore
"react_fabric:enable_early_event_emitter_update": -> will get data from MC (disabled using static value)
"react_fabric:enable_background_executor_android": -> does not exist in code anymore
"react_fabric:enable_props_forwarding_android": -> does not exist in code anymore
"react_fabric:remove_outstanding_surfaces_on_destruction_android": -> will get data from MC static value (ENABLED using static value)
"react_fabric:enable_large_text_measure_cache_android": -> will get data from MC default value (ENABLED by default)
```
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D33898210
fbshipit-source-id: 0ea1e0e2fc15929bec328f7dcc9410efa9925b34
Summary:
We put the `:interfaces` target on the dependencies list for `:devsupport` target in the [BUCK file](https://fburl.com/code/lrr1c0pn). In the following diffs I will need to put the interface [`/devsupport/RedBoxHandler`](https://fburl.com/code/v53euvps) on to [`/devsupport/interfaces/DevSupportManager`](https://fburl.com/code/k8gwxa0f). This violates the dependency rule.
Since `RedBoxHandler` is an interface, I moved it to the interfaces list in this diff to unblock.
Changelog:
[Android][Internal]
Reviewed By: yungsters
Differential Revision: D33987834
fbshipit-source-id: 77a1ee14bd10c6bbaac2ee465ae7050e99ed0399
Summary:
This diff deletes the ReactFeatureFlag enableFabricInLogBox, from now on Logbox will be rendered in Fabric when Fabric is enabled
changelog: [internal] internal
Reviewed By: genkikondo
Differential Revision: D33781626
fbshipit-source-id: 3187a22fec80125afd27860995637564640dab8d
Summary:
Enable eager intialization of FabricUIManager during intiialization of React Native.
This feature highly improved TTRC in Markeptlace Home
changelog: [internal] internal
Reviewed By: genkikondo
Differential Revision: D33585099
fbshipit-source-id: 0ffbc720bcb1edd1b04180189a52c82e9e2fa800
Summary:
This fixes https://github.com/facebook/react-native/issues/32898 by reseting ReactInstanceManager state when `createReactContext` throws. By resetting the state, we allow future attempts at creating the React context.
## Changelog
[Android] [Fixed] - Fixed empty screen after retrying a BundleDownloader failure in dev mode
Pull Request resolved: https://github.com/facebook/react-native/pull/32901
Test Plan: Go through the steps to reproduce listed in https://github.com/facebook/react-native/issues/32898 and see that the React Native application starts.
Reviewed By: cortinico
Differential Revision: D33634178
Pulled By: ShikaSD
fbshipit-source-id: e54d12d5f33c9c7c0ca213113871b88c2f1dc261
Summary:
This diff introduces a new interface named `SurfaceDelegate`. The interface abstracts the API for interacting with a surface, which is required for platforms other than mobile to implement how it wants to show and hide a surface. For existing Mobile use cases, the `LogBoxDialogSurfaceDelegate` is provided as a fallback solution so everything still works.
Changelog:
[Android][Added] - Add SurfaceDelegate abstraction to support interaction in multiple platforms and provide default implementation in LogBoxModule
Reviewed By: mdvacca
Differential Revision: D31132285
fbshipit-source-id: 13315a8bc5b7bcaee9b5e53ef5c6f6cc8cb01f31
Summary:
to open possibilities for some DX enhancement, the pr introduces `DevSupportManagerFactory` customization. applications could implement a different DevSupportManager in ReactNativeHost.
## Changelog
[Internal] [Added] - Support custom DevSupportManager
Pull Request resolved: https://github.com/facebook/react-native/pull/31841
Test Plan: this pr just introduces some new interfaces and should not break existing functionalities.
Reviewed By: RSNara
Differential Revision: D30878134
Pulled By: yungsters
fbshipit-source-id: ccdf798caa322b07a876da8312b97002da057388
Summary:
Changelog: [internal]
Remove RuntimeSchedulerManager on Android in favor of different way to initialise RuntimeScheduler.
Reviewed By: ShikaSD
Differential Revision: D30486975
fbshipit-source-id: 9fe38de12be452bd9d2c92bb54cf5933ce7555b5
Summary:
This diff is hooking up cxx error with redbox. Before this diff, cxx errors were only shown in log and there was no visible user feedback.
Changelog:
[Android] [Added] - Show Redbox for C++ errors.
Reviewed By: JoshuaGross
Differential Revision: D30421355
fbshipit-source-id: ad473337ba301feb08ba31ee8d82ebaa771ecaeb
Summary:
I'm not sure if we'll ever need to do more than this (probably!) but I want to have a specific option for Activity-less usage, so
that our logic in ReactInstanceManager and elsewhere is more clear. I want to be able to confidently assert that the Activity is present
and correct, or never present, depending on if this `requireActivity` flag is set; instead of adding else statements that imply "well, the Activity should be here, hope everything is okay" which feels hacky.
Doesn't change much for now, but it's an additional constraint in the RN Android codebase that we need to explicitly embed in code so that
we can point to it, and so that the logic is more clear.
Changelog: [Internal]
Reviewed By: javache, motiz88
Differential Revision: D30504616
fbshipit-source-id: d2abdb7c4765a16113c9517406cdbb8cf42822ff
Summary:
It is assumed that there will always be an activity associated on enabling the dev support which is not the case. Hence adding that null check.
Changelog:
[Android][Fixed] - Added null check for activity in onHostResume()
Reviewed By: javache
Differential Revision: D30411311
fbshipit-source-id: 8936be2df7f16c355693163347d5e1d94c5ce2e1
Summary:
ReactSoftException makes it seem like the class is an Exception, when it's actually a logger. This rename I think is more appropriate.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D30251735
fbshipit-source-id: 550bd543388e698774ec31753200bd3f722d8c17
Summary:
This diff fixes a NullPointerException that is caused when the method ReactInstanceManager.getViewManagerNames is called at the same time ReactInstanceManager is being destroyed.
Following the stacktrace I noticed that this crash can only happen when RN was destroyed by another thread while this method was being executed
This diff fixes the NullPointerException, but it doesn't fix the root cause race condition that cuases this bug
changelog: [Android][Fixed] Fix NullPointerException caused by race condition in ReactInstanceManager.getViewManagerNames method
Reviewed By: JoshuaGross
Differential Revision: D29616401
fbshipit-source-id: 6ae8ecdd765d2fe3529fef3237f08b182d8ed243
Summary:
Changelog: [internal]
Reland of D29131766 (https://github.com/facebook/react-native/commit/18165367b0347fc46cd52a6ac00afcf62d05cb30) which had to reverted because it caused binary size regression in instagram.
Size check for `automation_instagram_stablesize_release` and `automation_igtv_release`
{F626711916}
Reviewed By: JoshuaGross
Differential Revision: D29263302
fbshipit-source-id: cc8f5609ebaed9ddf666f7c57cdbf3dbf77a8f78
Summary:
Changelog: [internal]
RuntimeScheduler needs to be created and registered in the runtime before any JS is allowed to run. This diff moves the registration right after the runtime is initialised.
This diff removes funnelling of Fabric events through RuntimeScheduler. This will be added in subsequent diff to keep the complexity low.
Reviewed By: JoshuaGross
Differential Revision: D29131766
fbshipit-source-id: cbc650f6fbce95e4b9c2c9695e8e0aba5beac635
Summary:
This diff prevents a NullPointerException caused by a race condition in the tear down of React Native.
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D29135942
fbshipit-source-id: 76d5a1f16c2ca63a146b56c761f5f9595dcfe2a5
Summary:
Sometimes ```hasActiveCatalystInstance()``` is used to check if it's safe to access the CatalystInstance, which will still crash in Venice.
Previously we mitigate this by changing ```reactContext.hasActiveCatalystInstance()``` to ```reactContext.hasActiveCatalystInstance() || reactContext.isBridgeless()```.
To solve this for all and good the plan is:
1, Rename ```hasActiveCatalystInstance()``` to ```hasActiveReactInstance()``` so it won't sounds like CatalystInstance-only.
2, Implement hasActiveReactInstance() for Venice. D27343867
3, Remove previous mitigation. D27343952
This diff is the first step, by xbgs there are **58** non-generated callsites of ```hasActiveCatalystInstance()``` in code base which are all renamed in this diff.
Changelog:
[Android][Changed] - Rename "hasActiveCatalystInstance" to "hasActiveReactInstance"
Reviewed By: mdvacca
Differential Revision: D27335055
fbshipit-source-id: 5b8ff5e09b79a492e910bb8f197e70fa1360bcef
Summary:
This diff extracts ComponentNameRegistry out of Fabric modules
This is necessary to avoid depending on Fabric and regressing APK size for other RN apps (e.g. IG)
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D26765328
fbshipit-source-id: 0a22c4279146f5243473c74a84e78fad7f08f956
Summary:
This diff integrates the ComponentNameResolver class into ReactInstanceManager
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D26716900
fbshipit-source-id: e3a5f44485f659a32bf6094eee7985daf634f50f
Summary:
The purpose of this change is to make TTRC markers work similarly for bridge loading and bridgeless loading so we could compare performance between them.
There are mainly four cases involved:
```REACT_BRIDGE_LOADING_START,
REACT_BRIDGE_LOADING_END,
REACT_BRIDGELESS_LOADING_START,
REACT_BRIDGELESS_LOADING_END
```
First 2 are for beginning/ending of bridge loading which includes creating fragment, loading JS bundle, running JS bundle and creating react instance. Last 2 are for similar purpose with bridgeless.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D26514499
fbshipit-source-id: 65d6f3cc7de9e07a7a3a802dd77138e74c23aa5b
Summary:
This bug doesn't reproduce anymore in v301+. MC has been enabled since december
https://www.internalfb.com/intern/logview/details/facebook_android_javascripterrors/419f8892e7b1a02f205810219ddfc299/trends?selected-logview-tab=All%20Traces&drillstate={%22start%22:%22Thu,%2028%20Jan%202021%2000:59:54%20-0800%22,%22end%22:%22Thu,%2011%20Feb%202021%2000:59:54%20-0800%22,%22constraints%22:[{%22col%22:%22mid%22,%22op%22:%22==%22,%22vals%22:[%22419f8892e7b1a02f205810219ddfc299%22]}],%22context%22:%22facebook_android_javascripterrors%22,%22metric%22:%22count%22}
changelog: [internal] internal
Reviewed By: ShikaSD
Differential Revision: D26398484
fbshipit-source-id: ca85ca211f1a38aa2691f150956a27c878d243bc
Summary:
TurboModuleManager used to be provided by a JSIModules package. In D26193053 (https://github.com/facebook/react-native/commit/13f100f788063be2a30109c3f7fee386cb766ec4), we moved TurboModuleManager creation off JSIModules. However, we didn't move the creation outside the JSIModules guard. So, when there were no JSIModules registered, we simply wouldn't create the TurboModuleManager. This diff fixes that mistake.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26380674
fbshipit-source-id: 66939d11205b1d2eccd8c3b59ca4782e90645cd9
Summary:
This diff setup a global variable to control the staticViewConfig experiment before the bundle is loaded.
This global variable only has a meaning when RN uses a Bridge
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D26237670
fbshipit-source-id: 25ae63f36fba9c1e640ab2e70de88b71452ad8e6
Summary:
How does an application register a TurboModuleManagerDelegate with ReactInstanceManager?
1. Call ReactInstanceManagerBuilder.setReactPackageTurboModuleManagerDelegateBuilder(ReactPackageTurboModuleManagerDelegate.Builder)
2. Override ReactNativeHost.getReactPackageTurboModuleManagerDelegateBuilder()
Changelog: [Android][Added] - Introduce API to allow applications to register TurboModuleManagerDelegates with ReactInstanceManager
Reviewed By: mdvacca
Differential Revision: D26193055
fbshipit-source-id: bf82e63e6ab1c0c8f12bada92ac6852c992ec9cb
Summary:
The root cause of this bug is a race condition between the onMeasure method and setupReactContext.
ReactInstanceManager.attachRootView() method is responsible of the initialization of ReactRootViews and it is invoked by ReactRootView.onMeasure() method in the UIThread
Important initialization steps:
1. Clear the Id of the ReactRootView
2. Add the ReactRootView to the mAttachedReactRoots
3. Call StartSurface (if the bridge has been initialized)
Sometimes, when this method is invoked for the first time, the bridge is not initialized, in those cases we delay the start of the surface.
Once the bridge is initialized, StartSurface is called by the setupReactContext() running in the NativeModuleThread.
Since onMeasure can be called multiple times, it is possible that we call "StartSurface" twice for the same ReactRootView, causing the bug reported on T78832286.
This diff adds an extra check to prevent calling "StartSurface" twice. The fix is done using an AtomicInteger comparison and it is gated by the flag "enableStartSurfaceRaceConditionFix". Once we verify this works fine in production we will clean up the code, remove the flags and maybe revisit the API of ReactRoot.
changelog: [Android] Fix race-condition on the initialization of ReactRootViews
Reviewed By: JoshuaGross
Differential Revision: D25255877
fbshipit-source-id: ca8fb00f50e86891fb4c5a06240177cc1a0186d9
Summary:
Remove `enableFabricStartSurfaceWithLayoutMetrics` and treat as `true` always from now on.
Changelog: [Internal]
Differential Revision: D23633198
fbshipit-source-id: 5b7455b87e578ffa97d80746fa901cd2b50d3ea9
Summary:
This diff refactors the destruction of the ReactInstanceManager when the app is experiencing low memory.
As part of this refactor, I setup an experiment to understand at what level of memory pressure is convenient to destroy the RN bridge.
The experiment is divided in six levels described in the following table:
https://pxl.cl/1dzx8https://www.internalfb.com/intern/qe2/fb4a_react_native_memory/android_fb4a_instance_unload_pressure_v2/setup
changelog: [internal] Internal
Reviewed By: JoshuaGross
Differential Revision: D22577553
fbshipit-source-id: 37f8f561099a1ba6239795f5907090ced3b5dd18
Summary:
Pet Peeve: Metro is a brand name. You don't say "the Metro server" just like you don't say "the iPhone phone". This is a leftover from when it used to be called "the packager server".
Note: It makes sense to refer to "the Metro server" when talking about it in the context of Metro's features, like if you are discussing "Metro's bundling" and "Metro's server". However, when talking about the tool itself, just Metro is enough.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D22330966
fbshipit-source-id: 667618363c641884df543d88cac65d1e44956ad3
Summary:
These logs are no longer necessary, because data indicates that the TurboModule eager init crash was fixed.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D21852743
fbshipit-source-id: ddeefd6396283ee5e15980a33fb006cb83a81532
Summary:
Removing logs related to T62192299 that we don't need anymore.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21773629
fbshipit-source-id: d16c01f87be3ed7512fe90b6e261b4c7efbd3068
Summary:
I have a theory that T53114059 can be caused by (1) other crashes, and/or (2) reloads. Clear out the ID of a RootView when it is detached.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21732066
fbshipit-source-id: 5e607f34cf42ca26bdf199d5d3024fd49a60dc1e
Summary:
This diff uses a new MC to Start Fabric surfaces using layoutMetrics or not.
The motivation is to verify if the new initialization of fabric surfaces is regressing in production
changelog: [Internal] Internal change in fabric
Reviewed By: JoshuaGross
Differential Revision: D21606971
fbshipit-source-id: ed1f6937ffd0f1e6c54e3ebc34595d75b6c5f6e1
Summary:
This diff implements the eager initialization of fabric based on the param created in previous diffs
changelog: [Internal] Internal change in Fabric
Reviewed By: JoshuaGross
Differential Revision: D21574815
fbshipit-source-id: 1dfd2611ce8c8529ce5f6a7a8c48f8bee19be256
Summary:
This diff refactors the initial render of Fabric in order to set the layout metrics as we start the surface.
This prevents to create an additional fabric commit during initial render. Also this migth help fixing T63495589 (I wasn't able to repro T63495589 again when using this diff)
changelog: [Internal][Android] Internal change to reduce the amount of commits during initial render of Fabric
Reviewed By: JoshuaGross
Differential Revision: D21330072
fbshipit-source-id: 758c49b52ea4c12d5623b7c7d68c7318f4a6cd83
