Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43581
Changelog: [internal]
This implements a mechanism to ensure that JavaScript tasks have a consistent view of the state of the UI during their execution.
## Context
Fabric allows committing new revisions of the ShadowTree from any thread, but we don't make use of this capability and instead always commit them from the JS thread (e.g.: when we schedule Fabric state updates to update the offset of a list on scroll). This was done to make sure that JS work didn't see changes in the state of the tree at random points during its execution. E.g.:
```
useEffect(() => {
const rect = ref.current.getBoundingClientRect();
// do something
const newRect = ref.current.getBoundingClientRect();
// `rect` and `newRect` should always be the same
}, []);
```
This isn't used by Reanimated at the moment, which means JS can inadvertently see the result of animations in non-specific times during execution.
You can find additional context about this in the [RFC for DOM Traversal & Layout APIs in RN](https://github.com/react-native-community/discussions-and-proposals/blob/main/proposals/0607-dom-traversal-and-layout-apis.md#consistency-and-updates).
This works correctly at the moment, but we introduce a limitation in the execution model to prevent updating the tree synchronously from the main thread. One of the main problems this introduces is that computing intersections (for `IntersectionObserver`) relies on the information in the shadow tree, but this is updated asynchronously on scroll.
There are 2 potential solutions for that problem:
1) Send the timestamp of the scroll even with the state update to backdate the timestamps of the intersections. This could work but introduces more complexity and possibly accuracy problems due to batching those state updates with other changes (e.g.: what happens if we update the state and commit another tree in the same task? should we use the backdated timestamp or wait for mount?).
2) (**Preferred**/ this diff) Allow committing new revisions from any thread, but lock the JS thread into seeing a specific revision, which would only update/progress in specific moments when it's safe. Some of those moments would be:
1) When we start a new JS task.
2) When we commit a new tree from React (JS).
## Changes
This implements the solution outlined in 2), creating a few abstractions to handle what's the current tree that should be visible to JS and to lock/unlock it in specific moments.
More specifically:
* Creates `ShadowTreeRevisionProvider` as an abstract class for APIs consuming the visible revision of the ShadowTree (mainly DOM APIs and layout methods like `measure`, etc.).
* Creates `ShadowTreeRevisionConsistencyManager` as an abstract class to handle what trees are visible (with a `lockRevision` and `unlockRevision` to be called from `RuntimeScheduler` at the beginning and end of each JS task).
* Creates 2 different implementations of these abstractions:
* One that preserves the current behavior (`LatestShadowTreeRevisionProvider`, which just returns the last committed revision at the time of the call).
* One that locks revisions lazily (the first time they're accessed) (`LazyShadowTreeRevisionConsistencyManager`).
Reviewed By: sammy-SC
Differential Revision: D55024832
fbshipit-source-id: b59985bc83714ae7ec915baba72bf92b3d6fa140
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43504
Changelog: [internal]
We identified the issue in the experiments already, so we can remove this flag.
Reviewed By: sammy-SC
Differential Revision: D54945099
fbshipit-source-id: 4d547569eb3bbfd011f5d6894d87bfa542cac07b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43482
## Context
We are migrating to the new Hermes `CDPAgent` and `CDPDebugAPI` APIs in the modern CDP server (previously `HermesCDPHandler`).
## This diff
Now that we are confident that `CDPAgent` is stable, switch to it by default and remove the previous integration.
- Drop `inspectorEnableHermesCDPAgent` feature flag.
- Rename and replace `HermesRuntimeAgentDelegateNew` as `HermesRuntimeAgentDelegate`.
- Drop "Hermes integration: CDPAgent" log message.
- Update tests.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D54897841
fbshipit-source-id: 8a5212d27f21c54112c0820a2a3611e05d606880
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43353
## Context
We are migrating to the new Hermes `CDPAgent` and `CDPDebugAPI` APIs in the modern CDP server (previously `HermesCDPHandler`).
## This diff
Integrates `HermesRuntimeAgentDelegateNew` (using the new Hermes `CDPAgent` setup) into `HermesRuntimeTargetDelegate` behind a new feature flag, `inspectorEnableHermesCDPAgent`. This completes the initial integration for all platforms.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D54586162
fbshipit-source-id: 5f26c28af4414d961b1c8c9cb4cd7135bd00b410
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43349
Changelog: [internal]
We still haven't found the root cause of some of the crashes we're seeing in the experiments to enable mount hooks on Android.
This adds a new feature flag to skip part of the mount hooks pipeline to see if we can scope the investigation to that specific part (where we query the root tree in the base revision from the mounting coordinator).
Reviewed By: sammy-SC
Differential Revision: D54587739
fbshipit-source-id: 792aa8b06808e96638d1bba072bf4060ec492bd2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43350
Changelog: [internal]
Mount hooks have been shipped on iOS, so this removes the flag for them.
On Android, we're still testing them so it's worth moving them to the new system and scoping them to that platform.
Reviewed By: sammy-SC
Differential Revision: D54587740
fbshipit-source-id: d074927fee1a967bd3928970c31975d07cd393bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43329
Improve maintainability of this file, in particular reducing the probability of a merge conflict for new entries.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D54539469
fbshipit-source-id: dc2fca42b4490d87c532b21043b0855d8d1a894d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42432
Changelog: [internal]
This feature flag is accessed through `CoreFeatures` but it's initialized a few different ways:
* Android: assigned via `ReactFeatureFlags`, which is overridden by apps.
* iOS: `ReactNativeConfig` that's mapped to a dynamic configuration.
This migrates the flag to the new feature flag system.
Reviewed By: mdvacca, RSNara
Differential Revision: D52810065
fbshipit-source-id: d6fd1e819abbc4c3dee9e6221d8f99384f5197f5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42665
- Replace the internals of `InspectorFlags` to use the new `ReactNativeFeatureFlags` setup.
- Remove call sites to `InspectorFlags::initFromConfig`.
After this diff, all `InspectorFlags` are configured from `ReactNativeFeatureFlags.json`.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D53049790
fbshipit-source-id: 90c2b128a9c316546c3f8f8f88e2c08a9f55ae72
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42815
Feature flags were originally defined in a JSON file for easier interoperability but we're only using the definitions in JS anyway, so having the definitions in a JS file is more flexible (e.g.: adding comments).
Changelog: [internal]
Reviewed By: huntie
Differential Revision: D53351483
fbshipit-source-id: 23fe0a3898b4facf2f2cf9645f78c45d78937f31
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42811
changelog: [internal]
Attempt to fixing a crash in ReactViewGroup when removeClippedSubviews is enabled.
The implementation of removeClippedSubviews in ReactViewGroup is stateful and must be in sync between children of view and [member variables in ReactViewGroup](https://fburl.com/code/l22wewzc) that keep reference to all children. When it gets out of sync, it manifests itself as `java.lang.IndexOutOfBoundsException` crash.
The mounting layer counts on the fact that view hierarchy will never be directly mutated and all mutations will go through [ReactClippingViewManager](https://fburl.com/code/esl3vqhh). ReactClippingViewManager, if clipping is enabled, calls appropriate methods on ReactViewGroup to make sure member variables to manage clipping are in sync with view hierarchy.
This is true, except for a retry mechanism in SurfaceMountingManager. The retry mechanism tries to manually reconciliation the state with android view hierarchy. It bypasses ReactClippingViewManager in the process.
Reviewed By: javache, mdvacca
Differential Revision: D53348831
fbshipit-source-id: b6b190781a7c85ee4dfd7cb9bc74fd3a55466e45
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42719
The task T175989432 started firing on October 30 2020, which correspond to the landing of D24512203. I believe disabling CustomDrawOrder could be a potential cause of T175989432, that's why in this diff I'm creating an experiment to understand what is the impact (negative or positive) of re-enabling CustomDrawOrder in RN Android
Original diff: D24512203
Changelog: [Internal] internal
Reviewed By: javache
Differential Revision: D53150292
fbshipit-source-id: f0abbc7d175c2cd717ce87bbe69aeaf3db0b0e5c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42716
Migrates this to the new flag system just added.
Made a quick change to the Android template, to mark Kotlin accessors as `JvmStatic` to make calling from Java more idiomatic.
Next diff will wire to MC.
Changelog: [Internal]
Reviewed By: rubennorte, mdvacca
Differential Revision: D53198874
fbshipit-source-id: 6ab5b279d9ac59733c6e820c25be72383ce0e54a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42678
Changelog: [internal]
This is a re-application of https://github.com/facebook/react-native/pull/42430, which had to be reverted because of crashes in optimized builds on Android:
```
Abort Reason: terminating due to uncaught exception of type facebook::jni::JniException: java.lang.ClassNotFoundException: com.facebook.react.internal.featureflags.ReactNativeFeatureFlagsProvider
```
The root cause of that was that that class was removed because it wasn't statically referenced from Kotlin/Java, but it was dynamically referenced from C++ (in `ReactNativeFeatureFlagsProviderHolder.cpp`).
This applies the same changes + adds `DoNotStrip` annotations for the affected class and all its methods.
Reviewed By: huntie
Differential Revision: D53122992
fbshipit-source-id: efc4d5636a3f2d39b86e9c098bff408b6688b80b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42434
Changelog: [internal]
The flags for the event loop were set up using different mechanisms due to the limitations of the previous feature flags systems. Now we can centralize on the new system and use them consistently on Android and iOS.
Reviewed By: RSNara
Differential Revision: D52819137
fbshipit-source-id: e30a6f2e12b4a027a906502b80a70dd48bb657b6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42430
This PR creates a new internal feature flags system for React Native. This is only meant to be used internally within the framework, but we might expose it externally in some form in the future to allow customizing specific feature flags in frameworks and applications.
Features:
* 2 types of flags:
* Common: can be overridden from native and are accessible from all layers of the stack (Objective-C/Swift, Java/Kotlin, C++ and JavaScript).
* JS-only: flags that can only be defined and accessed from JS (to allow things like hot reloading without a native build).
* 1 source of truth for each flag.
* Feature flags are application/process scoped (using C++ singletons).
See the `README.md` file in this PR for additional information.
This also adds modifies `run-ci-javascript-tests` to run a new check to make sure that the generate files are in sync with the JSON file that contains the definitions.
Changelog: [internal]
Reviewed By: huntie
Differential Revision: D52806730
fbshipit-source-id: 0ba95803f61ec2f05266ee535921321bf6d3dc6a
Rubén Norte
Alex Hunt
Nick Gerleman
Samuel Susla
David Vacca