Summary:
This diff creates the Android OSS build system for the module react/config
As part of this diff I also moved the module to react/config folder
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D22877264
fbshipit-source-id: 5b3c42580d2b1d73dc0abb48bcf4ff063b2f581f
Summary:
The implementation of RuntimeExecutor must execute all provided callbacks. However, the implementation of RCTRuntimeExecutorFromBridge cannot guarantee it because it relies on Bridge to make the call. In this diff, we wrap the callback into a callable that asserts if it's not being called before destruction.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D22810439
fbshipit-source-id: f11932019ab6ccbab7e65db5919e0c64dcaf37ed
Summary:
Hook up onSuccess and onFailure callbacks to LayoutAnimations.
Note that in non-Fabric RN, onSuccess is not known to work in Android. I could not find any uses of onFailure and it's not documented, so for now, it is only called if the setup of the animation fails.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D22889352
fbshipit-source-id: 4306debb350388dd2b7a2cbfe295eb99723988e2
Summary:
Fabric's Telemetry uses `std::chrono::steady_clock::time_point`s to represent the exact moments in time when some events happen. This is the same clock that pretty much any performance tracker use (and should use), QPL included.
However, different trackers use different serializable representations of that timepoints. This diff adds functions that convert the timepoint value to UNIX Timestamp and to a number of seconds from the `steady_clock` epoch start.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D22887632
fbshipit-source-id: 2b51acddccee9af8071a34797b5015d6fd008394
Summary:
Now SurfaceTelemetry records the last 16 full transaction telemetries. We will use it info to report to our trackers.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D22887633
fbshipit-source-id: 0d88adff757e4bc5a701b51d4d06d85e1f51f10f
Summary:
This diff removes the inner folder of react/renderer/core, moving all its files into react/renderer/core
This is necessary to simplify the compilation of Fabric in OSS
More details: https://fb.quip.com/amaRA631DX3K
changelog: [internal] Internal
Reviewed By: fkgozali, JoshuaGross
Differential Revision: D22875854
fbshipit-source-id: e2d969c3ec67eab1bbdc9288e5a4285c740fa944
Summary:
If `__turboModuleProxy` is called with a second argument, we'll now forward that `jsi::Value` to TurboModuleManager on iOS and Android, so that the TurboModuleManager can eventually use this `jsi::Value` to read data required to perform method invocation on the TurboModule object.
**Note:** This diff is basically a no-op right now.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D22828838
fbshipit-source-id: 19db2adcae6a58b4885fcd11bef23f9d5882bfce
Summary:
This diff moves fabric C++ code from ReactCommon/fabric to ReactCommon/react/renderer
As part of this diff I also refactored components, codegen and callsites on CatalystApp, FB4A and venice
Script: P137350694
changelog: [internal] internal refactor
Reviewed By: fkgozali
Differential Revision: D22852139
fbshipit-source-id: f85310ba858b6afd81abfd9cbe6d70b28eca7415
Summary:
The async NativeModule method call event can fail if something goes wrong when we're about do dispatch the method call.
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D22609410
fbshipit-source-id: 699eeb78edfbefa85e417fd82318ae8e4f6f7d90
Summary:
In D17480605 (https://github.com/facebook/react-native/commit/689233b018bd533a7eecd38e38a7fb84b849cf88), I made all methods with void return types dispatch to the NativeModules thread. This diff makes the same change to methods with promise return types.
**Note:** The changes are disabled for now. I'll add an MC so that we can test this in production in a later diff.
Changelog:
[Android][Fixed] - Make promise NativeModule methods dispatch to NativeModules thread
Reviewed By: PeteTheHeat
Differential Revision: D22489338
fbshipit-source-id: d5b030871f9f7b3f48eb111225516521493cb05e
Summary:
Changelog:[Fabric][iOS] Add full support for AccessibilityState
Since the AccessibilityState checked, busy or expanded only exist in Android and they don't have corresponding AccessibilityTrait to set, so we could just ignore the implementation in RCTViewComponentView.mm. What I did is to update the AccessibilityState values in AccessibilityPrimitives.h and accessibilityPropsConversions.h in order to enable further implementation in Android.
Reviewed By: shergin
Differential Revision: D22807584
fbshipit-source-id: f3ef048055d11314bc833357d8ca061e0fe219a4
Summary:
Changelog: [Internal][Added] Support for toggling all breakpoints in Chrome debuggers
This implements the Debugger.setBreakpointsActive CDP message, allowing
users in Chrome to toggle all exceptions on and off.
As with V8/Chrome, setting a breakpoint will automatically re-activate
all breakpoints.
#utd-hermes-ignore-android
Reviewed By: avp
Differential Revision: D22825209
fbshipit-source-id: bda2cc59aba04443280bca46126c19bb0cdb58d7
Summary: As part of our usage color detection that relies on precise values of colors, it appears that the ration used was 256, but RBGA scale is 0-255
Reviewed By: shergin
Differential Revision: D22785378
fbshipit-source-id: 87a6f9b4611ceaadbbbb75a4566f4cf9b8285b68
Summary:
The standard says that zIndex should only be defined for non-`static` positioned views. This diff implements it.
For now, it actually enables zIndex for all views in RN because there is no way to specify `position: static` but will will give that ability by changing Flow definitions in future diffs in a couple of weeks (to ensure OTA safety).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22098586
fbshipit-source-id: 77dacbee0fe887f667ba81640b8bd759e1df11fd
Summary:
In W3C standard, `zIndex` prop can have `auto` value which is the default.
In classic React Native and in Fabric before this diff, the default value was `0`. The only difference between `auto` and `0` is that nodes with `auto` do not form stacking context whereas nodes with `0` (or any other numeric value) do. This worked fine in pre-Fabric RN where every view always formed staking context but in Fabric we need to finally implement it right.
https://developer.mozilla.org/en-US/docs/Web/CSS/z-indexhttps://stackoverflow.com/a/57892072/496389
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22403383
fbshipit-source-id: 6532d180a00f22bde763e3ebadd6683b344a0672
Summary:
In the current Fabric model, we compute layout during the commit phase on the caller thread synchronously. Even though, in general, it's by design the correct way to do it, there are cases where it's *not* a requirement. In such cases, it's more optimal to yield early and continue execution of the commit process on a different thread asynchronously.
One of such cases potentially is `completeRoot` call. There we don't need to return anything and can resume JavaScript execution immediately.
The performance implications of that are not clear but there is a hope that it can free up to ~100ms of JavaScript execution time which is currently spent waiting for layout calculation (and other aspects of the commit phase).
This is an implementation in the core. The plan is to test that on iOS first and then, in case if the results of the experiment are positive, to implement it on Android as well.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D22743723
fbshipit-source-id: 846a13152c5a419de0eaef0e6283ea4277c907dc
Summary: For the JS TurboModule Codegen, we'll have to have `__turboModuleProxy` accept an additional argument: information containing what methods are supported on the TurboModule object. This diff makes calling `__turboModuleProxy` with two arguments valid.
Reviewed By: shergin
Differential Revision: D22743294
fbshipit-source-id: fd0050fc0373b43dc7089695c8e341137cad21f1
Summary:
Unfortunately LayoutAnimations index adjustment is a bit tricky. There was one (hopefully only one!) remaining issue where a specific series of delayed removes, inserts, and removes would trip up index adjustment. Namely in this case: Preexisting delayed removes, and then a later animated commit with immediate inserts followed by higher-index removes.
This case is now resolved and I took time to test and verify other index adjustment paths.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22709915
fbshipit-source-id: 16ba5bb358608d384f44628dbb6cc691deb8164a
Summary:
Changelog: [Internal] Fabric-specific internal change.
This diff introduces a new value for `YGPositionType`: `YGPositionTypeStatic`.
No part of Yoga, RN, Litho or CK uses this value yet. `relative` and `static` values behave the same way for now. We also do not change any defaults. So, it should be fine.
Reviewed By: SidharthGuglani
Differential Revision: D22386732
fbshipit-source-id: 39cd9e818458ac2a91efb175f24a74c8c303ff08
Summary:
Chrome recently changed schema from 'chrome-devtools' to just 'devtools',
this change updates Hermes inspector cli tool usage string to reflect that change
Changelog: Minor fix in Hermes Inspector cli tool help message
Reviewed By: dulinriley
Differential Revision: D22557806
fbshipit-source-id: 95ec9cbaac445e105e7e92aec2b6c4e5a7d7924f
Summary:
This diff implements TelemetryController, a small tool that can be used to instrument mounting transactions. It abstracts the logic of merging telemetry data of multiple transactions in a thread-safe manner.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22490580
fbshipit-source-id: 3f3425b88d38fddb555c1390fd8f1ff3ef1c475a
Summary:
SurfaceTelemetry data structure represents telemetry data associated with a particular running Surface. We need it to aggregate data from multiple mount transaction.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22490579
fbshipit-source-id: e087aa9bc236af4da7010d67941f9ac93ad6da97
Summary:
Changelog:
[Internal][Fixed] - Fix the accessibilityRole crash
I only assigned three values that would be used for embedded links inside text (button, link, image). But the accessibilityRole has a lot of values that may be applied in other places. (https://reactnative.dev/docs/accessibility) To avoid this crash, need to add all possible values to the enum.
Reviewed By: JoshuaGross, shergin
Differential Revision: D22549264
fbshipit-source-id: dbaacf1965624e1d2eabe193b46168c6c8740f46
Summary:
Changelog:
[Internal] - Revert "Change the accessibilityRole from a string to an enum."
Original commit changeset: b46ce0bd156c
Reviewed By: PeteTheHeat
Differential Revision: D22540391
fbshipit-source-id: df4a62c7bb4525782121dea2c70a9101cf0d8e9f
Summary:
Now Yoga.cpp does not use the `YGPositionTypeRelative` value/constant, it uses `YGPositionTypeAbsolute` instead.
Now `YGPositionType` can only be `YGPositionTypeRelative` or `YGPositionTypeAbsolute`, so expressions `x == YGPositionTypeRelative` and `x != YGPositionTypeAbsolute` are equivalent.
The reasoning behind the change is that in all cases we actually check a node to be (or not to be) `absolute`, not `relative`. This will make a difference in the coming diffs in the stack when we will introduce a new value for the type: `static`.
We need to differentiate `static` and `relative` values t implement the `stacking context` feature in the W3C-compliant way (to fix bugs and avoid developer confusion). Read more here:
https://developer.mozilla.org/en-US/docs/Web/CSS/position
Changelog: [Internal] Internal change in Yoga.
Reviewed By: SidharthGuglani
Differential Revision: D22386733
fbshipit-source-id: 8e2c2b88b404660639f845783c8f93f0c62c0fbb
Summary:
During setup, TurboModules may synchronously dispatch to the main queue, if they require main queue setup. This is dangerous because it could cause the app to deadlock during TurboModule require. This is why D21654637 (https://github.com/facebook/react-native/commit/e206e34175c091a753c0e733abeda41b662241d4) added a warning aginst this. However, this diff had a mistake. We only want to display the warning if TurboModule eager initialization is enabled, because then, we can eagerly initialize the TurboModules before the bridge starts to avoid the problem. D21654637 (https://github.com/facebook/react-native/commit/e206e34175c091a753c0e733abeda41b662241d4) instead showed the warning if TurboModule eager init **wasn't** enabled. This isn't useful, because there's no way to avoid the problem with TurboModu eager initialization off.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D22529780
fbshipit-source-id: 15238483758b66b1a6addcad948203c64dca96ad
Summary:
Changelog:
[Internal] - Change the accessibilityRole from a string to an enum.
The change aims to save storage especially when scaling. Also, the enum makes it more difficult to input wrong because it gets checked when compiling.
Reviewed By: sammy-SC
Differential Revision: D22396351
fbshipit-source-id: b46ce0bd156c7705020ef5b061d8ac29e2cf3948
Summary:
Changelog: [Internal]
When calling "measure" on ScrollView's children, origin needs to be adjusted for ScrollView's content offset.
For this scrollView uses `getTransform` to adjust frames of its children.
This is wrong because transform is applied to ScrollView as well.
Example:
ScrollView is scrolled 900 points and its origin is {0, 0}, if you call "measure" on the ScrollView, our current measure infra will report its origin being {0, 900}.
Reviewed By: shergin
Differential Revision: D22456266
fbshipit-source-id: 6fd54661305ad46def8ece93fcf61d66817b3e01
Summary:
Changelog: [Internal]
Add view hierachy drawings to tests to make it easier to picture view hierarchy.
The sketches do not reflect sizing but relationship among the views.
I removed unnecessary reset of transform value to identity matrix.
Reviewed By: JoshuaGross, shergin
Differential Revision: D22456267
fbshipit-source-id: 480d0b938ffd0281fc94148570c412b0fcc22f42
Summary:
TurboModule eager initialization is a bit dangerous if we get it wrong, which we did (twice): T69449176.
This diff gates TurboModule eager init behind a MC, so that we can control (i.e: turn off/on, and do gradually rollout of) TurobModule eager initialization in isolation from the larger TurboModules experiment.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D22460359
fbshipit-source-id: 3b8dce0529f1739bd68b8b16d6a28aa572d82c2c
Summary:
When you require a TurboModule on thread that isn't the main thread, but the TurboModule requires main queue setup, we are forced to `dispatch_sync` the set up to the main queue. This is hazardous, because it can lead to deadlocks. Therefore, I'm migrating over a warning from the legacy infra that warns against this use-case.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D21654637
fbshipit-source-id: 99dc45708c533603d2111fe6163d40e807d2a513
Summary:
The changes in this diff are inconsequential. Just thought it was weird that TurboModuleManager was responsible for assigning itself to the bridge. Seems like that should be done by an entity that owns both the bridge and the TurboModuleManager.
Changelog:
[Internal]
Reviewed By: PeteTheHeat
Differential Revision: D22406172
fbshipit-source-id: cb32f097f4d377a3b85a6d165b7b06be8e6a185b
Summary:
## Why?
1. RCTTurboModuleLookupDelegate sounds a bit nebulous.
2. In JS and Java, we use a `TurboModuleRegistry` interface to require TurboModules. So, this diff will make JS, Java, and ObjC consistent.
Changelog:
[Internal]
Reviewed By: PeteTheHeat
Differential Revision: D22405754
fbshipit-source-id: 30c85c246b39d198c5b8c6ca4432a3196ca0ebfd
Summary:
## Context
1. In FBReactModule jsExecutorForBridge, we asynchronously initialize a list of TurboModules on the main queue: https://fburl.com/diffusion/i56wi3px
2. After initializing the bridge, we start executing the JS bundle, here: https://github.com/facebook/react-native/blob/e23e9328aa164d0a70fe4f16042c982e7801d924/React/CxxBridge/RCTCxxBridge.mm#L414-L417. Since bridge initialization knows nothing about TurboModule eager initialization, this happens concurrently with 1, and starts requiring NativeModules/TurboModules on the JS thread.
## The Race
1. Both the main thread and the JS thread race to create a TurboModule that requires main queue setup.
2. The JS thread wins, and starts creating the TurboModule. Meanwhile, the main thread blocks, waiting on a signal here, in RCTTurboModuleManager: https://github.com/facebook/react-native/blob/e23e9328aa164d0a70fe4f16042c982e7801d924/ReactCommon/turbomodule/core/platform/ios/RCTTurboModuleManager.mm#L430
3. The JS thread tries to dispatch_sync to the main queue to setup the TurboModule because the TurboModule requires main queue setup, here: https://github.com/facebook/react-native/blob/e23e9328aa164d0a70fe4f16042c982e7801d924/ReactCommon/turbomodule/core/platform/ios/RCTTurboModuleManager.mm#L402
4. We deadlock.
## The fix
Succinctly, NativeModule eager initialization finishes before execute the JS bundle, but TurboModule initialization doesn't. This diff corrects that mistake.
The changes in this diff:
1. The RN application via the TurboModuleManager delegate can now optionally provide the names of all eagerly initialized TurboModules by implementing two methods `getEagerInitModuleNames`, `getEagerInitMainQueueModuleNames`.
2. The TurboModuleManager grabs these two lists from the delegate, and exposes them to its owner via the `RCTTurboModuleRegistry` protocol.
3. The RCTCxxBridge, which already owns a `id<RCTTurboModuleRegistry>` object, uses it to eagerly initialize the TurboModules in these two lists with the correct timing requirements.
This is exactly how we implement eager initialization in Android.
**Note:** Right now, phase one and two of TurboModule eager initialization happen after phase one and two of NativeModule eager initialization. We could make the timing even more correct by initializing the TurboModules at the exact same time we initialize the NativeModules. However, that would require a bit more surgery on the bridge, and the bridge delegate. I think this is good enough for now.
Changelog:
[iOS][Fixed] - Fix TurboModule eager init race
Reviewed By: PeteTheHeat
Differential Revision: D22406171
fbshipit-source-id: 4715be0bceb478a8e4aa206180c0316eaaf287e8
Summary:
Currently the `remove` API returns an owned unique_ptr of the removed ShadowTree but it's not used anywhere, so we can simplify the API.
Because of that change, we can make the API safe even if the SurfaceId has already been removed.
For context, on Android there is a race between RootView.unmountReactApplication and C++ teardown which removes all SurfaceIds. This currently causes a crash, but after this diff the 2nd call to `remove` for a given SurfaceId will noop.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D22416471
fbshipit-source-id: dbba44c276aab8e81097b92a89e0becdcb7b28ba
Summary:
We are about to add several additional functions to this file, so we need to split it to keep it manageable. All changes in this diff are cosmetical.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22384429
fbshipit-source-id: d22592fba17ef04edb44388b4e1ff22112e9c020
Samuel Susla
Luna Wei
David Vacca
Thomas Nardone
Joshua Gross
Valentin Shergin
Ramanpreet Nara
Jiayan Zhuang
Will Holen
Patrik Tomas Chamelo
Oleg Bogdanov
Eloy Durán