Summary: Looks like some of the imports went missing when merging. Found this when testing this again.
Reviewed By: mdvacca
Differential Revision: D17200737
fbshipit-source-id: ded39493786d4999317c5e29be270e5990601b06
Summary: Same as prior diff, but Android.
Reviewed By: JoshuaGross
Differential Revision: D17005308
fbshipit-source-id: 1ac815a232dceaf918e14b045e04aed53a00ae47
Summary: This bypasses setNativeProps and causes all Fabric animations to go through the mounting layer.
Reviewed By: mdvacca
Differential Revision: D17201061
fbshipit-source-id: c43b59913d8240860e5269e73e1c0ec10ec8e717
Summary: When you return null or [NSNull null] from a TurboModule method, we should just return null to JS.
Reviewed By: fkgozali
Differential Revision: D17141170
fbshipit-source-id: a73410b7a4a765750a8dd9c4e904046ffe1c0fc1
Summary: Implements the new `reportException` method in the iOS version of `ExceptionsManager`.
Reviewed By: sammy-SC
Differential Revision: D17226365
fbshipit-source-id: baa81424399175eaf8fc0835d4df01897e7fa468
Summary:
Refines the condition for ignoring updates to an already-open redbox on iOS.
Previously we would only update the stack trace if the message string in the update was exactly the same as in the initial redbox. With this diff we rely on the `exceptionId` parameter instead, and only fall back to string comparison if it's omitted (i.e. for non-JS uses of redbox on iOS).
NOTE: `exceptionId` is part of the existing ExceptionsManager API and is already supported on Android.
Reviewed By: sammy-SC
Differential Revision: D17226179
fbshipit-source-id: 5940110bf4e4358a8a1b3477e8d2cf8b224dd9f8
Summary: Enables the use_framework! support for the Flipper for RN
Reviewed By: jknoxville
Differential Revision: D17206811
fbshipit-source-id: ec1408083655044e1c10d4b7d3b0a6844b15511b
Summary: We still include this info in real reports. We also still print the root tag when the app starts. This just removes the redbox "extra data" logging to console. It's noisy, especially on smaller apps in open source that only have one root tag and always empty props.
Reviewed By: cpojer
Differential Revision: D17226903
fbshipit-source-id: a702daaf3a02600fbe9038c46d294c3392953239
Summary: This diff adds support for generating native code for arrays of arrays of objects
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D16936272
fbshipit-source-id: 1543f8c1d5d9d4db28e4c7841ff7184ca0e417b3
Summary:
This diff adds a fixture for supporting arrays of arrays of objects, eventually parsable as:
`$ReadOnlyArray<$ReadOnlyArray<$ReadOnly<{|foo: string|}>>`
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D16936233
fbshipit-source-id: 14143522d82ad7d42e81605bb701890ca2731bed
Summary: Adds support for dynamic value that are `std::vector<std::vector<RawValue>>`
Reviewed By: shergin, mdvacca
Differential Revision: D16936932
fbshipit-source-id: fc8d087f9705af9da56ccc1bd9a0537b2bfeb50d
Summary:
## Overview
This diff adds flow parser support for number unions as Int32Enums
The following will be supported as an Int32 enum:
```
interval?: WithDefault<0 | 15 | 30 | 60, 0>,
```
## Number type issues
We assume that all number enums are ints (so far there's not been a valid use case for unions of floats).
If we think there would be a use case for float unions we would need to update this to something like:
```
// Int32
intervalInt?: WithDefault<Int32Enum<0 | 15 | 30 | 60>, 0>,
// Float
intervalInt?: WithDefault<FloatEnum<0.0 | 15.1 | 30.2 | 60.3>, 0.0>,
```
My recommendation is that we default number unions to ints and if a use case arises later for floats, we would add the Float support as:
```
// Int32
intervalInt?: WithDefault<0 | 15 | 30 | 60, 0>,
// Float
intervalInt?: WithDefault<FloatEnum<0.0 | 15.1 | 30.2 | 60.3>, 0.0>,
```
Reviewed By: JoshuaGross
Differential Revision: D17161701
fbshipit-source-id: 4b016eee45bf28bf505afd14a6c1aeea6ca8c04f
Summary: This diff adds more advanced support for Int32 enums by allowing them as object properties in props
Reviewed By: JoshuaGross
Differential Revision: D17161656
fbshipit-source-id: d4377d95961554c83b60ed929f6279291c2d1104
Summary: This diff adds the snapshots for the new Int32 fixture and renames the ENUM_ fixture to STRING_ENUM
Reviewed By: JoshuaGross
Differential Revision: D17158033
fbshipit-source-id: 405b1da5ede16410434a9097ef256f99e4115533
Summary:
Adds schema to allow for Int32Enums in the codegen.
All of the non-schema updates here are flow fixes, the code there is implemented in the next diffs
Reviewed By: JoshuaGross
Differential Revision: D17158026
fbshipit-source-id: b5a6871225771c3c97a43a901d5f8e51c44f35c8
Summary: See previous diff in this stack
Reviewed By: motiz88
Differential Revision: D17156649
fbshipit-source-id: 12bdba248481258b9c6ca001472a41ca19fb4b6f
Summary: This feature is not necessary any longer with Fast Refresh enabled by default.
Reviewed By: gaearon
Differential Revision: D17156607
fbshipit-source-id: 2396a86d192c6b5d90cbed9cefbf13367dd6b699
Summary:
This change fixes the issue "[ReactInstanceManagerBuilder.build fails unless SoLoader.init has been called](https://github.com/facebook/react-native/issues/26342)" on Android.
The `ReactInstanceManager` constructor calls `initializeSoLoaderIfNecessary`, so the intent is clearly that things should work without an explicit call to `SoLoader.init` on the part of the application.
However, with the introduction of Hermes, we have `ReactInstanceManagerBuilder.getDefaultJSExecutorFactory`, which gets called before the `ReactInstanceManager` constructor. It attempts this:
SoLoader.loadLibrary("jscexecutor");
This fails with the following stack trace:
java.lang.RuntimeException: Unable to start activity ComponentInfo{com.facebook.react.uiapp/com.facebook.react.uiapp.RNTesterActivity}: java.lang.RuntimeException: SoLoader.init() not yet called
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2957)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3032)
at android.app.ActivityThread.-wrap11(Unknown Source:0)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1696)
at android.os.Handler.dispatchMessage(Handler.java:105)
at android.os.Looper.loop(Looper.java:164)
at android.app.ActivityThread.main(ActivityThread.java:6944)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:327)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1374)
Caused by: java.lang.RuntimeException: SoLoader.init() not yet called
at com.facebook.soloader.SoLoader.assertInitialized(SoLoader.java:781)
at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:505)
at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:484)
at com.facebook.react.ReactInstanceManagerBuilder.getDefaultJSExecutorFactory(ReactInstanceManagerBuilder.java:291)
at com.facebook.react.ReactInstanceManagerBuilder.build(ReactInstanceManagerBuilder.java:266)
at com.facebook.react.ReactNativeHost.createReactInstanceManager(ReactNativeHost.java:86)
at com.facebook.react.ReactNativeHost.getReactInstanceManager(ReactNativeHost.java:38)
at com.facebook.react.ReactDelegate.loadApp(ReactDelegate.java:103)
at com.facebook.react.ReactActivityDelegate.loadApp(ReactActivityDelegate.java:83)
at com.facebook.react.ReactActivityDelegate.onCreate(ReactActivityDelegate.java:78)
at com.facebook.react.uiapp.RNTesterActivity$RNTesterActivityDelegate.onCreate(RNTesterActivity.java:40)
at com.facebook.react.ReactActivity.onCreate(ReactActivity.java:44)
at android.app.Activity.performCreate(Activity.java:7183)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1220)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2910)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3032)
at android.app.ActivityThread.-wrap11(Unknown Source:0)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1696)
at android.os.Handler.dispatchMessage(Handler.java:105)
at android.os.Looper.loop(Looper.java:164)
at android.app.ActivityThread.main(ActivityThread.java:6944)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:327)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1374)
## Changelog
[Android] [Fixed] - Don't crash ReactInstanceManagerBuilder.build even if SoLoader has not been explicitly initialized
Pull Request resolved: https://github.com/facebook/react-native/pull/26343
Test Plan:
To demonstrate the defect, remove the call to `SoLoader.init` from `RNTester.onCreate` and run the app.
To demonstrate the fix, apply this PR, which does in fact also remove the call to `SoLoader.init`
Differential Revision: D17223701
Pulled By: mdvacca
fbshipit-source-id: c508ab52bd3fefe8a946ebab7b2906a5d8c21e0f
Summary:
This ressurects D14994945 and fixes the following extra issues:
1. Source map not being accounted for after reloads
2. Breakpoints being resent before Hermes is ready for them
3. Connection being dropped when reloading at inopportune times
This hopefully fixes the issue of having to close and re-open the debugger if
it's attached when reloading.
Reviewed By: sahrens
Differential Revision: D17100911
fbshipit-source-id: df988e7bb532170f5add47b9e49cd7c8ddf67b43
Summary:
By enabling Flipper on RNTester, we can ensure that Flipper continues to work with ReactNative.
Note that Flipper is disabled when RNTester is built with `USE_FRAMEWORKS=1 pod install`
Reviewed By: PeteTheHeat
Differential Revision: D6976784
fbshipit-source-id: 4e16a47949d7ed6400e0b8ccd640be0754203c69
Summary:
It doesn't work super smoothly, but I don't think we should hide it. The ultimate goal is to get it working well in Fabric.
Changelog:
[Internal]
Reviewed By: shergin
Differential Revision: D17201209
fbshipit-source-id: 2d2f447e10173462d98ff01ed58f3cb94da77513
Summary: We used this mechanism at the very early stages of Fabric. Now we do component registration differently.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D17200952
fbshipit-source-id: 16ff9d6569714a24e2a8d58dc6e60ad4d7bc1e16
Summary: It looks like codegen supports string enums as long as defaults are provided. Uncommenting the enums and removing TODOs.
Reviewed By: rickhanlonii
Differential Revision: D17196139
fbshipit-source-id: a076b1a25eb38b23cfd53fd92e8c42f121d08d6b
Summary: This allows to implement `findNodeHandle` in Fabric world (temporary).
Reviewed By: zackargyle, JoshuaGross, mdvacca
Differential Revision: D17175953
fbshipit-source-id: c88bd1c58608450812799d4ecb4a6bf2c027c5f3
Summary: The mehtod implements the core functionality of finding a shadow node by given tag.
Reviewed By: zackargyle, JoshuaGross, mdvacca
Differential Revision: D17175955
fbshipit-source-id: 5cfbb80b2d4e54a33ca9c20a21988df4de54c800
Summary: The new methods provides a way to iterate over all registered shadow trees.
Reviewed By: zackargyle, JoshuaGross, mdvacca
Differential Revision: D17175954
fbshipit-source-id: e4e6ee5a0e0a4e4e36b99d546f8724b99559c8c2
Summary:
Fix flow test case input in react-native-codegen package that has syntax errors.
Missing ";" after export type,
Missing ";" or "," after interface/object type member signature,
Missing ":" in method signature,
etc
## Changelog
[General] [Fixed] - Fix flow test case input in react-native-codegen package
Pull Request resolved: https://github.com/facebook/react-native/pull/26316
Test Plan: Parsed files using flow parser, but some test cases are intended to have syntax error, in this case I fixed unexpected ones.
Reviewed By: rickhanlonii
Differential Revision: D17194969
Pulled By: osdnk
fbshipit-source-id: 262d0af4d9e7e74f7ba3eb30c4fd9753c08f3bf7
Summary:
The README.md was slightly out of date.
## Changelog
[Android] [Fixed] - Fixed RNTester instructions
Pull Request resolved: https://github.com/facebook/react-native/pull/26140
Test Plan: Ran `./gradlew :RNTester:android:app:installJscDebug` to build and install RNTester on my device.
Differential Revision: D17178074
Pulled By: mdvacca
fbshipit-source-id: 677f91833170af54eeb1f0b5431dd94eae7668ac
Summary:
Trying to build the Android RNTester app using Gradle fails with the following error:
```
Errors found:
[...]/RNTester/android/app/src/main/AndroidManifest.xml:2: Error: Hardware feature android.hardware.touchscreen not explicitly marked as optional [ImpliedTouchscreenHardware]
<manifest
~~~~~~~~
[...]/RNTester/android/app/src/main/AndroidManifest.xml:2: Error: Expecting <uses-feature android:name="android.software.leanback" android:required="false" /> tag. [MissingLeanbackSupport]
<manifest
~~~~~~~~
```
This PR adds the two missing `uses-feature` tags to AndroidManifest of RNTester.
## Changelog
[Android] [Fixed] - Fix RNTester Lint errors
Pull Request resolved: https://github.com/facebook/react-native/pull/26279
Test Plan: After adding the tags, the build is successful again.
Differential Revision: D17177952
Pulled By: mdvacca
fbshipit-source-id: c81dce9c6642fc8551f3d0eeb84c984ed06b18e3
Summary: Fixes the crash when calling setCameraDistance with NaN on Android Q.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D17170045
fbshipit-source-id: 386f969e70c56bca6ae5b8ffead62453ebb72857
Summary:
For iOS < 13, default to "light" appearance, just like in Android (instead of `nil`).
This fixes the following redbox:
{F205818545}
Reviewed By: cpojer
Differential Revision: D17147970
fbshipit-source-id: b2adccd349a0a0ff7668c2f30e93164d23c3eea6
Summary:
For now, disable TM completely in test environment, like RNTester integration/unit tests. See details in T53341772
This also fixes the failure discussed in https://github.com/facebook/react-native/pull/26151
Reviewed By: PeteTheHeat
Differential Revision: D17147915
fbshipit-source-id: 1c48ebb9c3b81fc08bc33606dcc38c29297d6010
Summary: This diff migrates `FbReactTTRCStepRenderFlagManager` to use the generated `TTRCStepRenderFlagManagerDelegate` for setting its properties. A bit more work was required to migrate this view manager since it doesn't extend `BaseViewManager`, so I had to add an adapter which made it possible to pass an instance of `FbReactTTRCStepRenderFlagManager` to `TTRCStepRenderFlagManagerDelegate`.
Reviewed By: mdvacca
Differential Revision: D16984172
fbshipit-source-id: 7bf8c1342435c4e615eb9e7ca711f53c63ed3438
Summary:
Our JS codegen assumes that all Android view managers extend `BaseViewManager` which allows generated delegates to set base view props using `BaseViewManagerDelegate`, see and example of the generated delegate for `FbReactTTRCStepRenderFlagManager`:
```
public class TTRCStepRenderFlagManagerDelegate<T extends View, U extends BaseViewManager<T, ? extends LayoutShadowNode> & TTRCStepRenderFlagManagerInterface<T>>{
public TTRCStepRenderFlagManagerDelegate(U viewManager) {
super(viewManager);
}
Override
public void setProperty(T view, String propName, Nullable Object value) {
switch (propName) {
case "traceId":
mViewManager.setTraceId(view, value == null ? null : (String) value);
break;
case "stepName":
mViewManager.setStepName(view, value == null ? null : (String) value);
break;
default:
super.setProperty(view, propName, value);
}
}
}
```
The problem is that `FbReactTTRCStepRenderFlagManager` doesn't extend `BaseViewManager`, but `ViewManager`, which means that we cannot use it with the generated delegate. We cannot use `ViewManager` instead of `BaseViewManager` in our JS codegen either, otherwise we will not be able to set base view props.
This diff makes it possible for delegates generated by JS to be used by Android view managers that do not extend `BaseViewManager`. By having a `BaseViewManagerInterface` we will be able to introduce a no-op base view manager implementation and wrap our original view manager in it so that we can pass as a constructor parameter to `BaseViewManagerDelegate`.
See an example of this approach for `FbReactTTRCStepRenderFlagManager`:
```
public class FbReactTTRCStepRenderFlagManager extends ViewManager<FbReactTTRCStepRenderFlag, ReactShadowNodeImpl> implements TTRCStepRenderFlagManagerInterface<FbReactTTRCStepRenderFlag> {
private final ViewManagerDelegate<FbReactTTRCStepRenderFlag> mDelegate;
public FbReactTTRCStepRenderFlagManager() {
mDelegate = new TTRCStepRenderFlagManagerDelegate<>(new ViewManagerWrapper(this));
}
...
private static class ViewManagerWrapper extends BaseViewManagerAdapter<FbReactTTRCStepRenderFlag> implements TTRCStepRenderFlagManagerInterface<FbReactTTRCStepRenderFlag> {
private final TTRCStepRenderFlagManagerInterface<FbReactTTRCStepRenderFlag> mViewManager;
private FbReactTTRCStepRenderFlagManagerAdapter(TTRCStepRenderFlagManagerInterface<FbReactTTRCStepRenderFlag> viewManager) {
mViewManager = viewManager;
}
Override
public void setTraceId(FbReactTTRCStepRenderFlag view, Nullable String traceId) {
mViewManager.setTraceId(view, traceId);
}
Override
public void setStepName(FbReactTTRCStepRenderFlag view, Nullable String stepName) {
mViewManager.setStepName(view, stepName);
}
}
}
```
Reviewed By: mdvacca
Differential Revision: D16984121
fbshipit-source-id: ea2761dda68a96ff3ba6ac64153bc4e56e396774
Summary:
blairv recently brought an issue with heap snapshots to our attention: When
captured from iOS, the viewer would quite regularly hang forever instead of
capturing the snapshot.
Further investigation showed that it was because the message that Hermes sends
to indicate that it had finished sending chunks of the heap snapshot was
arriving to chrome before the last chunk of the snapshot. This caused Chrome
to believe the snapshot was malformed.
I confirmed that:
- Sends from the Hermes Inspector were occurring in the correct order.
- The WebSocket protocol, being built on top of TCP, also preserves order.
- The Inspector Proxy in Metro was preserving the order of requests it was
given, but the responses were already in the wrong order when they reached
it.
This left the code that Hermes' Inspector calls into to send its messages. On
iOS, the logic to send the request is run on the global dispatch queue which
can and does schedule jobs concurrently with each other. Because the messages
containing heap snapshot chunks are much larger than the "Ok" message used to
indicate the end of the snapshot, the earlier chunk message would often lose
the race with the later "Ok" message.
There was already a serial background queue used by the websocket server to
schedule the actual sending of the message. I re-use it in this diff to
process the message as well.
The architecture of the [same code in Android](https://our.intern.facebook.com/intern/diffusion/FBS/browse/master/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/devsupport/InspectorPackagerConnection.java?commit=64c8954ec7be555509437db6944b9a71a350e87c&lines=283) initially seems to be broken in
the same way, but it is not, because AsyncTask does not run tasks concurrently
any more because Google found it exposed too many concurrency bugs to do so.
pakoito, it seems like you might be somewhat familiar with what's going on
here. Let me know if what I've done is sensible.
Reviewed By: pakoito
Differential Revision: D17106960
fbshipit-source-id: af85ff1753324340bb55fc63048e8bd424c8a983
Summary:
We probably don't always need to crash in these cases.
This should replace all prod/dev crashes with logged SoftExceptions.
Note that this is currently only used for Fabric.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D17170459
fbshipit-source-id: 70757ae88deb8c893b36971d879174e25a194fb9
Summary:
This diff replaces the usage of UIManagerModule.playTouchSound() in Pressability and Touchable for the SoundManager.playTouchSound()
Previously landed and unladed: D16543433
Reviewed By: rickhanlonii, JoshuaGross
Differential Revision: D17170140
fbshipit-source-id: 33a8ca508ec31f034c76fb0ac4107150d43c608b
Ram N
David Vacca
Joshua Gross
Ramanpreet Nara
gengjiawen
Nat Mote
Moti Zilberman
Pritesh Nandgaonkar
Dan Abramov
Rick Hanlon
Christoph Nakazawa
Frieder Bluemle
Petter Hesselberg
Will Holen
Valentin Shergin
Dulmandakh Sukhbaatar
Zihan Chen (MSFT)
Héctor Ramos
Oleg Lokhvitsky
Oleksandr Melnykov
Kevin Gozali
Ashok Menon