Summary:
**Motivation**
I'm working on a project that uses React Native and needs to add direct synchronous bindings to native stuff through the JavaScriptCore C API. This is because it's performance-sensitive and would benefit from the quickest JS->C path. It does this using cross-platform C++ code that works on both iOS and Android. Most of the infrastructure for getting access to the JSC context is already in React Native actually, just had to add a few more things.
(lexs you mentioned to tag you in this pull request)
**Test plan**
Modify the JavaScriptCore context through the `JSContextRef` returned (eg. add an object at global scope) and verify that it exists in JavaScript.
Closes https://github.com/facebook/react-native/pull/10399
Differential Revision: D4080945
Pulled By: lexs
fbshipit-source-id: 6659b7a01e09fd84475adde183c1d3aca2d4cf09
Summary:
Explain the **motivation** for making this change. What existing problem does the pull request solve?
See https://github.com/facebook/react-native/issues/10506. A native `NSError` with `NSUnderlyingErrorKey` set causes a JSON stringify error from the websocket dispatcher if remote debugging is enabled.
**Test plan (required)**
I'm not familiar with the react native testing framework. Happy to add a test for this if someone can point me to where this part of the codebase is exercised :)
I did some spot checks with nil user dictionaries and nil underlying errors here. The case that this solves is testable using https://github.com/superseriouscompany/react-native-error-repro, specifically:
```objective-c
NSError *underlyingError = [NSError errorWithDomain:@"underlyingDomain" code:421 userInfo:nil];
NSError *err = [NSError errorWithDomain:@"domain" code:68 userInfo:@{@"NSUnderlyingError": underlyingError}];
reject(@"foo", @"bar", err);
```
Closes https://github.com/facebook/react-native/pull/10507
Differential Revision: D4080802
Pulled By: lacker
fbshipit-source-id: 93a41d9e9a710e406a6ccac214a5617271b4bede
Summary:
1. Using weak container to hold the currently opened alerts.
2. Using weak reference to alertController in action handler block.
3. BTW, remove the unused vars: _alertCallbacks, _alertButtonKeys.
Test plan (required)
```
- (void)invalidate
{
for (UIAlertController *alertController in _alertControllers) {
[alertController.presentingViewController dismissViewControllerAnimated:YES completion:nil];
}
}
```
Since we use weak container, _alertControllers should only contains the currently opened alerts.
I test this way: Put a breakpoint in invalidate, open the UIExplorer play with the 'Alert' & 'AlertIOS' examples, then fire a reload and see if _alertControllers contains the expected values.
Closes https://github.com/facebook/react-native/pull/10407
Differential Revision: D4078649
Pulled By: lacker
fbshipit-source-id: 8509e7e7142379a81d5b28c9067c085bad8bb5cb
Summary: This is a simple hook to allow native side to fetch any file under the js root folder via packager. Historically, only the `main.jsbundle` is fetched via the packager. This then allows fetching local file like a json file that lives under the same root js folder
Reviewed By: yungsters
Differential Revision: D4037730
fbshipit-source-id: a2d6eb5e30d148fee573d413fc4036d0189f4938
Summary:
- Consolidate common code in iOS and tvOS test scripts
- Start the packager before starting tests, to improve reliability
- Increase timeout value in RCTTestRunner.m
Closes https://github.com/facebook/react-native/pull/10378
Differential Revision: D4028364
Pulled By: bestander
fbshipit-source-id: 24c2124a1c62643a02f0668b60a67b971e08d1a3
Summary:
JS API very similar to web workers and node's child process.
Work has been done by somebody else for the Android implementation over at #7020, so we'd need to have these in sync before anything gets merged.
I've made a prop `messagingEnabled` to be more explicit about creating globals—it might be sufficient to just check for an onMessage handler though.
Closes https://github.com/facebook/react-native/pull/9762
Differential Revision: D4008260
fbshipit-source-id: 84b1afafbc0ab1edc3dfbf1a8fb870218e171a4c
Summary:
This fixes the following problem on iPad (happens when trying to show the devmenu ActionSheet):
> Terminating app due to uncaught exception 'NSGenericException', reason: 'Your application has presented a UIAlertController () of style UIAlertControllerStyleActionSheet. The modalPresentationStyle of a UIAlertController with this style is UIModalPresentationPopover. You must provide location information for this popover through the alert controller's popoverPresentationController. You must provide either a sourceView and sourceRect or a barButtonItem. If this information is not known when you present the alert controller, you may provide it in the UIPopoverPresentationControllerDelegate method -prepareForPopoverPresentation.'
I see 2 ways of fixing the issue: falling back to Alert (always displayed in the center) or adding a fake view somewhere on the screen to display the ActionSheet.
Reviewed By: mmmulani
Differential Revision: D3989672
fbshipit-source-id: 59fabc50ec1aac3ae6ddd7ecf4d8e8e5b9586dba
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:
Packager can take a long time to load and the progress is usually displayed in another window (Terminal). I'm adding support for showing a UI inside React Native app for packager's progress when loading a bundle.
This is how it will work:
1. React Native sends request to packager with `Accept: multipart/mixed` header.
2. Packager will detect that header to detect that client supports progress events and will reply with `Content-Type: multipart/mixed`.
3. While building the bundle it will emit chunks with small metadata (like `{progress: 0.3}`). In the end it will send the last chunk with the content of the bundle.
4. RN runtime will be receiving the events, for each progress event it will update the UI. The last chunk will be the actual bundle which will end the download process.
This workflow is totally backwards-compatible -- normally RN doesn't set the `Accept` header.
Reviewed By: mmmulani
Differential Revision: D3845684
fbshipit-source-id: 5b3d2c5a4c6f4718d7e5de060d98f17491e82aba
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
Pieter De Baets
Nikhilesh Sigatapu
Neil Sarkar
littlesome
Scott Wolchok
Emil Sjolander
Kazuki Sakamoto
Kevin Gozali
dlowder-salesforce
Jacob Parker
Alex Kotliarskyi
Georgiy Kassabli
Dan Caspi
Ovidiu Viorel Iepure
Alexander Pantyuhov
Marc Horowitz
