Summary:
Changelog:
[General][Added] - Added an overlay similar to Inspector.js that allows directly selecting elements on RN from React DevTools
This diff updates DevToolsHighlighter into DevToolsOverlay. It now also allows DevTools user to select an element to inspect directly from DevTools.
Depends on https://github.com/facebook/react/pull/25111 to work.
TODOs:
- Currently once an element selected on RN, the inspector toggle isn't turned off automatically.
- Fabric support depends on https://github.com/facebook/react/pull/25118
Reviewed By: lunaruan
Differential Revision: D38815494
fbshipit-source-id: 7e1e3a78f6594960b5dfaec142bafd3ca4b146af
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 `tintColor` prop to the Image component to replace the non-standard `style.tintColor` as requested on https://github.com/facebook/react-native/issues/34424, so that React Native for Web does not have to deopt styles for Image rendering. I didn't have to change anything on Android as `tintColor` was already being passed down to the native component as a prop. This PR also updates RNTester ImageExample in order to facilitate the manual QA.
## Changelog
[General] [Added] - Add tintColor prop to Image component
Pull Request resolved: https://github.com/facebook/react-native/pull/34534
Test Plan:
1. Open the RNTester app and navigate to the Image page
2. Test the `tintColor` prop through the `Tint Color` section
https://user-images.githubusercontent.com/11707729/187444761-ce5fd949-89f3-4d73-9717-31d035c6ee6b.mov
Reviewed By: necolas
Differential Revision: D39133292
Pulled By: jacdebug
fbshipit-source-id: 314e0ed47ab65366153e730667a31554bc2b6aa7
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:
Small typo fix.
## Changelog
[General] [Fixed] - Typo in AssetSourceResolver
Pull Request resolved: https://github.com/facebook/react-native/pull/34520
Test Plan: No test plan is required. Just check the file changes.
Reviewed By: NickGerleman
Differential Revision: D39087572
Pulled By: cipolleschi
fbshipit-source-id: a79253d2486ee21fbf5683177b21ec534607d65d
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:
from the original design of `StyleSheet.setStyleAttributePreprocessor()` in https://github.com/facebook/react-native/issues/11138, the overwriting warning shows when the existing preprocess is be overwritten. the behavior changes from https://github.com/facebook/react-native/commit/33b385825c72. This PR revises the logic back to original design.
## Changelog
[Internal] [Fixed] - Show warning only when overwriting existing preprocessor in `StyleSheet.setStyleAttributePreprocessor()`
Pull Request resolved: https://github.com/facebook/react-native/pull/34479
Test Plan:
Unit Test
```
PASS Libraries/StyleSheet/__tests__/StyleSheet-test.js
setStyleAttributePreprocessor
✓ should not show warning when set preprocessor first time (2 ms)
✓ should show warning when overwrite the preprocessor (1 ms)
```
Reviewed By: dmitryrykun
Differential Revision: D38940676
Pulled By: cipolleschi
fbshipit-source-id: 80cf30fff62f4a02c17f7f42b3260a6011d5fc82
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:
changelog: [internal]
Call flushQueue directly from useAnimatedProps to avoid mismatch between `NativeAnimatedHelper.API.setWaitingForIdentifier` and `NativeAnimatedHelper.API.unsetWaitingForIdentifier`
Previously, animation queue only got called if every `setWaitingForIdentifier` call was matched by `unsetWaitingForIdentifier`. If an error is thrown, this is not the case and they get out of sync. WHen they get out of sync, they never recover and animation queue is never flushedddddd.
Reviewed By: yungsters
Differential Revision: D38938858
fbshipit-source-id: c38fdef05cc70ce274b8e16114ffe49cc2dcb9b3
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:
- Fix a typo in the word "feture" (-> "feature")
## 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
-->
[iOS] [Fixed] - Typo in AppDelegate.mm
Pull Request resolved: https://github.com/facebook/react-native/pull/34462
Test Plan: - Read the diff change
Reviewed By: dmitryrykun
Differential Revision: D38900680
Pulled By: cipolleschi
fbshipit-source-id: cdc5fb183cb7f5485a553dde7ea381f27f83e903
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:
Changelog:
[General][Changed] - Copied and refactored the current devtools highlighting code from Inspector into its own module and add to the top level `AppContainer`. The effect is that the highlight stills shows without Inspector opened.
This diff copies the current devtools highlighting logic from Inspector into a module and add to the top level `AppContainer`. The effect is without Inspector opened, the highlight will still show.
## Context
This is the first diff for "Component Tab Automatically Highlight Elements". The idea is to replicate the behavior on Web to RN.
## Behavior
on Web:
- highlight shows whenever an element in the component list is hovered
- Selecting an element doesn't keeps the highlight showing.
on RN (before this diff):
- when RN inspector opens: selecting an element keeps the highlight showing
- when RN inspector closes: stop showing highlihgintg.
on RN(this diff)
- selecting an element keeps the highlight showing
## TODO
- See if highlighting event can be sent on hover, instead of when an element is selected.
Reviewed By: lunaruan
Differential Revision: D38568135
fbshipit-source-id: d168874677d08a9c5526a7f896943579da804565
Summary:
This adds an option to the Error Reporting pipeline of React Native to attach custom extra data to Exceptions passed to the native ExceptionsManager. This allows for error logging abstractions such as Meta's FBLogger to attach extra fields to the reported error. This can help with more detailed error reports without having to stringify all data in the error message.
Note: The field (which is technically on ExtendedError) is keyed using a Symbol. This is to make sure that any use of this ability is extremely deliberate, as (accidentally) adding tons of data (or unserializable data) can cause issues we send down the data to the native ExceptionsManager implementation. Data sent using this method should be strictly controlled, hence opting in is a concious effort using the symbol in ExceptionsManager
Changelog:
[Internal] [Added] - Ability to add custom data to extraData field of exceptions passed to the ExceptionsManager
Reviewed By: yungsters
Differential Revision: D36099191
fbshipit-source-id: ce3f0dae52acd742de98b71868323c5878eaa677
Summary:
Changelog:
[General][Fixed] - Run ExceptionsManager unit tests in both __DEV__ and prod mode
This suite of unittests use a `__DEV__` check in various places to check that the correct data is sent to either LogBox (in __DEV__) or the Native ExceptionsManager (in PROD). However, we're not actually running both modes, so half of the assert branches in these tests aren't ever utilized.
This diff uses the same approach as ReactNativeVersionCheck-test.js to execute this test suite twice: Once in DEV and once in PROD mode.
Reviewed By: motiz88
Differential Revision: D36099190
fbshipit-source-id: 40b8ea26f1d9e093202f3c3f3b55111110a8d64c
Summary:
Currently both iOS and Android send over the list of transforms as an array. But there is an if statement that causes other platforms to get a matrix. This prevents other platforms from being able to use the fabric ViewProps class and the conversion functions as they exist in core, as those expect the transforms to be an array.
Stop special casing iOS and android. - Which will allow for example Windows to be able to share more fabric code.
## Changelog
[Internal] [Changed] - All platforms should get transform sent to native as an array of transform operations instead of a matrix
Pull Request resolved: https://github.com/facebook/react-native/pull/33579
Test Plan:
Similar change made in react-native-windows.
https://github.com/microsoft/react-native-windows/issues/9797
Reviewed By: NickGerleman
Differential Revision: D38615676
Pulled By: cortinico
fbshipit-source-id: 8861afe6bf34bebb09dd82f7365faf007dd79cbf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34384
This Diff aims to create a RCTAppDelegate library to offer a subclass which automates some operations required to set up the new architecture.
## Changelog
[iOS][Added] - Added the RCTAppDelegate library
Reviewed By: cortinico
Differential Revision: D38580424
fbshipit-source-id: 38f6c4b8ff2790a2ce9e23d385b36307701cffb7
Summary:
Sometime over the past few months (and with changes such as migrating to the `hermes-eslint` parser), a bunch of lint warnings crept into the codebase.
This does a pass to clean them all up, ignore generated files, and refactor some code to be... better.
There should be no observable behavior changes as a result of this.
Changelog:
[Internal]
Reviewed By: NickGerleman
Differential Revision: D38646643
fbshipit-source-id: a7b55d1e4cd5700340cc5c21f928baf3ea1d5a58
Summary:
Cleans up a few minor Flow suppression comments in `FlatList`. This reveals a new Flow error that is the result of `FlatList`'s props object being inexact whereas `VirtualizedList`'s props object is exact. For now, I introduce another -- but more specific -- Flow suppression for that type error.
The code changes should not have any consequential behavior change.
Changelog:
[Internal]
Reviewed By: NickGerleman
Differential Revision: D38646228
fbshipit-source-id: f4f9b0ad95323157ff1519353b38e8486adc841d
Summary:
needsOffscreenAlphaCompositing is supported on both iOS and Android, but was missing from the view config for Android.
https://reactnative.dev/docs/view#needsoffscreenalphacompositinghttps://fburl.com/code/hfxkrur1
Changelog:
[Internal][Fixed] - Add needsOffscreenAlphaCompositing to view config
Reviewed By: NickGerleman
Differential Revision: D38580371
fbshipit-source-id: 9b577079e575d73c94d7c0d0298ba880c1438099
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:
BaseViewManager.setPointerEnter was never called on ReactTextViews, and thus text views would not receive hover events.
Changelog:
[Internal][Fixed] - Add pointer events to text view config
Reviewed By: lunaleaps, javache
Differential Revision: D38557546
fbshipit-source-id: cfc0e5442efbd7c76d1b47acf56496d10ef78cf5
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:
This diff is part of an overall stack, meant to fix incorrect usage of `setState()` in `VirtualizedList`, which triggers new invariant checks added in `VirtualizedList_EXPERIMENTAL`. See the stack summary below for more information on the broader change.
## Diff Summary
This adds a `StateSafePureComponent`, which will override `setState`, along with `this.props` and `this.state`, in order to add runtime enforcement that `this.props` and `this.state` are not accessed during a state update where we should be relying on parameter instead. This should be landed after the fixes for unsafe `this.props`/`this.state` usage.
## Stack Summary
`VirtualizedList`'s component state is a set of cells to render. This state is set via the `setState()` class component API. The main "tick" function `VirtualizedList._updateCellsToRender()` calculates this new state using a combination of the current component state, and instance-local state like maps, measurement caches, etc.
From: https://reactjs.org/docs/state-and-lifecycle.html#state-updates-may-be-asynchronous
---
> React may batch multiple setState() calls into a single update for performance. Because this.props and this.state may be updated asynchronously, you should not rely on their values for calculating the next state. For example, this code may fail to update the counter:
```
// Wrong
this.setState({
counter: this.state.counter + this.props.increment,
});
```
> To fix it, use a second form of setState() that accepts a function rather than an object. That function will receive the previous state as the first argument, and the props at the time the update is applied as the second argument:
```
// Correct
this.setState((state, props) => ({
counter: state.counter + props.increment
}));
```
---
`_updateCellsToRender()` transitively calls many functions which will read directly from `this.props` or `this.state` instead of the value passed by the state updater. This intermittently fires invariant violations, when there is a mismatch.
This diff migrates all usages of `props` and `state` during state update to the values provied in `setState()`. To prevent future mismatch, and to provide better clarity on when it is safe to use `this.props`, `this.state`, I overrode `setState` to fire an invariant violation if it is accessed when it is unsafe to:
{F756963772}
Changelog:
[Internal][Changed] - Enable setState() hooks
Reviewed By: rshest
Differential Revision: D38294338
fbshipit-source-id: d04ff39f68df90adc9f4680887d308d997903675
Tianyu Yao
Pieter Vanderwerff
Ray
Gabriel Donadel Dall'Agnol
Luna Wei
Daksh Bhardwaj
dhruvtailor7
Kudo Chien
Samuel Susla
Nick Gerleman
Jérémy Barbet
Thuong Tran
Gijs Weterings
Andrew
Riccardo Cipolleschi
Tim Yung
Genki Kondo
fabriziobertoglio1987
Christoph Purrer
Marshall Roch
