Summary:
The current implementation of `Pressability` has a bug related to `onLongPress`.
When a user starts a press gesture, we keep track of the activation position (occurs after waiting `delayPressIn` milliseconds). If the touch moves away from that position by more than 10dp, we rule out the long press gesture. This means no matter how long you hold down the press, even if you move it back to within 10dp, we will not fire `onLongPress`.
However, there is currently a bug where we never reset the cached activation position. This means that after the first press gesture, all subsequent long press gestures must start within 10dp of that first press gesture. This leads to seemingly intermittent missing long press gestures.
This fixes the bug by ensuring that whenever a press gestures is terminated (either via a cancel or release), we reset the activation position.
Changelog:
[General][Fixed] - Fixed Pressability to properly fire `onLongPress`.
Reviewed By: TheSavior
Differential Revision: D20410075
fbshipit-source-id: e4727b7a9585ce3ea39481fc13e56b6b91740c8c
Summary:
Upgrades Flipper to 0.33.1 for both the Android template and RNTester.
## Changelog
[Android] [Changed] - Upgrade Flipper dependency to 0.33.1
Pull Request resolved: https://github.com/facebook/react-native/pull/28275
Test Plan: Still trying to figure out how to get my Gradle setup working again. Until then, CI.
Reviewed By: cpojer, mweststrate
Differential Revision: D20369480
Pulled By: TheSavior
fbshipit-source-id: 048c944819168a352214349f6a83407a587479c9
Summary:
A previous PR broke toggling between visible and non-visible password (basically once a password field was made visible, future updates to the keyboardType were effectively ignored, so the password would always be visible).
Original PR: https://github.com/facebook/react-native/pull/27523
Changelog: [Internal]
Reviewed By: mdvacca, rodrigos-facebook
Differential Revision: D19527245
fbshipit-source-id: a5ab343c8a0c6a608171dbfa5afc7536ff241826
Summary:
Adding `xcscheme` files for iOS template back in. They were removed in https://github.com/facebook/react-native/issues/26471 after https://github.com/facebook/react-native/issues/25451. We have reverted the change on `.gitignore`, as this directory is supposed to be in git, but we didn't revert the removed files. Now they are back as well.
You can also see here that the two files are still missing, they got removed on rc.0 and are still missing on rc.3.
https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.0-rc.3
## Changelog
[iOS] [Changed] - Add `xcscheme` files for iOS template back in.
Pull Request resolved: https://github.com/facebook/react-native/pull/28198
Test Plan: `init` a nre project, and check if the files are there or not. The paths are `ios/MyApp.xcodeproj/xcshareddata/xcschemes/MyApp.xcscheme` and `ios/MyApp.xcodeproj/xcshareddata/xcschemes/MyApp-tvOS.xcscheme`
Reviewed By: cpojer
Differential Revision: D20179447
Pulled By: TheSavior
fbshipit-source-id: b0f08c0f32d6bb7630179bc2fe46d9ac10f6c1d7
Summary:
We are currently unintentionally including both libhermes-executor-release.so
and libhermes-executor-debug.so in all OSS RN builds.
RN tries both in turn, but since they both exist and the release executor is compatible
with the debug build, we always get the release executor without debug functionality.
While we sort this out, switch the load order. Since the debug executor is not compatible
with the release build, so it'll fail to load and try the next one.
ChangeLog: [Android] Fix Hermes debugger being disabled by default
Reviewed By: mhorowitz
Differential Revision: D20163828
fbshipit-source-id: ee4d87f40e42a7c8eedfdb7e1fc17eb3e5966ba5
Summary:
This diff changes the behavior of UIImplementation.resolveViewManager() to return null instead of throwing an exception when trying to find an unexistent viewManager during the computation of constants for view Managers.
The C++/JS code manages exceptions and null results when a view manager doesn't exists, this diff simplifies the way this method operates.
changeLog: [internal]
Reviewed By: rickhanlonii
Differential Revision: D19624423
fbshipit-source-id: df31dcfae9a588bf325b61d529cec6ead59fb19d
Summary:
Fix for https://github.com/facebook/react-native/issues/27510.
Setting the `InputType.TYPE_CLASS_TEXT` flag when `keyboardType` is null or default breaks autoCapitalize. Handle the case when `keyboardType` is null, default, or invalid type.
## Changelog
[Android] [Fixed] - Fix setting keyboardType from breaking autoCapitalize
Pull Request resolved: https://github.com/facebook/react-native/pull/27523
Test Plan:
Added keyboardType prop to RNTester as so
```
<TextInput autoCapitalize="words" keyboardType="default" style={styles.default} />
```

