Summary: 9079beda9b wasn't enough to blacklist the strings.xml files from FB infra. So this is a better workaround. According to https://developer.android.com/guide/topics/resources/string-resource the .xml file names doesn't really matter, so this shouldn't break the ability to get the string resource in code, like `R.strings.foo`.
Reviewed By: yungsters
Differential Revision: D15103303
fbshipit-source-id: 6d5174a8dc9598930670d35434e1494f9eaea059
Summary:
Now RN has only ReactActivity which extends AppCompatActivity, subclass of FragmentActivity, therefore no need to check if activity is FragmentActivity or not. This PR changes DialogModule to work only with FragmentActivity.
Also DialogFragment from Android is deprecated in API 28, and recommends to use DialogFragment from Support Library. Excerpt from DialogFragment documentation.
> **This class was deprecated in API level 28.**
> Use the Support Library DialogFragment for consistent behavior across all devices and access to Lifecycle.
**BREAKING CHANGE**: Brown field apps must extend FragmentActivity or its subclasses.
[Android] [Changed] - DialogModule supports only FragmentActivity
Pull Request resolved: https://github.com/facebook/react-native/pull/23365
Differential Revision: D14021986
Pulled By: cpojer
fbshipit-source-id: b0ede60ef19cec48111a12701659a8bc1f66c331
Summary:
@public
Takes a const reference to the style of the printed node once, instead of using repeated calls to `node->getStyle()`.
Makes the code a bit shorter, and ensures that we are operating on `const YGStyle&`, which helps selecting the correct methods further up the stack.
Reviewed By: SidharthGuglani
Differential Revision: D14999094
fbshipit-source-id: 814f06b7e3179ac8cfb43d79fbec48ee4115d6e3
Summary: These strings shouldn't be translated by FB system because each app has its own set of languages and/or translation outputs. We're keeping just values/strings.xml in the repo.
Reviewed By: cpojer
Differential Revision: D15087192
fbshipit-source-id: c4b6112f6dd010d317060ac6640b34e4b725c695
Summary:
Per conversation with TheSavior, in #24538, this adds snapshot tests for more components. Shallow and deep snapshots are included.
[General] [Added] - Snapshots
Pull Request resolved: https://github.com/facebook/react-native/pull/24593
Differential Revision: D15082831
Pulled By: TheSavior
fbshipit-source-id: bc7f27317e2fd0bad133f4ba4d81996d08a12c44
Summary:
Assistive technologies use the accessibility role of a component to tell the disabled user what the component is, and provide hints about how to use it. Many important roles do not have analog AccessibilityTraits on iOS. This PR adds many critical roles, such as editabletext, checkbox, menu, and switch to name a few.
Accessibility states are used to convey the current state of a component. This PR adds several critical states such as checked, unchecked, on and off.
[general] [change] - Adds critical accessibility roles and states.
Pull Request resolved: https://github.com/facebook/react-native/pull/24095
Differential Revision: D15079245
Pulled By: cpojer
fbshipit-source-id: 941b30eb8f5d565597e5ea3a04687d9809cbe372
Summary:
Since initialisation flow changed with default template, we need to adjust the script to make it work properly.
[General] [Fixed] - Adjust text manual e2e script to work with new init.
Pull Request resolved: https://github.com/facebook/react-native/pull/24583
Differential Revision: D15062374
Pulled By: cpojer
fbshipit-source-id: 8110597b27056570784439362f12963154460613
Summary: For some reason the scroll events are sometimes generated with highly irregular spacing, some coming less than a millisecond apart. For interactions that must track scrolling exactly, this can cause them to glitch. With a scroll throttle of less than 17 ms, the intention is clear that the UI should be updated in sync with the scroll view so we shouldn't drop any events.
Reviewed By: PeteTheHeat
Differential Revision: D15068841
fbshipit-source-id: 730e7cb29cc3ddae66f37cf7392e02e0cc9d7844
Summary:
This test was disabled in e106112202 to allow unit tests to run on Facebook's internal CI. The change was reverted in 1f6de88230 because another internal test was broken when it found that mainBundleURL() was not getting called.
In this commit, I've commented out the actual piece of code that would cause unit tests to fail in Facebook's internal CI, without removing the call to mainBundleURL(). The localhostBundleURL() method is called elsewhere in the file, so commenting it out here should not cause any issues.
Changelog:
[iOS] [Changed] - Disable testBundleURL test.
Reviewed By: cpojer
Differential Revision: D15049238
fbshipit-source-id: da3a393922f2190b423980cac5ab54df5e7e3e41
Summary:
This pull request removes the tests for out-of-tree platforms and the dependency on the package `react-native-dummy` from the React Native repo.
The logic that this was meant to test was moved to the React Native CLI repo, and [it is being tested there](827daa4c16/packages/cli/src/tools/config/__tests__/index-test.js (L125-L152)) as well making this a bit redundant at this point.
The dependency on `react-native-dummy` was also an issue, because when the file structure under `Libraries/` changes, bundler errors could crop up if there wasn't an update made to the file structure of `react-native-dummy/Libraries/`.
This was an issue when [`TabBarIOS` was removed](02697291ff (diff-b9cfc7f2cdf78a7f4b91a753d10865a2)) - `react-native-dummy` was causing Haste errors and was stopping the commit from being able to land, and I needed to cut a new version just for it. With Lean Core, I expect more issues like this happening in the future.
[General] [Removed] - Removed Out-of-Tree platform tests (functionality is tested in the RN-CLI repo now)
Pull Request resolved: https://github.com/facebook/react-native/pull/24536
Differential Revision: D15063320
Pulled By: cpojer
fbshipit-source-id: 2a0467bed326b286623fa3cfa4e0bb6959b66b78
Summary:
We are seeing crash reports that the webview is missing. In this case
it should fail gracefully so that a missing webview does not block
from using an app built with React Native.
The contains could also be changed to check for "webview" in general
to catch all webview related exception. It's currently checking on
for the specific string that I'm seeing in our app's crashreporting tool.
<img width="1507" alt="Screen Shot 2019-04-19 at 11 26 19 AM" src="https://user-images.githubusercontent.com/741767/56438307-5e1c2f80-6297-11e9-970b-a5095d18e9d7.png">
<img width="935" alt="Screen Shot 2019-04-19 at 11 32 58 AM" src="https://user-images.githubusercontent.com/741767/56438213-fa920200-6296-11e9-8008-5eb344eca8a8.png">
[Android] [Fixed] - The ReactCookieJarContainer/ForwardingCookieHandler now handles the missing WebView gracefully.
Pull Request resolved: https://github.com/facebook/react-native/pull/24533
Differential Revision: D15062824
Pulled By: cpojer
fbshipit-source-id: 80805a47494f0d924b7ee029ce8ca0504eaeee57
Summary:
Per a conversation with TheSavior, in #24538, this adds snapshot tests for all components whose mocks will be addressed in that PR. Shallow and deep snapshots are included.
[General] [Added] - Snapshots
Pull Request resolved: https://github.com/facebook/react-native/pull/24554
Differential Revision: D15062197
Pulled By: cpojer
fbshipit-source-id: 70ddbaa5e6d1d2c0fd1130ab04c458d9c49d0ee8
Summary: At Facebook we do not install the cli or the packages around it. I added some workaround for that in D15044762 but failed to run Jest without cache to test it and it seems like it didn't run on sandcastle properly either (wtf?). Either way, this adds back the `ios` and `android` reducers for `hasteImpl` to run the tests properly again.
Reviewed By: rubennorte
Differential Revision: D15063152
fbshipit-source-id: 2f1fefe664f02d5f2f5e65b75ac1e0c5b813a343
Summary:
Updates React Native to use latest CLI.
Changes:
- No more `--reactNativePath`, define it once in the configuration file. This reverts the previous PR that added this flag
- Add `platforms` and `commands` - React Native now defines platform like any other package. There's no longer concept of "out-of-tree" platform. All are treated equally. If React Native works, any other platform will work too.
- Updates `jest/hasteImpl.js` to use public CLI interface (`loadConfig`) instead of `findPlugins` and removes a weird conditional that checks for CI presence.
[INTERNAL] - Update React Native CLI
Pull Request resolved: https://github.com/facebook/react-native/pull/24517
Differential Revision: D15044762
Pulled By: cpojer
fbshipit-source-id: 379b61e842e619312c542173219a7d326663cf24
Summary: In `ObjCTurboModule::getArgumentTypeName`, I replaced all instances of `':'` with `''` to transform the selector into a TurboModule methodName. This transformation works when the method has 0 or 1 argument, however, it breaks when the method has more than 1 argument. In all cases, we just want to get the substring until the first `':'`.
Reviewed By: fkgozali
Differential Revision: D15056937
fbshipit-source-id: 3a7dce1ce62ca9758e46c0af951b269166d68454
Summary: adding the flow types makes it impossible to forget to change them back.
Reviewed By: yungsters
Differential Revision: D14990037
fbshipit-source-id: d018e4cf6798d50bcfb44b55d3c68ca7f5beef72
Summary:
Trivial.
Apparently, `DEBUG` is non-standard feature and using `assert` with `DEBUG` is practically asking for bugs. So, if your `assert` relies on some variable which is only defined when `DEBUG` is set, it's easy to get invalid code because NDEBUG and DEBUG can be unsync.
So, we have to use clunky double negative `#ifndef NDEBUG` everywhere where we used DEBUG.
Reviewed By: JoshuaGross
Differential Revision: D15031328
fbshipit-source-id: 036f573e68925741ca46384261885766c87db1e3
Summary:
@public
RCTScrollView sometimes asserts with another contentView set. While this doesn't crash, it'd be good to know what's causing the assert. This will add a recursive description of the contentView.
Changelog: [iOS] [Changed] RCTScrollView: added debugging to help fix assert
Reviewed By: PeteTheHeat
Differential Revision: D15049869
fbshipit-source-id: 5431de7764881922327c6c0a3bdd392668396b58
Summary:
@public
Introduces `YGNodeConstRef` as `const YGNode*`, i.e. a pointer to a constant `YGNode`.
We also use it for all style getters, which will avoid casts to `const YGNode*` in diffs up the stack.
We should use this pointer type for all functions that do not modify the underlying node.
Reviewed By: SidharthGuglani
Differential Revision: D14999095
fbshipit-source-id: 61cc53bb35e787a12ae12e70438d84c0a4983752
Summary:
@public
In order to encapsulate property access on `YGStyle`, as a first measure we wrap all fields with accessors.
This will e.g. enable dynamic property storage and instrumentation in the future.
All accessors have a `const` version that allows direct access via `const&`. For mutation, bit fields are wrapped with a custom reference object.
This style allows for the least amount of changes in client code. Property access simply needs appended parens, eg `style.direction` becomes `style.direction`.
Reviewed By: shergin
Differential Revision: D14999096
fbshipit-source-id: fbf29f7ddab520513d4618f5e70094c4f6330b30
Summary:
@public
Remove unnecessary `const` and `extern` specifiers from `Yoga.h`.
- Function declarations are `extern` by default
- The removed `const` specifiers for pass-by-valye parameters are only meaningful for the *definition* of functions, not for the declaration.
In this specific case, I found `const YGNodeRef` particularly confusing, as it is a `typedef` for a pointer type. `const` does not refer to the pointed-to object, but to the parameter itself, i.e. `const YGNodeRef` is `YGNode * const`, and not `const YGNode *`.
Reviewed By: SidharthGuglani
Differential Revision: D14999097
fbshipit-source-id: 8350870cb67f4a34722f796c4f4a2fc7dde41b99
Summary:
Simplifies the code anyone on iOS using RN has _to see_. In this case, React Native knows that everyone probably wants all these imports (unless they're using dev mode) and so we can auto-import the pod specs for a user from inside the lib.
Basically auto-link for the React side.
[iOS] [Added] - Adds a ruby function which imports the Pods for RN, so that users only have to include this function and it can change per RN version.
Pull Request resolved: https://github.com/facebook/react-native/pull/24555
Differential Revision: D15044780
Pulled By: cpojer
fbshipit-source-id: c3702a52104706def51da6f1d11ab966d57d1edb
Summary:
React Native Environment Info:
System:
OS: Linux 4.15 Ubuntu 18.04.1 LTS (Bionic Beaver)
CPU: (4) x64 Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz
Memory: 1.12 GB / 15.55 GB
Shell: 4.4.19 - /bin/bash
Binaries:
Node: 8.10.0 - /usr/bin/node
Yarn: 1.13.0 - /usr/local/bin/yarn
npm: 3.5.2 - /usr/bin/npm
SDKs:
Android SDK:
API Levels: 16, 19, 22, 23, 24, 25, 26, 27, 28
Build Tools: 23.0.1, 23.0.3, 25.0.0, 25.0.2, 25.0.3, 26.0.1, 26.0.3, 27.0.3, 28.0.2, 28.0.3
System Images: android-16 | Google APIs Intel x86 Atom, android-19 | Google APIs Intel x86 Atom, android-24 | Google Play Intel x86 Atom, android-27 | Google APIs Intel x86 Atom, android-28 | Intel x86 Atom_64, android-28 | Google APIs Intel x86 Atom, android-28 | Google Play Intel x86 Atom
npmPackages:
react: 16.8.6 => 16.8.6
react-native: git+https://github.com/facebook/react-native.git#v0.59.5 => 0.59.5
npmGlobalPackages:
react-native-cli: 2.0.1
react-native-git-upgrade: 0.2.7
The workaround implemented in https://github.com/facebook/react-native/pull/21117 tries to fix
https://issuetracker.google.com/issues/112385925 scroll direction (according to the latest comments, the scroll direction problem has been reverted in security patches so not sure if the workaround is still valid).
But... proposed solution in fling method is using signum which leads to zero computedVelocityY in case of zero mOnScrollDispatchHelper.getYFlingVelocity() on old devices(Samsung s4 mini) even when real velocityY is non zero
```
final int correctedVelocityY = (int)(Math.abs(velocityY) * Math.signum(mOnScrollDispatchHelper.getYFlingVelocity()));
```
Proposed solution is to take signum from original velocityY in case of zero
```
float signum = Math.signum(mOnScrollDispatchHelper.getYFlingVelocity());
if (signum == 0) {
signum = Math.signum(velocityY);
}
final int correctedVelocityY = (int)(Math.abs(velocityY) * signum);
```
The symptoms are the same as described in issue https://github.com/facebook/react-native/issues/22925, but proposed workaround doesn't work.
[Android][fixed] - Fix smooth scrolling on old devices (SDK >=16)
Pull Request resolved: https://github.com/facebook/react-native/pull/24545
Differential Revision: D15044834
Pulled By: cpojer
fbshipit-source-id: 3f523eb1a438df774e22387aecded433b9031ab9
Summary:
By default, the text color is `#000000` on iOS and different on Android, e.g. `#808080`, depending on the manufactorer.
This PR changes it so that newly created projects all have the text color `#000000` by default on both iOS and Android.
The argument for this is to make the app by default be more consistent between platforms.
Expo also does this: https://github.com/expo/expo/blob/master/android/expoview/src/main/res/values/styles.xml#L31
---
For context and for your consideration, I have started a discussion here with the topic of whether React Native should try to use OS defaults or be consistent between platforms:
https://github.com/react-native-community/discussions-and-proposals/issues/121
[Android] [Changed] - New projects have a `#000000` by default.
Pull Request resolved: https://github.com/facebook/react-native/pull/24540
Differential Revision: D15044898
Pulled By: cpojer
fbshipit-source-id: 3197266504e1061ac7027bec3100e39e39a4406a
Kevin Gozali
Weichun Yuan
zhongwuzw
Dulmandakh
David Aurelio
Build Service
Brandon Carroll
Marc Mulcahy
Kacper Wiszczuk
Spencer Ahrens
Héctor Ramos
empyrical
Thorben Primke
Christoph Nakazawa
Salakar
Mike Grabowski
Ram N
Ramanpreet Nara
Valentin Shergin
Mehdi Mulani
Orta Therox
Pavel Rotek
Jonny Burger
