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
Summary:
Fix crashes in LayoutAnimations:
1) It is valid to omit create, update, delete configs
2) When extracting SRT from a matrix, ignoring skew properties
3) Provide valid telemetry from LayoutAnimations transactions
Unrelated to crashes: to help debugging and until onSuccess/onError callbacks are working, log any configuration parsing errors.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22050736
fbshipit-source-id: e59418ecad0f9bfd20a2b4976557e39020c2d101
Summary:
This diff fixes a race condition that caused a flicker during initial rendering of TextInput in Fabric
The root cause is that the TextInput's State is sometimes initialized with no information from the Theme, this causes text input to be rendered with 0 padding. Later ReactTextInput manager updates TextInput state with theme data and the TextInput is re-rendered with the correct padding information.
changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D22034849
fbshipit-source-id: a2fa91f34a8340878f2ec8d231ef6c86cee08f05
Summary:
This pull request updates the Podspecs to reflect recent changes to Fabric, so they build with Fabric enabled again.
In `React-Fabric.podspec`, subspecs for the views `legacyviewmanagerinterop`, `safeareaview`, `textinput`, and `unimplementedview` are added. A minor tweak to the subspec for `rncore` was added blacklisting two codegen-generated files that have issues building, but are not actually needed yet and are empty.
In `React-graphics.podspec`, the header paths for Boost were added.
This is partially a retread of https://github.com/facebook/react-native/issues/26805, which had to be backed out due to issues with the changes to the Yoga podspec.
## Changelog
[Internal] [Fixed] - Fixed building Fabric with the Cocoapods
Pull Request resolved: https://github.com/facebook/react-native/pull/28584
Test Plan: RNTester can now compile.
Reviewed By: shergin
Differential Revision: D20966065
Pulled By: hramos
fbshipit-source-id: 73931be63b72fcb52705643f81c0f787e571eb76
Summary:
Changelog: [Internal]
Round calculated text size to closest larger pixel size.
In Paper we do this as well in https://fburl.com/diffusion/w2pj6ea0
Why do we need this?
For example, we calculate height of the text to be 16.707235, yoga takes this value and assigns text to have height 17 anyway.
I assume Yoga uses this extra 0.3 points of height to move other things around a little bit because Yoga doesn't deal with exact values.
Reviewed By: shergin
Differential Revision: D21999032
fbshipit-source-id: 73923dc3e27fa110adb3f76cfa635e0bfdc672d4
Summary:
There is no good reason why they are `const` and `private`, in the future diffs we will need to mutate them.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D21992197
fbshipit-source-id: f8aee8db9ea1ff8282b38fbe3a966911678ee2c4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/29090
Moving the logic for calling into JS to handle errors into ErrorUtils, where it can be reused outside of the bridge.
Reviewed By: RSNara
Differential Revision: D21939254
fbshipit-source-id: 0d8f3bd2503720be7619ed8dc8b2389f544049f3
Summary:
While I was investigated the previous issue (T59430348) I found this place where we manipulate managed pointers manually. So, to make it error-prone this diff changes it to use `wrapManagedObject`.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D21943010
fbshipit-source-id: ecaeffb419ae8d4880187027ca7ec9563e0dfd46
Summary:
ManagedObjectWrapper (`wrapManagedObject`) is used to pass pointers managed by Objective-C runtime object thought C++ parts of the framework. The wrapper consists of a shared pointer to an object with a custom deleter that calls `CFRelease`.
Apparently, there is a caveat here: shared ptr implementation always calls a deleter even if the object points to `nullptr`. It's usually fine because in C++ calling `delete` on a nullptr is a no-op, not an error. But it's an error from the `CFRelease` perspective, which checks the pointer and crashes if it's nullptr.
More info:
https://stackoverflow.com/questions/1135214/why-would-cfreleasenull-crashhttps://stackoverflow.com/questions/50201967/why-unique-ptr-with-custom-deleter-wont-work-for-nullptr-while-shared-ptr-does
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D21943011
fbshipit-source-id: 442ad5e274a146de112e6bd8f3c2d20f0225bf77
Summary:
Changelog: [Internal]
`CFRelease` crashes app if `cf` is `NULL`, `CGColorRelease` doesn't.
From:
https://developer.apple.com/documentation/coregraphics/1586340-cgcolorrelease?language=objc#
Even though this hasn't happened yet, we had a similar crash in D21943011. Also `CGColorCreate` returns nullable so it could happen.
In order to prevent this in the future, let's switch to `CGColorRelease` which doesn't crash if `cf` is `NULL` and also is semantically correct.
Reviewed By: shergin
Differential Revision: D21953404
fbshipit-source-id: 8b969ee345c2507fcba2442fa20e3fdaf2235d8c
Summary:
Changelog: [Internal]
View gets flattened even though it has `display: none` and therefore it and its children do not get hidden.
Reviewed By: shergin, mdvacca
Differential Revision: D21929033
fbshipit-source-id: 994a79fb64fbe66273a70218ebe8056d92cd3cd4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/29087
D21908523 added an implicit dependency on `jsi.h` to use functions like `asObject`, etc. For some reason this doesn't break the build with BUCK (??) but it does with cocoapods. Adding the dep to the cxxreact podspec and regenerating offline mirrors to unbreak CircleCI. Also adding the BUCK dep and include statement for good measure.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21924592
fbshipit-source-id: 295c0670c6499e1195ba3c3a3320c6aee13bc025
Summary:
Changelog: [Internal]
The crash is caused by dereferencing invalid pointer.
This can happen because `UIManager` can outlive `RCTScheduler` and `Scheduler`.
Here we make sure when `Scheduler` is being deconstructed, UIManager's pointer is invalidated.
I don't think this is ideal solution but it should fix the crash.
Ideally we want the owner of animation delegate to invalidate the pointer.
Reviewed By: JoshuaGross
Differential Revision: D21922910
fbshipit-source-id: b2a56c1104574cecebaffad1bcbcbff82c1fa0cf
Summary:
Call into our existing JS error handling logic from C++ using JSI in the RuntimeExecutor used by the bridge.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D21908523
fbshipit-source-id: ae41196443781b9f2673dcb7bbcb5b5aa8aa2528
Summary:
Changelog: [Internal]
# Problem
`MountingCoordinator` holds a pointer to instance of `MountingOverrideDelegate` which becomes invalid.
# Solution
Use `std::weak_ptr` instead of raw pointer so it is possible to tell whether the pointer is expired.
Reviewed By: JoshuaGross
Differential Revision: D21905351
fbshipit-source-id: c7bf9635742a6ec086a03ba83202e46e1f1f373f
Summary:
This diff adds support elevation prop in Fabric core, additionally it adds this prop as non collapsable on the view flattening algorithm
changelog: [Internal] internal change in fabric to support elevation prop
Reviewed By: JoshuaGross
Differential Revision: D21896465
fbshipit-source-id: e0854acc0b2ac30eaf3f82d615aab1cf378cc530
Summary:
JSError creation can lead to further errors. Make sure these cases
are handled and don't cause weird crashes or other issues.
This solution has a few parts:
* include a ScopedNativeDepthTracker in checkStatus
* If an exception object message or stack property is already a String, don't
call JS String ctor on it
* Verify that a jsi::Value is a String before calling getString on it.
* Add more tests for JSError construction
Changelog: [Internal]
Reviewed By: dulinriley
Differential Revision: D21851645
fbshipit-source-id: 2d10da0e741ad4ede93cd806320f68ad512e5138
Summary:
There are two ways to make a NativeModule method execute synchronously:
- Declare the NativeModule method to be synchronous (i.e: use `RCT_EXPORT_BLOCKING_SYNCHRONOUS_METHOD`).
- Make the NativeModule synchronous (i.e: make its method queue `RCTJSThread`). This way, all its methods are synchronous.
`RCTNativeModule` executes all synchronous methods on the JS thread:
- Executing an async methods on a sync module: https://git.io/JfRPj
- Executing a sync method: https://git.io/JfRXe
However, in TurboModules we block the JS thread, execute the method on the NativeModule's method queue, and then unblock the JS thread. While this approach is thread-safe, and arguably the correct way to dispatch sync methods, it's also much slower than the alternative. Therefore, this diff migrates the legacy behaviour to the TurboModule system.
## Special Case: getConstants()
When an ObjC NativeModule requires main queue setup, and it exports constants, we execute its `constantsToExport` method on the main queue (see: [RCTModuleData gatherConstants](https://github.com/facebook/react-native/blob/c8d678abcf93fd3f6daf4bebfdf25937995c1fdf/React/Base/RCTModuleData.mm#L392-L402)). I replicated this behaviour with TurboModules.
Changelog:
[iOS][Fixed] - Execute ObjC TurboModule async method calls on JS thread for sync modules
Reviewed By: fkgozali
Differential Revision: D21602096
fbshipit-source-id: 42d07b7ad000abeac27091dc3ec440e3836d2eae
Valentin Shergin
Samuel Susla
Joshua Gross
Omer Peleg
Vitaly Potlov
David Vacca
Daniel Andersson
Luna Wei
Kacie Bawiec
Christoph Nakazawa
empyrical
Emily Janzer
Ryan Tremblay
Sidharth Guglani
Paige Sun
Marc Horowitz
Ramanpreet Nara