Summary: When loading bundle from packager, "application/javascript" and "text/javascript" both refer to JS, so let's allow both for now.
Reviewed By: javache
Differential Revision: D5499446
fbshipit-source-id: f0b42e2fe5dc043a68d2c8df6a9f81e6dd995b57
Summary:
When using the packager behind something like an http tunnel it is possible something else than JS is returned, in that case throw an error instead of trying to parse it.
This is useful for Expo since the packager runs behind ngrok. This allows to intercept that error and show a more meaningful error message based on the ngrok response.
**Test plan**
Tested by changing the packager to return text/html content type and validate that the error shows up properly.
Also tested that it works when multipart response is disabled.
<img width="354" alt="screen shot 2017-07-19 at 8 01 58 pm" src="https://user-images.githubusercontent.com/2677334/28394905-39e86d52-6cbe-11e7-9059-13a85816a57e.png">
Closes https://github.com/facebook/react-native/pull/15112
Differential Revision: D5459395
Pulled By: shergin
fbshipit-source-id: aaea7ab2e1311ee8dc10feb579adf9b9701d8d4c
Summary:
Our iOS devs frequently turn off wifi and forget to turn it back on. This message should remind them that they need wifi to connect. Often they waste several minutes due to this problem.
I'm not sure if there's a test plan to apply here. Any suggestions?
Closes https://github.com/facebook/react-native/pull/13551
Differential Revision: D5149231
Pulled By: hramos
fbshipit-source-id: 0afc71024f10f802ac1a50435fb57fc10a02c819
Summary:
Since we are reading from a file, we should make sure this struct is packed, just in case we change it down the line and the compiler decides it might want to introduce padding, we're now protected against that.
There was also a discussion about the fact that people might use `ptr += sizeof(BundleHeader)` as an idiom in their code, which would currently be incorrect, if padding was introduced at the end of the file. Actually, it remains incorrect to do that now, because a RAM bundle header is a different size to a BC Bundle header. If people are properly testing their code, they should spot this pretty quickly, because it will always be an incorrect thing to do with a RAM bundle, so this isn't as bad as previously thought: where the code only succeeds when the compiler deigns to not pad the struct at the end.
This diff also cleans up how headers are initialised. `BundleHeader` has a constructor that explicitly zero-initialises it so we can rely on the default initializer to do the right thing now.
Reviewed By: mhorowitz
Differential Revision: D4572032
fbshipit-source-id: 7dc50cfa9438dfdfb9f842dc39d8f15334813c63
Summary:
Currently a build warning is thrown by `if (header.BCVersion != runtimeBCVersion) ...` because `runtimeBCVersion` is signed, apparently because `-1` is used to mean that the runtime has no support for bytecode bundles.
This PR splits out the error case of the runtime not supporting BC bundles from the case of a version mismatch.
Tested as much as I could by building and running `UIExplorer` - I haven't attempted to use real bytecode bundles.
Closes https://github.com/facebook/react-native/pull/11806
Differential Revision: D4408608
fbshipit-source-id: a1d868bb2064588e6a20827692629a46b6ba1e74
Summary:
Strangely comparing a pointer with zero will only be a clang warning when compiling with `-Wpedantic`, so this incorrect comparison is silently allowed.
**Test plan**
Compiles with `-Wpedantic`.
Closes https://github.com/facebook/react-native/pull/11709
Differential Revision: D4377512
Pulled By: ericvicenti
fbshipit-source-id: 483cf1f41d3f539c452d542ad2155c4c4b41616d
Kevin Gozali
Janic Duplessis
Pieter De Baets
Stephen Bird
Ashok Menon
rh389
Dave Lee
David Aurelio
