Summary:
Changelog: [Internal]
Adds react_debug dependency in Android.mk where it was missing
Reviewed By: mdvacca
Differential Revision: D26617400
fbshipit-source-id: 5ac799269b106eadd881d30490ac34bd2134a9b7
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:
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:
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:
This hack was introduced to fix T63560216. See before/after, it no longer repros.
Changelog: [Internal]
Differential Revision: D26306134
fbshipit-source-id: 7e6f886d76f3c54912fbb548069c31faaac08786
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:
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:
It is the correct way to deal with the measure function.
I believe it can fix the crash we see with TextInput state update. The crash is probably caused by invalid value of `shadowNodeRawPtr` in `YogaLayoutableShadowNode::yogaNodeCloneCallbackConnector`.
It's hard to reconstruct the full chain of events but I think it's related: Yoga's dirty flag influences cloning, so the improper setting of this flag can misalign "natural" ShadowNode cloning (influenced by changes in the tree) and YGNode-initiated cloning (triggered by layout process).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25937710
fbshipit-source-id: a4e7c9dd8f5e6598fc662f4c6ee8061fd795e20d
Summary:
This implements the `MeasurableYogaNode` trait in `YogaLayoutableShadowNode`. We had this trait from the very beginning but never used it. Now, if the trait is specified, `YogaLayoutableShadowNode` will set the measure function for the node and dirty it during cloning.
Previously, we used (and still use) a dedicated method for setting up the measure function - `YogaLayoutableShadowNode::enableMeasurement()`. The problem with it is that to make it work we have to dirty the Yoga node every time we clone it. And the only proper way to do this in the `YogaLayoutableShadowNode` constructor because if we do it later ancestor nodes could not observe this and react to this. Therefore we have to have a trait for it.
The plan is to use it for TextInput first to fix a crash (see the next diff). After we confirm it works fine, we will replace all the usages of `enableMeasurement` with the new trait.
This diff also renames the other two yoga-related traits (to make them less verbose and look unified), adds more comments, and asserts.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25937711
fbshipit-source-id: fafbd5d62537ac09e02ffbfd56adab6d629d791d
Summary:
Changelog: [internal]
Making "layout" event asynchronous unbatched will bring the behaviour closer to Paper.
Paper puts "layout" event in the event queue from ShadowQueue and schedules a flush of event queue on JavaScript queue.
Before this, Fabric puts "layout" event in the event queue from JavaScript queue, waits until main run loop is about to go to sleep and then schedules a flush of event queue on JavaScript thread.
Now Fabric no longer waits for main run loop to go to sleep but induces a flush of event queue on JavaScript thread right away.
Reviewed By: JoshuaGross, shergin
Differential Revision: D25849468
fbshipit-source-id: 366e99364507f7bc1d09325c04a604bcb2043e3d
Summary:
This changes the way we throttle `onLayout` events in Fabric.
The approach we used before has several issues:
* Every event-dispatching action initiated a lambda scheduled on JavaScript thread (which is a bit inefficient).
* If an event had {0,0,0,0} frame, it might be skipped because this is the default frame value.
* An event was always delivered by the exact block scheduled at the moment of the event initiation (even though some other blocks might be called before). In case of events being initiated rapidly, it can delay actual event delivery and maybe even overwhelm the JavaScript thread.
The new implementation uses a different approach: we maintain the shared storage with recent frame value and use the very first opportunity to deliver it. Alse see comments in the code.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25676336
fbshipit-source-id: 275b08990f7c5cf1f05a8f954ebc795a14e10ec2
Summary:
In Android, only changed prop values are sent to the mounting layer via folly::dynamic maps. In the LayoutAnimation system, before this, we only sent that
map at the /end/ of the animation for any non-interpolated values (for example, image source is not interpolated so it was not updated until the end of the animation).
However, what we probably expect is that all non-interpolated values change immediately, and interpolated values smoothly transition. This diff makes that change on Android
by using the final RawProps as the /initial/ value that interpolations are stacked on.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25727483
fbshipit-source-id: e692d37b9965fedcdf429a81d60b7cb7f0c6abe1
Summary:
Generate Fabric C++ files along side TM spec files for RNTester. The combined .so then has both TM and Fabric files.
This commit also removed the checked-in JNI files.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25674313
fbshipit-source-id: 8091d5a00f42849a74cab50e8d24f4010d500e5b
Summary:
This should make `testID` prop work as it works in pre-Fabric renderer on iOS.
On Android it should already work fine.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D25524890
fbshipit-source-id: 3f25eb427d4449abaab790099546be18ae573f98
Summary:
Changelog: [internal]
Cloning of `LegacyViewManagerInteropViewProps` causes loss of `sourceProps.otherProps` if the cloning happens before shadow node is mounted. This was happening in WebView and callback `onLoadEnd` was dropped because of this.
Reviewed By: JoshuaGross
Differential Revision: D25474581
fbshipit-source-id: 74d7c5cd32b7318bb99306c82bc8b5e5eab63db2
Summary:
Changelog: [internal]
Touch events should be of a type PressEvent. Fabric only provided touches, changedTouches and targetTouches and leaves out force, identifier, locationX, locationY, pageX, pageY and timestamp.
Reviewed By: shergin
Differential Revision: D25243347
fbshipit-source-id: e824558bd43f51c0c6dcca62bfc98318aa61678e
Summary:
Changelog: [internal]
This is already defined in Touch.h
Reviewed By: shergin
Differential Revision: D25242843
fbshipit-source-id: 23bac2a60f3d995e34d342c3a189760875f4bc77
Summary:
Changelog: [Internal]
General improvements. Behaviour should be exactly the same.
Reviewed By: JoshuaGross
Differential Revision: D25092505
fbshipit-source-id: 584640ece3e02d468f6bcb84577d7a6c899cc253
Summary:
Like the task mentions `strongSelf->_eventInterceptors` was crashing, probably because the coordinator was cleaned up before this block ran.
Check to make sure self is still valid before attempting to access any instance variables.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D25073812
fbshipit-source-id: cdf666f2ac028b5523097f15ff51fbae9f9ffbd8
Summary:
This change introducing using `updateStateWithAutorepeat` for state updates in RCTSafeAreaViewComponentView. This way we can reduce the number of active commits and reduce jumps & relayout passes.
The approach with a callback is better than using `_lastPaddingStateWasUpdatedWith` because:
* When we compare the values, we can compare them with actual previous padding numbers stored in Shadow Tree.
* The value stored in a UIView instance can go away because of a view being remounted because of flattening.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D24719345
fbshipit-source-id: 9bf1ae284875b4c99cf23be2fcc9a829eb8a895e
Summary:
This implements a new ShadowNode trait that helps to propagate Yoga node `isDirty` flag down the root of the tree and clone siblings appropriately.
Several Fabric components mutate its Yoga styles after the node was cloned. In such cases, we need to mark the node as dirty after doing so. The problem with this is that the parent node and its siblings were already updated (cloned or not) based on the previous value of the `isDirty` flag. This happens because this logic is implemented in YogaLayoutableShadowNode which is a base constructor that must be called before any other logic from a subclass can run.
For now, this change enables that for SafeAreaView only (which seems to help with some junkiness issues), later we can extend the usage of this for other components if needed.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D24719347
fbshipit-source-id: b0d050afea5de9c470e05e1b4c9e7052e00ae949
Summary:
The callback `dispatchEvent` is called asynchronously on the JavaScript thread, so all data it uses must be copied to the lambda. To work around this constraint we use a shared pointer for the counter.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D24598840
fbshipit-source-id: fb5581858d54dc806863caf0c7c4f612ed6046e2
Summary:
#changelog: [internal]
When I built ThreadStorage I didn't know about existence of `thread_local` keyword. Because it achieves the same goal, using built in c++ features is preferred over building our own.
Reviewed By: JoshuaGross, shergin
Differential Revision: D24380680
fbshipit-source-id: e961fc34c6d3f085fc9b918b20bb4827de0d5624
Summary:
This diff ended up being a bit more complicated than I anticipated, since the source files in `ReactInternal` were depending on `RCTEventDispatcher`. I made the following changes:
1. Make `RCTEventDispatcher` a `protocol`, keep it in `ReactInternal`.
2. Rename the `RCTEventDispatcher` NativeModule to `RCTEventDispatcherModule`, make it conform to the `RCTEventEmitter` `protocol`, and move it to `CoreModules`.
3. Where necessary, replace categories of `RCTEventDispatcher` with functions.
Changelog:
[iOS][Added] - Make RCTEventDispatcher TurboModule-comaptible
Reviewed By: fkgozali
Differential Revision: D18439488
fbshipit-source-id: b3da15c29459fddf884519f33b0c3b8c036b5539
Summary:
There are a few places where we have JNI table ref leaks, and more places where we can aggressively clean up smart pointers immediately instead of waiting for them to be cleaned up at some later point.
In theory these smart pointers should be cleaned up immediately, but in cases where many components are being measured at once, the JNI table could grow until all measure calls are done. In extreme cases this
could cause a crash, which I want to avoid. At the very least, freeing memory more aggressively in this case can't hurt.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D24293775
fbshipit-source-id: 159741ba955e5a6fe02caf6e65d1e4d6d4afadee
Summary:
This adds support for `<Picker style={}/>` prop for text styling. It reuses most of conversion logic from BaseText. This means that it actually supports more styles than Paper Picker supported. (Paper picker only supported ~4 styles, this supports everything that Text supports, so 10+ styles).
The only tricky thing is that Picker supports multiple ways of setting text color. Both
<Picker
itemStyle={{color: '#008BD0'}} >
<Picker.Item label="Java" value="java" />
<Picker.Item label="JavaScript" value="js" />
</Picker>
and
<Picker>
<Picker.Item label="Java" value="java" color={'#008BD0'} />
<Picker.Item label="JavaScript" value="js" />
</Picker>
technically work in Paper. I've decided to maintain this behaviour (since there's lots of product code callsites to both options).
Changelog: [iOS][Fabric] Fabric Picker support
Reviewed By: sammy-SC
Differential Revision: D23980319
fbshipit-source-id: e469a837e28af0ad97cf0e171df26ee19adff3ab
Summary:
This builds on previous diff to properly parse `<Picker.Item/>` into a cpp struct.
This fixes the dummy text and text color TODOs.
Changelog: [iOS][Fabric] Fabric Picker support
Reviewed By: sammy-SC
Differential Revision: D23964557
fbshipit-source-id: f42c6c9cf410bfc5e66ff078645b6378548481de
Summary:
This is a starting point for the handwritten Fabric Picker component. It is incomplete, and needs to be landed with the rest of the stack above it.
In general, this creates a new `ComponentView`, `ComponentDescriptor`, `ShadowNode`, `Props` and a few other boilerplate classes for Picker. A bunch of the logic in `ComponentView` was copied over from the Paper `RCTPicker` and `RCTPickerManager`.
What works in this diff:
- A `<Picker>` with items can be created in JS, and a corresponding `UIPicker` is created in native with placeholder text, default styling and the correct amount of items
What doesn't work yet (implemented in later diffs):
- Parsing items to use correct text and styling in native
- Events/commands
Reviewed By: sammy-SC
Differential Revision: D23941821
fbshipit-source-id: e049ca6004757fbd1361985644d5dbb8f53e1ce6
Summary:
Remove the older implementation of image instrumentation in Fabric by removing, RCTImageInstrumentationProxy, ImageInstrumentation from ImageRequest, and trackURLImageContentDidSetForRequest from RCTImageLoaderWithAttributionProtocol.
Changelog: [RN][Fabric][Image] Remove unused Fabric image instrumentation
Reviewed By: fkgozali
Differential Revision: D23990606
fbshipit-source-id: 004d04025d031af11377a73e5bfb64b1e0449962
Summary:
Changelog: [internal]
In D23648430 (https://github.com/facebook/react-native/commit/a315e4cd30e4b8da841f587650146a62c868f67d) I made a mistake. I prevented calling `onTextLayout` unless there are attachments in the component. It fixed the problem because I unintentionally prevented `onTextLayout` to be called. Therefore, changes from D23648430 (https://github.com/facebook/react-native/commit/a315e4cd30e4b8da841f587650146a62c868f67d) need to be reverted.
To prevent infinite loop in `onTextLayout`, ParagraphEventEmitter checks if `linesMeasurements` have changed before dispatching it to JS.
Reviewed By: shergin
Differential Revision: D23782717
fbshipit-source-id: 0e84ae4f46d79ce0cf4c7340cd32be6f562ae179
Summary:
Under Fabric only, we can enter an infinite layout loop where the emitted layout event oscillates between two height values that are off by a very small amount.
The cause is, in part, components that use layoutEvents to determine their dimensions: for example, using onLayout event "height" parameters to determine the height of a child. If the onLayout height changes rapidly, the child's height will change, causing another layout, ad infinitum.
This might seem like an extreme case but there are product use-cases where this is done in non-Fabric and layout stabilizes quickly. In Fabric, currently it may never stabilize.
Part of this is due to a longstanding issue that exists in Fabric and non-Fabric, that we cannot immediately fix: If in a single frame, C++ emits 100 layout events to ReactJS, ReactJS may only process 50 before committing the root. That will trigger more layout events, even though product code has only partially processed the layout events. At the next frame, the next 50 events will be processed which may again change the layout, emitting more events... etc. In most cases the tree will converge and layout values will stabilize, but in extreme cases in Fabric, it might not.
Part of this is because Fabric does not drop *stale* layout events. If 10 layout events are dispatched to the same node, it will process all 10 events in older. Non-Fabric does not have this behavior, so we're changing Fabric to drop stale events when they queue up.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23719494
fbshipit-source-id: e44a3b3e40585b59680299db3a4efdc63cdf0de8
Summary:
This fixes TextInput measurement caching. Previously we were not setting the correct Spannable in the cache; we needed to additional Spans to it to indicate font size and other attributes.
This brings Fabric closer to how non-Fabric was measuring Spannables for TextInputs (see ReactTextInputShadowNode.java).
This should fix a few crashes and will be most noticeable with dynamically-sized multiline textinputs where the number of lines changes over time.
This also allows us to transmit less data from C++ to Java in the majority of cases.
Changelog: [Internal]
Differential Revision: D23670779
fbshipit-source-id: cf9b8c848b9e0c2619e01766b72b074248466825
Summary:
Changelog: [Internal]
There was a key mismatch between what Java and C++.
cacheIdMap was incorrectly initialised.
Differential Revision: D23652342
fbshipit-source-id: 66f54dc887a011afeead9420bda093e9a0c9a8ca
Summary:
* Create `ImageTelemetry` as a property of ImageRequest to pass image metadata from the ImageShadowNode into RCTImageComponentView
* ImageRequest is a object in the ImageShadowNode::ConcreteState
Reviewed By: fkgozali
Differential Revision: D23239664
fbshipit-source-id: db0f08bb889af8ce63fbe1abe88744edddb86150
Summary:
Changelog: [internal]
# Problem
onTextLayout was called even if there was no change to text layout. This can cause an infinite loop with onTextLayout triggering commit which triggers onTextLayout.
# Fix
Do not call onTextLayout if there is nothing to layout.
Reviewed By: yungsters
Differential Revision: D23648430
fbshipit-source-id: 055dc34a9aca0edf2c78a5812b35b80df32c9e3e
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 we 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: D23559447
fbshipit-source-id: 20ea10c9349de2c5b1adea5735324a8f57150695
Andrei Shikov
Samuel Susla
Valentin Shergin
Joshua Gross
Igor Klemenski
David Vacca
Ramanpreet Nara
Andres Suarez
Kevin Gozali
Peter Argany
Lulu Wu
Paige Sun
