Summary:
iOS will sometimes invoke the UIAlertAction handler for the cancel button more than once on iPad. This can be reproduced relatively easily by having a button that opens an action sheet and spam tapping outside the action sheet while it is opening. Since native module callbacks can only be invoked once this causes the app to crash here https://github.com/facebook/react-native/blob/main/ReactCommon/react/nativemodule/core/platform/ios/RCTTurboModule.mm#L206.
## Changelog
[iOS] [Fixed] - Fix action sheet callback invoked more than once on iPad
Pull Request resolved: https://github.com/facebook/react-native/pull/33099
Test Plan: Tested on iPad simulator to reproduce the crash and verified that this fixes it.
Reviewed By: philIip
Differential Revision: D34215327
Pulled By: ShikaSD
fbshipit-source-id: 6f406e4df737a57e6dd702dd54260aa72eab31d6
Summary: Upgrades `repo-config/package.json` to `coveralls@^3.1.1`, which removes the security vulnerability in `json-schema<0.4.0`.
Reviewed By: GijsWeterings
Differential Revision: D33961117
fbshipit-source-id: 375bd641686533d52f42adb9155dd642ae4c7cef
Summary:
Updates all dependencies in `bots/`, which also removes a security vulnerability with `websocket-extensions@<0.1.4`.
Changelog:
[Internal]
Reviewed By: GijsWeterings
Differential Revision: D33960461
fbshipit-source-id: 2d32ceba5ab09dc1bed5d6edc26a5134042dd29f
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 (be260b9f47) 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:
Pull Request resolved: https://github.com/facebook/react-native/pull/33108
The codegen config is optional and can be removed from the default package.json configuration in the template to simplify 0.68 upgrade for people who are not opted-in to the new arch.
Changelog: [Internal] - Remove optional codegenConfig field from template
Reviewed By: cortinico
Differential Revision: D34216988
fbshipit-source-id: 5c448472eed99bc112aef204c4025454171a83c5
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:
Changelog: [Internal]
# Diff Changes
- Set `RCTEnableNewArchitectureViolationReporting` to YES in app-wide Bridgeless mode.
- Rename `RCTWarnNotAllowedForNewArchitecture` to `RCTErrorNotAllowedForNewArchitecture`, and use `RCTLogError` instead of `RCTLogWarn` so the error goes to Logview.
Reviewed By: RSNara
Differential Revision: D34202682
fbshipit-source-id: 471486c65f7a42f8f11140e61ff60592dc826f61
Summary:
Changelog: [Internal]
After the diff Bridgeless and Bridge behaves the same for `RCTLogError` and `RCTLogWarn`.
Reviewed By: RSNara
Differential Revision: D34197703
fbshipit-source-id: 0645857aad609fa911df6681de9c0c251cf72a36
Summary:
Changelog: [Internal]
* Rename DummyUIManager to BridgelessUIManager
* Cleanup `RCTVirtualText` & `RCTShimmeringView` since the native changes from T107747313 are already in production, so these two will components always return a viewConfig in prod.
- `console.error` when deprecated Bridge UIManager method are being accessed.
- Make sure new BridgelessUIManager.js has the same method definition as [NativeUIManager.js](https://www.internalfb.com/code/fbsource/[e80c98b816183dcdfde1e81de01ba99aa6e30ed2]/xplat/js/react-native-github/Libraries/ReactNative/NativeUIManager.js?lines=15)
Reviewed By: RSNara
Differential Revision: D34203081
fbshipit-source-id: 99aafc2372b118d0c8cc41f7376e136dabae9bd5
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:
Before, when we called setValue with a PlatformColor, we unnecessarily called setValue on all component AnimatedValues before updateAnimatedNodeConfig.
This diff also fixes a bug where if we set a PlatformColor as the initial color, calling setValue with a non-PlatformColor would not have any effect. The fix is to reset AnimatedColor.nativeColor to null upon calling setValue.
Changelog:
[Internal] Optimize AnimatedColor when setting platform color
Reviewed By: javache
Differential Revision: D34187540
fbshipit-source-id: a0005d13f392a858d2eade912f2353f67eec1fd9
Summary:
While React Native depends on the `metro` package indirectly (via the CLI package), it depends on some secondary Metro packages directly. This diff updates those direct dependencies to use [Metro 0.68.0](https://github.com/facebook/metro/releases/tag/v0.68.0).
Changelog:
[General] Update direct Metro dependencies to 0.68.0
Reviewed By: motiz88
Differential Revision: D34108380
fbshipit-source-id: 06bddfcc16e0f715d6d120e48b37c64fda300c38
Summary:
Changes an internal call site that assumes image assets are `number`s to use the more general `ImageSource` type.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D34076216
fbshipit-source-id: dc0dc0c39982c87c21385828bb3357f9654d029f
Summary:
Adds `number` to the `ColorValue` union type.
Per our docs, React Native supports specifying colours as RGBA values packed into ints: https://reactnative.dev/docs/colors#color-ints. It looks like this case was missed in D6226807 (da047966e4) when we started typing the `StyleSheet` API with Flow.
Changelog: [General][Fixed] - Support numeric color values in StyleSheet's Flow types
Reviewed By: yungsters
Differential Revision: D34140748
fbshipit-source-id: 5bfe2995a473260926fa3c8b6926bb841615d393
Summary:
React Native has an *implicit* dev dependency on this transform via `metro-react-native-babel-transformer`. The transform replaces `Object.assign` with `babelHelpers.extend`, but `Object.assign` has been available natively since node 4.
We intend remove it from metro (https://github.com/facebook/metro/pull/745) as it's no longer needed by any supported runtime - removing RN's small dependency in advance so RN's tests won't break when we do.
Changelog:
[Internal][Changed] - Remove `babel/plugin-transform-object-assign` from jest preprocessor
Reviewed By: motiz88
Differential Revision: D34110208
fbshipit-source-id: 064f8241461fb338de1cd8b53077e8660301aa77
Summary:
Changelog:
[Internal] - Add an example to demo Animated colors with both JS and native drivers
Reviewed By: mdvacca
Differential Revision: D34153047
fbshipit-source-id: 9b61fd4e5f597b0440bed7ff1a33716e50ec34e5
Summary:
Now that animating color styles using native driver is supported on both Android and iOS, add color styles to the allowlist in NativeAnimatedHelper.
Changelog:
[General][Added] - Allow color styles to be animated using native driver
Reviewed By: mdvacca
Differential Revision: D34148038
fbshipit-source-id: c20dc149b805ec691a3936a77ab130fb4477a4c3
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:
Adds support for Animated.Color with native driver for iOS. Reads the native config for the rbga channel AnimatedNodes, and on update(), converts the values into a SharedColor.
Followup changes will include support for platform colors.
Ran update_pods: https://www.internalfb.com/intern/wiki/React_Native/Preparing_to_Ship/Open_Source_Pods/
Changelog:
[iOS][Added] - Support running animations with AnimatedColor with native driver
Reviewed By: sammy-SC
Differential Revision: D33860583
fbshipit-source-id: 990ad0f754a21e3939f2cb233bcfa793ef12eb14
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:
That's a really nit change, but when we moved the Makefile deps to be on separate
lines, we havent' done the same for the codegen. Here I'm doing it.
Changelog:
[Internal] [Changed] - Place Android.mk dependencies on separate lines for codegen
Reviewed By: ShikaSD
Differential Revision: D34144715
fbshipit-source-id: be9d5fb75b6b93c0b2bb479145053ae6f201e1fc
Summary:
This comment was out of date.
Changelog: [Internal]
Reviewed By: sshic
Differential Revision: D34113966
fbshipit-source-id: 0768baa9238736aea26e354792096fea6bb7fcdb
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 is pre-work for adding the v8 stack trace API support.
Changelog: [Internal]
Reviewed By: kodafb
Differential Revision: D34048366
fbshipit-source-id: 9d2b469767f7669cb428c61b215f193894892c03
Summary:
Changelog: [Internal]
Fixes `normalizeColor` to always return the normalized color. Previously, when normalization was delegated to `normalizeColorObject`, we would return the *original* color object, which is a bug.
Reviewed By: javache
Differential Revision: D34048595
fbshipit-source-id: 083cbe36be2311ea9cffe8ef61e6a986840aec71
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:
Changes to MapBuffer code in aaff15c...d287598 broke build for Windows. Errors included incompatible type conversions, the use of `__attribute__(__packed__)` which is only supported by GCC and Clang, and the usage of designated initializers which are only supported on C++20.
Changes here restore build on Windows.
## 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
-->
[General] [Fixed] - Fix build break on Windows with ReactCommon
Pull Request resolved: https://github.com/facebook/react-native/pull/33047
Test Plan: React Native project built on Windows and passes react-native-windows repository pipeline. These edits are currently merged into the main branch of react-native-windows.
Reviewed By: ShikaSD
Differential Revision: D34101367
Pulled By: philIip
fbshipit-source-id: 1596365c2e92f377c6375805b33de5e1c7b78e66
Janic Duplessis
Tim Yung
David Vacca
Pieter De Baets
Genki Kondo
fabriziobertoglio1987
Moti Zilberman
Andrei Shikov
Kunal Farmah
Neil Dhar
Paige Sun
Rob Hogan
Phillip Pan
Dark Knight
Samuel Susla
Joshua Gross
Gabriel Donadel Dall'Agnol
Nicola Corti
Ramanpreet Nara
Ian Childs
Kuba Holuj
John Porto
Minsik Kim
Xin Chen
Hamid
Aniket Mathur
Chiara Mooney