Summary:
This feature flag (enableStopSurfaceOnRootViewUnmount) was used to gate usage of the "stopSurface" API, which is now fully supported, and has been used
in the FB app for several months. This is safe to ship in code.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25275192
fbshipit-source-id: fa22bfd00aa023297bc19c83c138f133e9ff1645
Summary:
This was added to prevent mutating the UI during draw or measure, and appears to have been effective. Keep the comments, ship the feature, remove flags.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25258409
fbshipit-source-id: 36ad8a03d1eb82bc9dcd769372c03f1ebe8b8da8
Summary:
Currently, queuing any sort of MountItem or getting the list of MountItems requires synchronization. Since these can be queued up at any point from the JS thread, there will, in theory, be constant contention between JS and UI thread.
To see if this is true, I'm creating an experiment instead of just switching over to concurrent structures. After seeing results, we can hopefully make a decision and delete the non-concurrent stuff or improve on it somehow.
The original was unlanded in D24973616 (https://github.com/facebook/react-native/commit/26787e2260412d9d2fe831e68a8616505d3cab36) due to a typo, which has been fixed now. The typo was that in Blocking Mode, we queued up all PreMountItems to the concurrent PreMountItems queue.
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D24974851
fbshipit-source-id: d081c081bbd0de445bb92408f0ec822056b905a5
Summary:
Currently, queuing any sort of MountItem or getting the list of MountItems requires synchronization. Since these can be queued up at any point from the JS thread, there will, in theory, be constant contention between JS and UI thread.
To see if this is true, I'm creating an experiment instead of just switching over to concurrent structures. After seeing results, we can hopefully make a decision and delete the non-concurrent stuff or improve on it somehow.
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D24942110
fbshipit-source-id: fcbdeda51f91f4bd430a20d7484854fb1e94a832
Summary:
There is a flow where TM registry is creating a module instance (as registered in the TurboReactPackage), only to discard it if it's not a TM enabled module. This may be fine for many modules, but for module like `UIManagerModule`, this may cause a race condition or other issues, including potential perf regression when accessing UIManager from JS (e.g. for getting native viewConfigs).
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24811838
fbshipit-source-id: 6e1cce6993a6e5c9763773f175083bf52925c910
Summary:
## Android API
```
// Before we initialize TurboModuleManager
ReactFeatureFlags.useTurboModuleJSCodegen = true
```
## iOS API
```
// Before we initialize RCTBridge
RCTEnableTurboModuleJSCodegen(true);
```
## How is the JS Codegen actually enabled?
The above native flags are translated to the following global variable in JavaScript:
```
global.RN$JSTurboModuleCodegenEnabled = true;
```
Then, all our NativeModule specs are transpiled to contain this logic:
```
interface Foo extends TurboModule {
// ...
}
function __getModuleSchema() {
if (!global.RN$JSTurboModuleCodegenEnabled) {
return undefined;
}
// Return the schema of this spec.
return {...};
}
export default TurboModuleRegistry.get<Foo>('foo', __getModuleSchema());
```
Then, in our C++ JavaTurboModule, and ObjCTurboModule classes, we use the TurboModule JS codegen when the jsi::Object schema is provided from JavaScript in the TurboModuleRegistry.get call.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D24636307
fbshipit-source-id: 80dcd604cc1121b8a69df875bbfc87e9bb8e4814
Summary:
TurboModule methods that return promises are synchronously run on the JavaScript thread. Back in D22489338 (https://github.com/facebook/react-native/commit/9c35b5b8c4710dfe6a4b689a5565aa78ae5b37d3), we wrote code to make them dispatch on the NativeModules thread. That code, however, was just left disabled. In this diff, I wire up the TurboModules infra to a MobileConfig, which should allow us to assess the performance impact of async dispatch of promise methods to the NativeModules thread in production, before we roll it out more widely.
Changelog: [Internal]
NOTE: This diff was reverted, beacuse we landed it it without D24685387.
Reviewed By: ejanzer
Differential Revision: D24787573
fbshipit-source-id: 324bd22ce79c2c16c7f7b6996496d255a2c6256e
Summary:
TurboModule methods that return promises are synchronously run on the JavaScript thread. Back in D22489338 (https://github.com/facebook/react-native/commit/9c35b5b8c4710dfe6a4b689a5565aa78ae5b37d3), we wrote code to make them dispatch on the NativeModules thread. That code, however, was just left disabled. In this diff, I wire up the TurboModules infra to a MobileConfig, which should allow us to assess the performance impact of async dispatch of promise methods to the NativeModules thread in production, before we roll it out more widely.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24685389
fbshipit-source-id: 8ceb2e6effc125abecfa76e5e90bd310676aefc9
Summary:
For over a month I've been searching for a crash that occurs during Android's native `dispatchDraw` method on View. The stack traces didn't show anything useful - everything in the stack trace was native Android code,
not React Native code.
This also seems to only repro on certain vendors, and only on a very few React Native screens - I'm still not sure why either of those are the case, but from my repro, a *very* specific set of interactions needs to happen
to trigger this crash. See comments inline and an example stack trace.
Luckily, the fix is trivial. Since this code is used for animations, accessibility, and a number of other important interactions, I'm gating this change for now.
In general we must be careful to only mutate the View hierarchy only when we /know/ for certain it is safe to do so. Indirectly mutating the View hierarchy during measure, onMeasure, layout, dispatchDraw, etc, can all be
very dangerous. This is one of the last "escape hatches" that can cause view hierarchy modifications unexpectedly, so I think it's a very good idea to "secure" this further, and only update props synchronously here - and
ensure that other MountItems like `Delete` are definitely /not/ executed here.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D24639793
fbshipit-source-id: b6219ce882e8d2204b4d10bf99f6a1120a33cb5a
Summary:
Fabric should be inserting Views into the hierarchy in the correct order based on z-index already, so there should be no reason to enable this mechanism.
At best it's a perf pessimisation and at worst it could be causing consistency issues or crashing (TBD). Most likely this is a noop.
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D24512203
fbshipit-source-id: b9336240ef8506742bcbd8d08fc8b830f82cdfe2
Summary:
Remove `enableFabricStartSurfaceWithLayoutMetrics` and treat as `true` always from now on.
Changelog: [Internal]
Differential Revision: D23633198
fbshipit-source-id: 5b7455b87e578ffa97d80746fa901cd2b50d3ea9
Summary:
This diff optimizes the caching of Spannable objects managed by the TextLayoutManager class.
Previously, these objects were cached using unsing a String representation of the RedableMap (creating this string adds a non trivial cost), this diff improves the caching performance relying on the equals / hashcode methods of the ReadableNativeMap class
I created a MC just to have a killswitch
Motivation: I was analysing another bug and I found this non performant code
changelog: [internal] internal
Reviewed By: shergin
Differential Revision: D23429365
fbshipit-source-id: 59e5ad0b1b95da992ac393aecfe029da68a8df97
Summary:
With BackgroundExecutor+State Reconciliation, it is pretty common to have races where View layer UpdateState calls are thrown away.
Theoretically this is /always/ possible since C++ doesn't retry failed UpdateStates, we just try once and then bail. This is part 1 of improving our mechanisms for ensuring that State stays up-to-date from the View layer.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22933927
fbshipit-source-id: 77b3b87402f772e3f149be0f9200e673bbed7b57
Summary:
These flags haven't been used in months. They were useful to uncover some race conditions, but will not be iterated further. The Venice project will obviate the concerns that sparked these experiments in the first place.
These flags have been hardcoded to false for a while.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22319204
fbshipit-source-id: 09415f3bb1ca56e15f357210e966d0483ff384f2
Summary:
According to our experiments it's not better than "stop surface on unmount" in any way, and might regress some metrics. Unclear why, but if it's not necessary and doesn't seem to help, it doesn't make sense to continue this experiment.
We still have a mechanism on the C++ side to stop outstanding surfaces on teardown that does the same thing.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22318864
fbshipit-source-id: 7e678c63e4884382e57d996a7f4c4b7b24c8193a
Summary:
Early ViewCommand dispatch: ship the experiment everywhere on Android.
Since ViewCommands are totally divorced from the commit cycle currently, and since they are inherently unsafe, we can create a separate queue for them
and retry them if they fail with a specific category of exceptions.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22173050
fbshipit-source-id: 494b7c6b5dfd2aec8ba77ae35d0d58d4d727b9b4
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:
EZ diff to expose a new ReactFlag that will be used to configure the initialization of Fabric
changelog: [Internal] Internal change in fabric
Reviewed By: JoshuaGross
Differential Revision: D21606972
fbshipit-source-id: 53d6bac673b95f0fae93262ff52b815d76bb59ab
Summary:
This diff exposes a new react feature flag to eager initialize fabric
changelog: [Internal] Internal change in Fabric
Reviewed By: JoshuaGross
Differential Revision: D21574814
fbshipit-source-id: c74fb316963fe92e43ce0ca6262cb73a6a4acb7f
Summary:
This diff adds a temporary Feature Flag to control a fix in TextInlineView (see previous diffs of the stack)
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20812920
fbshipit-source-id: 90fece9b29ba173546d96e4d9baf1ccabb3031b2
Summary:
Hard-coded to false everywhere, and write-only. We never read from this.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D20788252
fbshipit-source-id: ae117ebc51db7045947b9713602527ff4220833e
Summary:
Remove unused feature flag. This is not used within Facebook and I'm not aware of usage outside of FB.
Changelog: [Removed] Removing Android feature flag: lazilyLoadViewManagers
Reviewed By: mdvacca
Differential Revision: D20788210
fbshipit-source-id: 435316e3de7830d7cb7f14537351883e4fc6eeaa
Summary:
ViewCommands are sort of like setNativeProps updates, in that they're direct manipulations of Views on-screen that don't go through the normal
commit/diff process that other UI updates do. This is an MVP that shows how we can do this in non-Fabric RN.
Changelog: [Internal] experiment, allow ViewCommands to be executed before other types of UIOperations
Reviewed By: axe-fb, mdvacca
Differential Revision: D20378633
fbshipit-source-id: 5f3c54d3c84b4e4f7cb060a9505b20b0e5b7afed
Summary:
This diff cleans up mobile config and ReactFeatureFlags that are not used anymore
changeLog: [internal]
Reviewed By: JoshuaGross, makovkastar
Differential Revision: D20026794
fbshipit-source-id: 3d941db195075a9cf49b7ecc0bf1ee839fcca189
Summary:
This diff fixes the redbox error: Views nested within a <Text> must have a width and height
This error is reproducible when rendering a View with no fixed size, inside a <Text>. e.g.
```
function PlaygroundContent(props: {}) {
return (
<View style={styles.container}>
<Text>
<View>
<Image source={fbicon.filled('chevron-down', 10)} />
</View>
</Text>
</View>
);
}
```
changelog: Add support to render <View> with no fixed size nested within a <Text>
Reviewed By: shergin
Differential Revision: D19387760
fbshipit-source-id: a9cee8410e56a2d362d6b8f993e602719c416925
Summary:
This diff introduces a new ReactFeatureFlag that will be used to enable / disable a custom implementation of getChildVisibleRect in the classes ReactViewGroup, ReactHorizontalScrollView and ReactScrollView.
The new ReactFeatureFlag is disabled by default bevause of T57363204
This is disabling the code landed as part of D17782658 / https://github.com/facebook/react-native/pull/26334
Changelog: Introduce ReactFeatureFlag to disable custom implementation of getChildVisibleRect (disabled by default)
This will disable the custom algorithm created on https://github.com/facebook/react-native/pull/26334
Reviewed By: yungsters
Differential Revision: D18621042
fbshipit-source-id: 35ca3417b596117b47edab29515a824c1726c2ce
Summary:
`ReactFeatureFlags.useTurboModules` can be written to and read from any number of threads. We should use `volatile` to make sure that all threads read/write this data straight from/to memory.
Changelog:
[Android][Fixed] - Make ReactFeatureFlags.useTurboModules volatile
Reviewed By: fkgozali
Differential Revision: D18505673
fbshipit-source-id: 0b2527b8cb95c1e1aedc6b03b12a6b1e6a6cdaa4
Summary:
Mostly for easing open-source migration and not making a backwards-incompatible change (yet), we'll set this to false by default. Every app can opt-in to this if wanted but it's not necessary. This change is part of experiments surrounding more-aggressive teardown for Fabric and Bridgeless mode.
Changelog: [Internal] - This has the effect of (by default) disabling the previous diff which caused ReactContext teardown to always set mCatalystInstance to null. Now that is opt-in behavior and off by default, so it's not longer a breaking change.
Reviewed By: mdvacca
Differential Revision: D18207302
fbshipit-source-id: 7acfc894415e966f652c7049849eef79c440a135
Summary:
CatalystInstanceImpl.destroy does a bunch of stuff in each of the relevant threads (Native Module thread, JS thread, UI thread).
This change creates a V1 destroy method (unchanged) and a V2 destroy method. The goal is to resolve (and catch!) race conditions in native modules and JSI modules that could occur during teardown; and mitigate race conditions that occur in RN teardown, like deallocation of C++ objects (scheduler, JS VM, and UIManager for Fabric).
Changelog:
[Internal] Experiment to fix deallocation race conditions
Reviewed By: mdvacca
Differential Revision: D18001677
fbshipit-source-id: 5955da0a7b726491c7d749642475f0fba74cce5a
Summary: This diff adds a feature flag which must be enabled if view managers should be allowed to use a delegate for setting their properties.
Reviewed By: mdvacca
Differential Revision: D16762876
fbshipit-source-id: ae3466d7f02ed02f203dbb79f5e0843e6d9fdd45
Summary:
This diff formats the Java class files inside xplat/js/react-native-github. Since google-java-format was enabled in D16071401 we want to codemode the existing code so that users don't have to deal with formatter lint noise at diff-time.
```arc f --paths-cmd 'hg files -I "**/*.java"'```
drop-conflicts
Reviewed By: cpojer
Differential Revision: D16071725
fbshipit-source-id: fc6e3852e45742c109f0c5ac4065d64201c74204
Summary: Easy diff to create a ReactFeatureFlag to enabled logging in Fabric
Reviewed By: JoshuaGross
Differential Revision: D15803582
fbshipit-source-id: d735f24850bddf43c27b97d006100cbb8f0cc6e3
Summary: This diff creates a new react feature flag to enable extra logging on React Web Views
Reviewed By: RSNara
Differential Revision: D15729871
fbshipit-source-id: 931d4a1b022c6a405228bf896b50ecc7a44478d1
Summary:
We are getting errors where views are being dropped twice.
This is following from logic that viewManagers are only removed from `mTagsToViewManagers` from `dropView`.
This log will hopefully identify if we are getting improper operations because we shouldn't be re-using tags
Reviewed By: mdvacca
Differential Revision: D15152869
fbshipit-source-id: 914ee9c1772fa066adefde0753075ecba6377a0c
Summary:
Added a flag that checks if TurboModules are enabled, don't expose them to JS via the old module system.
All TurboModules needs to implement TurboModule interface.
Reviewed By: mdvacca
Differential Revision: D13648332
fbshipit-source-id: f22506fe029ac82d56075f5b6962ff2df2e7eaa4
Summary: Adds copyright headers to all files that are missing them.
Reviewed By: hramos
Differential Revision: D12837494
fbshipit-source-id: 6330a18919676dec9ff2c03b7c9329ed9127d930
Summary: ReadableNativeArray initializes the ReactBridge which loads a bunch of c++ classes. Let's avoid doing this on the UI thread.
Reviewed By: mdvacca
Differential Revision: D10108380
fbshipit-source-id: ab4520535288ce450a865952e996b716d571df7f
Joshua Gross
Andrei Shikov
Kevin Gozali
Ramanpreet Nara
Alessandro Sisto
David Vacca
generatedunixname89002005287564
Lulu Wu
Andres Suarez
Oleksandr Melnykov
Luna Wei
Ram N
Tim Yung
Andrew Chen (Eng)