Summary:
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
If this PR fixes an issue, type "Fixes #issueNumber" to automatically close the issue when the PR is merged.
_Pull requests that expand test coverage are more likely to get reviewed. Add a test case whenever possible!_
Pull Request resolved: https://github.com/facebook/react-native/pull/21396
Differential Revision: D10119630
Pulled By: RSNara
fbshipit-source-id: d0fe193eee976b9b18a2eb467b5f3af48bd7d2de
Summary:
bump Android NDK to r17c, which is only available revision to download for r17. And it includes bug fixes.
Pull Request resolved: https://github.com/facebook/react-native/pull/21628
Differential Revision: D10352162
Pulled By: hramos
fbshipit-source-id: d372e55443260242a44a1f73698977a3e361f001
Summary: Looks like we have to explicitly require the BuildConfig package if we want to use it.
Reviewed By: mdvacca
Differential Revision: D10275883
fbshipit-source-id: 4fbce3085e1ac6486a782b2bc0e335b7e48fe8de
Summary:
This test is disabled internally and flaky in open source causing CI to fail. Skipping it for now.
Related to: https://github.com/facebook/react-native/issues/21517
Reviewed By: RSNara
Differential Revision: D10223498
fbshipit-source-id: 37a3798c0abb7de829bc5b59e02f23d8943da882
Summary: Fixes the runtime value of `ReactNativeStyleAttributes` to correctly map to `true` instead of strings (as returned by `keyMirror`).
Reviewed By: TheSavior
Differential Revision: D10057235
fbshipit-source-id: dc855cff3a114761098ed5176b2e6e25412481dc
Summary:
Up until now the `enableBabelRuntime` option in the `metro-react-native-preset` package was hardcoded in the transformer: our internal transformer set it to `false` and the opensource one was `true`.
This diff now exposes this param out to the config of Metro (now that it's quite easy to expose things) so anybody can set it to false or true.
This allows our end to end tests to set it to false to not have to deal with requires to `babel/runtime`.
Reviewed By: davidaurelio
Differential Revision: D10123776
fbshipit-source-id: 97e744eeb567c8e86ab3c613ac71970d226ed2ca
Summary:
We're currently getting a redbox in Turkish when we try to convert the string 'easeInEaseOut' to an InterpolatorType. This is because I use toLowerCase() to compare the string without setting a locale; in Turkish, the capital letter 'I' doesn't convert to 'i' when you lowercase it, but rather to 'ı' (http://www.i18nguy.com/unicode/turkish-i18n.html).
Passing in a locale param to `toLowerCase()` fixes it. Also updating the test.
Differential Revision: D10315474
fbshipit-source-id: 54be3ff1d3f91cb2ec765ff705ac364b976b8c6f
Summary: Adding a test for the newly added InterpolatorType.fromString()
Reviewed By: axe-fb
Differential Revision: D10203814
fbshipit-source-id: f3c70db1a5754c79b1bdd881d266bec110934494
Summary: Simplifying our OSS enums (remove private variables and methods) so that redex can more easily optimize them for us.
Reviewed By: achen1, Feng23
Differential Revision: D9812796
fbshipit-source-id: 11a8272db41ff04399d1cdf366e28ddf1b07b7be
Summary: The legacy implementation doesn't provide additional functionality and has a negative impact on performance and user experience. The legacyImplementation prop is deprecated and will be removed in a future release.
Reviewed By: yungsters
Differential Revision: D10212762
fbshipit-source-id: 9b3416434ba392827b538c984c7ab4bcbe156e60
Summary: The current buffer size isn't enough even to capture a short TTI trace.
Reviewed By: mhorowitz
Differential Revision: D10112538
fbshipit-source-id: 266fa6ffa916049245b21d7725a364d75589c776
Summary: D10138128 had some shamefully wrong boolean logic to determine whether we should customize the accessibility delegate. Previously, we did it if BOTH the accessibility label AND role were present. We should actually do it if EITHER are present.
Reviewed By: mdvacca
Differential Revision: D10182135
fbshipit-source-id: 209a8ab43f5869762843fe878cfd59a7b9b5ab1a
Summary:
The current accessibility implementation tries to generalize every view's accessibility node info by setting an accessibility delegate on every view -- regardless of whether or not any accessibility properties are set. This delegate however doesn't correctly set the appropriate accessibility node fields for every view. For example, ScrollViews needs AccessibilityNode.setScrollable(true) set, but the generic delegate does not account for this. For now let's avoid unnecessarily
setting an accessibility delegate on views that don't have any accessibility props set, which will likely fix the majority of these issues.
Reviewed By: mdvacca
Differential Revision: D10138128
fbshipit-source-id: b999b41e7256e3dce94cd70e9b944979d52f74fd
Summary:
The end-of-scrollable-range offset was not clipped before the nearestOffset calculation causing the ScrollView to not snap to the end of the view when the width of the ScrollView was not an exact multiple of snapToInterval.
Addresses https://github.com/facebook/react-native/issues/21116#issuecomment-427944838
Reviewed By: yungsters
Differential Revision: D10248545
fbshipit-source-id: 2bdc94ea0a9d9f063769f2c5da4c33d4872b1db2
Summary: This component has long been deprecated in the docs. Adding a warning to the code.
Reviewed By: sahrens
Differential Revision: D10261155
fbshipit-source-id: 462ce30a97f35e52477cfc135fb50c976b56e9cb
Summary:
This diff removes the `sinon` dependency from `metro` and `react-native-github`. It was only used in a handful of tests and having to learn and remember another mocking API just for these cases was not worth it IMO.
While doing the migration, most of the things that `sinon` provides can be done with `jest` in a very similar (and user friendly) way.
I've found, though, two small things that are more user friendly with `sinon`. I'm documenting them here because it may be worth adding them to jest:
With `sinon`:
```
stub.throws(new Error('foo'));
```
With `jest`:
```
mock.mockImplementation(() => {
throw new Error('foo');
});
```
Taking into account that `jest` has a `mockRejectedValue` method for mocks (to return a rejected promise) I don't see any reason why it does not have a `mockThrowError` method.
With `sinon`:
```
expect(mock1.calledBefore(mock2)).toBeTruthy();
```
With `jest`:
```
expect(mock1.mock.invocationCallOrder[0]).toBeLessThan(
mock2.mock.invocationCallOrder[0],
);
```
There's a community matcher that adds this matcher in `jest-extended`: https://github.com/jest-community/jest-extended#tohavebeencalledbefore, but we're not using `jest-extended` in `xplat/js`.
Reviewed By: jeanlauliac
Differential Revision: D10238331
fbshipit-source-id: 5441125b69596ad85bf8f56d203cfd20759bc358
Summary:
this is just a suggestion, but as the iPhone 6 is discontinued by Apple
and the new iPhone line will match the X version, it could be good to update the default simulator.
it could also be the iPhone 8, feel free to suggest other changes!
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
If this PR fixes an issue, type "Fixes #issueNumber" to automatically close the issue when the PR is merged.
Pull Request resolved: https://github.com/facebook/react-native/pull/21148
Differential Revision: D9928120
Pulled By: hramos
fbshipit-source-id: 005faa3a8e00b67f98a778c92ecc01b064e14199
Summary: Upgrades all dependents of `fbjs` to the latest version.
Reviewed By: mjesun
Differential Revision: D10100661
fbshipit-source-id: 2e2af616cb2b5eab560872b6c6c60ed264e986b2
Summary:
With the new xcode command line tools (10.1 beta2), running `xcrun simctl list --json devices` seems to gives us a slightly different format than what we were expecting. More specifically, the `availability` key is changed to `isAvailable` and returns `'YES'` if the simulator is available:
Before:
```js
devices: {
'iOS 9.2': [
{
state: 'Shutdown',
availability: '(unavailable, runtime profile not found)',
name: 'iPhone 4s',
udid: 'B9B5E161-416B-43C4-A78F-729CB96CC8C6',
},
{
state: 'Shutdown',
availability: '(unavailable, runtime profile not found)',
name: 'iPhone 5',
udid: '1CCBBF8B-5773-4EA6-BD6F-C308C87A1ADB',
},
...
]
}
```
After:
```js
devices: {
'iOS 12.1': [
{
state: 'Shutdown',
isAvailable: 'YES',
name: 'iPhone 6s',
udid: 'D0F29BE7-CC3C-4976-888D-C739B4F50508',
},
{
state: 'Shutdown',
isAvailable: 'YES',
name: 'iPhone 6',
udid: 'BA0D93BD-07E6-4182-9B0A-F60A2474139C',
},
...
]
}
```
Without this fix, `npm run ios` is not able to launch the simulator correctly and returns the following error:
```
Could not find iPhone 6 simulator
Error: Could not find iPhone 6 simulator
at resolve (/Users/antonyc/Projects/AwesomeProject/node_modules/react-native/local-cli/runIOS/runIOS.js:148:13)
at new Promise (<anonymous>)
at runOnSimulator (/Users/antonyc/Projects/AwesomeProject/node_modules/react-native/local-cli/runIOS/runIOS.js:134:10)
at Object.runIOS [as func] (/Users/antonyc/Projects/AwesomeProject/node_modules/react-native/local-cli/runIOS/runIOS.js:106:12)
at Promise.resolve.then (/Users/antonyc/Projects/AwesomeProject/node_modules/react-native/local-cli/cliEntry.js:117:22)
```
Pull Request resolved: https://github.com/facebook/react-native/pull/21557
Differential Revision: D10248115
Pulled By: TheSavior
fbshipit-source-id: 37197bbf828e4a6e254270d46411a6716a91afe3
Summary:
If a folly::dynamic contains a double when a Java method is
declared to take an int, getInt() will be called, and a C++ exception
will be thrown. This change uses similar logic to
NativeReadableMap.getInt() to convert a folly::dynamic double to a
jint. This will still throw an exception if the JS value cannot be
represented as a jint without loss.
Reviewed By: fromcelticpark
Differential Revision: D10209492
fbshipit-source-id: fd96416200c6b283ce5c8f8fa4c227ceb8f43054
Summary:
This PR fixes an obscure rendering bug on iOS for borders with asymmetric radii. It appears to be a problem with the custom drawing that React Native performs when it cannot use native UIKit/CoreAnimation border drawing.
Pull Request resolved: https://github.com/facebook/react-native/pull/21208
Differential Revision: D10130120
Pulled By: hramos
fbshipit-source-id: d9fbc5c622c060db15658d038a068216b47bb26d
Summary:
This fixes#19193
Characters of different languages may have different height and different baseline, even with a same font and same font-size. When they mixed together, iOS will adjust their baselines automatically, to display a suitable view of text.
The problem is the behavior of dealing with the text-style property 'lineHeight'.
It once to be a right way at version 0.52.3, to setting a base-line-offset attribute for the whole range of the string. However, in current version, it enumerated the string, and set a different base-line-offset for different font-height characters.
And this behavior broke the baseline adjustment made by the iOS. It just make every character's baseline aligned to a same line. But it is not supposed to displaying characters of different languages like that. Chinese characters' baseline is the bottom of each, however, it is not for English characters.
So maybe it is the better way to give a same value of base-line-offset attribute for the whole string. And this PR just did that: found the biggest value of font-height in the text, and calculate the offset with that biggest value, then set to the whole string. This will keep the origin baseline adjustment for different languages' chars made by iOS.
Since I always got an error when running the snapshot test locally, I can't even pass the them with the unmodified code in master branch.
The error is "Nesting of \<View\> within \<Text\> is not currently supported."
After I comment all of the check of that error from the source code, I got a different snapshot from the reference ones. It seems that all components which will cause that error are not rendered in the reference images.
Since this PR changed the behavior of 'lineHeight' property, it's better to add a new snapshot case for the situation of different-language-characters' mixture. So maybe somebody could help me with that or maybe it should be a issue?
[IOS] [BUGFIX] [Text] - fix the baseline issue when displaying a mixture of different-language characters
Pull Request resolved: https://github.com/facebook/react-native/pull/19653
Differential Revision: D10140131
Pulled By: shergin
fbshipit-source-id: 646a9c4046d497b78a980d82a015168cf940646b
Summary:
@public
We're seeing a crasher where `self` on line 54 isn't an `RCTNetInfo`. The timing looks related to D9798488, so my theory is that this class is being deallocated before it resolves, and thus causes a crash.
Reviewed By: PeteTheHeat
Differential Revision: D10127341
fbshipit-source-id: 94eaba7def6b118092adcf6b4cce841ccc7d0b59
Summary: D10138128 had some shamefully wrong boolean logic to determine whether we should customize the accessibility delegate. Previously, we did it if BOTH the accessibility label AND role were present. We should actually do it if EITHER are present.
Reviewed By: mdvacca
Differential Revision: D10182135
fbshipit-source-id: 209a8ab43f5869762843fe878cfd59a7b9b5ab1a
Summary: We need a new version of Metro with D10119384 to make the new Embeds work well
Reviewed By: davidaurelio
Differential Revision: D10119385
fbshipit-source-id: db7fc71c75c450720af41add466fc88ac38f3066
Summary:
Since the options that are passed to the `babelTransformer` are not exactly the same ones as the `transformer` receives, we need to have a specific object for them.
This allows us to make the transformer options object strict (since unfortunately the `babeltransformer` options object comes from many places and needs a bit of work to be able to be strict...
Reviewed By: mjesun
Differential Revision: D9309173
fbshipit-source-id: 0a92381968f17e5eb6c4740c1ca89580fa7ee4d3
Summary: This makes the Metro config type readonly, only a couple of things inside Metro needed to be tweaked :)
Reviewed By: mjesun
Differential Revision: D10028083
fbshipit-source-id: 15f5d957a8ee7384d6156c973639d86240fd251f
