Commit Graph

13 Commits

Author SHA1 Message Date
Jeff Morrison bd3be5bd24 Update fbsource
Reviewed By: zertosh

Differential Revision: D4111832

fbshipit-source-id: 301969a1c828fb87e7e09c1eea3cd44799b89509
2016-11-08 12:43:48 -08:00
Alexander Blom 1709043a12 Add Network agent
Summary: Adds methods in XMLHttpRequest so that the agent can hook the events needed for the implementation, these are only enabled if the agent is enabled (which means that the inspector is connected), it is also stripped out in non-dev currently.

Reviewed By: davidaurelio

Differential Revision: D4021516

fbshipit-source-id: c0c00d588404012d20b744de74e5ecbe5c002a53
2016-11-02 12:29:15 -07:00
leeight f9e36a08a8 Make sure xhr req header's value is String type
Summary:
In the `NetworkingModule.java`, `header.getString(1)` was
called, so the value must be String type.

FIX #10198
Closes https://github.com/facebook/react-native/pull/10222

Differential Revision: D4080319

Pulled By: lacker

fbshipit-source-id: 85234a2bbf90e5b9e0e65ceadbfabb330b2d1322
2016-10-25 22:29:35 -07:00
Erik Arvidsson 24c72f513e XMLHttpRequest.getAllResponseHeaders should use CRLF
Summary:
XMLHttpRequest.prototype.getAllResponseHeaders was previously joining
the headers with `\n`. The spec at:

https://xhr.spec.whatwg.org/#the-getallresponseheaders()-method

step 3.2, requires the headers to be joined using `\r\n`.
Closes https://github.com/facebook/react-native/pull/10034

Differential Revision: D3917020

fbshipit-source-id: f4e920f6bebacc3aa5c52c84348157d2b530480f
2016-09-23 16:28:56 -07:00
Erik Arvidsson 04d870b10b XMLHttpRequest should dispatch loadend events
Summary:
The code was never dispatching the loadend event. The event should be
dispatched after the load, error, timeout and abort events (abort
events are not yet supported).

https://xhr.spec.whatwg.org/#event-xhr-loadend
Closes https://github.com/facebook/react-native/pull/10047

Differential Revision: D3911080

fbshipit-source-id: 450f50a6f2a5c6845889bce624c64a1ca47ec06b
2016-09-22 17:13:46 -07:00
David Aurelio 9bfa393a79 fix new flow errors after D3561327
Reviewed By: bestander

Differential Revision: D3561376

fbshipit-source-id: 226f0d1c6a771a987f9e04f114dc3ba1cca531b1
2016-07-14 04:58:43 -07:00
Philipp von Weitershausen 08c375f828 Add responseType as a concept to RCTNetworking, send binary data as base64
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
2016-07-13 04:58:37 -07:00
Spencer Ahrens 4d6c1e55d7 Bring back trackingName
Reviewed By: yungsters

Differential Revision: D3501805

fbshipit-source-id: be7e1a76c022d050542af797dda49b3cf14340bb
2016-07-11 17:58:21 -07:00
Philipp von Weitershausen e29350214a Correct semantics for XMLHttpRequest.responseText
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
2016-06-02 18:13:23 -07:00
Nick Lockwood bdcdfb03d4 Fixed "Sending `didSendNetworkData` with no listeners registered" warning
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
2016-06-01 06:28:22 -07:00
Nick Lockwood b71db11554 Update RCTNetworking, RCTNetInfo and RCTLocationManager to use new events system
Summary: Updated networking and geolocation to use the new events system.

Reviewed By: bestander

Differential Revision: D3346129

fbshipit-source-id: 957716e54d7af8c4a6783f684098e92e92f19654
2016-05-25 04:28:36 -07:00
Konstantin Raev 2de0323182 Reverted commit D3339945
Summary: Updated networking and geolocation to use the new events system.

Reviewed By: javache

Differential Revision: D3339945

fbshipit-source-id: 01d307cf8a0aea3a404c87c6205132c42290abb1
2016-05-24 12:43:30 -07:00
Nick Lockwood 3f08fe4b7f Update RCTNetworking, RCTNetInfo and RCTLocationManager to use new events system
Summary: Updated networking and geolocation to use the new events system.

Reviewed By: javache

Differential Revision: D3339945

fbshipit-source-id: f1332fb2aab8560e4783739e223c1f31d583cfcf
2016-05-24 10:29:00 -07:00