Summary:
Currently any component using `Pressability` is quickly tapped and released (i.e. responder grant followed only by reponder release), we fire `onPressIn` and `onPressOut` immediately to ensure that any visual feedback for the interactive element is momentarily visible.
Currently, we were mistakenly skipping this logic if `onPress` was null.
This fixes it so that we fire `onPressIn` and `onPressOut` consistently, even if `onPress` is null.
Changelog:
[General][Fixed] - Pressability now consistently fires `onPressIn` and `onPressOut`, even without an `onPress`.
Reviewed By: lunaleaps
Differential Revision: D23613254
fbshipit-source-id: e316707cbb2a4814262dea4eb1ddf6e3780268d1
Summary:
Adds a new `unstable_pressDelay` prop to `Pressable`.
This is intended to be used to experiment with adding a delay for when `onPressIn` fires. The intended purpose of this delay is to prevent `Pressable` elements from activating (i.e. `onPressIn` firing) if a touch gesture is immediately canceled by an enclosing native component (e.g. `ScrollView`).
Changelog:
[General][Added] - Added `unstable_pressDelay` prop to `Pressable`.
Reviewed By: lunaleaps
Differential Revision: D23604581
fbshipit-source-id: 5ce5d15a996c8a7aabaa465aa02fa8bad1044227
Summary:
Removes the default press delay from `Pressability`, which was introduced in 0.63 and affected `Pressable`. Fixes#29376.
In a subsequent commit, I will bring it back as an `unstable_pressDelay` prop.
Changelog:
[General][Changed] - Removed default 130ms delay from Pressability and Pressable.
Reviewed By: lunaleaps
Differential Revision: D23604582
fbshipit-source-id: c21c72bf8b59fed028f5905ca4f805bb3fa79399
Summary:
With the upgrade to React Native 0.63, we started running into nullability warnings that were breaking our build. This PR fixes those nullability warnings as well as a few other warnings in React-Core.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fixed] - Fix xcodebuild warnings in React-Core
Pull Request resolved: https://github.com/facebook/react-native/pull/29622
Test Plan:
- Nullability annotations should only affect compilation, but even though RNTester compiles, I'm not fully convinced that this won't break projects downstream. It would be good to get another opinion on this.
- The change in `RCTAllocateRootViewTag` is the only real logic change in this PR. We throw an exception if the root view tag is not in the correct format, so this change seems safe after some basic manual testing in RNTester.
Reviewed By: shergin
Differential Revision: D23386678
Pulled By: appden
fbshipit-source-id: a74875195a4614c3248e8f968aa98602e3ee2de0
Summary:
Introduces support for `onPressIn` and `onPressOut` on the `TextInput` component.
This makes it possible to add visual feedback when users touch interact with `TextInput` components.
Changelog:
[General][Added] - TextInput now supports `onPressIn` and `onPressOut`.
Reviewed By: TheSavior
Differential Revision: D23514333
fbshipit-source-id: 1790e977b78f1c293d5476aef8613547f27d6731
Summary:
Fixes iOS builds failing with the following error in certain setups:
```
/~/Pods/React-RCTBlob/Libraries/Blob/RCTBlobPlugins.mm:14:9: fatal error: 'RCTBlobPlugins.h' file not found
#import "RCTBlobPlugins.h"
^~~~~~~~~~~~~~~~~~
1 error generated.
```
## 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
-->
[iOS] [Fixed] - "'RCTBlobPlugins.h' file not found" when building iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/29684
Test Plan:
- Existing builds should not fail
- Tested this change internally where we are seeing this build failure
cc hramos
Reviewed By: fkgozali
Differential Revision: D23581090
Pulled By: appden
fbshipit-source-id: 89d2088c362bfbd22df5cd098b110a43d76e784f
Summary:
This argument for the `onResponderGrant` event callback on `Text` is extraneous.
Changelog:
[General][Fixed] - Remove extraneous argument for `onResponderGrant` Flow type on `Text`.
Reviewed By: TheSavior
Differential Revision: D23513190
fbshipit-source-id: c4057cf534f4cdf73967e4324db64acc8cf323d0
Summary:
Replaces the `listeners()` method on `EventEmitter` with a `listenerCount()` method.
Changelog:
[General][Removed] - Removed `listeners()` from `DeviceEventEmitter` and `NativeEventEmitter`.
[General][Added] - Added `listenerCount()` to `DeviceEventEmitter` and `NativeEventEmitter`.
Reviewed By: cpojer
Differential Revision: D22204156
fbshipit-source-id: 15029525aeef55de9934a4f319910e666ecbe1d8
Summary: Changelog: [Changed] Used scoped performance logger to mark the beginning and end of the call to the renderer, instead of using `GlobalPerformanceLogger`.
Reviewed By: lunaleaps
Differential Revision: D23240784
fbshipit-source-id: 7099f1a4b5da3f29596fcee289a715d295ae0a65
Summary:
This type makes more sense as an interface, given a class would be a common implementation (and object types aren't supported in that case).
It also adds the names of the parameters so it's easier to understand for implementers.
Changelog:
[General][Changed] - Changed type definition of IPerformanceLogger from object to interface
Reviewed By: lunaleaps
Differential Revision: D23449816
fbshipit-source-id: be872748827b123587f3f397da20f5545b0aae07
Summary:
After monitoring scuba for a few days, previous fixes(D23301714 D23331828 (https://github.com/facebook/react-native/commit/07a597ad185c8c31ac38bdd4d022b0b880d02859)) don't work as expected.
I managed to test this issue on a Xiaomi device, the crash didn't happen but the there was a popup "Frequetly used email" on top of email edit text:
{F317216473}
Getting rid of the popup probably be the right fix.
For more context see https://github.com/facebook/react-native/issues/27204
Changelog: [Android] - Set caretHidden to true to fix the Xiaomi crash
Reviewed By: mdvacca
Differential Revision: D23451929
fbshipit-source-id: 521931422f3a46a056a9faa4b10fe93cf4732db0
Summary:
Fixes https://github.com/microsoft/react-native-windows/issues/5867
ScrollResponder has logic so that the first tap exiting out of a soft keyboard is captured instead of leaking to its children. This state is checked by testing if `TextInputState.currentlyFocusedInput()` is non-null. This also fires in cases a soft keyboard is not present (e.g. on Desktop where a physical keyboard is in use). This presents to users as clicks/taps not being registered when moving from a TextInput to something esle.
Instead of checking TextInputState to see if the softKeyboard is open, check `this.keyboardWillOpenTo`, which is tied to keyboard open and close events.
## Changelog
[General] [Fixed] - Prevent ScrollView From Stealing Responder Capture When Using Physical Keyboard
Pull Request resolved: https://github.com/facebook/react-native/pull/29798
Test Plan: Validated that on react-native-windows, ScrollView will capture responder events when tapped and a soft-keyboard is open, but will not capture events when clicking from a TextView to a child of a ScrollView and no soft keyboard is open.
Reviewed By: kacieb
Differential Revision: D23426786
Pulled By: TheSavior
fbshipit-source-id: 7138ef0bc4508aaec5531f455b022b105b5d858a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/29800
I changed this line in D23272735 (https://github.com/facebook/react-native/commit/700960c9f1a27a12d703b4f0a17673690799f019), to conform to normal ObjC semantics: impl files can import their header by file name.
I forgot that their's some special linking logic happening in this directory that doesn't allow for this import type.
This diff just reverts one line to fix CircleCI builds.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23399893
fbshipit-source-id: 976199c659522effd632aaeb38616d0d6c962f1f
Summary:
Removes `fbjs` dependency from `react-native` because it is no longer referenced.
Changelog:
[General][Changed] - Removed `fbjs` dependency from `react-native`.
Reviewed By: cpojer
Differential Revision: D23358201
fbshipit-source-id: 1945590d2e7ea853434c716a151fc1058718d471
Summary:
Long term fix in native for Error: android_crash:java.lang.NullPointerException:android.widget.Editor$SelectionModifierCursorController.access$300
For more detail please see T68183343 D23301714
Changelog:
[Android][Changed] - Fix Xiaomi TextInput crash in native
Reviewed By: mdvacca
Differential Revision: D23331828
fbshipit-source-id: 914f2d431772f49711b940d47a2b3ef57ab82cdc
Summary:
Cleans up the documentation and types for `ImageSource`.
The only material changes here are:
- `ImageSource`'s array variant will now be `$ReadOnlyArray` instead of `Array`.
- `ImageURISource.headers` is now an object of string properties.
Changelog:
[General][Changed] - Refined `ImageSource` Flow type for array-variant and headers.
Reviewed By: kacieb
Differential Revision: D23355812
fbshipit-source-id: c3407db037dfb1d3514a028d1a237eb76ee6fedd
Summary:
We disabled animations on Android because native driver animations weren't working yet. After recent changes in NativeAnimatedModule, animations are now working as expected. This diff re-enables animations for bridgeless mode on Android.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22605612
fbshipit-source-id: 7a7078bf23bb88e7745fc899e1a5ff551425dbad
Summary:
Microsoft’s RN for macOS fork supports the Hermes engine nowadays https://github.com/microsoft/react-native-macos/pull/473. As a longer term work item, we’ve started moving bits that are not invasive for iOS but _are_ a maintenance burden on us—mostly when merging—upstream. Seeing as this one is a recent addition, it seemed like a good candidate to start with.
As to the actual changes, these include:
* Sharing Android’s Hermes executor with the objc side of the codebase.
* Adding a CocoaPods subspec to build the Hermes inspector source and its dependencies (`Folly/Futures`, `libevent`).
* Adding the bits to the Xcode build phase script that creates the JS bundle for release builds to compile Hermes bytecode and source-maps…
* …coincidentally it turns out that the Xcode build phase script did _not_ by default output source-maps for iOS, which is now fixed too.
All of the Hermes bits are automatically enabled, on macOS, when providing the `hermes-engine-darwin` [npm package](https://www.npmjs.com/package/hermes-engine-darwin) and enabling the Hermes pods.
## Changelog
[General] [Added] - Upstream RN macOS Hermes integration bits
Pull Request resolved: https://github.com/facebook/react-native/pull/29748
Test Plan:
Building RNTester for iOS and Android still works as before.
To test the actual changes themselves, you’ll have to use the macOS target in RNTester in the macOS fork, or create a new application from `master`:
<img width="812" alt="Screenshot 2020-08-18 at 16 55 06" src="https://user-images.githubusercontent.com/2320/90547606-160f6480-e18c-11ea-9a98-edbbaa755800.png">
Reviewed By: TheSavior
Differential Revision: D23304618
Pulled By: fkgozali
fbshipit-source-id: 4ef0e0f60d909f3c59f9cfc87c667189df656a3b
Summary:
I noticed when porting my iOS app to macOS via Catalyst that the text rendering was somewhat different on the two platforms. Text looked blurry and over-weight on macOS, even when disabling the Catalyst scaling transform.
I hazily remembered that I'd seen this problem before in my old Cocoa development days: this kind of blurring occurs when rendering text with sub-pixel anti-aliasing into an offscreen buffer which will then be traditionally composited, because when the SPAA algorithm attempts to blend with the underlying content (i.e. in the offscreen buffer), there isn't any. SPAA is disabled on iOS, so the issue wouldn't appear there. On macOS, typical approachs to displaying text (e.g. `CATextLayer`) normally disable SPAA, since it's been incompatible with the platform's compositing strategy since the transition to layer-backed views some years ago. But React Native uses `NSLayoutManager` to rasterize text (rather than relying on the system render server via `CATextLayer`), and that class doesn't touch the context's font smoothing bit before drawing.
This change makes macOS/Catalyst text rendering consistent with iOS text rendering by disabling SPAA.
It appears that the code I've modified is in the process of being refactored (for Fabric?). It looks like [this](https://github.com/facebook/react-native/blob/8d6b41e9bcede07fb627d57cf6c11050ae590d57/ReactCommon/react/renderer/textlayoutmanager/platform/ios/RCTTextLayoutManager.mm#L111) is the corresponding place in the new code (sammy-SC, is that right?). I'm happy to include a change to the new renderer in this patch if someone can point me at how to test that change.
## Changelog
[iOS] [Fixed] - Improved text rendering on macOS Catalyst
Pull Request resolved: https://github.com/facebook/react-native/pull/29609
Test Plan:
1. Prepare RNTester for running on macOS (or apply [this patch](https://gist.github.com/andymatuschak/d0f5b4fc1a28efc4f860801aa1deddcd) to handle parts 1 and 2, but you'll still need to do part 3):
1. Open the workspace, navigate to the `RNTester` target's configuration, and check the "Mac" checkbox under "Deployment Info.
2. Flipper doesn't yet compile for Catalyst (https://github.com/facebook/react-native/issues/27845), so you must disable it by: a) commenting out `use_flipper!` and `flipper_post_install` in the Podfile, then running `pod install`; and b) removing the `FB_SONARKIT_ENABLED` preprocessor flags in the Xcode project.
3. macOS has different signing rules from iOS; you must set a development team in the "Signing & Capabilities" tab of the `RNTester` target configuration pane. Unfortunately, you must also do this in the `Pods` project for the `React-Core-AccessibilityResources` target ([this is an issue which CocoaPods must fix](https://github.com/CocoaPods/CocoaPods/issues/8891)).
2. Run RNTester with and without the patch. You'll see that the font hinting is overweight without the patch; see screenshots below (incorrect rendering above, correct rendering below; note that fonts still remain slightly blurred because of Catalyst's window scaling transform, but that's removed on Big Sur).
Reviewed By: PeteTheHeat
Differential Revision: D23344751
Pulled By: sammy-SC
fbshipit-source-id: 1bbf682b681e381a8a90e152245d9b0df8ec7697
Summary:
Deletes `Animated/polyfills` which is no longer necessary (and only creates extra configuration burden).
Changelog:
[Internal]
Reviewed By: cpojer
Differential Revision: D22451963
fbshipit-source-id: 7a9a48b96b3783f2f6340226bdafd2eaa43f32e7
Summary:
Removes the legacy `react-animated` package configuration and collapses the `Animated/src/` directory into `Animated/`.
Also, reconfigures all references to `Animated/src/` to just be `Animated/`.
Changelog:
[Internal]
Reviewed By: cpojer
Differential Revision: D22450848
fbshipit-source-id: 9fd4861e9f357d817d82e9fec71967a2936a3830
Summary:
Replaces `fbjs/warning` call sites in React Native with `console.warn`. A few warnings will now log as warnings without the "Warning:" prefix.
Changelog:
[General][Changed] - Some warnings changed to use `console.warn` without the "Warning:" prefix.
Reviewed By: TheSavior, cpojer
Differential Revision: D22445946
fbshipit-source-id: 96b01e1bdee52b89ff3b808bc9d6cd494f6787f5
Summary:
This diff ties the stack together. It completes the long chain of RCTSurfacePresenter ownership:
`FBReactModule` -> `RCTNativeAnimatedTurboModule` (this diff and D23272746)
`RCTNativeAnimatedTurboModule` -> `RCTNativeAnimatedNodesManager` (this diff)
`RCTNativeAnimatedNodesManager` -> `RCTPropsAnimatedNode` (D23272735)
It completes animations working without the bridge.
Changelog: [Internal]
Differential Revision: D23272755
fbshipit-source-id: 137f7ff89993a2cb644bd67869eb685afcec4068
Summary:
`RCTPropsAnimatedNode` uses the bridge to access it's current surface presenter to perform animations.
In bridgeless mode, the surface presenter is not owned by the bridge. Instead, pass the surface presenter through the ownership chain:
`RCTNativeAnimated*Module` -> `RCTNativeAnimatedNodesManager` -> `RCTPropsAnimatedNode`
`RCTSurfacePresenter` should not be strongly held by any of these animation internals. If it gets destroyed at a higher level, animations should not be completed.
Changelog: [Internal]
Differential Revision: D23272735
fbshipit-source-id: ce08ee3b59ac2ba70e31cebb7ba8e9f3a644c848
Summary:
The animated native module relies on `setBridge` to perform generic setup which doesn't rely on the bridge at all. This diff refactors that setup code to an `init` function.
Changelog: [Internal]
Differential Revision: D23272427
fbshipit-source-id: 0c9c5522c9044283f4db25360010465ff42aba25
Summary:
Extracts `ScrollViewContext` so that other components can use it without requiring `ScrollView` as a dependency.
Changelog:
[Internal]
Reviewed By: kacieb
Differential Revision: D22670035
fbshipit-source-id: 7f902697ad2a60cd1869438e9a2b77e479a18065
Summary:
This is the JS side of D23010844 (https://github.com/facebook/react-native/commit/73242b45a9f7f9ecce8f5124ac3d1665f575be74).
In the past I tried a few heuristics to guess when a batch of Animated Operations were ready, and none of these were super reliable. But it turns out we can safely allow JS to manage that explicitly.
Non-Fabric still uses the old behavior which seems fine.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23010937
fbshipit-source-id: 4a513672c166ceaa8b6daa387e46a2a95b60ce53
Summary:
Every single RN iOS application is initializing this native module on first bundle load, regardless if it is used or not. This wrapperModule makes it lazy.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D23175668
fbshipit-source-id: 0424a62d6c0b4fe7d5ce95f6c96e641a03b5fb2c
Summary:
Migrating DrawerLayoutAndroid component to use ES6 import
Slowly migrate each file to use es6 import/exports to make this discussion happen
react-native-community/discussions-and-proposals#201 (comment)
## Changelog
[General] [Changed] - Use ES6 import/export syntax for DrawerLayoutAndroid component
Pull Request resolved: https://github.com/facebook/react-native/pull/29639
Test Plan: Manual RNTester for Android
Reviewed By: TheSavior
Differential Revision: D23110137
Pulled By: mdvacca
fbshipit-source-id: a43b4f3981335c9f532185cec8957e46f35aac7b
Summary:
This diff fixes an issue in `TextInput` where `TextInputState.currentlyFocusedInputRef` could maintain a ref to a view that no longer exists. This issue was exposed when upgrading React, where cleanups for passive effects are deferred. This change means that `inputRef.current` would no longer reference the host view *to be* destroyed; it would be null because the view was *already destroyed*.
There are two fixes here that would independently fix the bug and fix the issue better together.
First, we convert `useEffect` to `useLayoutEffect`. `useLayoutEffect` is intended to fire synchronously after all host view mutations, and the cleanup function is intended to fire synchronously before the host view is destroyed, similar to the behavior assumed before. This change is now the correct function to use semantically. However, if we made this change without the second then any change in the order the effects fire would surface the same bug.
So second, move the `inputRefValue).blur()` call to the same effect as unregistering. This is because we currently require the `blur` effect to be called to null out `currentlyFocusedInputRef` in addition to calling `unregisterInput`. That makes the semantic ordering of effects in `TextInput` meaningful. Instead, when a TextInput is unregistered we should always `blur` to clear the `currentlyFocusedInputRef`, which will prevent dispatching events to a view that doesn't exist. If we made this change without the first then there's would be a race condition between calling blur on a TextInput and when that TextInput has been unregistered.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D23035358
fbshipit-source-id: ab686b8046d85e2becd8b879b0b4b7e69e672754
Summary:
Motivation:
`Invariant Violation: Module AppRegistry is not a registered callable module (calling runApplication).` is an error that happens rarely, and most SO answers end up recommending to use `react-native bundle` to work around. I stumbled upon this error the other day and it took me a while to figure out that the error was caused by the fact that my `entryFile` path was pointing to an existing but invalid file. I figured it would be nice to mention this because I believe this will be a frequent cause of the error.
## 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] [Changed] - improve "not a registered callable module error message"
Pull Request resolved: https://github.com/facebook/react-native/pull/28913
Test Plan:
tested locally with RNTester, prints
```
[Sun May 17 2020 18:15:55.396] ERROR Invariant Violation: Module AppRegistry is not a registered callable module (calling runApplication). This can happen when the application entry file path is incorrect.
On Android, verify 'getJSMainModuleName()' in 'MainApplication.java' and 'project.ext.react.entryFile' in 'android/app/build.gradle'.
On iOS, verify '- (NSURL *)sourceURLForBridge:(RCTBridge *)bridge' in 'AppDelegate.m' and 'ENTRY_FILE' env. variable passed to 'react-native-xcode.sh' (if any) in 'Build Phases' -> 'Bundle React Native code and images'.
```
in metro logs
Reviewed By: mdvacca
Differential Revision: D23107228
Pulled By: fkgozali
fbshipit-source-id: 0712ed7e593ba96b041578bafdbefcd09a3994b7
Summary:
Previously `reset` was not doing anything about configured callbacks, and after unmount (especially in Fabric) it was possible for callbacks to be called on unmounted nodes due to race conditions.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D23041046
fbshipit-source-id: eb9ebc8e99a0d244a2033e97178bf8ede8b5c7b2
Summary:
In D22801173 (https://github.com/facebook/react-native/commit/9e6ba9ddb8608d4e3a4a80d0138600130b766d4c) I introduced a mechanism to queue Animated operations on the JS side until all mounting effects were finished. I also added an unnecessary check that the NativeAnimated module is loaded, and it seems like if it's called too early, before the NM is initialized, it will crash.
It's not necessary in these two methods, so we just delete the invariant check.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D23040331
fbshipit-source-id: e70ec887695b9abefa0f01408a4a1c2749946d1c
Summary:
In the past I tried a few heuristics to guess when a batch of Animated Operations were ready, and none of these were super reliable. But it turns out we can safely allow JS to manage that explicitly.
Non-Fabric still uses the old behavior which seems fine.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23010844
fbshipit-source-id: 4c688d3a61460118557a4971e549ec7457f3eb8f
Tim Yung
Jayme Deffenbaugh
Tommy Nguyen
Rubén Norte
Rick Hanlon
Lulu Wu
Emily Janzer
Nick Gerleman
Peter Argany
Agastya Darma
Eloy Durán
Luna Wei
Andy Matuschak
Jordan Brown
Joshua Gross
David Vacca
Vojtech Novak
Christoph Nakazawa
Samuel Susla
