Summary:
This is a refactor of the logging of Fabric commit statistics to simplify the way we track performance points.
we'll later refactor and iterate on the API to integrate fabric perf point into developer tools
changelog: [internal] internal
Reviewed By: ShikaSD
Differential Revision: D34006700
fbshipit-source-id: 93a01accd90dfacc8b44edd158033b442a843284
Summary:
Was trying out some behaviour when using the MapBuffer experiment and fixed some small issues.
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D34108859
fbshipit-source-id: 550ca0847419006ec17472cc4b70d38fc8d05396
Summary:
Brings the same fix https://www.internalfb.com/diff/D34015853 (https://github.com/facebook/react-native/commit/be260b9f479a3b55ee43d2959d2c49fd3c1eb4ac) for ReactScrollView to ReactHorizontalScrollView
When setting ScrollView's contentOffset, if the ScrollView hasn't been laid out yet when ReactHorizontalScrollViewManager.setContentOffset is called, then scroll position is never set properly. This is because the actual scroll offset (0, 0) was being passed into setPendingContentOffsets, instead of the desired scroll offset. Thus, when ReactHorizontalScrollView.onLayout gets called, ReactHorizontalScrollView.scrollTo gets called with (0, 0).
Changelog:
[Android][Fixed] - Fix ReactHorizontalScrollView contentOffset
Reviewed By: bvanderhoof
Differential Revision: D34246489
fbshipit-source-id: d923f7c9f136f7275d64bd658ffd5c2cc049d392
Summary:
Found that after backgrounding `mShouldStop` would always remain true, which prevents events from being dispatched / scheduled.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D34247567
fbshipit-source-id: 63876986dc0cee5e2a73cb4f8a35d90379d9f8ea
Summary:
The check implemented in PR https://github.com/facebook/react-native/issues/29089 is flawed as the exception class name and message depends on the OS version as well as the OEM. In OxygenOS running android 11, it comes out as RuntimeException and the check fails and hence the crash occurs again. But on observing closely, its clear that the exception message is consistent across OEMs with similar strings appearing in them that have been included in the if check.
Hence there is a simple fix to this issue, by checking the message instead of the exception class.
Here is the snippet:
```
private Nullable CookieManager getCookieManager() {
if (mCookieManager == null) {
possiblyWorkaroundSyncManager(mContext);
try {
mCookieManager = CookieManager.getInstance();
} catch (IllegalArgumentException ex) {
// https://bugs.chromium.org/p/chromium/issues/detail?id=559720
return null;
} catch (Exception exception) {
String message = exception.getMessage();
// We cannot catch MissingWebViewPackageException as it is in a private / system API
// class. This validates the exception's message to ensure we are only handling this
// specific exception.
// The exception class doesn't always contain the correct name as it depends on the OEM
// and OS version. It is better to check the message for clues regarding the exception
// as that is somewhat consistent across OEMs.
// For instance, the Exception thrown on OxygenOS 11 is a RuntimeException but the message contains the required strings.
// https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/webkit/WebViewFactory.java#348
if (exception.getClass().getCanonicalName().contains("MissingWebViewPackageException") ||
(message!=null && (message.contains("WebView provider") ||
message.contains("No WebView installed")))){
return null;
} else {
throw exception;
}
}
}
return mCookieManager;
}
```
## Changelog
[General] [Added] - A fail proof check to catch any crash involving webview:
if (exception.getClass().getCanonicalName().contains("MissingWebViewPackageException") || (message!=null && (message.contains("WebView provider") || message.contains("No WebView installed"))))
[General] [Removed] - Flawed check to catch WebViewProvider crash:
if (message != null && exception.getClass().getCanonicalName().contains("MissingWebViewPackageException"))
Pull Request resolved: https://github.com/facebook/react-native/pull/33088
Test Plan:
This code has been tested rigorously on OnePlus Nord CE 5G (Oxygen OS 11.0) and Realme X (Realme UI 2.0) both running on Android 11 and reproducing the crash on a hybrid (Native android + ReactNative) app that showed this crash in production being dependent on WebViews. I have implemented an entire patched fork of 0.67.2 to fix this issue in our app.
How to test:
Launch any app that has a webview.
Go to settings->apps->Android System Webview -> disable.
Resume/Restart the app.
In this fix:
Open a webview and notice that the app will not crash.
In current version:
App crashes on startup as the exception escapes the catch block.
Even if it survives startup (did on Realme X), it will crash once you try to open a webview.
Reviewed By: rh389
Differential Revision: D34240097
Pulled By: cortinico
fbshipit-source-id: 0f1f9a3b078c0ad3074c7841392892cb70b427eb
Summary:
This diff integrates DeviceConfig into ReactNativeConfig used by ReactNativePanelApps. The goal is to be able to control Fabric MCs using GKs and QEs in RN VR apps
I did an audit of the MCs that were used by RNPanelApps:
```
"react_fabric:enabled_android_fabric_logs": -> will get data from GK (disabled by default)
"react_fabric:disable_virtual_node_preallocation": -> does not exist in code anymore
"react_fabric:enable_early_event_emitter_update": -> will get data from MC (disabled using static value)
"react_fabric:enable_background_executor_android": -> does not exist in code anymore
"react_fabric:enable_props_forwarding_android": -> does not exist in code anymore
"react_fabric:remove_outstanding_surfaces_on_destruction_android": -> will get data from MC static value (ENABLED using static value)
"react_fabric:enable_large_text_measure_cache_android": -> will get data from MC default value (ENABLED by default)
```
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D33898210
fbshipit-source-id: 0ea1e0e2fc15929bec328f7dcc9410efa9925b34
Summary:
Certain events (practically always touch events probably?) will not be correctly emitted to JS in Fabric if there is no View underneath the touch - if there is no touch target besides the ReactRootView.
We can just rely on the UIManagerType annotation on the Event, which is correct and reliable.
Instead, what we do today is derive UIManagerType from ViewTag, which is correct UNLESS the viewtag is the same as the SurfaceId, in which case we may incorrectly detect that the touch is on a non-Fabric View when in fact it is on a Fabric ReactRootView.
ViewTag is not a reliable way to detect Fabric vs non-Fabric /when looking at the RootView/, where ViewTag is the same as SurfaceId. Ironically, only Fabric RootViews have a SurfaceId at all.
Practically, this won't change anything since events emitted to ReactRootView don't go anywhere (they don't have EventEmitters). So this is a pretty low-stakes fix, but is still technically correct.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D34149878
fbshipit-source-id: f01da556865eb597a50cd49e9787316a0ed56f70
Summary:
Currently we are using Appcompat in version 1.0.2 which is almost 4 years old now, this PR updates it to version 1.4.1.
Using Appcompat 1.0.2 was also causing a crash on RNTester due to an error where FontFamily's method was not found (Related to https://github.com/facebook/react-native/issues/33065)
Closes https://github.com/facebook/react-native/issues/31620
## Changelog
[Android] [Changed] - Bump android Appcompat to 1.4.1
Pull Request resolved: https://github.com/facebook/react-native/pull/33072
Test Plan: Use `./scripts/test-manual-e2e.sh` to test both RNTester and a new app
Reviewed By: cortinico
Differential Revision: D34107105
Pulled By: ShikaSD
fbshipit-source-id: 966e4687b09ae50a88ee518622f073d72e8c6550
Summary:
The views with touch event props are currently flattened by Fabric core, as we don't take event listeners into account when calculating whether the view should be flattened. This results in a confusing situation when components with touch event listeners (e.g. `<View onTouchStart={() => {}} /> `) or ones using `PanResponder` are either ignored (iOS) or cause a crash (Android).
This change passes touch event props to C++ layer and uses them to calculate whether the view node should be flattened or not. It also refactors events to be kept as a singular bitset with 32 bit (~`uint32_t`).
Changelog: [Changed][General] Avoid flattening nodes with event props
Reviewed By: sammy-SC
Differential Revision: D34005536
fbshipit-source-id: 96255b389a7bfff4aa208a96fd0c173d9edf1512
Summary:
In https://github.com/facebook/react-native/issues/32975 I implemented the new `insetsController#setSystemBarsAppearance` interface, but I found that on Android 11 (API 30) it doesn't appear to work which I missed in earlier testing. It works correctly on Android 12 and the deprecated `systemUiVisibility` interface still works fine on Android 11, so I'm having Android 11 use the deprecated mechanism.
## 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] [Fixed] - Fix StatusBar on Android API 30
Pull Request resolved: https://github.com/facebook/react-native/pull/33058
Test Plan: Tested in `rn-tester` on simulators using Android 9, 10, 11, 12, and on an Android 9 device.
Reviewed By: lunaleaps
Differential Revision: D34050025
Pulled By: ShikaSD
fbshipit-source-id: ad80fae1446aca368b09df810785a1cc38383450
Summary:
This diff adds `RedBoxSurfaceDelegate` to replace existing logic in `DevSupportManagerBase` to abstract how we show/hide the RedBox surface. The delegate will wrap a RedBoxDialog instance, which is used to show/hide the dialog for default behavior (when there is no surface delegate for redbox got provided).
I also updated the interface for delegate to accomodate new use cases:
- Add `isShowing` for the `SurfaceDelegate`
- Add a list of getters for `DevSupportManager` for data access in the delegate
- (Update 2/7) Separate Dialog from `RedBoxDialog`, and re-named it to `RedBoxContentView`. This is to make it clear that the delegate is responsible to provide actual surface implementation (Dialog). The content view is meant to be shared.
Changelog:
[Android][Internal]
Reviewed By: javache
Differential Revision: D33987835
fbshipit-source-id: 57c20648e7f2ec8238963feca27ccd5518e7931d
Summary:
Not setting locale for language/country neutral operation may cause bug depending on the default locale.
See https://docs.oracle.com/javase/7/docs/api/java/util/Locale.html#ROOT
Note: I am just searching for toLowerCase() and toUppercase() in my project's dependencies and send the same PR, in order to just be considered. Although I've seen the lack of explicit locale has caused issues for us, I am not sure if react-native is actually affected. I haven't checked for `String.format()` yet.
Example related issue: joltup/rn-fetch-blob#573
## Changelog
[Android] [Fixed] - Use root locale when converting string case.
Pull Request resolved: https://github.com/facebook/react-native/pull/33028
Reviewed By: ShikaSD
Differential Revision: D33943446
Pulled By: cortinico
fbshipit-source-id: d5be9392ea7c21a33436acac5b5e8c50b7c7e31e
Summary:
In order to support AnimatedColor.setValue for platform colors, we need to pass the platform color object to the native animated node which will then resolve and apply the color.
Thus, the approach is:
- Add a new API updateAnimatedNodeConfig to NativeAnimatedModule
- [JS] On AnimatedColor.setValue, if the value is a platform color, then we call updateAnimatedNodeConfig
- [Android] We introduce AnimatedNodeWithUpdateableConfig interface with a method updateConfig. On ColorAnimatedNode.java, we use updateConfig to resolve and apply the color
Changelog:
[Internal][Fixed] - Use context from view when resolving platform color
Reviewed By: javache, mdvacca
Differential Revision: D34025193
fbshipit-source-id: 8b368f6b7cb2cf7cebe8b66461cd4185cbadd44c
Summary:
There are cases where the activity may not exist (such as for VRShell panel apps). In this case we will search for a view associated with a PropsAnimatedNode to get the context.
Changelog:
[Internal][Fixed] - Use context from view when resolving platform color if activity doesn't exist
Reviewed By: javache
Differential Revision: D34022882
fbshipit-source-id: c316935af1034ea770f3ef9334f77d6dc783fb27
Summary:
Updates early return in the CREATE command codepath that checks if the view already exists before allocating it. Normally the view state is expected to be created only if the view is preallocated, but empty view state is also created for the flattened nodes when they create an event emitter.
By checking the view existence, we can ensure that view was indeed preallocated before, and skip for optimization purposes.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D34050884
fbshipit-source-id: 489fc1052fec9f71712ea729121ac8ef3e3f3d4e
Summary:
This diff separates the content view creation logic from existing `RedBoxDialog` logic. After the change, `RedBoxDialog` is no longer a subclass of `Dialog`, but behaves like a dialog with forwarding pattern to delegate dialog API to internal member. This will keep the APIs consistent with dependent components.
The motivation of the change is to make the content view reusable. This is important in VR surface where we don't have activities and necessary implementations for Dialog to show.
Changelog:
[Android][Internal]
Reviewed By: javache
Differential Revision: D34016503
fbshipit-source-id: 261594bda9f6fb2d83764a1e5ec2e9e60d8d39a3
Summary:
We put the `:interfaces` target on the dependencies list for `:devsupport` target in the [BUCK file](https://fburl.com/code/lrr1c0pn). In the following diffs I will need to put the interface [`/devsupport/RedBoxHandler`](https://fburl.com/code/v53euvps) on to [`/devsupport/interfaces/DevSupportManager`](https://fburl.com/code/k8gwxa0f). This violates the dependency rule.
Since `RedBoxHandler` is an interface, I moved it to the interfaces list in this diff to unblock.
Changelog:
[Android][Internal]
Reviewed By: yungsters
Differential Revision: D33987834
fbshipit-source-id: 77a1ee14bd10c6bbaac2ee465ae7050e99ed0399
Summary:
changelog: [internal]
In order to call `RuntimeScheduler::callExpiredTasks`, we need to pass it to `Scheduler` through context container.
Reviewed By: javache
Differential Revision: D34042293
fbshipit-source-id: 62d18507fb107c5be2ac9d003f63735aab6a09ac
Summary:
When setting ScrollView's contentOffset, if the ScrollView hasn't been laid out yet when ReactScrollViewManager.setContentOffset is called, then scroll position is never set properly. This is because the actual scroll offset (0, 0) was being passed into setPendingContentOffsets, instead of the desired scroll offset. Thus,
when ReactScrollView.onLayout gets called, ReactScrollView.scrollTo gets called with (0, 0).
Also updates out of date comments,
Changelog:
[Android][Fixed] - Fix ScrollView contentOffset
Reviewed By: ryancat
Differential Revision: D34015853
fbshipit-source-id: 84141a663fdb0ace2be7cef61f14944cb08125d1
Summary:
Update javadoc of ReactRoot.getState() since the task was fixed and the API remained the same
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D33981298
fbshipit-source-id: 0136a640b884a787b0a20162781735630c1fa1c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33038
While rolling out RN 0.68.x we noticed that `libhermes.so` and `libjsc.so` were included
inside the final .aar we publish to NPM. This forced users (on both old or new arch) to
specify a `pickFirst` directive inside their packaging option (which is unpractical and
risky as the two .so might not be compatible each other if they're coming from
different Hermes/JSC versions).
Changelog:
[Android] [Fixed] - Do not bundle libhermes.so or libjsc.so inside the React Native Android AAR
Reviewed By: ShikaSD
Differential Revision: D33979107
fbshipit-source-id: 0b71d59f210b8bc9903cd0f30ed6e2120aab99e0
Summary:
This change makes automatic sample profiling registration opt in. This is in preparation for an upcoming change where hermes
will enforce that the sampling profiler must be destroyed on
the same thread it was created.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D33826992
fbshipit-source-id: 89843b5fc5b936f674a8d0a470e92af0cd8f6125
Summary:
Venice uses `SurfaceHandler` abstraction which start/stops surfaces independently from `Binding.cpp`, so previous `onSurfaceStart/Stop` callback would not be triggered.
On Android, each surface is used exactly once at the time of writing, so we can use `register/unregister` callbacks to create/clear remembered views for the surface.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D33845685
fbshipit-source-id: 8de4204c7498176fdbe8d44fbc5f2e4079212a1c
Summary:
Adds support for platform colors in AnimatedColor.
Passes the processed native color object to the native ColorAnimatedNode via the native config; ColorAnimatedNode then uses ColorPropConverter.getColor to resolve the resource path.
Note: setting a platform color via setValue on an existing AnimatedColor is not supported yet
Changelog:
[Android][Added] - Support platform color with AnimatedColor
Reviewed By: yungsters
Differential Revision: D33922266
fbshipit-source-id: 04d39a5ce0872b31d06ffbd4639d2f2213cf3314
Summary:
D33740360 (https://github.com/facebook/react-native/commit/16ed62a850dd81bd9cc7f77ab3e77f42ed64b177) broke Explore VR on React Native. The app would go into a loop on boot and not finish mounting. This is probably a product code issue, but it's not a trivial issue to solve. Unlanding to unblock the RN migration.
Changelog:
[internal] internal
Reviewed By: mdvacca
Differential Revision: D33918026
fbshipit-source-id: cc77c70ece9994d82c91f7ae8783e959629e9cfb
Summary:
Fixes a potential crash was introduced by https://github.com/facebook/react-native/issues/30919 that aimed to get the keyboard height on devices with a Notch. The problem is that it considers that any ReactRootView will have an insets available.
When using [react-native-navigation](https://github.com/wix/react-native-navigation) and assigning a Navigation button to the TopBar as a component, the component gets registered as a RootView but won't have any insets attach to the view.
[getRootWindowInsets()](https://developer.android.com/reference/android/view/View#getRootWindowInsets()) in fact return a `WindowInset` only available if the view is attached, so when executing `checkForKeyboardEvents` method from ReactRootView, is trying to access the `DisplayCutout` of a null object, leading to a crash.
## Changelog
[Android] [Fixed] - Fix potential crash if ReactRootView does not have insets attached.
Pull Request resolved: https://github.com/facebook/react-native/pull/32989
Test Plan:
Without the code change: Notice how the second screen being push contains a React Component on the top right of the navigation bar, and when component is unmounted (going back) the app crashes.
https://user-images.githubusercontent.com/6757047/151558235-39b9a8b5-be73-4c31-8053-02ce188637b8.mp4
crash log
```
2022-01-28 10:27:52.902 15600-15600/com.mattermost.rnbeta E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.mattermost.rnbeta, PID: 15600
java.lang.NullPointerException: Attempt to invoke virtual method 'android.view.DisplayCutout android.view.WindowInsets.getDisplayCutout()' on a null object reference
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.checkForKeyboardEvents(ReactRootView.java:778)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.onGlobalLayout(ReactRootView.java:769)
at android.view.ViewTreeObserver.dispatchOnGlobalLayout(ViewTreeObserver.java:1061)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:3214)
at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2143)
at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:8665)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1037)
at android.view.Choreographer.doCallbacks(Choreographer.java:845)
at android.view.Choreographer.doFrame(Choreographer.java:780)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1022)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loopOnce(Looper.java:201)
at android.os.Looper.loop(Looper.java:288)
at android.app.ActivityThread.main(ActivityThread.java:7839)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)
```
After applying the patch which is only a null check validation and does not change any previous behavior
https://user-images.githubusercontent.com/6757047/151558429-9ff1a608-abb6-4168-8db9-df0c3c71d79e.mp4
Reviewed By: cortinico
Differential Revision: D33844955
Pulled By: ShikaSD
fbshipit-source-id: ed5579ad3afeed009c61cc1851eee45c70087cf5
Summary:
Adds support for Animated.Color with native driver for Android. Reads the native config for the rbga channel AnimatedNodes, and on update(), converts the values into an integer (0xaarrggbb)
Followup changes will include support for iOS and platform colors.
Changelog:
[Android][Added] - Support running animations with AnimatedColor with native driver
Reviewed By: javache
Differential Revision: D33833600
fbshipit-source-id: 2bf05c9715b603cf014ace09e9308b2bfd67f30a
Summary:
Changelog: [Internal]
Remove all the MCs that enable SVCs in Fabric, because we'll only test SVCs in Bridgeless mode to simplify rollout. There were complications with enabling SVCs in Fabric at a previous rollout.
Reviewed By: RSNara
Differential Revision: D33861243
fbshipit-source-id: fdbfedce77f8bd1bab2a807237017787ae8bf7c1
Summary:
when migrated to `maven-publish` in https://github.com/facebook/react-native/issues/31611, the sources jar is not included by default from `maven-publish`. so react-native 0.66 / 0.67 doesn't include sources jar in npm published artifacts. it's not ideal for debug or tracing code.
this pr added the sources jar into the published artifact.
## Changelog
[Android] [Fixed] - Add missing sources jar into published android artifacts
Pull Request resolved: https://github.com/facebook/react-native/pull/32982
Test Plan:
make sure sources jar is included in artifact.
```
$ ./gradlew :ReactAndroid:installArchives
$ find android -name '*sources.jar*'
```
Reviewed By: ShikaSD
Differential Revision: D33842979
Pulled By: cortinico
fbshipit-source-id: f99ad46ce0cca0cfc2ab1d5c5a4fcb40a02683e7
Alfonso Curbelo
David Vacca
Pieter De Baets
Genki Kondo
fabriziobertoglio1987
Kunal Farmah
Dark Knight
Paige Sun
Joshua Gross
Gabriel Donadel Dall'Agnol
Ian Childs
Samuel Susla
Andrei Shikov
Kuba Holuj
Xin Chen
Hamid
Aniket Mathur
Nicola Corti
John Porto
Felipe Perez
Keshav Kolur
Elias Nahum
Kudo Chien