Reviewed By: makovkastar
Differential Revision: D19132261
Pulled By: JoshuaGross
fbshipit-source-id: be66f0317ed305425ebcff32046ad4bff06d367f
Summary:
Use the latest published release of hermes-engine.
Changelog: [Android] [Changed] - Upgraded to Hermes 0.4.0
Reviewed By: mhorowitz
Differential Revision: D19866355
fbshipit-source-id: be2bed957bc034d3e6107804229abc2d83e40d40
Summary:
Resolve React-RCTText warning: `'UIKeyboardTypeASCIICapableNumberPad' is only available on iOS 10.0 or newer`
## Changelog
[iOS] [Fixed] - Resolve React-RCTText Xcode warning
Pull Request resolved: https://github.com/facebook/react-native/pull/28054
Test Plan: Build template, React-RCTText should no longer throw a warning.
Differential Revision: D19887063
Pulled By: hramos
fbshipit-source-id: 3437ee993babd7cdaec259af24526e197acb64bb
Summary:
This implement the autoFocus functionality natively instead of calling the focus method from JS on mount. This is needed to properly fix the issue described in https://github.com/facebook/react-native/issues/27217, where when using native navigation (UINavigationController) text input focus needs to happen in the same frame transition starts or it leads to an animation bug in UIKit.
My previous attempt fixed the problem only partially and the bug could still happen since there is no guaranty code executed in useEffect will end up in the same frame as the native view being created and attached.
To fix this I added an autoFocus prop to the native component on iOS and in didAttachToWindow we focus the input if it is set. This makes sure the focus is set in the same frame as the view hierarchy containing the input is created.
## Changelog
[iOS] [Fixed] - Add native support for TextInput autoFocus on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/27803
Test Plan:
- Tested that the UI glitch when transitionning to a screen with an input with autofocus no longer happens in my app.
- Tested that autofocus still works in RNTester
- Made sure that onFocus does get called and TextInputState is updated properly
Differential Revision: D19673369
Pulled By: TheSavior
fbshipit-source-id: 14d8486ac635901622ca667c0e61c75fb446e493
Summary:
When I was testing React Native 0.62-rc.1, I noticed that console was showing a warning for Require Cycle as shown in image below

