Summary:
Looks we forgot to add this file to publish list. By adding it, we can remove some code in CLI that special-cases `react-native` package, since it now announces itself as a proper platform.
cc kelset, we'd like to have this cherry-picked for 0.60.
## Changelog
[Internal] [Fixed] - Publish `react-native.config.js`
Pull Request resolved: https://github.com/facebook/react-native/pull/25436
Test Plan: `npm pack` shows `react-native.config.js`
Differential Revision: D16071113
Pulled By: cpojer
fbshipit-source-id: df18affbb9a0ad7f2cfdd1a4cc93191aa5ffadeb
Summary:
The current technique we use to draw text uses linear memory, which means that when text is too long the UIView layer is unable to draw it. This causes the issue described [here](https://github.com/facebook/react-native/issues/19453). On an iOS simulator the bug happens at around 500 lines which is quite annoying. It can also happen on a real device but requires a lot more text.
To be more specific the amount of text doesn't actually matter, it is the size of the UIView that we use to draw the text. When we use `[drawRect:]` the view creates a bitmap to send to the gpu to render, if that bitmap is too big it cannot render.
To fix this we can use `CATiledLayer` which will split drawing into smaller parts, that gets executed when the content is about to be visible. This drawing is also async which means the text can seem to appear during scroll. See https://developer.apple.com/documentation/quartzcore/calayer?language=objc.
`CATiledLayer` also adds some overhead that we don't want when rendering small amount of text. To fix this we can use either a regular `CALayer` or a `CATiledLayer` depending on the size of the view containing the text. I picked 1024 as the threshold which is about 1 screen and a half, and is still smaller than the height needed for the bug to occur when using a regular `CALayer` on a iOS simulator.
Also found this which addresses the problem in a similar manner and took some inspiration from the code linked there https://github.com/GitHawkApp/StyledTextKit/issues/14#issuecomment-395234885
Fixes https://github.com/facebook/react-native/issues/19453
## Changelog
[iOS] [Fixed] - Use CALayers to draw text, fixes rendering for long text
Pull Request resolved: https://github.com/facebook/react-native/pull/24387
Test Plan:
- Added the example I was using to verify the fix to RNTester.
- Made sure all other examples are still rendering properly.
- Tested text selection
Reviewed By: shergin
Differential Revision: D15918277
Pulled By: sammy-SC
fbshipit-source-id: c45409a8413e6e3ad272be39ba527a4e8d349e28
Summary:
Bump Fresco to 2.0.0, which supports AndroidX. We should cherry-pick to 0.60 release, to support brown field apps but also native components.
## Changelog
[Android] [Changed] - Bump Fresco to 2.0.0, supports AndroidX
Pull Request resolved: https://github.com/facebook/react-native/pull/25358
Test Plan: CI is green, and RNTester builds and runs as expected.
Differential Revision: D15959443
Pulled By: mdvacca
fbshipit-source-id: 58ba2c3e4d1342014d6ea632cd865b4f413548d9
Summary:
I found that on Android we only support 2 fontWeight options, either **normal** or **bold**, even developer can set any numeric value. But iOS supports all possible numeric values. This PR tries to add support for all possible numeric values on Android, even if it's supported only on Android P(28) and above.
This change might break texts where fontWeight use improperly, because this PR removes conversion of values above 500 to BOLD and below 500 to normal.
FYI, also moved **mCustomTypefaceCache** usage up because it was working after unnecessary mFontCache usage.
## Changelog
[Android] [Changed] - add custom font weight support to Text component on Android, only on P(API 28) and above versions.
Pull Request resolved: https://github.com/facebook/react-native/pull/25341
Test Plan: RNTester app's Text examples will show Rubik Regular, Rubik Light, Rubik Bold, Rubik Medium and Rubik Medium Italic texts in corresponding font family, style and weights.
Differential Revision: D15956350
Pulled By: mdvacca
fbshipit-source-id: 61079d953c65fb34ab4497d44c22317912a5a616
Summary:
Upgrading the CLI to the latest with a bunch of fixes and features included.
## Changelog
[General] [Changed] - Bump CLI to 2.0.0-rc.0
Pull Request resolved: https://github.com/facebook/react-native/pull/25175
Differential Revision: D15694764
Pulled By: cpojer
fbshipit-source-id: 25fbf1c275ed5379e1cdb372512b6bb6327dea92
# Conflicts:
# jest/hasteImpl.js
# package.json
# yarn.lock
Summary:
Fixes#22752
On line 1021 you are passing base style to props:
`style: [baseStyle, this.props.style],`
Explicitly passing base style to ScrollView just overrides this line and doesn't let developers to customise style of any inheritors of ScrollView (not only FlatList) with custom RefreshControl.
So this line (1113) seems to be removed.
## Changelog
[GENERAL] [Fixed] - fix of Android's bug that doesn't let override ScrollView's Style with custom RefreshControl.
Pull Request resolved: https://github.com/facebook/react-native/pull/24411
Differential Revision: D15713061
Pulled By: cpojer
fbshipit-source-id: 461259800f867af15e53e0743a5057ea4528ae69
Summary:
### Problem
According to https://github.com/facebook/react-native/issues/9145, the `--port` setting is not respected when executing `react-native run-android`. The templates that report things like what port the dev server runs on are hard coded as well.
### Solution
This commit replaces the hardcoded instances of port 8081 on Android with a build configuration property. This allows setting of the port React Native Android connects to for the local build server.
For this change to work, there must also be an update to the react native CLI to pass along this setting:
https://github.com/react-native-community/react-native-cli/compare/master...nhunzaker:9145-android-no-port-hardcode-cli
To avoid some noise on their end, I figured I wouldn't submit a PR until it's this approach is deemed workable.
## Changelog
[Android][fixed] - `react-native run-android --port <x>` correctly connects to dev server and related error messages display the correct port
Pull Request resolved: https://github.com/facebook/react-native/pull/23616
Differential Revision: D15645200
Pulled By: cpojer
fbshipit-source-id: 3bdfd458b8ac3ec78290736c9ed0db2e5776ed46
Summary:
Fixes build in Xcode 11 beta, the signature for `__unused` was changed. This adds a new check for the new style.
## Changelog
[iOS] [Fixed] - Xcode 11 beta build
Pull Request resolved: https://github.com/facebook/react-native/pull/25146
Differential Revision: D15628404
Pulled By: cpojer
fbshipit-source-id: 781a188a0e1562a3316fbe62920b12b03a44e4a7
Summary:
The accessibilityActions accessors in UIView+React.m are not aligned with the property declaration in the header file.
## Changelog
[General] [Fixed] - Fix accessibilityActions accessors
Pull Request resolved: https://github.com/facebook/react-native/pull/25134
Differential Revision: D15621848
Pulled By: cpojer
fbshipit-source-id: f344689292ae7988e46d0d4263980306d364366b
Summary:
Co-Authored: zamotany
With React Native 0.59.8 the app keeps crashing with indexed RAM bundle on Android with the following error:
```
2019-05-09 11:58:06.684 2793-2856/? E/AndroidRuntime: FATAL EXCEPTION: mqt_js
Process: com.ramtestapp, PID: 2793
com.facebook.jni.CppException: getPropertyAsObject: property '__fbRequireBatchedBridge' is not an Object
no stack
at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
at android.os.Handler.handleCallback(Handler.java:873)
at android.os.Handler.dispatchMessage(Handler.java:99)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:29)
at android.os.Looper.loop(Looper.java:193)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:232)
at java.lang.Thread.run(Thread.java:764)
```
After investigation we found that when using any bundle, let it be non-ram, FIle RAM bundle or Index RAM bundle, the `CatalystInstanceImpl.java` is always using `loadScriptsFromAsset`, which is calling `CatalystInstanceImpl::jniLoadScriptFromAssets` in C++. This method when checking if bundle is a RAM bundle, uses `JniJSModulesUnbundle::isUnbundle` which only check for js-modules/UNBUNDLE - file generated when building File RAM bundle. There is no other logic to handle Indexed RAM bundle, so it figures that the bundle is not RAM, cause there is no js-modules/UNBUNDLE file and tries to load as regular bundle and fails.
In this PR we added check if it is indexed RAM bundle in `jniLoadScriptFromAssets` and handle it if it is.
## Changelog
[Android] [Fixed] fix indexed RAM bundle
Solves https://github.com/facebook/react-native/issues/21282
Pull Request resolved: https://github.com/facebook/react-native/pull/24967
Differential Revision: D15575924
Pulled By: cpojer
fbshipit-source-id: 5ea428e0b793edd8242243f39f933d1092b35260
Summary:
The original reason for vendoring the fetch polyfill was to remove the default blob response type but this was reverted.
Here's a little history around the fetch polyfill and the blob issue:
- Original commit introducing the vendored polyfill: #19333, the goal was to fix a memory leak because our blob implementation doesn't release resources automatically. Not an ideal fix but since the issue was pretty severe and the infra for a proper fix was not in place.
- This introduced an issue when downloading images using `fetch` which was fixed by #22063 which re-added the default blob content type. However that re-introduced the original fetch memory leak.
- We have better infra now with jsi and I was able to get blob deallocation working, see #24405
Currently the vendored fetch polyfill is useless since it was changed back to the original version. We can just use the npm version again. I also updated to 3.0 which brings better spec compliance and support for cancellation via `AbortController`, https://github.com/github/fetch/releases/tag/v3.0.0.
## Changelog
[General] [Changed] - Remove vendored fetch polyfill, update to whatwg-fetch@3.0
Pull Request resolved: https://github.com/facebook/react-native/pull/24418
Differential Revision: D14932683
Pulled By: cpojer
fbshipit-source-id: 915e3d25978e8b9d7507ed807e7fba45aa88385a
Summary:
If you (try to) build React Native for Android without having the NDK properly installed and referenced, you get the following error:
>A problem occurred evaluating project ':ReactAndroid'.
\> Cannot get property 'absolutePath' on null object
This is not an overly helpful diagnostic. This PR results in this message instead:
>ndk-build binary cannot be found, check if you've set $ANDROID_NDK environment variable correctly or if ndk.dir is setup in local.properties
Fixes#25087
## Changelog
[Android] [Fixed] - Show proper error message instead of throwing a NullReferenceException if Gradle cannot find the NDK
Pull Request resolved: https://github.com/facebook/react-native/pull/25088
Differential Revision: D15559271
Pulled By: cpojer
fbshipit-source-id: 35c9a9321af4e4a34bf519144ada48884b48352d
Summary:
This PR solves bug https://github.com/facebook/react-native/issues/24393 for Android. Allows an app to be opened with an NFC tag and getting the url trough Linking.getInitialURL()
## Changelog
[Android] [Fixed] - This branch checks also for `ACTION_NDEF_DISCOVERED` intent matches to set the initialURL
Pull Request resolved: https://github.com/facebook/react-native/pull/25055
Differential Revision: D15516873
Pulled By: cpojer
fbshipit-source-id: e8803738d857a69e1063e926fc3858a416a0b25e
Summary:
Changelog: [Android] [FIXED] - Fix backgroundColor top level prop of TextInput
This diff fixes two issues with the `backgroundColor` top level property of TextInput on Android:
* Now it is possible to set a **string** value for the top-level `backgroundColor` property of TextInput (crashed the app previously):
```
<TextInput backgroundColor="#ffccbb">Hello, React Native</TextInput>
```
* Now it's possible to set an **integer** value for the top-level `backgroundColor` property of TextInput (had no effect previously):
```
<TextInput backgroundColor={0xffccbbff}>Hello, React Native</TextInput>
```
A `customType = "Color"` annotation parameter must be provided for `ReactBaseTextShadowNode.setBackgroundColor(...)` since the color value must be previously processed in JS before sending it over the bridge to the native code. The JS code will parse the color value and return the proper ARGB color integer to the native platforms (https://fburl.com/uqup52tn).
Without providing the custom type for the background color, if a string value is set for the top-level `backgroundColor` property in the JS code, the Android code will crash since it expects an integer value for the color in `ReactBaseTextShadowNode.setBackgroundColor(...)`, but a string will be passed from JS without any conversion and there will be a `ClassCastException` thrown. If an integer value without the alpha component (like `0xffccbb`) is set, the Android native view would get an integer color value with its alpha component set to `0x00`, which means a transparent color.
On a side note: the alpha component of a color must always be set when using an integer value for `backgroundColor` since the JS code, while processing the color type, shifts the rightmost 8 bytes (alpha component) to the leftmost position. If those 8 bytes are not the alpha component, you will get the wrong color in the end. It doesn't seem to be a problem for string values of `backgroundColor` though.
Reviewed By: mdvacca
Differential Revision: D15453980
fbshipit-source-id: f3f5d9c9877cdbce79a67f2ed93ad4589576d166
Summary:
This diff adds a new `--test` option to `js1 build viewconfigs` which will only check that the configs have not changed instead of writing the new/updated files. This will allow us to run sandcastle checks on the view configs
I also improved the output of the script to give better feedback during normal runs including an additional message and a summary of generated files
Reviewed By: TheSavior
Differential Revision: D15372843
fbshipit-source-id: 4988fc2405cc03137b540817e08d4365cb31fc34
Summary: Fixes a flow failure in the generated output and adds trailing commas to pass linting
Reviewed By: yungsters
Differential Revision: D15354725
fbshipit-source-id: 1eac27fa753af595a9a2787426b147e5f49a4e1d
