Summary:
I've found that when switching between tabs that each have ScrollViews, sometimes `emitScrollEvent` fires without a `contentView`, which causes the following crash:
```
`D/AndroidRuntime(24496): Shutting down VM
E/AndroidRuntime(24496): FATAL EXCEPTION: main
E/AndroidRuntime(24496): Process: com.listexp, PID: 24496
E/AndroidRuntime(24496): java.lang.NullPointerException: Attempt to invoke virtual method 'int android.view.View.getWidth()' on a null object reference
E/AndroidRuntime(24496): at com.facebook.react.views.scroll.ReactScrollViewHelper.emitScrollEvent(ReactScrollViewHelper.java:59)
E/AndroidRuntime(24496): at com.facebook.react.views.scroll.ReactScrollViewHelper.emitScrollMomentumEndEvent(ReactScrollViewHelper.java:46)
E/AndroidRuntime(24496): at com.facebook.react.views.scroll.ReactScrollView$1.run(ReactScrollView.java:159)
E/AndroidRuntime(24496): at android.os.Handler.handleCallback(Handler.java:739)
E/AndroidRuntime(24496): at android.os.Handler.disp
Closes https://github.com/facebook/react-native/pull/5561
Reviewed By: svcscm
Differential Revision: D2876385
Pulled By: androidtrunkagent
fb-gh-sync-id: 33406eaa96352d5adae857088da09fb446b68440
Summary:
Catalyst is the old project name. Rename a few files.
public
Reviewed By: bestander
Differential Revision: D2859553
fb-gh-sync-id: 65a87cc7bcc22f20326971becec02aa1c573e5b9
Summary:
In Android, Fresco's default rounding corners support mode is BITMAP_ONLY which doesn't work in all cases (such as animated GIF's, some scale types, etc.).
Specifying the new "overlayColor" property on an Image will cause Fresco to switch to the other rounding corners mode, OVERLAY_COLOR, and will draw rounded corners by overlaying the solid color specified.
Fresco's behaviour is explained here: http://frescolib.org/docs/rounded-corners-and-circles.html
Closes https://github.com/facebook/react-native/pull/5366
Reviewed By: svcscm
Differential Revision: D2854696
Pulled By: mkonicek
fb-gh-sync-id: 251701ee8a64acbfc22694e9d4661c40eef75725
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:
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:
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:
In Android, when displaying an image with local uri, react-native seems to fail to rotate it according to Exif.
Images on iOS seem like they are being rotated, so this does not seem like a consistent behaviour.
For instance, when taking a picture on a Samsung Galaxy S6, and displaying it with code like below, image does not have a correct orientation.
```javascript
<Image source={{uri: "file:/storage/emulated/0/DCIM/Camera/20160106_171628.jpg"}} />
```
<img src="https://cloud.githubusercontent.com/assets/4534323/12403776/aa5075cc-be36-11e5-885a-7be8236a7fdd.jpg" width=200 />
As seen [here](http://frescolib.org/docs/resizing-rotating.html#auto-rotation), Fresco can do all the work for us (hence this very simple PR).
I tested it on Samsung Galaxy S6 (lollipop), Galaxy S4 (kitkat) and Moto X Style (marshmallow).
I have written an example that fetches images uri from the Java side and then display them in a list view.
[Here](https://github.com/Almouro/rn-camera-roll/tree/use-react-native-master
Closes https://github.com/facebook/react-native/pull/5386
Reviewed By: svcscm
Differential Revision: D2839551
Pulled By: androidtrunkagent
fb-gh-sync-id: 6f0f2f301f263fd142dfbeba6a53f8c482fb5cb0
Summary:
Moved setElevation from ReactViewManager to BaseViewManager. This allows
setting elevation on any type of view such as Toolbar for exemple.
Closes https://github.com/facebook/react-native/pull/5292
Reviewed By: svcscm
Differential Revision: D2837415
Pulled By: androidtrunkagent
fb-gh-sync-id: a5aa7abd95b99303d312cd9c2414539335540925
Summary:
With the numeric keyboard now being an actual numeric keyboard (before
it was actually phone-pad), we need a proper phone-pad keyboard as well.
public
Reviewed By: dmmiller
Differential Revision: D2830707
fb-gh-sync-id: 80a1d314eac730e691de73a31342c014a2fa5ba6
Summary:
The offset is cached so it doesn't need to calculate the entire height on each scroll, but the cached value was being thrown away when you scroll up -- this fixes that. Found this because it was breaking an infinite scroll view that depended on the contentOffset.y value reported from onScroll.
Closes https://github.com/facebook/react-native/pull/5278
Reviewed By: svcscm
Differential Revision: D2827556
Pulled By: dmmiller
fb-gh-sync-id: 0897b89de427cada7389113991444f57c970f980
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:
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
Summary:
public
Add an onSelectionChange method to TextInput that works on Android same as iOS
Reviewed By: andreicoman11
Differential Revision: D2780131
fb-gh-sync-id: 9b3b8fbd9ea653d43e3107a338e4bc08bde2e8c6
Summary:
The annotation processor finds subclasses of ViewManager and ShadowNode and generates classes that can both provide a mapping of property names to their type as well as a way of setting these properties.
This avoids having to do reflection to find the properties.
The annotation processor is currently not working when building with Gradle.
public
Reviewed By: astreet
Differential Revision: D2748958
fb-gh-sync-id: ded5b072d236ebf19fb43eaf704fc7f221a82c26
Summary:
Moves ReactProp and ReactPropGroup to `com.facebook.react.uimanager.annotations`. This is needed
so that future annotation processor can run on code inside the com.facebook.react.uimanager package.
public
Reviewed By: astreet
Differential Revision: D2754842
fb-gh-sync-id: 3808c3e3f6c45e5897ecab88cd4175573c0c24e6
Summary:
2 things that I want to clarify / ask for feedback:
* do we really need to make sure we're running on the UI thread? I guess `onPageStarted` maybe already runs there? Couldnt find anything [here](http://developer.android.com/reference/android/webkit/WebView.html) though
* everytime a page starts we re-enable debugging -- it's a bit useless but I also don't think it's a huge problem, as debugging should only be enabled in dev
Relates to issue #4857, where we switched debugging off as, in some circumstances, it would crash the application as debugging was invoked outside the UI thread.
Closes https://github.com/facebook/react-native/pull/5071
Reviewed By: svcscm
Differential Revision: D2803649
Pulled By: astreet
fb-gh-sync-id: 523d3b442b196d6c54b14ba0c2b29601095c3363
Summary:
This is already open-source on iOS, albeit badly documented. Now Android too!
Tested in open source by adding a `import com.facebook.react.ARTPackage;` and `.addPackage(new ARTPackage())` to UIExplorerActivity.java, running
```
./gradlew :Examples:UIExplorer:android:app:installDebug
```
and copying VectorWidget into the UIExplorer JS code as described in http://browniefed.com/blog/2015/05/03/getting-react-art-running-on-react-native/.
public
Reviewed By: foghina
Differential Revision: D2700481
fb-gh-sync-id: 2a5308b022869ecc1868a46dbecf397581ddbe04
Summary:
Was developing on a WebView and couldnt get it to run. Turns out its JS code mostly depends on `localStorage` and I realized it wasnt turned on in RN. This PR adds a prop, similar to `javascriptEnabledAndroid` to be able to turn DOM storage on / off.
TBH I dont really know how it works on IOS, so I created an android specific thingy. I assume DOM storage is enabled by default on IOS.
Closes https://github.com/facebook/react-native/pull/5065
Reviewed By: svcscm
Differential Revision: D2797735
Pulled By: androidtrunkagent
fb-gh-sync-id: cd60cfa4d24d80fb82e4f54f387a4517a99e75ab
Summary:
This PR adds a contentInsetStart and a contentInsetEnd property to ToolbarAndroid, allowing offsetting Toolbar contents to different keylines
Closes https://github.com/facebook/react-native/pull/4699
Reviewed By: svcscm
Differential Revision: D2759294
Pulled By: mkonicek
fb-gh-sync-id: f22aa255f07929ad7a99ac7568981d35e848065b
Summary:
`WebView.getUrl()` doesn't return the correct value in WebView callbacks
(e.g. `onPageFinished`).
For example, when navigating to a URL, we report that loading finished,
but still with the old URL. This diff fixes that.
public
Reviewed By: andreicoman11
Differential Revision: D2769597
fb-gh-sync-id: f14bdd405290469ac0a20d0fb89aa2a27d33e758
Summary:
Keep `WebView.android.js` and `WebView.ios.js`, there are
some small differences. Use the same example on both platforms.
public
Reviewed By: bestander
Differential Revision: D2769446
fb-gh-sync-id: be3d0afcbfd6ddcbaa49f70555063b3081ba03cb
Summary:
public
This adds support for
onScrollBeginDrag/End
onMomentumScrolBegin/End
Reviewed By: astreet
Differential Revision: D2739035
fb-gh-sync-id: 2a49d1df54e5f5cd82008bdb0ffde0881ba39aff
Summary:
If border radius is not set or is zero, then elevation will not
work properly. This bug seems to have been introduced when the
style in facebook/react-native#4180 was modified slightly to
produce commit b65f1f2234.
Closes https://github.com/facebook/react-native/pull/4555
Reviewed By: svcscm
Differential Revision: D2741203
Pulled By: mkonicek
fb-gh-sync-id: f4ee9ccdfc64374d58824a6e988409ac2b7532a4
Summary: public Right now there is no centralized place to initialize CallerContext for Fresco. It should probably go through FrescoModule, but currently it's going through ReactImageManager, and thus unavailable to FlatUIImplementation, that doesn't use ReactImageManager. So this diff provides public getters for CallerContext (and DraweeControllerBuilder) in ReactViewManager. This is hacky and generally should not be needed, but without it groups don't have correct CallerContext set.
Reviewed By: kmagiera, astreet
Differential Revision: D2569372
fb-gh-sync-id: 2622e69c64bfebfc575deb330ee77e0139efb7ec
Summary: ~~This is a WIP, just finished the first bit and wanted to get some feedback to see if this approach seems appropriate, as I haven't done a lot of Android development.~~
Looks ready for review now.
Closes https://github.com/facebook/react-native/pull/3791
Reviewed By: svcscm
Differential Revision: D2672262
Pulled By: mkonicek
fb-gh-sync-id: 1e8f1cc6658fb719a68f7da455f30a7c9b1db730
