Summary:
I am using ReactNative in a hybrid App.
We have a setup like so:
Native Navigation Controller
Native Tab Controller
Native View Controller wrapping React
React Navigation Controller
React View Controller 1
React View Controller 2
Native View Controller 2.
When I pop Native View Controller 2 off the Navigation stack, I get a seg fault on this line:
NSUInteger indexOfFrom = [_currentViews indexOfObject:fromController.navItem];
I believe what's happening:
Your code is listening to Nav Controller transitions, assuming that they are all from React Native Nav Controllers.
You are catching this one instead, which is actually a Native Nav Controller transition.
You start trying to access the pushed/popped view controllers as if they were react native view controllers.
In this case, the view controllers are not react native -> no navItem field -> seg fault.
Solution: if we are catching this transition but it isn't from our react native nav controller, just
Closes https://github.com/facebook/react-native/pull/5495
Reviewed By: svcscm
Differential Revision: D2857473
Pulled By: nicklockwood
fb-gh-sync-id: cc7f0a16e2e0cea56ca9e49bcb87db4ebd3a0905
Summary:
public
This is needed to bring numerical module IDs back.
The numerical ID of the main module will always be `0` and is therefore of no use when used as conditional. We have to pass on the name, which will be preserved, when requesting transform options.
Reviewed By: martinbigio
Differential Revision: D2855106
fb-gh-sync-id: f9bc40e753b1b283ce0b00068e3c9964a541ad9b
Summary:
public
The reverted change doesn’t play nice with inline requires, let’s revert it for now.
I will bring it back after fixing it or adapting inline requires
Reviewed By: martinbigio
Differential Revision: D2854771
fb-gh-sync-id: 32fdbf8ad51240a9075b26502decb6328eed4b29
Summary:
I talked about this a bunch before. node-haste2 will resolve this issue. Right now node-haste1 looks into eevery single node_module recursively even though we only need to look into a finite-set of them. Some node_modules are huge so it takes a long time. haste2 doesn't eagerly look into node_modules so it doesn't have this issue. This diff blacklists the modules from node-haste but since we use the `resolve` npm module as a fallback we'll still be able to require them.
public
Reviewed By: kassens
Differential Revision: D2852384
fb-gh-sync-id: 113f1bd9c66fcd712c2549a7110a3e752b0e4a69
Summary:
public
Previously, `<Image>` elements embedded inside `<Text>` ignored all style attributes and props apart from `source`. Now, the `width`, `height` and `resizeMode` styles are observed. I've also added a transparent placeholder to be displayed while the image is loading, to prevent the layout from changing after the image has loaded.
Reviewed By: javache
Differential Revision: D2838659
fb-gh-sync-id: c27f9685b6976705ac2b24075922b2bf247e06ba
Summary:
public
Fix https://github.com/facebook/react-native/issues/5465
Instead of returning null when we fail to parse the Uri, just return an empty Uri which somewhat hides the problem but does prevent the crash
Reviewed By: mkonicek
Differential Revision: D2854902
fb-gh-sync-id: 71265d5e52302e174b898af5be25ac698abcf9ab
Summary:
public
This diff fixes a bug in RCTScreenScale() on iPhone6+. The issue was due to the fact that the iPhone6+'s virtual screen resolution of 414x736 points 3x resolution (1242x2208 pixels) does not match its actual screen resolution, which is 1080p (1080x1920 pixels).
I did not realize that `[UIScreen mainScreen].nativeBounds` reports the *actual* resolution, not the virtual resolution, and was dividing by the virtual scale (3.0) instead of the actual native scale factor (2.6).
This only affects iPhone6+, because for all other iOS devices, the virtual resolution matches the native resolution.
Reviewed By: milend
Differential Revision: D2854663
fb-gh-sync-id: bce8965a151e2f005a02a5f6b54f259d01b9ab12
Summary:
Instead of using `UINT32_MAX` in C++ code, use `std::numeric_limits<uint32_t>::max()`. The `UINT32_MAX` macro is not available in all compilation setups
Closes https://github.com/facebook/react-native/pull/5481
Reviewed By: svcscm
Differential Revision: D2854545
Pulled By: androidtrunkagent
fb-gh-sync-id: 00a70b429c78bcf120866bb59fae2ffe6330a910
Summary:
This NPEs because the layout is null if the TextView has recently
changed. However, this also means that the TextView hasn't been laid out yet, so
the default TextView tag is correct.
public
Reviewed By: oli
Differential Revision: D2848412
fb-gh-sync-id: 5faf793d17f50283c153dc0d43fb717e8764cb7d
Summary:
public
Adds two feature to the require implementation for unbundled code:
- Ports Systrace from `require.js`
- Prevents already loaded modules from being overwritten by repeated calls to `nativeRequire` with the same ID
Reviewed By: martinbigio
Differential Revision: D2850345
fb-gh-sync-id: 122e2d5d4a64b2e868d4cf6e5079810f59b1db18
Summary:
public
Although the feature itself is gated, once the user is on the experiment we want to make sure hot loading starts disabled up until the feature is enabled through the dev menu.
Reviewed By: javache
Differential Revision: D2850070
fb-gh-sync-id: 66e69e152806d3bb01985afe20827e3b9cffeb41
Summary:
public
This adds the ability to load “unbundles” in RN android apps. Unbundles are created by invoking the packager with the `unbundle` command rather than `bundle`.
The code detects usage of an “unbundle” by checking for the existence of a specific asset.
Reviewed By: astreet
Differential Revision: D2739596
fb-gh-sync-id: d0813c003fe0fa7b47798b970f56707079bfa5d7
Summary:
change `setTextAlign` and `setTextAlignVertical` to receive argument of type `String` (the same as in `StyleSheet`), so that native props and stylesheet props are calling the same ReactMethod
- add demo (may not be necessary)
Closes https://github.com/facebook/react-native/pull/4481
Reviewed By: svcscm
Differential Revision: D2823456
Pulled By: mkonicek
fb-gh-sync-id: 349d17549f419b5bdc001d70b583423ade06bfe8
Summary:
Ok, so this started as fixing #5273 but ended up getting a little more complicated. 😄
Currently, AlertIOS has the following API:
* `alert(title, message, buttons, type)`
* `prompt(title, defaultValue, buttons, callback)`
I've changed the API to look like the following:
* `alert(title, message, callbackOrButtons)`
* `prompt(title, message, callbackOrButtons, type, defaultValue)`
I know that breaking changes are a big deal, but I find the current alert API to be fairly inconsistent and unnecessarily confusing. I'll try to justify my changes one by one:
1. Currently `type` is an optional parameter of `alert`. However, the only reason to change the alert type from the default is in order to create one of the input dialogs (text, password or username/password). So we're in a weird state where if you want a normal text input, you use `prompt`, but if you want a password input you use `alert` with the 'secure-text' type. I've moved `type` to `prompt` so all text input is now done with `pro
Closes https://github.com/facebook/react-native/pull/5286
Reviewed By: svcscm
Differential Revision: D2850400
Pulled By: androidtrunkagent
fb-gh-sync-id: 2986cfa2266225df7e4dcd703fce1e322c12b816
Summary:
public
Since the combination of node and haste modules (and modules that can be required as both node and haste module) can lead to situations where it’s impossible to decide an unambiguous module identifier, this diff switches all module ids to integers. Each integer maps to an absolute path to a JS file on disk.
We also had a problem, where haste modules outside and inside node_modules could end up with the same module identifier.
This problem has not manifested yet, because the last definition of a module wins. It becomes a problem when writing file-based unbundle modules to disk: the same file might be written to concurrently, leading to invalid code.
Using indexed modules will also help indexed file unbundles, as we can encode module IDs as integers rather than scanning string IDs.
Reviewed By: martinbigio
Differential Revision: D2842418
fb-gh-sync-id: 97addd28e964ac5f2b5081dcd3f36124d2864df8
Summary:
public
When we were debugging in the main window JS context in Chrome, the global environment had to be tweaked so that DOM features wouldn’t be detected.
Since we switched to debugging within a web worker, we don’t need to do this tweaks any more.
Reviewed By: bestander
Differential Revision: D2850239
fb-gh-sync-id: 886f2f7ac5c579c3fd4a424d5341bc6bc0432c0d
Summary:
Making the default people see when they look at the module the Promise based version
public
Reviewed By: davidaurelio
Differential Revision: D2850048
fb-gh-sync-id: e0815983ed798c202047cb071e65ce63a52fd1af
Summary:
public
We had a bug a few weeks ago which caused transform errors not to be shown properly. The problem was on this piece of code, so lets unit test it.
Reviewed By: davidaurelio
Differential Revision: D2849990
fb-gh-sync-id: 9f6bb8a8b7d59bbaa3577c29cee37fb23a50d66f
Summary:
There's a long standing issue on open source (https://github.com/facebook/react-native/issues/4968). Until someone gets some free bandwidth to fix it lets at the very least improve the error message to guide users to the issue and suggest workarounds.
public
Reviewed By: mkonicek
Differential Revision: D2849051
fb-gh-sync-id: ef7913442ceabcab2076141bd13ab1ceeb529759
Summary:
public
This is the first module moving to the new model of working with Promises.
We now warn on uses of callback version. At some point we will remove that.
Reviewed By: davidaurelio
Differential Revision: D2849811
fb-gh-sync-id: 8a31924cc2b438efc58f3ad22d5f27c273563472
Summary:
At the moment we have to disable strict mode for the transform-es2015-modules-commonjs because strict mode leaks to the global scope and breaks the bridge. It was due to the way the polyfills were bundled in the package. To fix it, I wrapped the polyfill modules in an IIFE. Then when strict mode was enabled some polyfills were broken due to strict mode errors so that was fixed too. Also removed the IIFE from the polyfills that included one.
This diff doesn't enable the strict mode transform since some internal facebook modules depend on it not being enabled. When #5214 lands we could make the default babel config shipped with OSS react-native use strict mode modules and facebook could just modify the babel config to disable it if needed.
This will allow removing `"strict": false` from https://github.com/facebook/react-native/blob/master/packager/react-packager/.babelrc#L16Fixes#5316
Closes https://github.com/facebook/react-native/pull/5422
Reviewed By: svcscm
Differential Revision: D2846422
Pulled By: davidaurelio
fb-gh-sync-id: a3e2f8909aa87dabab2b872c61b887e80220fb56
Chirag
Arjun Komath
Christopher Dro
Konstantin Raev
DougBanksPersonal
sunnylqm
Elliot Hesp
Dale Jefferson
David Aurelio
Christoph Pojer
Nick Lockwood
Martin Konicek
Dave Miller
Martin Konicek
Martín Bigio
Moz Morris
David Aurelio
Andrei Coman
Martin Kralik
tfallon@mail.depaul.edu
Sokovikov
Hedger Wang
Huang Yu
Kyle Corbitt
Janic Duplessis