Summary:
This avoids reordering views because it created some bugs when the native hierarchy is different from the shadow views. This leverages `layer.zPosition` and takes z-index in consideration when we check what view should be the target of a touch.
**Test plan**
Tested that this fixes some layout issues that occurred when using sticky headers in the Expo home screen.
Closes https://github.com/facebook/react-native/pull/14011
Differential Revision: D5108437
Pulled By: shergin
fbshipit-source-id: 0abfe85666e9d236a190e6f54cdd5453cacfbcac
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:
Currently it's not possible to create a silent local notification (which is useful for badge updates) with PushNotificationIOS. This commit solves the problem - when **soundName** param is not specified in **PushNotificationIOS.scheduleLocalNotification** method, a silent notification will be created.
Local notification without sound:
```
let fireDate = new Date();
fireDate = fireDate.setSeconds(fireDate.getSeconds() + 15); //fire in 15 seconds
PushNotificationIOS.scheduleLocalNotification({
fireDate: fireDate,
alertBody: "I'm silent!"
});
```
Local notification with sound:
```
let fireDate = new Date();
fireDate = fireDate.setSeconds(fireDate.getSeconds() + 15); //fire in 15 seconds
PushNotificationIOS.scheduleLocalNotification({
fireDate: fireDate,
alertBody: "I'm with sound!",
soundName: "Any sound"
});
```
Closes https://github.com/facebook/react-native/pull/13734
Differential Revision: D5144848
Pulled By: shergin
fbshipit-source-id: dc990b2673305a01cfd868fcdedcf27c461d0a34
Summary:
should be consistent with semicolons...
Thanks for submitting a PR! Please read these instructions carefully:
- [x] Explain the **motivation** for making this change.
- [x] Provide a **test plan** demonstrating that the code is solid.
- [x] Match the **code formatting** of the rest of the codebase.
- [x] Target the `master` branch, NOT a "stable" branch.
I think it's good to stay consistent when using semicolons and when not using semicolons.
What existing problem does the pull request solve?
Consistency, I guess?
None really - it's a document (markdown) change. Not much to test.
Closes https://github.com/facebook/react-native/pull/13993
Differential Revision: D5144814
Pulled By: shergin
fbshipit-source-id: 8bf345897738458183047a229a3d327bec4b64ae
Summary:
The Examples directory no longer exists and the instructions in this part of the README were stale.
Follow the instructions to run RNTester on iOS and Android
(this actually fails for me currently on Android, but I believe the instructions are correct and the failure is related to something else)
Closes#14222
Closes https://github.com/facebook/react-native/pull/14229
Differential Revision: D5144514
Pulled By: shergin
fbshipit-source-id: 19ca173e8c5e91de7e1e53a21dbcaa0968da092b
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:
Maintainers - hoping theres a chance this could be cherry-picked into 0.44-stable as it's a very minor change to the local-cli.
Our iOS app has 3 different configurations, each with a separate Product Name. When building for debugging on the simulator with the `react-native run-ios` command, the build would complete successfully but would error in trying to install to the simulator. I tracked the error down to the regex I've updated in this PR which was looking for the full product name in the build output, but the regex there wasn't using the multiline flag so it never matched.
I've tested this locally with our app and it now works as expected. If I specify a different configuration with `react-native run-ios --configuration Beta` (for example), it properly detects the Product Name for the configuration and installs correctly as well.
Closes https://github.com/facebook/react-native/pull/14071
Differential Revision: D5141414
Pulled By: shergin
fbshipit-source-id: 23bceb8a9650cc0cf2a83ea92ad417049240da4e
Summary:
Thanks for submitting a PR! Please read these instructions carefully:
- [x] Explain the **motivation** for making this change.
- [x] Provide a **test plan** demonstrating that the code is solid.
- [x] Match the **code formatting** of the rest of the codebase.
- [x] Target the `master` branch, NOT a "stable" branch.
Fixes#14081. Prevents unnecessary error output on check for yarn package manager on Windows systems.
Can't find existing tests for the CLI and JavaScript doesn't have much knowledge about this change anyhow.
Example behavior with and without the fix:
Note that on master, the output contains the line "'yarn' is not recognized as an internal or external command, operable program or batch file." and on my branch, it does not.
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/14082
Differential Revision: D5141387
Pulled By: shergin
fbshipit-source-id: 80f9aa9ecb7d8943f0b3b87b8ebbe7828c317bbd
Summary:
We found that `-[CALayer renderInContext:]` produces bad results in some cases (which is actually documented thing!),
so we decided to replace it with `-[UIView drawViewHierarchyInRect:]` which is more reliable (I hope).
As part of this change I completly removed support of `CALayer` from local fork of `RNTesterIntegrationTests`.
See https://github.com/facebook/react-native/pull/14011#issuecomment-303844580 for more details.
janicduplessis
Reviewed By: javache
Differential Revision: D5129492
fbshipit-source-id: 6a9227037c85bb8f862d55267f5301e177985ad9
Summary:
The documentation for the prop `scrollEnabled` on the `ScrollView` component does not clarify that scrolling is still possible by calling `scrollTo` on the view ref.
Please see [this expo snack demo](https://snack.expo.io/BJKTVMM-Z) showing scrolling is allowed while `scrollEnabled` is `false`.
This PR makes the documentation for this prop more clear, in that setting it to false will only disable scrolling by touches, not universally.
In my opinion, this also raises the question of a need for an additional prop which would disable all scrolling, even when calling `scrollTo`.
I have attached a screenshot of what this part of the documentation looks like with my edit:
Closes https://github.com/facebook/react-native/pull/14140
Differential Revision: D5138593
Pulled By: shergin
fbshipit-source-id: db1a5f9c8ac41ecfce952e7b1fce9428b2068162
Summary: By getting rid of callbacks, we get a code that's pretty halved in size, and much easier to read, but we also fix bugs! When some of the code of Module would throw, we wouldn't catch it, meaning that packager would crash entirely. That's the case for when we have a Haste name mistach, for example. This changeste fixes that by instead capturing exceptions through the Promise chain, that bubble up all the way to the `Server` and reasonnably handled. People can then fix the Haste nane mismatch and refresh right away, and it'll work as expected.
Reviewed By: davidaurelio
Differential Revision: D5137408
fbshipit-source-id: b9e938b93e8d23738af49106bbae1fce97d7a5db
Summary:
* Only add the moduleName to the outer marker
* Include module init in the marker time
* Include the WritableNativeArray time in CONVERT_CONSTANTS
* Stop all markers from finally block in case of exception
Reviewed By: kathryngray
Differential Revision: D5031411
fbshipit-source-id: bf86ee3d59f2cb38866afd52e84af5699db1a003
Summary:
When using native animated we don't go through the shadow thread and use the NativeViewHierachyOptimizer so we have to make sure the views won't get optimized away. Also since we are not passing certain props because they are driven by native it is possible that the view will be marked as layout only when in fact it is not.
**Test plan**
Animated a simple view that will be collapsed with native animated and reproduce the error (it's actually just an error log in logcat now and no longer a redscreen) and checked that this fixes it.
Fixes#12975
Closes https://github.com/facebook/react-native/pull/12983
Differential Revision: D4811420
Pulled By: javache
fbshipit-source-id: f217f244baca64df2b76cbe08cce2d847c0dc985
Summary:
Follow up to #11973 to add support to Animated.loop with useNativeDriver on iOS.
**Test plan**
Test with new UIExplorer example
Run unit tests
Closes https://github.com/facebook/react-native/pull/13359
Differential Revision: D4960754
Pulled By: javache
fbshipit-source-id: caa840281f1b060df7a2b1c50405fcae1e1b0de6
Summary: I'd like us to start having some decent testing at the packager/bundler level to check that there are no major breakage hapenning. This changeset introduce a simple test that just test the `buildBundle` public API. On the same model, I'd like to test the server API and behavior, and things such as hot module reloading. I hope this will also highlight the gross inconsistencies of the API, for example the Bundle/BundleBase hierarchy, that we can proceed to fix later.
Reviewed By: davidaurelio, cpojer
Differential Revision: D5121817
fbshipit-source-id: e0f3758c7fbb7a85cf51fb3cbc34c12d5374b7d3
Summary:
This change introduces an API, `setAccessibilityFocus`, which moves the screen reader's focus to the passed in element. This causes VoiceOver to announce the element and draw a focus rectangle around it.
Similar functionality is already available in RN Android through the `sendAccessibilityEvent` method. Here's an example of what exists today in RN Android:
```
RCTUIManager.sendAccessibilityEvent(
node,
8 /* TYPE_VIEW_FOCUSED */);
```
Called `setAccessibilityFocus` on a couple of elements to verify that focus does indeed move when VoiceOver is enabled. Additionally, my team is using this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/14169
Differential Revision: D5137002
Pulled By: javache
fbshipit-source-id: 466e8b187e625de7c0f0d36e0400327dcd8d192a
Summary:
When attempting to inverse a Bash boolean, the `!` character converts the meaning to become `[[ ! -n false ]]` (checking that the string "false" is empty) which never matches, and therefore this condition can never occur.
See https://stackoverflow.com/a/2953673
Closes https://github.com/facebook/react-native/pull/14190
Differential Revision: D5137013
Pulled By: javache
fbshipit-source-id: 7df52cc90a4ab79c7b5da54dbfb6c99fba3e8b80
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:
What existing problem does the pull request solve?
Beginning in iOS9, Apple has deprecated `-application:openURL:sourceApplication:annotations:`
`- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(nullable NSString *)sourceApplication annotation:(id)annotation NS_DEPRECATED_IOS(4_2, 9_0, "Please use application:openURL:options:") __TVOS_PROHIBITED;`
This PR uses the newly recommended method:
`- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey, id> *)`
while meanwhile, leaving the deprecated one for developers wishing to use the older `-application:openURL:sourceApplication:annotations:` for apps that support versions 8.x or less.
Benefits will include:
- [x] less warnings
- [x] official deprecation should happen when iOS 11 is deployed
- [x] TVOS support
Closes https://github.com/facebook/react-native/pull/13615
Differential Revision: D4987980
Pulled By: javache
fbshipit-source-id: ae07715a55ca627860262a9c8cf7df1e3c5e752b
Summary:
Fixes https://github.com/facebook/react-native/issues/13784
The section footer was only rendered with the last item of the section. However, that meant in sections where no items were rendered, no section footer would be rendered. This patch makes sure that when there are no items the section footer is rendered with the section header in addition to adding tests asserting the existance of section footers in empty lists.
One potential point of contention is whether or not a section separator (as defined by the `SectionSeparatorComponent` prop to `<SectionList>`) should be rendered in an empty list. I did not include a section separator for empty lists, but let me know if you think one should be included. See the test plan below for an image of an empty section rendered without a section separator.
I was also running into a lint error, `no-alert`, in `SectionListExample.js` around line 135 that blocked me from publishing. This error looks to be triggered when the `alert()` global function is called, so to fix the error I added an import for the `Alert` module and called the `alert()` function on that module.
To help debug the `scrollToLocation()` behavior that was modified as a part of this PR I added three buttons (can be seen in the test plan image) which scroll to arbitrary points in the list.
Reviewed By: sahrens
Differential Revision: D5084095
fbshipit-source-id: 4c98bebc1c3f1ceaa5a634fa144685d83d1072df
Summary:
Code generation for indexed RAM bundles did not append module ID and dependencies. This fixes that.
Eventually, we only want to have the call to `addModuleIdsToModuleWrapper` in one place.
Reviewed By: jeanlauliac
Differential Revision: D5129255
fbshipit-source-id: 7f6148dd607bbf7c97e9df7936a07bde3f05b3aa
Summary:
**Motivation**
The ART library is part of the react-native repo, but is not included in UIExplorer and has no native testing. This PR adds the ART library to UIExplorer, adds an example tab for it, and adds a snapshot test.
**Test plan**
New snapshot test.
Closes https://github.com/facebook/react-native/pull/13621
Differential Revision: D4954082
Pulled By: javache
fbshipit-source-id: 83e21c5df1b766ff6ca9f8914eb3382f7323627d
Summary:
There was an edge case where sometimes a view could be added and removed in the same batch so this caused issues because we ran `disconnectAnimatedNodeFromView` before `connectAnimatedNodeToView`. This separates restoring default values from `disconnectAnimatedNodeFromView` so we can run only `restoreDefaultValues` on the pre-operations queue and just do nothing in case the view doesn't exist (it is fine because we know it will be removed immediately).
**Test plan**
Tested that native animations still work properly in RNTester and tested that the edge case crash was fixed.
Closes https://github.com/facebook/react-native/pull/14114
Differential Revision: D5128989
Pulled By: javache
fbshipit-source-id: 9f47a2d3aafeb06d8ed1a4dd1800b8af225edb7d
Summary: This allows us to get the new fix for recovery on duplicate modules.
Reviewed By: cpojer
Differential Revision: D5128975
fbshipit-source-id: 5a2b60430bbca1806a97798c482af8522366e071
Summary:
This changeset moves the creation of the transform cache at the top-level of the bundler so that:
* we can use alternative folders, such as the project path itself, that I think will be more robust especially for OSS;
* we can disable the cache completely, that is useful in some cases (for example, the script that fills the global cache).
The reasons I believe a local project path is more robust are:
* there are less likely conflicts between different users and different projects on a single machine;
* the cache is de facto cleaned up if you clone a fresh copy of a project, something I think is desirable;
* some people have been reporting that `tmpDir` just returns nothing;
* finally, it prevents another user from writing malicious transformed code in the cache into the shared temp dir—only people with write access to the project have write access to the cache, that is consistent.
Reviewed By: davidaurelio
Differential Revision: D5113121
fbshipit-source-id: 74392733a0be306a7119516d7905fc43cd8c778e
Summary:
This is a simple bugfix. `_updateViewableItems` expects the `data` prop, as it calls `getItemCount` on it. Without this, `onViewableItemsChanged` updates twice for each scroll position, once from `_onScroll` with the incorrect results, and once from `_updateCellsToRender` with the correct results. This means the callback nigh-on unusable.
I simply logged the results of `onViewableItemsChanged` and made sure they were correct.
Closes https://github.com/facebook/react-native/pull/14162
Differential Revision: D5128363
Pulled By: sahrens
fbshipit-source-id: 3faef812068921a26ed871339da79870fd0d911c
Summary:
This change fixes a memory leak in `AccessibilityInfoModule`.
Our tooling detected this memory leak. After this commit, we no longer see the leak in the tool. We've been using the change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/14171
Differential Revision: D5128845
Pulled By: javache
fbshipit-source-id: b604902188eb8cc029b1ad39d087e199ae26877c
Janic Duplessis
Saleel Salam
Valentin Shergin
Alex Ledak
Shashank Saxena
Brent Vatne
Emil Sjolander
Hector Ramos
unexge
Adam Comella
Max Thorson
Ryan Stelly
Chris Knepper
Georgiy Kassabli
Brian Vaughn
Jean Lauliac
Pieter De Baets
G. Kay Lee
Hank Brekke
glevi@fb.com
Andrew Y. Chen
Kathy Gray
David Aurelio
Jason Noah Choi
Daniel Zlotin
Caleb Meredith
Douglas Lowder
Marcus do Nascimento
ashoat
yk3372
