Summary:
React Native ScrollViews are flipped upside down when the prop inverted is set to true. This is the root of a bug: tapping on the status bar in iOS should scroll the Flatlist up to the top but currently it does to the bottom.
The solution proposed is to detect natively if the ScrollView is inverted, on such case, prevent it from scrolling it to the beginning of the ScrollView (as a non-inverted ScrollView would do) and force a scroll to the end of it.
I've been careful enough not to force the scroll if the user explicitly selected not to do it or if it's happening in a nested ScrollView, as it is the default behaviour in iOS.
Fixes https://github.com/facebook/react-native/issues/21126
## Changelog
[iOS] [Fixed] - Inverted ScrollViews scroll to their bottom when the status bar is pressed
Pull Request resolved: https://github.com/facebook/react-native/pull/27574
Test Plan:
- on iOS, add a ScrollView and put enough content to overflow the screen size so it can be scrolled
- add the prop `inverted={true}` to the ScrollView
- go to the screen the Scrollview is in and press the status bar
- it should scroll to top (previously it scrolled to the bottom)
Differential Revision: D19185270
Pulled By: hramos
fbshipit-source-id: 5445093ff38f4ba4082f1d883d8ed087e9565eaf
Summary:
Starting on iOS 13, a View Controller presented modally will have a "bottom sheet" style unless it's explicitly presented full screen.
Before this, modals on iOS were only being dismissed programatically by setting `visible={false}`. However, now that the dismissal can happen on the OS side, we need a callback to be able to update the state.
This PR reuses the `onRequestClose` prop already available for tvOS and Android, and makes it work on iOS for this use case.
Should fix https://github.com/facebook/react-native/issues/26892
## Changelog
[iOS] [Added] - Add support for onRequestClose prop to Modal on iOS 13+
Pull Request resolved: https://github.com/facebook/react-native/pull/27618
Test Plan:
I tested this using the RNTester app with the Modal example:
1. Select any presentation style other than the full screen ones
2. Tap Present and the modal is presented
3. Swipe down on the presented modal until dismissed
4. Tap Present again and a second modal should be presented
Differential Revision: D19235758
Pulled By: shergin
fbshipit-source-id: c0f1d946c77ce8d1baab209eaef7eb64697851df
Summary:
It closes https://github.com/facebook/react-native/issues/24855
In the endRefreshProgrammatically of RCTRefreshControl.m there is calculation for content offset when spinner is shown CGPoint offset = {scrollView.contentOffset.x, scrollView.contentOffset.y - self.frame.size.height};
However self.frame.size.height is always 0 and therefore spinner is not visible
This change should fix that
Since the owner of the following PR is quite busy and won't be able to resolve the merge conflict anytime soon, I created this PR here to get the fix merged soon.
Ref: https://github.com/facebook/react-native/pull/27236
Thanks to [IgnorancePulls](https://github.com/IgnorancePulls)
## Changelog
[iOS] [Fixed] - Fix spinner visibility on beginRefreshingProgrammatically
Pull Request resolved: https://github.com/facebook/react-native/pull/27397
Test Plan:
IOS tests passed
Check whether this issue is reproduced or not for the repro which is described inside the issue.
https://github.com/facebook/react-native/issues/24855
Reviewed By: sammy-SC
Differential Revision: D18801307
Pulled By: hramos
fbshipit-source-id: d12af236778441a136dbe6b03dfd3495a465ae0f
Summary:
Changelog: [Internal]
Introduce native command `setNativeRefreshing`, it has the word Native in order to avoid name conflict with setRefreshing in Android implementation. Even this component is iOS only, it would make it easier to merge them in the future.
Introduce `RCTRefreshableProtocol` and make `RCTRefreshControl` and `RCTPullToRefreshViewComponentView` to conform to the protocol so view manager can forward command to both, Paper and Fabric component.
Reviewed By: mmmulani
Differential Revision: D18475804
fbshipit-source-id: 4c19225784efc931b7b8f2d2671cc839bce429bf
Summary:
Changelog: [Internal]
In paper implementation:
`accessibilityActivate` returns NO in case `onAccessibilityTap` is nil.
In Fabric we have no option to detect whether `onAccessibilityTap` is nil or isn't but we don't want to prevent VoiceOver from tapping an element. This could potentially trigger action associated with element twice.
Let's say you have `onPress` and `onAccessibilityTap`, it will trigger both if you trigger action through VoiceOver.
Reviewed By: shergin
Differential Revision: D18572432
fbshipit-source-id: c5ac002317c798a10045b6f05738299d0ae27456
Summary:
Changelog: [Internal]
The main use-case here is to get the rootTag off RCTImageView, for image loading instrumentation. The fact is, each RCTView subclass already has `reactTag` attached today. We already have the `rootTag` when the view is created by the UIManager, so why not just attach it like reactTag? If we don't, looking up the rootTag from the native component is non-trivial and extremely inefficient (have to jump to shadow queue, back to main queue, etc).
Reviewed By: sammy-SC
Differential Revision: D18497002
fbshipit-source-id: 8409e3a1c95e09accedd959592cbf178fab0b2c3
Summary:
With tvOS (Apple TV) now residing in a separately maintained fork, this removes the residual props from React Native. This only includes the JavaScript changes. The Objective-C changes will come later.
Specifically, the following props have been removed:
- `isTVSelectable`
- `tvParallaxProperties`
- `tvParallaxShiftDistanceX`
- `tvParallaxShiftDistanceY`
- `tvParallaxTiltAngle`
- `tvParallaxMagnification`
Note that `hasTVPreferredFocus` is still being used by Android TV, so it remains.
Changelog:
[Removed] Apple TV View Props
Reviewed By: TheSavior
Differential Revision: D18266278
fbshipit-source-id: 9d1448bf2f434a74e6eb23c70d3a37971e406768
Summary:
Use `reactTag` instead of address of `UIView` to map events from paper components to Fabric.
changelog: [internal]
Reviewed By: shergin
Differential Revision: D17954974
fbshipit-source-id: 0d8bf748e58f4cb6769e107bc7fd0e66b93d8f12
Summary:
Searching for the ancestor view while measuring a shadow view layout relative to the ancestor is limited to `30`. I couldn't find the reason nor commit where it was introduced (because I have no access to internal facebook commits).
I think we should keep looking for an ancestor view until the shadow view has the superview property.
## Changelog
[iOS] [Fixed] - Remove maximum searching depth while measuring layout.
Pull Request resolved: https://github.com/facebook/react-native/pull/26986
Test Plan:
- Tested if RNTester works as expected.
- Tested in app with a lot of nested flatlists where sometimes I was facing this redbox because of the max depth limit.
<img width="297" alt="Screenshot 2019-10-24 at 14 40 11" src="https://user-images.githubusercontent.com/16336501/67486474-6309d380-f66c-11e9-9eab-15e8fb8372a5.png">
Differential Revision: D18175568
Pulled By: shergin
fbshipit-source-id: cd59a18032d10bc6dd5707981e69813810f65b5a
Summary:
iOS 13 introduced a new design for `UISegmentedControl` and new APIs to control this. `[UISegmentedControl tintColor]` is now ignored.
We try to maintain backwards compatibility so the appearance is as close as possible to iOS 12.
Changelog:
Fix `tintColor` on SegmentedControlIOS
Reviewed By: shergin
Differential Revision: D17905892
fbshipit-source-id: 964ac64c8543660929c43b427dce4f78094b1255
Summary:
The component RCTRefreshControl was renamed to PullToRefreshView (for Paper). Now only old Objective-C class names have the old name, which is okay.
Changelog: [Internal] [Changed] - The internal name of PullToRefresh component was changed from `RCTRefreshControl` to `PullToRefreshView` (No public API changes)
Reviewed By: rickhanlonii
Differential Revision: D17456225
fbshipit-source-id: a8db99ddd507377d8c98b26707a3b9fae483d20c
Summary:
Currently the react native framework doesn't handle the accessibility state changes of the focused item that happen not upon double tapping. Screen reader doesn't get notified when the state of the focused item changes in the background.
To fix this problem, post a layout change notification for every state changes on iOS.
On Android, send a click event whenever state "checked", "selected" or "disabled" changes. In the case that such states changes upon user's clicking, the duplicated click event will be skipped by Talkback.
## Changelog:
[General][Fixed] - Announce accessibility state changes happening in the background
Pull Request resolved: https://github.com/facebook/react-native/pull/26624
Test Plan: Add a nested checkbox example which state changes after a delay in the AccessibilityExample.
Differential Revision: D17903205
Pulled By: cpojer
fbshipit-source-id: 9245ee0b79936cf11b408b52d45c59ba3415b9f9
Summary: Move RCTScrollEvent into separate file and export its header.
Reviewed By: shergin
Differential Revision: D17831709
fbshipit-source-id: f4ee4e09147ef5703b85a10238ddb6cdefdf05a5
Summary:
LegacyViewManagerInterop layer can now handle events as well.
We expose `eventInterceptor` from `NSComponentData`, that way we can hook into event dispatching that happens within `NSComponentData`.
Coordinator has a map of `UIView -> reactTag` which it uses to figure out to which component view to forward the event.
New `LegacyViewManagerInteropViewEventEmitter` exposes APIs to send `folly::dynamic` to javascript.
Reviewed By: shergin
Differential Revision: D17765834
fbshipit-source-id: 25e75e445b32c69ec9ab0189c4ab7fba5f8c7b5d
Summary:
@public
This will provide a more useful error message and hopefully allow us to debug the issue further.
Reviewed By: JoshuaGross
Differential Revision: D17793693
fbshipit-source-id: 848ae658200ea5e3892d8a88888599c1c248c994
Summary: We are moving away from setNativeProps, this adds necessary method on native to leverage commands API
Reviewed By: shergin
Differential Revision: D17787877
fbshipit-source-id: 8f06cdd85c96bce4ea9bb7a8cd5f6c1a1d68b20a
Summary:
This is required so we can switch to using commands instead of `setNativeProps`.
`setNativeProps` are not supported in Fabric, we are moving away from it.
Reviewed By: JoshuaGross
Differential Revision: D17764967
fbshipit-source-id: 16e54ebe1f0c58b80a6491db970a60c01fec8a15
Summary:
When sliders are adjusted via accessibility, no onSlidingComplete callback is
generated. This causes problems for components which perform behavior in this
callback, and means that such components don't behave properly when adjusted via
accessibility. For example, if an app hosting a volume control slider only commits the volume change to the hardware on onSlidingComplete, it is impossible for a screen reader user to ever actually adjust the volume.
Ensure that sliders call the onSlidingComplete callback after adjusted via
accessibility.
## Changelog
[General] [Fix] - Add onSlidingComplete callbacks when sliders adjusted via a11y.
[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/26600
Test Plan: Prior to this change, using the RNTester slider example with a screen reader, the onSlidingComplete callback tests never shows any callbacks when the slider is adjusted. With this change applied, the callback test will show a number of callbacks corresponding to the number of times the slider was adjusted via the screen reader.
Differential Revision: D17661157
Pulled By: cpojer
fbshipit-source-id: a6eedef099c6c1b571b290c329059ac9b69b53dd
Summary:
React Native components need a mechanism to specify their value to assistive technologies. This PR adds the notion of accessibilityValueDescription-- a property which either contains a textual description of a component's value, or for range-based components, such as sliders and progress bars, it contains range information (minimum, current, and maximum).
On iOS, the range-based info if present is converted into a percentage and added to the accessibilityValue property of the UIView. If text is present as part of the accessibilityValueDescription, it is used instead of the range-based information.
On Android, any range-based information in accessibilityValueDescription is exposed in the AccessibilityNodeInfo's RangeInfo. Text which is part of accessibilityValueDescription is appended to the content description.
## Changelog
[GENERAL] [Change] - add accessibilityValuedescription property.
Pull Request resolved: https://github.com/facebook/react-native/pull/26169
Test Plan: Added two new accessibility examples to RNTester, one which uses text and another which uses range-based info in accessibilityValueDescription. Verified that they both behave correctly on both Android and iOS.
Differential Revision: D17444730
Pulled By: cpojer
fbshipit-source-id: 1fb3252a90f88f7cafe1cbf7db08c03f14cc2321
Summary:
We added the accessibilityState property as a more semantically rich way for components to describe information about their state to accessibility services. This PR removes the old accessibilityStates property.
<!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? -->
## Changelog
[General] [Change] - Remove accessibilityStates property.
Pull Request resolved: https://github.com/facebook/react-native/pull/26168
Test Plan: Ensure that RNTester accessibility examples function properly on both iOS and Android.
Differential Revision: D17152891
Pulled By: cpojer
fbshipit-source-id: d71d3cf0f2e0846979d2ba104b6c69e4e5725252
Summary:
The activityIndicatorViewStyle property overrides the previous set color
if it's changed. Depending on the property set order you may end in a state
that the color property will never be respected since it first sets
the color and then the activityIndicatorViewStyle property (which overrides
the color property). In order to prevent this problem
before setting the new activityIndicatorViewStyle save the old
color and override it after activityIndicatorViewStyle is set. Thus
always respecting the user's color.
## Changelog
[iOS] [Fixed] - Do not override ActivityIndicator color when setting its size
Pull Request resolved: https://github.com/facebook/react-native/pull/25849
Test Plan:
Using the code below on iOS notice that the last ActivityIndicator will always have its color set to white while te testID is provided
### Without the patch
Notice the white -> blue transition when disabling the testID
### With the patch
Color remains unchanged
```javascript
import React from "react";
import { View, StyleSheet, ActivityIndicator, Button } from "react-native";
const App = () => {
const [enableTestID, onSetEnableTestID] = React.useState(true);
const onPress = React.useCallback(() => {
onSetEnableTestID(!enableTestID);
}, [enableTestID]);
return (
<View style={styles.container}>
<ActivityIndicator size="large" color="red" />
<ActivityIndicator size="small" color="red" />
<ActivityIndicator size="small" />
<ActivityIndicator color="green" />
<ActivityIndicator
key={enableTestID.toString()}
size="large"
color="blue"
testID={enableTestID ? 'please work' : undefined}
/>
<Button
title={enableTestID ? 'Disable testID' : 'enable testID'}
onPress={onPress}
/>
</View>
);
};
export default App;
const styles = StyleSheet.create({
container: {
flex: 1,
alignItems: "center",
justifyContent: "center",
backgroundColor: "black"
},
});
```
Closes https://github.com/facebook/react-native/issues/25319
Reviewed By: cpojer
Differential Revision: D16559929
Pulled By: sammy-SC
fbshipit-source-id: ac6fd572b9f91ee5a2cbe46f8c46c1f46a1ba8b3
Summary:
# Disclaimer:
I might be missing something as the solution I implemented here seems like something that was considered by original author. If this solution isn't good, I have a plan B.
# Problem:
`onDismiss` prop isn't being called once the modal is dismissed, this diff fixes it.
Also I've noticed that `onDismiss` is meant to only work on iOS, why is that? By landing this diff, it'll be called on Android as well so we need to change the docs (https://facebook.github.io/react-native/docs/modal.html#ondismiss).
## Video that shows the problem
Following code is in playground.js P70222409 which just increments number everytime onDismiss is called
{F166303269}
Reviewed By: shergin
Differential Revision: D16109536
fbshipit-source-id: 3fba56f5671912387b217f03b613dffd89614c9d
Summary:
The accessibilityActions accessors in UIView+React.m are not aligned with the property declaration in the header file.
## Changelog
[General] [Fixed] - Fix accessibilityActions accessors
Pull Request resolved: https://github.com/facebook/react-native/pull/25134
Differential Revision: D15621848
Pulled By: cpojer
fbshipit-source-id: f344689292ae7988e46d0d4263980306d364366b
Summary:
We need to use second for calculation, so change 17ms to 0.017s instead.
## Changelog
[iOS] [Fixed] - Fixes wrong time unit of scroll event throttle
Pull Request resolved: https://github.com/facebook/react-native/pull/25098
Reviewed By: sahrens, cpojer
Differential Revision: D15576526
Pulled By: sammy-SC
fbshipit-source-id: ddd8dd9098cbe582c6923ce8466892c363c090fc
Summary:
As PR [#24743](https://github.com/facebook/react-native/pull/24743) suggested, accessibility properties are better to set on UIView+React instead of RCTView so they can be used safely on any UIView.
## Changelog
[General] [Fixed] - Move accessibilityActions props to UIView+React
Pull Request resolved: https://github.com/facebook/react-native/pull/25015
Differential Revision: D15503131
Pulled By: cpojer
fbshipit-source-id: dedf9afbd0a1d35a5abbd13ace95ee620f718f39
Summary:
As currently defined, accessibilityStates is an array of strings, which represents the state of an object. The array of strings notion doesn't well encapsulate how various states are related, nor enforce any level of correctness.
This PR converts accessibilityStates to an object with a specific definition. So, rather than:
<View
...
accessibilityStates={['unchecked']}>
We have:
<View
accessibilityStates={{'checked': false}}>
And specifically define the checked state to either take a boolean or the "mixed" string (to represent mixed checkboxes).
We feel this API is easier to understand an implement, and provides better semantic definition of the states themselves, and how states are related to one another.
## Changelog
[general] [change] - Convert accessibilityStates to an object instead of an array of strings.
Pull Request resolved: https://github.com/facebook/react-native/pull/24608
Differential Revision: D15467980
Pulled By: cpojer
fbshipit-source-id: f0414c0ef6add3f10f7f551d323d82d978754278
Summary:
In case `RCTView` had no subviews, `RCTRecursiveAccessibilityLabel` was returning an empty string rather than nil.
I've noticed that https://fburl.com/i95iynxi returns empty string as well. Shall we change it there as well?
Reviewed By: shergin
Differential Revision: D15337865
fbshipit-source-id: 8e38a88321f3dcfdf35a38d43fdbe4f5118796f1
Summary:
This is a reconstitution of #24190. It extends accessibility actions to include both a name and user facing label. These extensions support both standard and custom actions.
We've also added actions support on Android, and added examples to RNTester showing how both standard and custom accessibility actions are used.
## Changelog
[general] [changed] - Enhanced accessibility actions support
Pull Request resolved: https://github.com/facebook/react-native/pull/24695
Differential Revision: D15391408
Pulled By: cpojer
fbshipit-source-id: 5ed48004d46d9887da53baea7fdcd0e7e15c5739
Summary:
## Overview
This diff switches the RCTSlider onSlidingComplete event on iOS from a bubbling event to a direct (non-bubbling) event to match the non-bubbling type on android.
Note that in this case these seems like a bug. I will still explain the motivation and reasoning as this will come up in future diffs.
## Changelog
[Slider][BREAKING] Switch Slider onSlidingComplete event to a non-bubbling event on iOS to match Android
## Motivation:
The motivation here is that when we codgen the view configs, we'll need to unify all of the events and props across platforms for components that have the same name on iOS and Android.
In this case, the view configs (below) conflict for onSlidingComplete. On iOS this is under bubblingEventTypes, on Android this is under directEventTypes. We have code [here](https://fburl.com/3s1dahm2) in the react native renderer which ensures an event is not listed as both.
```
// iOS
const SliderViewConfig = {
bubblingEventTypes: {
onSlidingComplete: {
phasedRegistrationNames: {
captured: 'onChangeCapture',
bubbled: 'onChange'
}
}
},
directEventTypes: {
// None
},
validAttributes: {
// ...
}
};
```
```
// Android
const SliderViewConfig = {
bubblingEventTypes: {
// None
},
directEventTypes: {
onSlidingComplete: {
registrationName: 'onEventDirect'
}
},
validAttributes: {
// ...
}
};
```
## Solutions
There are three solutions to this issue:
1. Don't generate view configs
2. Rename the component on one platform
3. Make a breaking change in the event behavior on one platform to make it consistent across both platforms
Here we've chosen option #3
Reviewed By: TheSavior
Differential Revision: D15322304
fbshipit-source-id: ff1ab86efe9e2bc50fd3f7619e6760ab5c1c5090
Summary:
The bug description can see https://github.com/facebook/react-native/issues/24688, we add `contentView` size check before center the content, because in some cases, the contentView's size not yet be calculated, in those cases, we don't adjust the `contentOffset`.
cc. cpojer .
[iOS] [Fixed] - Fixes ScrollView centerContent not work in some cases
Pull Request resolved: https://github.com/facebook/react-native/pull/24817
Differential Revision: D15322502
Pulled By: sahrens
fbshipit-source-id: e2081f13e9f2e8597a379a9db1607451ea496909
Summary:
React Native Gesture Handler uses a `RCTViewManager` subclass to manage `UIControl` so the cast to set accessibility props is not safe. This moves the accessibility props we set to `UIView+React` so they can be used safely on any `UIView`.
[General] [Fixed] - Move accessibility props to UIView+React
Pull Request resolved: https://github.com/facebook/react-native/pull/24743
Differential Revision: D15258062
Pulled By: cpojer
fbshipit-source-id: 4a25b79407e5cb7b3b368c7506161e989794bb26
Summary:
Assistive technologies use the accessibility role of a component to tell the disabled user what the component is, and provide hints about how to use it. Many important roles do not have analog AccessibilityTraits on iOS. This PR adds many critical roles, such as editabletext, checkbox, menu, and switch to name a few.
Accessibility states are used to convey the current state of a component. This PR adds several critical states such as checked, unchecked, on and off.
[general] [change] - Adds critical accessibility roles and states.
Pull Request resolved: https://github.com/facebook/react-native/pull/24095
Differential Revision: D15079245
Pulled By: cpojer
fbshipit-source-id: 941b30eb8f5d565597e5ea3a04687d9809cbe372
Summary: For some reason the scroll events are sometimes generated with highly irregular spacing, some coming less than a millisecond apart. For interactions that must track scrolling exactly, this can cause them to glitch. With a scroll throttle of less than 17 ms, the intention is clear that the UI should be updated in sync with the scroll view so we shouldn't drop any events.
Reviewed By: PeteTheHeat
Differential Revision: D15068841
fbshipit-source-id: 730e7cb29cc3ddae66f37cf7392e02e0cc9d7844
grabbou
Emilio
Valentin Shergin
Jorge Bernal
Binh Nguyen
Samuel Susla
Kevin Gozali
Andres Suarez
Tim Yung
Dratwas
Sharon Gong
Mehdi Mulani
Marc Mulcahy
Guilherme Iscaro
Min ho Kim
David Vacca
zhongwuzw
Rick Hanlon
Janic Duplessis
Spencer Ahrens
