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:
…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:
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:
Previously <TextInput>'s onContentSizeChange event fires very rearly, usually just once after initial layout. This diff fixed that.
I also considered to a bunch of another things to get the native notification, but I found that overriding `onTextChanged` is the most reliable, easy and effitient way to implement this.
I tried/considered:
* onLayout (does not fire)
* OnPreDrawListener (fires to often)
* OnGlobalLayoutListener (does not fire)
* OnLayoutChangeListener (does not fire)
* isLayoutRequested (too hacky)
(I also fixed the <AutoExpandingTextInput> demo to illustrate the fix.)
And just heads up, we will remove `contentSize` info from `onChange` event very soon.
GH issue: https://github.com/facebook/react-native/issues/11692
Reviewed By: achen1
Differential Revision: D5132589
fbshipit-source-id: e7edbd8dc5ae891a6f4a87b51d9450b8c6ce4a1e
Summary:
The new implementation of z-index did not handle touches properly. This fixes it by using the mapped child index like we do in `getChildDrawingOrder` in `TouchTargetHelper`.
**Test plan**
Tested that touchables work properly inside sticky headers (it uses z-index) on Android.
Closes https://github.com/facebook/react-native/pull/13705
Reviewed By: AaaChiuuu
Differential Revision: D4987964
Pulled By: sahrens
fbshipit-source-id: 165f98e23d2f304c4dc87f536c22b68a8923d806
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: D4680300
fbshipit-source-id: 337836deef0767e5f26350f5a8ce73adb4146a02
Summary:
Adds functionality to be able to disable saving of form data and thereby disabling autocomplete in webview on Android. Can be used as a workaround for #13241
Manual testing that autocomplete is disabled when the property is set to true, and still enabled when it is unset or set to false.
Closes https://github.com/facebook/react-native/pull/13271
Differential Revision: D4858899
Pulled By: ericvicenti
fbshipit-source-id: 62738b0685e4c1958c8a32e184fa2fe4f711b336
Summary:
Use `getChildDrawingOrder` instead of reordering views. The old implementation didn't work properly when `removeClippedSubviews` was enabled and this one should have better performance since we don't play with the view hierarchy at all.
This fixes weird bugs with sticky headers in `SectionList` and allows removing the hack that disabled `removeClippedSubviews` when using sticky section headers.
**Test plan**
Tested using the SectionList and ListViewPaging examples that use sticky headers which uses z-index.
Closes https://github.com/facebook/react-native/pull/13105
Reviewed By: sahrens
Differential Revision: D4765869
Pulled By: achen1
fbshipit-source-id: be3c824658a3ce965b6e7324ad95c77cbd8a86ae
Summary:
Inspired by #13191
Creating a test app with spannable `TextView`, and observe the text width/height
Closes https://github.com/facebook/react-native/pull/13203
Differential Revision: D4795809
Pulled By: hramos
fbshipit-source-id: a7c6845abe7472dc7ad2f1f978a20d02fe49eda8
Summary:
Bug in Android https://code.google.com/p/android/issues/detail?id=33868 causes the RN catalyst instrumentation test to fail with
```
java.lang.ArrayIndexOutOfBoundsException: length=253; index=-1
at android.text.StaticLayout.calculateEllipsis(StaticLayout.java:667)
at android.text.StaticLayout.out(StaticLayout.java:631)
at android.text.StaticLayout.generate(StaticLayout.java:423)
...
```
The fix is to set singleLine to true when there is only one line of text
Reviewed By: AaaChiuuu
Differential Revision: D4562000
fbshipit-source-id: 84248e3982063b767e8b0465effe2321b54a7fa2
Summary:
See https://github.com/facebook/react-native/issues/10845
onSizeChanged is enqueueing a runnable from the ui thread that references a shadow view by id on the native modules thread. Since the shadow thread 'runs ahead' of the UI thread (e.g. it has a newer state of the world than the UI thread), this isn't safe. By the time that code block runs, it's possible that an update from JS has already removed that view from the shadow hierarchy (a change which would then propagate to the native hierarchy on the UI thread).
Reviewed By: AaaChiuuu
Differential Revision: D4706521
fbshipit-source-id: 0915f081068709b895f70b2edce12163b39e5456
Summary:
Display.getCurrentSizeRange() doesn't include the size of the status
bar, so Modal windows on Android have a gap in the bottom that is the
same size as the status bar. This checks the current theme and adds the
size of status bar to the modal window height if necessary.
**Test plan (required)**
Run a React Native app on Android with a theme that doesn't show status bar and launch a modal dialog. See issue #11872 for an example.
Closes https://github.com/facebook/react-native/pull/11928
Differential Revision: D4695847
fbshipit-source-id: 9fafc2b5040e2f58d562c9cc4cd4d6d87b0df2a3
Summary:
PR for option to set mixed content mode in Webview(Android) for issue #8460
Closes https://github.com/facebook/react-native/pull/12314
Differential Revision: D4663084
Pulled By: lacker
fbshipit-source-id: 0e40ea463739166311ddcb7887ff6d0289369637
Summary:
Fixes#11592
This bug was seen on a Galaxy S4 running Android 4.4.2. On this device, Android's `Layout.getDesiredWidth` method doesn't correctly measure text that contains unicode emoticons. It appears to think the emoticons take up 0 space.
Setting ANTI_ALIAS_FLAG in the TextPaint's constructor instead of setting it later with setFlags works around the Android bug.
**Test plan (required)**
My team uses this fix in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/12690
Differential Revision: D4673649
Pulled By: mkonicek
fbshipit-source-id: 535f371281927bfff5d8b42966496bc8daf30045
Summary:
This adds blurRadius support for <Image>, similar to iOS.
The heavy-lifting was done by lambdapioneer in the stack of diffs ending with
D3924013, we're just patching this in.
Two notes: we might need to apply two postprocessors going forward, will tackle
that in a separate diff, so we can ship this asap.
However, we need a new version of fresco to be released in order
to ship this.
Reviewed By: lexs
Differential Revision: D3936438
fbshipit-source-id: 353bf1f1120ebd5f4f8266c5a20188b41478a741
Summary:
This PR fixes#6332
The issue is that Android Framework will return the same drawable instance for all requests if they request for the same resource. So the changes on the drawable instance will affect all users(`TextInput` in this case). The solution is very easy, call `mutate()` before change it will get a new drawable instance which make sure the change doesn't affect other users.
Closes https://github.com/facebook/react-native/pull/12493
Differential Revision: D4620034
Pulled By: astreet
fbshipit-source-id: a7b10fbc7447e01132b7ca0e1f78413796493e07
Summary:
This PR will:
- add missing documentation for `caretHidden` prop to the docs
- add `caretHidden` prop implementation for Android
I noticed this by accident when looking at `RCTTextFieldManager.m` and there is `RCT_EXPORT_VIEW_PROPERTY(caretHidden, BOOL)` which hides caret on iOS. Then I realised that the docs were missing for this prop and implementation on Android side :)
Render `TextInput` with prop `caretHidden`. After this caret is not visible anymore.
`<TextInput style={styles.input} caretHidden />`
If you omit the prop then caret is visible again
`<TextInput style={styles.input} />`
Closes https://github.com/facebook/react-native/pull/11863
Differential Revision: D4448402
fbshipit-source-id: 456e1df3e2cbb8af32540d2c7a8f4e7da219f5c3
Summary:
A copy of https://github.com/facebook/react-native/pull/7791 because of our very imperfect tools that mirror the changes from pull requests in the fb monorepo. The internal Phabricator revision for #7791 is in an 'abandoned' state (by foghina probably because of changing teams) and Phabricator doesn't allow me to claim that revision and merge it. Therefore I'm creating a new one.
(It's not foghina's fault, no one probably knew about this "abandoned Phabricator revision" edge case, don't remember we hit it before.)
Will try to keep attribution (git blame) to rigdern when merging.
Closes https://github.com/facebook/react-native/pull/12448
Differential Revision: D4584743
Pulled By: mkonicek
fbshipit-source-id: 66e5b88134fca1980adc4cd8a2ff17c42e10022c
Summary: We're logging all console logs from webview. This strips console logging for non debug builds
Reviewed By: AaaChiuuu
Differential Revision: D4578071
fbshipit-source-id: 79b21012a6ef215eb35701911662a720cb6be280
Summary:
This matches the behavior on iOS, there was no way before to change the cursor color per input, it was only possible to change it globally via the theme. Ideally cursor color and selection color would be 2 different props but I think this is better than what we have (and matches iOS).
Sadly there is no api to change it pragmatically (only possible via xml) so this uses reflection and can easily break so it is wrapped in a try catch to avoid crashes. I think it is better to just silently fail in this case. Definetly not super happy about the solution but I think it's worth adding since it is possible to do it natively using xml so it would suck not to be able to do it in RN.
**Test plan**
Tested that the cursor has the same color as before the change when not setting the prop and that it gets the selectionColor color when set.
Closes https://github.com/facebook/react-native/pull/12280
Differential Revision: D4571858
Pulled By: astreet
fbshipit-source-id: 7dca2db33a0a4eecb6115b45155549b1265ffbed
Summary:
Corresponding iOS PR: https://github.com/facebook/react-native/pull/11002
This adds an onScroll event to TextInput which is useful when a multiline TextInput has so much content that it is scrollable.
**Test plan (required)**
Verified the event works properly in a test app. Also, my team uses this event in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/11001
Differential Revision: D4220941
Pulled By: mkonicek
fbshipit-source-id: 7e420579946f2ae840c9e1fcdc8afab68007da17
Summary:
This prop exposes the functionality provided by Android ScrollView's setOverScrollMode method.
One interesting thing to note is that, if you were to read the Android docs, you would think that the value "always" is the default over scroll mode. However, the docs are incorrect and "always-if-content-scrolls" is actually the default value (http://stackoverflow.com/a/27116306).
**Test plan (required)**
Verified this change in a test app. Also, our team uses this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/10905
Differential Revision: D4500957
Pulled By: mkonicek
fbshipit-source-id: 873eba38183defba133c228e0c1038efa83297d3
Summary: `RecyclerViewBackedScrollView` was added a long time ago to work around the scroll-back-when-data-is-added bug, but that has now been fixed directly in the `ScrollView` (`ReactScrollView.java`) in open source and internally.
Reviewed By: astreet
Differential Revision: D4482105
fbshipit-source-id: 208f21f00045d5c5a83b74ad69b3db6fa63391d7
Summary:
**Motivation**
Ability to customize slider colors is desirable to match the brand. Currently iOS allows using images for slider parts, but android doesn't have any customization options. This PR adds support for customizing `thumbTintColor`, `trackTintColor` and `progressTintColor`.
**Test plan (required)**
Run UIExplorer example with the changes and verify everything works fine.
cc brentvatne
Closes https://github.com/facebook/react-native/pull/11946
Differential Revision: D4427474
fbshipit-source-id: ec3a38db600bac6108691a4cfa15e2409143b9f3
Summary:
This is a followup for https://github.com/facebook/react-native/pull/12088 and implements the scrolling to end on Android natively rather than sending a large scroll offset from JS.
This turned out to be an OK amount of code, and some reduction in the amount of JavaScript. The only part I'm not particularly happy about is:
```
// ScrollView always has one child - the scrollable area
int bottom = scrollView.getChildAt(0).getHeight() + scrollView.getPaddingBottom();
```
According to multiple sources (e.g. [this SO answer](http://stackoverflow.com/questions/3609297/android-total-height-of-scrollview)) it is the way to get the total size of the scrollable area, similar to`scrollView.contentSize` on iOS but more ugly and relying on the fact the ScrollView always has a single child (hopefully this won't change in future versions of Android).
An alternative is:
```
View lastChild = scrollLayout.getChildAt(scrollLayout.getChildCount() - 1);
int bottom = lastChild.getBottom() + scrollLayout.getPadd
Closes https://github.com/facebook/react-native/pull/12101
Differential Revision: D4481523
Pulled By: mkonicek
fbshipit-source-id: 8c7967a0b9e06890c1e1ea70ad573c6eceb03daf
