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: Separates the polyfills used for node.js from the configuration of `babel-register`, to make pretransforming packager before invoking it easier.
Reviewed By: cpojer
Differential Revision: D4978047
fbshipit-source-id: 45d3d49d0a714a8257be8d244a01e41b68bbce3d
Summary:
When using a translucent status bar using `<StatusBar />` and a `<Modal transparent />` the dialog layer applies its own translucent status bar color on top causing the status bar to darken.
This is especially problematic when the modal is a menu and nothing on the screen is supposed to darken.
I've collected screenshots of the status bar in various situations before and after this change to show the change and demonstrate that it doesn't have any bad side effects for the other status bar and modal types (non-translucent status bars / non-transparent modals).
* "**Before**" row: RN 0.43.1 unmodified
* "**After**" row: This modification applied
* **Translucent**: Translucent status bar `<StatusBar backgroundColor='rgba(0, 0, 0, 0.2)' translucent />` (modal closed)
* **Alpha Colored**: Coloured translucent status bar `<StatusBar backgroundColor='rgba(255, 0, 255, 0.2)' translucent />` (modal closed)
* **Not Translu...**: Non-translucent status bar `translucent={false}` (modal closed)
* **w/modal**: Same as image to the left but with the Modal opened
* **Opaque Modal**: Translucent status bar with open but opaque/dim modal (`<Modal transparent={false} />`)
Closes https://github.com/facebook/react-native/pull/13629
Differential Revision: D4985349
Pulled By: astreet
fbshipit-source-id: 4d3614a07bb15cb52f220d9444b898d15be7b4dc
Summary: People rarely re-order sections so this is an annoying requirement and we can just use the index by default.
Reviewed By: thechefchen
Differential Revision: D4972154
fbshipit-source-id: 256c445b36c9ba101277614d30a6dc1dbd477ee0
Summary: The xcode project for these bundled libraries should not depend on UIExplorer
Reviewed By: yungsters
Differential Revision: D4979629
fbshipit-source-id: 440b225805e9ebaf0a02b39a35c3ab9c2a83ad05
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: Fixes support for haste packages in `ModuleGraph`. As `HasteMap` is no longer used for anything else, we can probably strip it down completely.
Reviewed By: cpojer
Differential Revision: D4967367
fbshipit-source-id: d40cbe46c1e8b05690c0a2c71955479c28607c01
Summary: deduplicates / unifies types for source maps across the code base
Reviewed By: jeanlauliac
Differential Revision: D4955924
fbshipit-source-id: 25cb71031dce835dd7d2bc1c27d6b20050906e81
Summary:
Two things in there:
* Using `base64` was kinda broken, as it can contain slashes, invalid in file names. It would still work however because it would just create a second level folder when doing `mkdirp`. Still I think it's better to fix that correctness.
* Include the UID in the hash, so that different users have different folders for sure, and that we reduce potiential permissions issues. `tmpdir()` already returns a folder that's user-specific on OS X, but this is not a guarantee on all platforms.
Reviewed By: cpojer
Differential Revision: D4969856
fbshipit-source-id: 4a9be35104ac9698edf2c84c58d395ee171ce2a8
Summary: Oftentimes packager stalls for several seconds after requiring a bundle, because it's busy cleaning up old cache files. We shouldn't do that when, for example, we just restarted packager. This changeset stores the micro-timestamp of the last collection so that we don't waste time next time.
Reviewed By: cpojer
Differential Revision: D4969832
fbshipit-source-id: 3aa0495b18d5a8efa1b8f87dbf7a40b0673fd9fd
Summary:
Fixes the sizing of items so that under most scenarios it calcultes its height by it's content for non exact measurings. This introduces a new useLegacyStretchBehaviour flag on the config to opt out of this change as it is breaking.
See facebook/yoga#505
Closes https://github.com/facebook/yoga/pull/506
Reviewed By: astreet
Differential Revision: D4954016
Pulled By: emilsjolander
fbshipit-source-id: d28bd5d174cd76951fb94df85e3b0cfab7f81ff7
Summary:
Added an example of the Fetch usage inside a component.
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 the ["Pull Requests" section of our "Contributing" guidelines](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#pull-requests).
Closes https://github.com/facebook/react-native/pull/12348
Differential Revision: D4962419
Pulled By: hramos
fbshipit-source-id: 37b3517811f5391126d9e3ec026d2902705729a7
Summary:
Updated map view example to correct and extend on change event management
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 the ["Pull Requests" section of our "Contributing" guidelines](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#pull-requests).
Closes https://github.com/facebook/react-native/pull/12759
Differential Revision: D4962286
Pulled By: hramos
fbshipit-source-id: 92cc41f100616d3b5633603cf69850ebc9fc33b2
Summary:
I don't think editing the search path is necessary anymore for notifications since [0.40](https://github.com/facebook/react-native/releases/tag/v0.40.0).
I removed the part that says to edit the search paths, and changed `#import "RCTPushNotificationManager.h"` to `#import <React/RCTPushNotificationManager.h>` in the documentation
Thanks for submitting a PR! Please read these instructions carefully:
- [ ] Explain the **motivation** for making this change.
- [ ] Provide a **test plan** demonstrating that the code is solid.
- [ ] Match the **code formatting** of the rest of the codebase.
- [ ] Target the `master` branch, NOT a "stable" branch.
What existing problem does the pull request solve?
A good test plan has the exact commands you ran and their output, provides screenshots or videos if the pull request changes UI or updates the website. See [What is a Test Plan?][1] to learn more.
If you have added code that should be tested, add tests.
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/13700
Differential Revision: D4969728
Pulled By: javache
fbshipit-source-id: d72aee1c5b8578cea27d6b7d45ee7a7f269433fc
Summary:
In the current docs, it's not quite clear, at the first sight, what the `lang` parameter passed to `onValueChange` is. This makes it obvious.
Closes https://github.com/facebook/react-native/pull/13617
Differential Revision: D4969592
Pulled By: javache
fbshipit-source-id: e94bedefebbe19d838d010f0c79d9a76743a4341
Summary:
What existing problem does the pull request solve?
I was seeing errors in the crash monitoring software for my app in production. Many took the form of, `Unable to open URL: telprompt:5551231234`
After some research, I found that when the user attempts to call a phone number, a dialog pops up in iOS asking the user to confirm or cancel the call. If the call is canceled, the promise returned by `openURL` is rejected.
This PR improves the documentation around what happens to the promise returned by `openURL`.
No test plan, text changes only.
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/13624
Differential Revision: D4962161
Pulled By: javache
fbshipit-source-id: c8d5ffbc24ba4c14c85db6ea799a6f95339b94c8
Summary:
Looking to address a few new `FlowFixMe`s I had to do some minor refactoring of `MessageQueue`. Has the advantage of (IMO) making things clearer by removing a redundant counter and some gratuitous bitwise operations.
Previously `_callbacks` was an array of `?Function`s where even elements were failure callbacks and odd elements were successes. Each new call incremented `_callID` by one and `_callbackID` by two. I've changed this to use two arrays `_successCallbacks` and `_failureCallbacks` indexed by `callID`. That made the `_callbackID` counter unnecessary and reduced the need for computed indices.
Tested with flow and a quick play with UIExplorer.
Closes https://github.com/facebook/react-native/pull/11986
Differential Revision: D4962162
Pulled By: javache
fbshipit-source-id: 17dddfedc0cb5950dbdd9bd06fae6eb6de4c4a7d
Summary:
Mitigates the issue in https://github.com/facebook/react-native/issues/10471, by not trying to present
a modal or alert view if the presenting view controller is already being dismissed.
Reviewed By: shergin
Differential Revision: D4962169
fbshipit-source-id: 593e3f21096458651d16677a3e030552f809bf02
Summary:
This PR solves issue #13618.
Selectable text still behaves the same way:
```jsx
<Text selectable={true}>yo yo yo</Text>
```
Text that is not selectable and has a custom tooltip now do not include the copy item:
```jsx
import * as React from 'react';
import { Text } from 'react-native';
import ToolTip from 'react-native-tooltip';
const MyComponent = () => (
<Text>
<Text>This is my text.</Text>
<ToolTip
actions={[
{text: 'My', onPress: (): any => null },
{text: 'Context', onPress: (): any => null },
{text: 'Menu', onPress: (): any => null },
]}
underlayColor='transparent'
longPress={true}
arrowDirection='down'
>
<Text>You can long press me for a tooltip.</Text>
</ToolTip>
<Text>This is the rest of my text</Text>
</Text>
);
export default MyComponent;
```
Closes https://github.com/facebook/react-native/pull/13619
Reviewed By: shergin
Differential Revision: D4936900
Pulled By: ericvicenti
fbshipit-source-id: 82028b0958c37d63b8a80882196295be4aebecb4
Brian Vaughn
Janic Duplessis
Sokovikov
Blair Vanderhoof
Ravi Bhoraskar
Alex Dvornikov
David Aurelio
Daniel Friesen
Jean Lauliac
Spencer Ahrens
Valentin Shergin
Eric Vicenti
Liron Yahdav
sunnylqm
Emil Sjolander
Karol Kuczmarski
Jan Kassens
Karin Wefald
Lukas Wöhrl
sebasbad
Brendan Rius
Vojtech Novak
Garrett McCullough
rh389
Pieter De Baets
Andres Suarez
Ashok Menon
Gabe Levi
Gabriel Bull
Seth Kirby
