Summary:
Currently the RCTActionSheetManager attempts to present itself from the 'rootViewController' of the key window, presenting a modal from a view controller which is already presenting a modal is not allowed on iOS and this fails with the following error appearing in the XCode debugger (but not the chrome debugger):
```
Warning: Attempt to present <UIAlertController: 0x7fca85b14f40> on <UINavigationController: 0x7fca84812000> whose view is not in the window hierarchy!
```
This change recursively looks through modally presented view controllers until it finds the top one and then uses that to present the action sheet.
Closes https://github.com/facebook/react-native/pull/5263
Reviewed By: svcscm
Differential Revision: D2823201
Pulled By: nicklockwood
fb-gh-sync-id: aad1ad88115563f633fd9aaea8e27d1d155a6c27
Summary:
brentvatne this is the pull request you requested
See issue #4886
On iOS the plist key NSLocationAlwaysUsageDescription was ignored and the location could not be retreived when using this key. Now both keys NSLocationWhenInUseUsageDescription and NSLocationAlwaysUsageDescription are supported. If NSLocationAlwaysUsageDescription is set, NSLocationWhenInUseUsageDescription will be simply ignored according to https://developer.apple.com/library/ios/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40009251-SW18
I read the contribution guidelines regarding the Objective-C coding standards. Hopefully my line length breaks are okay - otherwise just give me a shout and I will fix that. Didn't write any line of Objective-C before so^^
Closes https://github.com/facebook/react-native/pull/5093
Reviewed By: svcscm
Differential Revision: D2823206
Pulled By: nicklockwood
fb-gh-sync-id: dd856a18416796749025e4b32d9c72895401916d
It caused problems on Windows unfortunately and when we tried to
fix it we got: https://github.com/facebook/react-native/issues/5159
Reverting to unblock people. In the future we'll do careful rc
releases of the CLI. We should try to make the change again without
breaking anyone, regardless of OS (OSX, Linux, Windows) or npm version.
Summary:
public
The fix for border smearing introduced a bug where borders + background would sometimes not be rendered if the view was created at a small size (e.g. zero) and then resized.
This diff fixes that by redrawing the border if the view size changes. There is some opportunity to optimize this in future by performing some logic up-front to detect if the redrawing is necessary, but I thought I'd keep it simple for this bug fix rather than risk introducing further bugs.
Reviewed By: jingc
Differential Revision: D2817365
fb-gh-sync-id: eca164e8ce03a66598677c9e05496791230b5210
Summary:
public
Disabling background color propagation had the unexpected effect of turning ART views black. This diff re-enabled propagation for ART views.
Reviewed By: jingc
Differential Revision: D2816402
fb-gh-sync-id: f2a4c44f3b4a16e04cbf6051391bb8fb1c0a7ed2
Summary:
This PR adds support for Android Gradle [Build Variants](https://sites.google.com/a/android.com/tools/tech-docs/new-build-system/user-guide#TOC-Build-Variants) when generating the JS bundle.
**Before**: only supported "bundleDebugJsAndAssets" and "bundleReleaseJsAndAssets"
**Now**: all variants are supported
Examples: "bundleDevDebugJsAndAssets", "bundleStageAlphaJsAndAssets", or "bundleBetaJsAndAssets"
The Gradle script will automatically create bundle tasks for each build variant found in a project.
Closes https://github.com/facebook/react-native/pull/4686
Reviewed By: svcscm
Differential Revision: D2815856
Pulled By: foghina
fb-gh-sync-id: 4518de70d178205bc3e5044d2446b56c40298da2
Summary:
One consequence we didn't predict after introducing the Internal Transform Pipeline, was that when the workers would get started, we won't require the external transformer the user specified up until the first time each worker received a job. There're 2 visible consequences of this: (1) the transform progress bar seems to get stuck for about 5 seconds the first time the packager receives a request and (2) the first N (# of cores) HMR requests take way longer (about 4 seconds with FB's transformer instead of << 1 second) as we need to require lots of modules.
This diff creates a temporary file for the js transformer workers that requires the user-specified transform file eagerly.
That makes sure workers have imported babel and the transforms before receiving the first request.
There are better ways to do this, like adding an `init()` method to the workers and call that eagerly. I will follow with another diff doing that.
public
Reviewed By: javache
Differential Revision: D2812153
fb-gh-sync-id: 15be316b792d1acd878ed9303bea398aa0b52e1d
Summary:
I'm working on deploying haste2 with jest. This updates all the files that require changes for this to work and they are backwards compatible with the current version of jest.
* package.json was just outdated. I think haste1's liberal handling with collisions made this a "non-issue"
* env.js didn't properly set up ErrorUtils, also unsure why that isn't a problem in jest right now already?
* some things were mocking things they shouldn't
* Because of the regex that matches against providesModule and System.import, it isn't possible to list module names more than once. We have multiple tests reusing the same providesModule ids and using System.import with modules that only exist virtually within that test. Splitting up the strings makes the regexes work (we do the same kind of splitting on www sometimes if we need to) and using different providesModule names in different test files fixes the problem. I think the BundlesLayoutIntegration-test is going to be deleted, so this doesn't even matter.
public
Reviewed By: voideanvalue
Differential Revision: D2809681
fb-gh-sync-id: 8fe6ed8b5a1be28ba141e9001de143e502693281
Summary:
public
The 'end' value in the onTextInput callback was incorrectly computed. It now is correct. The value of start and end are relative to the entirety of the entire prechange text in the text input.
Reviewed By: andreicoman11
Differential Revision: D2815064
fb-gh-sync-id: e9f9c84cc5836042d0ffcccc991df72b725ab994
Summary:
public
Blending semitransparent pixels against their background is fairly a fairly expensive operation on mobile GPUs. To reduce blending, React Native has a system called "background color propagation", where the background color of parent views is automatically inherited by child views unless explicitly overridden. This means that translucent pixels can be blended directly against a known background color, avoiding the need to do this dynamically on the GPU.
In practice, this is only useful for views that do their own drawing, which is basically just `<Image/>` and `<Text/>` components, and for image components it only really matters when the image has an alpha component.
The automatic background propagation is a bit of a hack, and often does the wrong thing - for example if a view overflows its bounds, or if it overlaps a sibling, the background color will often be incorrect and need to be manually disabled. Because the only place that it provides a significant performance benefit is for text, this diff disables the behavior for everything except `<Text/>` nodes. It might still be useful for `<Image/>` nodes too, but looking through the examples in UIExplorer, the number of places where it does the wrong thing for images outnumbers the cases where it provides significant reduction in blending.
Note that this diff does not prevent you from eliminating blending on image components by manually setting an opaque background color, nor does it stop you from disabling color propagation on text components by manually setting a transparent background.
Reviewed By: javache
Differential Revision: D2811031
fb-gh-sync-id: 2eb08918c9031c582a3dd2d40e04b27a663dac82
Summary:
public
We should further improve this on the future by showing the actual stacktrace instead of the `HMRClient` one. Also, we need to integrate this with the dev plugin that opens in the default editor the file/line the user clicks on.
Reviewed By: vjeux
Differential Revision: D2798889
fb-gh-sync-id: 2392966908c493e86e11b0d024e7b68156c9066c
Reviewed By: mkonicek
Differential Revision:D2812482
Ninja: Doesn't affect any fb apps or code, purely for open source
fb-gh-sync-id: 4d190354112e3f002405686769dcc409e3394c3c
Summary:
public
Fixes a terrible bug due to which when Hot Loading enabled when the user reloads we'll serve them the first `hot` bundle he requested. This happened because when HMR enabled we bailed out after sending the HMR updates and didn't rebuild any of the bundles the user requested before. As a consequence, when they reload we'd sent him the first and only one we ever built.
The fix is to tweak the hmr listener to return a promise. This way we can run the remaining code on the file change listener just after the HMR stuff finishes. We need to do it this way to avoid the remaining stuff to compete for CPU with the HMR one and give the best possible experience when HMR is enabled.
Reviewed By: davidaurelio
Differential Revision: D2811382
fb-gh-sync-id: 906932d71f35467485cf8a865a8d59f4d2ff41a0
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
The props argument of the `-[RCTComponentData createView:props:]` method was removed,
but the C function used to swizzle it in the profiler wasn't updated.
Reviewed By: majak
Differential Revision: D2811228
fb-gh-sync-id: 8896638c77370142e29913b5fb80e7fd748254b5
Summary:
public
Since we don't actually recreate our native modules every time (will fix in follow-up), we'd never update the reference after reloading the bridge, and all navigation would fail.
Reviewed By: majak
Differential Revision: D2811406
fb-gh-sync-id: 4f4fd73bbdecfe510e1e1554668b2354181f22a8
Summary:
public
The iOS border rendering code did not follow the CSS spec in cases where the sum of adjacent border radii was greater than the width of the view, resulting in drawing glitches such as pixel smear and borders appearing stretched or squashed.
This diff brings our implementation closer to spec-compliance in these cases. I also fixed a longstanding issue with ghostly diagonal lines appearing at the corners due to antialiasing rounding errors!
Fixes
https://github.com/facebook/react-native/issues/1572https://github.com/facebook/react-native/issues/2089https://github.com/facebook/react-native/issues/4604
Reviewed By: tadeuzagallo
Differential Revision: D2811249
fb-gh-sync-id: c3dd2721e0a01a432fa4dc78daa05680595edd08
Summary:
This allows everyone to deploy significantly smaller APKs to they Play Store by building separate APKs for ARM, x86 architectures.
For a simple app, a release APK minified with Produard:
- Universal APK is **7MB**
- x86 APK is **4.6MB** (34% reduction)
- ARM APK is **3.7MB** (47% reduction)
Created a sample project, uncommented `// include "armeabi-v7a", 'x86'`:
cd android
./gradlew assembleDebug
Three APKs were created, unzipped each: one has only x86 binaries,
one has ARM binaries, one has both.
./gradlew assembleRelease
Three APKs were created, JS bundle is correcly added to assets.
react-native run-android
The correct APK is installed on the emulator and the app runs fine
(Gradle output: "Installing APK 'app-x86-debug.apk'").
With the line commented out the behavior is exactly the same as before,
only one universal APK is built.
Checked that version codes are set correctly as described in
http://tools.android.com/tech-docs/new-build-system/user-guide/apk-splitshttp://developer.android.com/intl/ru/google/play/publishing/multiple-apks.html
Closes https://github.com/facebook/react-native/pull/5160
Reviewed By: svcscm
Differential Revision: D2811443
Pulled By: mkonicek
fb-gh-sync-id: 97b22b9cd567e53b8adac36669b90768458b7a55
Summary:
Adds support for tracking unhandled rejections with `console.warn` (= yellow box).
I will create a follow-up with proper error stack formatting.
related: #4971fixes: #4045, #4142
public
{F59857438}
{F59857439}
Reviewed By: bestander
Differential Revision: D2803126
fb-gh-sync-id: 376b33e42a967675a04338cbff3ec315a77d1037
Summary:
public
We're not planning to accept file removals in the short term on the HMR interface so lets bail when a file is removed (before this this we were throwing when trying to get the shallow dependencies).
Reviewed By: yungsters
Differential Revision: D2810534
fb-gh-sync-id: f2733382f4a2619e22bdf1163aa4180694fff9f8
Summary:
Current default value of ProgressBarAndroid's styleAttr is "Large" which sets the ProgressBar's style to [Widget_ProgressBar_Large](http://developer.android.com/reference/android/R.style.html#Widget_ProgressBar_Large) at native side. But large is not the default style for the native side ProgressBar.
For example, the size of the ProgressBar is 48dip for default style, but 76dip for large and 16dip for small as in the Material themes. Although the size of ProgressBarAndroid could be set in JS, it'll be better to have the same default style as in native side themes.
My PR adds a "Normal" value for styleAttr prop and makes it the default value.
Closes https://github.com/facebook/react-native/pull/4974
Reviewed By: svcscm
Differential Revision: D2811229
Pulled By: bestander
fb-gh-sync-id: 087f68d1919fe933d86e5194112bf7a5f5b3f3c6
Aleksei Androsov
Morgan Pretty
Sebastian Gronewold
Martín Bigio
Janic Duplessis
Andreas Drivenes
Chirag
Ian Wang
Ben
Satyajit Sahoo
BerndWessels
Martin Konicek
Martin Konicek
trave7er
Aaron Chiu
Olivier Notteghem
Nick Lockwood
Seth Ladd
Jiajie Zhu
Andrew Jack
Oleg Lokhvitsky
Christoph Pojer
David Aurelio
Dave Miller
Lukas Benes
Andrei Coman
realaboo
Tadeu Zagallo
Pieter De Baets