This is because ScrollResponder was importing `ScrollView` to get the `typeof ScrollView`.
I've made an export for ScrollView type in `ScrollView` so that Require cycle warning will not show up.
## Changelog
[General] [Fixed] - Remove Require cycle warning.
Pull Request resolved: https://github.com/facebook/react-native/pull/27851
Differential Revision: D19577644
Pulled By: cpojer
fbshipit-source-id: 257b9421a91244d69394375102cfbe683326bba2
Summary:
Files that are inside `xcshareddata` are meant to be "shared", and that means committed to git. These files are for example `ios/RnDiffApp.xcodeproj/xcshareddata/xcschemes/RnDiffApp.xcscheme`, and if ignored that means they are removed from the repo or are missing when cloning. These should be present. They are the shared schemes so Xcode knows what and how to build, on everyone's machine.
I noticed it being there in a new project on 0.62.0-rc.0.
## Changelog
[iOS] [Changed] - Remove the xcshareddata from .gitignore
Pull Request resolved: https://github.com/facebook/react-native/pull/27563
Differential Revision: D19166364
Pulled By: TheSavior
fbshipit-source-id: 0377dc5b08ba04d121f9ed5e4027942a7a9f463f
Summary: This diff reverts the iOS LogBox module back to the UIWindow strategy used by Redbox.
Reviewed By: sammy-SC
Differential Revision: D19941390
fbshipit-source-id: 4aea09137ea9e8bfc166a733272647a79102bf35
Summary:
Moves the LogBox images from base64 data to files since base64 is not supported everywhere.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D19879323
fbshipit-source-id: 2dc03eebfc712ed863ed76322e133fcad5b00bb4
Summary:
This adds support for `adjustsFontSizeToFit` and `minimumFontScale` on Android. The implementation tries to match closely the behaviour on iOS (hardcoded 4px min size for example). It uses a simpler linear algorithm for now, opened to improving it now if it is a deal breaker or in a follow up.
See https://twitter.com/janicduplessis/status/1171147709979516929 for a more detailed thread about the implementation
## Changelog
[Android] [Added] - Implement `adjustsFontSizeToFit` on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/26389
Test Plan: Tested by adding the existing `adjustsFontSizeToFit` example from the iOS text page to android. Also added a case for limiting size by using `maxHeight` instead of `numberOfLines`.
Reviewed By: mdvacca
Differential Revision: D17285473
Pulled By: JoshuaGross
fbshipit-source-id: 43dbdb05e2d6418e9a390d11f921518bfa58e697
Summary:
Upgrading CLI to latest. This diff is intended to be cherry-picked to 0.62.
cc grabbou kelset
[Internal] [Changed] - Bump CLI to ^4.0.0
Pull Request resolved: https://github.com/facebook/react-native/pull/27976
Test Plan: None
Differential Revision: D19769017
Pulled By: cpojer
fbshipit-source-id: c3f5cd8afc0bc26372ee9f9e9dbaf4e68cdec216
Summary:
Starting on iOS 13, a View Controller presented modally will have a "bottom sheet" style unless it's explicitly presented full screen.
Before this, modals on iOS were only being dismissed programatically by setting `visible={false}`. However, now that the dismissal can happen on the OS side, we need a callback to be able to update the state.
This PR reuses the `onRequestClose` prop already available for tvOS and Android, and makes it work on iOS for this use case.
Should fix https://github.com/facebook/react-native/issues/26892
## Changelog
[iOS] [Added] - Add support for onRequestClose prop to Modal on iOS 13+
Pull Request resolved: https://github.com/facebook/react-native/pull/27618
Test Plan:
I tested this using the RNTester app with the Modal example:
1. Select any presentation style other than the full screen ones
2. Tap Present and the modal is presented
3. Swipe down on the presented modal until dismissed
4. Tap Present again and a second modal should be presented

