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:
Sync the changes in `types/react-native` https://github.com/DefinitelyTyped/DefinitelyTyped/pull/62394 to here as required by lunaleaps
## Changelog
[Internal] [Added] - Sync new changes in `types/react-native`
Pull Request resolved: https://github.com/facebook/react-native/pull/34794
Test Plan: Tested in `types/__typetests__/index.tsx`
Reviewed By: cortinico
Differential Revision: D39846101
Pulled By: cortinico
fbshipit-source-id: cebe62aa97f764d9a10c8371936870c515fb9be3
Summary:
This adds support for the `verticalAlign` style attribute, mapping the already existing `textAlignVertical` attribute as requested on https://github.com/facebook/react-native/issues/34425. This PR also updates the TextExample.android on the RNTester in order to facilitate the manual QA of this.
## Changelog
[Android] [Added] - Add support for verticalAlign style
Pull Request resolved: https://github.com/facebook/react-native/pull/34567
Test Plan:
1. On Android open the RNTester app and navigate to the Text page
2. Check the text alignment through the `Text alignment` section
https://user-images.githubusercontent.com/11707729/188051914-bf15f7eb-e53f-4de5-8033-d1b572352935.mov
Reviewed By: jacdebug
Differential Revision: D39771237
Pulled By: cipolleschi
fbshipit-source-id: d2a81bec1edd8d49a0fcd36a42fea53734909739
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:
Currently, height is sometimes the only valid option for pushing `TextInput` up in the layout on Android. The problem is when switching keyboards. For instance, switching from ABC to emojis. This will trigger keyboard show events and recalculate the height for the `KeyboardAvoidingView`. Since the keyboard is still showing, the view has the height that was previously calculated and thus `frame` represents that. This means the `frame.height` has adjustments for the keyboard calculated in it, but it is used the same way as if the keyboard was not showing. This results in wrong calculation and the input showing at the incorrect place in the layout (mostly hidden under the keyboard)
This fix simply uses the previous calculation to offset `frame.height`, resulting in the correct height and smooth switching between keyboards. It's also scoped only to height mode since that's where the problem shows.
_Note: I mention android here, but it fixes it for both platforms. It's just that iOS usually works best with different behaviour so it's rarely used there._
## Changelog
[General] [Added] - Include `this.state.bottom` when calculating new keyboard height to fix android keyboard switching
Pull Request resolved: https://github.com/facebook/react-native/pull/34749
Test Plan:
With simple code:
```jsx
import { StatusBar } from "expo-status-bar";
import React from "react";
import {
KeyboardAvoidingView,
StyleSheet,
Text,
TextInput,
View,
} from "react-native";
export default function App() {
return (
<KeyboardAvoidingView style={styles.container} behavior="height">
<Text>Open up App.js to start working on your app!</Text>
<StatusBar style="auto" />
<TextInput style={{ backgroundColor: "red", width: "100%" }} />
</KeyboardAvoidingView>
);
}
const styles = StyleSheet.create({
container: {
padding: 32,
flex: 1,
backgroundColor: "#fff",
alignItems: "center",
justifyContent: "space-between",
},
});
```
Notice the consistency of the TextInput after the changes, while before it would just move around more you switch the keyboards.
| Before | After |
|---|---|
|  |  |
Reviewed By: cipolleschi
Differential Revision: D39718812
Pulled By: NickGerleman
fbshipit-source-id: 2550182e846f3f8e719d727fa8e6d87165faebf6
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:
This updates `fontVariant` to support space-separated string values, i.e., `'small-caps common-ligatures'`, thus aligning it with the [CSS Fonts Module Level 4](https://drafts.csswg.org/css-fonts/#font-variant-prop) specification as requested on https://github.com/facebook/react-native/issues/34425. This also adds unit tests to the `processFontVariant` function ensuring the style processing works as expected.
## Changelog
[General] [Added] - Add space-separated string support for fontVariant
Pull Request resolved: https://github.com/facebook/react-native/pull/34641
Test Plan:
This can be tested either through `processFontVariant-tests` or by using the following code:
```js
<Text
style={{
fontVariant: 'small-caps common-ligatures',
}} />
```
Reviewed By: javache
Differential Revision: D39423317
Pulled By: cipolleschi
fbshipit-source-id: ad971addb423ed338e178528a11fe9d456c03e6e
Summary:
This adds the `id` prop to `Text`, `TouchableWithoutFeedback` and `View` components as requested on https://github.com/facebook/react-native/issues/34424 mapping the existing `nativeID` prop to `id`. As this components are inherited by others this also adds the `id` prop support to `Image`, `TouchableBounce`, `TouchableHighlight`, `TouchableOpacity` and `TextInput`.
This PR also adds android tests ensuring that the `id` property is passed to the native view via the `nativeID` prop, these tests were based on the existing `nativeID` tests ([NativeIdTestCase.java](https://github.com/facebook/react-native/blob/main/ReactAndroid/src/androidTest/java/com/facebook/react/tests/NativeIdTestCase.java)).
## Changelog
[General] [Added] - Add id prop to Text, TouchableWithoutFeedback and View components
Pull Request resolved: https://github.com/facebook/react-native/pull/34522
Test Plan: Ensure that the new `id` prop android tests pass on CircleCI
Reviewed By: lunaleaps
Differential Revision: D39089639
Pulled By: cipolleschi
fbshipit-source-id: 884fb2461720835ca5048004fa79096dac89c51c
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:
This PR aims to add support for objectFit a partial equivalent to the resizeMode style and prop of Image.
## Changelog
[General] [Added] - Add support for objectFit style of Image.
Pull Request resolved: https://github.com/facebook/react-native/pull/34576
Test Plan:
1. Open the RNTester app and navigate to the Image page
2. See the Object Fit section.
Reviewed By: rickhanlonii
Differential Revision: D39261176
Pulled By: jacdebug
fbshipit-source-id: 1eefd76b6c11ed5fc52b2c524ad78c91051077f6
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:
This unifies the Android only `autoComplete` and the iOS only `textContentType` TextInput props with the web `autoComplete` values as requested on https://github.com/facebook/react-native/issues/34424. I left the `textContentType` prop and the current supported `autoComplete` values untouched in order to avoid having a breaking change. This also updates RNTester to include test cases using the new `autoComplete` values
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Changed] - Unify TextInput autoComplete and textContentType props
Pull Request resolved: https://github.com/facebook/react-native/pull/34523
Test Plan:
1. Open the RNTester app and navigate to the TextInput page
2. Test the `TextInput` component through the `Text Auto Complete` section
https://user-images.githubusercontent.com/11707729/187118267-3b509631-7b84-47b7-a580-567a7f5b483f.mov
Reviewed By: NickGerleman
Differential Revision: D39104545
Pulled By: cipolleschi
fbshipit-source-id: a0d4b1b9ab336854a741a9efe4a62c3da0b5c0f4
Summary:
This adds `aria-live` alias for `accessibilityLiveRegion`, it unifies aria-live and accessibilityLiveRegion and also maps `aria-live='off'` to `accessibilityLiveRegion='none'` as requested on https://github.com/facebook/react-native/issues/34424
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General][Added] - Added aria-live alias for accessibilityLiveRegion.
Pull Request resolved: https://github.com/facebook/react-native/pull/34555
Test Plan:
```js
<View aria-live="polite">
<Text>Clicked {this.state.count} times</Text>
</View>
<View aria-live="off">
<Text>Clicked {this.state.count} times</Text>
</View>
```
Reviewed By: cipolleschi
Differential Revision: D39206291
Pulled By: jacdebug
fbshipit-source-id: fd2019e7047ff7ff6133fed39f1a70b5a9396f89
Summary:
This adds support for the `userSelect` style attribute, mapping the already existing selectable attribute as requested on https://github.com/facebook/react-native/issues/34425. This PR also updates the TextExample.android and TestExample.ios on the RNTester in order to facilitate the manual QA of this.
## Changelog
[General] [Added] - Add support for `userSelect` style
Pull Request resolved: https://github.com/facebook/react-native/pull/34575
Test Plan:
- open the RNTester app and navigate to the Text page
- Check the `Selectable Text` through the Selectable text section
<Image src="https://user-images.githubusercontent.com/22423684/188112863-65acd145-76b0-47ba-8bc6-f72298077096.png" height="600" width="300" />
Reviewed By: yungsters
Differential Revision: D39252798
Pulled By: jacdebug
fbshipit-source-id: f7fabf20ee68778d75461f511c56f94d0d756d9c
Summary:
This adds the ` aria-hidden` prop to `Pressable`, `TouchableBounce`, `TouchableHighlight`, `TouchableNativeFeedback`, `TouchableOpacity`, `TouchableWithoutFeedback` and `View` components as requested on https://github.com/facebook/react-native/issues/34424, being an alias `importantforAccessibility='no-hide-descendants'` on Android and an alias for `accessibilityElementsHidden` on iOS. This PR also updates RNTester AccessibilityExample in order to facilitate the manual QA.
## Changelog
[General] [Added] - Add aria-hidden prop to Pressable, View and Touchables components
Pull Request resolved: https://github.com/facebook/react-native/pull/34552
Test Plan:
1. Open the RNTester app and navigate to the Accessibility page
2. Test the `aria-hidden` prop through the `View with hidden children from accessibility tree` section, this can be tested either by enabling Voice Over if you're using a real device or through the Accessibility Inspector if you're using a simulator
https://user-images.githubusercontent.com/11707729/187814455-6937e33e-7edd-434e-b7d3-ee6c03f635ca.mov
Reviewed By: NickGerleman
Differential Revision: D39206245
Pulled By: jacdebug
fbshipit-source-id: 551dc671fbcedc824f253e22b8d7753c466838c7
Summary:
This adds `pointerEvents` style which is equivalent to `pointerEvents` prop as requested in https://github.com/facebook/react-native/issues/34425
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Added] - Added pointerEvents style equivalent to pointerEvents prop
Pull Request resolved: https://github.com/facebook/react-native/pull/34586
Test Plan:
```
<View
style={{
pointerEvents: 'none'
}}
>
</View>
```
Reviewed By: cipolleschi
Differential Revision: D39252830
Pulled By: jacdebug
fbshipit-source-id: 94f265a6b6940a4371e7985d5de3b8143693e069
Summary:
Fix `KeyboardAvoidingView` height on iOS when "Prefer Cross-Fade Transitions" is enabled by adding an additional check to `_relativeKeyboardHeight` verifying if `prefersCrossFadeTransitions()` is true and `keyboardFrame.screenY` is `0` and treating this special case. The issue was caused by the native RCTKeyboardObserver where the `endFrame` reported by `UIKeyboardWillChangeFrameNotification` returns `height = 0` when Prefer Cross-Fade Transitions" is enabled
and unfortunelly there isn't much we can do on the native side to fix it.
Closes https://github.com/facebook/react-native/issues/31484
Closes https://github.com/facebook/react-native/issues/29974
## Changelog
[iOS] [Fixed] - Fix KeyboardAvoidingView height when "Prefer Cross-Fade Transitions" is enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/34503
Test Plan:
**On iOS 14+**
1. Access Settings > "General" > "Accessibility" > "Reduce Motion", enable "Reduce Motion" then enable "Prefer Cross-Fade Transitions".
2. Open the RNTester app and navigate to the KeyboardAvoidingView page
3. Focus and blur inputs and observe the keyboard behaving correctly
https://user-images.githubusercontent.com/11707729/186822671-801872be-7db1-4c5c-904b-1987441c1326.mov
Reviewed By: jacdebug
Differential Revision: D39055213
Pulled By: cipolleschi
fbshipit-source-id: fac17cbe02867e0fe522397f6cb59a8b51c1840f
Summary:
This adds the `inputMode` prop to the TextInput component as requested on https://github.com/facebook/react-native/issues/34424, mapping web [inputMode types](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inputmode) to equivalent [keyboardType](https://reactnative.dev/docs/textinput#keyboardtype) values. This PR also updates RNTester TextInputExample in order to facilitate the manual QA.
### Caveats
~~This only adds support to `text`, `decimal`, `numeric`, `tel`, `search`, `email`, and `url` types.~~
#### `inputMode="none"`
**Currently mapped to `default` keyboard type.**
The main problem with this input mode is that it's not supported natively neither on Android or iOS. Android `TextView` does accept `none` as `android:inputType` but that makes the text not editable, which wouldn't really solve our problem. `UITextInput` on iOS on the other hand doesn't even have something similar to avoid displaying the virtual keyboard.
If we really want to add the support for `inputMode="none"` one interesting approach we could take is to do something similar to what WebKit has done (3b5f0c8ecf). In order to achieve this behavior, they had to return a `UIView` with a bounds of `CGRectZero` as the inputView of the `WKContentView` when inputmode=none is present.
~~I guess the real question here should be, do we really want to add this? Or perhaps should we just map `inputMode="none"` to `keyboardType="default"`~~
Android docs: https://developer.android.com/reference/android/widget/TextView#attr_android:inputType
iOS docs: https://developer.apple.com/documentation/uikit/uikeyboardtype?language=objc
#### `inputMode="search"` on Android
**Currently mapped to `default` keyboard type.**
Android `TextView` does not offers any options like `UIKeyboardTypeWebSearch` on iOS to be used as `search` with `android:inputType` and that's probably the reason why `keyboardType="web-search"` is iOS only. I checked how this is handled on the browser on my Android device and it seems that Chrome just uses the default keyboard, maybe we should do the same?
### Open questions
- ~~What should be done about `inputMode="none"`?~~ Add it and map it to `default` keyboard type.
- ~~Which keyboard should we show on Android when `inputMode="search"`?~~ Use the `default` keyboard the same way Chrome does
## Changelog
[General] [Added] - Add inputMode prop to TextInput component
## Test Plan
1. Open the RNTester app and navigate to the TextInput page
2. Test the `TextInput` component through the `Input modes` section
https://user-images.githubusercontent.com/11707729/185691224-3042e828-a008-4bd0-bb3d-010a6a18dfd5.mov
Pull Request resolved: https://github.com/facebook/react-native/pull/34460
Reviewed By: necolas
Differential Revision: D38900724
Pulled By: cipolleschi
fbshipit-source-id: 60d405ccdbfad588b272fbb6b220b64ffdfc4b14
Summary:
This adds the `tabIndex` Android only prop to View as requested on https://github.com/facebook/react-native/issues/34424 mapping the existing `focusable` prop to `tabIndex` so that `tabIndex={0}` maps to `focusable={true}` and `tabIndex={-1}` represents ` focusable={false}`.
## Changelog
[Android] [Added] - Add tabIndex prop to View component
Pull Request resolved: https://github.com/facebook/react-native/pull/34486
Test Plan: I'm still investigating the best way to test this but we're are just mapping this to an existing prop
Reviewed By: GijsWeterings
Differential Revision: D38957303
Pulled By: necolas
fbshipit-source-id: d00db854e11cb3457329c1547b69cff60afb34cf
Summary: Changelog: [Internal] - Make AccessibilityInfo public type an exact object
Reviewed By: NickGerleman
Differential Revision: D38921820
fbshipit-source-id: 6f264595814a817fb1101788942f9127d9cc85c1
Summary:
This adds the Android only `rows` prop to TextInput as requested on https://github.com/facebook/react-native/issues/34424 mapping the existing `numberOfLines` prop to `rows`. This PR also updates the TextInputExample.android on the RNTester in order to facilitate the manual QA of this.
## Changelog
[Android] [Added] - Add rows prop to TextInput component
Pull Request resolved: https://github.com/facebook/react-native/pull/34488
Test Plan:
1. On Android open the RNTester app and navigate to the TextInput page
2. Test the `TextInput` component through the `Fixed number of lines` section
https://user-images.githubusercontent.com/11707729/186300173-7de79799-25b8-48af-99c0-8e3abeae334f.mov
Reviewed By: christophpurrer
Differential Revision: D38981953
Pulled By: cipolleschi
fbshipit-source-id: d4d84b3c0dac7342ba9a65e2491928fbc61ff4f1
Summary:
This adds the `readOnly` prop to TextInput as requested on https://github.com/facebook/react-native/issues/34424 mapping the existing `editable` prop to `readOnly` so that `readOnly={false}` maps to `editable={true}` and `readOnly={true}` represents ` editable={false}`. This PR also updates the TextInputExample on the RNTest in order to facilitate the manual QA of this.
## Changelog
[General] [Added] - Add readOnly prop to TextInput component
Pull Request resolved: https://github.com/facebook/react-native/pull/34444
Test Plan:
1. Open the RNTester app and navigate to the TextInput page
2. Test the `TextInput` component through the `Editable and Read only` section
https://user-images.githubusercontent.com/11707729/185295132-036443c8-1d5e-4567-a15e-5f1173cb0526.mov
Reviewed By: lunaleaps
Differential Revision: D38912786
Pulled By: necolas
fbshipit-source-id: faeb59ed8695732be682ec55406a2de0cb7e619a
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 (1e48274223) 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: Changelog: [Internal] - Create a type declaration for AccsesibilityInfo for clearer signal when our public API types change
Reviewed By: yungsters
Differential Revision: D38712552
fbshipit-source-id: cc7c727d41fb03ca714cb05fd10dc32038374fd0
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
David
Luna Wei
Daksh Bhardwaj
Pieter De Baets
Aelita
Gabriel Donadel Dall'Agnol
Tim Yung
Vic
Pavol Fulop
Nick Gerleman
Luna Wei
Rujin Cao
Viraj-10
Rubén Norte
Agastya Darma Laksana
Mayank Sunil Pagar
ankit-tailor
cyrus25
madhav23bansal
Pieter Vanderwerff
