Summary:
See e94b116d76 which broke RNTester in open source. Environment variables are always strings, so "0" is a truthy value. This fixes it.
[iOS] [fixed] - Fixed broken RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/24736
Reviewed By: fkgozali
Differential Revision: D15272951
Pulled By: hramos
fbshipit-source-id: aa78f229e05cb553f75cdf6fb4f926829e20a557
Summary: Apparently, Yoga has a "quirks mode" and we have to enable that for Fabric. Which is probably a mistake that we have to make one more time.
Reviewed By: davidaurelio
Differential Revision: D15267852
fbshipit-source-id: 88a910fafc9ff64fb19376f4b74a2f2fd5827eba
Summary:
See e94b116d76 which broke RNTester in open source. Environment variables are always strings, so "0" is a truthy value. This fixes it.
[iOS] [fixed] - Fixed broken RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/24736
Differential Revision: D15240810
Pulled By: hramos
fbshipit-source-id: 76f498222b6ac05131b3820d8356bfee696f46b8
Summary:
Continuation of #24687
> Issue: [Polish the "new app screen"](https://github.com/react-native-community/discussions-and-proposals/issues/122)
> This is the pull request for the new intro screen proposal in react native as directed by cpojer
This PR was created because the previous one could not be pushed to for some reason. I cleaned up a few small things and added the component as an example to RNTester so we can keep iterating. My plan is to land this, and then polish it and make it the default in a follow-up.
[General][Added] - New Intro screen, Icons
Removed Lottie Integration
100% React Native 💥
Pull Request resolved: https://github.com/facebook/react-native/pull/24737
Differential Revision: D15259092
Pulled By: cpojer
fbshipit-source-id: bc141fb1425cf354f29deffd907c37f83fd92c75
Summary:
Our Blob implementation was very problematic because it didn't release its underlying resource when the JS instance was dealocated. The main issue is that the fetch polyfill uses blobs by default if the module is available, which causes large memory leaks.
This fixes it by using the new jsi infra to attach a `jsi::HostObject` (`BlobCollector`) to `Blob` instances. This way when the `Blob` is collected, the `BlobCollector` also gets collected. Using the `jsi::HostObject` dtor we can schedule the cleanup of native resources. This is definitely not the ideal solution but otherwise it would require rewriting the whole module using TurboModules + jsi.
Fixes#23801, #20352, #21092
[General] [Fixed] - [Blob] Release underlying resources when JS instance in GC'ed
Pull Request resolved: https://github.com/facebook/react-native/pull/24745
Reviewed By: fkgozali
Differential Revision: D15248848
Pulled By: hramos
fbshipit-source-id: 1da835cc935dfbf4e7bb6fbf2aea29bfdc9bd6fa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/24764
The `test_android` CI build was failing:
```
./scripts/circleci/buck_fetch.sh
+ buck fetch ReactAndroid/src/test/java/com/facebook/react/modules
Not using buckd because watchman isn't installed.
Picked up _JAVA_OPTIONS: -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap
PARSING BUCK FILES: FINISHED IN 1.1s
No build file at ReactAndroid/src/main/libraries/fbjni/BUCK when resolving target //ReactAndroid/src/main/libraries/fbjni:java.
This error happened while trying to get dependency '//ReactAndroid/src/main/libraries/fbjni:java' of target '//ReactAndroid/src/main/java/com/facebook/react/turbomodule/core:jscallinvokerholder'
Exited with code 1
```
The problem was that I was using `react_native_dep("libraries/fbjni:java")` to access JNI classes like `HybridData`. In open source this target translates to the path `//ReactAndroid/src/main/libraries/fbjni`, which doesn't exist. Instead, the actual classes are available at the path `//ReactAndroid/src/main/java/com/facebook/jni`. Therefore, I changed the target to `react_native_dep("java/com/facebook/jni:jni")`. This is exactly how the bridge (i.e: `//ReactAndroid/src/main/java/com/facebook/react/bridge:bridge`) accesses JNI clases.
Reviewed By: hramos
Differential Revision: D15261218
fbshipit-source-id: 659a5627389bbca3603db7de347618cd400d4ffc
Summary:
This is the next step in moving RN towards standard path-based requires. All the requires in `Libraries` have been rewritten to use relative requires with a few exceptions, namely, `vendor` and `Renderer/oss` since those need to be changed upstream. This commit uses relative requires instead of `react-native/...` so that if Facebook were to stop syncing out certain folders and therefore remove code from the react-native package, internal code at Facebook would not need to change.
See the umbrella issue at https://github.com/facebook/react-native/issues/24316 for more detail.
[General] [Changed] - Migrate "Libraries" from Haste to standard path-based requires
Pull Request resolved: https://github.com/facebook/react-native/pull/24749
Differential Revision: D15258017
Pulled By: cpojer
fbshipit-source-id: a1f480ea36c05c659b6f37c8f02f6f9216d5a323
Summary:
This is another step in moving RN towards standard path-based requires. All the requires in Jest's setup script have been rewritten to use relative requires. This commit uses relative requires instead of `react-native/...` so that if Facebook were to stop syncing out certain folders and therefore remove code from the react-native package, internal code at Facebook would not need to change.
[General] [Changed] - Migrate Jest setup scripts from Haste to path-based requires
Pull Request resolved: https://github.com/facebook/react-native/pull/24753
Differential Revision: D15258238
Pulled By: cpojer
fbshipit-source-id: aa05dc8ea2e4ba195226e8ec7ba6482b7de03240
Summary:
AccessibilityInfo.announceForAccessibility is currently only available on iOS. I've added the Android specific implementation, updated RNTester, and the documentation.
[Android] [Added] - Added AccessibilityInfo.announceForAccessibility for Android
[General] [Added] - RNTester example for AccessibilityInfo.announceForAccessibility
Pull Request resolved: https://github.com/facebook/react-native/pull/24746
Differential Revision: D15258054
Pulled By: cpojer
fbshipit-source-id: 3e057a5c32b28e30ea2ee74a18854b012cd2dbfd
Summary:
React Native Gesture Handler uses a `RCTViewManager` subclass to manage `UIControl` so the cast to set accessibility props is not safe. This moves the accessibility props we set to `UIView+React` so they can be used safely on any `UIView`.

[General] [Fixed] - Move accessibility props to UIView+React
Pull Request resolved: https://github.com/facebook/react-native/pull/24743
Differential Revision: D15258062
Pulled By: cpojer
fbshipit-source-id: 4a25b79407e5cb7b3b368c7506161e989794bb26
Summary:
So far we have only officially supported "iOS" and "Android" as categories, with a "General" catch all for everything else.
Let's add a "JavaScript" category for changes that only affect JavaScript, and an "Internal" category for things that do not make sense in a changelog (e.g. CI changes).
[Internal] [Added] - Added JavaScript and Internal categories to changelog regex
Pull Request resolved: https://github.com/facebook/react-native/pull/24744
Differential Revision: D15258061
Pulled By: cpojer
fbshipit-source-id: 8b6cb193adf602d3bd6639b550e04775b201fe59
Summary:
Solves #15961 - [ANDROID] Linking.getInitialURL() returns null after exiting the app with back button and using deep linking again (only in production!)
As the issue says, it seems that `currentActivity` is null in [IntentModule#getInitialURL](1e8f3b1102/ReactAndroid/src/main/java/com/facebook/react/modules/intent/IntentModule.java (L50)). So I used the `InteractionManager` to wait until current activity to finish initializing.
[Android] [Fixed] - In `Linking.getInitialURL` method, use the `InteractionManager` to wait for the current activity to finish initializing.
Pull Request resolved: https://github.com/facebook/react-native/pull/24748
Differential Revision: D15258046
Pulled By: cpojer
fbshipit-source-id: 0ec1c873766ae90955d47e5e023556eb6c5d5fbb
Summary:
Fix crash in XMLHttpRequest example because `groupTypes` is not supported on android.
[Android] [Fixed] - Fix crash in XMLHttpRequest example on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/24747
Differential Revision: D15258037
Pulled By: cpojer
fbshipit-source-id: 73086dc92ceb065200e0faafaf100fa742b387bb
Summary:
This is another step in moving RN towards standard path-based requires. All the requires in `IntegrationTests` have been rewritten to use relative requires. This commit uses requires that are relative to `react-native/...` assuming that IntegrationTests are meant to try consuming RN rather than being part of it.
See the umbrella issue at https://github.com/facebook/react-native/issues/24316 for more detail.
[General] [Changed] - Migrate IntegrationTests from Haste to path-based requires
Pull Request resolved: https://github.com/facebook/react-native/pull/24750
Differential Revision: D15258019
Pulled By: cpojer
fbshipit-source-id: 01ac01ba4699f8ba424353f74e745b4057f79b59
Summary:
See #24316 for the motivation. This commit rewrites a couple more new imports in the RNTester project so they use path-based requires.
[General] [Changed] - Migrate TurboModule example in RNTester to use path-based requires
Pull Request resolved: https://github.com/facebook/react-native/pull/24754
Differential Revision: D15258015
Pulled By: cpojer
fbshipit-source-id: adb298cb3006ea0afcd3b813a2e2fe85017764d2
Summary:
There are 2 issues:
* RCTTurboModuleManager may be initialized too late, so the module lookup from native via `[bridge moduleForClass:]` may end up going to the old system incorrectly
* In the case where JS is asking for a nativemodule, we may be incorrectly registering modules that are marked as RCTTurboModule - they should be ignored instead
Reviewed By: mmmulani, RSNara
Differential Revision: D15247632
fbshipit-source-id: 4e0fae33923810c74966b38276b206ac00723012
Summary: I don't recall why the mutation function return rvalue reference, but it is totally incorrect (the function cannot own the object, so returning a reference introducing a dungling pointer and will crash).
Reviewed By: mdvacca
Differential Revision: D15156312
fbshipit-source-id: 497d10de22a41906efe71cd10139e3710ae11a79
Summary:
In https://github.com/facebook/react-native/pull/23865, RN introduced support for custom fonts the Android Way. But it introduced performance regression because it'll lookup for a font using getIdentifier() every time fontFamily changed. This PR fixes regression by requiring custom fonts to be listed in **fonts** array, and populating **mTypeCache** at first use using the list.
[Android] [Changed] - Require custom fonts to list in **fonts** array. Fixes performance regression.
Pull Request resolved: https://github.com/facebook/react-native/pull/24595
Reviewed By: mdvacca
Differential Revision: D15184590
Pulled By: fkgozali
fbshipit-source-id: e3feb2396609583ebc95101130186a1f5af931da
Summary:
When using `scrollToLocation` together with `stickySectionHeadersEnabled` in a `SectionList`, the length of the section header is not accounted for when scrolling to any item except the header.
[General] [Fixed] - Adjust scrollToLocation when using sticky section headers
Pull Request resolved: https://github.com/facebook/react-native/pull/24735
Differential Revision: D15240953
Pulled By: cpojer
fbshipit-source-id: fd7121d990c5b01533e456bdfa39bebf6245fa80
Summary:
packagingOptions.pickFirst is unreliable that we could not specify which library will be used.
If user have other third party libraries, the story is more complicated.
From the framework point of view, it is better to drop the pickFirst.
In jsc-android 241213.1.0, we did two things:
1. Remove libc++_shared.so in AAR to prevent the conflict with RN.
2. Build by NDK r17c, which aligned with current RN NDK version.
In this commit, I also revert the pickFirst for JSC.
pickFirst JSC also makes upgrade JSC unreliable.
Currently a lot of user report JSC crash issues, those crash issues may relate to JIT and hard to reproduce in-house.
My plan is to make sure user could choose another JSC build easier,
i.e. only to `yarn add 'jsc-android@latest'`.
We could then propose some experimented JSC build for user to check
if the build could help them to fix the crash issue.
[Android] [Fixed] - Remove unreliable packagingOptions.pickFirst for libc++_shared.so and libjsc.so
NOTE that this may not need to add the changelog, as RN 0.59 does not have pickFirst.
This will also reduce a breaking change for upgrade from RN 0.59 or before.
Pull Request resolved: https://github.com/facebook/react-native/pull/24672
Differential Revision: D15164536
Pulled By: cpojer
fbshipit-source-id: 9fc897a77409173a5841f325b38e2836bb07f599
Summary: Adds disabled kebab case modal props now that we can safely generate them to cpp
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15218837
fbshipit-source-id: d712e53f53d91ae14bba9956321530907f67d2e8
Summary: This diff adds support for kebab-case enum properties by transforming them to KebabCase in cpp
Reviewed By: mdvacca
Differential Revision: D15218781
fbshipit-source-id: 0ec6d28f3ca0e5b8187fc7026e12a8d76be73a7c
Summary:
Resolve#24690
This is very simple unicode detecting. Should I improve this solution creating StringsUtils for detecting unicodes in whole react-native project ?
[Android][Fixed] onKeyPress method is calling, when user type emoji
Pull Request resolved: https://github.com/facebook/react-native/pull/24717
Differential Revision: D15238388
Pulled By: cpojer
fbshipit-source-id: 038b1040e1c44fd6f9401a3988a782f5778e1209
Summary:
`UITextField` don't have delegate to observe the selection changes of users(multiline text input `UITextView` have it), so we can add a KVO to observe selection changes.
cpojer shergin
[iOS] [Fixed] - Fixes selection of single line text input
Pull Request resolved: https://github.com/facebook/react-native/pull/24714
Differential Revision: D15238379
Pulled By: cpojer
fbshipit-source-id: f149721d6b4df28e90f5a9405c74e01fde7c7d10
Summary:
In #24095, we removed the code that changes the underlying Android view's enabled state to false when "disabled" is included in the accessibility states, which seems correct. The Android view's state shouldn't mirror the accessibility state, it should be the other way round-- the accessibility state should represent the state of the view.
It seems that the existing test is brokenly setting the disabled state in the Javascript object, and then querying the Android view's enabled state to confirm the change. If the Button implementation is actually the culprit, then IMHO, the correct fix would be to have the Button implementation manipulate the Android View's enabled state, not the accessibilityStates code.
[android] [fix] - Fix internal test case around disabled state of buttons
Pull Request resolved: https://github.com/facebook/react-native/pull/24678
Differential Revision: D15237590
Pulled By: cpojer
fbshipit-source-id: d7ebefbcba9d4d9425da4285175302e4b6435df7
Summary:
PR https://github.com/facebook/react-native/pull/24633 introduced some inconsistency in crash messaging, this PR fix it. Asked by mhorowitz
[General] [Added] - Consistent reporting native module name on crash on native side
Pull Request resolved: https://github.com/facebook/react-native/pull/24704
Differential Revision: D15237424
Pulled By: cpojer
fbshipit-source-id: ded8db45b2a2ec9998ff33fdbecef3f12c19578f
Summary:
Fixes https://github.com/facebook/react-native/issues/23712
Currently, It seems like `__nativeAnimatedValueListener` is not listening to the correct `onAnimatedValueUpdate` events if component was re-mounted. In this PR I'm attaching a new listener if the native view tag has changed.
[General] [Fixed] - Fixed Animated.Value value after animation if component was re-mounted
Pull Request resolved: https://github.com/facebook/react-native/pull/24571
Differential Revision: D15237431
Pulled By: cpojer
fbshipit-source-id: 1fe4e290ab45dfe6d1d364d8d7384aabf18d6610
Summary:
Our Blob implementation was very problematic because it didn't release its underlying resource when the JS instance was dealocated. The main issue is that the fetch polyfill uses blobs by default if the module is available, which causes large memory leaks.
This fixes it by using the new jsi infra to attach a `jsi::HostObject` (`BlobCollector`) to `Blob` instances. This way when the `Blob` is collected, the `BlobCollector` also gets collected. Using the `jsi::HostObject` dtor we can schedule the cleanup of native resources. This is definitely not the ideal solution but otherwise it would require rewriting the whole module using TurboModules + jsi.
Fixes#23801, #20352, #21092
[General] [Fixed] - [Blob] Release underlying resources when JS instance in GC'ed
Pull Request resolved: https://github.com/facebook/react-native/pull/24405
Differential Revision: D15237418
Pulled By: cpojer
fbshipit-source-id: 00a94a54b0b172fbc62324364b753d192ac7016a
Summary: Apparently it's not used anymore. And that a good this.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15219258
fbshipit-source-id: e3258d851d1eec5955d86f99a0b0d8a1b0304cb4
Summary: I have noticed that `backfaceVisibility` example crashes (because actual value is a string/enum, not a boolean), so I fixed it.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15219261
fbshipit-source-id: 27f76cd10903794d597adacb9da7300a42813f8e
Summary: After this change, all measuring operations based on `LayoutableShadowNode::getRelativeLayoutMetrics` will take into account the transformation matrices provided by shadow nodes. This will allow implementing scroll-offset-aware and custom-transform-aware measuring.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15219259
fbshipit-source-id: 1d7cd8c0ee4406f4dd0002cd442dc0679391922b
Summary: The diff implements a function that applies given transformation to a point.
Reviewed By: JoshuaGross
Differential Revision: D15219263
fbshipit-source-id: 4cc0595b0dda38c1ede1f2885b800cbe57f54243
Summary:
`LayoutableShadowNode::getTransform` returns a transform object that represents transformations that will/should
be applied on top of regular layout metrics by mounting layer.
Reviewed By: mdvacca
Differential Revision: D15219262
fbshipit-source-id: e7aeb85b5f7e2fce3f8faf9dfcaee5dae3217d36
Summary:
Add support for a `CI_USE_BUNDLE_PREFIX` envvar in the RNTester Xcode scheme, as part of ongoing work to enable integration tests in Facebook's internal CI system.
[iOS] [Added] - Add new envvar to support internal iOS tests at Facebook
Reviewed By: cpojer
Differential Revision: D15163397
fbshipit-source-id: 1b75b1868b5f9721a69f6cba4d4052be47e5e5e2
Summary:
The jest HasteImpl's `pluginNameReducers` regex was not properly escaping a backslash, resulting in unintended behavior.
The intent of the code is to strip the `.${name}` from the end of a filepath, where `name` is a platform name. The correct regex for that would be `^(.*)\.(myPlat)$`, but because the regex is being constructed from a string, the `\.` is being interpreted as an escaped period, resulting in the regex `^(.*).(myPlat)$`. To correct this, the backslash needs to be escaped so it makes it into the regex.
[General] [Fixed] - Fix HasteImpl platform name regex
Pull Request resolved: https://github.com/facebook/react-native/pull/24628
Differential Revision: D15224468
Pulled By: hramos
fbshipit-source-id: 6eb507aa5410bdd7c247e6d301052d41995a2f11
Summary: I'm not sure if this is a good idea. Right now FabricUIManager creates a ThemedReactContext in addRootView() using the RAC you pass in. If you pass in an RAC without a Catalyst instance, this will throw; this diff makes it so it'll throw the next time you try to actually try to access the CatalystInstance, instead. I don't know if we're really relying on this right now, but we need to be able to create a ThemedReactContext without a CatalystInstance for Venice (for now, until we actually go through and get rid of TRC's dependency on the CatalystInstance entirely - but that'll be a lot more work)
Reviewed By: mdvacca
Differential Revision: D15194220
fbshipit-source-id: 64689cbe79c84ae33fe16e3dc396e3c69ec8e20f
Summary: Refactoring ReactContext to move message queue initialization into its own function that can be called independently of initializeWithInstance. This allows you to create a ReactContext with message queue threads without a CatalystInstance.
Reviewed By: mdvacca
Differential Revision: D14817741
fbshipit-source-id: f314a526c6534792714e5ba55dd873f1728c6b9f