Summary:
There is a problem that the `mediaPlaybackRequiresUserAction` property does not work in WKWebView(`useWebKit`) under iOS 10.
I fully know you are currently working to migrate the core's WebView to the standalone `react-native-webview` project. This has already been submitted to PR in `react-native-webview` and will be merged soon. I hope this fix applies to `react-native` before your migration is done.
Pull Request resolved: https://github.com/facebook/react-native/pull/22208
Differential Revision: D13334868
Pulled By: cpojer
fbshipit-source-id: f2a811a477054155ed5fe62ab31e4d63f70e7848
Calling -[UIScrollView setContentOffset] with NaN values can cause a crash. That's not clear why exactly the computation returns NaN sometime, but the implemented sanitizing should help to detect this problem during development (and this also prevents the app from crashing).
See attached task for more details.
Reviewed By: fkgozali
Differential Revision: D13242729
fbshipit-source-id: 747bf1b42e02597e9f1300eee24547563ab29b27
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/22316
Pull Request resolved: https://github.com/facebook/react-native/pull/22315
In order for TLS Mutual Auth to work for webviews, the caller must present a credential. Expose a setter that can be called to set a credential.
Reviewed By: RSNara
Differential Revision: D13095969
fbshipit-source-id: d136556a0030f799651d574b6e47ce38295b108e
Summary:
This PR splits and renames all references of ViewAccessibility to DeprecatedViewAccessibility
Related to #21342
Pull Request resolved: https://github.com/facebook/react-native/pull/21422
Reviewed By: yungsters
Differential Revision: D10132659
Pulled By: RSNara
fbshipit-source-id: 68c371230c69ed37c3e44bf8a36043adb04afc78
Summary:
This PR fixes an obscure rendering bug on iOS for borders with asymmetric radii. It appears to be a problem with the custom drawing that React Native performs when it cannot use native UIKit/CoreAnimation border drawing.
Pull Request resolved: https://github.com/facebook/react-native/pull/21208
Differential Revision: D10130120
Pulled By: hramos
fbshipit-source-id: d9fbc5c622c060db15658d038a068216b47bb26d
Summary:
This PR exposes the `onScrollToTop` event on iOS using the same event-forwarding infrastructure as other ScrollView events. (As such, its `nativeEvent` object reflects the same fields as other ScrollView events.)
Motivation:
----------
If your app is only interested in knowing the position of a ScrollView after a scroll has completed, it can use `onScrollEndDrag` and `onMomentumScrollEnd` to inspect the `contentOffset` after a drag-initiated scroll has finished. (This is much less expensive than observing the `onScroll` event if you only want to know the end position.) However, neither of these `End` events fire if the ScrollView is scrolled to the top by tapping the status bar.
By exposing `onScrollToTop`, it is now possible for an app to cheaply know when such a scroll has completed.
Pull Request resolved: https://github.com/facebook/react-native/pull/21204
Differential Revision: D9943618
Pulled By: hramos
fbshipit-source-id: ac5ee42b7f12d94655ffda617f8f811138da7f6f
Summary: In some cases, the custom implementation of this prop is undesirable, so this allows to turn it off.
Reviewed By: yungsters
Differential Revision: D9759228
fbshipit-source-id: 4f61cd900c2da9046977c11a61606a4f5f961177
Summary: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Summary:
@public
Now all configurations or border styles are supported by RCTViewComponentView (and all subclasses).
Reviewed By: sahrens
Differential Revision: D9631868
fbshipit-source-id: 3a5b141ac5ffa9c28f4ebb0718f2fc935b8f1a75
Summary:
@public
We will use that in RCTFabric module.
Reviewed By: sahrens
Differential Revision: D9631866
fbshipit-source-id: a8e4074189359ad6014d0506d6a1e020b5d0d330
Summary:
Legacy navigator impl. There are other alternatives that should be used instead.
Part of the slimmening effort as described here: https://github.com/react-native-community/discussions-and-proposals/issues/6
Reviewed By: TheSavior
Differential Revision: D9677824
fbshipit-source-id: 24ae500751d2a8c398f246d36604a58f0b3c113b
Summary:
D8842691 split AccessibilityTraits into multiple RN properties. However, the accessor code did not support REMOVING traits.
This results in buttons that were disabled (AccessibilityTraits & NotEnabled === true) never being enabled.
Fix the issue by making the split accessors properly mask in the bits, allowing you unset them without disturbing bits managed by the other accessor.
NOTE: setting AccessibilityTraits and AccessibilityRole or AccessibilityStates will still result in bugs.
Reviewed By: shergin
Differential Revision: D9661970
fbshipit-source-id: 77d70dd0754f2eaf8cbf895bfc13757c697a76d8
Summary: Added `snapToStart` and `snapToEnd` props to ScrollView which work together with `snapToOffsets` and determine whether the beginning and end of the list automatically count as snap offsets or not. If not, the list is allowed to free-scroll between its start/end and the first/last snap offset.
Reviewed By: sahrens
Differential Revision: D9442386
fbshipit-source-id: 47a5fdb20f884542434b01b1f0a486ed2b478c6e
Summary:
* Added snapToOffsets prop to ScrollView. Allows snapping at arbitrary points.
* Fixed pagingEnabled not being overridden by snapToInterval on iOS.
* Fixed Android *requiring* pagingEnabled to be defined alongside snapToInterval.
* Added support for decelerationRate on Android.
* Fixed snapping implementation. It was not calculating end position correctly at all (velocity is not a linear offset).
* Resolves https://github.com/facebook/react-native/issues/20155
* Added support for new content being added during scroll (mirrors existing functionality in vertical ScrollView).
* Added support for snapToInterval.
* Resolves https://github.com/facebook/react-native/issues/19552
Reviewed By: yungsters
Differential Revision: D9405703
fbshipit-source-id: b3c367b8079e6810794b0165dfdbcff4abff2eda
Summary:
Currently `SafeAreaView` works only on iOS 11, because implemented in terms of native safeArea API, that not exists in older iOS versions. But this make it hard to use the component in real applications, because content will be under top bars on older versions of iOS and no reliable way to workaround this in js. More motivation in #17638
This changeset emulate safe area in terms of `UIViewController` layout guides API if safeArea not available.
Fixes#17638, #18255
I run RNTester with these simulators: iPhone6 (9.3), iPhone6 (10.0), iPhone6 (11.2), iPhoneX (11.2)
- Start RNTester application
- Look on top header, it should not overlap status bar
- Go to the `<SafeAreaView>` example, open modal
- Modal area should not overlap status bar
<img src="http://vovkasm.skitch.vovkasm.org/iPhone6_10_20662C5B.png" width="40%"> <img src="http://vovkasm.skitch.vovkasm.org/iPhone6_11_20662CC8.png" width="40%">
<img src="http://vovkasm.skitch.vovkasm.org/iPhone6_10_pr_20662DE6.png" width="40%"> <img src="http://vovkasm.skitch.vovkasm.org/iPhone6_11_pr_20662DA8.png" width="40%">
[IOS] [BUGFIX] [SafeAreaView] - Make SafeAreaView to work on iOS < 11
Pull Request resolved: https://github.com/facebook/react-native/pull/18534
Reviewed By: PeteTheHeat, shergin
Differential Revision: D9166052
Pulled By: hramos
fbshipit-source-id: c086e1ae4af13110a7453b770ca75b6e0d5321ea
Summary:
@public
We can't dynamically link `WebKit` because doing so will impact cold start of all our Apps.
This diff includes a few changes:
1. Weakly link the `WebKit` framework in the `ReactInternal` library, so that the compiler doesn't die when it encounters a WebKit symbol.
2. Undo dynamic linking of WebKit in Catalyst.
3. Undo dynamic linking of WebKit in AdsManager
4. Before the first `WKWebView` is instantiated, dynamically load the `WebKit` framework.
The end result of these changes is that WebKit will be loaded only when it's going to be used.
Reviewed By: mmmulani
Differential Revision: D6564328
fbshipit-source-id: a45a44e774d0c61c1fb578a6fa3d16bb08f68ac9
Summary:
@public
This diff introduces two new props:
1. **automaticallyAdjustContentInsets**: Controls whether to adjust the content inset for web views that are placed behind a navigation bar, tab bar, or toolbar. The default value is true.
1. **contentInset**: The amount by which the web view content is inset from the edges of the scroll view. Defaults to {top: 0, left: 0, bottom: 0, right: 0}.
**Note:** There're some inconsistencies between how `UIWebView` and `WKWebView` render web pages with respect to the `contentInset` property. These two videos illustrate the problem:
**UIWebView**
[[ P58674349 | Playground.js ]]
https://pxl.cl/9R9V
**WKWebView**
[[ P58674348 | Playground.js ]]
https://pxl.cl/9R9W
Here's a stack overflow answer describing the problem: https://stackoverflow.com/a/35472603.
Reviewed By: shergin
Differential Revision: D6432181
fbshipit-source-id: aee6dac65d28435381ebec90519474b4707c7bab
Summary:
@public
This diff implements background colors for the `RCTWKWebView` component by proxying the background color prop to the underlying `WKWebView` and its underlying `UIScrollView`.
There's few differences between `backgroundColor` in `RCTWebView` and `RCTWKWebView` implementations:
1. With `UIWebView,` the background color gets applied after the page loads. With `WKWebView`, this isn't necessarily true. This results in a white flicker on solid backgrounds because sometimes, the background color is set before the page loads. This video illustrates the problem: https://our.intern.facebook.com/intern/px/p/9QBH
1. As far as I can tell, `WKWebView` doesn't handle transparent backgrounds correctly. Either that, or I could be setting the background color incorrectly. I set the background color to `rgba(1, 1, 1, 0.5)` and recorded how both `RCTWebView` and `RCTWKWebView` render. These two videos indicate the differences:
**RCTWebView: Lighter background**
https://pxl.cl/9R13
**RCTWKWebView: Darker background**
https://pxl.cl/9R1b
I tried to replicate this on the web. According to [[ https://our.intern.facebook.com/intern/fiddle/zCHu/ | this fiddle ]], `RCTWebView` is correct. Clearly, RCTWKWebView is rendering transparent backgrounds a bit darker than necessary. This doesn't seem simple to debug, so I've created a task to document this work: T23815343. I'll get to it eventually.
Reviewed By: shergin
Differential Revision: D6398209
fbshipit-source-id: 1812cb68133bc18a3278f6b328d7b085362528b0
Summary:
When text is rendered in `WKWebView` WebKit component, the component itself can detect things like phone numbers, flight numbers, links, etc. and render them with additional functionality.
For example, when the text `apple.com` is detected, if the `link` data detector type is enabled, the web view will actually render a link that takes the user to the Apple home page.
In this diff, I implement the `dataDetectorTypes` prop. The data detector types supported are:
1. phoneNumber
1. link
1. address
1. calendarEvent
1. trackingNumber
1. flightNumber
1. lookupSuggestion
These enums are documented in the [[ https://developer.apple.com/documentation/webkit/wkdatadetectortypes | WKDataDetectorTypes docs ]].
Reviewed By: shergin
Differential Revision: D6392546
fbshipit-source-id: 4dd373f0ac52f898163cd959eeef6672e55b42a6
Summary:
HTML video elements can have the `autoplay` attribute, which forces them to play automatically whenever they load on the page.
In this diff, I introduce a new prop `mediaPlaybackRequiresUserAction`, which allows us to control whether video or audio element autoplays even when `autoplay` is set.
Reviewed By: shergin
Differential Revision: D6382256
fbshipit-source-id: 617508653910d600bc43f7f68c6dfd17ab1b6dd8
Summary:
For iPhones with small screen sizes (e.g: iPhone 5s), inside the `<WKWebView/>` component, videos will play in fullscreen mode. In this diff, I introduce a prop called `allowsInlineMediaPlayback` that when set to true, will allow videos to play inline.
**Note:** For videos to play inline, the HTML video element must also have a `playsinline` attribute on it.
Reviewed By: shergin
Differential Revision: D6379770
fbshipit-source-id: a0130720ffede6c24a90cad0c97a75b657d77017
Summary:
@public
This diff introduces the native backend for a new WKWebView prop: `onShouldStartLoadWithRequest`.
In the final component, the behaviour will be as follows: Whenever the user navigates around in the web view, we call `onShouldStartLoadWithRequest` with the navigation event. If `onShouldStartLoadWithRequest` returns `true`, we continue the navigation. Otherwise, we abort it.
Reviewed By: shergin
Differential Revision: D6370317
fbshipit-source-id: e3cdd7e2a755125aebdb6df67e7b39116228bdfb
Summary:
@public
This diff implements the `reload` and `stopLoading` methods for `WKWebView`. Their functionality is self-explanatory.
Reviewed By: shergin
Differential Revision: D6369292
fbshipit-source-id: ba176f4406e0a67606406f36dd66f7615f4796c3
Summary:
@public
This diff implements the `goForward` and `goBack` methods on `WKWebView`.
1. `goForward` moves the web view one screen forward in the browser history.
1. `goBack` moves the web view one screen back in the browser history.
Reviewed By: shergin
Differential Revision: D6367495
fbshipit-source-id: e100ca00e92a6eaa30d2af1af642ba79a9c9feae
Summary:
@public
This diff introduces a method called `injectJavaScript(script)` on the React Native `<WKWebView/>` component. When called with a string, it evaluates that string as JavaScript within the web view.
Reviewed By: shergin
Differential Revision: D6367445
fbshipit-source-id: f68afeff42535dc991747f96a63f3c956faf13d3
Summary:
@public
The content that renders within the `WKWebView` instance actually renders inside a `UIScrollView`. On that scroll view, we can adjust the `decelerationRate`, which controls how fast the view stops scrolling after the user lets go while scrolling.
In this diff, I implemented the `decelerationRate` prop for `WKWebView`, which gets forwarded to the `UIScrollView` instance underlying the web view.
**Note:** Even though we accept a floating point value for the deceleration rate, the native `UIScrollView` component only allows two inputs:
1. `UIScrollViewDecelerationRateNormal`: 0.998
2. `UIScrollViewDecelerationRateFast`: 0.99
As far as I know, it seems to just round up to the nearest valid `CGFloat` (or down if number > 0.998), for any invalid numbers.
Reviewed By: mmmulani
Differential Revision: D6307262
fbshipit-source-id: 98c4395702415aa36519f9e9bd84f043be3a5881
Summary:
@public
The content of `WKWebView` renders within a scrollview. In this diff, I'm introducing the prop `scrollEnabled` to allow developers to control whether scrolling is enabled within the scroll view, or not.
Reviewed By: mmmulani
Differential Revision: D6307001
fbshipit-source-id: 5a199c6c3b8535e45a5a3cb6041e822bb7af2362
Summary:
@public
The content that loads inside `WKWebView` renders within a `ScrollView`. Suppose the user pulls the page down when its top edge hits the top edge of the web view. Then, one of two things can happen as the user continues to pull the page down:
1. We let the page be pulled past the top edge of the web view.
1. We fix the page's vertical offset to 0 so that it doesn't move past the top edge of the web view.
The property that controls this behaviour is `<WKWebView bounces={true|false}/>`. In this diff, I implement it.
Reviewed By: mmmulani
Differential Revision: D6306866
fbshipit-source-id: 7763df78676215c3dd0bd7a029497a6eca1873ab
Summary:
@public
This diff implements message passing between the `WKWebView` and React Native. As with `<WebView/>`, we can only send/receive strings.
**Usage:**
1. Set `messagingEnabled` to `true`.
1. To send data from the web view to React Native, call `postMessage(data)` within the web view. This forces React Native to execute the `onMessage` prop on the `WKWebView` component. `onMessage` will be called with an event `e`, where `e.nativeEvent.data` will be the data you passed into `postMessage`.
1. To send data from React Native to the web view, call `UIManager.dispatchViewManagerCommand` to dispatch the `UIManager.RCTWKWebView.Commands.postMessage` command. Look at [[ https://fburl.com/u1wusf2f | this part of the existing `<WebView/>` ]] component for more details. After you make the call, React Native will dispatch a `'message'` event to the `document` object within the webview. You can listen to the event by doing `document.addEventListener('message', callback)`. Let the event dispatched be `e`. Then, `e.data` is the data you sent over from React Native.
[[ P58627181 | This Playground.js ]] illustrates the usage.
Reviewed By: shergin
Differential Revision: D6304850
fbshipit-source-id: 29075ef753296e9fb5a9cddeb1ad0f4ff7e28650
Summary:
@public
This diff includes four very straightforward changes:
1. Whenever the WebView starts loading, the `onLoadingStart` hook should be executed. The event passed into this hook should be decorated with the `navigationType`.
1. Whenever the WebView errors out while loading, the `onLoadingError` hook should be executed.
1. Whenever the WebView finishes loading (without any errors), the `onLoadingFinish` hook should be executed.
1. The serialized JavaScript passed into the `injectedJavaScript` prop should be executed when the WebView finishes loading. After execution finishes, the `onLoadingFinish` prop should be called with the serialized completion value of this JavaScript.
Reviewed By: shergin
Differential Revision: D6293532
fbshipit-source-id: 21407c766f73413046823ae605afc21e85cf9db6
Summary:
@public
`UIWebView` has been deprecated and replaced by `WKWebView`. This diff introduces a new component `WKWebView` that simply renders a `WKWebView` on iOS.
This is the first in the stack of many diffs that'll be required to fully replace `UIWebView` with `WKWebView` in the `<WebView/>` React Native component. Eventually, I hope to introduce a prop called `useWebKitImplementation`, which, when true, will force RN to use `WKWebView` instead of `UIWebView` for the `<WebView/>` component.
The only thing that's been implemented so far is the `source` property.
Reviewed By: mmmulani
Differential Revision: D6266100
fbshipit-source-id: 65862e34bd98db7fff0349cf26888afee43a56e4
Summary:
Calls abort() in cases where malloc returns NULL.
Checking the return value from malloc is good practice and is
required to pass a [Veracode security scan](https://www.veracode.com/). This will let
developers who are required to submit their software to Veracode
use React Native.
Pull Request resolved: https://github.com/facebook/react-native/pull/20173
Differential Revision: D9235096
Pulled By: hramos
fbshipit-source-id: 9fdc97f9e84f8d4d91ae59242093907f7a81d286
Summary:
This adds the accessibilityHint for View, Text and Touchable* on iOS.
The accessibilityHint provides some more information about an element
when the accessibilityLabel is not enough.
The accessibilityHint is a core accessibility property on iOS.
From https://developer.apple.com/documentation/objectivec/nsobject/1615093-accessibilityhint:
> An accessibility hint helps users understand what will happen when they perform an action on the accessibility element when that result is not obvious from the accessibility label.
Related issue: https://github.com/facebook/react-native/issues/14706
The npm scripts `test`, `flow`, `lint` and `prettier` are satisfied.
I added a couple of examples to the RNTester app. The Accessibility Inspector on Mac helps debugging accessibility stuff on a simulator, but it does not show the accessibilityHint. Therefore I tested the RNTester app on an iPhone 8 device using VoiceOver to verify the hint functionality. It works fine, and I've tested disabling and enabling "read hints" in the VoiceOver settings on the phone.
https://github.com/facebook/react-native-website/pull/222
[IOS][FEATURE][Accessibility] - Add accessibilityHint for View, Text, Touchable* on iOS
Closes https://github.com/facebook/react-native/pull/18093
Reviewed By: hramos
Differential Revision: D7230780
Pulled By: ziqichen6
fbshipit-source-id: 172ad28dc9ae2b67ea256100f6acb939f2466d0b
Summary:
When I bridged FBPullToRefresh to RN, the integration with ScrollView caused a bug on OSS
TLDR; assuming that a scrollview subview that implemented UIScrollViewDelegate protocol was a custom PTR was a bad idea. This caused some scrollviews to break in OSS. The solution is to define a more explicit protocol.
Further details here:
https://github.com/facebook/react-native/issues/20324
Reviewed By: mmmulani
Differential Revision: D8953893
fbshipit-source-id: 98cdc7fcced41d9e98e77293a03934f10c798665
Summary:
Context:
After discussing with yungsters, `currentViewStates` is a very ambiguous name for a prop, especially because there are only two possible values. From a developer's perspective, it makes more sense to just call them `accessibilityStates` because the main use for them is to add states to Talkback and Voiceover.
Also, the actual implementation of what we're changing under the hood in Native Code is abstracted away from developers using React Native, so as long as behavior is as they would expect, it makes more sense to change the name into a clear one.
Changes in this Diff:
Renamed the view property exposed to native iOS code from `currentViewStates` to `accessibilityStates`
Also deleted setting the userInteractionEnabled view property, because we want to keep it as just an accessibility property.
Reviewed By: PeteTheHeat
Differential Revision: D8896821
fbshipit-source-id: 95674c9b7295f5b9e60994c297acdee83f6226d7
Summary:
Added Native iOS functionality for prop currentViewStates.
On iOS, this property modifies both the view property userInteractionEnabled and also adds corresponding UIAccessibilityTraits to the view.
If disabled is passed in, userInteractionEnabled of the view will be set to false.
The value that is passed into currentviewStates is converted to a UIAccessibilityTrait Enum and masked in with existing UIAccessibilityTraits on that native view.
The native implementation for accessibilityRole is also changed to also mask new UIAccessibilityTraits with existing ones.
Reviewed By: PeteTheHeat
Differential Revision: D8842691
fbshipit-source-id: 919267300c70efed93a7a92377a0178bd8885eb5
Summary:
Because we're now separating accessibilityTraits into accessibilityRole and accessibilityState, we're going to only allow one role to be set, and allow on preset combinations of roles that make sense.
This change adds iOS functionality to the role image button because a popular accessibilityTrait combination is image and button.
Reviewed By: ikenwoo
Differential Revision: D8847012
fbshipit-source-id: da386dbf82cb3854d14c228a1116da9f4067fe93
Summary: Removed Accessibility Trait TabBar for iOS compatibility Issues, since tabbar is only available on iOS 10+
Reviewed By: PeteTheHeat
Differential Revision: D8822469
fbshipit-source-id: 34bf00eb930f631a5a4effa0a4159da07c1573f6
Summary:
Added a new property to View for Accessibility called `accessibilityRole`. This property merges functionality of existing properties: `accessibilityTraits` (iOS) and `accessibilityComponentType` (android).
Currently, nine values are supported with equivalent behavior as `accessibilityTraits` (iOS) when `accessibilityRole` is set on iOS Voiceover and Android TalkBack
```
| 'none'
| 'button'
| 'link'
| 'search'
| 'image'
| 'keyboardkey'
| 'text'
| 'adjustable'
| 'tabbar'
```
They currently support similar behavior on talkback on Android and voice over on iOS
Does not break functionality of existing properties, but have not tested for behavior of setting both this one and the old one.
* iOS - I added a property accessibilityRoles, and basically remapped it to the same thing as accessibilityTraits. I also added in enum mappings for keyboardkey and tabbar.
* Android - Also added a property accessibilityRoles, from the Android side. For the underlying native functionality, I built a helper class that is based off of AccessibilityRolesUtil.java from the accessibility team. Biggest changes made are that I defined my own enums if needed, and also set some properties to match the functionality of iOS Accessibility Traits. I also handled the logic for switch/case statements of setting roles for the android side on this file. Also, I currently haven't localized strings for setRoleDescription, but plan to.
* Javascript - I added a view property accessibilityRoles in ViewPropTypes.
Reviewed By: blavalla
Differential Revision: D8756225
fbshipit-source-id: e03eec40cce86042551764f433e1defe7ee41b35
Summary:
Added Check for iOS 11 before setting property for `accessibilityIgnoreInvertColor`
Builds on top of
https://our.intern.facebook.com/intern/diff/D8549084/
Reviewed By: shergin
Differential Revision: D8599698
fbshipit-source-id: c5cc26b4c1c20fb9cca5bfe7143fa9dcb217a2d7
Summary:
@public
Added a property `accessibilityIgnoresInvertColors (boolean)` to Views which allows the Apple API `accessibilityIgnoresInvertColors` to be used in React Native.
Now, when a user has Display: Smart Invert enabled, you can set the property to be true, and things like photos and views with the property set to true will no longer be inverted when Smart Invert is enabled.
This property can also be applied to the Image Component.
Example Use Case:
```
<Image accessibilityIgnoresInvertColors={true} />
```
```
<View accessibilityIgnoresInvertColors={true} />
```
| Before | After |
| ------ | ----- |
|  | 
Reviewed By: PeteTheHeat
Differential Revision: D8549084
fbshipit-source-id: 82a3bc73c9e6d75d6b50ba013b88127f07692641
Summary: Moving target deployment to iOS 9.0+ from now on, removing customization for iOS 8.
Reviewed By: shergin
Differential Revision: D8053439
fbshipit-source-id: 292c58f15c6e6caf8b28d15c1521812d6ed675c5
Summary:
`RCTFontTests` test in RNTester is broken if the target deployment is <= OS 8.2. This is because RCTFont.mm overrides the OS-defined values, but the override is only visible to RCTFont.mm internals. As the result, when the Unit test tries to create UIFont of the "same" weight, it got a different font - most likely due to internal floating rounding errors.
To mitigate, code that wants to test out internals of RCTFont should import RCTFontConstantsOverride.h
Reviewed By: mmmulani
Differential Revision: D7900954
fbshipit-source-id: e5814ef059a8afdfb5205ca1af46c41b3cfd4318
Summary:
… is not a protoype #19086
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
<!--
Required: Write your motivation here.
If this PR fixes an issue, type "Fixes #issueNumber" to automatically close the issue when the PR is merged.
-->
Fixes#19086
Related to react-native-navigation issue #3019
<!--
Required: Write your test plan here. If you changed any code, please provide us with
clear instructions on how you verified your changes work. Bonus points for screenshots and videos!
-->
Created a fresh react native >= 0.55.2 project and only install React Native Navigation. The error "This function declaration is not a prototype" message occurs.
Downgrading to React Native 0.54.4 builds fine.
<!--
Does this PR require a documentation change?
Create a PR at https://github.com/facebook/react-native-website and add a link to it here.
-->
No documentation change
<!--
Required.
Help reviewers and the release process by writing your own release notes. See below for an example.
-->
[iOS] [BUGFIX] [react-native-navigation] - For compatibility with react-native-navigation >= 2.0.2237 https://github.com/facebook/react-native/issues/19086
<!--
**INTERNAL and MINOR tagged notes will not be included in the next version's final release notes.**
CATEGORY
[----------] TYPE
[ CLI ] [-------------] LOCATION
[ DOCS ] [ BREAKING ] [-------------]
[ GENERAL ] [ BUGFIX ] [ {Component} ]
[ INTERNAL ] [ ENHANCEMENT ] [ {Filename} ]
[ IOS ] [ FEATURE ] [ {Directory} ] |-----------|
[ ANDROID ] [ MINOR ] [ {Framework} ] - | {Message} |
[----------] [-------------] [-------------] |-----------|
EXAMPLES:
[IOS] [BREAKING] [FlatList] - Change a thing that breaks other things
[ANDROID] [BUGFIX] [TextInput] - Did a thing to TextInput
[CLI] [FEATURE] [local-cli/info/info.js] - CLI easier to do things with
[DOCS] [BUGFIX] [GettingStarted.md] - Accidentally a thing/word
[GENERAL] [ENHANCEMENT] [Yoga] - Added new yoga thing/position
[INTERNAL] [FEATURE] [./scripts] - Added thing to script that nobody will see
-->
Closes https://github.com/facebook/react-native/pull/19089
Differential Revision: D7841198
Pulled By: shergin
fbshipit-source-id: 31638274055c3f143342d2d6dde6d4af7a2ac304
Summary:
This fixes perf regression which was introduced by recent refactoring of the layout process.
That is how it used to be:
114c258045/React/Views/RCTShadowView.m (L160-L166)
Note: We have to resert this flag in indication that we already applied those changes and we don't need to traverse this subtree until it is changed again.
Reviewed By: fkgozali
Differential Revision: D7343564
fbshipit-source-id: ba7e00bc5fe4992d777eed20ba0d959fd8f6c037
Summary:
This change is a revert of [#17927](https://github.com/facebook/react-native/pull/17927) pull-request.
The pull-request caused an issue with the keyboard covering the text field at the bottom of the scroll view.
Reviewed By: shergin
Differential Revision: D7246609
fbshipit-source-id: 149f825274c4fa79ab593f1bae3602667d16ddee
Summary:
Related to: #15454
Motivation: Improve tvOS feeling for TouchableHighlight
- When you select the button he is focus and the underlay is show
- When you press the button, there is an animation, but after the animation, the focus is on the button and the underlay is show
Play with tvParallaxProperties on tvOS, test with and without patch just to see the actual behaviour
```
<TouchableHighlight
tvParallaxProperties={{
enabled: true,
shiftDistanceX: 0,
shiftDistanceY: 0,
tiltAngle: 0,
magnification: 1.1,
pressMagnification: 1.0,
pressDuration: 0.3,
}}
underlayColor="black"
onShowUnderlay={() => (console.log("onShowUnderlay")}
onHideUnderlay={() => (console.log("onHideUnderlay")}
onPress={() => (console.log("onPress")}
>
<Image
style={styles.image}
source={ uri: 'https://www.facebook.com/images/fb_icon_325x325.png' }
/>
</TouchableHighlight>
```
Closes https://github.com/facebook/react-native/pull/15455
Differential Revision: D6887437
Pulled By: hramos
fbshipit-source-id: e18b695068bc99643ba4006fb3f39215b38a74c1
Summary:
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html
Happy contributing!
-->
The scrollToOffset method of RCTScrollView for iOS does not include bound check for the scroll offset provided to the method. This can cause the whole view to scroll out of screen if the offset provided is greater than the bounds of the View.
The same does not happen on Android, where the scroll halts once the last item of the scrollView is in the viewport.
I have added bounds check so the offset resets to the MaxOffset which makes sure the view does not scroll out of the viewport.
The issue can be observed in the following snack:
https://snack.expo.io/H1363Uo8f
To test my changes I ran the code provided in the snack above with the react-native dependency pointing to my branch. As can be see in the video attached below, the scroll halts once it hits the end of the ScrollView even if the scroll offset provided is higher than the bounds of the ScrollView. It also does not scroll up for negative scroll offset.
[IOS] [BUGFIX] [ScrollView] - Added bounds check to prevent ScrollView from scrolling to an offset which is out of bounds of the ScrollView for iOS.
Closes https://github.com/facebook/react-native/pull/17927
Differential Revision: D7014466
Pulled By: shergin
fbshipit-source-id: a817738d08e1057a4c70f43373132f88fa1461c4
Summary:
Includes React Native and its dependencies Fresco, Metro, and Yoga. Excludes samples/examples/docs.
find: ^(?:( *)|( *(?:[\*~#]|::))( )? *)?Copyright (?:\(c\) )?(\d{4})\b.+Facebook[\s\S]+?BSD[\s\S]+?(?:this source tree|the same directory)\.$
replace: $1$2$3Copyright (c) $4-present, Facebook, Inc.\n$2\n$1$2$3This source code is licensed under the MIT license found in the\n$1$2$3LICENSE file in the root directory of this source tree.
Reviewed By: TheSavior, yungsters
Differential Revision: D7007050
fbshipit-source-id: 37dd6bf0ffec0923bfc99c260bb330683f35553e
Summary:
This is reimagining of interoperability layer between Yoga and ShadowViews (at least in Yoga -> RN part).
Goals:
* Make it clear and easy.
* Make clear separation between "what layout what", now parent always layout children, noone layout itself.
* Make possible to interleave Yoga layout with custom imperative layout (may be used in SafeAreaView, Text, Modal, InputAccessoryView and so on).
Reviewed By: mmmulani
Differential Revision: D6863654
fbshipit-source-id: 5a6a933874f121d46f744aab99a31ae42ddd4a1b
Summary:
This change enables built-in Yoga mechanism which rounds producing layout metrics to closest "pixel" values.
See previous diff for more context.
Reviewed By: fkgozali
Differential Revision: D6889762
fbshipit-source-id: bc2eea44704db4b377e2e14fab9f67be8c935719
Summary:
> Okay, I don't remember where we first met
> But hey, admitting is the first step
This issue has a looong history.
The original algorithm was introduced by Nick Lockwood (nicklockwood Hey Nick! We miss you!) a while ago and from the very beginning this has one small error that basically makes it useless (try to find it yourself, it's fun!)
The problem was discovered and fixed twice (D4133643, D4983054), but every time we found that our <Text> infra was not ready for this, so we reverted and abandoned the change. As part of the last attempt to finally solve the issue, I ported the algorithm to Yoga where it lives today and works very well for Lytho and CK.
For now, the vision is clear:
* The basic algorithm should live in Yoga for unification and performance reasons.
* We still have to have `absolutePostion` as part of this API because it might be useful for some components which implement its own custom/non-Yoga-based layout.
* We have to enable it in RN eventually.
So, this is the first step: Removing old, broken code which we don't plan to fix and use.
Make React Native crisp again!
Reviewed By: fkgozali
Differential Revision: D6888662
fbshipit-source-id: 2e5098d9935dcbe05d66c777dad3a9ec8ac87ec3
Summary:
It's unused.
Use `display` prop instead to control visiblity of the view.
Reviewed By: fkgozali
Differential Revision: D6888104
fbshipit-source-id: dd37a365033ec36bdfcfa305ec6a965a10dec2cd
Summary: Another juicy leftover from old Text implementation.
Reviewed By: fkgozali
Differential Revision: D6887942
fbshipit-source-id: d0363d06d566554c03d0ae3293597daf9c387028
Summary: This is leftovers from last <Text> reimplementation; nobody uses it and it does not hooked up with UIManager.
Reviewed By: fkgozali
Differential Revision: D6887795
fbshipit-source-id: 9e2e29af4ba959270096eeb494666d1cacaeba32
Summary: It's been more than two years; I think everyone already migrated and learned the new behavior.
Reviewed By: emilsjolander
Differential Revision: D6829885
fbshipit-source-id: a86d56fb7235a137e9ce6e360d7ae2224b047313
Summary:
[this commit](2e1707d0e6) which was just a small refactor broke refreshControl behavior - if we render FlatList with refreshing=true, the refreshControl won't be visible on initial render.
The problem is, the [previous beginRefreshing method](2e1707d0e6 (diff-cfafa8d7e42ab87ab863f917e187a4aeL51)) was renamed to `beginRefreshingProgramatically` and the old call was left in one place [here](2e1707d0e6 (diff-cfafa8d7e42ab87ab863f917e187a4aeR47)).
Now, I am not sure what kind of jumping the mentioned commit was fixing, but since this fix only concerns the initial render, I believe it will not influence the jumping fix.
I have tested this locally in my app, can provide a video if needed.
none
[IOS] [BUGFIX] [RefreshControl] - Make sure refreshControl shows up on initial render if specified
Closes https://github.com/facebook/react-native/pull/17727
Differential Revision: D6827402
Pulled By: shergin
fbshipit-source-id: 25849244e87af54f25d636b6ade7adcf88958980
Summary:
This is a complete rewrite of RCTText, the part of React Native which manages Text and TextInput components.
Key points:
* It's understandable now. It follows a simple architectural pattern, and it's easy to debug and iterate. Text flow layout is a first-class citizen in React Native layout system now, not just a wired special case. It also brings entirely new possibilities such as nested interleaving <Text> and <View> components.
* All <Text>-specific APIs were removed from UIManager and co (it's about ~16 public methods which were used exclusively only by <Text>).
* It relies on new Yoga measurement/cloning API and on-dirty handler. So, it removes built-in dirty propagation subsystem from RN completely.
* It caches string fragments properly and granularly on a per-node basis which makes updating text-containing components more performant.
* It does not instantiate UIView for virtual components which reduces memory utilization.
* It drastically improves <TextInput> capabilities (e.g. rich text inside single line <TextInput> is now supported).
Screenshots:
https://cl.ly/2j3r1V0L0324https://cl.ly/3N2V3C3d3q3R
Reviewed By: mmmulani
Differential Revision: D6617326
fbshipit-source-id: 35d4d81b35c9870e9557d0211c0e934e6072a41e
Summary:
Builds off of cae7179c94
- Make the prop a dictionary for more configuration options
- Rename `maintainPositionAtOrBeyondIndex` -> `maintainVisibleContentPosition` + `minIndexForVisible`
- Add autoscroll threshold feature
Given the async native of RN JS and background layout, there is no way to trigger the scrollTo from JS without risking a delay, so we add the feature in native code.
== Test Plan ==
ScrollViewExample:
https://youtu.be/pmY8pxC9PRs
Reviewed By: shergin
Differential Revision: D6729160
fbshipit-source-id: 70f9bae460ce84567857a4f696da78ce9b3b834c
Summary:
Another trivial sugar/helper to access computed by Yoga layout metrics.
We will use it soon in the new Text render/layout engine.
Reviewed By: mmmulani
Differential Revision: D6671979
fbshipit-source-id: d36933415c2fa50bae5cc171434d8f0b281955b7
Summary:
== Problem / Background ==
Most lists paginate in a single direction (standard infinite list), but some paginate in both directions. Most common example is a chat thread where new messages show up on the bottom, and old content can be loaded by scrolling up. Comment threads are another example.
Right now, adding content to the bottom of a scroll view is smooth - the content doesn't jump. But when adding to the top of the scrollview, the content gets pushed down, which is jarring (note this may appear reversed because of inverting the list which is common for chat applications).
== Approach ==
The basic idea is simple - we set a flag in JS, then for every uimanager transaction, we record which is the first eligible and visible view in the ScrollView, and compare it's new origin to the old one. If it has changed, we update the contentOffset of the ScrollView to compensate.
This is done by observing `willPerformMounting` directly (only from scrollviews that have this new property set), and then observing the prev state with prependUIBlock and making the update synchronously in addUIBlock to avoid any flicker.
There is also a way to skip views that we don't care about, like a spinner at the top of the view that we don't want to stay in place - we actually want it to get pushed up by the new content, replaced visually in the viewport.
== Notes ==
Most chat applications will probably want to do a scrollToTop when new content comes in and the user is already scrolled at or near the bottom.
This is glitchy if visible children are re-ordered, which could be fixed with additional logic, but it doesn't come up in the type of applications we're targetting here so punting on that.
== Test Plan ==
https://youtu.be/4GcqDGz9eOE
Reviewed By: shergin
Differential Revision: D6696921
fbshipit-source-id: 822e7dfcb207006cd1ba098356324ea81f619428
Summary:
Fix issue #17027 (`RCTModalHostView` has a tvOS dependency that was not wrapped in `TARGET_OS_TV`)
Existing test automation should pass.
[GENERAL] [BUGFIX] [tvOS] Fix cocoapods compile issue in RCTModalHostView
Closes https://github.com/facebook/react-native/pull/17502
Differential Revision: D6688166
Pulled By: hramos
fbshipit-source-id: 38297f439f75a8303f59f83b92e004c6c73d9bf6
Summary:
That's now possible thanks to new Yoga's clonning API.
That will speed up RCTSurface measuring (see the next diff in stack) and should illuminate a class of problems in CK interop layer.
We also will use it in the new text layout engine (in React Native).
Reviewed By: gkassabli
Differential Revision: D6665632
fbshipit-source-id: e94909f0af89e9c7fc5e46b95090ecb3c52546a2
Summary:
Yoga and CoreGraphics have different opinions about how "infinity" value
should be represented.
Yoga uses `NAN` which requires additional effort to compare all those values,
whereas GoreGraphics uses `GFLOAT_MAX` which can be easyly compared with
standard `==` operator.
Messing with this can cause super weired bugs like 100% CPU load for couple of seconds somewhere in CoreGraphics.
Reviewed By: mmmulani
Differential Revision: D6665633
fbshipit-source-id: b6236c6fa50d1f8fb0c9576203922f7b24b7301e
Summary:
Those are supposed to replace all `dirtyText`, `dirtyPropagation`, `isPropagationDirty`, `setTextComputed`, `isTextDirty` and so on.
We will use it widely soon (and remove all old ones).
Reviewed By: mmmulani
Differential Revision: D6665634
fbshipit-source-id: 3c1db7154e90b71446756f2495627b163c779996
Summary:
It's always bothered that we have this protocol and I figured it could just be merged with RCTWrapperViewController.
Closes https://github.com/facebook/react-native/pull/17290
Reviewed By: mmmulani
Differential Revision: D6611544
Pulled By: javache
fbshipit-source-id: a50b9d5adbeb2c48dbadbbfc1c77ccf6d1aae144
Summary:
Nobody uses it.
If the reference to the bridge is available (which is should be case for testing purposes at least), it is easy to get same information.
Reviewed By: mmmulani
Differential Revision: D6596376
fbshipit-source-id: 066eeb1e9465b4e0cc9d9b5b6bf41722450870e4
Summary:
Motivation:
* Current implementation of `didUpdateReactSubviews` relies on `processUpdatedProperties:parentProperties:` method of RCTShadowView, which we plan to remove.
* The existing implementation does not call handlers on unmounted nodes (because they are not part of traversing tree), which is not correct.
* The current implementation is tight with RCTComponentData, which is conceptually wrong, it should be a UIManager thing.
* The new implementation must be much more performant because of simplicity. (We can measure it only after removing `processUpdatedProperties`.)
Reviewed By: mmmulani
Differential Revision: D6595780
fbshipit-source-id: a517207c17b5d5db839c9ce99a37136292acf78c
Summary:
The previous file/class name convention seemed cool... but now it drives me BANANAS! It makes all this code really hard to maintain.
So, evething were renamed following common modern RN convention.
Reviewed By: mmmulani
Differential Revision: D6605090
fbshipit-source-id: 88ca13d793a5d2adaac2b7922ec6bd4654aacec5
Summary: As it was mentioned in previous diffs, we are removing this because it overcomplicates rendering layer and provides (almost) no benefits (and cannot be implemented 100% accurate way).
Reviewed By: mmmulani
Differential Revision: D6582560
fbshipit-source-id: 0778db96a45dd8e2520268d5d00792677cb01a20
Summary:
We are removing `reactBridgeDidFinishTransaction`.
Why?
* It is a performance drain. Supporting this requires dispatching main-thread block on every single transaction complete;
* It has "too broad" non-conceptual semantic which encouraged using this as a "band-aid solution" for poorly designed components;
* It is conceptually incompatible with new approaches that we are trying to implement to optimize the render layer;
* It was deprecated for very long time.
Reviewed By: mmmulani
Differential Revision: D6549729
fbshipit-source-id: 58094aab982c67cec3d7fa3b616c637cb84d697f
Summary:
We are removing `reactBridgeDidFinishTransaction`.
Why?
* It is a performance drain. Supporting this requires dispatching main-thread block on every single transaction complete;
* It has "too broad" non-conceptual semantic which encouraged using this as a "band-aid solution" for poorly designed components;
* It is conceptually incompatible with new approaches that we are trying to implement to optimize the render layer;
* It was deprecated for very long time.
This diff replaces usage of `reactBridgeDidFinishTransaction` with `uiManagerDidPerformMounting` which has very similar semantic except that fact that `uiManagerDidPerformMounting` is called asynchronously on the next run loop tick. And this should be okay because new React partial rendering does not guarantee synchronous execution anyways.
Reviewed By: mmmulani
Differential Revision: D6549586
fbshipit-source-id: 589b814f83b91ed8fabf7e638e7554ab3c9d286e
Summary:
We are removing `reactBridgeDidFinishTransaction`.
Why?
* It is a performance drain. Supporting this requires dispatching main-thread block on every single transaction complete;
* It has "too broad" non-conceptual semantic which encouraged using this as a "band-aid solution" for poorly designed components;
* It is conceptually incompatible with new approaches that we are trying to implement to optimize the render layer;
* It was deprecated for very long time.
This diff replaces usage of `reactBridgeDidFinishTransaction` with `uiManagerDidPerformMounting` which has very similar semantic except that fact that `uiManagerDidPerformMounting` is called asynchronously on the next run loop tick. And this should be okay because new React partial rendering does not guarantee synchronous execution anyways.
Reviewed By: mmmulani
Differential Revision: D6549217
fbshipit-source-id: 2649e943e82e6fbe02c7678583a97db3f5800201
Summary:
Now setting explicit backgroundColor style is required for Views with background shadow,
otherwise the shadow will be generated based on content of the view (which is expected behaviour).
Reviewed By: mmmulani
Differential Revision: D6582587
fbshipit-source-id: 0514cb3c57bad17d2af40810b0e0f7ddc96a2c31
Summary:
This was leftovers from old implementation of zIndex feature.
Janic janicduplessis refactored this and moved all logic to UIView layer, so we don't need this prop anymore in shadow realm.
More info: https://github.com/facebook/react-native/pull/14011
Reviewed By: mmmulani
Differential Revision: D6574414
fbshipit-source-id: 2cae19350765689784d7884ed875878d39b4e3f1
Summary:
We are removing `reactBridgeDidFinishTransaction`.
Why?
* It is a performance drain. Supporting this requires dispatching main-thread block on every single transaction complete;
* It has "too broad" non-conceptual semantic which encouraged using this as a "band-aid solution" for poorly designed components;
* It is conceptually incompatible with new approaches that we are trying to implement to optimize the render layer;
* It was deprecated for very long time.
This diff removes `reactBridgeDidFinishTransaction` from RCTScrollView component. As I mentioned, because of the semantic of `reactBridgeDidFinishTransaction` is extremely broad, it's hard to capture what exact case it should handle. Based on comments and existing logic, it seems it tight to `contentSize` property and the size of RCTScrollContentView.
Reviewed By: rsnara
Differential Revision: D6538419
fbshipit-source-id: ccc6f5fea327471f10f1738d3da5214c0d362953
Summary:
This feature has been requested by customers. Our previous (pre-react) application had support for custom accessibility actions.
This feature allows UI elements to provide a list of custom actions that can be read when VoiceOver is enabled. UI elements expose one accessibility action by default. Some UI elements may support multiple actions though other mechanisms like tap and hold. To expose these actions in an accessible way iOS provides custom accessibility actions.
Feature was tested in the iOS simulator using the Accessibility Inspector. Custom actions were added to a button and observed in the tool. Custom actions were also invoked using the tool and then stepped through in the debugger.
The feature was also tested on an iPhone. VoiceOver was enabled on the device and custom actions were observed for controls that exposed them.
We have been using this feature in our app for some time as well.
[IOS] [ENHANCEMENT] [Accessibility] - Added support for custom accessibility actions
Eric Davison
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/17020
Differential Revision: D6472283
Pulled By: shergin
fbshipit-source-id: 4ac4697dca07028e87ffe71b70c00280e7f2043c
Summary:
Integration testing with Appium on iOS is slow. Profiling with Instruments.app points to `RCTView`'s `accessibilityLabel` method being a hot point in React Native, due to the `RCTRecursiveAccessibilityLabel` function.
I did a baseline benchmark by using Appium's `find_element(accessibility_id: <label>)` call on our application 10 times and got a baseline result of 0.6s for one of our primary screens.
After implementing the change and performing the same call 10 times, I got 0.48s for the same call, for a 20% performance increase in `find_element`.
[iOS] [View] - Improve performance of `RCTView` `accessibilityLabel`
<!--
Help reviewers and the release process by writing your own release notes
**INTERNAL and MINOR tagged notes will not be included in the next version's final release notes.**
CATEGORY
[----------] TYPE
[ CLI ] [-------------] LOCATION
[ DOCS ] [ BREAKING ] [-------------]
[ GENERAL ] [ BUGFIX ] [-{Component}-]
[ INTERNAL ] [ ENHANCEMENT ] [ {File} ]
[ IOS ] [ FEATURE ] [ {Directory} ] |-----------|
[ ANDROID ] [ MINOR ] [ {Framework} ] - | {Message} |
[----------] [-------------] [-------------] |-----------|
[CATEGORY] [TYPE] [LOCATION] - MESSAGE
EXAMPLES:
[IOS] [BREAKING] [FlatList] - Change a thing that breaks other things
[ANDROID] [BUGFIX] [TextInput] - Did a thing to TextInput
[CLI] [FEATURE] [local-cli/info/info.js] - CLI easier to do things with
[DOCS] [BUGFIX] [GettingStarted.md] - Accidentally a thing/word
[GENERAL] [ENHANCEMENT] [Yoga] - Added new yoga thing/position
[INTERNAL] [FEATURE] [./scripts] - Added thing to script that nobody will see
-->
Closes https://github.com/facebook/react-native/pull/17022
Differential Revision: D6459462
Pulled By: shergin
fbshipit-source-id: 3de7e5dc075281e35e62b4d4234d3f7fac5aae23
Summary:
Incorrect render for borders that are not proportional to device pixel: borders get stretched and become significantly bigger than expected.
Rdar: http://www.openradar.me/15959788
Incorrect render for borders that are not proportional to device pixel: borders get stretched and become significantly bigger than expected.
Rdar: http://www.openradar.me/15959788
Reviewed By: shergin
Differential Revision: D6317674
fbshipit-source-id: 6bc331447458583a02c0e56d0d011a31d31d70a8
Summary:
set the y offset to 0, since 0 offset is where we want to be after we hide the refreshControl.
Tested in emulator with ios 8, 9, 10 and also with section headers.
Closes https://github.com/facebook/react-native/pull/15033
Differential Revision: D6265930
Pulled By: shergin
fbshipit-source-id: b249c4713de68fc6b3a32cee7f995dc352315970
Summary:
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html
Happy contributing!
-->
While building a React Native application, I've come across the use case of wanting to set a specific locale for DatePickers irrespective of the users OS region setting. Since this is a feature available to native DatePicker components, I think it would be helpful to expose this in React Native as well.
Testing can be done by passing a `locale` prop to a DatePickerIOS. Example:
```
<DatePickerIOS
date={this.state.date}
mode="date"
locale="fr_FR"
onDateChange={date => this.setState({ date: date })}
/>
```
<!--
Help reviewers and the release process by writing your own release notes
**INTERNAL and MINOR tagged notes will not be included in the next version's final release notes.**
CATEGORY
[----------] TYPE
[ CLI ] [-------------] LOCATION
[ DOCS ] [ BREAKING ] [-------------]
[ GENERAl ] [ BUGFIX ] [-{Component}-]
[ INTERNAL ] [ ENHANCEMENT ] [ {File} ]
[ IOS ] [ FEATURE ] [ {Directory} ] |-----------|
[ ANDROID ] [ MINOR ] [ {Framework} ] - | {Message} |
[----------] [-------------] [-------------] |-----------|
[CATEGORY] [TYPE] [LOCATION] - MESSAGE
EXAMPLES:
[IOS] [BREAKING] [FlatList] - Change a thing that breaks other things
[ANDROID] [BUGFIX] [TextInput] - Did a thing to TextInput
[CLI] [FEATURE] [local-cli/info/info.js] - CLI easier to do things with
[DOCS] [BUGFIX] [GettingStarted.md] - Accidentally a thing/word
[GENERAL] [ENHANCEMENT] [Yoga] - Added new yoga thing/position
[INTERNAL] [FEATURE] [./scripts] - Added thing to script that nobody will see
-->
[IOS][ENHANCEMENT][DatePickerIOS] - Adding a locale prop.
Closes https://github.com/facebook/react-native/pull/16639
Differential Revision: D6241981
Pulled By: hramos
fbshipit-source-id: 77b1b85c09f3e12d6b3e103b3d1ffd1f12e2cea9
Summary:
According to the retain code collector, RCTSafeAreaView is in a cycle:
-> _bridge -> RCTCxxBridge -> _moduleDataByName -> __NSDictionaryM -> RCTModuleData -> _instance -> RCTUIManager -> _viewRegistry -> __NSDictionaryM -> RCTSafeAreaView
This should break the cycle.
Reviewed By: shergin
Differential Revision: D6213668
fbshipit-source-id: efb9c1dd148b72f66fe4485b81c16cd4c2d18b17
Summary:
Same IOS 11 issue as https://github.com/facebook/react-native/pull/15023
Fixes the annoying 20px content insert on top.
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html
Happy contributing!
-->
Fix the behaviour of WebView when building the iOS project with Xcode 9 due to the `contentInsetAdjustmentBehavior`.
<!--
Help reviewers and the release process by writing your own release notes
**INTERNAL and MINOR tagged notes will not be included in the next version's final release notes.**
CATEGORY
[----------] TYPE
[ CLI ] [-------------] LOCATION
[ DOCS ] [ BREAKING ] [-------------]
[ GENERAl ] [ BUGFIX ] [-{Component}-]
[ INTERNAL ] [ ENHANCEMENT ] [ {File} ]
[ IOS ] [ FEATURE ] [ {Directory} ] |-----------|
[ ANDROID ] [ MINOR ] [ {Framework} ] - | {Message} |
[----------] [-------------] [-------------] |-----------|
[CATEGORY] [TYPE] [LOCATION] - MESSAGE
EXAMPLES:
[IOS] [BREAKING] [FlatList] - Change a thing that breaks other things
[ANDROID] [BUGFIX] [TextInput] - Did a thing to TextInput
[CLI] [FEATURE] [local-cli/info/info.js] - CLI easier to do things with
[DOCS] [BUGFIX] [GettingStarted.md] - Accidentally a thing/word
[GENERAL] [ENHANCEMENT] [Yoga] - Added new yoga thing/position
[INTERNAL] [FEATURE] [./scripts] - Added thing to script that nobody will see
-->
[IOS] [BUGFIX] [WebView] - Fix extra white space added to webView due to iOS 11 contentInsetAdjustmentBehavior
Closes https://github.com/facebook/react-native/pull/16519
Differential Revision: D6195670
Pulled By: shergin
fbshipit-source-id: 08d4d4dc700059bb7707e038dc4f592af0275896
Summary:
ExtraBold is a fairly common suffix in font naming. A good example is "Circe-ExtraBold". It's usually synonymous with Heavy or Black at font weight 800, as described here: https://www.webtype.com/info/articles/fonts-weights/
This fixes a regression with ExtraBold fonts introduced in d3007b0 where simply having an extrabold font will cause `weightOfFont` to choose this weight aggressively, resulting in all bold text erroneously interpreted as extrabold/heavy. This fix ensures that extrabold is detected before bold, and correctly attributed to `UIFontWeightHeavy`.
Closes https://github.com/facebook/react-native/pull/16323
Differential Revision: D6119059
Pulled By: shergin
fbshipit-source-id: 56a5c30584f220974308a7d6068c8d952aa20fb8
Summary: It saves 8 bytes per shadowView instance, and it is more logical because it does nothing by default.
Reviewed By: javache
Differential Revision: D5997804
fbshipit-source-id: c985a11aeea881e95911469e10c8c27429a2718a
Summary:
This is required for D5874536, wherein I'll be introducing direction-aware props for borders.
When a view's border changes due to a direction update, only the frames of its children update. Therefore, only the children `UIView`s get a chance to be re-rendered. This is incorrect because the view that's had its borders changed also needs to re-render. So, I keep a track of the layout direction in a property on all shadow views. Then, when I update that prop within `applyLayoutNode`, I push shadow views into the `viewsWithNewFrames` set.
Reviewed By: mmmulani
Differential Revision: D5944488
fbshipit-source-id: 3f23e9973f3555612920703cdb6cec38e6360d2d
Summary: Because `RCTUIManager` is already overcomplicated and that stuff deserves separate file and header.
Reviewed By: javache
Differential Revision: D5856653
fbshipit-source-id: 7001bb8ba611976bf3b82d6a25f5619810a35b34
Summary:
This issue has been open for a really long time, but I'm pretty sure this is the line that needed to change:
https://github.com/facebook/react-native/issues/1831
What was happening here is that `CGRectIsEmpty` returns true when either height or width is zero. With the current logic, one of those would always be zero when the parent was rendered off screen. This ensures that there the intersection be of CGSizeZero for the view to actually be clipped.
That being said, there seems to be something more complex going on here that I'm not understanding? I would think that you'd simply want to check if the child view's frame is within the bounds of the parent at all. If it was, then don't clip it. If I'm in the wrong, could someone explain this a bit more? If so, I'll fix this issue.
Using this [repository](https://github.com/jcharlet/react_native_listview_bug), this one line change fixes the issue and still clips cells as they are scrolled off screen.
Closes https://github.com/facebook/react-native/pull/15669
Differential Revision: D5815056
Pulled By: shergin
fbshipit-source-id: 32382e4954139e4d5af67d786422fd87173b1a1a
Summary: As per the comment, <Modal> uses entering/leaving the view hierarchy as a cue to show/hide the modal. By re-adding it, we are causing a bunch of confusion.
Reviewed By: shergin
Differential Revision: D5893607
fbshipit-source-id: ecd05799751a9bba843998ae93f24fe35edca8b4
Summary:
<SafeAreaView> renders nested content and automatically applies paddings reflect the portion of the view
that is not covered by navigation bars, tab bars, toolbars, and other ancestor views.
Moreover, and most importantly, Safe Area's paddings feflect physical limitation of the screen,
such as rounded corners or camera notches (aka sensor housing area on iPhone X).
Reviewed By: mmmulani
Differential Revision: D5886411
fbshipit-source-id: 7ecc7aa34de8f5527c4e59b0fb4efba3aaea28c8
Summary:
In some cases we need a way to specify some environmental data to shadow view
to improve layout (or do something similar), so `localData` serves these needs.
For example, any stateful embedded native views may benefit from this.
Have in mind that this data is not supposed to interfere with the state of
the shadow view.
Reviewed By: mmmulani
Differential Revision: D5884711
fbshipit-source-id: f0bf66e4608894ec4479b8aca262afcfba6b9f4b
Summary: Adds an onDismiss so that navigation events can be chained to the dismissing of a modal.
Reviewed By: sahrens
Differential Revision: D5852953
fbshipit-source-id: a86e36fdd5b0b206c2dd9fa248e2a88da22efa31
Summary:
fix the regression I mentioned in https://github.com/facebook/react-native/pull/15162#issuecomment-319696706
as no one is working on this, I take the step, although I know nothing about Objective C
I find the key point is that the keys in `NSDictionary` are not ordered as presented, it's a hash table, so no grantee on keys order, so I create a new array to do that, then it will check `ultralight` before `light` and `semibold` before `bold`
Closes https://github.com/facebook/react-native/pull/15825
Differential Revision: D5782142
Pulled By: shergin
fbshipit-source-id: 5346b0cb263e535c0b445e7a2912c452573248a5
Summary:
Shame on me.
Naming can be hard. We have to use positive logic to avoid this kind of bugs. :(
In the bright future we also have to rename `isYogaLeafNode` to something with positive logic, like `canHaveYogaChildNodes`.
But before we can do this, we have to have solid plan how to unify it with Android.
Reviewed By: mmmulani
Differential Revision: D5780917
fbshipit-source-id: 1ddaaea06f5618b91528cc87f1433a55b5fae4ac
Summary:
Content offset was broken because on initial render contentSize is {0,0} so any positive offset is lost. Also inset top/bottom and left/right were inversed �, this led to bad initial scrolling offset when using contentInset. This fixes it by making sure contentSize is actually measured (not {0,0}. I guess it's possible that the content is ACTUALLY {0,0} but in that case I don't think it really matters).
**Test plan**
Tested that a scrollview has proper scroll position when specifying contentOffset. Also tested that it works well with contentInset.
```js
<ScrollView contentOffset={{y: 100}}>
<View style={{height: 1000}} />
</ScrollView>
```
Closes https://github.com/facebook/react-native/pull/15670
Differential Revision: D5771221
Pulled By: shergin
fbshipit-source-id: 455ed8fd5a4ad1ec61780b573d1a8ef1d77dd124
Summary:
We have to have a way to track ownership of shadow view.
Previous solution with traversing the hierarchy to figure out the root view does not actually work in some cases when the view is temporary detached from hierarchy.
This is also how it work on Andorid.
Reviewed By: mmmulani
Differential Revision: D5686112
fbshipit-source-id: a23a10e8c29c7572ac69403289db136c9d5176a9
Summary:
- [x] Explain the **motivation** for making this change.
- [x] Provide a **test plan** demonstrating that the code is solid.
- [x] Match the **code formatting** of the rest of the codebase.
- [x] Target the `master` branch, NOT a "stable" branch.
There is a problem where setting a bigger fontSize in PickerItem style
clips the top and bottom of the text.
This solves that problem by computing the row height using the font
size.
Create a PickerIOS component and set a larger font size (e.g. 50). The row height will grow accordingly.
Example with `fontSize=50`: [Screenshot](http://i.imgur.com/YwK5fOc.png)
Closes https://github.com/facebook/react-native/pull/13513
Differential Revision: D5692124
Pulled By: shergin
fbshipit-source-id: 4629403e37ad68cdbc0b17b48ba924a77e133078
Summary:
> The property contentInset can change the maximum and minimum values of the content offset to allow scrolling outside of the scrollable area. Its type is UIEdgeInsets, which consists of 4 numbers: {top, left, bottom, right}. When you introduce an inset, you change the range of the content offset. For example, setting the content inset to have a value of 10 for its top value allows the content offset’s y value to reach -10. This introduces padding around the scrollable area.
( https://www.objc.io/issues/3-views/scroll-view/ )
See also: https://github.com/facebook/react-native/pull/15395
Reviewed By: mmmulani
Differential Revision: D5607192
fbshipit-source-id: 1acd6a84e2bcfefc6e82861cfbdfe6247d0e4264
Summary:
**Motivation**
On Apple TV, pressing the menu button destroys the native view that backs the `Modal` component, causing an app using this component to get into a broken state. This fix implements `onRequestClose` for tvOS to have the same behavior as it does for the Android back button.
**Test plan**
Manually tested this with the `ModalExample` in the `RNTester` app. See also the test code in issue #15313.
Closes https://github.com/facebook/react-native/pull/15341
Differential Revision: D5651035
Pulled By: shergin
fbshipit-source-id: 54bf66887bbe85940567e63e90b437ac4a8daf9a
Summary:
**Motivation**
Fix flickering in TabBarIOS on Apple TV... issue #15081
After this change, on Apple TV, TabBarIOS item selections will be controlled purely from the native side after initial render with the `selected` prop. This is necessary because the `UITabBar` implementation in tvOS moves the selection before calling `shouldSelectViewController:`; this issue does not occur on iOS.
**Test plan**
Existing CI should still pass. Issue is resolved when testing the example code in #15081 .
Closes https://github.com/facebook/react-native/pull/15220
Differential Revision: D5601671
Pulled By: javache
fbshipit-source-id: c18e7d3482d6c07d534ff40a443a6f642d4267bb
Summary:
It is not itemPositoning it is itemPositioning
I have test it on iOS and tvOS
Closes https://github.com/facebook/react-native/pull/15426
Differential Revision: D5591807
Pulled By: javache
fbshipit-source-id: 0ad0bc32012c63f93f6b1528cae46c6dcba56706
Summary:
When false, ScrollView disables use of pinch gestures to zoom in and out. This allows ScrollView's pinch gesture responder to be disabled to only allow zooming programmatically. The default value is ~false~ true.
**Test Plan**
Tested that pinch gesture responder is disabled when pinchEnabled=false.
/cc nicklockwood sahrens
🍺
Closes https://github.com/facebook/react-native/pull/10037
Differential Revision: D5491953
Pulled By: shergin
fbshipit-source-id: eae16f92ec616e415b4ddacfccb84c697582daf9
Summary:
Hey!
So, I was interested to contibure, and started from todo
Thank
Closes https://github.com/facebook/react-native/pull/14823
Differential Revision: D5546610
Pulled By: javache
fbshipit-source-id: 58e1b67786cbafa20399ac12dde9fcc3920abe94
Summary:
In iOS11, Apple added a new layout feature called "Safe Areas" (this blog post talks a bit about it: https://www.bignerdranch.com/blog/wwdc-2017-large-titles-and-safe-area-layout-guides/).
UIScrollView is one component that is affected by this change in Apple's API. When the `contentInsetAdjustmentBehavior` is set to `automatic`, for example, it will adjust the insets (and override any manually set insets) automatically based on whether or not there's a UINavigationBar, a UITabBar, a visible status bar, etc on the screen. Frustratingly, Apple decided to default to `Automatic` for this behavior, which will cause any apps that set contentInset/contentContainerStyle padding to have their values offset by, at the very least, the size of the status bar, when they compile their app for iOS 11. Here's more information about this behavior: https://developer.apple.com/documentation/uikit/uiscrollview/2902261-contentinsetadjustmentbehavior?language=objc
Mostly, this is a really straightforward change -- it simply adds a new iOS-only prop to ScrollView that allows setting `contentInsetAdjustmentBehavior`. But I did decide to default the behavior to `never`, so that it mimics the behavior we've seen in iOS < 11. I think it's good to keep something as crucial as scrollview content insets non-magical, and also keep it behaving similarly between platforms.
Closes https://github.com/facebook/react-native/pull/15023
Reviewed By: javache
Differential Revision: D5517552
Pulled By: hramos
fbshipit-source-id: c9ce4bf331b3d243228268d826fdd4dcee99981d
Summary:
Adds a queue to postMessage so that messages sent close together are not lost.
Setting location="a";location="b" results in only "b" reaching shouldStartLoadWithRequest. Making the second update asynchronous with setTimeout does not fix the issue unless a delay is added.
With this update, postMessage queues "b" until it gets a "message:received" event that confirms "a" has already been processed.
The included test sends two messages from a webview and checks that both are received. It fails against the preexisting code with the first message being dropped.
Closes https://github.com/facebook/react-native/pull/11304
Differential Revision: D5481385
Pulled By: hramos
fbshipit-source-id: 9b6af195eeff8f20c820e2fcdac997c90763e840
Summary:
In iOS11, Apple added a new layout feature called "Safe Areas" (this blog post talks a bit about it: https://www.bignerdranch.com/blog/wwdc-2017-large-titles-and-safe-area-layout-guides/).
UIScrollView is one component that is affected by this change in Apple's API. When the `contentInsetAdjustmentBehavior` is set to `automatic`, for example, it will adjust the insets (and override any manually set insets) automatically based on whether or not there's a UINavigationBar, a UITabBar, a visible status bar, etc on the screen. Frustratingly, Apple decided to default to `Automatic` for this behavior, which will cause any apps that set contentInset/contentContainerStyle padding to have their values offset by, at the very least, the size of the status bar, when they compile their app for iOS 11. Here's more information about this behavior: https://developer.apple.com/documentation/uikit/uiscrollview/2902261-contentinsetadjustmentbehavior?language=objc
Mostly, this is a really straightforward change -- it simply adds a new iOS-only prop to ScrollView that allows setting `contentInsetAdjustmentBehavior`. But I did decide to default the behavior to `never`, so that it mimics the behavior we've seen in iOS < 11. I think it's good to keep something as crucial as scrollview content insets non-magical, and also keep it behaving similarly between platforms.
Closes https://github.com/facebook/react-native/pull/15023
Differential Revision: D5441491
Pulled By: shergin
fbshipit-source-id: 7b56ea290f7f6eca5f1d996ff8488f40b866c2e6
Summary:
**Issue:**
Some fonts are defined with weights that don't match with the UIFontWeight constants.
**Example:**
UIFontWeightTraits for Roboto font
Light: -0.230
Thin: -0.365
Currently, the UIFontWeightTrait is always used if it != 0.0, and given the UIFontWeight constants for Light and Thin:
UIFontWeightThin -0.6
UIFontWeightLight -0.4
A style font weight of "300" or "200" will both resolve to Roboto-Thin as its weight -0.365 is closer to -0.4 (UIFontWeightLight) and -0.6 (UIFontWeightThin) than -0.230 (Roboto-Light).
**Proposed fix:**
When resolving `getWeightOfFont` try to match the name of weight to the name of the font first, and guess the font with UIFontWeightTrait as the fall back.
**Test Plan:**
Attempt to display Roboto at weights "200" and "300" and Roboto-Thin and Roboto-Light should be displayed correctly.
Current:
Fixed:
Closes https://github.com/facebook/react-native/pull/15162
Differential Revision: D5479817
Pulled By: javache
fbshipit-source-id: a9f93d8ce69a96fb685cb09393d1db42486cc0c2
Summary:
<!--
Thank you for sending the PR!
If you changed any code, please provide us with clear instructions on how you verified your changes work. In other words, a test plan is *required*. Bonus points for screenshots and videos!
Please read the Contribution Guidelines at https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md to learn more about contributing to React Native.
Happy contributing!
-->
Closes https://github.com/facebook/react-native/pull/15156
Differential Revision: D5479265
Pulled By: shergin
fbshipit-source-id: a2dfa3a4357e126838a17dac4797d1d845cd56ae
Summary:
* Now `setFrame:` is called by autoresizing masks, so it is safe.
* Nobody calls `setBounds:`, so it is also safe.
Reviewed By: javache
Differential Revision: D5414441
fbshipit-source-id: 6fc51c7598c4817301db51f627aa1e9840642fec
Summary:
Previous `contentOffset` can be invalid for a new layout and overscroll the ScrollView, so the diff fixes that.
Also documented here: https://github.com/facebook/react-native/issues/13566
Reviewed By: mmmulani
Differential Revision: D5414442
fbshipit-source-id: 7de1b4a4571108a37d1795e80f165bca5aba5fef
Summary:
Surprisingly enough, even if semantically the code remains identical, layouting via autoresizing masks applies changes to subviews a bit earlier than iOS calls `layoutSubviews`.
This allows us to avoid situations where we already explicitly set calculated by Yoga frames and want to scroll to some subview, but actual layout have not done yet and internal views has wrong frames.
Reviewed By: javache
Differential Revision: D5414440
fbshipit-source-id: d4152c9c68dc17f6827832dcb45e5ba86fb82831
Summary:
This PR fixes#15006 by removing all UI API calls from RCTScrollEvent.
`-[RCTScrollEvent arguments]` can now be called from a background thread.
The Main Thread Checker of Xcode 9 will not any longer produce runtime issues when calling this method.
1. create a React Native (version: this PR) project with a scroll view
2. open it in Xcode 9
3. launch it
4. scroll the scroll view
5. observe the runtime issues in Xcode. There should not contain "UI API called from background thread"-issues.
I verified my changes on this branch: https://github.com/HeEAaD/Demo-ReactNative-UI-not-on-main-thread/tree/fix
<!--
Thank you for sending the PR!
If you changed any code, please provide us with clear instructions on how you verified your changes work. In other words, a test plan is *required*. Bonus points for screenshots and videos!
Please read the Contribution Guidelines at https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md to learn more about contributing to React Native.
Happy contributing!
-->
Closes https://github.com/facebook/react-native/pull/15008
Differential Revision: D5424734
Pulled By: shergin
fbshipit-source-id: 56beec2d7603ea6782d55622567509f3758a4517
Summary:
It's very important in complex UIs to be able to apply alpha channel-based masks to arbitrary content. Common use cases include adding gradient masks at the top or bottom of scroll views, creating masked text effects, feathering images, and generally just masking views while still allowing transparency of those views.
The original motivation for creating this component stemmed from work on `react-navigation`. As I tried to mimic behavior in the native iOS header, I needed to be able to achieve the effect pictured here (this is a screenshot from a native iOS application):
In this image, there are two masks:
- A mask on the back button chevron
- A gradient mask on the right button
In addition, the underlying view in the navigation bar is intended to be a UIBlurView. Thus, alpha masking is the only way to achieve this effect.
Behind the scenes, the `maskView` property on `UIView` is used. This is a shortcut to setting the mask on the CALayer directly.
This gives us the ability to mask any view with any other view. While building this component (and testing in the context of an Expo app), I was able to use a `GLView` (a view that renders an OpenGL context) to mask a `Video` component!
I chose to implement this only on iOS right now, as the Android implementation is a) significantly more complicated and b) will most likely not be as performant (especially when trying to mask more complex views).
Review the `<MaskedViewIOS>` section in the RNTester app, observe that views are masked appropriately.
Closes https://github.com/facebook/react-native/pull/14898
Differential Revision: D5398721
Pulled By: javache
fbshipit-source-id: 343af874e2d664541aca1fefe922cf7d82aea701
Summary:
**Motivation**
This is a re-worked version of #14260, by shergin's suggestion.
For iOS, if you want to inherit from a native ViewManagers, your custom ViewManager will not automatically export the parents' props. So the only way to do this today, is to basically copy/paste the parent ViewManager-file, and add your own custom logic.
With this PR, this is made more extensible by exporting the `baseModuleName` (i.e. the iOS `superclass` of the ViewManager), and then using that value to re-establish the inheritance relationship in `requireNativeComponent`.
**Test plan**
I've run this with a test project, and it works fine there. But needs more testing.
Opened this PR as [per shergin's suggestion](https://github.com/facebook/react-native/pull/10946#issuecomment-311860545) though, so we can discuss approach.
**Discussion**
* Android already supports inheritance, so this change should be compatible with that. But, not every prop available on `UIManager.RCTView.NativeProps` is actually exported by every ViewManager. So should `UIManager.RCTView.NativeProps` still be merged with `viewConfig.NativeProps`, even if the individual ViewManager does not export/use them to begin with?
* Does this break other platforms? [UWP](https://github.com/Microsoft/react-native-windows)?
Closes https://github.com/facebook/react-native/pull/14775
Differential Revision: D5392953
Pulled By: shergin
fbshipit-source-id: 5212da616acfba50cc285e2997d183cf8b2cd09f
Summary:
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
> **Unless you are a React Native release maintainer and cherry-picking an *existing* commit into a current release, ensure your pull request is targeting the `master` React Native branch.**
Explain the **motivation** for making this change. What existing problem does the pull request solve?
The problem occurs when a ScrollView's content height is smaller than the ScrollView height. If the method `scrollToEnd` is called on the ScrollView, it will pull the content down until the bottom of the content is aligned with the bottom of the Scrollview container.
This fix will ensure the proper functionality: That the furthest the ScrollView can scroll down is to where the top of the content container is at the origin (i.e., the ScrollView scroll number cannot be less than 0).
Prefer **small pull requests**. These are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
**Test plan (required)**
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.
Make sure tests pass on both Travis and Circle CI.
I tested on a scenario where the ScrollView is almost the full size of the screen, and the content of the ScrollView has a height of much less. In this situation, the `scrollToEnd` method was executed and the content stayed in the same position. This is the intended behavior. If the content of the ScrollView is smaller than the height of the ScrollView, then the `scrollToEnd` method should not scroll anywhere.
**Code formatting**
Look around. Match the style of the rest of the codebase. See also the simple [style guide](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#style-guide).
For more info, see the ["Pull Requests" section of our "Contributing" guidelines](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#pull-requests).
Closes https://github.com/facebook/react-native/pull/12889
Reviewed By: javache
Differential Revision: D5289894
Pulled By: sahrens
fbshipit-source-id: df2e779ee855c1dea85d33649d754371ad244bca
Summary:
Yes, `display: none;` did not work on iOS before this commit.
Now it "just works". It can be useful when some view needs to be hidden temporary and efficiently.
Reviewed By: javache
Differential Revision: D5173936
fbshipit-source-id: 83a03fff04dd3a872d7dd6bf673189f932906776
Summary:
That's interesting!
If we apply `display: none;` style to some node, Yoga will stop calculation layout for this subtree (which is reasonable).
So, from RN perspective we have to stop applying layout for hidden subtree because it is meaningless and causes another errors.
Note: We do actually not support `display: none;` yet. It stops computing layout, but it does not hide the views!
Reviewed By: javache
Differential Revision: D5168651
fbshipit-source-id: 29a9385c76a0f9d637285fc0d268ccc39879ca0a
Summary:
Override `canHaveSubviews` in RCTShadowView subclass to disallow any nested content.
For now, this prop will be checked only in DEV mode for performance reasons.
Reviewed By: javache
Differential Revision: D5189083
fbshipit-source-id: 87087dd806e1fd7320128dab969b13642174f81c
Summary: Optimize ScrollView by adding flag "DEPRECATED_sendUpdatedChildFrames" to gate whether updatedChildFrames data is computed and propagated on scroll events. The frame data is used in ListView by the onChangeVisibleRows prop. When this prop is not defined, unnecessary computation in ScrollView should not be performed.
Reviewed By: sahrens
Differential Revision: D5174898
fbshipit-source-id: e3eaed8760b76becf14dfeb00122bdebdaeae4ef
Summary:
Flashing scroll indicators is a standard behavior on iOS to show the user there's more content.
Launch RNTester on iOS, go to the ScrollView section, tap the "Flash scroll indicators" button.
You'll see this:
I've exposed the method `flashScrollIndicators` on all scrolling components that were already exposing a `scrollToXXX` method so it's usable from those components using a ref.
Let me know what you think.
Closes https://github.com/facebook/react-native/pull/14058
Differential Revision: D5103239
Pulled By: shergin
fbshipit-source-id: caad8474fbe475065418d771b17e4ea9766ffcdc
Summary:
Sometimes, when we implement some custom RN view, we have to proxy all accessible atributes directly to some subview which actually has accesible content. So, in other words, this allows bypass some axillary views in terms of accessibility.
Concreate example which this approach supposed to fix:
https://github.com/facebook/react-native/pull/14200/files#diff-e5f6b1386b7ba07fd887bca11ec828a4R208
Reviewed By: mmmulani
Differential Revision: D5143860
fbshipit-source-id: 6d7ce747f28e5a31d32c925b8ad8fd4b98ce1de1
Summary: Previosly `borderWidth` did not affect actual content inset (which was a problem).
Reviewed By: mmmulani
Differential Revision: D5072483
fbshipit-source-id: d43cba7414a9335b9f9fd4d1565d7aee403cce0e
Summary:
This avoids reordering views because it created some bugs when the native hierarchy is different from the shadow views. This leverages `layer.zPosition` and takes z-index in consideration when we check what view should be the target of a touch.
**Test plan**
Tested that this fixes some layout issues that occurred when using sticky headers in the Expo home screen.
Closes https://github.com/facebook/react-native/pull/14011
Differential Revision: D5108437
Pulled By: shergin
fbshipit-source-id: 0abfe85666e9d236a190e6f54cdd5453cacfbcac
Summary:
In some cases, `RCTRecursiveAccessibilityLabel` could return an accessibility label that had leading space, trailing space, or multiple spaces between words. This is because it always added a space before adding a label even if the label turned out to be empty.
This is fixed by being stricter about adding spaces.
Found test cases that used to introduce leading space, trailing space, or multiple spaces between words and verified that there aren't any extra spaces after the fix.
```
{/* Used to have leading space */}
<View accessible={true}>
<View />
<View accessibilityLabel='Two' />
<View accessibilityLabel='Three' />
</View>
{/* Used to have 2 spaces between "One" and "Three" */}
<View accessible={true}>
<View accessibilityLabel='One' />
<View />
<View accessibilityLabel='Three' />
</View>
{/* Used to have trailing space */}
<View accessible={true}>
<View accessibilityLabel='One' />
<View accessibilityLabel='Two' />
<View />
</View>
```
Additionally, my team is using this fix in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/14177
Differential Revision: D5127891
Pulled By: shergin
fbshipit-source-id: 42c3022895d844959e0037eaf381b326af3cd6d1
Summary:
fix problem of function scrollToEnd: There are some strange thing happened when contentSize.height(width) is smaller than bounds.size.height(width). In fact, there is no need to scroll in this case.
Thanks for submitting a PR! Please read these instructions carefully:
- [x] Explain the **motivation** for making this change.
- [x] Provide a **test plan** demonstrating that the code is solid.
- [x] Match the **code formatting** of the rest of the codebase.
- [x] Target the `master` branch, NOT a "stable" branch.
What existing problem does the pull request solve?
A good test plan has the exact commands you ran and their output, provides screenshots or videos if the pull request changes UI or updates the website. See [What is a Test Plan?][1] to learn more.
If you have added code that should be tested, add tests.
Sign the [CLA][2], if you haven't already.
Small pull requests are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
Make sure all **tests pass** on both [Travis][3] and [Circle CI][4]. PRs that break tests are unlikely to be merged.
For more info, see the ["Pull Requests"][5] section of our "Contributing" guidelines.
[1]: https://medium.com/martinkonicek/what-is-a-test-plan-8bfc840ec171#.y9lcuqqi9
[2]: https://code.facebook.com/cla
[3]: https://travis-ci.org/facebook/react-native
[4]: http://circleci.com/gh/facebook/react-native
[5]: https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#pull-requests
Closes https://github.com/facebook/react-native/pull/13180
Differential Revision: D4928778
Pulled By: javache
fbshipit-source-id: 8b74833593ee317df726a4035ec71bbc77d13afe
Summary:
Fixes the sizing of items so that under most scenarios it calcultes its height by it's content for non exact measurings. This introduces a new useLegacyStretchBehaviour flag on the config to opt out of this change as it is breaking.
See facebook/yoga#505
Closes https://github.com/facebook/yoga/pull/506
Reviewed By: astreet
Differential Revision: D4954016
Pulled By: emilsjolander
fbshipit-source-id: d28bd5d174cd76951fb94df85e3b0cfab7f81ff7
Summary:
* It complicates Touch Handling mechanism.
* The same functionality can be (and should be) implemented via overriding standard `hitTest:` method.
* It was marked as deprecated a while ago.
Reviewed By: mmmulani
Differential Revision: D4667776
fbshipit-source-id: 2e047c3308563a2849ea351a242270f0800fead2
Summary:
Pair `reactWillMakeFirstResponder` and `reactDidMakeFirstResponder` was replaced with just `reactFocus` method
which is supposed to incapsulate all "focus" and "focus-later-if-needed" functionality.
Reviewed By: mmmulani
Differential Revision: D4664626
fbshipit-source-id: 8d3b7935ca26d32ba1d1826a585cce0396fcc885
Summary:
…th RCTSharedApplication()
Thanks for submitting a PR! Please read these instructions carefully:
- [ ] Explain the **motivation** for making this change.
Using React Native latest version with Cocoapods 1.2.0 causes the following error inside iOS app extensions
> /react-native/React/Modules/RCTAccessibilityManager.m:67:70: ‘sharedApplication’ is unavailable: not available on iOS (App Extension) — Use view controller based solutions where appropriate instead.
Moving the use of [UIApplication sharedApplication] to RCTSharedApplication() which is safe on app extension
- [ ] Provide a **test plan** demonstrating that the code is solid.
I am not sure how to test such that all the features which touch the modified code are tested.
- [ ] Match the **code formatting** of the rest of the codebase.
- [ ] Target the `master` branch, NOT a "stable" branch.
What existing problem does the pull request solve?
Using React Native latest v
Closes https://github.com/facebook/react-native/pull/13227
Differential Revision: D4816338
Pulled By: javache
fbshipit-source-id: e3e3c77882990ad1817b0b633521cff52571ecd0
Summary:
Various fixes of xcode projects and cleaning up some warnings
Closes https://github.com/facebook/react-native/pull/13109
Differential Revision: D4762652
Pulled By: lacker
fbshipit-source-id: b452976a58962439de4adecc8e703264af40cb38
Summary:
The Math Strikes Back
Several related things:
* When we specify `scale: 0;` style for some view it ends up with calling `CATransform3DScale` with zero scale parameter.
* In this case `CATransform3DScale` returns transform matrix full of zeros. It actually depends on representation and matrix-type (2d or 3d) but in UIView debugger it appears as [0, 0, 0, 0, ...]. And probably it is correct result.
* By default, for hit-testing, UIKit uses specially optimized logic based on GPU/CALayer infrastructure under the hood. And the transform matrix full of zeros breaks this algorithm. I guess, it happens because zero-matrix doesn't quite make sense.
So, `scale: 0;` is a weird edge case, and in this diff, we are trying to illuminate it by replacing with epsilon value.
Related SO issues:
http://stackoverflow.com/questions/25964224/cgaffinetransformscale-not-working-with-zero-scalehttp://stackoverflow.com/questions/7937369/animate-uiview-scale-to-zero
Reviewed By: blairvanderhoof
Differential Revision: D4734475
fbshipit-source-id: 7241cdffa86c05a6552860a25789e2281588ba23
Summary:
If user slide picker when picker item is zero, `UIPickerViewDelegate` will call `pickerView:didSelectRow:inComponent` row=0, `_items[row][@"value"]` will crash.
Closes https://github.com/facebook/react-native/pull/12187
Differential Revision: D4709882
Pulled By: mkonicek
fbshipit-source-id: 772c819d4eaef41ac983287877bda2918f40b1a7
Summary: Helps mitigate part of https://github.com/facebook/react-native/pull/12245 while we wait for a more comprehensive solution.
Reviewed By: emilsjolander
Differential Revision: D4571776
fbshipit-source-id: 185cd1b0d3af37724136a37471df412c2000dfe4
Summary:
Moving setting `availableSize` for `RCTRootShadowView` on earlier stage allows to prevent situations where `availableSize` is not specified yet, but Yoga layout is already happening.
Because `availableSize` equals {infinity, infinity} by default (in this case), Yoga returns a lot of nodes with infinit metrics, which confises UIKit.
Reviewed By: mmmulani
Differential Revision: D4672170
fbshipit-source-id: f9d8c84799dcbdb6b9230ddef6284d84df268833
Summary:
MapView has been deprecated in open source for a while: http://facebook.github.io/react-native/docs/mapview.html
We still want to use it internally. Moving it away from the GitHub folder.
Reviewed By: mmmulani
Differential Revision: D4646199
fbshipit-source-id: f469971e448dbca12afe141b43fa8a2518c7d467
Summary:
Remove the native iOS sticky headers implementation that has been replaced by the js Animated one. Also remove a line in JS that made sure we passed null to native so it did not use the native implementation.
**Test plan**
Made sure there were no more mentions of sticky / header in native ScrollView related code.
Tested that sticky headers still work :o
Closes https://github.com/facebook/react-native/pull/12696
Differential Revision: D4657391
Pulled By: ericvicenti
fbshipit-source-id: 16324a45ca4ce5cd143293c61394a0fa7ad0c4a1
Summary:
This diff adds display:none support to React Native. This enables hiding components which still calling their render method and keeping them within the state of your application. This enables preserving state in a component even though the component is not visible. Previously this was often implemented by rendering a component off screen as a work around. See below playground for usage.
```
class Playground extends React.Component {
render() {
return (
<View style={{width: '100%', height: '100%', flexDirection: 'row', backgroundColor: 'white'}}>
<View style={{width: 100, height: 100, display: 'none', backgroundColor: 'red'}}/>
<View style={{width: 100, height: 100, backgroundColor: 'blue'}}/>
</View>
);
}
}
```
Reviewed By: astreet
Differential Revision: D4611771
fbshipit-source-id: 0dbe0494d989df42994ab9ad5125d47f3233cc5a
Summary:
The actual badgeColor prop causes the following error when run on device with a version inferior to iOS 10 like iPad 2 and iPad mini 1.
`*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[UITabBarItem setBadgeColor:]: unrecognized selector sent to instance 0x7968be80'`
This PR fixes it by checking at runtime if the selector is available for the current running version.
It also makes the color available at start by using the variable `self.barItem`. Currently, the color appears only after a reload.
Closes https://github.com/facebook/react-native/pull/12354
Differential Revision: D4598036
Pulled By: shergin
fbshipit-source-id: 9f104fc27db51213a54273e33c5a22f1b350c55e
Summary:
In some cases, the accessibilityLabel contains a leading space. This is because `RCTRecursiveAccessibilityLabel` adds a space before every iteration of the loop including the first.
After this change, the contract is that:
- `RCTRecursiveAccessibilityLabel` always returns a string with a leading space.
- `accessibilityLabel` never returns a string with a leading space.
**Test plan**
I created a test app with the following code:
```
<View style={{height: 100, width: 100, backgroundColor: 'steelblue'}} accessible={true}>
<View style={{height: 20, width: 20, backgroundColor: 'red'}} accessibilityLabel='One' />
<View style={{height: 20, width: 20, backgroundColor: 'yellow'}} accessibilityLabel='Two' />
<View style={{height: 20, width: 20, backgroundColor: 'green'}} accessibilityLabel='Three' />
</View>
```
Before this change, the accessibilityLabel of the outermost View was " One Two Three" (notice the leading space).
After this change, it is "One Two Three" as desired.
Adam
Closes https://github.com/facebook/react-native/pull/12269
Reviewed By: javache
Differential Revision: D4596761
Pulled By: shergin
fbshipit-source-id: 7d5ff704e858d9f277d1547339a2831ffa90f592
Summary:
Now things look much more clear, I hope.
This diff:
* Introduces new property of `RCTRootShadowView` `availableSize` which represents exactly what we transmit to layout engine;
* Illuminates conflict between logical `availableSize` and explicitly specified size of DOM node (current `size`);
* Splits overcomplicated `setSize:forView:` method into two unrelated ones;
* Changes actual values of `RCTRootViewSizeFlexibility` enum constants for simpler usage;
* Completely removes `sizeFlexibility` concept from `RCTRootShadowView` (in favor of special values of `availableSize`);
* Makes the code clearer finally.
This is beginning of big effort to improve `RCTRootView` and co.
Reviewed By: mmmulani
Differential Revision: D4562834
fbshipit-source-id: f5baaf2859ea430d44645a6b5d35f222f15a668e
Summary: With the Cxx bridge, properties are not guaranteed to be set it any order (and furthermore, they should not be). RCTRefreshControl previously had its title set first, and would crash otherwise. This fixes that.
Reviewed By: mhorowitz
Differential Revision: D4580253
fbshipit-source-id: 39baecceb8b67c6a851c08ba9cabbf4dc99359cb
Summary: This method was defined in the .m file already, so we can just expose it to the header for other usages.
Reviewed By: mmmulani, shergin
Differential Revision: D4557942
fbshipit-source-id: a1be8af8e31b88a152cabfab6d4cf82316088572
Luna Wei
Doug Russell
ifsnow
Valentin Shergin
Jason Hu
danibonilha
James Reggio
Héctor Ramos
Kevin Gozali
Zack Gomez
Oleg Lokhvitsky
Vladimir Timofeev
Ramanpreet Nara
Steven Cable
Mats Byrkeland
Peter Argany
Valentin Schlattinger
Ziqi Chen
Hoa Dinh
Sean Nicolay
Jerry Horton
Sahil Ohri
Julien K
Manman Ren
siddhantsoni
Sophie Alpert
Mehdi Mulani
Semen Zhydenko
Adam Putinski
Vojtech Novak
Spencer Ahrens
Stepan Hruda
Douglas
Pieter De Baets
Pritesh Nandgaonkar
Eric Davison
Alex Kotliarskyi
chendo
Nikita Tuk
Robert Paul
Y.Shing
Aditya Kumar
Sam Mueller
Jason Carreiro
tfallon@mail.depaul.edu
Jakub Grzmiel
Kellie Medlin
Sean Holbert
Neo
Janic Duplessis
Jacob Parker
Alin Panaitiu
Douglas Lowder
Jake Murzy
Dmitry Patsura
Adam Miskiewicz
Tom Clarkson
Saad Ismail
Pieter De Baets
Kip Ricker
Tomas Reimers
Steffen Matthischke
Yu Wang
Christian Brevik
Nathaniel Rankin Webb
Hank Brekke
John O'Leary
Jean Regisser
adamjmcgrath
Adam Comella
Feng999
Lukas Wöhrl
Shruti Malugu
Ben Alpert
Sokovikov
ShiHui
Martin Konicek
Emil Sjolander
Benoit VALLON
Mathieu Baudet
