Summary:
On some platforms, when two inputs are in a scrollview, trying to switch focus to another textinput doesn't work and requires two taps. This is because from `_handleTouchEnd` we blur the currently focused input, even if that input had only just become focused from the same touch event. Instead, only blur when the event did not target the current textinput.
Changelog: [Android][Fixed] TextInputs may not get focused when switching inputs in a ScrollView
Reviewed By: jehartzog
Differential Revision: D40159333
fbshipit-source-id: 388f85dff5ac8f24d7e2590e887635391c52d72f
Summary:
Found and removed duplicates of the word "the" in comments.
## Changelog
[Internal] [Removed] – Removed duplicates of the word "the" in comments.
Pull Request resolved: https://github.com/facebook/react-native/pull/34807
Test Plan: Not applicable.
Reviewed By: yungsters, cipolleschi
Differential Revision: D39880587
fbshipit-source-id: b7277aa70604902929903c31ab69d4c532f2667a
Summary:
React Native's TS definitions are currently mostly stored in one monolithic file. This change splits the definitions up to correspond to the source files they came from, and are placed next to the source files. I think this should help inform, and make it easy to update the TS declarations when touching the Flow file.
I noticed as part of the change that the typings have not yet removed many APIs that were removed from RN. This is bad, since it means using the removed/non-functional API doesn't cause typechecker errors. Locating typings next to source should prevent that from being able to happen.
The organization here means individual TS declarations can declare what will be in the RN entrypoint, which is a little confusing. Seems like a good potential next refactor, beyond the literal translation I did.
Changelog:
[General][Changed] - Place TS Declarations Alongside Source Files
Reviewed By: lunaleaps, rshest
Differential Revision: D39796598
fbshipit-source-id: b36366466fd1976bdd2d4c8f7a4104a33c457a07
Summary:
Changelog: [internal]
This brings back a fix for ScrollView on iOS that we removed because we thought it was no longer necessary, but it actually is.
Reviewed By: jacdebug
Differential Revision: D39382967
fbshipit-source-id: f052b4fb899f4e60e8c530990caf07344a907c43
Summary:
Changelog: [internal]
This replaces all direct references to the `ReactNative` module (which is the Paper renderer) to `RendererProxy` which would select between Paper and Fabric correctly.
The implementation of these functions is exactly the same right now.
As per the removal of the fix for T55744311 in `ScrollView`, I verified this doesn't cause any issues in the screen where it failed before.
Reviewed By: javache
Differential Revision: D39270691
fbshipit-source-id: 03882748fe4b754b9a2c5e9d4c4f003b94ed49ef
Summary:
This replaces all direct references to `ReactNative` within the `react-native` package to use `findNodeHandle` with a reference obtained from `RendererProxy`, which will allow us to select the correct renderer.
Changelog: [internal]
Reviewed By: javache
Differential Revision: D39270689
fbshipit-source-id: a39875281ba7b7b1b00128564124b6adcacebc4d
Summary:
ScrollView has special-case logic to dismiss keyboard on tap, controlled via the `keyboardShouldPersistTaps` property. The first click does not propagate to children of the scrollview if the tap causes the keyboard to be dismissed. This behavior is motivated by a soft keyboard on phones which takes away space from the viewport.
ScrollView historically determined if a soft-keyboard was open via querying if there was a focused TextInput. This meant that clicks to a ScrollView would be eaten, even on form factors using phsyical keyboards.
A couple years ago I added https://github.com/facebook/react-native/pull/30374 to only eat clicks when keyboard events have indicated that a soft keyboard is present. I special-cased Android out of the change, because of platform issues with its reliability of keyboard events.
After D38500859 (https://github.com/facebook/react-native/commit/1e48274223ee647ac4fc2c21822b5240f3c47e4c) rolls out we can start to remove that special-casing, of devices which report "android" for Platform.OS.
Reviewed By: javache
Differential Revision: D38528887
fbshipit-source-id: a745b478b18abe4ef32cbdd8a14ca6dfdb5e738f
Summary:
If currently focused on a TextInput, clicking an item in a ScrollView takes two clicks.
This is because of `keyboardShouldPersistTaps`, which will fire despite a lack of keyboard events on Android due to special-casing.
This behavior is jarring in scenarios like VR where the soft keyboard is detached from the application. This change avoids eating taps, in this case, where a soft keyboard is open but not inset.
Reviewed By: genkikondo
Differential Revision: D38529237
fbshipit-source-id: a10c5dbf04e6288e0e9e0c805215054bc883339f
Summary:
ScrollView has special behavior when the keyboard is open, but starts listening to keyboard events on mount. This means a ScrollView mounted after the keyboard is already up (e.g. for a typeahead) is not initialized to the keyboard being up.
This change adds `Keyboard.isVisible()` and `Keyboard.metrics()` APIs to allow seeding initial keyboard metrics.
Changelog:
[General][Fixed] - Inform ScrollView of Keyboard Events Before Mount
Reviewed By: JoshuaGross, yungsters
Differential Revision: D38701976
fbshipit-source-id: 42b354718fbf5001ca4b90de0442eeab0be91e7a
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predictable.
Reviewed By: bradzacher
Differential Revision: D37388949
fbshipit-source-id: cdcbc98035ce9b6994842005ea46df42de54f9b8
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predicatable.
Reviewed By: evanyeung
Differential Revision: D37353648
fbshipit-source-id: e5a0c685ced85a8ff353d578b373f836b376bb28
Summary:
ScrollView's contentOffset prop was assumed to be iOS only, but in reality it is supported on Android as well: https://fburl.com/code/nuxpjpth
Changelog:
[General] - Move ScrollView's contentOffset to common props
Reviewed By: yungsters
Differential Revision: D36219604
fbshipit-source-id: f41679fd2ce7971a30129e0d91ae9f32b9cf756e
Summary:
Changelog:
[General][Fixed] - Improved Flow type inference in Animated `.interpolate()`
Improves the ergonomics of `.interpolate()` by allowing Flow to infer the correct type for `outputRange`. This is achieved by adding a new type parameter `OutputT` to `interpolate()` (and `Animated.Interpolation` and `InterpolationConfigType`), which Flow infers as either `number` or `string` based on usage.
Admittedly, at the call site, this is not that much safer compared to something like `outputRange: $ReadOnlyArray<number | string>`, but it does document the intent of the API a bit better and provide some downstream type safety. For example, we can now express `Animated.Number` (D35869375) more precisely by excluding string-valued interpolation nodes.
Reviewed By: javache
Differential Revision: D35869725
fbshipit-source-id: e03ec22e9b3368ee196b392af011062ac99d8bb9
Summary:
Problem:
All CellRenderers rerender every time the containing VirtualizedList is rerendered. This is due to the following:
- Lambda is created for each CellRenderer's onLayout prop on every VirtualizedList render (fixed in this diff)
- CellRenderer's parentProps prop changes on every VirtualizedList render
Changelog:
[Internal] - VirtualizedList optimization - avoid lambda creation in CellRenderer onLayout prop
Reviewed By: javache
Differential Revision: D35061321
fbshipit-source-id: ab16bda8418b692f1edb4bce87e25c34f6252b56
Summary:
This should fix the SVC === NVC check for ScrollView and AndroidHorizontalScrollView.
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D34542873
fbshipit-source-id: 7e25d3a6c1417877b64501981652d767ba2eda48
Summary:
The static ViewConfig codegen generates the static ViewConfig inside the JavaScript module [under an exported constant](https://github.com/facebook/react-native/blob/a0a2958cdac767f50084c2d5bee6cf224ffb9db3/packages/react-native-codegen/src/generators/components/GenerateViewConfigJs.js#L127-L129):
```
export const __INTERNAL_VIEW_CONFIG = VIEW_CONFIG;
export default NativeComponentRegistry.get(nativeComponentName, () => __INTERNAL_VIEW_CONFIG);
```
This exported constant allows us to build a test page that requires all components, and compares their static ViewConfigs with their native ViewConfig.
This diff makes components with hand-written static ViewConfigs also export this __INTERNAL_VIEW_CONFIG const.
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D34541868
fbshipit-source-id: f55dd3f1b161038baaf84cbbf75c1f4041c34647
Summary:
## Changelog:
[General] [Changed] Export Flow type for deceleration rate for use in other files to keep deceleration rate prop values consistently typed
Reviewed By: lunaleaps
Differential Revision: D32989199
fbshipit-source-id: 2e2fef0721de0d0eb60aaefdbb635788bfc8c1f1
Summary:
Retrying D30015799 (https://github.com/facebook/react-native/commit/6e903b07fa8e8d9b78cae0e031bb8022f7a63195) with a fix where ScrollViewNativeComponent was missing the automaticallyAdjustKeyboardInsets prop.
----- Original Summary
Currently, ScrollViews provide the prop `keyboardDismissMode` which lets you choose `"interactive"`. However when the keyboard is shown, it will be rendered above the ScrollView, potentially blocking content.
With the `automaticallyAdjustKeyboardInsets` prop the ScrollView will automatically adjust it's `contentInset`, `scrollIndicatorInsets` and `contentOffset` (scroll Y) props to push the content up so nothing gets blocked.
* The animation curve and duration of the Keyboard is exactly matched.
* The absolute position of the ScrollView is respected, so if the Keyboard only overlaps 10 pixels of the ScrollView, it will only get inset by 10 pixels.
* By respecting the absolute position on screen, this automatically makes it fully compatible with phones with notches (custom safe areas)
* By using the keyboard frame, this also works for different sized keyboards and even `<InputAccessoryView>`s
* This also supports `maintainVisibleContentPosition` and `autoscrollToTopThreshold`.
* I also fixed an issue with the `maintainVisibleContentPosition` (`autoscrollToTopThreshold`) prop(s), so they behave more reliably when `contentInset`s are applied. (This makes automatically scrolling to new items fully compatible with `automaticallyAdjustKeyboardInsets`)
## Changelog
* [iOS] [Added] - ScrollView: `automaticallyAdjustKeyboardInsets` prop: Automatically animate `contentInset`, `scrollIndicatorInsets` and `contentOffset` (scroll Y) to avoid the Keyboard. (respecting absolute position on screen and safe-areas)
* [iOS] [Fixed] - ScrollView: Respect `contentInset` when animating new items with `autoscrollToTopThreshold`, make `automaticallyAdjustKeyboardInsets` work with `autoscrollToTopThreshold` (includes vertical, vertical-inverted, horizontal and horizontal-inverted ScrollViews)
Pull Request resolved: https://github.com/facebook/react-native/pull/31402
Test Plan:
<table>
<tr>
<th>Before</th>
<th>After</th>
</tr>
<tr>
<td>
https://user-images.githubusercontent.com/15199031/115708680-9700aa80-a370-11eb-8016-e75d81a92cd7.MP4
</td>
<td>
https://user-images.githubusercontent.com/15199031/115708699-9b2cc800-a370-11eb-976f-c4010cd96d55.MP4
</td>
</table>
### "Why not just use `<KeyboardAvoidingView>`?"
<table>
<tr>
<th>Before (with <code><KeyboardAvoidingView></code>)</th>
<th>After (with <code>automaticallyAdjustKeyboardInsets</code>)</th>
</tr>
<tr>
<td>
https://user-images.githubusercontent.com/15199031/115708749-abdd3e00-a370-11eb-8e09-a27ffaef12b8.MP4
</td>
<td>
https://user-images.githubusercontent.com/15199031/115708777-b3044c00-a370-11eb-9b7a-e040ccb3ef8c.MP4
</td>
</table>
> Also notice how the `<KeyboardAvoidingView>` does not match the animation curve of the Keyboard
### Usage
```jsx
export const ChatPage = ({
flatListProps,
textInputProps
}: Props): React.ReactElement => (
<>
<FlatList
{...flatListProps}
keyboardDismissMode="interactive"
automaticallyAdjustContentInsets={false}
contentInsetAdjustmentBehavior="never"
maintainVisibleContentPosition={{ minIndexForVisible: 0, autoscrollToTopThreshold: 100 }}
automaticallyAdjustKeyboardInsets={true}
/>
<InputAccessoryView backgroundColor={colors.white}>
<ChatInput {...textInputProps} />
</InputAccessoryView>
</>
);
```
## Related Issues
* Fixes https://github.com/facebook/react-native/issues/31394
* Fixes https://github.com/facebook/react-native/issues/13073
Reviewed By: yungsters
Differential Revision: D32578661
Pulled By: sota000
fbshipit-source-id: 45985e2844275fe96304eccfd1901907dc4f9279
Summary:
Links under `reactnative.dev` that ended with `.html` lead to Page not found.
Fixed the url so that users get sent to the appropriate url.
## 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] - Fixed dead links in the comments.
Pull Request resolved: https://github.com/facebook/react-native/pull/32619
Test Plan: - Changed links are accessible
Reviewed By: lunaleaps
Differential Revision: D32528978
Pulled By: cortinico
fbshipit-source-id: e039d18188371cf5240b37049e431329e28b1b8b
Summary:
This diff runs the codemod to add type annotations to function parameters in preparation for Flow's local type inference (LTI) project. I ran the codemod over xplat/js and reverted any files that had flow errors in them. See the list of commands run to see the regeneration of various files.
Changelog:
[Internal][Changed] - Added type annotations
Reviewed By: yungsters
Differential Revision: D32075270
fbshipit-source-id: 6a9cd85aab120b4d9e690bac142a415525dbf298
Summary:
Original commit changeset: 9ccfb4b6d477 / D30015799 (https://github.com/facebook/react-native/commit/6e903b07fa8e8d9b78cae0e031bb8022f7a63195)
The diff caused a redbox/error in some products. Reverting now and will try it again.
Changelog: Backing out PR: 31402
Differential Revision: D31238961
fbshipit-source-id: b2ccd3d3ab9d7e764e41fb54d8a7e60882d1405f
Summary:
Currently, ScrollViews provide the prop `keyboardDismissMode` which lets you choose `"interactive"`. However when the keyboard is shown, it will be rendered above the ScrollView, potentially blocking content.
With the `automaticallyAdjustKeyboardInsets` prop the ScrollView will automatically adjust it's `contentInset`, `scrollIndicatorInsets` and `contentOffset` (scroll Y) props to push the content up so nothing gets blocked.
* The animation curve and duration of the Keyboard is exactly matched.
* The absolute position of the ScrollView is respected, so if the Keyboard only overlaps 10 pixels of the ScrollView, it will only get inset by 10 pixels.
* By respecting the absolute position on screen, this automatically makes it fully compatible with phones with notches (custom safe areas)
* By using the keyboard frame, this also works for different sized keyboards and even `<InputAccessoryView>`s
* This also supports `maintainVisibleContentPosition` and `autoscrollToTopThreshold`.
* I also fixed an issue with the `maintainVisibleContentPosition` (`autoscrollToTopThreshold`) prop(s), so they behave more reliably when `contentInset`s are applied. (This makes automatically scrolling to new items fully compatible with `automaticallyAdjustKeyboardInsets`)
## Changelog
* [iOS] [Added] - ScrollView: `automaticallyAdjustKeyboardInsets` prop: Automatically animate `contentInset`, `scrollIndicatorInsets` and `contentOffset` (scroll Y) to avoid the Keyboard. (respecting absolute position on screen and safe-areas)
* [iOS] [Fixed] - ScrollView: Respect `contentInset` when animating new items with `autoscrollToTopThreshold`, make `automaticallyAdjustKeyboardInsets` work with `autoscrollToTopThreshold` (includes vertical, vertical-inverted, horizontal and horizontal-inverted ScrollViews)
Pull Request resolved: https://github.com/facebook/react-native/pull/31402
Test Plan:
<table>
<tr>
<th>Before</th>
<th>After</th>
</tr>
<tr>
<td>
https://user-images.githubusercontent.com/15199031/115708680-9700aa80-a370-11eb-8016-e75d81a92cd7.MP4
</td>
<td>
https://user-images.githubusercontent.com/15199031/115708699-9b2cc800-a370-11eb-976f-c4010cd96d55.MP4
</td>
</table>
### "Why not just use `<KeyboardAvoidingView>`?"
<table>
<tr>
<th>Before (with <code><KeyboardAvoidingView></code>)</th>
<th>After (with <code>automaticallyAdjustKeyboardInsets</code>)</th>
</tr>
<tr>
<td>
https://user-images.githubusercontent.com/15199031/115708749-abdd3e00-a370-11eb-8e09-a27ffaef12b8.MP4
</td>
<td>
https://user-images.githubusercontent.com/15199031/115708777-b3044c00-a370-11eb-9b7a-e040ccb3ef8c.MP4
</td>
</table>
> Also notice how the `<KeyboardAvoidingView>` does not match the animation curve of the Keyboard
### Usage
```jsx
export const ChatPage = ({
flatListProps,
textInputProps
}: Props): React.ReactElement => (
<>
<FlatList
{...flatListProps}
keyboardDismissMode="interactive"
automaticallyAdjustContentInsets={false}
contentInsetAdjustmentBehavior="never"
maintainVisibleContentPosition={{ minIndexForVisible: 0, autoscrollToTopThreshold: 100 }}
automaticallyAdjustKeyboardInsets={true}
/>
<InputAccessoryView backgroundColor={colors.white}>
<ChatInput {...textInputProps} />
</InputAccessoryView>
</>
);
```
## Related Issues
* Fixes https://github.com/facebook/react-native/issues/31394
* Fixes https://github.com/facebook/react-native/issues/13073
Reviewed By: yungsters
Differential Revision: D30015799
Pulled By: sota000
fbshipit-source-id: 9ccfb4b6d477da192a96db4cfa07c31a2d2cefcb
Summary:
Fixes https://github.com/facebook/react-native/issues/23364
The current logic using `_isTouching` does not work because `_handleTouchCancel` is always called before scroll events begin. This means `_isTouching` is always false. To fix it I moved the logic to `_handleScrollBeginDrag` which is only called once when scroll drag beings. This accomplishes the expected behavior and is better than keeping it in onScroll where it would be called for each scroll event.
## Changelog
[Android] [Fixed] - Fix keyboardDismissMode="on-drag" on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/31943
Test Plan: Tested in an app that on-drag does not work before and works after this patch.
Reviewed By: sshic
Differential Revision: D30674276
Pulled By: yungsters
fbshipit-source-id: aa0bd605809fa01518f70fbf323c06e32c76ed1d
Summary:
Changelog:
[Internal][Changed] - revert to class component of ScrollViewStickyHeader. There is a redbox error during unmount in the functional version
Reviewed By: lunaleaps
Differential Revision: D30705974
fbshipit-source-id: b564c522b0026db0b334cc834a80bbbe9cd261e2
Summary:
iOS 13 added a new property to `UIScrollView`: `automaticallyAdjustsScrollIndicatorInsets`, which is `YES` by default. The property changes the meaning of the `scrollIndicatorInsets` property. When `YES`, any such insets are **in addition to** whatever insets would be applied by the device's safe area. When `NO`, the iOS <13 behavior is restored, which is for such insets to not account for safe area.
In other words, this effects ScrollViews that underlay the device's safe area (i.e. under the notch). When `YES`, the OS "automatically" insets the scroll indicators, when `NO` it does not.
There are two problems with the default `YES` setting:
1. It means applying `scrollIndicatorInsets` to a `ScrollView` has a different effect on iOS 13 versus iOS 12.
2. It limits developers' control over `scrollIndicatorInsets`. Since negative insets are not supported, if the insets the OS chooses are too large for your app, you cannot fix it.
Further explanation & sample code is available in issue https://github.com/facebook/react-native/issues/28140 .
This change sets the default for this property to `NO`, making the behavior consistent across iOS versions, and allowing developers full control.
## 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] [Changed] - ScrollView scrollIndicatorInsets to not automatically add safe area on iOS13+
Pull Request resolved: https://github.com/facebook/react-native/pull/29809
Test Plan:
Updated the RNTester example to explain what to expect. Also removed the `pageScreen` modal example for now as mentioned in my Github comment.
{F628636466}
Here are screenshots of the demo app (from the original bug) before (with safe area applied to insets) & after (without safe area applied to insets):
Reviewed By: p-sun
Differential Revision: D28229603
Pulled By: lunaleaps
fbshipit-source-id: 2e774ae150b1dc41680b8b7886c7ceac8808136a
Summary:
This fixes how ES modules are handled in Jest tests in the react-native codebase.
They caused some problems before because `import` statements weren't inlined as `require` calls were, so there were some errors in tests when migrating from CommonJS to ESM.
This changes the transform that Jest uses to inline import statements the same way, so we can migrate everything without issues in tests.
Changelog: [Internal]
Reviewed By: kacieb
Differential Revision: D28899692
fbshipit-source-id: 027690f57ca3b5613c261a1089c0635af76662b2
Summary:
This pre-suppresses the 153 error diff ahead of its release, since it is large.
Changelog: [Internal]
Reviewed By: mroch
Differential Revision: D28754374
fbshipit-source-id: 1806f53bc7d804644d434583a2dcd6da63d00328
Summary:
Changelog:
[General][Changed] Refactor ScrollViewStickyHeader to a functional component to remove unsafe lifecycles and mutations during render
Reviewed By: lunaleaps
Differential Revision: D28203776
fbshipit-source-id: 615c8e1cd9e9e26d25c7d02aee7e4a0bfc8ec6c3
Summary:
Changelog:
[General][Changed] Convert require statements to use import from in Libraries/Components
Reviewed By: lunaleaps
Differential Revision: D27921557
fbshipit-source-id: 3f1618455a47a56c4a090f3ececfef88476c0b8a
Summary:
This is a small cleanup to move initialization out of the `constructor` as it is unnecessary, and it is currently double initializing a few values.
Changelog:
[General][Changed] Clean up the initialization of instance variables in ScrollView
Reviewed By: nadiia
Differential Revision: D27631320
fbshipit-source-id: 762277e4993a9ce86d444ff2d9e845c93e94d1a8
Summary:
Changelog: [internal]
For React Native classic the behaviour is identical.
# Problem
`ScrollView.scrollResponderScrollNativeHandleToKeyboard` is broken in new React Native renderer. The behaviour depends on race between two events, `measureLayout` and `keyboardWillShow` event. In the new renderer, `measureLayout` always wins because it is a synchronous call, unlike in React Native classic.
To fix this we can just delay execution by wrapping it in `setTimeout`, which puts it on the back of the queue.
Reviewed By: JoshuaGross
Differential Revision: D27705883
fbshipit-source-id: 7556f86978ca3ccd2fddf1eef2435af26b54f585
Summary:
It looks like `ScrollView` still contains the remnant props for VR platform, which afaik has be discontinued a while ago (please correct me, if I'm wrong).
This PR removes `scrollBarThumbImage` prop marked as VR platform only prop from `ScrollView`.
## 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
-->
[VR] [Removed] - remove VR platform specific `scrollBarThumbImage` prop from `ScrollView`
Pull Request resolved: https://github.com/facebook/react-native/pull/31230
Test Plan: CI
Reviewed By: javache
Differential Revision: D27367267
Pulled By: PeteTheHeat
fbshipit-source-id: b76fdb0e03c443aaf87308162bf75f8683220918
Pieter De Baets
Tim Yung
Vic
Nick Gerleman
Rujin Cao
Rubén Norte
Pieter Vanderwerff
Jérémy Barbet
Genki Kondo
Evan Yeung
Moti Zilberman
Ramanpreet Nara
Andres Suarez
Amy Huyen
Marc Rousavy
Jesse Katsumata
Tim Yung
Gijs Weterings
David Vacca
Sota Ogo
Janic Duplessis
Aaron (Li Bo) Tao
Justin Huntington
Daniel Sainati
Kacie Bawiec
Samuel Susla
Luna Wei
simek
