Summary:
It is time to target SDK version 10.0+.
Changelog: [iOS] [Deprecated] - Deprecating support for iOS/tvOS SDK 9.x, 10.0+ is now required
Reviewed By: mdvacca
Differential Revision: D19265731
fbshipit-source-id: 93b6f9e8f61c5b36ff69e80d3f18256aa96cc2c0
Summary:
We are rolling out exact-by-default syntax to xplat/js.
I had to manually move around some comments to preserve proper placement.
Changelog: [Internal]
Reviewed By: jbrown215
Differential Revision: D18633611
fbshipit-source-id: 48f7468dcc55b1d00985419d035a61c6820b3abe
Summary:
Changelog: [Internal]
Reverting the import to the previous local module style since importing from react-native seems to introduce some perf regression. We'll revisit this later in the future.
Reviewed By: yungsters
Differential Revision: D18383893
fbshipit-source-id: f11d46a4545768f39199fd6fd22fcf14905d0a74
Summary:
Changelog: [Internal]
Moved the imports for `TurboModuleRegistry` and `TurboModule` from `react-native`. This was a jscodeshift with the script: P120688078
Reviewed By: yungsters
Differential Revision: D18262538
fbshipit-source-id: 48fac15229c897408928511c5ecbb42f17ec7b42
Summary:
Cleans up all the Jest tests to minimize spurious console output.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D18289690
fbshipit-source-id: cdcecca879b3b85d3dccf9e0ab617ea7dc1e0777
Summary:
`responseType` should be a string, not an Object (which gets converted to a NativeMap by TM).
Changelog: [General] [Fixed] Fix the flow type for NativeNetworkingModule
Reviewed By: fkgozali
Differential Revision: D18019418
fbshipit-source-id: 316470ca82241223eafb5b05a54fc2bbf3074821
Summary:
@public
We're seeing crashes from multiple threads trying to call `[NSData appendData:]` at the same time. Usually the RCTURLRequestHandlers implementation avoids this but if you're using a background queue, it is pretty easy to reach this case.
Adding a lock to accessors of `_data` should prevent this.
Reviewed By: shergin
Differential Revision: D17552136
fbshipit-source-id: 3384d36221d0ada8cda638ad8e79e1bf3862f93f
Summary: This is the only remaining part of NetInfo that's in open source. Moving it to FB internal.
Reviewed By: motiz88
Differential Revision: D17343031
fbshipit-source-id: 482a2daa397aa9f1391a72775735027de996ddb3
Summary:
As part of the fix for https://github.com/facebook/react-native/issues/25349 I added `s.static_framework = true` to each podspec in repo (see https://github.com/facebook/react-native/pull/25619#discussion_r306993309 for more context).
This was required to ensure the existing conditional compilation with `#if RCT_DEV` and `__has_include` still worked correctly when `use_frameworks!` is enabled.
However, fkgozali pointed out that it would be ideal if we didn't have this requirement as it could make life difficult for third-party libraries.
This removes the requirement by moving `React-DevSupport.podspec` and `React-RCTWebSocket.podspec` into `React-Core.podspec` as subspecs. This means the symbols are present when `React-Core.podspec` is built dynamically so `s.static_framework = true` isn't required.
This means that any `Podfile` that refers to `React-DevSupport` or `React-RCTWebSocket` will need to be updated to avoid errors.
## Changelog
I don't think this needs a changelog entry since its just a refinement of https://github.com/facebook/react-native/pull/25619.
Pull Request resolved: https://github.com/facebook/react-native/pull/25816
Test Plan:
Check `RNTesterPods` still works both with and without `use_frameworks!`:
1. Go to the `RNTester` directory and run `pod install`.
2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine.
3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again.
4. Run the tests again and see that it still works with frameworks enabled.
Reviewed By: hramos
Differential Revision: D16495030
Pulled By: fkgozali
fbshipit-source-id: 2708ac9fd20cd04cb0aea61b2e8ab0d931dfb6d5
Summary:
This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349.
It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`.
The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` .
There are still a few breaking changes which I hope will be acceptable:
- `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path.
- ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823.
- ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823.
- ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967.
- ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823.
- Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled.
Still to do:
- ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by 33573511f0.
- I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? �
## Changelog
[iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks.
Pull Request resolved: https://github.com/facebook/react-native/pull/25619
Test Plan:
### FB
```
buck build catalyst
```
### Sample Project
Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed.
You can see that it works with these steps:
1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git`
2. `git checkout fix-frameworks-subspecs`
3. `cd ios && pod install`
4. `cd .. && react-native run-ios`
The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again.
### RNTesterPods
`RNTesterPodsPods` can now work with or without `use_frameworks!`.
1. Go to the `RNTester` directory and run `pod install`.
2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine.
3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again.
4. Run the tests again and see that it still works with frameworks enabled.
Reviewed By: PeteTheHeat
Differential Revision: D16465247
Pulled By: PeteTheHeat
fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
Summary: Currently callback has type `callback: (result: boolean) => mixed` what is pointless (and breaks codegen), because value returning flow callback doesn't have any impact.
Reviewed By: RSNara
Differential Revision: D16282852
fbshipit-source-id: fe1036f17bff307ac91b280727eaa5bf81febd35
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/25583
We now use CocoaPods for better maintainability.
Reviewed By: hramos
Differential Revision: D16193719
fbshipit-source-id: 26382f2da4eaba14a71771540b587fdc80b41108
Summary:
This PR adds initial support for Project Catalyst a.k.a. UIKitForMac. This is not yet meant for production, but this is enough for RNTester to successfully compile and mostly work :)
Some APIs are not supported on the Mac -- e.g. telephony, and deprecated APIs are removed on Mac ���-- those had to be ifdef'd out via platform checks.
The biggest limitation right now is that I couldn't get Web Socket code to successfully compile, and so there are a lot of temporary platform checks for that , and the RCTWebSocket.xcodeproj is marked as not supporting UIKitForMac. Again -- temporary, until someone with more knowledge knows how to fix this.
https://github.com/react-native-community/discussions-and-proposals/issues/131
## Changelog
[iOS] [Added] - Fixed compilation for macOS (Project Catalyst) -- not meant for production use yet
Pull Request resolved: https://github.com/facebook/react-native/pull/25427
Test Plan:
- Open RNTester/RNTester.xcodeproj with Xcode 10.2, run it like a normal iOS app -- make sure it compiles and runs correctly (no regression)
- Open the same project with Xcode 11 beta 2 (or higher) on macOS Catalina beta, select "My Mac" as device target, and run -- see that it actually compiles and runs. **Note** there are unfortunately some required steps:
- change build configuration to Release (because packager doesn't work correctly yet)
- change development team to yours if Xcode tells you to
- go to RNTester project → Build phases → Link binary with libraries, and change `platforms` for `libRCTWebSocket.a` to `iOS` (without Mac compatibility). I can't commit that change because it breaks compatibility with earlier Xcode versions
The two extra steps for successful compile will disappear once web socket compilation for Catalyst is fixed
Reviewed By: mmmulani
Differential Revision: D16088263
Pulled By: sammy-SC
fbshipit-source-id: 9c0b932b048e50a8e0f336eaa0612851b1909cae
Summary:
The old whatwg-fetch module doesn't actually export anything, so we would always hit the `else` condition.
The new whatwg-fetch (3.0.0, introduced in #24418) now exports an ES module. As a result, `whatwg` and `whatwg.fetch` are both truthy but the `module.exports` will end up empty. This breaks the RN fetch module.
This will switch the behavior back to the expected polyfill behavior (calling `require('whatwg-fetch')` and allowing it to polyfill fetch in global scope). The RN fetch module will re-export these globals.
Reviewed By: cpojer
Differential Revision: D15639851
fbshipit-source-id: ebd8bce85f7797d8539f53982e515ac47f6425e7
Summary:
There exists race condition in `sendRequest:withDelegate:` method, it can do the session creation multiple times, because we don't lock that, which would leads `EXC_BAD_ACCESS` because use and deallocated session concurrently, we can refer to how to create a singleton safely.
Related https://github.com/facebook/react-native/issues/25152.
## Changelog
[iOS] [Fixed] - Fixes race condition of Network module
Pull Request resolved: https://github.com/facebook/react-native/pull/25156
Differential Revision: D15671734
Pulled By: sammy-SC
fbshipit-source-id: 5021e6cf33c2b55e3f7adf573ab5c8e6a8d82e23
Summary:
The original reason for vendoring the fetch polyfill was to remove the default blob response type but this was reverted.
Here's a little history around the fetch polyfill and the blob issue:
- Original commit introducing the vendored polyfill: #19333, the goal was to fix a memory leak because our blob implementation doesn't release resources automatically. Not an ideal fix but since the issue was pretty severe and the infra for a proper fix was not in place.
- This introduced an issue when downloading images using `fetch` which was fixed by #22063 which re-added the default blob content type. However that re-introduced the original fetch memory leak.
- We have better infra now with jsi and I was able to get blob deallocation working, see #24405
Currently the vendored fetch polyfill is useless since it was changed back to the original version. We can just use the npm version again. I also updated to 3.0 which brings better spec compliance and support for cancellation via `AbortController`, https://github.com/github/fetch/releases/tag/v3.0.0.
## Changelog
[General] [Changed] - Remove vendored fetch polyfill, update to whatwg-fetch@3.0
Pull Request resolved: https://github.com/facebook/react-native/pull/24418
Differential Revision: D14932683
Pulled By: cpojer
fbshipit-source-id: 915e3d25978e8b9d7507ed807e7fba45aa88385a
Summary:
This is an ESLint plugin that infers whether an import looks like a Haste module name. To keep the linter fast and simple, it does not look in the Haste map. Instead, it looks for uppercase characters in single-name import paths, since npm has disallowed uppercase letters in package names for a long time. There are some false negatives (e.g. "merge" is a Haste module and this linter rule would not pick it up) but those are about 1.1% of the module names in the RN repo, and unit tests and integration tests will fail anyway once Haste is turned off.
You can disable the lint rule on varying granular levels with ESLint's normal disabling/enabling mechanisms.
Also rewrote more Haste imports so that the linter passes (i.e. fixed lint errors as part of this PR).
## Changelog
[General] [Changed] - Add a lint rule to disallow Haste imports
Pull Request resolved: https://github.com/facebook/react-native/pull/25058
Differential Revision: D15515826
Pulled By: cpojer
fbshipit-source-id: d58a3c30dfe0887f8a530e3393af4af5a1ec1cac
Summary:
Part of #24875, adds a spec for Networking. Since `sendRequest` methods are different for both platforms, I had to create 2 spec files as Flow would merge their definitions even when I added `Platform.OS` check
## Changelog
[General] [Added] - TM spec for Networking
Pull Request resolved: https://github.com/facebook/react-native/pull/24892
Reviewed By: RSNara
Differential Revision: D15543067
Pulled By: fkgozali
fbshipit-source-id: 2b91114dfa45e7899bbb139656a30a6fd52e31db
Summary: This removes the NetInfo import from RN and moves it to FB internal. Follow-up diffs will move the Android and iOS files as well.
Reviewed By: rubennorte
Differential Revision: D15392486
fbshipit-source-id: b868b671b8d91661bc7634b4662074ae953835be
Summary:
In D15367312, I deprecate `$Enum<...>` in favour of `$Keys<...>` (the functionality is identical). Codemod existing usages in xplat and fbcode.
bypass-lint
Reviewed By: samwgoldman
Differential Revision: D15378084
fbshipit-source-id: 251c6b9ac07cb50139a8f03e3a45a5fac0d91812
Summary:
We provided `ReactNetworkForceWifiOnly` in https://github.com/facebook/react-native/pull/24242, but it's a string type, actually the value only YES or NO, so let's change it to Boolean type, we can benefit from:
1. Users don't need to type string `YES`, just select bool YES or NO directly by click the button:
<img width="789" alt="image" src="https://user-images.githubusercontent.com/5061845/57634311-a8af7400-75d7-11e9-9f8a-ebf865d672e3.png">
2. Don't need to do string compare.
3. More looks what it should looks, Boolean is the Boolean. :)
cc. cpojer ericlewis .
[iOS] [Changed] - Change ReactNetworkForceWifiOnly from String to Boolean
Pull Request resolved: https://github.com/facebook/react-native/pull/24829
Differential Revision: D15323685
Pulled By: cpojer
fbshipit-source-id: c626d048d0cbea46d45f232906fd3ac32a412741
Summary:
On iOS in React Native, immediately after successfully connecting to a WiFi network, if 4G is also on, it is possible that network requests sent via fetch get sent over 4G instead of WiFi for several seconds (between 1 and 40+ seconds depending on the device and network in my experience). If the calls are meant to be communicating with a local Wireless Device (such as a wireless router, etc.), then API calls that get sent over 4G to the internet are lost. Note that Reachability/NetInfo are saying that we are connected to a WiFi network and are not sufficient to prevent this from happening. To prevent this, I would like to be able to set an instance property that iOS exposes for network requests allowsCellularAccess to NO to ensure a request is never sent over 4G.
This code needs to be able to accept a flag to allow the user to override the default value of YES, but only when they explicitly opt in to this decision. I am not sure the best place to set and pass in this value, so I created [this issue](https://github.com/react-native-community/discussions-and-proposals/issues/113), where it was recommended that I make a PR and discuss how best to do this here. Before this PR could be merged we would need to allow the NO to be configurable in some way.
Additional information about the [allowsCellularAccess](https://developer.apple.com/documentation/foundation/nsurlsessionconfiguration/1409406-allowscellularaccess?language=objc) property can be found in the [Apple documentation.](https://developer.apple.com/library/archive/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/Platform-SpecificNetworkingTechnologies/Platform-SpecificNetworkingTechnologies.html#//apple_ref/doc/uid/TP40010220-CH212-SW9)
[iOS] [Added] - Ability to force network requests to use WiFi using the allowsCellularAccess property. This can ensure that network requests are sent over WiFi if communicating with a local hardware device and is accomplished by setting a flag. Default behavior of allowing network connections over cellular networks when available is unchanged.
Pull Request resolved: https://github.com/facebook/react-native/pull/24242
Differential Revision: D15316760
Pulled By: cpojer
fbshipit-source-id: 96df43b4eff6b4301c853df6b2e5c6e1bb1abda0
Summary:
This is the next step in moving RN towards standard path-based requires. All the requires in `Libraries` have been rewritten to use relative requires with a few exceptions, namely, `vendor` and `Renderer/oss` since those need to be changed upstream. This commit uses relative requires instead of `react-native/...` so that if Facebook were to stop syncing out certain folders and therefore remove code from the react-native package, internal code at Facebook would not need to change.
See the umbrella issue at https://github.com/facebook/react-native/issues/24316 for more detail.
[General] [Changed] - Migrate "Libraries" from Haste to standard path-based requires
Pull Request resolved: https://github.com/facebook/react-native/pull/24749
Differential Revision: D15258017
Pulled By: cpojer
fbshipit-source-id: a1f480ea36c05c659b6f37c8f02f6f9216d5a323
Summary:
@public
Right now when you pass a ph:// video asset, we only ever return the image thumbnail of it. This is useful if you're displaying the ph:// in an <Image> but bad if you're trying to upload it.
This change keeps the original behaviour of displaying a thumbnail in an Image but fixes the latter behaviour, so that ph:// videos are uploaded correctly.
NOTE: There is a terrible hack to accomplish this. It is detailed in the code but essentially, we change the URL scheme to ph-upload:// when trying to upload it so that the default image loader doesn't try to process it.
Reviewed By: JoshuaGross
Differential Revision: D15129454
fbshipit-source-id: 18f87bec18b7cfa5edc1d60a47f23ac5d00675e0
Summary:
`setupDevtools.js` is accessing `AppState.currentState` without checking its availability. In environments where 1) `__DEV__ == true`, and 2) no `RCTAppState` native module is provided thus resorting to `MissingNativeAppStateShim`, this will result in an exception:
```Cannot use 'AppState' module when native 'RCTAppState' is not included in the build. Either include it, or check 'AppState'.isAvailable before calling any methods.```
(Interestingly, `MissingNativeAppStateShim.currentState` did have a [default `null` value](118e88393e (diff-305b5180aa6ccc876ede6767de1fbfc4R192)) that was [later removed](a93b7a2da0 (diff-305b5180aa6ccc876ede6767de1fbfc4R186)).)
**Update**: Following cpojer's suggestion of reverting a93b7a2da0. Title also updated to reflect this.
[General] [Fixed] - Remove MissingNativeRCTNetworkingShim; revert MissingNativeAppStateShim
Pull Request resolved: https://github.com/facebook/react-native/pull/24380
Differential Revision: D14932658
Pulled By: cpojer
fbshipit-source-id: aef7ca566b3b8660eaed74a8ba3b6b0117b1200c
Summary: This diff wires up everything from the previous 8 diffs. After this, all codepaths that execute `modulesConformingToProtocol` in `RCTImageLoader.m` will instead use iOS plugins to retrieve the modules on FBiOS.
Reviewed By: fkgozali
Differential Revision: D14360252
fbshipit-source-id: 6f0cecfa8dffa1955ba2f9ed54bc1c130fb23341
Summary:
This PR implements the first part of [RFC0004: CocoaPods Support Improvements](353d44f649/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects.
The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are:
* `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies.
* The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`.
*Next steps (not in scope of this PR):*
- Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`.
- Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR)
[iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project
Pull Request resolved: https://github.com/facebook/react-native/pull/23559
Differential Revision: D14179326
Pulled By: cpojer
fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
Summary:
Fix crash similar to #22410
react-native: 0.51.0
react: 16.0.0
Changelog:
----------
[iOS] [Changed] - Use onw serial queue to execute invalidate and send request action in RCTHTTPRequestHandler.mm.
Message:
--------
```
- (void)invalidate
{
[_session invalidateAndCancel];
_session = nil;
}
- (NSURLSessionDataTask *)sendRequest:(NSURLRequest *)request
withDelegate:(id<RCTURLRequestDelegate>)delegate
{
// Lazy setup
if (!_session && [self isValid]) {
NSOperationQueue *callbackQueue = [NSOperationQueue new];
callbackQueue.maxConcurrentOperationCount = 1;
callbackQueue.underlyingQueue = [[_bridge networking] methodQueue];
NSURLSessionConfiguration *configuration = [NSURLSessionConfiguration defaultSessionConfiguration];
[configuration setHTTPShouldSetCookies:YES];
[configuration setHTTPCookieAcceptPolicy:NSHTTPCookieAcceptPolicyAlways];
[configuration setHTTPCookieStorage:[NSHTTPCookieStorage sharedHTTPCookieStorage]];
_session = [NSURLSession sessionWithConfiguration:configuration
delegate:self
delegateQueue:callbackQueue];
std::lock_guard<std::mutex> lock(_mutex);
_delegates = [[NSMapTable alloc] initWithKeyOptions:NSPointerFunctionsStrongMemory
valueOptions:NSPointerFunctionsStrongMemory
capacity:0];
}
NSURLSessionDataTask *task = [_session dataTaskWithRequest:request];
{
std::lock_guard<std::mutex> lock(_mutex);
[_delegates setObject:delegate forKey:task];
}
[task resume];
return task;
}
```
now the invalidate function is called by the RCTBridge.invalidate->RCTCxxBridge.invalidate->[moduleData.instance invalidate] , this is on the "com.facebook.react.HTTPRequestHandlerQueue".
the sendRequest:withDelegate function is called by RCTImageLoader and is on the "com.facebook.react.imageLoaderURLRequestQueue".
when one thread step in invalidate and execute [_session invalidateAndCancel] and the another thread step in sendRequest:withDelegate and execute [_session dataTaskWithRequest:request], the _session is invalidate, so there will be a crash "Task created in a session that has been invalidated"
Pull Request resolved: https://github.com/facebook/react-native/pull/22746
Differential Revision: D13781512
Pulled By: cpojer
fbshipit-source-id: bd5fd1edf593e2bcdcc18596a29e906882bac8a4
Summary: This is one more step to remove `fbjs` from `react-native-github`. This changes both the internal and external code to use `invariant` from zertosh instead of the copy in fbjs.
Reviewed By: yungsters
Differential Revision: D13195941
fbshipit-source-id: 73564ca1715110e7da9c7ef56dc57374d61377e0
Summary:
@public
We're seeing a crash on line 191 when we do `CFRelease(self->_firstTimeReachability);`. My thinking is that there's a race condition between the deallocation coming from calling `getCurrentConnectivity` twice in a row and the callback coming back.
Reviewed By: PeteTheHeat
Differential Revision: D12982772
fbshipit-source-id: d3d882a074b67a5e547e7f480f561fcaf8d79ec4
Summary: Removing explicit requires of Map and Set (since those are polyfilled), and fixing resulting flow errors.
Reviewed By: yungsters
Differential Revision: D10350673
fbshipit-source-id: 2fefe8ed1ae1f2cc9e5b7923ad630e73eda9e856
Summary:
@public
If you call NetInfo.getCurrentConnectivity multiple times in succession, we'll create a bunch of callbacks but lose them in the ether.
With this fix, we'll unschedule them before creating a new one, which should resolve some crashes we're seeing.
Reviewed By: PeteTheHeat
Differential Revision: D10409486
fbshipit-source-id: 6065b09fa626f7f06aed9bf0e278c0a6a6169f58
Summary:
@public
We're seeing a crasher where `self` on line 54 isn't an `RCTNetInfo`. The timing looks related to D9798488, so my theory is that this class is being deallocated before it resolves, and thus causes a crash.
Reviewed By: PeteTheHeat
Differential Revision: D10127341
fbshipit-source-id: 94eaba7def6b118092adcf6b4cce841ccc7d0b59
Summary:
Fixes#18223
This is a fairly simple solution to what seems to be a recurring issue where certain requests that result in an empty body where JSON is expected throw an error rather than being handled gracefully. Client side error handling is not being hit as this is being thrown at a lower level.
Make a http request that results in an empty blob: ""
[INTERNAL] [BUGFIX] [XMLHttpRequest.js] - Line 262
Pull Request resolved: https://github.com/facebook/react-native/pull/19567
Differential Revision: D8314416
Pulled By: hramos
fbshipit-source-id: a17c49f3620f0abbb936f3a1c2b01aa1b64820fd
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:
.android.js files may be checked (when the next version of flow is released) by using `flow start --flowconfig-name .flowconfig.android` and `flow status --flowconfig-name .flowconfig.android`
This diff adds suppressions to the errors that are in .android.js files, which flow does not check right now.
When site is `react_native_fb` or `react_native_android_fb`, error will be suppressed when checking with .flowconfig.android
When site is `react_native_fb` or `react_native_ios_fb`, error will be suppressed when checking with .flowconfig.
You can use `react_native_fb` when it should be suppressed for both.
The controller you requested could not be found.
Reviewed By: TheSavior
Differential Revision: D9122178
fbshipit-source-id: 0ec9d3cae3d887f58645e6585b2a3f6c3889b13e
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:
Flow doesn't check .android.js files yet anyway.
I'm going to be adding suppressions in a followup diff. It would be nice to not have >1k suppressions saying that we can't do certain things in `flow strict` when we don't even typecheck with regular `flow` just yet
I ran these commands to produce this diff:
`find . -name '*.android.js' -exec sed -i 's/flow strict-local/flow/g' {} +`
`find . -name '*.android.js' -exec sed -i 's/flow strict/flow/g' {} +`
Followed https://unix.stackexchange.com/questions/112023/how-can-i-replace-a-string-in-a-files to do it.
The controller you requested could not be found.
Reviewed By: TheSavior
Differential Revision: D9143783
fbshipit-source-id: e9af4fe695ebdba4db4083de1697cc248d48eb0d
Summary:
ag -L --ignore __snapshots__ 'flow strict$|noflow|generated|The controller you requested could not be found.' | ag '\.js$' | xargs ag -l 'flow' | sort > ~/temp
cat ~/temp | xargs ag -L 'flow strict' | xargs sed -i '' 's/flow$/flow strict/'
cat ~/temp | xargs ag -L 'flow strict$' | xargs sed -i '' 's/flow strict-local$/flow strict/'
until flow; do flow check --json | jq -r '.errors[].message[0].path' | sort | uniq | xargs hg revert; done
allow_many_files
The controller you requested could not be found.
The controller you requested could not be found.
Reviewed By: yungsters
Differential Revision: D9003523
fbshipit-source-id: d0c9fbfe3c32e65d57819fa040d06cd6ebbd59cc
Summary:
@public
A few people have been complaining, including me, that when we compile a react native project, there are a lot of warnings from xcode, suggesting to update the project build settings to the new recommendations.
I took the liberty to actually update the xcode projects, so we can finally have these gone, as well as replace some deprecated methods with the new suggested ones.
[IOS] [MINOR] [Xcode] - updated the Xcode projects with the latest suggestions from Xcode 9.3, and replaced a few deprecated methods of iOS with their new replacements.
Closes https://github.com/facebook/react-native/pull/19574
Reviewed By: shergin
Differential Revision: D8530135
Pulled By: hramos
fbshipit-source-id: b9c9ede0e07760cb2207caa6b468bd5c241848dc
Summary:
A few people have been complaining, including me, that when we compile a react native project, there are a lot of warnings from xcode, suggesting to update the project build settings to the new recommendations.
I took the liberty to actually update the xcode projects, so we can finally have these gone, as well as replace some deprecated methods with the new suggested ones.
I made two react native projects, one with the regular react native and the other one using this branch.
Left is before, right is after:
[IOS] [MINOR] [Xcode] - updated the Xcode projects with the latest suggestions from Xcode 9.3, and replaced a few deprecated methods of iOS with their new replacements.
Closes https://github.com/facebook/react-native/pull/19574
Differential Revision: D8489006
Pulled By: hramos
fbshipit-source-id: 2922b2e76aca6883c4f5d04e9c511b9fc1029583
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:
This PR fixes a bug where in `RCTNetworking` not all tasks/handlers were not being cleared when invalidating the class.
I came across this issue when writing some unit tests for my native plugins, sometimes a test would finish running (and the bridge invalidated), and only afterwards a callback from RCTNetworking would come, resulting in this exception:
```
2018-05-07 15:23:34.264494-0700 Guardian[73794:10710945] *** Assertion failure in -[RCTEventEmitter sendEventWithName:body:](), /Users/.../app/node_modules/react-native/React/Modules/RCTEventEmitter.m:41
2018-05-07 15:23:34.276505-0700 Guardian[73794:10710945] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error when sending event: didCompleteNetworkResponse with body: (
2,
cancelled,
0
). Bridge is not set. This is probably because you've explicitly synthesized the bridge in RCTNetworking, even though it's inherited from RCTEventEmitter.'
*** First throw call stack:
(
0 CoreFoundation 0x000000010d5b21e6 __exceptionPreprocess + 294
1 libobjc.A.dylib 0x000000010be6f031 objc_exception_throw + 48
2 CoreFoundation 0x000000010d5b7472 +[NSException raise:format:arguments:] + 98
3 Foundation 0x000000010b94864f -[NSAssertionHandler handleFailureInFunction:file:lineNumber:description:] + 165
4 Guardian 0x0000000106ff5227 -[RCTEventEmitter sendEventWithName:body:] + 567
5 Guardian 0x0000000106e9ebab __76-[RCTNetworking sendRequest:responseType:incrementalUpdates:responseSender:]_block_invoke.423 + 1115
6 Guardian 0x0000000106e8f48c __50-[RCTNetworkTask URLRequest:didCompleteWithError:]_block_invoke + 92
7 Guardian 0x0000000106e8ded1 -[RCTNetworkTask dispatchCallback:] + 113
8 Guardian 0x0000000106e8f37a -[RCTNetworkTask URLRequest:didCompleteWithError:] + 410
9 Guardian 0x0000000106ea1aa3 -[RCTHTTPRequestHandler URLSession:task:didCompleteWithError:] + 403
10 CFNetwork 0x000000010cf3a437 __51-[NSURLSession delegate_task:didCompleteWithError:]_block_invoke.207 + 80
11 Foundation 0x000000010b885363 __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 7
12 Foundation 0x000000010b8851ca -[NSBlockOperation main] + 68
13 Foundation 0x000000010b8836b2 -[__NSOperationInternal _start:] + 766
14 libdispatch.dylib 0x0000000112457779 _dispatch_client_callout + 8
15 libdispatch.dylib 0x000000011245c931 _dispatch_block_invoke_direct + 317
16 libdispatch.dylib 0x0000000112457779 _dispatch_client_callout + 8
17 libdispatch.dylib 0x000000011245c931 _dispatch_block_invoke_direct + 317
18 libdispatch.dylib 0x000000011245c7d4 dispatch_block_perform + 109
19 Foundation 0x000000010b87f75b __NSOQSchedule_f + 337
20 libdispatch.dylib 0x0000000112457779 _dispatch_client_callout + 8
21 libdispatch.dylib 0x000000011245f1b2 _dispatch_queue_serial_drain + 735
22 libdispatch.dylib 0x000000011245f9af _dispatch_queue_invoke + 321
23 libdispatch.dylib 0x0000000112461cf8 _dispatch_root_queue_drain + 473
24 libdispatch.dylib 0x0000000112461ac1 _dispatch_worker_thread3 + 119
25 libsystem_pthread.dylib 0x000000011297a169 _pthread_wqthread + 1387
26 libsystem_pthread.dylib 0x0000000112979be9 start_wqthread + 13
)
libc++abi.dylib: terminating with uncaught exception of type NSException
```
Bug can be reproduced by making a `XMLHttpRequest` (uses `RCTNetworking` internally) that takes a couple seconds to perform, and issuing a RCTBridge reload command in the meantime.
You can add the following code to the react-native template project,
```
componentDidMount() {
var oReq = new XMLHttpRequest();
oReq.addEventListener("load", () => console.log('Finished'));
oReq.open("GET", "https://www.dropbox.com/s/o01hz0chqvjafhv/file.bin?dl=1");
oReq.send();
console.log('Request is being performed...')
}
```
In my case I download a 1MB file.
Run the project and reload the a couple times. Bug is triggered.
[INTERNAL] [BUGFIX] [RCTNetworking] - Clear handlers and tasks on RCTNetworking invalidation
Closes https://github.com/facebook/react-native/pull/19169
Differential Revision: D8053070
Pulled By: hramos
fbshipit-source-id: d8af54fecd99173905363f962ffc638ef8b85082
Summary:
This PR removes the need for having the `providesModule` tags in all the modules in the repository.
It configures Flow, Jest and Metro to get the module names from the filenames (`Libraries/Animated/src/nodes/AnimatedInterpolation.js` => `AnimatedInterpolation`)
* Checked the Flow configuration by running flow on the project root (no errors):
```
yarn flow
```
* Checked the Jest configuration by running the tests with a clean cache:
```
yarn jest --clearCache && yarn test
```
* Checked the Metro configuration by starting the server with a clean cache and requesting some bundles:
```
yarn run start --reset-cache
curl 'localhost:8081/IntegrationTests/AccessibilityManagerTest.bundle?platform=android'
curl 'localhost:8081/Libraries/Alert/Alert.bundle?platform=ios'
```
[INTERNAL] [FEATURE] [All] - Removed providesModule from all modules and configured tools.
Closes https://github.com/facebook/react-native/pull/18995
Reviewed By: mjesun
Differential Revision: D7729509
Pulled By: rubennorte
fbshipit-source-id: 892f760a05ce1fddb088ff0cd2e97e521fb8e825
Summary:
We currently handle empty body poorly in the iOS blob implementation, this happens because of an early return that cause the blob response to not be processed by the blob module, resulting in an empty string as the body instead of a blob object. We also need to make sure to create an empty blob object when data is nil (empty body) as per the XMLHttpRequest spec. The Android implementation was already handling this properly.
Fixes#18223
Send a HEAD request
```js
fetch('https://apipre.monkimun.com/whoami', {
body: null,
method: 'HEAD',
headers: {
Accept: 'application/json',
'Content-Type': 'application/json',
},
})
```
[IOS][BUGFIX][Blob] - Fix blob response parsing for empty body
Closes https://github.com/facebook/react-native/pull/18547
Differential Revision: D7415950
Pulled By: hramos
fbshipit-source-id: 56860532c6171255869f02a0960f55d155184a46
Summary: The pull request that added this (#17397) simply forgot to remove the callback, which would cause crashes if the RCTNetInfo module was ever deallocated. While that usually doesn't happen in apps, it can if the user logs out and you need to wipe all the RCT modules (to remove user data, for instance).
Reviewed By: PeteTheHeat
Differential Revision: D7322999
fbshipit-source-id: e49ec7311b39920f7b7743a5854c0dda1dbccc73
Summary:
This is fixing #8615. The problem was that, on initialization, the `_connectionType` variable was still set to its default value of `RCTConnectionTypeUnknown`. The exposed API method did nothing to determine this unless a subscription had be established and then the method would simply return the last reported value. Instead, the exposed oneshot API call now actually checks the connection status through the same methods as the subscription and updates RCTNetInfo’s values before returning.
In order to avoid reporting events without a subscription, a flag is set and unset on calls to start/stopObserving.
- start app
- observe the (in)correct reporting of the manual status
- change network status to offline
- press refresh
- observe the manual fetch
- start subscription
- change network status to online
- press refresh to show that the manual refresh works (only now working for current RN version)
- change network status to offline
- stop subscription
- change network status to online
- press refresh to show manual refresh does(n't) work without subscription
- start subscription to show it updates to current
Current Behavior: https://drive.google.com/file/d/1Ods6HORgp_vfm1mQVjGwhtH1D7issxjo/view?usp=sharing
Fixed Behavior: https://drive.google.com/file/d/11H1UOF33LeMGvXEOoapU62ARDSb7qoYv/view?usp=sharing
[IOS] [BUGFIX] [Libraries\Network\RCTNetInfo.m] - Fixed#8615, `iOS: NetInfo.isConnected returns always false`, by decoupling the fetch from the status of the subscription.
Closes https://github.com/facebook/react-native/pull/17397
Differential Revision: D7102771
Pulled By: hramos
fbshipit-source-id: ea11eb0b1a7ca641fc43da2fe172cf7b2597de4a
Summary:
Hi! I would like to contribute to React Native, and I am just starting out. I forked the repo and found that it has quite a lot of ESLint warnings – many of which were automatically fixable. This PR is simply the result of running `yarn lint --fix` from the root folder.
Most changes are removing trailing spaces from comments.
Haven't really done any manual testing, since I haven't done any code changes manually. `yarn test` runs fine, `yarn flow` runs fine, `yarn prettier` is satisfied.
N/A
[INTERNAL][MINOR][] - Fix ESLint warnings
Closes https://github.com/facebook/react-native/pull/18047
Differential Revision: D7054948
Pulled By: hramos
fbshipit-source-id: d53e692698d1687de5821c3fb5cdb76a5e03b71e
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 PR is a followup to https://github.com/facebook/react-native/pull/11417 and should be merged after that one is merged.
1. Add support for creating blobs from strings, not just other blobs
1. Add the `File` constructor which is a superset of `Blob`
1. Add the `FileReader` API which can be used to read blobs as strings or data url (base64)
1. Add support for uploading and downloading blobs via `XMLHttpRequest` and `fetch`
1. Add ability to download local files on Android so you can do `fetch(uri).then(res => res.blob())` to get a blob for a local file (iOS already supported this)
1. Clone the repo https://github.com/expo/react-native-blob-test
1. Change the `package.json` and update `react-native` dependency to point to this branch, then run `npm install`
1. Run the `server.js` file with `node server.js`
1. Open the `index.common.js` file and replace `localhost` with your computer's IP address
1. Start the packager with `yarn start` and run the app on your device
If everything went well, all tests should pass, and you should see a screen like this:
!
Pull to rerun all tests or tap on specific test to re-run it
[GENERAL] [FEATURE] [Blob] - Implement blob support for XMLHttpRequest
Closes https://github.com/facebook/react-native/pull/11573
Reviewed By: shergin
Differential Revision: D6082054
Pulled By: hramos
fbshipit-source-id: cc9c174fdefdfaf6e5d9fd7b300120a01a50e8c1
Summary:
It's currently possible to crash React Native on iOS when using XMLHTTPRequest with onreadystatechange by having the server send a bunch of bad unicode (we found the problem when a bad deploy caused this to happen).
This is due to an integer overflow when handling carryover data in decodeTextData.
Create Express server with mock endpoint:
```js
var express = require('express');
var app = express();
app.get('/', function(req, res) {
res.writeHead(200, {'content-type': 'text/plain; charset=utf-8'});
res.flushHeaders();
res.write(new Buffer(Array(4097).join(0x48).concat(0xC2)));
res.write(new Buffer([0xA9]));
res.end();
});
app.listen(3000);
```
Create React Native application which tries to hit the endpoint:
```js
export default class App extends Component<{}> {
componentDidMount() {
const xhr = new XMLHttpRequest()
xhr.open('get', 'http://localhost:3000', true);
xhr.onreadystatechange = function () {
if(xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
console.warn(xhr.responseText);
}
};
xhr.send();
}
render() {
return null;
}
}
```
Observe that the application crashes when running master and doesn't when including the changes from this pull request.
[IOS] [BUGFIX] [RCTNetworking] - |Check against integer overflow when parsing response|
Closes https://github.com/facebook/react-native/pull/16286
Differential Revision: D6060975
Pulled By: hramos
fbshipit-source-id: 650e401a3bc033725078ea064f8fbca5441f9db5
Summary:
The first code block already uses the new `connectionChange` event instead of
the deprecated `change` event, so change this example code block as well to use
the new event.
I came across this while upgrading my RN version. In the debug-console I saw a deprecation warning, despite I was using the example-code. Looking at the source, I saw the example code block still used the deprecated event, so update it to use the new one.
Closes https://github.com/facebook/react-native/pull/16357
Differential Revision: D6054428
Pulled By: hramos
fbshipit-source-id: 72ef1a79ece7494cda3773461a740dbbdf383e7e
Summary:
Hi React Native folks! Love your work!
To make contributing easier, this sets the indentation settings of all the Xcode projects to 2 spaces to match their contents.
Closes https://github.com/facebook/react-native/pull/15275
Differential Revision: D5526462
Pulled By: javache
fbshipit-source-id: cbf0a8a87a1dbe31fceed2f0fffc53839cc06e59
Summary:
This change intends to fix 2 issues with the NetInfo API:
- The NetInfo API is currently platform-specific. It returns completely different values on iOS and Android.
- The NetInfo API currently doesn't expose a way to determine whether the connection is 2g, 3g, or 4g.
The NetInfo API currently just exposes a string-based enum representing the connectivity type. The string values are different between iOS and Andorid. Because of this design, it's not obvious how to achieve the goals of this change without making a breaking change. Consequently, this change deprecates the old NetInfo APIs and introduces new ones. Specifically, these are the API changes:
- The `fetch` method is deprecated in favor of `getConnection`
- The `change` event is deprecated in favor of the `connectionchange` event.
- `getConnection`/`connectionchange` use a new set of enum values compared to `fetch`/`change`. See the documentation for the new values.
- On iOS, `cell` is now known as `cellular`. It's worth pointing out this one in particular because the old and new names are so similar. The rest of the iOS values have remained the same.
- Some of the Android enum values have been removed without a replacement (e.g. `DUMMY`, `MOBILE_DUN`, `MOBILE_HIPRI`, `MOBILE_MMS`, `MOBILE_SUPL`, `VPN`). If desirable, we could find a way to expose these in the new API. For example, we could have a `platformValue` key that exposes the platform's enum values directly (like the old `fetch` API did).
`getConnection` and `connectionchange` each expose an object which has 2 keys conveying a `ConnectionType` (e.g. wifi, cellular) and an `EffectiveConnectionType` (e.g. 2g, 3g). These enums and their values are taken directly from the W3C's Network Information API spec (https://wicg.github.io/netinfo/). Copying the W3C's API will make it easy to expose a `navigation.connection` polyfill, if we want, in the future. Additionally, because the new APIs expose an object instead of a string, it's easier to extend the APIs in the future by adding keys to the object without causing a breaking change.
Note that the W3C's spec doesn't have an "unknown" value for `EffectiveConnectionType`. I chose to introduce this non-standard value because it's possible for the current implementation to not have an `effectiveConnectionType` and I figured it was worth representing this possibility explicitly with "unknown" instead of implicitly with `null`.
**Test Plan (required)**
Verified that the methods (`fetch` and `getConnection`) and the events (`change` and `connectionchange`) return the correct data on iOS and Android when connected to a wifi network and a 4G cellular network. Verified that switching networks causes the event to fire with the correct information. Verified that the old APIs (`fetch' and 'change') emit a deprecation warning when used. My team is using a similar patch in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/14618
Differential Revision: D5459593
Pulled By: shergin
fbshipit-source-id: f1e6c5d572bb3e2669fbd4ba7d0fbb106525280e
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.
`Promise.done` is non-standard, `Promise.then` is preferred as a standardized method. On Android, polyfill filling in `Promise.done` has been most probably taken out in newer versions of `react-native` and app crashes when it tries to query network state through `NetInfo`.
No tests are required for this change.
Closes https://github.com/facebook/react-native/pull/13489
Differential Revision: D4897566
Pulled By: mkonicek
fbshipit-source-id: 140720d7367cd1d9bf8924ec8a118c1bff4e461d
Summary:
Corresponding iOS PR: #12275
Respect the withCredentials XMLHttpRequest flag for sending cookies with requests. This can reduce payload sizes where large cookies are set for domains.
This should fix#5347.
This is a breaking change because it alters the default behavior of XHR. Prior to this change, XHR would send cookies by default. After this change, by default, XHR does not send cookies which is consistent with the default behavior of XHR on web for cross-site requests. Developers can restore the previous behavior by passing `true` for XHR's `withCredentials` argument.
**Test plan (required)**
Verified in a test app that XHR works properly when specifying `withCredentials` as `true`, `false`, and `undefined`. Also, my team uses this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/12276
Differential Revision: D4673646
Pulled By: ericvicenti
fbshipit-source-id: 924c230c9df72071b3cf9151c3ac201905ac28a5
Summary:
This is enforced for all of our internal iOS code and a common cause of import failures.
cc janicduplessis
Closes https://github.com/facebook/react-native/pull/13124
Differential Revision: D4765016
fbshipit-source-id: 7c8248c98bca0fa6bad24d5a52b666243375e0db
Summary:
Corresponding Android PR: #12276
Respect the withCredentials XMLHttpRequest flag for sending cookies with requests. This can reduce payload sizes where large cookies are set for domains.
This should fix#5347.
This is a breaking change because it alters the default behavior of XHR. Prior to this change, XHR would send cookies by default. After this change, by default, XHR does not send cookies which is consistent with the default behavior of XHR on web for cross-site requests. Developers can restore the previous behavior by passing `true` for XHR's `withCredentials` argument.
**Test plan (required)**
Verified in a test app that XHR works properly when specifying `withCredentials` as `true`, `false`, and `undefined`. Also, my team uses this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/12275
Differential Revision: D4673644
Pulled By: mkonicek
fbshipit-source-id: 2fd8f536d02fb39d872eb849584c5c4f7e7698c5
Summary:
04d870b added support for onabort in XHRs. The other on* events are declared on XMLHttpRequest and XMLHttpRequestEventTarget. This adds onabort there as well.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/12277
Differential Revision: D4673648
Pulled By: mkonicek
fbshipit-source-id: 0c5255da77537103c5ad91d9b2826d064140708d
Summary:
Largely typing fixes to deal with the glut of new `FlowFixMe` suppressions introduced with flow 0.38 in a4bfac907e
Tested with flow itself. CC gabelevi
Closes https://github.com/facebook/react-native/pull/11985
Differential Revision: D4452045
Pulled By: ericvicenti
fbshipit-source-id: acc46c4c406ae706a679e396be1d40ae2f4ce5a1
Summary:
Support `xhr.send(data)` for typed arrays.
**Test plan:** run UIExplorer example on iOS and Android.
Closes https://github.com/facebook/react-native/pull/11904
Differential Revision: D4425551
fbshipit-source-id: 065ab5873407a406ca4a831068ab138606c3361b
Kevin Gozali
George Zahariev
Ramanpreet Nara
Tim Yung
Emily Janzer
Andres Suarez
Mehdi Mulani
Christoph Nakazawa
Logan Daniels
James Treanor
Michał Osadnik
Radosław Pietruszewski
Arthur Lee
zhongwuzw
Janic Duplessis
Tom Sanderson
James Ide
Michał Pierzchała
Parker Bond
Dmitry Dushkin
Brian Zhao
Ville Immonen
Rafael Lincoln
SHANKS
Nat Mote
Tnarita0000
Olivier Corradi
nd-02110114
anthony
Karan Thakkar
Héctor Ramos
Jordan Brown
Steven Cable
Wayne Cheng
Pavlos Vinieratos
Jose Pereira
Eli White
Rubén Norte
Peter van der Zee
Adam Burdette
Mats Byrkeland
Sophie Alpert
Satyajit Sahoo
Yujie Liu
Chris Lewis
Miguel Jimenez Esun
Willem Fibbe
Marshall Roch
Adlai Holler
Jiajie Zhu
Adam Comella
Kathy Gray
James Burnett
Alex Dvornikov
Daniel Zlotin
Seraj Ahmad
Jakub Šimo
Pieter De Baets
Pieter De Baets
Matthew Oaxaca
rh389
Philipp von Weitershausen
Gabe Levi
