Summary:
Adding shebang to local-cli's setup_env script.
Depending how your *nix environment is setup, running `react-native bundle` will throw this error:
```
Error: spawnSync /opt/build/in/node_modules/react-native/local-cli/setup_env.sh Unknown system error -8
at exports._errnoException (util.js:1022:11)
at spawnSync (child_process.js:461:20)
at Object.execFileSync (child_process.js:498:13)
at repl:1:14
at sigintHandlersWrap (vm.js:22:35)
at sigintHandlersWrap (vm.js:96:12)
at ContextifyScript.Script.runInThisContext (vm.js:21:12)
at REPLServer.defaultEval (repl.js:346:29)
at bound (domain.js:280:14)
at REPLServer.runBound [as eval] (domain.js:293:12)
```
In my case I was running react-native on docker (using alpine-node:6 as base image).
Closes https://github.com/facebook/react-native/pull/12173
Differential Revision: D5154069
Pulled By: shergin
fbshipit-source-id: acf2a21499b4a57310afd06b57386e7900662b7d
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:
We are removing support of nesting views inside <Image> component. We decided to do this because having this feature makes supporting intrinsinc content size of the <Image> impossible; so when the transition process is complete, there will be no need to specify image size explicitly, it can be inferred from actual image bitmap.
And this is the step #2: Yellow Box.
<ImageBackground> is very simple drop-in replacement which implements this functionality via very simple styling.
Please, use <ImageBackground> instead of <Image> if you want to put something inside.
Reviewed By: yungsters
Differential Revision: D5139264
fbshipit-source-id: 99442107e10a321618fd34802c57a8c205ce66fb
Summary:
Make android-version accept a decimal
number as lineHeight.
Credits where due, solution was given in this
issue: facebook/react-native#10607
According to the w3 spec the property
line-height should accept decimal values
(and it does on iOS) but the android
version has the wrong data-type for the
shadowed method, resulting in a stacktrace
saying:
com.facebook.react.bridge.UnexpectedNativeTypeException: TypeError:
expected dynamic type `int64', but had type `double'
Setting it to a float makes it accept
decmial values as it should.
* Create an app without this commit and create the same app with this commit:
In both apps:
- Leave line-height undefined. Behavior is unaffected by this commit.
- Set lineHeight to a integer number. Behavior is unaffected by this commit.
- Set lineHeight to a decimal number. Line height is now rendered with decimals in the app with this fix.
* Run android integration tests to see nothing
else broke.
Sign the [CLA][2], if you haven't already.
Small pull requests are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
Make sure all **tests pass** on both [Travis][3] and [Circle CI][4]. PRs that break tests are unlikely to be merged.
For more info, see the ["Pull Requests"][5] section of our "Contributing" guidelines.
[1]: https://medium.com/martinkonicek/what-is-a-test-plan-8bfc840ec171#.y9lcuqqi9
[2]: https://code.facebook.com/cla
[3]: https://travis-ci.org/facebook/react-native
[4]: http://circleci.com/gh/facebook/react-native
[5]: https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#pull-requests
Closes https://github.com/facebook/react-native/pull/13843
Differential Revision: D5152982
Pulled By: shergin
fbshipit-source-id: cda3b72497a6c27d6948b31ec846640a8913775a
Summary:
The current website defaults to using JavaScript for any code block, regardless of language tag. This PR adds syntax highlighting support by passing the necessary language prop and by adding any missing languages to Marked.js.
Depends on #14212, #14065
Closes https://github.com/facebook/react-native/pull/14215
Differential Revision: D5149897
Pulled By: hramos
fbshipit-source-id: 95a817af2168d5743c75dd1ac030d399a68fb93c
Summary:
We've noticed that many newcomers paste sample code straight into a project created using `react-native init AwesomeProject`, but the sample code assumes the user is creating a new project for each example. This PR makes it so that these samples can be pasted into the same project from the Getting Started.
Closes https://github.com/facebook/react-native/pull/14264
Differential Revision: D5149746
Pulled By: hramos
fbshipit-source-id: cae95ab5b7baf64ddd9fe12d342ad05f785bb381
Summary:
This PR aims to update the Inspector tool in React Native to use the new inspection APIs that have been added to the ReactNative renderer:
https://github.com/facebook/react/pull/9691
This PR also cleans up the code in `Inspector.js` so there's no usage of React's internals.
Closes https://github.com/facebook/react-native/pull/14160
Reviewed By: bvaughn
Differential Revision: D5129280
Pulled By: trueadm
fbshipit-source-id: b1b077c04f46b0f52cdea0e19b4154441558f77a
Summary:
This change introduces some APIs that are useful for making announcements through the screen reader on iOS:
- `announceForAccessibility`: The screen reader announces the string that is passed in.
- `announcementFinished`: An event that fires when the screen reader has finished making an announcement.
You can already solve similar problems with RN Android using the `accessibilityLiveRegion` prop. Live regions are a different feature but they can be used to solve the same problem. This commit does not attempt to add live region support in RN iOS because Apple did not build live region support into iOS.
Verified that `announceForAccessibility` causes VoiceOver to announce the string when VoiceOver is enabled. Verified that `announcementFinished` fires with the appropriate data in the event object. Additionally, my team has been using this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/14168
Differential Revision: D5137004
Pulled By: javache
fbshipit-source-id: b3c10f3dfc716430a16fcc98e1bb6fe52cabd6a5
Summary:
` ConstantsconstantsToExport` in` EnumConstants` has an error. It is a missing a closing curly braces after `return`.
Do not need a test.
Closes https://github.com/facebook/react-native/pull/13911
Differential Revision: D5145977
Pulled By: shergin
fbshipit-source-id: 267ea7d69253d10aaef763879318824b6e02d2c5
Summary:
Motivation:
* We maintain two different implementation of <TextInput> (multilined and singlelined), this change makes the implementations much similar which will help us to support and improve both of them in the (near) future;
* We have to have separated RCTView-based container view for (TextField) to support sofisticated bordering and so on;
* It opens to us possibility to unify UITextView and UITextField subclasses and remove code duplication across RCTTextView and RCTTextField;
* Making things decoupled in general will allow us to fix existing bugs with events.
Reviewed By: mmmulani
Differential Revision: D5083010
fbshipit-source-id: 2f2d42c2244d2b39256c51480c1f16f4e3947c01
Summary: Now padding, border and intinsic sizes are computed same way as for singlelined text input.
Reviewed By: mmmulani
Differential Revision: D5075880
fbshipit-source-id: 1bc2fd479c13a003c717b1fc3d9c69f4639d4444
Summary:
Because it introduces inconsistency in RN layout model, confuses people and hurts dev experience.
The original problem was introduced in D1611014 as an attempt to address the intrinsic size issue.
So, now <TextInput> has intrinsic size (D5069971) and we don't need this hack anymore.
GH issues:
https://github.com/facebook/react-native/issues/11892https://github.com/facebook/react-native/issues/9646
Reviewed By: javache
Differential Revision: D5072833
fbshipit-source-id: d9a60ab09b728e6de89bfa53eda07069377f1369
Summary: Previosly `borderWidth` did not affect actual content inset (which was a problem).
Reviewed By: mmmulani
Differential Revision: D5072483
fbshipit-source-id: d43cba7414a9335b9f9fd4d1565d7aee403cce0e
Summary: Because we believe in Objective-C.
Reviewed By: javache
Differential Revision: D5070920
fbshipit-source-id: 17e2335c829f2e5857981c5028e3bcecbe5dc13f
Summary:
Singleline <TextInput> now has intrinsic size which is equal to size of placeholder.
And if <TextInput> does not have placeholder it still has intrinsic height.
So, we don't need to set the size up manually every single time anymore!
(Multiline <TextInput> already has this feature.)
Reviewed By: mmmulani
Differential Revision: D5069971
fbshipit-source-id: f65c1062a812259b66d287929314dc571dc1f3ee
Summary:
- new-library was copying file inside the <project_root>/node_modules/react-native/Libraries instead of <project_root>/Libraries. This was due to the path.resolve that was being passed 2 full paths instead of a base path + relative path segment.
---
Before:
```js
console.log(libraryDest, dest, path.resolve(libraryDest, dest);
// <base-path>/Libraries/TestLib
// <base-path>/node_modules/react-native/Libraries/TestLib/package.json
// <base-path>/node_modules/react-native/Libraries/TestLib/package.json
```
After:
```js
console.log(libraryDest, dest, path.resolve(libraryDest, dest);
// <base-path>/Libraries/TestLib
// ../TestLib/package.json
// <base-path>/Libraries/TestLib/package.json
```
Closes https://github.com/facebook/react-native/pull/13748
Differential Revision: D5043652
Pulled By: shergin
fbshipit-source-id: febee13781fc7075276daa67f9a78cc73dfd4b73
Summary:
This avoids reordering views because it created some bugs when the native hierarchy is different from the shadow views. This leverages `layer.zPosition` and takes z-index in consideration when we check what view should be the target of a touch.
**Test plan**
Tested that this fixes some layout issues that occurred when using sticky headers in the Expo home screen.
Closes https://github.com/facebook/react-native/pull/14011
Differential Revision: D5108437
Pulled By: shergin
fbshipit-source-id: 0abfe85666e9d236a190e6f54cdd5453cacfbcac
Summary:
…cookies on Android Lollipop or later versions.
Third party cookies in WebView are [disabled by default](https://developer.android.com/reference/android/webkit/CookieManager.html#setAcceptFileSchemeCookies(boolean)) on Android Lollipop or later versions. This prevented users from logging in by using _Login by Facebook_ method (in redirect mode) in Android Webview.
This PR exposes a prop `thirdPartyCookiesEnabled` which will enable third party cookies in Android Webview. This setting is ignored on versions below Android Lollipop and on iOS as third party cookies are enabled in them by default.
Appropriate documentation was added in code and they were reflected in the website.
Closes https://github.com/facebook/react-native/pull/14013
Differential Revision: D5145059
Pulled By: shergin
fbshipit-source-id: 67bcb3a497a9c6f6db1d12e8d16197d2facd157e
Summary:
`contentSize` was removed from both iOS and Android, tests was updated.
USE `onContentSizeChange` INSTEAD.
Why?
* It always was a hack;
* We already have dedicated event for it: `onContentSizeChange`;
* `onChange` has nothing to do with layout actually;
* We have to maintain `onChange` handler as fast and simple as possible, this feature complicates it a lot;
* It was undocumented feature;
* We already have native auto-expandable <TextInput>, so it illuminates 99% current use cases of this feature.
Reviewed By: mmmulani
Differential Revision: D4989881
fbshipit-source-id: 674bb98c89ada1fca7b3b20b304736b2a3b8304e
Summary:
Currently it's not possible to create a silent local notification (which is useful for badge updates) with PushNotificationIOS. This commit solves the problem - when **soundName** param is not specified in **PushNotificationIOS.scheduleLocalNotification** method, a silent notification will be created.
Local notification without sound:
```
let fireDate = new Date();
fireDate = fireDate.setSeconds(fireDate.getSeconds() + 15); //fire in 15 seconds
PushNotificationIOS.scheduleLocalNotification({
fireDate: fireDate,
alertBody: "I'm silent!"
});
```
Local notification with sound:
```
let fireDate = new Date();
fireDate = fireDate.setSeconds(fireDate.getSeconds() + 15); //fire in 15 seconds
PushNotificationIOS.scheduleLocalNotification({
fireDate: fireDate,
alertBody: "I'm with sound!",
soundName: "Any sound"
});
```
Closes https://github.com/facebook/react-native/pull/13734
Differential Revision: D5144848
Pulled By: shergin
fbshipit-source-id: dc990b2673305a01cfd868fcdedcf27c461d0a34
Summary:
should be consistent with semicolons...
Thanks for submitting a PR! Please read these instructions carefully:
- [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.
I think it's good to stay consistent when using semicolons and when not using semicolons.
What existing problem does the pull request solve?
Consistency, I guess?
None really - it's a document (markdown) change. Not much to test.
Closes https://github.com/facebook/react-native/pull/13993
Differential Revision: D5144814
Pulled By: shergin
fbshipit-source-id: 8bf345897738458183047a229a3d327bec4b64ae
Summary:
The Examples directory no longer exists and the instructions in this part of the README were stale.
Follow the instructions to run RNTester on iOS and Android
(this actually fails for me currently on Android, but I believe the instructions are correct and the failure is related to something else)
Closes#14222
Closes https://github.com/facebook/react-native/pull/14229
Differential Revision: D5144514
Pulled By: shergin
fbshipit-source-id: 19ca173e8c5e91de7e1e53a21dbcaa0968da092b
Summary:
On some devices, we saw many Chrome windows open when the WebView attempted to send the user to about:blank. This change allows the WebView to handle about:blank which prevents the Chrome windows from opening and gives the user a better experience.
Verified that the WebView no longer opens the device's browser when navigating to about:blank. My team has been using this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/14173
Differential Revision: D5142352
Pulled By: hramos
fbshipit-source-id: 1070d4381b385a5bf1829fd8e97efba2045f7968
Summary:
Maintainers - hoping theres a chance this could be cherry-picked into 0.44-stable as it's a very minor change to the local-cli.
Our iOS app has 3 different configurations, each with a separate Product Name. When building for debugging on the simulator with the `react-native run-ios` command, the build would complete successfully but would error in trying to install to the simulator. I tracked the error down to the regex I've updated in this PR which was looking for the full product name in the build output, but the regex there wasn't using the multiline flag so it never matched.
I've tested this locally with our app and it now works as expected. If I specify a different configuration with `react-native run-ios --configuration Beta` (for example), it properly detects the Product Name for the configuration and installs correctly as well.
Closes https://github.com/facebook/react-native/pull/14071
Differential Revision: D5141414
Pulled By: shergin
fbshipit-source-id: 23bceb8a9650cc0cf2a83ea92ad417049240da4e
Summary:
Thanks for submitting a PR! Please read these instructions carefully:
- [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.
Fixes#14081. Prevents unnecessary error output on check for yarn package manager on Windows systems.
Can't find existing tests for the CLI and JavaScript doesn't have much knowledge about this change anyhow.
Example behavior with and without the fix:
Note that on master, the output contains the line "'yarn' is not recognized as an internal or external command, operable program or batch file." and on my branch, it does not.
Sign the [CLA][2], if you haven't already.
Small pull requests are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
Make sure all **tests pass** on both [Travis][3] and [Circle CI][4]. PRs that break tests are unlikely to be merged.
For more info, see the ["Pull Requests"][5] section of our "Contributing" guidelines.
[1]: https://medium.com/martinkonicek/what-is-a-test-plan-8bfc840ec171#.y9lcuqqi9
[2]: https://code.facebook.com/cla
[3]: https://travis-ci.org/facebook/react-native
[4]: http://circleci.com/gh/facebook/react-native
[5]: https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#pull-requests
Closes https://github.com/facebook/react-native/pull/14082
Differential Revision: D5141387
Pulled By: shergin
fbshipit-source-id: 80f9aa9ecb7d8943f0b3b87b8ebbe7828c317bbd
Summary:
We found that `-[CALayer renderInContext:]` produces bad results in some cases (which is actually documented thing!),
so we decided to replace it with `-[UIView drawViewHierarchyInRect:]` which is more reliable (I hope).
As part of this change I completly removed support of `CALayer` from local fork of `RNTesterIntegrationTests`.
See https://github.com/facebook/react-native/pull/14011#issuecomment-303844580 for more details.
janicduplessis
Reviewed By: javache
Differential Revision: D5129492
fbshipit-source-id: 6a9227037c85bb8f862d55267f5301e177985ad9
Summary:
The documentation for the prop `scrollEnabled` on the `ScrollView` component does not clarify that scrolling is still possible by calling `scrollTo` on the view ref.
Please see [this expo snack demo](https://snack.expo.io/BJKTVMM-Z) showing scrolling is allowed while `scrollEnabled` is `false`.
This PR makes the documentation for this prop more clear, in that setting it to false will only disable scrolling by touches, not universally.
In my opinion, this also raises the question of a need for an additional prop which would disable all scrolling, even when calling `scrollTo`.
I have attached a screenshot of what this part of the documentation looks like with my edit:
Closes https://github.com/facebook/react-native/pull/14140
Differential Revision: D5138593
Pulled By: shergin
fbshipit-source-id: db1a5f9c8ac41ecfce952e7b1fce9428b2068162
Summary: By getting rid of callbacks, we get a code that's pretty halved in size, and much easier to read, but we also fix bugs! When some of the code of Module would throw, we wouldn't catch it, meaning that packager would crash entirely. That's the case for when we have a Haste name mistach, for example. This changeste fixes that by instead capturing exceptions through the Promise chain, that bubble up all the way to the `Server` and reasonnably handled. People can then fix the Haste nane mismatch and refresh right away, and it'll work as expected.
Reviewed By: davidaurelio
Differential Revision: D5137408
fbshipit-source-id: b9e938b93e8d23738af49106bbae1fce97d7a5db
Gabriel Laet
chunghe
Aaron Chiu
adamjmcgrath
Stephen Bird
Valentin Shergin
Jonas Lundberg
Pieter De Baets
Reem Helou
Hector Ramos
Hyunchel Kim
Pieter De Baets
Dominic Gannaway
Brian Vaughn
Jean Lauliac
Christoph Pojer
Adam Comella
Jeff kang
Hugo Dozois
Emil Sjolander
Werner Roets
Janic Duplessis
Saleel Salam
Alex Ledak
Shashank Saxena
Brent Vatne
unexge
Max Thorson
Ryan Stelly
Chris Knepper
Georgiy Kassabli
