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
Summary:
We currently have "Type: Bug Report", "Type: Bug Fix", and "Impact: Bug" in our list of labels. To simplify life for maintainers, lets use a single Bug label.
This PR makes it so new Bug Reports use the "Bug" label. The bot has been updated to accept "Bug" as a valid template label already.
[General] [Changed] - New issues use the Bug label
Pull Request resolved: https://github.com/facebook/react-native/pull/24707
Differential Revision: D15220772
Pulled By: hramos
fbshipit-source-id: e25f7180839d2e6aa7211b805dfbf5368b39d738
Summary:
[General] [Fix] - Reorder operations of native view hierarchy
When we update the native view hierarchy in `manageChildren` we:
1. iterate through all views we plan to remove and remove them from the native hierarchy
2. iterate through all views we plan to add and add them to the native hierarchy
3. iterate through all views we plan to delete and delete them (remove them from memory)
This covers these cases:
a. A view is moved from one place to another -- handled by steps 1 & 2
b. A view is added -- handled by step 2
c. A view is deleted -- handled by step 1 & 3
> Note the difference between remove and delete
Everything above sounds fine! But...
The important bit:
**A view that is going to be deleted asynchronously (by a layout animation) is NOT removed in step 1. It is removed and deleted all in step 3.** See: https://fburl.com/ryxp626i
If the reader may recall we solved a similar problem in D14529038 where we introduced the `pendingIndicesToDelete` data structure to keep track of views that were marked for deletion but had not yet been deleted. An example of an order of operations that we would've solved with D14529038 is:
* we "delete" the view asynchronously (view A) in one operation
* we add a view B that shares a parent with view A in subsequent operation
* view A finally calls its callback after the animation is complete and removes itself from the native view hierarchy
A case that D14529038 would not fix:
1. we add a view B in one operation
2. we delete a view A in the same operation asynchronously because it's in a layout animation
3. ... etc.
What we must remember is that the index we use to add view B in step 1 is based on the indices assuming that all deletions are synchronous as this [comment notes](https://fburl.com/j9uillje): removals (both deletions and moveFroms) use the indices of the current order of the views and are assumed independent of each other. Whereas additions are indexed on the updated order (after deletions!)
This diff re-arranges the order in how we act upon the operations to update the native view hierarchy -- similar to how UIImplementation does its operations on the shadow tree here: https://fburl.com/j9uillje
By doing the removals and deletions first, we know that the addAt indices will be correct because either the view is removed from the native view hierarchy or `pendingIndicesToDelete` should be tracking an async delete already so the addAt index will be normalized
Reviewed By: mdvacca
Differential Revision: D15112664
fbshipit-source-id: 85d4b21211ac802183ca2f0fd28fc4437d312100
Summary:
This diff adds generated c++ tests for all generated components
There is a test for every prop based on type, and in the case of enums every allowed value
Reviewed By: shergin
Differential Revision: D15147126
fbshipit-source-id: b4f88d2dab825e41754a880081d86b3cd12274ee
Summary:
This diff forces the eager initialization of some additional classes into FabricJSIModuleProvider.loadClasses().
This is a "hack" that will be removed in the near future
Reviewed By: JoshuaGross
Differential Revision: D15208977
fbshipit-source-id: 2e2c7856839b6c6888452800ef6da7f269e46735
Summary: When passing StateWrapper objects across the JNI, we were not ensuring that the Java objects would own the C++ state. This was initially done because I assumed that in Java, State would either be used immediately or discarded, so this wouldn't be unsafe. As it turns out, it makes sense in some cases to store the StateWrapper in Java and use it later, potentially even in other threads, so we need to make sure we maintain ownership of the C++ object from the Java object.
Reviewed By: shergin
Differential Revision: D15206194
fbshipit-source-id: a437d921ba00b194cf08bad80666bd99baf11d52
Summary: This diff implements encapsulating all time metrics in a single class for better extensibility and readability.
Reviewed By: JoshuaGross
Differential Revision: D15179835
fbshipit-source-id: 62bdf94435a0d37a87ad9bad613cc8e38043a235
Summary:
Rename test_detox_end_to_end to test_end_to_end, then move JavaScript and iOS end-to-end tests to this job.
Fixes an issue in the end-to-end tests, but does not yet bring them back fully to green.
[General] [Changed] - Collect e2e tests under test_end_to_end job
Pull Request resolved: https://github.com/facebook/react-native/pull/24689
Differential Revision: D15202242
Pulled By: hramos
fbshipit-source-id: e7a9627896d2990cb6ddd0d3a91b915781ac2417
Summary: iOS TurboModules work in OSS. I pulled out JSCallInvoker from `React-turbomodule-core`, as a part of D15055511. In this diff, I'm adding it back in.
Reviewed By: mdvacca
Differential Revision: D15195007
fbshipit-source-id: 64ee294a68c0a63ba400b8a829864c6619d3311a
Summary:
`CatalystInstanceImpl.cpp` now depends on `JSCallInvoker` and `JavaJSCallInvokerHolder`. Therefore, we need to correctly adjust the OSS builds to include these dependencies into the `libreactnativejni.so` file.
I made `ReactCommon/turbomodule/jscallinvoker` a static library `libjscallinvoker.a`. I then made `ReactAndroid/src/main/jni/react/jni`'s `libreactnativejni.so` depend on that static library. Also, because the Android NDK build system doesn't support header namespaces, I had to use the filesystem to simulate them. This is why all the `.cpp` and `.h` files for `JSCallInvoker` were moved to a `jsireact` folder.
Reviewed By: mdvacca
Differential Revision: D15194821
fbshipit-source-id: 0cee682e41db53d0619f56ad017d5882f6d554aa
Summary:
`TurboModuleManagerDelegate` is an abstract base class with the following API:
```
public TurboModule getModule(String name, ReactApplicationContext reactApplicationContext);
public CxxModuleWrapper getLegacyCxxModule(String name, ReactApplicationContext reactApplicationContext);
```
```
std::shared_ptr<TurboModule> getTurboModule(std::string name, jni::global_ref<JTurboModule> turboModule, std::shared_ptr<JSCallInvoker> jsInvoker) override;
std::shared_ptr<TurboModule> getTurboModule(std::string name, std::shared_ptr<JSCallInvoker> jsInvoker) override;
```
On the C++ side, when asked to provide a TurboModule with name `name`:
1. First, is this a CxxModule? If so:
1. Create the CxxModule and return
2. Otherwise:
1. Somehow get a Java instance of the TurboModule
2. If this Java object represents a CxxModule, like `FbReactLibSodiumModule`:
1. Grab the C++ part of this object, and wrap it in a `TurboCxxModule.cpp` and return.
3. Otherwise:
1. Wrap the Java object in a C++ HostObject and return.
This pseudocode demonstrates how we'd use `TurboModuleManagerDelegate` to implement `__turboModuleProxy`.
```
__turboModuleProxy(name, jsCallInvoker):
let cxxModule = TurboModuleManagerDelegate::getTurboModule(name, jsCallInvoker)
if (!cxxModule) {
return cxxModule;
}
// JNI Call that forwards to TurboModuleManagerDelegate.getLegacyCxxModule
let javaCxxModule : CxxModuleWrapper = TurboModuleManager.getLegacyCxxModule(name)
if (!javaCxxModule) {
return std::shared_ptr<react::TurboCxxModule>(javaCxxModule.getModule())
}
// JNI Call that forwards to TurboModuleManagerDelegate.getModule
let javaModule : TurboModule = TurboModuleManager.getModule(name)
if (!javaCxxModule) {
return TurboModuleManagerDelegate::getTurboModule(name, javaModule, jsCallInvoker)
}
return null
```
Reviewed By: mdvacca
Differential Revision: D15111335
fbshipit-source-id: c7b0aeda0e4565e3a2729e7f9604775782b6f893
James Ide
Alan Kenyon
Janic Duplessis
Héctor Ramos
Injung Chung
Kevin Gozali
Valentin Shergin
Dulmandakh
Dmitry Dushkin
Adrian Zgorzalek
Danilo Bürger
Kudo Chien
Rick Hanlon
Piotr Trocki
zhongwuzw
Marc Mulcahy
Florian
Zeyad Salloum
michalchudziak
Eileen Zhang
Héctor Ramos
Nicolas Breidinger
Emily Janzer
Luna Wei
David Vacca
Joshua Gross
Ramanpreet Nara
