Summary:
In preparation for Blob support (wherein binary XHR and WebSocket responses can be retained as native data blobs on the native side and JS receives a web-like opaque Blob object), this change makes RCTNetworking aware of the responseType that JS requests. A `xhr.responseType` of `''` or `'text'` translates to a native response type of `'text'`. A `xhr.responseType` of `arraybuffer` translates to a native response type of `base64`, as we currently lack an API to transmit TypedArrays directly to JS. This is analogous to how the WebSocket module already works, and it's a lot more versatile and much less brittle than converting a JS *string* back to a TypedArray, which is what's currently going on.
Now that we don't always send text down to JS, JS consumers might still want to get progress updates about a binary download. This is what the `'progress'` event is designed for, so this change also implements that. This change also follows the XHR spec with regards to `xhr.response` and `xhr.responseText`:
- if the response type is `'text'`, `xhr.responseText` can be peeked at by the JS consumer. It will be updated periodically as the download progresses, so long as there's either an `onreadystatechange` or `onprogress` handler on the XHR.
- if the response type is not `'text'`, `xhr.responseText` can't be accessed and `xhr.response` remains `null` until the response is fully received. `'progress'` events containing response details (total bytes, downloaded so far) are dispatched if there's an `onprogress` handler.
Once Blobs are landed, `xhr.responseType` of `'blob'` will correspond to the same native response type, which will cause RCTNetworking to only send a blob ID down to JS, which can then create a `Blob` object from that for consumers.
Closes https://github.com/facebook/react-native/pull/8324
Reviewed By: javache
Differential Revision: D3508822
Pulled By: davidaurelio
fbshipit-source-id: 441b2d4d40265b6036559c3ccb9fa962999fa5df
Summary:
Under rare and as-yet-to-be determined circumstances, images can sometimes fail to load/download and get "stuck", without producing an error.
Because the `RCTNetworkTask` for these images is stuck in the "in progress" state, they clog up the RCTImageLoader task queue, which has a limit of 4 concurrent in-progress tasks.
This was previously masked by the fact that we automatically cancelled image requests when the RCTImageView moved offscreen, but we no longer do that.
This diff adds logic to detect some types of stuck task and remove them, thereby unblocking the queue. I've also restored the functionality of cancelling downloads for offscreen images (but not unloading the image itself) so that stuck images will be cancelled when you move to another screen, instead of using up space in the queue forever.
Reviewed By: fkgozali
Differential Revision: D3398105
fbshipit-source-id: 75ee40d06a872ae8e1cb57f02f9cad57c459143c
Summary:
Accessing the `responseText` property when `responseType` is not `''` or `'text'` should throw. Also, the property is read-only.
**Test Plan:** UIExplorer example, unit tests
Closes https://github.com/facebook/react-native/pull/7284
Differential Revision: D3366893
fbshipit-source-id: a4cf5ebabcd1e03d6e2dc9d51230982922746c11
Summary:
XMLHttpRequest was sending the request before registering any listeners, resulting in a warning from the native event emitter.
Since we weren't seeing widespread problems with XHR missing data, this was probably working OK in practice because the queuing of events meant that the listener would have been registered before the message was actually delivered.
Still, this was working more through luck than design. This diff fixes it by registering the listeners *before* sending the request.
Reviewed By: lexs
Differential Revision: D3371320
fbshipit-source-id: c688d4053a61f856eaacccd0106905edbefcc86a
Summary: Updated networking and geolocation to use the new events system.
Reviewed By: bestander
Differential Revision: D3346129
fbshipit-source-id: 957716e54d7af8c4a6783f684098e92e92f19654
Summary: Updated networking and geolocation to use the new events system.
Reviewed By: javache
Differential Revision: D3339945
fbshipit-source-id: 01d307cf8a0aea3a404c87c6205132c42290abb1
Summary: Updated networking and geolocation to use the new events system.
Reviewed By: javache
Differential Revision: D3339945
fbshipit-source-id: f1332fb2aab8560e4783739e223c1f31d583cfcf
Summary: AppState now subclasses NativeEventEmitter instead of using global RCTDeviceEventEmitter.
Reviewed By: javache
Differential Revision: D3310488
fbshipit-source-id: f0116599223f4411307385c0dab683659d8d63b6
Summary:
Further describe the methods available on NetInfo.
Question: How do I update the docs on the website?
Closes https://github.com/facebook/react-native/pull/7375
Differential Revision: D3303300
fbshipit-source-id: 4343d490f65e4e47b93f2c98a645cb675d2cf708
Summary:
The XMLHttpRequest jest tests were attempting to call a private method in XMLHttpRequestBase.js (denoted by an _ prefix).
JS doesn't actually have any language-level support for private methods, the use of _ prefix is just a convention. But to prevent casually calling private methods externally, we have a transform that mangles the names of prefixed methods so that that attempting to call them will fail.
Using a double _ bypasses this name-mangling mechanism, while still making it clear that the method is intended to be private.
Reviewed By: javache
Differential Revision: D3276261
fb-gh-sync-id: e0c17e1003d2df09d1a16f78ae9d95bef923d74e
fbshipit-source-id: e0c17e1003d2df09d1a16f78ae9d95bef923d74e
Summary:
NSMutableURLRequest appears to be running `[headerValue count]` on every value of the NSDictionary that `allHTTPHeaderFields` is set to, meaning that any `null` values passed to headers in an XHR throw an exception. This differs from the implementation of XHR in browsers, which just ignore any `null` values for headers.
PR doesn't currently include tests, happy to add those if this is something you'd consider merging
Closes https://github.com/facebook/react-native/pull/6903
Differential Revision: D3256727
fb-gh-sync-id: 58e8db9c86a1fe7fbd95cba7dcf916957d179e0c
fbshipit-source-id: 58e8db9c86a1fe7fbd95cba7dcf916957d179e0c
Summary:
So far, XHR only supports a few `onfoo` event handlers, not the entier `EventTarget` interface (`addEventListener`, `removeEventListener`). It also doesn't support the `upload` object on Android -- for no good reason. Even if we don't send any events there yet, there's no reason we have to break consuming code that wants to register an event handler there. This PR rectifies all that.
Fortunately, adding proper `EventTarget` support is very easy thanks to `event-target-shim`. We already use it in our WebSocket implementation. It transparently handles the `addEventListener('foo', ...)` as well as `onfoo` APIs, so when you dispatch an event on the event target, the right handlers will be invoked. The event object is wrapped so that `event.target` is set properly. Basically, it's a super easy way to make us conform to the spec.
Also added a bit of polish here and there, using ES2015 class property goodness to consolidate a lot of Flow property definitions with the corresponding property initializers.
**T
Closes https://github.com/facebook/react-native/pull/7017
Reviewed By: fkgozali
Differential Revision: D3202021
Pulled By: martinbigio
fb-gh-sync-id: 2b007682074356c75c774fab337672918b6c4355
fbshipit-source-id: 2b007682074356c75c774fab337672918b6c4355
Summary:Currently React-Native does not have `ontimeout` and `onerror` handlers for [XMLHttpRequest](https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest). This is an extension to [No timeout on XMLHttpRequest](https://github.com/facebook/react-native/issues/4648).
With addition to two handlers, both Android and iOS can now handle `ontimeout` if request times out and `onerror` when there is general network error.
**Test plan**
Code has been tested on both Android and iOS with [Charles](https://www.charlesproxy.com/) by setting a breakpoint on the request which fires `ontimeout` when the request waits beyond `timeout` time and `onerror` when there is network error.
**Usage**
JavaScript -
```
var request = new XMLHttpRequest();
function onLoad() {
console.log(request.status);
};
function onTimeout() {
console.log('Timeout');
};
function onError() {
console.log('General network error');
};
request.onload = onLoad;
request.ontimeout = onTimeout;
request.onerr
Closes https://github.com/facebook/react-native/pull/6841
Differential Revision: D3178859
Pulled By: lexs
fb-gh-sync-id: 30674570653e92ab5f7e74bd925dd5640fc862b6
fbshipit-source-id: 30674570653e92ab5f7e74bd925dd5640fc862b6
Summary:This prevents possible developer errors when using 'post' or 'put' instead of 'POST' and 'PUT'.
Fixes: https://github.com/facebook/react-native/issues/6855
**Test plan:**
Previously, a `method put must not have a request body` error would be thrown when the method was in lowercase and a request body was indeed included.
With this fix and the following code (note the method name in all lowercase), the request is properly completed.
```javascript
const url = 'http://myurl.com';
const request = new XMLHttpRequest();
request.open('put', url);
request.setRequestHeader("Content-type","application/json");
request.onload = function() {
console.log('onload');
};
request.onerror = function() {
console.log('error');
};
request.send(JSON.stringify({ something: 'here' }));
```
Closes https://github.com/facebook/react-native/pull/6956
Differential Revision: D3173467
Pulled By: davidaurelio
fb-gh-sync-id: add90e9f31cd4f548547a3f85267a782ae74a89c
fbshipit-source-id: add90e9f31cd4f548547a3f85267a782ae74a89c
Summary:Fixes #6679
This adds support for the missing response types to XMLHttpRequest.
Don?t ship this yet. This is completely untested. yolo and stuff.
Closes https://github.com/facebook/react-native/pull/6870
Reviewed By: bestander
Differential Revision: D3153628
Pulled By: davidaurelio
fb-gh-sync-id: 76feae3377bc24b931548a9ac1af07943b1048ac
fbshipit-source-id: 76feae3377bc24b931548a9ac1af07943b1048ac
Summary:After adding support for `XMLHttpRequest#response`, the `fetch` polyfill detects buffer support when debugging in Chrome and sets `responseType` to `'blob'`.
In that case, the response was always empty.
This change will construct a blob if `responseType` has been set to `'blob'` in order to avoid that problem
Reviewed By: steveluscher
Differential Revision: D3018884
fb-gh-sync-id: 4ade0413de67242c3565d95c2880d4a981ba2342
shipit-source-id: 4ade0413de67242c3565d95c2880d4a981ba2342
Summary:Initializing native modules can block the main thread for tens of milliseconds when it starts up, making it difficult to instantiate the bridge on demand without causing a performance blip.
This diff splits up the initialization of modules so that - although they still happen on the main thread - they don't block the thread continuously.
Reviewed By: javache
Differential Revision: D2965438
fb-gh-sync-id: 38c9c9d281e4672b5874d68b57d4c60d1d268344
shipit-source-id: 38c9c9d281e4672b5874d68b57d4c60d1d268344
Summary:The ArrayBuffer support added in https://github.com/facebook/react-native/pull/6156 crashed on iOS7 as Uint8Array is unavailable.
This diff removes that feature. We can revisit it again once we drop support for iOS 7.
Reviewed By: javache
Differential Revision: D2999762
fb-gh-sync-id: b497eac92ca5a0865b308d2a08c9409fcce97156
shipit-source-id: b497eac92ca5a0865b308d2a08c9409fcce97156
Summary:Currently the XMLHttpRequest don't support any response types other than text. This PR will add responseType attribute as well response attribute.
This PR will partially solve the issue https://github.com/facebook/react-native/issues/6017
Closes https://github.com/facebook/react-native/pull/6156
Differential Revision: D2994267
Pulled By: nicklockwood
fb-gh-sync-id: 24642c48655930c8350112bac38e6ed4a42bd40d
shipit-source-id: 24642c48655930c8350112bac38e6ed4a42bd40d
Summary:
Introduced in a major lazy loading refactoring: 060664fd3d.
This is especially an issue when aborting a long-lived HTTP connection used as a notification channel, as it will use 1 of the maximum 4 connections per host (default limit defined by iOS' NSURLSession).
Closes https://github.com/facebook/react-native/pull/5782
Reviewed By: svcscm
Differential Revision: D2907600
Pulled By: nicklockwood
fb-gh-sync-id: 8406a045904a7ddb61fe1539a0474ec27b5e9e37
Summary:
Opening this in a separate PR but the discussion can be viewed on #4832.
Basically, this is a native implementation and is a bit more elegant. The consensus on my previous PR was that it should be done natively rather than in JS.
There's now no maximum valid timeout value and a timeout of 0 will never time out.
ontimeout isn't implemented (yet) in this PR.
cc nicklockwood ide philikon
Closes https://github.com/facebook/react-native/pull/5038
Reviewed By: svcscm
Differential Revision: D2838743
Pulled By: nicklockwood
fb-gh-sync-id: 774f864ac35082bf522f7665f4311bd3affbe82c
Summary:
An HTTP request may be redirected to another URL, sometimes we need to know the URL where the response comes from.
If the server is in control, we can add an HTTP header X-Request-URL for the redirect URL. However there will be cases that 3rd party services are used.
This PR retrieves the response URL from native networking module and passes to it XMLHttpRequest. The fetch API built on XMLHttpRequest also benefits from this feature.
Closes https://github.com/facebook/react-native/pull/4981
Reviewed By: svcscm
Differential Revision: D2811392
Pulled By: lexs
fb-gh-sync-id: 3ec356fb92f8011b6a243d6879172877a3dc498a
Summary:
public
Attempting to load an undefined URL via XMLHttpRequest produced a confusing error deep within the network layer. This diff improves the networking stack to catch such errors earlier, and also adds a helpful error in the JS layer.
Fixes https://github.com/facebook/react-native/issues/4558
Reviewed By: javache
Differential Revision: D2811080
fb-gh-sync-id: 1837427e1080a0308f2c4f9a8a42bce2e041fb48
Summary:
public
This diff replaces the RegEx module method parser with a handwritten recursive descent parser that's faster and easier to maintain.
The new parser is ~8 times faster when tested on the UIManager.managerChildren() method, and uses ~1/10 as much RAM.
The new parser also supports lightweight generics, and is more tolerant of white space.
(This means that you now can – and should – use types like `NSArray<NSString *> *` for your exported properties and method arguments, instead of `NSStringArray`).
Reviewed By: jspahrsummers
Differential Revision: D2736636
fb-gh-sync-id: f6a11431935fa8acc8ac36f3471032ec9a1c8490
Summary:
public
When uploading images, RCTHTTPFormDataHelper was sometimes accessed on the wrong thread.
Reviewed By: helouree
Differential Revision: D2709186
fb-gh-sync-id: d0a14926927d1d41f602f78a9f6892dfbdfc6ff9
David Aurelio
Philipp von Weitershausen
Spencer Ahrens
Skotch Vail
Jeff Morrison
Nick Lockwood
Philipp von Weitershausen
Basil Hosmer
Konstantin Raev
Yao Bin Then
Griffin Smith
Christoph Pojer
grgmo
Dave Sibiski
Aleksei Androsov
Laurence Bortfeld
Sreejumon
Satyajit Sahoo
Lasse Bang Mikkelsen
Connor McEwen
Alex Roman
Aleksei Androsov
Oleg Lokhvitsky
realaboo
Gabe Levi
Martin Konicek
Nathan Spaun
Huang Yu