Summary:
Not much to add. My OCD spotted this 😄
Closes https://github.com/facebook/react-native/pull/10275
Differential Revision: D3984542
Pulled By: hramos
fbshipit-source-id: 2de8c8f7f5c2c518e0ec5277087095e0553c72d6
Summary:
* Motivation *
Second PR for Apple TV support.
* Test plan *
Apple TV tests have been added to scripts/objc-test.sh
Closes https://github.com/facebook/react-native/pull/10227
Differential Revision: D3974064
Pulled By: javache
fbshipit-source-id: 36dffb4517efa489e40fa713a30655d1d76ef646
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?
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.
**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
Closes https://github.com/facebook/react-native/pull/10157
Differential Revision: D3974091
Pulled By: javache
fbshipit-source-id: c756fb82422253bb9098c37fbcb5637e58e53340
Summary:
These are caused by new [syntax checking](1285131e3e/CHANGELOG.md (v6113-2016-10-01)) introduced by babylon.
"The single rest at the end only applies to binding `let { x, ...y } = obj;` and assignment `({ x, ...y } = obj).`"
I'd say this really should be cherry picked into the stable branch.
**Test plan**
1. install babylon@6.11.3
2. see that things break
3. apply patch
4. things work
5. make sure all instances were fixed (I used `\.\.\..*,.*\n.*=` in IntelliJ regex format—find all ... followed by newline followed by =)
Issue #10199
Closes https://github.com/facebook/react-native/pull/10200
Differential Revision: D3974066
Pulled By: javache
fbshipit-source-id: 3f3c1e9df01a3b3bdd61dd3863416c638d3ed98d
Summary:
There is no "window" in react native. And by the way fix the indent.
Closes https://github.com/facebook/react-native/pull/10182
Differential Revision: D3974090
Pulled By: javache
fbshipit-source-id: e0e47e15364abff5bcb136d988e234fc8e1f0a8b
Summary:
Update to docs to indicate that TouchableHighlight must have exactly one child (i.e. not zero or more than one). Previously it was only indicated that it cannot have more than one.
Closes https://github.com/facebook/react-native/pull/10244
Differential Revision: D3970841
fbshipit-source-id: f1c4c223cfaf150fec9bbae1041567d0c81eb63b
Summary: Currently, for short touches (under 130ms by default), we don't trigger the highlight effect. This diff makes it so that if we're not highlighted when we invoke onPress, we highlight.
Reviewed By: astreet
Differential Revision: D3932019
fbshipit-source-id: c0ff7d4c646890507ce510f51c279c88aeba66ae
Summary:
Android (starting from API 23) supports "light status bar", thus it is possible to extend StatusBar and make `barStyle` property work not only for iOS, but also for Android.
This PR introduces one more `barStyle` option `dark-content` in addition to two existing ones (`default` and `light-content`).
Why there are 3 options instead of 2?
Two simple reasons:
1) to make all existing applications fully compatible with these changes;
2) the default status bar on Android is dark with white text and icons, while on iOS it is light with black text and icons on it. Thus the `default` option means something like "I don't really care, just apply the default color for this platform", while two other options (`light-content` and `dark-content`) allow to accurately specify the required result.
Closes https://github.com/facebook/react-native/pull/10185
Differential Revision: D3952346
fbshipit-source-id: 999a67614abff52321fbeb06298ebf1946c3f1d1
Summary:
Is okay to remove this link? It seems that we don't have the Navigator Comparison anymore.
Closes https://github.com/facebook/react-native/pull/10186
Differential Revision: D3951863
Pulled By: mmmulani
fbshipit-source-id: 170f4cc9288f84d88c3b607e3a1a85619d9776c8
Summary:
Very similar to https://github.com/facebook/react-native/pull/9600.
Does not trigger on DEV, but there are two inspectors: one underneath and one
above the modal. This looks like something we should fix, but the only solution
I've come up with so far was to mangle the event that AppContainer listens to, so that
only the AppContainer in the modal responds to it. This seems pretty ugly, I'd
rather look for something else. Wdyt?
Reviewed By: frantic
Differential Revision: D3937096
fbshipit-source-id: a6e648b6d583088514d6ba8df7851f9a8ef48f74
Summary: Provide a base `HeadlessJsTaskService` class that can be extended to run JS in headless mode in response to some event. Added `HeadlessJsTaskEventListener` for modules that are interested in background lifecycle events, and `HeadlessJsTaskContext` that basically extends `ReactContext` without touching it. The react instance is shared with the rest of the app (e.g. activities) through the `ReactNativeHost`.
Reviewed By: astreet
Differential Revision: D3225753
fbshipit-source-id: 2c5e7679636f31e0e7842d8a67aeb95baf47c563
Summary:
Simple and elegant. Now someone can dismiss a keyboard in a way that makes sense.
```js
import { Keyboard } from 'react-native'
// Hide that keyboard!
Keyboard.dismiss()
```
+ docs
Closes https://github.com/facebook/react-native/pull/9925
Differential Revision: D3935357
fbshipit-source-id: ecd2fb5c72c4dd769951d308e9bb6ee5d888052a
Summary:
This PR is related to the multitude of crashes (#10016, #9751, #9882).
From my understanding, we should be using a strong reference when calling `decodeImageData` or we could be calling the method on a deallocated instance.
PR #9751 have mitigated this by adding a fail-safe, but I think the culprint is the weak reference, which this PR fixes.
Tested on iOS only, since it doesn't touch Android.
Closes https://github.com/facebook/react-native/pull/10147
Differential Revision: D3938763
fbshipit-source-id: 7389d4ae7a98926014401a1fe0cbbdcdd5ee6a01
Summary: Changing from flex -> flexGrow on Scrollview caused some layouts to break due to having views below the scrollview. Adding flexShrink allows for the behavior again.
Reviewed By: blairvanderhoof
Differential Revision: D3936963
fbshipit-source-id: 0f43e6f5148918d3d431b98d26d185bbcc1548d0
Summary:
This changes modal behavior to resize when the keyboard appears/disappears.
Previously, the modal would not react in any way, or it would pan above to bring the
TextInput into view. Resizing is the correct behavior for android.
This is not trivial, as in, setting the flag, because of the combination of
react native laying out all views and the system reacting to the keyboard
appearance in a weird way. Namely:
- if `windowTranslucentStatus` is not set, the system will just call
`onSizeChanged` on the dialog's content view, and everything works nicely
- with `windowTranslucentStatus` set, the system will consider the dialog as a
full screen view that doesn't resize. In order for it to resize, the base
view of the layout needs to have
`setFitsSystemWindows(true)` called on it. This is needed, so that the system
can call layout on that base view with the new value of `paddingBottom` that
coincides with the height of the keyboard. Neat.
We fix this by wrapping our existing content view (mHostView) in a simple
FrameLayout that has `setFitsSystemWindows` set. That way, `mHostView` will have
`onSizeChanged` called on itself with the correct new size of the dialog.
This has the fortunate consequence of our layout now also getting `paddingTop` as the size of the
status bar, which means that we can remove the JS `top` hack in Modal, which
was necessary for no view getting drawn under the status bar.
This behavior is set as default, since that is the default correct Android behavior.
Reviewed By: astreet
Differential Revision: D3913784
fbshipit-source-id: 4378ada21f466dc7ac6e357abeca10b88009ca3f
Summary:
The Navigator component inconsistently emits the `willfocus` event.
While it is emitted in `Navigator#resetTo`, `Navigator#push`, `Navigator#pop` and event `Navigator#replaceAtIndex` it is not emitted from `Navigator#immediatelyResetRouteStack`. This leads to surprising inconsistencies when working with these events.
With the PR I suggest to emit the `willfocus` event before resetting the route stack.
Closes https://github.com/facebook/react-native/pull/10125
Differential Revision: D3931284
fbshipit-source-id: 6e4f45c6d38426bcd0acc8f8c39478524032a03a
Summary:
First commit for Apple TV support: changes to existing Objective-C code so that it will compile correctly for tvOS.
Closes https://github.com/facebook/react-native/pull/9649
Differential Revision: D3916021
Pulled By: javache
fbshipit-source-id: 34acc9daf3efff835ffe38c43ba5d4098a02c830
Summary:
Combining 2 animated values via addition, multiplication, and modulo are already supported, and this adds another one: division.
There are some cases where an animated value needs to invert (1 / x) another animated value for calculation. An example is inverting a scale (2x --> 0.5x), e.g.:
```
const a = Animated.Value(1);
const b = Animated.divide(1, a);
Animated.spring(a, {
toValue: 2,
}).start();
```
`b` will then follow `a`'s spring animation and produce the value of `1 / a`.
The basic usage is like this:
```
<Animated.View style={{transform: [{scale: a}]}}>
<Animated.Image style={{transform: [{scale: b}]}} />
<Animated.View>
```
In this example, the inner image won't get stretched at all because the parent's scaling gets cancelled out.
Also added this to native animated implementation.
Reviewed By: foghina, mmmulani
Differential Revision: D3922891
fbshipit-source-id: 32508956c4b65b2deb7574d50a10c85b4809b961
Summary:
This diff adds support for value offsets on iOS. It separates out code originally submitted in #9048.
Test plan (required)
Set up an animation with an offset, and `useNativeModule: true`. Compare results with `useNativeModule: false`.
Closes https://github.com/facebook/react-native/pull/9627
Differential Revision: D3924410
fbshipit-source-id: 8177a25a5f6b9e33f00ea66143c782aeea24507d
Summary:
This fixes measuring of items in the main axis of a container. Previously items were in a lot of cases measured with UNSPECIFIED instead of AT_MOST. This was to support scrolling containers. The correct way to handle scrolling containers is to instead provide them with their own overflow value to activate this behavior. This is also similar to how the web works.
This is a breaking change. Most of your layouts will continue to function as before however some of them might not. Typically this is due to having a `flex: 1` style where it is currently a no-op due to being measured with an undefined size but after this change it may collapse your component to take zero size due to the implicit `flexBasis: 0` now being correctly treated. Removing the bad `flex: 1` style or changing it to `flexGrow: 1` should solve most if not all layout issues your see after this diff.
Reviewed By: majak
Differential Revision: D3876927
fbshipit-source-id: 81ea1c9d6574dd4564a3333f1b3617cf84b4022f
Summary:
_renderScene would unnecessary test if `this.state.transitionFromIndex != null` twice.
The left side and right side of the 'or' statement would always be the same.
For cleaner code I suggest to remove it.
Closes https://github.com/facebook/react-native/pull/10042
Differential Revision: D3923058
fbshipit-source-id: 7466c1f0f24eac3f9f296debd9a5e9f5320aea28
Summary:
The suppression comment was not formatted correctly and thus not
used.
Closes https://github.com/facebook/react-native/pull/10076
Differential Revision: D3917036
fbshipit-source-id: 92927993fb7223dc131d82096ca92017aea5f1aa
Summary:
Hi there,
when using the ScrollView component with `onScroll` and `scrollEventThrottle = 0` as it is documented in [react-native/docs/scrollview](https://facebook.github.io/react-native/docs/scrollview.html#scrolleventthrottle) this message will appear unnecessary.
This happens because `!this.props.scrollEventThrottle` is `true` when the value is `0`.
So I changed it to `this.props.scrollEventThrottle == null`. Now it is `false` when the value is `0`.
Closes https://github.com/facebook/react-native/pull/10038
Differential Revision: D3909323
fbshipit-source-id: 3c701f23708b64576a8c9f47e140d87159087894
Summary: If a user scrolls the `SwipeableListView`, any open row(s) will close.
Reviewed By: furdei
Differential Revision: D3903787
fbshipit-source-id: efd9ae896ba50ad6e83e72d52bc1f5c0c35efd61
Summary:
Fixes an issue where location request timeout errors always reported "Unable to fetch location within **0s**".
Previously we had `@"Unable to fetch location within %zds.", (NSInteger)(timer.timeInterval * 1000.0)` but from the [NSTimer.timeInterval docs](https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSTimer_Class/#//apple_ref/occ/instp/NSTimer/timeInterval) "If the receiver is a non-repeating timer, returns 0 even if a time interval was set.".
Change to use `request.options.timeout` instead, which is a `Double` defaulting to `INFINITY`. Tested on an iOS simulator.
Closes https://github.com/facebook/react-native/pull/9888
Differential Revision: D3902788
Pulled By: javache
fbshipit-source-id: aef717d6c39f3177cb7056a17adc35c1bfd94132
Summary:
This fixes https://github.com/facebook/react-native/issues/9751
We were seeing the same issues as the original reporter.
I'm not an expert on this code, so apologies if it's naive, but we haven't seen the crash since making this change.
From my understanding of it, it seems like the `cancelLoad` block was being released before the block returned by `_loadImageOrDataWithURLRequest:` was called.
This PR checks the `cancelled` flag before calling `cancelLoad()`.
Closes https://github.com/facebook/react-native/pull/10016
Differential Revision: D3902723
Pulled By: javache
fbshipit-source-id: 75cd115e28694105c6fc29469986998ca0d4cd09
Summary:
While working on a feature in realized the buttons I built using `TouchableHighlight` were too dark when pressed.
When used white white views, `TouchableHighlight` produces the color `d4d5d5`. This is different from `dedede` which iOS uses.
Let's use opacity 0.85 instead of 0.8 to make the color match iOS. See a React Native view compared to iOS settings screen (same color for pressed items now): http://imgur.com/a/6CyL3
On Android, people should be using `TouchableNativeFeedback` everywhere.
Reviewed By: sahrens
Differential Revision: D3896168
fbshipit-source-id: a7dd12b4bde079b120faaffc36d25292533a2c6d
Summary:
In certain cases, if a navigation title is present in place of an empty nav stack, the first breadcrumb may steal part of the title's touch events since it's hardcoded to sit 1/4 from the left of the screen (for animation reasons). This diff fixes it, allowing titles on an empty nav stack to be entirely touchable while retaining all other breadcrumb functionality.
Also, applied some suggested lint changes.
Reviewed By: hedgerwang
Differential Revision: D3891909
fbshipit-source-id: 97d1fb3bba4e4118401d84cec2d8836b94bfde75
Summary:
Since API 18, Android locations have had the `isFromMockProvider()` function, to verify the validity of a provided location. This was one of many methods one could verify location data, but as of Marshmallow, the other ways of detecting if "Mock Locations" is on in developer settings has been deprecated or defunct.
This means some devices can only detect location mocking by exposing the method on the location object.
This change provides that exposure.
Closes https://github.com/facebook/react-native/pull/9390
Differential Revision: D3858205
Pulled By: bestander
fbshipit-source-id: 3bae429cc0596ea01926c5be204f4403e4a2414f
Summary:
Explain the **motivation** for making this change. What existing problem does the pull request solve?
Copy&paste from the example in the documentation will cause exception because there is no `AndroidPermissions` object. To avoid confusion we should refer to `PermissionsAndroid` instead since this is how this module is named in the API.
Closes https://github.com/facebook/react-native/pull/9956
Differential Revision: D3889080
Pulled By: hramos
fbshipit-source-id: 8f30d8f51ffee1321088a16a1b454ab163a746a2
Summary:
When debugging in VScode or nucleide using a nodejs environment rather than chrome, the JS sources are made to appear as if they exist on disk, rather than coming from a `http://` url. Prior to this change the packager would see these file paths and not know how to handle them.
Since all the application JS will be part of a bundle file, we can switch out the path to the bundle on the filesystem with paths to the bundle served by the packager, and things will work just as though it was debugging in chrome. We stop the replacement once we reach an internal module (`vm.js` in the case of both nucleide and VSCode) since that is the point when the execution switches from inside the app to the surrounding debugging environment.
I've verified that this fixes redbox stack trace symbolication in VSCode, and from my understanding of nucleide's debugging environment it should also work there without requiring any changes.
Closes https://github.com/facebook/react-native/pull/9906
Differential Revision: D3887166
Pulled By: davidaurelio
fbshipit-source-id: e3a6704f30e0fd045ad836bba51f6e20d9854c30
Summary:
Currently, it's hard to find out that it's very easy to use android toasts. The example is very complex and hard to grasp for a beginner. So, I propose to add an easy to understand example.
I'm sure the syntax of this PR is not really correct, it's just a start to show the kind of thing I propose.
Closes https://github.com/facebook/react-native/pull/9859
Differential Revision: D3886274
Pulled By: donyu
fbshipit-source-id: 15e693f5ddb1efea0fc6b7accfa688fd5f99a100
Summary:
This adds support for `Animated.event` driven natively. This is WIP and would like feedback on how this is implemented.
At the moment, it works by providing a mapping between a view tag, an event name, an event path and an animated value when a view has a prop with a `AnimatedEvent` object. Then we can hook into `EventDispatcher`, check for events that target our view + event name and update the animated value using the event path.
For now it works with the onScroll event but it should be generic enough to work with anything.
Closes https://github.com/facebook/react-native/pull/9253
Differential Revision: D3759844
Pulled By: foghina
fbshipit-source-id: 86989c705847955bd65e6cf5a7d572ec7ccd3eb4
Summary:
see also: eb3360b02a (commitcomment-19042340)
commit eb3360b02a recently break some third libraries that was (weakly) relying on traversing `animatedNode.refs.node` to get the original node of the decorated (animated) component (at least 2 libs: gl-react-native and react-native-material-kit).
Instead of now doing `animatedNode._component` (that might later break again), getNode() is a more 'public' solution for these third party.
as you expose a way to create an animated component (`createAnimatedComponent`) you sometimes still want a way to get the reference.
That way, third party components can continue providing some extra native methods to the animated version.
Closes https://github.com/facebook/react-native/pull/9944
Differential Revision: D3885973
Pulled By: foghina
fbshipit-source-id: 43ffdbfe7f9c52f5a1689e6a9a4052d4973f5c5f
Summary:
This adds support for sticky headers on Android. The implementation if based primarily on the iOS one (https://github.com/facebook/react-native/blob/master/React/Views/RCTScrollView.m#L272) and adds some stuff that was missing to be able to handle z-index, view clipping, view hierarchy optimization and touch handling properly.
Some notable changes:
- Add `ChildDrawingOrderDelegate` interface to allow changing the `ViewGroup` drawing order using `ViewGroup#getChildDrawingOrder`. This is used to change the content view drawing order to make sure headers are drawn over the other cells. Right now I'm only reversing the drawing order as drawing only the header views last added a lot of complexity especially because of view clipping and I don't think it should cause issues.
- Add `collapsableChildren` prop that works like `collapsable` but applies to every child of the view. This is needed to be able to reference sticky headers by their indices otherwise some subviews can get optimized out and break indexes.
Closes https://github.com/facebook/react-native/pull/9456
Differential Revision: D3827366
Pulled By: fred2028
fbshipit-source-id: d346068734c5b987518794ab23e13914ed13b5c4
Summary:
This adds support for sticky headers on Android. The implementation if based primarily on the iOS one (https://github.com/facebook/react-native/blob/master/React/Views/RCTScrollView.m#L272) and adds some stuff that was missing to be able to handle z-index, view clipping, view hierarchy optimization and touch handling properly.
Some notable changes:
- Add `ChildDrawingOrderDelegate` interface to allow changing the `ViewGroup` drawing order using `ViewGroup#getChildDrawingOrder`. This is used to change the content view drawing order to make sure headers are drawn over the other cells. Right now I'm only reversing the drawing order as drawing only the header views last added a lot of complexity especially because of view clipping and I don't think it should cause issues.
- Add `collapsableChildren` prop that works like `collapsable` but applies to every child of the view. This is needed to be able to reference sticky headers by their indices otherwise some subviews can get optimized out and break indexes.
Closes https://github.com/facebook/react-native/pull/9456
Differential Revision: D3827366
fbshipit-source-id: cab044cfdbe2ccb98e1ecd3e02ed3ceaa253eb78
Summary: Introduce `overflow:scroll` so that scrolling can be implemented without the current overflow:visible hackiness. Currently we use AT_MOST to measure in the cross axis but not in the main axis. This was done to enable scrolling containers where children are not constraint in the main axis by their parent. This caused problems for non-scrolling containers though as it meant that their children cannot be measured correctly in the main axis. Introducing `overflow:scroll` fixes this.
Reviewed By: astreet
Differential Revision: D3855801
fbshipit-source-id: 3c365f9e6ef612fd9d9caaaa8c650e9702176e77
Summary: Introduce `overflow:scroll` so that scrolling can be implemented without the current overflow:visible hackiness. Currently we use AT_MOST to measure in the cross axis but not in the main axis. This was done to enable scrolling containers where children are not constraint in the main axis by their parent. This caused problems for non-scrolling containers though as it meant that their children cannot be measured correctly in the main axis. Introducing `overflow:scroll` fixes this.
Reviewed By: astreet
Differential Revision: D3855801
fbshipit-source-id: 6077b0bcb68fe5ddd4aa22926acab40ff4d83949
Summary:
We've enabled getters in .flowconfig, so Flow will now understand react-native.js. We no longer need to maintain a separate file for Flow.
cc bestander
Closes https://github.com/facebook/react-native/pull/9892
Differential Revision: D3862560
Pulled By: bestander
fbshipit-source-id: 9efb66bc885dbac80c18b4b5e3cf5362495928a9
Summary:
Fixes https://github.com/facebook/react-native/issues/9216.
As nickzuber describes in #9216, conditional `Picker.Item` elements will lead to exceptions downstream when the `Picker` attempts to construct the collection of items.
[In the picker source](a2fb703bbb/Libraries/Components/Picker/PickerIOS.ios.js (L48-L53)) we can see that `child.props` is accessed when `child` has the potential to be an invalid `React` element.
```js
ReactChildren.forEach(props.children, function (child, index) {
if (child.props.value === props.selectedValue) {
selectedIndex = index;
}
items.push({value: child.props.value, label: child.props.label});
});
```
This change ensures the incoming element is valid
```diff
ReactChildren.forEach(props.children, function (child, index) {
+ if (!React.isValidElement(child)) {
+ return;
+ }
if (child.props.value === props.selectedValue) {
selectedIndex = index;
}
items.
Closes https://github.com/facebook/react-native/pull/9243
Differential Revision: D3847514
Pulled By: spicyj
fbshipit-source-id: f46fbd4b0f81de7a92e1ca3e60b5ed15a9cbbf78
Summary:
Explain that, unlike other APIs, geolocation follows the browser spec and is exposed through `navigator.geolocation` rather than as an `react-native` export.
This can be inferred from the example code but isn't otherwise stated in the docs. See also https://github.com/facebook/react-native/pull/9793
Closes https://github.com/facebook/react-native/pull/9810
Differential Revision: D3841341
Pulled By: javache
fbshipit-source-id: b1423e8bf7fb78c788f5cdc5630a4a948b8178c6
Summary:
Here's a little background. Resizing is inferior to scaling. See http://frescolib.org/docs/resizing-rotating.html#_
Currently, React Native has a heuristic to use resize when the image is likely to be from the device's camera. However, there may be other cases where a developer wants to use resize. For example, when the developer knows they'll be downloading a large image from a service but the image will be rendered at a small size on the device.
This change adds a `resizeMethod` prop to the `Image` component so developers can choose how Fresco resizes the image. The options are 'auto', 'resize', or 'scale'. When 'auto' is specified, a heuristic is used to choose between 'resize' and 'scale'. The default value is 'auto'.
**Test plan (required)**
In a small test app, verified that the `resizeMethod` prop properly influences the mechanism that is used to resize the image (e.g. resize or scale).
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/9652
Differential Revision: D3841322
Pulled By: foghina
fbshipit-source-id: 6c78b5c75ea73053aa10386afd4cbff45f5b8ffe
Summary:
`Navigator` throws an error if using a custom `NavigationBar` component that does not have a `immediatelyRefresh` method present.
Closes https://github.com/facebook/react-native/pull/9438
Differential Revision: D3838928
Pulled By: mkonicek
fbshipit-source-id: 74d62ef09e179f457a4b14f8537dfaf0d4697322
Summary:
Fix for https://github.com/facebook/react-native/issues/9465
We are building a react-native based application which extensively uses WebSockets. The Android app crashes right after waking up being in suspended mode for a coupe of days and throws an exception:
"Cannot send a message. Unknown WebSocket id 1"
Before calling WebSocket.send(...) method from WebSocket.js we always check its readyState. I believe the problem is caused by not updating readyState if case of 'websocketFailed' event. this.close() cause the current used websocket ID to be removed from mWebSocketConnections HashMap (WebSocketModule.java), but readyState stays the same.
Closes https://github.com/facebook/react-native/pull/9487
Differential Revision: D3838675
Pulled By: mkonicek
fbshipit-source-id: e833cef9f1b94c6f7236077241cacf5a56f5824b
Summary:
Resolves#7081 by allowing iCloud to download photos not stored on the device.
**Test plan (required)**
1. Verified existing photos stored on the device still display.
2. Deleted my iCloud photo library from my phone and verified the image downloads and displays.
Closes https://github.com/facebook/react-native/pull/9530
Differential Revision: D3838470
Pulled By: mkonicek
fbshipit-source-id: 810830a4246714b6e166e4411f3fa848b1f1b71c
Summary:
JSC on iOS 8 and above includes TypedArrays so there's no need for the guard statement anymore since React Native officially does not support iOS 7 moving forward.
Closes https://github.com/facebook/react-native/pull/9780
Differential Revision: D3834979
Pulled By: mkonicek
fbshipit-source-id: 6e28a47702d6e3d604fedb9d2d00fe1c539a6926
Summary: Get rid of the old behaviour of JSON encoding in `nativeRequireModuleConfig` and consistently use the same names for function types "async/promise/sync"
Reviewed By: lexs
Differential Revision: D3819348
fbshipit-source-id: fc798a5abcaf6a3ef9d95bd8654afa7825c83967
Summary:
Hi!
I found problem with accessibilityLabel on PickerAndroid.
There's no value in content-desc attribute while accessibilityLabel is correct.
I found that accessibilityLabel is not propagated into native components via
native props.
This PR brings accessibilityLabel for PickerAndroid.
Without this solution my appium tests fails, for example:
My code:
```jsx
<Picker
style={this.props.style}
selectedValue={this.props.value}
onValueChange={this.onChange}
disabled={this.props.disabled}
accessibilityLabel="select_wineType">
// Chilren
</Picker>
```
```sh
✖ Error: element (~select_wineType) still not visible after 5000ms
```
Because xml of this view is (look into content-desc of Spinner):
```xml
<android.widget.Spinner index="0" text="" class="android.widget.Spinner" package="com.hello_github" content-desc="" checkable="false" checked="false" clickable="true" enabled="true" focusable="true" focused="false" scrollable="true" long-clickable="false" password=
Closes https://github.com/facebook/react-native/pull/8873
Differential Revision: D3831691
Pulled By: spicyj
fbshipit-source-id: a494f22cb8be8cd6964981fe7ef7d9ff3773bcce
Summary: Cleans things up and also defers rendering rows if there is an interaction happening.
Reviewed By: achen1
Differential Revision: D3817231
fbshipit-source-id: fd08d0ca7cb6c203178f27bfc5a0f55469135c3a
Summary:
Add native support on iOS and Android for `Animated.diffClamp` that was added in #9419.
**Test plan**
Tested that it works properly using the native animations UIExplorer example.
Closes https://github.com/facebook/react-native/pull/9691
Differential Revision: D3813440
fbshipit-source-id: 48a3ecddf3708fa44b408954d3d8133ec8537f21
Summary:
Adds support for the `extrapolate` parameter on the native interpolation node. This is pretty much a 1 to 1 port of the JS implementation.
**Test plan**
Tested by adding the `extrapolate` parameter in the native animated UIExplorer example.
Closes https://github.com/facebook/react-native/pull/9366
Differential Revision: D3824154
fbshipit-source-id: 2ef593af827a8bd3d7b8ab2d53abbdc9516c6022
Summary:
This is an updated version of #2336 and #7694.
---
This adds a `registrationError` event that is emitted by `PushNotificationIOS` whenever an application receives a registration error from APNS (APNS service failure, running on simulator, etc). This event fires to the exclusion of the `register` event (and vice versa).
**How to use**
Add the following to your `AppDelegate.m`:
```obj-c
- (void)application:(UIApplication *)application didFailToRegisterForRemoteNotificationsWithError:(NSError *)error
{
[RCTPushNotificationManager didFailToRegisterForRemoteNotificationsWithError:error];
}
```
And register an event handler for the event:
```js
PushNotificationIOS.addEventListener('registrationError', function({ message, code }) {
// Complete your registration process in error.
});
```
**Test plan**
Added support for this event (and `register`) to UIExplorer as a proof of concept. Navigating to the push notifications example on a simulator is an easy way to reproduce this e
Closes https://github.com/facebook/react-native/pull/9650
Differential Revision: D3822142
Pulled By: javache
fbshipit-source-id: a15ed8941b74dc3eed2c44c658deccbcaf39ce3d
Summary:
Include CSSLayout headers in the same way as other project headers, ie `#import <CSSLayout/CSSLayout.h>` becomes `#import "CSSLayout.h"`. CSSLayout is not a framework or system dependency, so shouldn't (AFAIK) be included with angle brackets. Doing so breaks framework builds, such as when RN is used as a pod in a swift project.
In combination with https://github.com/facebook/css-layout/pull/217 this fixes https://github.com/facebook/react-native/issues/9014 (specifically swift cocoapods projects). There is then no need for a separate CSSLayout pod subspec.
Tests run on the RN project in isolation (with changes inside `CSSLayout` itself also applied) and against a dummy swift project with RN included as a pod.
NB: This effectively reverts https://github.com/facebook/react-native/pull/9015 and may break non-swift cocoapods projects unless https://github.com/facebook/css-layout/pull/217 is merged and synced first.
Update: As discussed with alloy and emilsjolander, wrap these imports in a preprocess
Closes https://github.com/facebook/react-native/pull/9544
Differential Revision: D3821791
Pulled By: javache
fbshipit-source-id: d27ac8be9ce560d03479b43d3db740cd196c24da
Summary:
Currently, when sharing local files, the file contents are being sent as NSData causing the file to never be attached when sharing via Email or via Airdrop, being renamed to something obscure such as (null)-257D026032E9-1.data
Simply passing the Local File URL to UIActivityViewController instead of the file contents resolves this issue.
More info on this issue: https://github.com/facebook/react-native/issues/8442
Closes https://github.com/facebook/react-native/pull/9693
Differential Revision: D3821142
Pulled By: javache
fbshipit-source-id: a06128db88d24cf5565169f321365ace43ab89fe
Summary:
Currently when doing a file upload, the Content-Type header gets set to whatever MIME type iOS computed for the file. The Content-Type header the developer provided never takes precedence.
For example, when uploading an image, iOS might determine that the MIME type is "image/jpeg" and so this would be the Content-Type of the HTTP request. But the developer might need the Content-Type to be "application/octet-stream". With this change, if the developer provides a Content-Type header, it will not be overriden.
There is only one exception to this rule which is for "multipart" requests. In this case, the developer's Content-Type header is always ignored. This is because the Content-Type header needs to contain the boundary string and that information is not available to the developer in JavaScript.
This change makes iOS's behavior more consistent with Android's.
**Test plan (required)**
In a small test app, verified that the developer's Content-Type header takes precedence when it's provided. Verif
Closes https://github.com/facebook/react-native/pull/9651
Differential Revision: D3820001
Pulled By: mkonicek
fbshipit-source-id: fdb8871f88a0d0db1ae59f75bb62b896fe69542d
Summary:
Update documentation for Switch as it's not a background color that is displayed when the switch off, but juste the border (the background remains transparent)
Closes https://github.com/facebook/react-native/pull/9707
Differential Revision: D3819887
Pulled By: mkonicek
fbshipit-source-id: 218fd20deaded5260cc51e815b559f3cbbb3f752
Summary:
Android PR for TextInput selection, based on the iOS implementation in #8958.
** Test plan **
Tested using the text selection example in UIExplorer.
Closes https://github.com/facebook/react-native/pull/8962
Differential Revision: D3819285
Pulled By: andreicoman11
fbshipit-source-id: 9a2408af2a8b694258c88ab5c46322830c71452a
Summary:
When bringing back `node-haste` to React Native, I left an `fdescribe` in a test that led to ~70 tests being skipped.
This re-enables these tests, and fixes test failures
Reviewed By: cpojer
Differential Revision: D3811225
fbshipit-source-id: 67a16f385759bb829f1f3f559862eab7e78f2097
Summary:
It's very confusing that this modules doesn't work like most others. I believe it would be beneficial to state that upfront. When you know that you *have* to link the CameraRoll library then the resources help you know how to link are pretty straightforward.
Closes https://github.com/facebook/react-native/pull/9708
Differential Revision: D3809715
fbshipit-source-id: b100874426146d38251c52fde29502e4dda74d40
Domenico Matteo
Neil Sarkar
Douglas Lowder
Nader Dabit
Michał Łazowik
sunnylqm
pedramsaleh
Chace Liang
Felix Oghina
Jeff Morrison
Alexander Pantyuhov
AgtLucas
Andrei Coman
Gant Laborde
Mattias Pfeiffer
Emil Sjolander
Lord Daniel Zautner
Kevin Gozali
Ryan Gomba
Matej Matiasko
Erik Arvidsson
Pieter De Baets
Fred Liu
Dustin Hoffner
Rob Hogan
Toby Cox
Mehdi Mulani
Martin Konicek
Stanisław Wasiutyński
Cristian Carlesso
Laguana
Damien
Janic Duplessis
Gaëtan Renaudeau
Eric Vicenti
Muhammad Raihan Muhaimin
leeight
Spencer Ahrens
Satyajit Sahoo
Spike Brehm
Atticus White
yunfeng
Adam Comella
Jacob Parker
Andrew Grewell
Dmitry Petukhov
Ron Heft
James Ide
Tobias Ritzau
Anton Kuznetsov
Gabe Levi
Ian MacLeod
sheparddw
Pierre-Yves Desnoues
Jake Murzy
David Aurelio
Nobuhito Kurose
michaelAndersonCampingWorld
Marc Horowitz
