Summary:
This is to prepare for enabling TurboModule on Android. This commit compiles in all the core files (C++) into the ReactAndroid NDK build step. This doesn't yet enable TurboModule by default, just compiling in the infra, just like for iOS.
New shared libs:
* libreact_nativemodule_core.so: The TurboModule Android core
* libreact_nativemodule_manager.so: The TurboModule manager/delegate
To be compatible with `<ReactCommon/` .h include prefix, the files had to move to local `ReactCommon` subdirs.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23805717
fbshipit-source-id: b41c392a592dd095ae003f7b2a689f4add2c37a9
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:
In a previous recent diff we changed Android's Delete mount instruction to *not* recursively delete the tree. This is fine, but because of that, we stopped calling `onDropViewInstance` when views are normally deleted.
Bring back that behaviour.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23801666
fbshipit-source-id: 54e6b52ab51fff2a45102e37077fe41081499888
Summary:
This diff moves the code of TurboModule Core from ReactCommon/turbomodule to ReactCommon/react/nativemodule
For iOS: Pod spec name stays as "ReactCommon/turbomodule/..." for now, only the source/header location is affected. The target will be renamed/restructured closer to TurboModule rollout.
changelog: [internal] Internal
Reviewed By: RSNara
Differential Revision: D23362253
fbshipit-source-id: c2c8207578e50821c7573255d4319b9051b58a37
Summary:
Exceptions in C++ work quite differently from exceptions in other languages. To make exceptions actually work **correctly** all the code needs to be written with "exceptions in mind" (e.g., see https://www.stroustrup.com/except.pdf). In short, if the code is not "exceptions ready", throwing an exception causes memory leaks, dangling pointers, and invariant violations all over the place, which will probably cause another crashes down the road (which will be especially hard to investigate and attribute to the original issue).
Fabric Core (Layout, Props parsing, ShadowNodes management, and so on) does not use exceptions because in most (all?) the cases the exception is now recoverable. So, if a program detects some internal state invariant violation or missing some resource, *logically* it's fatal. We also don't want to pay code-size and performance tax for exception support, so that's why we don't use them. It's just not the right fit for Fabric Core.
This does not mean that exceptions don't happen though. C++ standard library can throw them... sometimes. And if our library is compiled with exceptions enabled (still the case, unfortunately), an exception can bubble to JavaScript code and losing all context down the road. And it's hard to investigate such crashes. To isolate those occasional exceptions inside C++ core we are marking all C++/JS boundaries with `noexcept` that stops the bubbling.
I hope that will give us much more informative crash reports.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D23787492
fbshipit-source-id: 0822dbf36fc680c15b02b5cd0f2d87328296b642
Summary:
See additional assertion. Tests still pass, so no other change was necessary.
Changelog: [Internal]
Differential Revision: D23775553
fbshipit-source-id: 57d3191f25dd55ab4da189207f6d201a31b175e0
Summary:
Because BatchMountItem executes many items, sometimes it's unclear which MountItem causes a crash. Catch and log the exact item.
This shouldn't cause perf regressions because we have a try/catch block in FabricUIManager where execute is called.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23775500
fbshipit-source-id: c878e085c23d3d3a7ef02a34e5aca57759376aa6
Summary:
There are cases where we Delete+Create a node in the same frame. Practically, the new differ should prevent this, but we don't want to rely on that necessarily.
See comments for further justification on why deleteView can do less work overall.
In reparenting cases, this causes crashes because dropView removes *and deletes* children that shouldn't necessarily be deleted.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23775453
fbshipit-source-id: c577c5af8c27cfb185d527f0afd8aeb08ee3a5fe
Summary:
The current Flipper version included in new React Native is quite old, causing some bugs to be present which have long been solved, such as freezing the UI after inspecting it.
Fixes
This fixes https://github.com/facebook/react-native/issues/29492 /
https://github.com/facebook/flipper/issues/1399
## 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
-->
[general][changed] - Update Flipper to 0.54
Pull Request resolved: https://github.com/facebook/react-native/pull/29787
Test Plan:
Updated the RN 0.63.2 based test project https://github.com/mweststrate/flipper-issue-1399-repo with `use_flipper!('Flipper' => '0.54.0')` (in `ios/Podspec`) / `FLIPPER_VERSION=0.52.1` in `gradle.properties` in the test project https://github.com/mweststrate/flipper-issue-1399-repo and verified that everything builds and connects correctly, and that the bug is no longer present.
Tried to run RN-tester project in this repo. For iOS this succeeded, on Android I got a build error:
```
make: Leaving directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni'
make: Entering directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni'
fcntl(): Bad file descriptor
[armeabi-v7a] Compile++ thumb: folly_json <= FileUtil.cpp
/Users/mweststrate/Desktop/react-native/ReactAndroid/build/third-party-ndk/folly/folly/FileUtil.cpp:37:14: error: no matching function for call to 'wrapNoInt'
make: Leaving directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni'
return int(wrapNoInt(open, name, flags, mode));
^~~~~~~~~
/Users/mweststrate/Desktop/react-native/ReactAndroid/build/third-party-ndk/folly/folly/detail/FileUtilDetail.h:34:9: note: candidate template ignored: couldn't infer template argument 'F'
ssize_t wrapNoInt(F f, Args... args) {
^
1 error generated.
make: *** [/opt/android_sdk/ndk/21.3.6528147/build/core/build-binary.mk:478: /Users/mweststrate/Desktop/react-native/ReactAndroid/build/tmp/buildReactNdkLib/local/armeabi-v7a/objs/folly_json/folly/FileUtil.o] Error 1
make: *** Waiting for unfinished jobs....
fcntl(): Bad file descriptor
make: Entering directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni'
[armeabi-v7a] Compile++ thumb: folly_json <= Demangle.cpp
```
No idea if it is related. I guess not since without making the change I got the same error.
Reviewed By: mweststrate
Differential Revision: D23767388
Pulled By: fkgozali
fbshipit-source-id: 35f0d3ddec41942f5bbc96cb391975d84729ef5e
Summary:
Continuing the adding of a "cause" field for logging to GCs.
This allows embedders of Hermes (such as React Native) to specify
the cause of a call to `collectGarbage`.
Notably, this allows Hermes to know when a GC is triggered by a memory warning.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23742099
fbshipit-source-id: 99453e632328c00045b92a72f789d41c898dc518
Summary:
The `description` parameter is never used so we can simplify the API.
Changelog:
[Internal][Changed] Removed `description` option from performance logger timespans
Reviewed By: lunaleaps
Differential Revision: D23758829
fbshipit-source-id: 10900f86effc3e1f54a408cf8f9fbc9b3b52f569
Summary:
The way the performance logger is defined now is very unsafe regarding type safety, as all accesses to its properties is untyped (`any`) and it uses several `mixed` types in cases that could be more refined.
This migrates the creation of performance loggers to instances of a class to improve its type safety. If there's an impact in performance, it's expected to be positive.
Changelog:
[Internal][Changed] - Replaced object literals with class instances to create performance loggers
Reviewed By: lunaleaps
Differential Revision: D23758609
fbshipit-source-id: 0734742eb97d92a4a53f7b66a8ca45a2ae90946c
Summary:
Inside JavaTurboModule, the native `CallInvoker` is used to schedule work on the NativeModules thread. So, in ~JavaTurboModule(), I scheduled some work on the NativeModules thread. This work holds a copy of the JNI global reference to the Java NativeModule object, and when it's executed, it resets this global reference to the Java NativeModule object. This should ensure that the we don't access the JVM in ~JavaTurboModule, which could crash the program.
I also removed the redundant `quitSynchronous()` in `~CatalystInstanceImpl()`, to prevent the NativeModules thread from being deleted before we delete the `jsi::Runtime`. This shouldn't cause an issue, because we delete the NativeModules thread when we call [ReactQueueConfigurationImpl.destroy()](https://fburl.com/codesearch/p7aurwn3).
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D23744777
fbshipit-source-id: a5c8d3f2ac4287dfef9a4b4404a04b335aa0963d
Summary:
This enables a new state auto repeating mechanism built-in mechanism for all state updates which we already use for CK interop. This experiment is supposed to help with T74769670 and co.
This change is gated with MC.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23762508
fbshipit-source-id: f535513c724ace9ede570177281324eb507329c5
Summary:
Use the latest published release of hermes-engine.
Changelog: [Android] [Changed] - Upgraded to Hermes 0.7.0
allow-large-files
Reviewed By: cpojer
Differential Revision: D23725129
fbshipit-source-id: 50938433147100e97699b717d77a687fbbfe892b
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:
LayoutAnimations: at the end of every animation, issue an update mutation - this is so that the props data on the Mounting layer/StubViewTree layer is pointer-identical to the props data on the ShadowTree.
This unblocks iOS debug mode crashes.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23753606
fbshipit-source-id: 407e0c2746a65e6d3ee29c1cce891cd7c1013593
Summary:
iOS needs this function to be marked as static.
Changelog: [internal]
Reviewed By: shergin
Differential Revision: D23749613
fbshipit-source-id: a8c160646853450fc7d849448bdbb45e02beb964
Summary:
Currently, MountingCoordinator's RN_SHADOW_TREE_INTROSPECTION code will crash often because it assumes there is always a "new" tree to compare the old tree to. In the LayoutAnimations context this is not always the case - in fact, the majority of the time, LayoutAnimations is producing mutations for animation without a "new" tree.
Just check that the tree exists before trying to print it.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23747289
fbshipit-source-id: a1ba22aeae32ed8915a53bc33cdc199e8ce5128a
Summary:
In MountingCoordinator override mode (used in LayoutAnimations) we must set the start and end `diff` time when no real diff happens, otherwise we will hit an assert in telemetry later.
I also ensure that the TransactionNumber is incremented in that case.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23746684
fbshipit-source-id: b1fe3864e453fdba89d43cc827bd37434abf7a4d
Summary:
`adjustDelayedMutationIndicesForMutation` asserts that the mutation is either Remove or Insert. At one callsite, we weren't checking the mutation type before calling `adjustDelayedMutationIndicesForMutation`.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23746617
fbshipit-source-id: 6046fec2eb4821094937b1b16f40347bbc55c20e
Summary:
This change maps the three most used colors (black, white, clear) to corresponding predefined values in UIColor. This should meaningfully reduce the overall amount of allocated UIColor/CGColor objects. In my non-scientific measures, it reduces the number of CGColor objects from ~1500 to ~1000. And... it no much at least in terms of kilobytes. However, I still think it's a good idea to implement this because I hope that can remove some work from memory allocation infra and maybe enable some optimizations that UIKit hopefully does for black and white colors. (I tend to believe that this optimization exists because UIKit even has a classes called UIDeviceWhiteColor and UICachedDeviceWhiteColor.)
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23753506
fbshipit-source-id: 46e58dc7e6b0dcab3c83d29c7257c90ffbd95246
Summary:
Finally, this diff changes the internal implementation of SharedColor to be `optional<int>`.
Initially, when we started working on the new renderer, it seemed like a good idea to allocated CGColor objects ahead of time and store them with Props. Now, this idea does not look so good, especially because:
* Having `SharedColor` as a `shared_ptr` is a quite big perf overhead for copying this thing. And the size of the object is not small.
* Having `SharedColor` as a `shared_ptr` creates huge interconnectedness among pieces of the core and rendering. E.g. improper releasing a pointer in some component view can cause a crash somewhere in the core (because both places might use the same shared `blackColor`.
On Android, we already use simple `int` as a representation of a color, and this works great. And this diff implements something very similar to Android, but a bit differently: here we use `optional<int>` instead of custom class with a single `int` field and some magic value that represents "empty value".
This approach should fix T75836417 because now we don't have allocation and deallocation when we simply assign color values.
If this solution works fine on iOS, I will do unify all implementations among all platforms.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23753507
fbshipit-source-id: 42fd6cee6bf7b39c92c88536da06ba9e8cf4d4db
Summary:
This diff changes the implementation of `RCTCreateCGColorRefFromSharedColor` and `RCTUIColorFromSharedColor` in such a way that they don't rely on the fact that SharedColor is actually a `shared_ptr<CGColorRef>`. Instead, the methods just extract color components from SharedColor and create UIColor and CGColorRef objects on demand.
This allows us to change the implementation of SharedColor without worrying much about the rest of the system, which will do in the next diff.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23753510
fbshipit-source-id: 340127527888776ebd5d241ed60c7e5220564013
Summary:
Even though we have wonderful helper functions converting SharedColor to UIColor and CGColorRef, in many places we still use some hardcoded things. This diff fixes that; it will be important for the next diff.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23753508
fbshipit-source-id: 09d280b132266252753526c2735ab3e41b96c8d5
Summary:
This diff removes `RCTCGColorRefUnretainedFromSharedColor` function because it's not compatible with future changes we plan to make.
Converting SharedColor to unretained CGColorRef is actually quite dangerous because... it's an unowned pointer.
Reviewed By: JoshuaGross
Differential Revision: D23753509
fbshipit-source-id: df030ade69b63cbb872d6bdbde51575eedc6a4a6
Summary:
Added an explicit NDK version to the Android template. This allows tooling to detect which NDK version to install automatically.
## 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] [Added] - Add an explicit NDK version to Android template
Pull Request resolved: https://github.com/facebook/react-native/pull/29403
Test Plan: Template builds as it should. NDK version gets installed with initial Android set up.
Reviewed By: passy
Differential Revision: D23752007
Pulled By: fkgozali
fbshipit-source-id: 31c33f275f94a4a62338a61e79b31c4b996969bf
Summary:
We don't need a shared_ptr here and without it the code will be faster and simpler.
This change is aligned with any clone-line callbacks we have in the Core which accepts a `const &` and return `shared_ptr<>`.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross, sammy-SC
Differential Revision: D23725687
fbshipit-source-id: 1cd959f4273913175d342302e2f12752f0114768
Summary:
Previously, to get a current root shadow node for a shadow tree, we called `tryCommit` method and stole a pointer from this. That was not a very straightforward method to get things done, and most importantly we need to do this to change the shape of the ShadowTreeCommitTransaction signature (remove a shared pointer from the callback) to make it simpler, faster and allow future improvements (see the next diff).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross, sammy-SC
Differential Revision: D23725689
fbshipit-source-id: 51950b843a0e401828b6c6a38e5e2aaaf21ec166
Summary:
Instead of storing tree separate instance variables, we now store a single object that contains them. We will need it to be able to postpone the mounting stage (we save all info we need for mounting inside the new instance variable).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D23725690
fbshipit-source-id: 09dd4a0912c6f5b34d805636b62f73ca12287329
Summary:
The implementation of this class is too complex for the purpose it serves. Making it simpler will make the code simpler and faster.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D23725688
fbshipit-source-id: 5e1ecddb0dd3c4c4f94786e2ba0af9b67e7426ce
Summary:
Changelog: [internal]
# Problem
Default padding for TextEdit is top: 26, bottom: 29, left: 10, right: 10 however the default values for LayoutMetrics.contentInsets is {0, 0, 0, 0}.
If you try to construct TextEdit with padding 0, Fabric will drop padding update because padding is already 0, 0, 0, 0.
# Fix
To fix this, I added a special case to `Binding::createUpdatePaddingMountItem`, if the mutation is insert, proceed with updating padding.
Reviewed By: JoshuaGross
Differential Revision: D23731498
fbshipit-source-id: 294ab053e562c05aadf6e743fb6bf12285d50307
Summary:
An experiment where we use `LayoutMetrics::overflowInset` to optimize performance of hit-testing algorithm.
In my measurements enabling this feature drastically (2x) reduced amount of calls to `hitTest:withEvent:` method.
Reviewed By: sammy-SC
Differential Revision: D23669091
fbshipit-source-id: ac6dadc90b6a2fbb45e41e0d4a113bd5ae8f1218
Summary:
Right now nested Text components are not accessible on Android. This is because we only create a native ReactTextView for the parent component; the styling and touch handling for the child component are handled using spans. In order for TalkBack to announce the link, we need to linkify the text using a ClickableSpan.
This diff adds ReactClickableSpan, which TextLayoutManager uses to linkify a span of text when its corresponding React component has `accessibilityRole="link"`. For example:
<Text>
A paragraph with some
<Text accessible={true} accessibilityRole="link" onPress={onPress} onClick={onClick}>links</Text>
surrounded by other text.
</Text>
With this diff, the child Text component will be announced by TalkBack ('links available') and exposed as an option in the context menu. Clicking on the link in the context menu fires the Text component's onClick, which we're explicitly forwarding to onPress in Text.js (for now - ideally this would probably use a separate event, but that would involve wiring it up in the renderer as well).
ReactClickableSpan also applies text color from React if it exists; this is to override the default Android link styling (teal + underline).
Changelog: [Android][Fixed] Make nested Text components accessible as links
Reviewed By: yungsters, mdvacca
Differential Revision: D23553222
fbshipit-source-id: a962b2833d73ec81047e86cfb41846513c486d87
Summary:
Since Prettier 2.0, the default for the `arrowParens` option has changed from `avoid` to `always`.
In preparation for upgrading Prettier in Xplat to 2.1, add `arrowParens: 'avoid'` explicitly to configurations that were missing it so that we do not have a change of behaviour when upgrading.
Changelog: [Internal]
Reviewed By: bolinfest
Differential Revision: D23666397
fbshipit-source-id: 665f20d1419d0d664a6ef5cddc46f441b20eeb51
Summary:
Disabling Fast Refresh won't be persisted when restarting the app.
I believe this regressed with https://github.com/facebook/react-native/commit/824e1711172d14a9373209bbae63d1ae50601625. In this commit `HMRClient.setup` will always be called with `enabled` being set true. This PR loads the _enabled_ state from the user defaults (as it was done before).
## Changelog
[iOS] [Fixed] - Enable Fast Refresh gets persisted across app launches
Pull Request resolved: https://github.com/facebook/react-native/pull/29880
Test Plan:
Without this change Fast Refresh is enabled on every app restart.
Tested with this change:
- Disabling Fast Refresh
- Restarting App -> Fast Refresh still disabled
- Enabled Fast Refresh again
- Restarting App -> Fast Refresh still enabled again
Reviewed By: sammy-SC
Differential Revision: D23686435
Pulled By: PeteTheHeat
fbshipit-source-id: 42c31b22060d3dc4b1d4cb8f41792b303fc7fce8
Summary:
Fix a typo in the invariant message presented when ActionSheetManager does not exist (typo was found in 2 places)
## Changelog
[General] [Fixed] - Fix typo in invariant message
Pull Request resolved: https://github.com/facebook/react-native/pull/29913
Test Plan: Run ActionSheetIOS.showActionSheetWithOptions(...) on an Android emulator to get this invariant message to appear.
Reviewed By: hramos
Differential Revision: D23691048
Pulled By: appden
fbshipit-source-id: 469db65a42bf547c7818b45729befa214b5791f2
Summary:
It's more correct and we will rely on this in the future.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23681508
fbshipit-source-id: 5fef0ea164e8a400e6ca9a67947252b47ce6d44e
Summary:
This diff allows specifying the preemptive compilation threshold via CompileFlags.
Users get a toggle in CLI and RuntimeConfig that allows choosing between 1. fully eager, 2. fully lazy, 3. use default thresholds ("smart"). The default is #3.
However, since we use `-O` by default, it overrides any lazy compilation when
using the `hermes` binary.
ChangeLog: [Internal] Inspector updated to use new RuntimeConfig laziness control
Reviewed By: tmikov
Differential Revision: D23356463
fbshipit-source-id: 508b7b2e6a218346c69acfec97e7891e388f0e9b
Kevin Gozali
Samuel Susla
Joshua Gross
Valentin Shergin
Michel Weststrate
Riley Dulin
Rubén Norte
Ramanpreet Nara
Xuan Huang
Jason Safaiyeh
Emily Janzer
George Zahariev
Ullrich Schäfer
S. Weatherall
Will Holen