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
Summary: Changelog: [Internal] - We can now remove the '2' suffix as we had an internal implementation that was not truly aligned with W3C pointers but used the same name. We have aligned the internal types to match w3c so we can now remove the suffix that differentiates them.
Reviewed By: vincentriemer
Differential Revision: D37545813
fbshipit-source-id: 6f2336ae9e314066c340161113268c1f28621a71
Summary:
`InputAccessoryView` works fine on iOS, but crashes on Android - you can see that by using an Android device on the [Expo Snack from the official doc](https://reactnative.dev/docs/inputaccessoryview).
It forces the developer not to render the component on Android, which is usually good, but other components have implemented other, safer ways to deal with incompatibility issues.
I am of course open to discussion about this change, as well as other implementation ideas.
## Changelog
[Android] [Fixed] - Fix InputAccessoryView crash on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/33803
Test Plan:
`yarn test` gives out the following output:
Reviewed By: cipolleschi
Differential Revision: D37215394
Pulled By: cortinico
fbshipit-source-id: 66c4401f7c61b745ea893969d69c8dde3e5afb03
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:
An issue that popped up working on:
D36140890
There is already behavior implemented to set the TextInput caret/cursor color independently from the selection box color in Android.
However this handy prop, was not documented or added as one of the available props for the TextInput component.
Associated behavior can be found here:
https://www.internalfb.com/code/fbsource/[f116d651b2e8]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/views/textinput/ReactTextInputManager.java?lines=512
## **Changelog**
[Android] - Add android-only prop documentation at the TextInput js level.
Reviewed By: genkikondo
Differential Revision: D36208656
fbshipit-source-id: a54a2646351d897e0d598d5e1979f2a0c443e9d6
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
cyrus25
madhav23bansal
Pieter Vanderwerff
Gabriel Donadel Dall'Agnol
Luna Wei
Daksh Bhardwaj
Nick Gerleman
fabriziobertoglio1987
Genki Kondo
Michael Sokolnicki
Tony Du
Eric Edouard
Paige Sun
Garrett Forbes Monroe
George Zahariev
hduprat
Zachinquarantine
Kacie Bawiec
Jérémy Barbet
Hetan Thakkar
Ken Tominaga
Christian Ruink
