Summary:
iOS return all 0 metrics for <Text> inside <Text>, which results immediate `onPressOut` event on press in. These kind of response should be ignored
this solved issue #11462
Closes https://github.com/facebook/react-native/pull/11530
Differential Revision: D4541452
Pulled By: ericvicenti
fbshipit-source-id: efd7bf1b380b1aecf7301b23f1fbd5a77a9e9095
Summary:
findNodeHandle is considered an internal module. The one to use is ReactNative.findNodeHandle. We need to rely on this because we will have two different renderers and we need the renderers to inject themselves with findNodeHandle before it is used.
I use ReactNative.findNodeHandle from inside the module because I think this leads to a cycle somewhere or might not play well with inline require otherwise.
There is also one in UIManager but that is definitely a cycle so I'm going to try to avoid that one.
Reviewed By: spicyj, bvaughn
Differential Revision: D4533911
fbshipit-source-id: f771641ea5c5366ccbaff68c42202fa6f8c18cb3
Summary: We deprecated `transformMatrix` and `decomposedMatrix` in D3239960 10 months ago. This revision finally removes remains of this functionality from native code.
Reviewed By: mmmulani
Differential Revision: D4515760
fbshipit-source-id: b4d5b7e834ac4a775f4992b28270b4ff961889a6
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:
Added a note to the `refreshControl` prop on ScrollView to call out that the prop only works for vertical ScrollViews.
Fixes#12139
Closes https://github.com/facebook/react-native/pull/12150
Differential Revision: D4508796
Pulled By: mkonicek
fbshipit-source-id: 8e71692f29ee175e32177c3a26a4ed2e8d14f139
Summary: Exports Flow types for the props related to accessibility.
Reviewed By: fkgozali
Differential Revision: D4498562
fbshipit-source-id: 2fb6e78d4ceaf9f26b6ea88d515b7b28f570de52
Summary:
To update the documentation. Works on iOS, so I assume this is the same on Android.
Closes https://github.com/facebook/react-native/pull/11575
Differential Revision: D4494464
Pulled By: mkonicek
fbshipit-source-id: c7480d39ed0849401efaa080948c14fa0cb7a08d
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:
Explain the **motivation** for making this change. What existing problem does the pull request solve?
I had tried fixing a broken link in a previous commit (#11453). My commit was merged, but it did not resolve the underlying problem. I have looked into how links should be formed for the docs and have fixed the original problem as well as updated all other links to be consistent.
Previous link formats:
- /docs/sample.html <-- broken link
- sample.html <-- broken link
- https://facebook.github.io/react-native/docs/sample.html <-- works
- /react-native/docs/sample.html <-- works
- docs/sample.html <-- works (permalink format)
This PR updates all links to the permalink format.
**Test plan (required)**
I ran the website locally and manually tested half of the links in each category. They all worked.
```
$ cd website
$ npm install && npm start
```
Closes https://github.com/facebook/react-native/pull/12064
Differential Revision: D4489153
Pulled By: mkonicek
fbshipit-source-id: bf0231d941ba147317595c3b3466dc579a887169
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
Summary: `'invariant'` can only be resolved by chance if node modules have been installed with npm3 or yarn, as it is a transitive dependency of `babel-traverse`. This changes the import to the direct dependency `fbjs/lib/invariant`.
Reviewed By: jeanlauliac, astreet
Differential Revision: D4462471
fbshipit-source-id: 5c841845012ed22a7c6264d46326a47807948513
Summary:
Following the PR https://github.com/facebook/react-native/pull/6195, this adds a `HEIGHT` constant on `StatusBar` for iOS.
Combined with `statusBarFrameDidChange` and `statusBarFrameWillChange` StatusBar native events, it solves various problems with In-Call cellar bar / Location bar / others 40pt status bars, and offers a correct `keyboardVerticalOffset` value for the KeyboardAvoidingView component.
Closes https://github.com/facebook/react-native/pull/12041
Differential Revision: D4450924
Pulled By: hramos
fbshipit-source-id: 664798260f4226140f3fa3f9222a415a305d0d78
Summary: Since we don't support this, we should throw early. Also tries to improve the error message when adding a node that doesn't have a YogaNode to a node that can't measure itself.
Reviewed By: andreicoman11
Differential Revision: D4421542
fbshipit-source-id: e0be8cdd763091145e5e6af2db91515f4d236b37
Summary:
Hi,
The (as of yet unreleased) commit 5537055bf8 added some ListView and ScrollView mocks, but they leave out the original properties passed into them, which broke some of my tests (e.g. by excluding some properties like `testID`, for example, from the render tree) and I assume might break others' as well.
This PR makes it so the ListView mock directly returns the scroll component (instead of wrapping it in a View), and has ListViewMock and ScrollViewMock pass their given properties through.
Closes https://github.com/facebook/react-native/pull/11847
Differential Revision: D4408497
Pulled By: sahrens
fbshipit-source-id: 7ec01c35d6b8efeb97761cddffdb4075d09c7d70
Summary:
This PR adds the `testID` prop to the `Button` component in order to allow end-to-end tests.
Closes https://github.com/facebook/react-native/pull/11526
Differential Revision: D4392137
Pulled By: ericvicenti
fbshipit-source-id: d3f864aacee319e520af226cd063edef452f6fc8
Summary:
Currently, < WebView > allows you to pass JS to execute within the view. This works great, but there currently is not a way to execute JS after the page is loaded. We needed this for our app.
We noticed that the WebView had messaging support added (see #9762) . Initially, this seemed like more than enough functionality for our use case - just write a function that's injected on initial load that accepts a message with JS, and `eval()` it. However, this broke once we realized that Content Security Policy can block the use of eval on pages. The native methods iOS provide to inject JS allow you to inject JS without CSP interfering. So, we just wrapped the native methods on iOS (and later Android) and it worked for our use case. The method injectJavaScript was born.
Now, after I wrote this code, I realized that #8798 exists and hadn't been merged because of a lack of tests. I commend what was done in #8798 as it sorely solves a problem (injecting JS after the initial load) and has more features than what I'
Closes https://github.com/facebook/react-native/pull/11358
Differential Revision: D4390425
fbshipit-source-id: 02813127f8cf60fd84229cb26eeea7f8922d03b3
Summary:
Bandaid for #7070. Until this is fixed, the docs should at least be honest the state they're in, so people don't have to go search and wonder.
Closes https://github.com/facebook/react-native/pull/11626
Differential Revision: D4366925
Pulled By: mkonicek
fbshipit-source-id: 082a8a9916ad0f8fbb2955cffbf61142fa2a98a1
Summary:
`Fake` components are simplified so snapshots are stable and reliable, and references are exported
so that interactions like `onRefresh` and `onScroll` can be called manually. Currently there is just
one global export for each class, but we may change this in the future if we need to manage multiple
`Fake`s of the same type in one render tree.
Right now these must be installed explicitly, but I might move them into `__mocks__` folders if it
seems reasonable to make them defaults.
Reviewed By: cpojer
Differential Revision: D4318207
fbshipit-source-id: 62802353a98b09ca1c80804ef7201ea63091f94a
Summary:
I'm pretty sure this is supposed to be "bottom" as opposed to "top", as it's the offset from the keyboard, which is at the bottom of the screen.
Closes https://github.com/facebook/react-native/pull/11446
Differential Revision: D4339957
Pulled By: lacker
fbshipit-source-id: 62dca544a0167704d76cd972c44570f277ea63aa
Summary:
cc brentvatne
potential reviewers mkonicek and kmagiera
**Motivation for making this change.**
The previous PR was closed : #11095 but the followup actions was never done
I reopened a really similar one so it get merged
RecyclerView is no more used at Facebook (according to previous PR)
According to brentvatne, their were two motivations for RecyclerView:
* ListView with ScrollView component used to bounce back on row insert, but this is now fixed
* This made possible to implement certain performance improvements, but the maintenance cost was not worth the risk
With RN 0.37, the actual code in React Native make the app crash:
- see #10560
I spend one hour investigating this and did also require brent time at exponent slack. I think other people are struggling too.
**Test plan**
<img width="708" alt="screen shot 2016-12-13 at 23 42 22" src="https://cloud.githubusercontent.com/assets/13785185/21162483/dbeb642e-c18d-11e6-9c32-1fe73f1826c1.png">
**Code formatting**
The
Closes https://github.com/facebook/react-native/pull/11445
Differential Revision: D4340640
Pulled By: mkonicek
fbshipit-source-id: 64c5cf060f2eb035d4d6199b30f0e73afc520180
Summary:
Android has a text API called breakStrategy for controlling how paragraphs are broken up into lines. For example, some modes support automatically hyphenating words so a word can be split across lines while others do not.
One source of complexity is that Android provides different defaults for `breakStrategy` for `TextView` vs `EditText`. `TextView`'s default is `BREAK_STRATEGY_HIGH_QUALITY` while `EditText`'s default is `BREAK_STRATEGY_SIMPLE`.
In addition to exposing `textBreakStrategy`, this change also fixes a couple of rendering glitches with `Text` and `TextInput`. `TextView` and `EditText` have different default values for `breakStrategy` and `hyphenationFrequency` than `StaticLayout`. Consequently, we were using different parameters for measuring and rendering. Whenever measuring and rendering parameters are inconsistent, it can result in visual glitches such as the text taking up too much space or being clipped.
This change fixes these inconsistencies by setting `breakStrategy` and `hyphenat
Closes https://github.com/facebook/react-native/pull/11007
Differential Revision: D4227495
Pulled By: lacker
fbshipit-source-id: c2d96bd0ddc7bd315fda016fb4f1b5108a2e35cf
Summary:
I was comparing `<TouchableOpacity>` to `UIButton` in iOS and it just doesn't feel native. The initial delay was fixed by https://github.com/facebook/react-native/pull/10866 but still there is a lag between button release and animation.
I'm also not sure what `_hideTimeout` was used for. When logging `touchableHandle*` events looks like `touchableHandleActivePressIn` is called first, then `touchableHandleActivePressOut` and then `touchableHandlePress`. Which means the fade in animation from `touchableHandleActivePressOut` was interrupted by `touchableHandlePress`.
Reviewed By: vjeux
Differential Revision: D4309789
fbshipit-source-id: b6d4df544952e11c2ade97d860531cbb2fada36b
Summary:
Right now, the ScrollView's keyboard hiding behavior is either all or nothing: Hide the keyboard on any tap, or do nothing ever. This PR introduces a third mode to keyboardShouldPersistTaps which is much closer to what I consider should be the default.
In the new behavior, the tap responding is done in the bubbling phase (instead of the capture phase like =true). As a result, a child can handle the tap. If no child does, then the ScrollView will receive the tap and will hide the keyboard. As a result, changing TextInput focus works as a user expects, with a single tap and without keyboard hiding. But taping on Text or on the empty part of the ScrollView hides the keyboard and removes the focus.
You can view the behavior in a monkey patched ScrollView demo on rnplay:
https://rnplay.org/apps/E90UYwhttps://rnplay.org/apps/UGzhKA
In order to have a uniform props set, i added 3 values to the keyboardShouldPersistTaps:
'never' and 'always' are the same as false and true.
'handled' is the new behavior.
I don't
Closes https://github.com/facebook/react-native/pull/10628
Differential Revision: D4294945
Pulled By: ericvicenti
fbshipit-source-id: 1a753014156cac1a23fabfa8e1faa9a768868ef2
Summary:
Internal research at FB has shown that many devs don't know why they should use ListView instead of ScrollView, or that ListView even exists. This PR changes ScrollView's docs to upsell ListView.
I could put this as a separate guide in the docs, but I think this place will have the best possible reach for target audience.
Suggestions welcome. Let me know if it doesn't make sense or is too verbose.
Closes https://github.com/facebook/react-native/pull/11349
Differential Revision: D4292109
Pulled By: mkonicek
fbshipit-source-id: e4a14e5a55333c9282d0e407461505e71e850b20
Summary:
This fixes a cryptic bug to appear when you try to use scrollResponderZoomTo in Android.
before this PR it would break with a `Error: TaskQueue: Error with task : invariant requires an error message argument` because the invariant() was not properly used..
Also, instead of detecting the platform, I think it's better practice to duck type.
Closes https://github.com/facebook/react-native/pull/11186
Differential Revision: D4246674
fbshipit-source-id: 47002a85d8252e5abbd1cd9ecef3d7676fa8615a
Summary:
When using text inputs inside a ScrollView with `keyboardShouldPersistTaps=false` (default behavior) tapping another text input dismisses the keyboard instead of keeping it open and focusing the new text input which I think is the better and expected behavior.
See #10628 for more discussion about that. Note that this affects nothing but the behavior with text inputs unlike #10628.
cc satya164 MaxLap ericvicenti
Closes https://github.com/facebook/react-native/pull/10887
Differential Revision: D4178474
Pulled By: ericvicenti
fbshipit-source-id: 0c62ea2fac0017d559d1f8674b0a686a5e1b3d2d
Summary:
This exposes iOS's spellCheckingType functionality to JavaScript. The native functionality is a three state enum. It gets exposed to JavaScript as a boolean. The initial value and JS null map to the third state.
An alternative design for this API would have been to expose a three state enum to JavaScript:
- "on" which maps to UITextSpellCheckingTypeYes
- "off" which maps to UITextSpellCheckingTypeNo
- "auto" (default) which maps to UITextSpellCheckingTypeDefault
For consistency, I decided to use the same API design as spellCheck. We don't have many options for fixing spellCheck in #11055 without introducing a breaking change.
**Test plan (required)**
Verified that switching `spellCheck` between `true`, `false`, and `null` all work correctly in single line and multiline `TextInputs`.
Closes https://github.com/facebook/react-native/pull/11056
Differential Revision: D4232802
Pulled By: javache
fbshipit-source-id: 79e03307fa6a30a169f7e2fd0ec5ac826663e7c1
Summary:
On Android, if there is a small amount of space available around a text input (e.g. landscape orientation on a phone), Android may choose to have the user edit the text inside of a full screen text input mode. This behavior isn't always desirable. For example, if your app offers some UI controls for controlling the formatting of the text, you want the controls to be visible while the user is editing the text. This Android feature conflicts with that desired experience because the UI controls would be hidden while the text is being edited.
The `disableExtractUI` prop enables developers to choose whether or not Android's full screen text input editing mode is enabled. When this prop is true, Android's `IME_FLAG_NO_EXTRACT_UI` flag is passed to the `setImeOptions` method.
**Test plan (required)**
Verified `disableExtractUI` works for both `true` and `false` values in a test app.
My team is also using this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/10900
Differential Revision: D4226483
Pulled By: mkonicek
fbshipit-source-id: 8f1055f6e612b05bafabe6f07a3705dd8788e3da
Summary:
Corresponding Android PR: https://github.com/facebook/react-native/pull/11001
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/11002
Differential Revision: D4203565
Pulled By: ericvicenti
fbshipit-source-id: 7cb5e10325c3b03c6b395cce0f1bacb0528db40a
Summary:
> Explain the **motivation** for making this change. What existing problem does the pull request solve?
When I'm referring to the `TouchableWithoutFeedback` documentation, I keep noticing this missing 's'.
Closes https://github.com/facebook/react-native/pull/11037
Differential Revision: D4211726
Pulled By: ericvicenti
fbshipit-source-id: 32adf03ec37733128039e064b8fdfa8b817e4a01
Summary:
On iOS, when you press down native fading components, they become
transparent instantly, but then have an animated fade in/out if you
move your finger in/out of their hit box.
On react-native currently, the touchdown fades, instead of providing
instant feedback, which doesn't feel right on iOS.
I'm less familiar with Android conventions, but it seems to use fading
components for buttons less often, instead using the ripple effect from
TouchableNativeFeedback. In either case, instant feedback seems better
for the user.
Closes https://github.com/facebook/react-native/pull/10866
Differential Revision: D4175854
Pulled By: hramos
fbshipit-source-id: d993231074e8190cf4ba7ca86dc24299f05d5d8f
Summary:
The React Native docs list `replaceAtIndex` as a public method of the **NavigatorIOS** component but it is never exposed.
Closes https://github.com/facebook/react-native/pull/10577
Differential Revision: D4168180
Pulled By: hramos
fbshipit-source-id: 6d91d9de8404bb229930d804f8b01b324ec16f24
Summary:
This pull request exposes the `setAllowUniversalAccessFromFileURLs` method of Android WebViewSettings as a property. The reason for this is when loading pages with a `file://` baseUrl it's sometimes desirable to allow loading other assets from a file base url. (For example loading an image into a canvas). More information on its use and purpose can be found [in the android docs here](https://developer.android.com/reference/android/webkit/WebSettings.html#setAllowUniversalAccessFromFileURLs%28boolean%29)
Usage example:
``` jsx
return (
<WebView
source={{ html: myhtml, baseUrl: 'file://' }}
allowUniversalAccessFromFileURLs={true}
javaScriptEnabled={true} />
)
```
Closes https://github.com/facebook/react-native/pull/8905
Differential Revision: D4147245
Pulled By: hramos
fbshipit-source-id: 7eaa884b8c0268de52b284954a34acec0fbd4061
Summary: The warning is only relevant to open source RN but shown to employees too.
Reviewed By: fkgozali
Differential Revision: D4137216
fbshipit-source-id: 21d5c3051c7964231eeb3f555681a83eacb4c972
Summary:
Hi!
Just noticed an incorrect description for the `hidden` argument for `StatusBar.setHidden()` on the website, this trivial change fixes that.
FYI I followed the start procedure for the website mentioned in [CONTRIBUTING.md](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#pull-requests), and noticed one needs to run `npm install` in the project root directory as well before starting the website. Do you want me to add that instruction as part of this PR, or as a separate PR entirely?
Closes https://github.com/facebook/react-native/pull/10735
Differential Revision: D4131223
fbshipit-source-id: b70c5ef12e72807445c51f13811537b9fa3b6b3e
Summary:
Compared to the `<MapView>` that comes with React Native, [react-native-maps](https://github.com/airbnb/react-native-maps) work on Android and is more feature complete. It is actively maintained and used extensively (9.2k installs / month, see [JS.Coach](https://js.coach/react-native/react-native-maps?search=react-native-maps)).
We think now is a good time to switch to react-native-maps in your applications and make `react-native-maps` the official `<MapView>` implementation for React Native.
We are going to release the deprecated `<MapView>` as a separate npm module so you can migrate to `react-native-maps` at your own pace.
**Test Plan**
Checked the docs render correctly on the website:
```
cd website
npm install
npm start
```
<img width="696" alt="screenshot 2016-11-01 20 17 31" src="https://cloud.githubusercontent.com/assets/346214/19905831/480074b8-a070-11e6-8779-8e12343c2883.png">
Warning is shown:
<img width="423" alt="screenshot 2016-11-01 20 39 21" src="https://cloud.githu
Closes https://github.com/facebook/react-native/pull/10500
Differential Revision: D4119602
Pulled By: mkonicek
fbshipit-source-id: 86780a98bf999e6047565ab66a5ebbd15e499a46
Summary:
To my mind this feature should be documented as here lots of issues can happen potentially.
Closes https://github.com/facebook/react-native/pull/10706
Differential Revision: D4119506
fbshipit-source-id: 54f9738ea2308144a05678fd1897f529f260966c
Summary:
this brings back the previous commit that had to be reverted due to internal breakages.
original commit: 1bb323e256
Reviewed By: AaaChiuuu
Differential Revision: D4109811
fbshipit-source-id: b50de145eaf6851138429635bc0302518d656b75
Summary:
They keyboard module is an instance of `NativeEventEmitter` which is an instance of `EventEmitter`. But the exported module only has a small subset of the APIs. This broke existing codebases which are using the methods not exported currently.
The PR just reassigns the variable before exporting so that the actual module is exported instead of the dummy object used for documentation. It also fixes a layout issue in the documentation.
Closes https://github.com/facebook/react-native/pull/10671
Differential Revision: D4110355
fbshipit-source-id: a6757f3ca8c2494970ba221b10a7e6e9a5f2d64d
Summary:
Now that native animations for opacity and springs have landed in both iOS and Android, we can enable native animations both for TouchableBounce and TouchableOpacity.
Closes https://github.com/facebook/react-native/pull/10583
Differential Revision: D4099819
Pulled By: jingc
fbshipit-source-id: de70f8732b84d4caf0e4adfb2ad0e95b3de5da0f
Summary:
Now that native animations for opacity and springs have landed in both iOS and Android, we can enable native animations both for TouchableBounce and TouchableOpacity.
Closes https://github.com/facebook/react-native/pull/10583
Differential Revision: D4099819
Pulled By: lacker
fbshipit-source-id: 247d7bff9a778e520af764f571caf6286b4a5749
Summary:
Fixes#7996.
Test included.
Not sure this is the best way to go, just a simple solution since the TouchableNativeFeedback is trying to clone the component with a Native component, then seems like it should wrap it with Animated.Component if the incoming child was.
Closes https://github.com/facebook/react-native/pull/10081
Differential Revision: D4073603
fbshipit-source-id: 7827198a3e4697c14e37762cdca93f46a5a1d716
Summary:
With nested NavigatorIOS components:
```
<NavigatorIOS initialRoute={{
component: ComponentWithAnotherNavigatorIOSInSubtree
title: 'xyz'
}}>
```
Navigating (via push etc.) in ComponentWithAnotherNavigatorIOSInSubtree's `navigator` caused an invariant error, making apps with this structure unusable. The reason was that the `navigationComplete` nativeEvent was being propagated to the outer Navigator due to React's automatic event bubbling, making the outer NavigatorIOS incorrectly think it was holding navigation stack state inconsistent with its native UINavigationController.
Concretely, if the outer navigation stack is empty except for its initial state and something is pushed onto the inner stack, the outer NavigatorIOS suddenly complains that it has 2 items on its stack rather than 1. In reality, the outer Navigator still only has 1 item on its stack but the inner Navigator's event (containing information about the inner Navigator) incorrectly bubbles up and reaches the outer Navigator too.
Closes https://github.com/facebook/react-native/pull/9828
Differential Revision: D4030167
Pulled By: ericvicenti
fbshipit-source-id: d04de3d5b70b4862a78610c92701ebdab2b047dd
Summary:
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
> **Unless you are a React Native release maintainer and cherry-picking an *existing* commit into a current release, ensure your pull request is targeting the `master` React Native branch.**
Explain the **motivation** for making this change. What existing problem does the pull request solve?
Prefer **small pull requests**. These are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
**Test plan (required)**
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.
Make sure tests pass on both Travis and Circle CI.
**Code formatting**
Look around. Match the style of the rest of the codebase. See also the simple [style guide](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#style-guide).
For more info, see
Closes https://github.com/facebook/react-native/pull/10413
Differential Revision: D4028108
fbshipit-source-id: 99a864dfda578d640f582b296583591415ba26cd
Summary:
JS API very similar to web workers and node's child process.
Work has been done by somebody else for the Android implementation over at #7020, so we'd need to have these in sync before anything gets merged.
I've made a prop `messagingEnabled` to be more explicit about creating globals—it might be sufficient to just check for an onMessage handler though.
Closes https://github.com/facebook/react-native/pull/9762
Differential Revision: D4008260
fbshipit-source-id: 84b1afafbc0ab1edc3dfbf1a8fb870218e171a4c
Summary:
Warning: bind(): You are binding a component method to the component.
React does this for you automatically in a high-performance way, so you can safely remove this call. See TouchableOpacity
Closes https://github.com/facebook/react-native/pull/10349
Differential Revision: D4008552
Pulled By: javache
fbshipit-source-id: d98fe9a0d694dee74ea872e51b02fbd75a133e43
Summary:
We've deprecated these APIs for quite a few releases and we should be able to get rid of them now.
Remove following deprecated modules/components
- AppStateIOS
- ActivityIndicatorIOS
- IntentAndroid
- SliderIOS
- SwitchAndroid
- SwitchIOS
- LinkingIOS
Update following modules to remove callback support
- Clipboard
- NetInfo
cc bestander
Closes https://github.com/facebook/react-native/pull/9891
Reviewed By: bestander
Differential Revision: D3974094
Pulled By: javache
fbshipit-source-id: 9abe32716bd85d0cea9933894f4447d53bdd5ee7
Summary:
We got a report that onContentSizeChange function was being called with an object instead of a number for width, sometimes. Upon debugging, it looked like the param being passed in was a native event wrapper. Tim eventually figured out that this is because there's a TextInput child, and the event bubbles: diffusion/FBS/browse/master/fbobjc/Libraries/FBReactKit/js/react-native-github/Libraries/Text/RCTTextViewManager.m;afbdef32df50$39
Because ScrollView just passes all its props down to the component it eventually renders (RCTScrollView on iOS), the TextInput event bubbles up and triggers the onContentSizeChange prop that was passed in directly, instead of going through the layer in ScrollView that normally unpacks width/height from the native event: diffusion/FBS/browse/master/fbobjc/Libraries/FBReactKit/js/react-native-github/Libraries/Components/ScrollView/ScrollView.js;247ddb2022151b68dd9f83a888b6e0ec9923737a$413-416
Overriding the prop before passing down to RCTScrollView will break that chain, so that the event will continue to bubble but it won't find the incorrect prop from ScrollView.
Reviewed By: yungsters
Differential Revision: D3999689
fbshipit-source-id: d6c3bf711969b3e1c6fc1e51fd44c6894910bc3d
Summary:
Button is an important component to help the community get onboarded with RN quickly, so the first few minutes of a developer's experience is not spent formatting a simple button component.
In my opinion, `<Button />` should be seen as a "lowest common demoniator" component, rather than "the one button to rule them all". In other words, we should only support features in Button that will work on any platform. We should encourage people to fork Button if they need to add specific features to it, rather than trying to twist and bloat this component until it supports everything.
These platform imitations may not have the perfect constants just yet, but they are good enough to make a user feel at home in the app, without any modification. The community can help tweak the final formatting to make them look just right- PRs are welcome!
Reviewed By: frantic
Differential Revision: D3929041
fbshipit-source-id: 3785fb67472a7614eeee0a9aef504c0bdf62ede7
Summary:
This is a critical change and should be pushed to stabel asap
The reason for the pull request is to prevent crashes that can occure if the function relativeKeyboardHeight(keyboardFrame: ScreenRect) got null as an input variable which sometimes does happen.
Closes https://github.com/facebook/react-native/pull/10287
Differential Revision: D3988359
Pulled By: bestander
fbshipit-source-id: 0d1052b590b2684907ea6f7d6b4fe9b89989d4dd
Summary:
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
> **Unless you are a React Native release maintainer and cherry-picking an *existing* commit into a current release, ensure your pull request is targeting the `master` React Native branch.**
Explain the **motivation** for making this change. What existing problem does the pull request solve?
Prefer **small pull requests**. These are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
**Test plan (required)**
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.
Make sure tests pass on both Travis and Circle CI.
**Code formatting**
Look around. Match the style of the rest of the codebase. See also the simple [style guide](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#style-guide).
For more info, see
Closes https://github.com/facebook/react-native/pull/10157
Differential Revision: D3974091
Pulled By: javache
fbshipit-source-id: c756fb82422253bb9098c37fbcb5637e58e53340
Summary:
There is no "window" in react native. And by the way fix the indent.
Closes https://github.com/facebook/react-native/pull/10182
Differential Revision: D3974090
Pulled By: javache
fbshipit-source-id: e0e47e15364abff5bcb136d988e234fc8e1f0a8b
Summary:
Update to docs to indicate that TouchableHighlight must have exactly one child (i.e. not zero or more than one). Previously it was only indicated that it cannot have more than one.
Closes https://github.com/facebook/react-native/pull/10244
Differential Revision: D3970841
fbshipit-source-id: f1c4c223cfaf150fec9bbae1041567d0c81eb63b
Summary: Currently, for short touches (under 130ms by default), we don't trigger the highlight effect. This diff makes it so that if we're not highlighted when we invoke onPress, we highlight.
Reviewed By: astreet
Differential Revision: D3932019
fbshipit-source-id: c0ff7d4c646890507ce510f51c279c88aeba66ae
Summary:
Android (starting from API 23) supports "light status bar", thus it is possible to extend StatusBar and make `barStyle` property work not only for iOS, but also for Android.
This PR introduces one more `barStyle` option `dark-content` in addition to two existing ones (`default` and `light-content`).
Why there are 3 options instead of 2?
Two simple reasons:
1) to make all existing applications fully compatible with these changes;
2) the default status bar on Android is dark with white text and icons, while on iOS it is light with black text and icons on it. Thus the `default` option means something like "I don't really care, just apply the default color for this platform", while two other options (`light-content` and `dark-content`) allow to accurately specify the required result.
Closes https://github.com/facebook/react-native/pull/10185
Differential Revision: D3952346
fbshipit-source-id: 999a67614abff52321fbeb06298ebf1946c3f1d1
Summary:
Simple and elegant. Now someone can dismiss a keyboard in a way that makes sense.
```js
import { Keyboard } from 'react-native'
// Hide that keyboard!
Keyboard.dismiss()
```
+ docs
Closes https://github.com/facebook/react-native/pull/9925
Differential Revision: D3935357
fbshipit-source-id: ecd2fb5c72c4dd769951d308e9bb6ee5d888052a
Summary: Changing from flex -> flexGrow on Scrollview caused some layouts to break due to having views below the scrollview. Adding flexShrink allows for the behavior again.
Reviewed By: blairvanderhoof
Differential Revision: D3936963
fbshipit-source-id: 0f43e6f5148918d3d431b98d26d185bbcc1548d0
Summary:
This fixes measuring of items in the main axis of a container. Previously items were in a lot of cases measured with UNSPECIFIED instead of AT_MOST. This was to support scrolling containers. The correct way to handle scrolling containers is to instead provide them with their own overflow value to activate this behavior. This is also similar to how the web works.
This is a breaking change. Most of your layouts will continue to function as before however some of them might not. Typically this is due to having a `flex: 1` style where it is currently a no-op due to being measured with an undefined size but after this change it may collapse your component to take zero size due to the implicit `flexBasis: 0` now being correctly treated. Removing the bad `flex: 1` style or changing it to `flexGrow: 1` should solve most if not all layout issues your see after this diff.
Reviewed By: majak
Differential Revision: D3876927
fbshipit-source-id: 81ea1c9d6574dd4564a3333f1b3617cf84b4022f
Summary:
Hi there,
when using the ScrollView component with `onScroll` and `scrollEventThrottle = 0` as it is documented in [react-native/docs/scrollview](https://facebook.github.io/react-native/docs/scrollview.html#scrolleventthrottle) this message will appear unnecessary.
This happens because `!this.props.scrollEventThrottle` is `true` when the value is `0`.
So I changed it to `this.props.scrollEventThrottle == null`. Now it is `false` when the value is `0`.
Closes https://github.com/facebook/react-native/pull/10038
Differential Revision: D3909323
fbshipit-source-id: 3c701f23708b64576a8c9f47e140d87159087894
Libin Lu
Sebastian Markbage
Valentin Shergin
Adam Comella
Bhuwan Khattar
Jon Cursi
Tim Yung
Michal Srb
Martin Konicek
Satyajit Sahoo
Paul Mestemaker
Pieter De Baets
David Aurelio
Mathieu Acthernoene
Alex Kotliarskyi
Andy Street
Dan Hassin
Gabriel Reis
Luke Miles
Horcrux
Spencer Ahrens
Leland Richardson
tychota
Alex Kotliarskyi
Maxime Lapointe
Martin Konicek
Jake Dawkins
Gaëtan Renaudeau
Sokovikov
Janic Duplessis
Pandiarajan Nagarajan
Justin
Don Yu
Linmic
Slavik Manukyan
Aria Buckles
Daniel Nagy
Thomas Beverley
Adam Dierkens
Ben Griffith
Phillip Johnsen
aybb
Kevin Gozali
James Ide
Adam Miskiewicz
Anthony Sherbondy
Denis
Geordie
Cristian Carlesso
leeight
Jacob Parker
Konstantin Raev
Jan Kassens
Timur Gibadullin
Jing Chen
Eric Vicenti
Isak Dunér
Nader Dabit
sunnylqm
pedramsaleh
Felix Oghina
Jeff Morrison
Alexander Pantyuhov
Gant Laborde
Emil Sjolander
Matej Matiasko
Dustin Hoffner