Differential Revision: D19235758
Pulled By: shergin
fbshipit-source-id: c0f1d946c77ce8d1baab209eaef7eb64697851df
Summary:
Removing the experimental types-first flag from RN templates, until these are properly documented in the docs. See https://github.com/facebook/flow/issues/8279 for context.
Changelog: [Internal]
Reviewed By: jbrown215
Differential Revision: D19728257
fbshipit-source-id: 8f7473b9c8383bd1eef76b5733ff3a26e2e554fc
Summary:
This PR makes it possible for subclasses of `ReactTextInputShadowNode` to control the construction of the "dummy" `EditText` instance that `ReactTextInputShadowNode` internally uses to determine the expected height of the view. This PR does not change the default behavior, it just opens up that default to being overriden.
This is useful in the case of custom views that have different behavior from a "default" `EditText` instance (`new EditText(context)`). For example, it might have a different style applied.
As a side benefit, this change also makes it easy to have subclasses not apply the default theme, which can allow the custom view to avoid a longstanding crash issue (https://github.com/facebook/react-native/issues/17530).
## Changelog
[Android] [Added] - Allow overriding `EditText` construction in `ReactTextInputShadowNode`
Pull Request resolved: https://github.com/facebook/react-native/pull/27782
Test Plan: All tests pass.
Reviewed By: mdvacca
Differential Revision: D19450593
Pulled By: JoshuaGross
fbshipit-source-id: 8d2ce6117246fc3e2108623312b38583af5722b3
Summary:
In D14244606 I "fixed" `Platform.isTesting()` in JS. By fixed, I made it return true when running SSTs.
People in OSS complained about this in discord and [github](https://github.com/facebook/react-native/issues/27010). The problem is that this call returns true whenever an RN project references Detox in the build.gradle file. In practice, this has been really annoying, because it has disabled animations in debug builds, due to D13811035.
The fix is to be more specific, and look for the exact screenshot test activity. I haven't explicitly verified this doesn't trigger from Detox, but it shouldn't. I'll coordinate on the github issue to verify.
Changelog: [Android][Fixed] Fix animations in OSS debug builds by modifying `Platform.isTesting()` behaviour
Reviewed By: TheSavior
Differential Revision: D19384098
fbshipit-source-id: 22c885219f2c00f5dcc3b930b068bfd2ad7e4b8e
Summary:
react-native-cookie-store wants the ability to set custom cookies on Android. We use ForwardingCookieHandler to mange the cookies. Exposing the `addCookies` method will allow the module to provide the same functionality on Android.
https://github.com/safaiyeh/react-native-cookie-store/issues/1
## Changelog
[Android] [Changed] - Expose addCookies method
Pull Request resolved: https://github.com/facebook/react-native/pull/27512
Test Plan: N/A
Differential Revision: D19236309
Pulled By: cpojer
fbshipit-source-id: bf1a0730165456c34c5bf432ac370176a881cbcf
Summary:
In https://github.com/facebook/react-native/issues/25427, radex added initial support for running React Native projects on macOS via Catalyst. However, `RCTWebSocket` was disabled for that target because of some compilation issues. This meant that running projects via a connection to the packager wasn't possible: no live reload, and projects must be run in "Release" mode. It also meant making manual changes to Xcode projects deploying to macOS and scattering a number of conditional checks throughout the codebase.
In this change, I've implemented support for `RCTWebSocket` on the macOS target and re-enabled the affected features. Live reload and the inspector now work for macOS targets. Manual modifications of Xcode build settings are no longer necessary for react-native projects running on macOS.

### Limitations
There's no binding which displays the developer menu (since there's no shake event on macOS). We'll probably want to add one, perhaps to the menu bar.
I've chosen not to commit the modifications to RNTester which enable macOS support, since that would imply more "official" support for this target than I suspect you all would like to convey. I'm happy to add those chunks if it would be helpful.
## Changelog
[iOS] [Added] - Added web socket support for macOS (Catalyst), enabling debug builds and live reload
Pull Request resolved: https://github.com/facebook/react-native/pull/27469
Test Plan:
* Open RNTester/RNTester.xcodeproj with Xcode 11.2.1, run it like a normal iOS app -- make sure it compiles and runs correctly (no regression)
* Select "My Mac" as device target, and run. You may need to configure a valid development team to make signing work.
* RNTester should run fine with no additional configuration. Modify a file in RNTester, note that live reload is now working.
* Test the developer inspector. To display the developer menu, you'll need to manually show it; here's an example diff which does that:
```
diff --git a/RNTester/js/RNTesterApp.ios.js b/RNTester/js/RNTesterApp.ios.js
index 8245a68d12..a447ad3b1b 100644
--- a/RNTester/js/RNTesterApp.ios.js
+++ b/RNTester/js/RNTesterApp.ios.js
@@ -19,6 +19,8 @@ const React = require('react');
const SnapshotViewIOS = require('./examples/Snapshot/SnapshotViewIOS.ios');
const URIActionMap = require('./utils/URIActionMap');
+import NativeDevMenu from '../../Libraries/NativeModules/specs/NativeDevMenu';
+
const {
AppRegistry,
AsyncStorage,
@@ -143,6 +145,7 @@ class RNTesterApp extends React.Component<Props, RNTesterNavigationState> {
UNSAFE_componentWillMount() {
BackHandler.addEventListener('hardwareBackPress', this._handleBack);
+ NativeDevMenu.show();
}
componentDidMount() {
```
Reviewed By: sammy-SC
Differential Revision: D18945861
Pulled By: hramos
fbshipit-source-id: edcf02c5803742c89a845a3e5d72bc7dacae839f
Summary:
Depends on https://github.com/facebook/react-native/issues/27833.
Updates the Flipper version to the most recent release.
## Changelog
[Android] [Changed] - Upgrade Flipper version in default template
Pull Request resolved: https://github.com/facebook/react-native/pull/27837
Test Plan:
This is a bit annoying, but I can't test this against the 0.62-rc.0 version. I tried patching it by running `react-native init --version 0.62.0-rc.0 testproj`, which would fail because of a missing androidx dep. After adding `implementation 'androidx.swiperefreshlayout:swiperefreshlayout:1.0.0'` to the deps, that was fixed but now after updating, `libfbjni.so` is missing because my PR https://github.com/facebook/react-native/issues/27729 isn't part of the RN dependency yet.
Given that this mirrors the RNTester app, I'm pretty confident that the change here is otherwise correct and will work on top of master with the most recent template changes.
Differential Revision: D19619365
Pulled By: passy
fbshipit-source-id: 5723bd105ab3ab86b7f00e1a26e29e1e9dc58290
Summary:
Files that are to be part of the user’s project shouldn’t have FB copyright notices.
There’s [one notice left](https://github.com/facebook/react-native/blob/66601e755fcad10698e61d20878d52194ad0e90c/template/android/app/src/debug/java/com/helloworld/ReactNativeFlipper.java#L2) in the `android` template, which is in a file that doesn’t seem to be intended to be changed by the user and so that seems fine to me.
[iOS] [Removed] - Remove copyright notices from iOS application template
Pull Request resolved: https://github.com/facebook/react-native/pull/27725
Test Plan:
```bash
npx react-native init TestTemplateUpdates --template ~/Code/ReactNative/react-native
cd ios
xcodebuild -workspace TestTemplateUpdates.xcworkspace \
-scheme TestTemplateUpdates \
-destination 'platform=iOS Simulator,OS=latest,name=iPhone 8' build
[…]
** BUILD SUCCEEDED **
```
Differential Revision: D19343386
Pulled By: TheSavior
fbshipit-source-id: a78be5e5d2fdc2477adedb51d6bb3ff19845b75f
Summary:
When building as a framework these headers get automatically added to the framework umbrella header for React-Core. Instead of converting all the React sources to ObjC++ files and still forcing external users that build native source (and link against a framework build) to also compile as ObjC++, this makes the attribution related methods that were added in https://github.com/facebook/react-native/commit/fdcdca4 opt-in to ObjC++ builds.
This is also the reason for the current failure of the CI `test_ios_frameworks` run.
I’m unsure if this change really warrants an entry in the CHANGELOG, as it’s more of an amendment of the (afaik) unreleased [change](https://github.com/facebook/react-native/commit/fdcdca4).
[iOS] [Fixed] - Make framework builds work again by making `RCTImageLoader` C++ requirement opt-in
Pull Request resolved: https://github.com/facebook/react-native/pull/27730
Test Plan:
I tested static and dynamic (framework) builds and ran the test suite.
This change should make the `test_ios_frameworks` CI run _build_ again, ~~but it may still fail overall as in my local testing one of the tests leads to a segfault (which I will try to address separately)~~.
Reviewed By: PeteTheHeat
Differential Revision: D19348846
Pulled By: fkgozali
fbshipit-source-id: 8a74e6f7ad3ddce2cf10b080b9a5d7b399bd5fc0
Summary:
The class was deprecated in 2016 and is blocking an upgrade to fbjni
which no longer supports the `Countable` class this extends.
Changelog:
[Android] [Removed] - NativeRunnableDeprecated
Pull Request resolved: https://github.com/facebook/react-native/pull/27529
Test Plan: No references to it in this codebase.
Reviewed By: mdvacca
Differential Revision: D19087074
Pulled By: passy
fbshipit-source-id: a4ee73be7c13cedf1d86d2643f8e788ad4a2e31f
Summary:
Issue: https://github.com/facebook/react-native/issues/27565
initalizeFlipper should be set in template app by default.
## Changelog
[iOS] [Changed] - Added Flipper to template app
[Android] [Changed] - Added Flipper to template app
Pull Request resolved: https://github.com/facebook/react-native/pull/27569
Test Plan:
Connect Flipper to the iOS application
Connect Flipper to the Android application
Reviewed By: passy
Differential Revision: D19344704
Pulled By: rickhanlonii
fbshipit-source-id: ca126fd2caab13751ddc2ce6d195bd0c644c704e