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 (https://github.com/WebKit/WebKit/commit/3b5f0c8ecf9de23f79524ed02e290837ab8334cd). 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 (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: 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
Summary:
RN for Android fires `keyboardDidShow` and `keyboardDidHide` by observing changes to viewable window size. This isn't always reliable, such as when an activity has `awindowSoftInputMode` set to not have the system adjust the viewport when a keyboard is opened.
Android 11 added the direct ability to measure and check visibility of the soft keyboard via `WindowInsets`, which fixes these issues. This is exposed downlevel to API 23 via WindowInsetsComapt` with the same limitations as previously, but using it simplifies our calculations a lot.
Changelog:
[Android][Fixed] - Use WindowInsetsCompat for Keyboard Events
Reviewed By: javache
Differential Revision: D38500859
fbshipit-source-id: d4ad41d7e75e4b9c14a485539a5f9de19de74362
Summary:
Previously published by [grgr-dkrk][2] as [https://github.com/facebook/react-native/issues/31296][3], fixes the following issues:
1) ImportantForAccessibility="no" does not work on Text, Button
2) ImportantForAccessibility="no-hide-descendants" does not work on Text, Button, or ImageBackground.
Note: On ImageBackground, focus is prevented on the imageBackground node itself, but focus is not prevented on its descendants.
Note: [Button component expected behavior for prop importantForAccessibility][4]
>Some components like Button seem like atomic units, but they end up rendering a hierarchy of components for example a wrapper View with a Text inside them. Allowing those descendants to become focusable, breaks the model of these being a single component to consider and forcing no-hide-descendants makes sense here.
>The other option is always to render any descendants of these elements with importantForAccessibility="no", so they can never be focusable on their own. This would have the same result, **BUT may potentially cause issues when the descendant content is supposed to automatically get moved up to the focusable ancestor to act as a label** (which is what Talkback does with unfocusable text elements by default).
Note: [importantForAccessibility="no" does not allow screenreader focus on nested Text Components with accessibilityRole="link" or inline Images][5]
fixes https://github.com/facebook/react-native/issues/30850 related https://github.com/facebook/react-native/pull/33690
## Changelog
[Android] [Fixed] - adding importantForAccessibility for Text, Button, ImageBackground
Pull Request resolved: https://github.com/facebook/react-native/pull/34245
Test Plan:
1) testing ImageBackground importantForAccessiblity ([link to test][1])
2) importantForAccessibility="no" does not allow screenreader focus on nested Text Components with accessibilityRole="link" or inline Images ([link to test][5])
3) testing ImageBackground importantForAccessiblity ([link to test][6])
4) Button with importantForAccessibility=no ([link to test][7])
[1]: https://github.com/facebook/react-native/pull/31296#issuecomment-1192341626 ""
[2]: https://github.com/grgr-dkrk "grgr-dkrk"
[3]: https://github.com/facebook/react-native/pull/31296 "https://github.com/facebook/react-native/issues/31296"
[4]: https://github.com/facebook/react-native/pull/31296#discussion_r616184584 "expected behaviour with prop importantForAccessibility in Button component"
[5]: https://github.com/facebook/react-native/issues/30850#issuecomment-1192286477 "importantForAccessibility=no does not allow screenreader focus on nested Text Components with accessibilityRole=link or inline Images"
[6]: https://github.com/facebook/react-native/pull/34245#issuecomment-1192446124 "testing ImageBackground importantForAccessiblity"
[7]: https://github.com/facebook/react-native/pull/34245#issuecomment-1192443589 "Button with importantForAccessibility=no"
Reviewed By: cipolleschi
Differential Revision: D38121992
Pulled By: dmitryrykun
fbshipit-source-id: 368b4dcb47d7940274820aa2e39ed5e2ca068821
Summary:
Add capture-phase focus events to the type system, for use in the refactored VirtualizedList https://github.com/facebook/react-native/pull/32646/files
Tracking the last focused child is done via focus events. Focus events are bubbling (vs direct events like onLayout), and are given both a "capture" phase, and "bubbling phase", like DOM events on the web. https://stackoverflow.com/questions/4616694/what-is-event-bubbling-and-capturing
The VirtualizedList change wants to know if a child will receive focus. This is not possible to reliably capture in the bubbling phase, since a child may stop propagation.
See https://github.com/react-native-community/discussions-and-proposals/pull/335#discussion_r584851337 for some discussion with Scott Kyle about this issue back in the day
This is done by convention in React by adding a "capture" variant of the `onXXX` method. For all platforms I've seen with focus events, these map the `topFocus` native event to `onFocus` for bubbling phase, and `onFocusCapture` for capture phase. See https://reactjs.org/docs/events.html#supported-events
Changelog:
[General][Added] - Add types for onFocusCapture/onBlurCapture
Reviewed By: javache
Differential Revision: D38013861
fbshipit-source-id: 7bda22e1a4d5e36ac5e34e804abf6fb318a41baf
Summary:
Now that [exact_empty_objects has been enabled](https://fb.workplace.com/groups/flowlang/posts/1092665251339137), we can codemod `{...null}` to `{}` - they are now equivalent.
1) Run my one-off jscodeshift codemod
2) `scripts/flow/tool update-suppressions .` (as some suppressions move around due to the change)
drop-conflicts
Reviewed By: bradzacher
Differential Revision: D37834078
fbshipit-source-id: 6bf4913910e5597e5dd9d5161cd35deece6a7581
Summary:
A layout-impacting style change will trigger a layout effect hook within `TextInput`. This hook fires a ViewManager command to set the text input based on the known JS value: https://github.com/facebook/react-native/blob/d82cd3cbce1597512bb2868fde49b5b3850892a0/Libraries/Components/TextInput/TextInput.js#L1009
The JS value is determined using `value` if set, falling back to `defaultValue`. If a component uses `TextInput` as an uncontrolled component, and does not set this value, the command wipes text input back to the default value. This does not happen on re-render of the JS side, despite setting text prop, since the underlying native property never changes/triggers a rerender.
This change alters the logic to prefer `lastNativeText` instead of `defaultValue` when available, to retain the updated `TextInput` content on relayout.
Reviewed By: javache
Differential Revision: D37801394
fbshipit-source-id: d56c719d56bebac64553c731ce9fca8efc7feae9
Gabriel Donadel Dall'Agnol
Viraj-10
Rubén Norte
Daksh Bhardwaj
Agastya Darma Laksana
Mayank Sunil Pagar
ankit-tailor
cyrus25
madhav23bansal
Pieter Vanderwerff
Luna Wei
Nick Gerleman
fabriziobertoglio1987
Genki Kondo
Michael Sokolnicki
Tony Du
Eric Edouard
Paige Sun
Garrett Forbes Monroe
George Zahariev
