Summary:
Changelog: [internal]
`shadowNodeFromValue` can return nullptr. Let's make sure it returns valid value before dispatching command.
Reviewed By: JoshuaGross
Differential Revision: D26605350
fbshipit-source-id: eb9a0347c95ba07fd7e9b7ddeca7e6d6011f50ad
Summary:
Changelog: [internal]
### Why does the crash happen?
The crash can happen if runtime is destroyed before background executor lambda is run. Destroying a shadow node after runtime leads to a crash through the chain of ownerships.
Chain of ownership:
`ShadowNode -> ShadowNodeFamily -> EventEmitter -> EventTarget -> Pointer`
Pointer tries to call `invalidate` method on raw pointer to the runtime which is gone.
https://www.internalfb.com/intern/diffusion/FBS/browse/master/xplat/js/react-native-github/ReactCommon/jsi/jsi/jsi.h?commit=2ee3ae0c6a64&lines=335-339
To work around this, weak pointers are passed to lambda. This way the lambda is less likely to be the last owner of shadow nodes. Possibility of race still exists but it less likely to happen.
## Other solution
Alternatively, we could make sure native Runnable queue in Java is emptied as part of tear down process. We can even implement both solutions as they are semantically correct.
Reviewed By: shergin
Differential Revision: D26582554
fbshipit-source-id: b1b8a92237902bc4c40376176f575caa24a41a05
Summary:
Surprisingly, it's not that trivial to pass `LayoutContrants` to `YGNodeCalculateLayout` in a way that always works. The problem is that `YGNodeCalculateLayout` does not allow expressing the constraints explicitly, so we need to pass them as `YGStyle` properties of a root node. With this approach, we unconditionally apply them as `YGStyle`s as actual values or `Undefined` value (which overrides some other values that can be previously set by calling this function or other code). We also intentionally preserve `height` and `width` values because it's a common use-case when a component explicitly specifies its size.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D26583550
fbshipit-source-id: 2cd506fbdc9e6a1a8f119d09ccfd34f876a13625
Summary:
Changelog: [internal]
shergin found that folly's merge_patch implementation doesn't propagate `null` correctly (details in D26435620 (https://github.com/facebook/react-native/commit/1e9f63fe277c42d812ef007ced7eff1688602b62)). This is a requirement and needs to be adjusted in props forwarding on Android.
As far as we know this isn't causing any bugs but it is an error that should be fixed.
Reviewed By: shergin
Differential Revision: D26545821
fbshipit-source-id: 9edd24aecfcde17f5d9c1197f65db0e0f3f9e364
Summary:
We have a custom STUB_VIEW_ASSERT that helps debugging stub view issues on platforms (like iOS) where flushing logs around assert-time isn't 100% guaranteed.
Move that logic into react_native_assert since it's generally useful.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26567218
fbshipit-source-id: 79f5ae66fc65a0af48dbcf4c7204ac8245911cb0
Summary:
See react_native_assert.{h,cpp}. Because of the BUCK+Android issue where NDEBUG is always defined, we use react_native_assert instead of assert to enable xplat asserts in debug/dev mode.
This migrates most of the codebase, but probably not 100%. The goal is to increase assertion coverage on Android, not to get to 100% (yet).
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D26562866
fbshipit-source-id: a7bf2055b973e1d3650ed8d68a6d02d556604af9
Summary:
These assertions will already run by default on iOS, macOS, Windows, etc, all OSes except Android because of a longstanding Buck+Android NDEBUG issue.
Align platforms by using REACT_NATIVE_DEBUG flag.
Only impacts debug/dev builds.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D26561977
fbshipit-source-id: 324875c48b2a138e8ab55630c3e2ec43c2f768c3
Summary:
Use REACT_NATIVE_DEBUG for consistent branding and to prevent potential collisions with other codebases.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26517424
fbshipit-source-id: c85740d4e5320cc14023eb6f521bb1a242ae56fe
Summary:
Use react_native_assert in LayoutAnimations to enable asserts to fire on Android.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26517096
fbshipit-source-id: f000c4848f29c8779170625d357f547f2e9e6365
Summary:
This will allow these asserts to crash on Android debug builds.
We will migrate more sites as we confirm this is stable through testing.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26409354
fbshipit-source-id: fb35cd8de29890f7c2b761435eaa02de377bdd1e
Summary:
BUCK always defines NDEBUG on Android builds. This is a longstanding issue and it's tricky to work around.
Previous attempts to fix this within React Native were difficult because disabling NDEBUG caused lots of issues that were difficult to track down.
Instead, I am (1) introducing a new RN_DEBUG flag that can be used cross-platform, (2) whenever NDEBUG is *not* enabled, RN_DEBUG will automatically be defined, (3) enables debug-only code to be compiled on Android, (4) enables us to selectively, slowly migrate `assert` to `rn_assert` in a way that doesn't impact non-Android platforms, but allows us to maintain stability of Android debug builds.
Actually enabling the RN_DEBUG flag in debug builds is done in FB-internal code. I assume the NDEBUG issue is not a problem when compiling in open-source without BUCK.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26409355
fbshipit-source-id: 285b8073bba3756834925727bfa28d3c6bc06335
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/30988
We have a bunch of flags scattered throughout the codebase with poor hygiene and commenting. Consolidate.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26392518
fbshipit-source-id: 2823de123a5009d6b8c358e8a3f451b9fa0e05b7
Summary:
This diff defines an initial implementation of MapBuffer class. This is an unfinished implementation and the API and internals is going to change considerably in the next days.
The purpose of this stack is to experiment with ByteBuffers moving data from C++ into Java and learn about what're the performance implications of this model.
The format of serialization is going to change in the next few days. I'm going to follow a format similar to https://fb.quip.com/3ENaA782rkkC
I'm expecting to iterate on this API as we expand the development of the new JNI system, PLEASE read all the TODOs as you are reviewing the code.
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D26364354
fbshipit-source-id: 94e434f699a4250dd240342386eddeaa6acd3ba2
Summary:
The standard merge_patch (aka RFC7386) mechanism that we used before removes the key-value pairs from the original object in case if the patch has a `null` value. And we don't need it there because we should pass this null value down to the mounting layer to clean up this prop there. Besides that, the patch should not be recursive because props are not divisible.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D26435620
fbshipit-source-id: 0d7612c6ca04dcbc122ff6add3777674e3868af8
Summary:
In D26292378 (https://github.com/facebook/react-native/commit/81147b6f793fbc00b81501393371bb332641f4c8) we changed the way the layout constraints are specified to Yoga for measuring and layout. This is a second iteration of the change that slightly more correct and fixes other problematic cases we discovered. See also the commend in the code.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D26412484
fbshipit-source-id: 06011982a63cd4d3b61ae295f9aba6f8dab6ca02
Summary:
Building ReactAndroid from source on Windows has recently hit the limitation of maximum path lengths.
At build time, during the `:ReactAndroid:buildReactNdkLib` task, the linker tries to access several of the intermediate binaries located deep in the tmp folder hierarchy, eg.
```
D:\r\ReactAndroid\build\tmp\buildReactNdkLib/local/armeabi-v7a/objs/react_render_components_progressbar/D_/r/ReactAndroid/__/ReactCommon/react/renderer/components/progressbar/android/react/renderer/components/progressbar/AndroidProgressBarMeasurementsManager.o
```
**Suggested fix:** for modules such as `react_render_components_progressbar` and `react_render_components_picker`, rename them to `rrc_progressbar` etc.
**NOTE**: this assumes that the fix from https://github.com/facebook/react-native/issues/30535 is in place. This regression happened while https://github.com/facebook/react-native/issues/30535 has been pending checkin.
**Other mitigations I've tried:**
- setting [`LOCAL_SHORT_COMMANDS`](https://developer.android.com/ndk/guides/android_mk#local_short_commands) for the problematic modules or `APP_SHORT_COMMANDS` for the root project. Turns out those commands don't work on the NDK version RN requires, but even after manually applying a [patch ](https://android-review.googlesource.com/c/platform/ndk/+/1126440) to my local copy of the NDK, these flags had no effect.
- moving the repo directory higher in the file system tree, and using short directory names `D:\r\...` was not enough
- creating virtual drive letters for specific long paths with the [`sust`](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/subst#examples) command is not workable, since they depend on the source folder structure, and get partly generated by the build system, which I can't plug into
- just enabling long path support on Windows is not enough, since the compiler toolchain doesn't support them.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Android] [Fixed] - Fix source build on Windows machines vol. 2
Pull Request resolved: https://github.com/facebook/react-native/pull/30776
Test Plan:
Run `.\gradlew installArchives`
Before:

Now:

Differential Revision: D26194286
Pulled By: mdvacca
fbshipit-source-id: 778b5a0515148e2ace19e7902f74301831ebed94
Summary:
This diff increases the severity for yoga logs to match all other logs in Fabric
changelog: [internal] internal
Differential Revision: D26315760
fbshipit-source-id: 1de3c23513ad8ce1630e3d0e3576f60608aac7de
Summary:
iOS and Android platform code already explicitly check this invariant: nodes cannot have parents when they're inserted into the View hierarchy.
Check this in the core so we get these checks in unit tests, and earlier in the core before platform code runs.
Changelog: [Internal]
Reviewed By: shergin, mdvacca
Differential Revision: D26331842
fbshipit-source-id: c12bc9066d280cb85ccc9e754c9fa475927e6080
Summary:
This hack was introduced to fix T63560216. See before/after, it no longer repros.
Changelog: [Internal]
Differential Revision: D26306134
fbshipit-source-id: 7e6f886d76f3c54912fbb548069c31faaac08786
Summary:
During earlier testing I didn't fully realize that Android disables a core bit of View Flattening: Views can be concrete or non-concrete; and their children can be flattened or not. None of these properties are mutually exclusive with each other.
Except on Android - that functionality is currently disabled. A View can be either flattened and non-concrete, or non-flat and concrete. So there are some flattening edge-cases hit on iOS but not Android, due to the larger state-space on iOS.
To test, I forced Android to align with iOS and tested; and then tested on iOS; and ensured no mounting errors, assertions, or crashes were hit during some specific tests.
Changelog: [Internal]
Differential Revision: D26298872
fbshipit-source-id: 2f0f78127a7bf057c7cf109005f1dae74f0ff6ba
Summary:
On iOS, log lines are not entirely flushed when an assert is hit right after (or during) this mutate function. Make sure to flush log lines regularly during this function so that debugging is easier.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D26291789
fbshipit-source-id: 47af109cdc3dcfc6bf08cbb41db06e9260bfaa08
Summary:
remove dead code; this flag is always defaulted to false, and not used anywhere
Changelog: [Internal]
Reviewed By: sammy-SC, mdvacca
Differential Revision: D26271507
fbshipit-source-id: e2277cc24f164c53f2e8a0aa72456ac400834d70
Summary:
Add LA_ASSERT macro, this just makes debugging easier on Android since these asserts are compiled out for us even in debug.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D26271508
fbshipit-source-id: 9be8c71e273d762a4f31ff1fcc629ce48218b98d
Summary:
These asserts don't run in prod; only set starting/final view props if the result props object is non-null.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D26271512
fbshipit-source-id: b495c014a062cf255fd4b5cb8609582f23edcec8
Summary:
In this case where there's an ongoing UPDATE animation and an INSERT of the same node, make sure the ongoing animation type is what we expect, and that the `newChildShadowView` is valid.
We were already guarding against these, but we should (1) crash more in debug and (2) fail more elegantly in prod when the asserts don't run.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D26271514
fbshipit-source-id: 48e7d37a2493241f16099d9fe5ecb0d247707ca7
Summary:
Changelog: [internal]
To avoid typecasting, let's return `UIViewContentMode`. This way we get rid of a condition to check if contentMode is repeat.
Reviewed By: JoshuaGross
Differential Revision: D26252431
fbshipit-source-id: 94ef7af1a76f13c91b696d57ceecc2453bbc9d8d
Summary:
We still have usages of "fbsource//tools/build_defs/apple:flag_defs.bzl" in react-native-github. But this should get us closer towards not using the fbsource cell. Hopefully, this is enough to unbreak the test_docker CircleCI build.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D26289304
fbshipit-source-id: 1c6464bb84df4f82f8a797321a73a1ed324e319a
Summary:
Instead of changing Yoga styles for a root node, now we pass available height and width to YGNodeCalculateLayout directly.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC, mdvacca
Differential Revision: D26292378
fbshipit-source-id: f99127e1cbddc1d57e4ee116afc141cbff5054ab
Summary:
LayoutAnimations: assert that tag >0 instead of != 0. It's possible that a corrupt tag value would be below zero which is not valid.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26271515
fbshipit-source-id: a62445ad29d60e5180e62ec4c6d5b08784655808
Summary:
We should always be able to reference a ComponentDescriptor. If there are any valid cases where the ComponentDescriptor doesn't exist (?) we need to document those and investigate more.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26271511
fbshipit-source-id: 659d160f82f1e78025d3dbe16efa0fa2d072d15f
Summary:
Make sure there's no corruption happening to these ShadowViews.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D26271509
fbshipit-source-id: 01bfa1bfce56e72b48304fe15b6f6426d3b5247e
Summary:
Currently, there is a bug with the way that fabric translates float values for color components to hex/int value (which android uses). There are two main problems with the current setup. The first is that we are using 256 as our ratio instead of 255 which is the maximum value for any color component in hex. The second is that we cast the components to ints instead of rounding which truncates the values. We uncovered this with UIQR because our off-by-one color values were incorrectly off a little bit extra for fabric surfaces.
Changelog: [Internal] updates the float-to-int value conversion for color components to be fully accurate
Reviewed By: shergin
Differential Revision: D26161396
fbshipit-source-id: 884e27ffa01b116f9307c00298bb8d888f9f6dd7
Summary:
This is a Fabric-compliant implementation of `JSResponder` feature. To make it work e2e we also need to update FabricRenderer in React repository. But before we can do this, we need to ship the native changes.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D24630027
fbshipit-source-id: 70c30e1250b554d83862956b536714704093072f
Summary:
This diff refactor strong references on TM infra to use weak references and avoid leaking objects
changelog: [internal] internal
Reviewed By: RSNara
Differential Revision: D26229814
fbshipit-source-id: d4a327dba227378d23764433d5917eb4378a4453
Summary:
Changelog: [internal]
`UpdateState` lambda can be called multiple times because of state auto-repeater. But previously we moved state data into the lambda and then moved it into constructor shared data constructor. If auto-repeater called update state lambda again, the data would be in invalid state.
To fix this, state data has to be copied into shared data constructor.
Background executor was more likely to kick trigger state auto-repeater, that's why the crash was happening in BE experiment.
State-autorepeater was enabled at the end of December. That explains why the crash started appearing in v301 (prior to 301, this crash was not happening).
Reviewed By: JoshuaGross, shergin
Differential Revision: D26173800
fbshipit-source-id: 46d1bae226e607d04d5ba28e6c2a8ec86258593a
Summary:
Similarly to D25937710 (https://github.com/facebook/react-native/commit/3d166a0a4c08fdaae9174625d7baba247f84fdea) we are moving away from using imperative methods that dirty Yoga node.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D26069354
fbshipit-source-id: 3d4e1bd4715a204d90174c7ea29b56438778bfa3
Summary:
changelog: [internal]
Tests were not running because of `#ifdef ANDROID` directive.
Tests had leaks and were using asserts instead of `EXPECT_EQ`.
Reviewed By: JoshuaGross
Differential Revision: D26168536
fbshipit-source-id: 453fe06a965c48f54d4bad6fe6653b6f45c39ccd
Summary:
Changelog: [internal]
Fixes an inconsistency that `AttributedStringBox` can get into.
Example of inconsitency:
After `AttributedStringBox` is moved (move constructor or move assignment operator), moved from `AttributedStringBox` needs to be set into blank state. Its mode needs to be `Value`, `opaquePointer_` should be nullptr and `value_` empty AttributedString. This was not the case before as the default move constructor and operator would leave `mode_` as `OpaquePointer` but ivar representing opaquePointer would be nullptr.
Reviewed By: JoshuaGross
Differential Revision: D26168142
fbshipit-source-id: eed2a7c3a165ae5e1f269822c12042c6ccbd3388
Summary:
The diff implements a way to use `SurfaceHandler` without using `SurfaceHandler` directly for testing and transitioning purposes. If a boolean flag is enabled all calls related to surface management will be redirected to an appropriate `SurfaceHandler` via `SurfaceManager`.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D26125955
fbshipit-source-id: 8760c237d486897ea0c32867c921d445a7f24edc
Summary:
This implements `SurfaceHandler`, a new primitive for controlling the Surface life-cycle that ensures ownership, preserves state, maintains internal invariants, and simplifies surface manipulation from the application side.
For now, all this is an unused code. The coming diff will introduce an experiment that will route all surfaceId-based APIs to SurfaceHandler-based ones.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D24290777
fbshipit-source-id: f2ff2b58e6d46e971a548f9f02113a1c783c4940
Summary:
Changelog: [internal]
Name `shouldCancel` is misleading. It implies the commit is cancelled and doesn't happen.
`shouldYield` expresses the intent better, because the commit's changes do eventually reach mounting layer but the current commit is rather yielding to the next one.
Reviewed By: mdvacca
Differential Revision: D26126121
fbshipit-source-id: 18988f217cbc651f0010f6e2381682bdbaed8bd4
Summary:
Changelog: [internal]
In theory, a commit from different surface could cancel a commit for unrelated surface. Adding surfaceId to cancellation logic assures this doesn't happen.
Reviewed By: shergin
Differential Revision: D26126003
fbshipit-source-id: 15b9b73f1000a2b4ae882e0a5129fe26fbb53fd2
Summary:
Changelog: [internal]
This simplifies logic, there is no need to keep the counter as an ivar of UIManager.
Reviewed By: JoshuaGross, shergin
Differential Revision: D26125928
fbshipit-source-id: bd266586463a9f9b85d6dc189cdab19f79e3d107