Summary: This diff fixes the height of the Slider component in Fabric on Android. Note that the layout is still broken (no padding and the seek bar is misaligned, but it's another issue).
Reviewed By: JoshuaGross
Differential Revision: D17629798
fbshipit-source-id: af8cae909279dc92ee1c80b9be2f5c578972eafc
Summary: This diff implements the core functionality of "reactive component registration". With a new API now we have a public API that allows registering a component by request on-demand. That can be helpful in some environments where loading of all components is undesirable or impossible due to generic app design constrains.
Reviewed By: mdvacca
Differential Revision: D17211914
fbshipit-source-id: 5a957a4f6541420d70952856599b827ceec63e3b
Summary:
Currently, the same ComponentDescriptor class cannot be registered as a responder for components with different names. However, we have marginal cases where we really need it. The examples are `UnimplementedView` or possible universal interop with the classic RN or any other UI framework.
This change adds a special optional argument to ComponentDescript constructor that allows implementing this functionality.
Reviewed By: fkgozali
Differential Revision: D17211915
fbshipit-source-id: 18f59e09fe06b875a8e8975b7b2ab423489238bb
Summary:
This part of the codebase is very perf sensitive and designed to work without exceptions enabled.
Most of the method was `noexcept` all the time, but some of those missing that by mistake.
Reviewed By: sammy-SC
Differential Revision: D17629426
fbshipit-source-id: b311e4b7eff8e2b7cf29518288480d3a812dda44
Summary:
When sliders are adjusted via accessibility, no onSlidingComplete callback is
generated. This causes problems for components which perform behavior in this
callback, and means that such components don't behave properly when adjusted via
accessibility. For example, if an app hosting a volume control slider only commits the volume change to the hardware on onSlidingComplete, it is impossible for a screen reader user to ever actually adjust the volume.
Ensure that sliders call the onSlidingComplete callback after adjusted via
accessibility.
## Changelog
[General] [Fix] - Add onSlidingComplete callbacks when sliders adjusted via a11y.
[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/26600
Test Plan: Prior to this change, using the RNTester slider example with a screen reader, the onSlidingComplete callback tests never shows any callbacks when the slider is adjusted. With this change applied, the callback test will show a number of callbacks corresponding to the number of times the slider was adjusted via the screen reader.
Differential Revision: D17661157
Pulled By: cpojer
fbshipit-source-id: a6eedef099c6c1b571b290c329059ac9b69b53dd
Summary:
## Motivation
I have seen a spike in users reporting this error. Unfortunately I did not receive any repros that would confirm this, but my hypothesis is that they ran into situation when `new XYZPackage()` was present in `getPackages()` method and then the CLI kicked in with autolinking and they were left with this incomplete error.
someone more knowledgeable of autolinking should review this.
Pull Request resolved: https://github.com/facebook/react-native/pull/26467
Differential Revision: D17661242
Pulled By: cpojer
fbshipit-source-id: 63dfcd85a0d41d85a0dd52f84ab16cb7ceb64ba2
Summary:
`ReactRootView.startReactApplication` takes a `Bundle` argument called `initialProperties`. This is translated to a `ReadableMap` via `Arguments.fromBundle`. If the bundle contains an array of bundles, this gets translated by `Arguments.fromArray`.
If the bundle was passed from one activity to another via intent extras, however, there is a problem. After the bundle has been marshaled and unmarshaled, the array of `Bundle`s come out the other end as an arrap of `Parcelable`s, although each array element remains a `Bundle`. This results in an "Unknown array type" exception.
This PR fixes this by adding support for `Parcelable` arrays – provided they contain only members of type `Bundle`.
## Changelog
[Android] [Fixed] - Don't throw "Unknown array type" exception when passing serialized bundle arrays in ReactRootView.startReactApplication's initialProperties parameter
Pull Request resolved: https://github.com/facebook/react-native/pull/26379
Test Plan: Added test class `ArgumentsTest`. The test method `testFromMarshaledBundle` fails when used on the old version of `Arguments`.
Differential Revision: D17661203
Pulled By: cpojer
fbshipit-source-id: 63612d78f49bdf9cc53f6f21ae883dba6cebce84
Summary: Make it possible for a Runtime implementation to provide its own JSON parsing, by making the method on Value call through Runtime, which now has the default implementation.
Reviewed By: tmikov
Differential Revision: D17637395
fbshipit-source-id: b8997f7d1721a7790326417f3abfa86c875923c9
Summary:
Without `transform` in `OUTER_PROPS`, the refresh control component would not include `transform: {scaleY: -1}` in its style and so pulling down, rather than up, on a scroll view would trigger a refresh.
Fixes https://github.com/facebook/react-native/issues/26181
## Changelog
[Android] [Fixed] - Fixed issue with refresh control not working properly on an inverted ScrollView
Pull Request resolved: https://github.com/facebook/react-native/pull/26611
Test Plan: Updated unit test in splitLayoutProps-test.js.
Differential Revision: D17661079
Pulled By: cpojer
fbshipit-source-id: 747da27b11c3ca59b7f639f393ae5ac137f5490a
Summary:
Very small update here. 0fcaca8e26 accidentally introduced a whitespace error (trailing whitespace) in an iOS test file - This whitespace error is now propagated into all new projects generated by `react-native init`. This fixes it.
## Changelog
[iOS] [Fixed] - Template whitespace error
Pull Request resolved: https://github.com/facebook/react-native/pull/26631
Test Plan: N/A
Differential Revision: D17661040
Pulled By: cpojer
fbshipit-source-id: 1858d2fe238d139894738187ec73f1e27e306294
Summary: We need to check if `_eventEmitter` is not nullptr before each call on it.
Reviewed By: sammy-SC
Differential Revision: D17531070
fbshipit-source-id: e9b5608845c10c7c2ef38f43c8deb67dad10fb6f
Summary:
Seems a ScrollView sometimes calls the delegate in own destructor; and seems that in some configurations the delegate is also already destroyed at this point. I am not sure if this a bug in UIKit or not, but seems the fix is easy, we just have to clear the ScrollView's delegate on the delegate's deallocation.
This issue is also looks similar:
https://stackoverflow.com/questions/18778691/crash-on-exc-breakpoint-scroll-view/19011871
Reviewed By: sammy-SC
Differential Revision: D17531071
fbshipit-source-id: 373ae5270199f3a9099bda8c34b06737446858f1
Summary:
In `CatalystInstanceImpl.destroy()`, we require the TurboModuleManager using the [following lines](https://fburl.com/diffusion/a4y6wbft):
```
final JSIModule turboModuleManager =
ReactFeatureFlags.useTurboModules
? mJSIModuleRegistry.getModule(JSIModuleType.TurboModuleManager)
: null;
```
For some strange reason, even though `ReactFeatureFlags.useTurboModules` is true, the TurboModuleManager isn't registered with mJSIModuleRegistry. I spent some time looking through the code, but I couldn't figure out why. These lines actually aren't necessary, so it's possible to fix the issue by simply working around it, which is what this diff does. We shouldn't have been double requiring the TurboModuleManager anyways, since `CatalystInstance.java` has a method to set the TurboModuleManager, which we call in `ReactInstanceManager.createReactContext`.
## Alternative approach
I could push this diff to the next cut, and instead land a diff that adds debug information to the native crash. At the cost of a week, it may help us figure out why we're seeing the crash. Thoughts? cc fkgozali
Reviewed By: fkgozali
Differential Revision: D17636604
fbshipit-source-id: ecfff593dc6eb4ec4d5e331348b308bc7ab37966
Summary:
There are cases where the CallbackWrapper instances were added from different thread, potentially crashing the inner std::unordered_set<> we're using to keep the wrappers alive for extended time.
To avoid it, let's just use std::mutex.
Reviewed By: shergin
Differential Revision: D17631233
fbshipit-source-id: e8f98004e45a68be31f8f0cda118fb67dcb06d45
Summary:
Adds a flag useVanillaJNI in YogaConfig to determine whether to use FbJNI or JNI.
Currently default is set to false.
We will experiment based on this flag once all code have been migrated.
Reviewed By: Andrey-Mishanin
Differential Revision: D17601703
fbshipit-source-id: 377a5bd2a6f8a7584e84932e87fa7044d8165efd
Summary:
This diffs adds a separate file YGJNIVanilla.cpp to add jni methods which uses vanilla JNI instead of FBJNI.
In this diff only one method has been added to setup the experiment boolean setup.
At the end of this diff stack , we will be able to experiment between fbjni and vanilla jni in yoga and finally get rid of fbjni which saves us around 300Kb per architecture in yoga binary size.
Reviewed By: Andrey-Mishanin
Differential Revision: D17601591
fbshipit-source-id: a88520c625bd8b5d9ffcf8ab5f02fc71dc800081
Summary: Details in Task T53266042. AMA users are trying to upload video data of more than 300 MB which is causing spikes of server_err in the web tier. So i added check to retrive videos that have size < 100 MB.
Reviewed By: furdei
Differential Revision: D17544308
fbshipit-source-id: 5a1d1329b6b12656f1617bb8775e303c96d529cb
Summary:
## Description
The C++ lambda that JS invokes to create TurboModules uses `TurboModuleManager`. It is possible for this lambda to outlive the `TurboModuleManager` instance because we delete `TurboModuleManager` on the JS Thread before we schedule the deletion of `CatalystInstanceImpl` object on a neutral third-party background thread. `CatalystInstanceImpl` owns the JS VM instance that owns the C++ lambda.
## [CatalystInstanceImpl.java](https://fburl.com/diffusion/vt4pwjwa)
```
public void destroy() {
// ...
getReactQueueConfiguration()
.getJSQueueThread()
.runOnQueue(
new Runnable() {
Override
public void run() {
// We need to destroy the TurboModuleManager on the JS Thread
if (turboModuleManager != null) {
turboModuleManager.onCatalystInstanceDestroy();
}
getReactQueueConfiguration()
.getUIQueueThread()
.runOnQueue(
new Runnable() {
Override
public void run() {
// AsyncTask.execute must be executed from the UI Thread
AsyncTask.execute(
new Runnable() {
Override
public void run() {
// Kill non-UI threads from neutral third party
// potentially expensive, so don't run on UI thread
// contextHolder is used as a lock to guard against
// other users of the JS VM having the VM destroyed
// underneath them, so notify them before we reset
// Native
mJavaScriptContextHolder.clear();
mHybridData.resetNative();
getReactQueueConfiguration().destroy();
Log.d(
ReactConstants.TAG,
"CatalystInstanceImpl.destroy() end");
ReactMarker.logMarker(
ReactMarkerConstants.DESTROY_CATALYST_INSTANCE_END);
}
});
}
});
}
});
}
});
// ...
}
```
The JS thread is also terminated in the neutral third-party thread. Therefore, it should be possible for JS to request a `TurboModule` after `TurboModuleManager` has been destroyed (i.e: JS can try to access memory that was freed). This is why I think we're getting a segfault in T54298358.
## Fix
The fix was to wrap all the member variables of TurboModuleManager we use in `TurboModuleProviderFunctionType` in weak references. This way, we can make sure that the memory is valid before using it.
Reviewed By: fkgozali
Differential Revision: D17539761
fbshipit-source-id: fe527383458a019a4cb9107ec5c3ddd6295ae41c
Summary:
I upstreamed the changes to this file from previous commits to React in this (unlanded) PR: https://github.com/facebook/react/pull/16898#issuecomment-535248721
I had to make some additional changes to be able to make Flow pass there. Bringing those changes back to FBSource as well. Having this change made here will make the next sync easier as we won't have to deal with conflicts then.
Changelog:
[Internal]
Reviewed By: cpojer
Differential Revision: D17586781
fbshipit-source-id: 4be8376d0af4fb5d63410afaaf5bb0005d992981
Summary:
`HostComponent` is built specifically to differentiate from `ReactNative.NativeComponent`. These tests should ensure that is the case, and help it stay that way.
I also expect these tests to be duplicated to DefinitelyTyped to help the team working on the TypeScript types ensure they have things modeled correctly.
Reviewed By: cpojer
Differential Revision: D17580120
fbshipit-source-id: c14eb18507cbee1b308beeff0092607e18706171
Summary:
MeasureLayout requires either a reactTag or a ref to a host component. Now that we have a type for Host Components we can be more differentiating here.
Also, because Object is treated as `any` in flow, the type was allowing the return from findNodeHandle or a ref itself be passed, even though both of those are nullable.
This change explicitly requires checking for null before calling the function which is consistent with the behavior of the implementation of measureLayout.
Changelog:
[Changed] Flowtype for measureLayout now disallows null as reactTag
Reviewed By: cpojer
Differential Revision: D17579300
fbshipit-source-id: af062fcd9dfc40eab42e5c5452af2ff653d0888e
Summary:
This PR solves bug https://github.com/facebook/react-native/issues/26552 for Android. Allows an app to receive url events through Linking from NFC tags
## Changelog
[Android] [Fixed] - This branch checks also for `ACTION_NDEF_DISCOVERED` intent matches to send the url events
Pull Request resolved: https://github.com/facebook/react-native/pull/26553
Test Plan: Tested the code multiple times with both NFC tags and normal links
Differential Revision: D17589654
Pulled By: cpojer
fbshipit-source-id: 55e854e765a84da5e22ec2cc51d0fe0972254175
Summary:
I am importing an image from a scoped package and I expected this to be recognized by the `module.name_mapper` and treated as a `RelativeImageStub`. But since there's an `@` in the path, the string does not match the regex pattern as it is defined today. Therefore I added the possibility of a `@` in the start of the path to the regex pattern.
Example import not recognized by the name_mapper today:
```
import NicePicture from 'example-pkg/assets/nice-picture.png'
```
## Changelog
[General] [Fixed] - Make RelativeImageStub regex match images in scoped packages
Pull Request resolved: https://github.com/facebook/react-native/pull/26567
Test Plan:
* I have run `yarn flow` in the `react-native` project
* I tested that it resolves my issue with images in scoped packages in my own app's repo
Differential Revision: D17589473
Pulled By: cpojer
fbshipit-source-id: d0c18f2b36456fd974012a0605f3d9ceff0ad744
Summary:
On the Windows platform, with hermes-engine enabled, the assembly crashes with an error:
The problem lies in calling hermes command without the leading arguments `"cmd", "/c"` ([react.gradle, line: 152](e028ac7af2/react.gradle (L152)) )
## Changelog
[General] [Fixed] - Added a platform check and running commandLine with the corresponding arguments
Pull Request resolved: https://github.com/facebook/react-native/pull/26556
Test Plan:
Under Windows, enable hermes-engine in _build.gradle_ and run the `gradlew assembleRelease` or `gradlew bundleRelease` command
Also check assembly on other available platforms
Differential Revision: D17587023
Pulled By: cpojer
fbshipit-source-id: bab10213b23fac5ab6a46ac4929759dcd43e39c2
Summary:
This diff adds nuance to timer creation. Imagine the following bit of JS:
```
setTimeout(() => {
console.log("Timeout")
}, 0);
setImmediate(() => {
setNine("Immediate");
});
```
In classic RN, `setTimeout` will be called async by the bridge, immediate is implemented in JS, so the ordering of logs will be:
1. Immediate
2. Timeout
In bridgeless RN `setTimeout` is called sync, so the ordering of the logs is:
1. Timeout
2. Immediate
In order to preserve ordering, this diff adds a timer creation method which doesn't immediately invoke it, but waits one frame to do so.
This PR does the same thing for android, and explains the reasoning for preserving behaviour (some products may rely on this behaviour) f054928124
Reviewed By: ejanzer
Differential Revision: D17535639
fbshipit-source-id: 3f734c420a6a95be2ee10e8d6ac48adc79ef1c96
Summary:
The stack of D17563110 was reverted because it triggered a failing OTA job that wasn't caught at land time.
Fixing the issue by reverting the change to `Route.js` and re-landing the rest of the diff.
Differential Revision: D17564219
fbshipit-source-id: 166b50a163ce8ae226de224882a98c40652e29ac
Summary:
We found that many callsites existed that could be using the native driver, but weren't. In order to help people use it when appropriate and eventually switch the default, we are requiring that useNativeDriver is explicit, even when set to false.
This change adds a runtime warning if useNativeDriver is not specified, hopefully giving some light feedback to remember to use the native driver when you can. Without it being explicit it is very easy to forget setting this.
Reviewed By: JoshuaGross
Differential Revision: D17575918
fbshipit-source-id: e54612d87177e1821692b7de20fe673df0e890d2
Summary:
In React Native there are three types of "Native" components.
```
createReactClass with NativeMethodsMixin
```
```
class MyComponent extends ReactNative.NativeComponent
```
```
requireNativeComponent('RCTView')
```
The implementation for how to handle all three of these exists in the React Native Renderer. Refs attached to components created via these methods provide a set of functions such as
```
.measure
.measureInWindow
.measureLayout
.setNativeProps
```
These methods have been used for our core components in the repo to provide a consistent API. Many of the APIs in React Native require a `reactTag` to a host component. This is acquired by calling `findNodeHandle` with any component. `findNodeHandle` works with the first two approaches.
For a lot of our new Fabric APIs, we will require passing a ref to a HostComponent directly instead of relying on `findNodeHandle` to tunnel through the component tree as that behavior isn't safe with React concurrent mode.
The goal of this change is to enable us to differentiate between components created with `requireNativeComponent` and the other types. This will be needed to be able to safely type the new APIs.
For existing components that should support being a host component but need to use some JS behavior in a wrapper, they should use `forwardRef`. The majority of React Native's core components were migrated to use `forwardRef` last year. Components that can't use forwardRef will need to have a method like `getNativeRef()` to get access to the underlying host component ref.
Reviewed By: rickhanlonii
Differential Revision: D17563615
fbshipit-source-id: b9e6042805517d502770fcba37301c2c5b6452b6
Summary:
We need to migrate to HostComponent instead of the exported type from codegenNativeComponent which is the same type
Changelog:
[Internal] Migrate NativeComponentType from codegenNativeComponent to HostComponent
Reviewed By: rickhanlonii
Differential Revision: D17563307
fbshipit-source-id: 01c8fea8c67b33bed42ae28ffb8c132be87b9a7a
Summary:
We need to migrate to HostComponent, this is the first batch.
Changelog:
[Internal] Migrate NativeComponentType from codegenNativeComponent to HostComponent
Reviewed By: rickhanlonii
Differential Revision: D17562879
fbshipit-source-id: ce1993b64a79cede3598c89ddff0dadf07fde92f
Summary:
In React Native there are three types of "Native" components.
```
createReactClass with NativeMethodsMixin
```
```
class MyComponent extends ReactNative.NativeComponent
```
```
requireNativeComponent('RCTView')
```
The implementation for how to handle all three of these exists in the React Native Renderer. Refs attached to components created via these methods provide a set of functions such as
```
.measure
.measureInWindow
.measureLayout
.setNativeProps
```
These methods have been used for our core components in the repo to provide a consistent API. Many of the APIs in React Native require a `reactTag` to a host component. This is acquired by calling `findNodeHandle` with any component. `findNodeHandle` works with the first two approaches.
For a lot of our new Fabric APIs, we will require passing a ref to a HostComponent directly instead of relying on `findNodeHandle` to tunnel through the component tree as that behavior isn't safe with React concurrent mode.
The goal of this change is to enable us to differentiate between components created with `requireNativeComponent` and the other types. This will be needed to be able to safely type the new APIs.
For existing components that should support being a host component but need to use some JS behavior in a wrapper, they should use `forwardRef`. The majority of React Native's core components were migrated to use `forwardRef` last year. Components that can't use forwardRef will need to have a method like `getNativeRef()` to get access to the underlying host component ref.
Note, we will need follow up changes as well as changes to the React Renderer in the React repo to fully utilize this new type.
Changelog:
[Internal] Flow type to differentiate between HostComponent and NativeMethodsMixin and NativeComponent
Reviewed By: jbrown215
Differential Revision: D17551089
fbshipit-source-id: 7a30b4bb4323156c0b2465ca41fcd05f4315becf
Summary:
In D17439957, I noted that YogaLogger#log throws a NoMethodFoundException when called from C++ b/c C++ and Java's signatures of that method don't match. C++ uses YogaNodeJNIBase for the first param, Java uses YogaNode. Both my attempts to fix this failed.
Attempt #1 - Make Java use YogaNodeJNIBase. This doesn't work because the :java-interface target includes YogaLogger but not YogaNodeJNIBase. Moving YogaLogger to the impl target doesn't work either b/c other files in :java-interface reference YogaLogger.
Attempt #2 - Make C++ use YogaNode. This doesn't work b/c we try to call the log method with objects of fbjni type YogaNodeJNIBase. This would be fine in Java since YogaNodeJNIBase extends YogaNode. But fbjni's typing isn't advanced enough to know this, so the Yoga C++ fails to compile.
At this point, I was wondering what the value of having this param in the log function at all was. None of the implementations in our codebase use it today. It might be easier to just remove it all together. This also removes a bug with YGNodePrint where we pass a null layout context that eventually causes a SIG_ABRT when we use it to try to find a YogaNode to pass to this function. (https://fburl.com/diffusion/ssw9h8lv).
Reviewed By: amir-shalem
Differential Revision: D17470379
fbshipit-source-id: 8fc2d95505971a52af2399a9fbb60b63f27f0ec2
Summary:
These types aren't robust to changes in the React component type. When we refactor requireNativeComponent these will error. This change is forwards compatible.
Changelog:
[Internal] Improve internal type in DrawerLayoutAndroid
Reviewed By: JoshuaGross
Differential Revision: D17561194
fbshipit-source-id: 470289449b4d5b3148692f1945fb720e1e3972eb
Summary:
This is used by Image.android.js and needs to be flow typed to be able to have confidence in the requireNativeComponent type change
Changelog:
[Internal] Flow type vendor/core/merge.js
Reviewed By: JoshuaGross
Differential Revision: D17561195
fbshipit-source-id: 2639f2628e15b2dd5469bb2ebfe935a444025a21
Summary:
It's possible that this crashes because the callback is non-null/non-undefined but isn't a function; if so, I would like to collect that information.
These changes have already been made in the React repo.
Reviewed By: TheSavior
Differential Revision: D17559022
fbshipit-source-id: a0538d533c3c482d27eef0ed3c8c980e2bc8e817
Summary:
@public
We're seeing crashes from multiple threads trying to call `[NSData appendData:]` at the same time. Usually the RCTURLRequestHandlers implementation avoids this but if you're using a background queue, it is pretty easy to reach this case.
Adding a lock to accessors of `_data` should prevent this.
Reviewed By: shergin
Differential Revision: D17552136
fbshipit-source-id: 3384d36221d0ada8cda638ad8e79e1bf3862f93f
Samuel Susla
Oleksandr Melnykov
masaaki1915
Valentin Shergin
Marc Mulcahy
Vojtech Novak
Roshan Gautam
Petter Hesselberg
Pablo Espinosa
Daniel Andersson
Miguel Alatzar
vasilich
Frieder Bluemle
Dulmandakh
Ramanpreet Nara
Kevin Gozali
Marek Cirkos
Luna Wei
Sidharth Guglani
Rajdeep Kaur
Eli White
Han Lin Yap
Andrea Cimitan
Mats Byrkjeland
Ilia Burdukovski
Juan Tejada
Peter Argany
Logan Daniels
Uts Sikder
Joshua Gross
Mehdi Mulani
