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
Summary:
Changelog:
[Internal] - Add `accessibilityRole` to `RCTAttributedTextUtils`. AccessibilityRole was in `TextAttributes` which is a Fabric's abstraction so cannot be detected when enumerating attributedString. Mapping accessibilityRole from `TextAttributes` to `NSAttributedString` could provide the attributeName when iterating over attributedString and then successfully find the range of the fragment whose `accessibilityRole` has value @"link".
Reviewed By: shergin
Differential Revision: D22286747
fbshipit-source-id: eb039d6a35e77d1860f86ba287391ccb56fbe7b5
Summary:
Changelog:
[iOS][Added] - `getRectWithAttributedString()` aims to get the rect of the fragment with embedded link, which is necessary when building the `accessibilityElement`. In this function, we first enumerate attributedString to find the range of fragments whose `accessibilityRole` is @"link". Then we calculate the rect of the fragment and send to the block and we would define what to do in the block in `RCTParagraphComponentAccessibilityProvider`.
Reviewed By: shergin
Differential Revision: D22286733
fbshipit-source-id: 4d11cb54375a4e9e72869e646fcb484de089b14b
Summary:
ART has been moved out of OSS, but I created the fabric implementation in github repo, this diff migrates the Fabric ART implementation to FB repository again
changelog: [Internal]
Reviewed By: shergin
Differential Revision: D22352930
fbshipit-source-id: 1125d3f27b98be783529134de0d3fbcf1b01a6f4
Summary:
Changelog:
[Internal] - The accessibilityRole will be used to specially distinguish normal fragments and fragments with embedded link, which is helpful when building accessibilityElement.
According to this document: https://reactnative.dev/docs/accessibility, the accessibilityRole is a common accessibility props that could be inherited, and this is why I add accessibilityRole to the TextAttributes.
Reviewed By: sammy-SC
Differential Revision: D22249140
fbshipit-source-id: 408b4415bf44539d8671d3d98f1ec06f8035baf6
Summary:
Changelog: [Internal]
FindNoteAtPoint takes transformations into account. There is however a problem with how transformation in ScrollView. In ScrollViewShadowNode, getTransform is overriden. In the override we apply `Transform::Translate(-contentOffset.x, -contentOffset.y, 0)`, this means that ScrollView has moved by {-x,-y}. However this is only true for its children, not for scroll view itself. This trips off findNodeAtPoint and if you scroll more than than screen's height, point will not be evaluated as inside ScrollView.
Until we can figure out how to deal with this properly, I think it is better to disable it as usage of JS Inspector is more common in ScrollViews than it is with transformed views.
Reviewed By: shergin
Differential Revision: D22332779
fbshipit-source-id: f48c9ae67a595e6954c2b70fb287db7f8c74378b
Summary:
This was an experiment that never shipped. In the meantime we built Fast Refresh which obviates the need to complicate how we load and store bundles on device.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D22330994
fbshipit-source-id: 5a623b2611dd2622f17dd83ed35ef05c3100e40d
Summary:
This introduces a new shadow node trait (`Hidden`) which disables emitting ShadowVides for such nodes and all their descendants.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22134220
fbshipit-source-id: 8ea1fc3186019005ad687eacaca0ba4a4d8343dc
Summary:
The Hermes inspector always logged the message for `console.assert`.
It instead should check the first argument, and only if that argument
is false should it log.
Also remove the polyfill code that tried to avoid this situation.
Changelog: [Internal]
Reviewed By: mhorowitz
Differential Revision: D22299186
fbshipit-source-id: cdf4f8957d4db3d171d6673a82c7fc32b7152af3
Summary:
It's a Yoga specific feature that does not need to exposed as LayoutableShadowNode.
Removing this we save many virtual calls and add simplicity.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22304717
fbshipit-source-id: f2dda8309dd86b78cd2775971721d29e5317ffd5
Summary:
`Overflow inset` is a field in LayoutMetrics that describes the external bounding box that covers area formed by all descendants of the view (that might stick out of the frame of the view).
This information can be used for various optimizations across all rendering pipeline. Here is some of them:
Improving hit-testing performance.
Implementing a robust "remove invisible native views" feature.
Improving `clipToBounds` performance.
Improving View Flattening versatility.
Most importantly, we need this for improving <ScrollView> performance (and memory footprint) which we have to do to match parity with Paper's `removeClippedSubviews` feature.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22297325
fbshipit-source-id: cb238f0505d11ccabbe9db26f36a98b3172c70db
Summary:
After years of trying to design a somehow decomposed and universal layout API, I think we chased a wrong goal. None of the solutions that I tried helped with simplicity, composability, performance, or readability. Besides that, a bunch of execution primitives we use (e.g. `setHasNewLayout`) are heavily influenced by Yoga and are far from being commonly applicable. Finally, we ended up with a situation where the current design does not allow us to implement the features we want (more about that in coming diffs).
The diff changes that. Now we have only one method that implements layout - `layout()`; all possible implementations are free to implement it in any way that makes sense for a particular approach. And, I think, even for the base case - Yoga powered layout - things are much simpler and faster now: it's easy to comprehend how a single method works and now we don't have two loops and an expensive call to `getLayoutableChildNodes`.
But most importantly, after this change will be able to implement the `Inset Overflow` feature quite easily.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D22297317
fbshipit-source-id: f8662b7e8e3b522bdd6e5b2b0ac6a06efb45be6d
Summary:
Changelog: [Internal]
Introducing InputAccessoryView.
There is one big difference between Fabric's implementation and Paper's implementation.
Fabric searches for text input from InputAccessoryView, unlike Paper where it is the other way around.
Reviewed By: shergin
Differential Revision: D22160445
fbshipit-source-id: 55313fe50afeced7aead5b57137d711dd1cfd3ae
Summary:
View elevation is an Android-only prop, and it's a float, not an int. https://www.codota.com/code/java/methods/android.view.View/setElevation
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D22298431
fbshipit-source-id: 91edc3aa64e7254a5c4a4cb33f26e64ebae89b8d
Summary:
Here is why:
* It was with us from the very beginning but we never use it.
* The main purpose of this - snap-to-pixel layout - was moved to Yoga, where it should be.
* The current implementation has a bug.
* It's not really correct conceptually because the value becomes incorrect when an immutable subtree is being reused as part of a new tree.
* It over-complicates a new feature I am working on.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22284645
fbshipit-source-id: c4c2df8d24e8fe924725b465e04e8154d097d226
Summary:
A function in graphics/geometry which adjusts a rectangle by the given edge insets.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22284644
fbshipit-source-id: ad78abd7889b4457c450b2cc43fb73054aef2c79
Summary:
Attempt to fix T68951888 where (1) ComponentHandle is zero, and/or (2) ComponentHandle is missing in the registry. Either will cause a crash and both should be trivial to work around. I was able to repro once accidentally in about 1/200 sessions, so I am not 100% sure if this fixes the root cause.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D22216030
fbshipit-source-id: b6986adee6fe739ce58579a2b031a2d252e73e35
Summary:
Previously, we tried to take a Transform matrix, decompose it into parts, and then interpolate between those parts. This will always be risky at best, and in some cases ambiguous or unsolvable. For example, a scale of -1 is identical to a rotation of 180 degrees.
Another issue is that when decomposing a matrix, it is impossible to tell the sign of scaleX, scaleY, scaleZ. This is a problem - flipping a View over an axis via scale then becomes a non-animatable operation.
This caused a number of issues.
To resolve it, we accumulate the "operations" resulting in a particular transform. This allows us to easily interpolate between two Transform matrices without actually decomposing the matrix, since we have the "path" that resulted in each particular matrix.
This will make LayoutAnimations over transforms, including Skew transforms, look and work much better, and more reliably.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D22204559
fbshipit-source-id: 0d88ae77e4399a7ea333afbf6062beea977b854a
Summary:
Changelog: [Internal]
When Paper loads images. it calls with with `clipped` being set to NO.
https://github.com/facebook/react-native/blob/master/Libraries/Image/RCTImageView.mm#L346
We should do the same in Fabric as it can result in different images being loaded.
Reviewed By: JoshuaGross, shergin
Differential Revision: D22185286
fbshipit-source-id: 04afafee67fdfac53e9d17f5edeaf9b9317c7a22
Summary:
This diff refactors the theme management for text input in order to avoid extra state updates.
changelog:[Internal]
Reviewed By: JoshuaGross
Differential Revision: D22149754
fbshipit-source-id: 8a6dbe63c8d532986dbf785c7b16323e0a980669
Summary:
Index adjustment is complicated since we defer REMOVE operations. This diff solves some remaining (hopefully final!) bugs found when queueing several conflicting LayoutAnimations repeatedly (this is sort of an "extreme" case since we're continuously re-queueing additional LayoutAnimations instead of allowing any to complete, while reordering and deleting, so it exercises the most extreme LayoutAnimations use-cases).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22150085
fbshipit-source-id: db1381bef3ba8bb5ec82dab791f69162d46d23f0
Summary:
This will prevent views from becoming out-of-order as view removals are delayed and there are inserts at the same level.
There is at least one additional issue that crops up if many animations are queued up at the same time, that will be resolved separately.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D22130185
fbshipit-source-id: d8041c6afdcd729939dd392c9e2c23fe8ec1b706
Summary:
Changelog: [Internal]
Order of events dispatched to JS matter. If we remove duplicate events, we shouldn't change order of types.
So If we have order of events
A -> B -> C
and inserting a new event A for the same target, we shouldn't delete the first A, as there might be logic that depends on event B being preceded by A.
What we can do though, is delete previous event of the same type and target in queue if we would be adding subsequent event.
So when we have events
A -> B -> C
and we are about to add event C to the queue which goes to the same target, we can delete the first C before inserting the new one.
Reviewed By: shergin
Differential Revision: D22135931
fbshipit-source-id: 1dadd1688516330be07c4251f446f77ca08eaa87
Summary:
When asking for the data of a JSBigFileString, check that the instance satisfies some basic invariants.
This is meant to catch any corruption issues as early as possible.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22125436
fbshipit-source-id: e0a84752c86151d56b7e7cbed3b95650d8ba1f75
Summary:
Add tooltip to the list of components supported with the legacy view manager, so that it will work in Fabric.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D21917137
fbshipit-source-id: 1ab6c7cdd0a10a496531d2ea8fbcae7e427ec647
Summary:
Changelog: [Internal]
Add support for dynamic font size.
New class `ThreadStorage` is introduced, which is used to pass LayoutContext to `YogaLayoutableShadowNode::yogaNodeMeasureCallbackConnector`.
## Shortcoming
This implementation doesn't cause re-render, if user changes font size and comes to the app without restarting it, it will show old font size. I believe this is fine for now as most people set their font size before they use the app and keep the same setting for a long time.
Reviewed By: shergin
Differential Revision: D22043728
fbshipit-source-id: 7453d165c280a2f4bcb73f4ee6daf9e64b637ded
Summary:
Changelog: [internal]
Rename `LayoutableShadowNode::measure` to `LayoutableShadowNode::measureContent` and add LayoutContext as parameter.
Pass `LayoutConstraints` by reference rather than value.
Reviewed By: shergin
Differential Revision: D22043727
fbshipit-source-id: b668240c45b658db5b114630b73d7407d35482aa
Summary:
Changelog: [Internal]
A long time ago we experimented with JSC bytecode. We are not experimenting with JSC bytecode any more. This code can be removed.
Reviewed By: mhorowitz
Differential Revision: D22017374
fbshipit-source-id: 6fe3fb7ad7966f92a5cd103605ac5c0bd1f17a8e
Joshua Gross
Valentin Shergin
Ramanpreet Nara
Jiayan Zhuang
Samuel Susla
Eloy Durán
David Vacca
Christoph Nakazawa
Riley Dulin
Omer Peleg
Vitaly Potlov
Daniel Andersson
Luna Wei
Kacie Bawiec