Summary: Missed in D14434796. We'll think of adding a lint rule in open source for this separately.
Reviewed By: rubennorte
Differential Revision: D14477475
fbshipit-source-id: 9002d9a7feadcb42f84031f21ad23c481ac304e3
Summary:
This function returns a HOC that passes `scopedPerformanceLogger` as a prop to the wrapped component. That HOC
can be used whenever we can't declare `static contextType` as `PerformanceLoggerContext` on a component,
for example because React supports only one React Context per component.
Reviewed By: sahrens
Differential Revision: D14385560
fbshipit-source-id: 41971b4bf499f336c34b9220a3ee97c4ed89498d
Summary:
I was looking at the coverage report of the JavaScript code in the `Libraries` folder, and found some of the modules and functions to be (partially) untested. I believe that adding tests to them would formally capture their behaviour and avoid future regressions. In this PR, I've added some unit tests for 3 utility components.
Perhaps a more general question: Are these kinds of PRs appreciated? I'd be interested in submitting more of them in the future.
Not applicable, since it only adds tests.
Pull Request resolved: https://github.com/facebook/react-native/pull/23903
Differential Revision: D14477601
Pulled By: cpojer
fbshipit-source-id: c0700c5b514cd0df983fecfd91c93fc2bd049f5d
Summary:
Adds a deprecation warning for using status-bar package
Lean Core Issue: #23313
[General] [Deprecated] - Deprecated StatusBar as it has now been moved to react-native-community/statusbar
Pull Request resolved: https://github.com/facebook/react-native/pull/23898
Differential Revision: D14477606
Pulled By: cpojer
fbshipit-source-id: 2955374446f879c3e7cfea97cb8c379ec8b003cd
Summary:
I ran into a build error when `xcodebuild` would invoke a custom script (in my case `sentry-cli`):
```
error: Could not parse Info.plist file
caused by: invalid data
```
Upon further investigation it turned out the parse error was **caused by a comment**, and I found some other oddities with the default `Info.plist` template files:
- The problematic comment is a **dead link** (website does not exist)
- The main Info.plist contains a **duplicate entry** for `NSLocationWhenInUseUsageDescription`
- Some entries are _reordered_ and the comment is removed when modifying/saving the file in Xcode
This PR fixes these inconsistencies, unnecessary customizations, and potential sources of errors.
[iOS] [Fixed] - Fix Info.plist templates to prevent parse error
Pull Request resolved: https://github.com/facebook/react-native/pull/23924
Differential Revision: D14477557
Pulled By: cpojer
fbshipit-source-id: 6d734c5aa3b800f05394db189e8d8db63be8e353
Summary:
D14323747 broke SSTs. This PR optimized implementation of nativeID. Instead of searching entire tree to find a view, it uses a map to cache views which have nativeID set. The map uses keys with format <nativeID-rootViewTag>. Finding the rootViewTag causes a race condition, due to [this syncing code](https://fburl.com/93vqzlbg). The SST runner attempts to read the map to find a [SST view](https://fburl.com/8zadz024) before that view is added to the map.
My fix is to change the key format to simply <nativeID>. Product code should not duplicate nativeID since it is used to uniquely identify react managed views from native. I'll comment on PR with this fix.
Reviewed By: shergin, mmmulani
Differential Revision: D14416262
fbshipit-source-id: 3b707f2ff4049ac83ac8861e3cda435224d973d8
Summary:
Accidentally I noticed that the signature of Folly's hash_combine is different from boost's one.
The Folly's one is:
`size_t hash_combine(const T& t, const Ts&... ts)`, so the first argument is immutable and the method returns the result normally.
It means that all hashes that we compute in Fabric using `hash_combine` were `0`.
So I fixed it.
I have no idea why this difference exists, but some modern papers suggest that folly's variant has good chances to be standardized.
E.g.: http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0814r0.pdf
Technically, it should improve performance, but I doubt that it can be more than 1-2 ms per screen TTI.
Reviewed By: JoshuaGross
Differential Revision: D14430380
fbshipit-source-id: 97da999ee5780b940bb789bc3eb5bf9f89c194ca
Summary:
Part of: #23313.
This moves the `RCTTest` lib from `Libraries/RCTTest` to `RNTester/RCTTest`. This also removes `takeSnapshot` from React Native, and implements it as a standalone module in RNTester called `ScreenshotManager`.
[General] [Removed] - RCTTest & ReactNative.takeSnapshot
Pull Request resolved: https://github.com/facebook/react-native/pull/23721
Differential Revision: D14434796
Pulled By: PeteTheHeat
fbshipit-source-id: d6e103a0ea0b6702701cdb5ce8449163ca4628ce
Summary:
While the proper typographical terminology is [Strikethrough](https://en.wikipedia.org/wiki/Strikethrough), we should still support `line-through` as it goes through a deprecation phase.
[iOS] [Added] - line-through support for fabric text components
Pull Request resolved: https://github.com/facebook/react-native/pull/23911
Differential Revision: D14460610
Pulled By: shergin
fbshipit-source-id: 0dae41b765f21d166ea3618c463ebe1330607b30
Summary:
Fix#23849. When setting a semi-transparent background on text, it becomes obvious that we are drawing the background color twice. Since background color is handled by the view, we should not need to draw the glyph background color too.
| Before | After |
| ------------- |-------------|
|<img src="https://i.imgur.com/8JGpKTC.png" width="300"> | <img src="https://imgur.com/qjKU9Ze.png" width="300">
[iOS] [Fixed] - Semi-transparent backgrounds on text
Pull Request resolved: https://github.com/facebook/react-native/pull/23872
Differential Revision: D14430501
Pulled By: shergin
fbshipit-source-id: 19743415b2d20a3b941b1c80bd7b47144e929458
Summary: Upgrade Jest and related packages to their latest stable version (24.5.0)
Reviewed By: mjesun
Differential Revision: D14424512
fbshipit-source-id: 6292b9f95c3315a520233b80ae06074d69a0ea3b
Summary:
@public
This bumps Prettier to v1.16.4
Only format source files were updated.
Reviewed By: mjesun
Differential Revision: D14454893
fbshipit-source-id: 72f9872fe764a79dbf0d9fab9bebb1456b039f2f
Summary: Change the codegen `srcs` to match any `**/*Schema.js`
Reviewed By: TheSavior
Differential Revision: D14401232
fbshipit-source-id: 61e60b1c9ca2f33efacc5caa1903b02a93cc644e
Summary:
Moves rn_codgen to rn_library behind a `codegen` flag to limit the number of rules we generate
WIth this, modules with native components can enable the react-native-codegen schema parsing by just updating their buck rule to:
```
rn_library(
name = 'lib',
codegen = True,
// ...
)
```
Reviewed By: TheSavior
Differential Revision: D14401263
fbshipit-source-id: 1675bc28389db64da10153c988bb4eb00d715056
Summary:
Moved all layout outputs fields which are set always on yoga node java object.
This change set is for adding experiment for layout outputs batching using a float array
Reviewed By: davidaurelio
Differential Revision: D14355025
fbshipit-source-id: 371d9c49fcb631efa8a79b62f8051ba5a17c232c
Summary: These constants are used for setting bit fields so they should be in power of 2
Reviewed By: davidaurelio
Differential Revision: D14384999
fbshipit-source-id: fa1f6994c874aff7a039ca98d5947cba317fa749
Summary:
Currently, when relative sizes are given in margin or padding stylings (be it a percentage or an auto measure), the inspector crashes, due to frame rendering not properly handling those kinds of measurements. This PR adds a resolution step for them:
* Percentages are evaluated relative to the window size.
* I decided to simply not render `auto` margins/paddings, due to the complexities involved (e.g. when the margin is between multiple elements with relative sizes).
Since the inspector does not crash anymore on relative sizes on paddings or margins, I believe that this addresses #17496.
Fixes#17496
[General] [Fixed] - Fix inspector rendering of relative margins and paddings
Pull Request resolved: https://github.com/facebook/react-native/pull/23804
Differential Revision: D14437273
Pulled By: cpojer
fbshipit-source-id: c9f0f71a2e1b2399a2b2148cef2124787703ead3
Summary:
On conditional rendering if child is null then the PickerAndroid breaks.
when conditional rendering is used then picker breaks when the child is null.
This conditional rendering inside Picker fails when a is 1, because child will be null in PickerAndroid.android.js.
```
{
this.state.a === 2 && <Picker.Item label="value" value="value" />
}
```
[ANDROID] [FIXED] - Filter props.children.
Pull Request resolved: https://github.com/facebook/react-native/pull/23884
Differential Revision: D14436860
Pulled By: cpojer
fbshipit-source-id: 6a8fca604acf77c20729f26a53cd7f67e514deac
Summary:
I moved `devDependencies` to `dependencies` section of `packages/eslint-config-react-native-community`, to avoid the need for installation of them in the main projects. Now the installation should match the guide, from https://github.com/facebook/react-native/tree/master/packages/eslint-config-react-native-community
[General] [Changed] - Moved `devDependencies` of eslint config to `dependencies` section.
Pull Request resolved: https://github.com/facebook/react-native/pull/23766
Differential Revision: D14436081
Pulled By: cpojer
fbshipit-source-id: 770110eb4b2b6dfbbb7456fd1b69e20a8473a4e2
Summary:
…ake sure Android does not crash from bad params when using useNativeDriver
Android apps crash when using Animated useNativeDriver: true and the toValue is not a number. See issue here with test case. [Issue](https://github.com/facebook/react-native/issues/23810)
[Android] [fixed] - Fix crash when using Animated with useNativeDriver and a non Number toValue
Pull Request resolved: https://github.com/facebook/react-native/pull/23812
Differential Revision: D14436113
Pulled By: cpojer
fbshipit-source-id: 89fb3180c08cc5ffb817b3984dacda0a80b4f703
Summary:
We need to add SurfacePresenterStub header to project header for tvOS.
Related 544d9fb10b
CC. sahrens .
[iOS] [Fixed] - Add SurfacePresenterStub header to project header for tvOS
Pull Request resolved: https://github.com/facebook/react-native/pull/23855
Differential Revision: D14436185
Pulled By: cpojer
fbshipit-source-id: b59369541e78967346fc9e9fa6a9685725834f39
Summary:
Each time, when I run `iOS` tests like `RNTesterIntegrationTests`, Xcode will copy the bundle in `DerivedData` directory, and we added `RNTesterUnitTestsBundle.js` to bundle, so it leads `Haste module naming collision`, I think we can add `DerivedData` directory to blacklist.
<img width="752" alt="c7d7dcbd-6507-481a-a8ef-64f16fec3a6f" src="https://user-images.githubusercontent.com/5061845/53960917-6888cc80-4122-11e9-9d1d-faac97f73a26.png">
[iOS] [Fixed] - Add DerivedData to BLACKLISTED_PATTERNS for haste paths
Pull Request resolved: https://github.com/facebook/react-native/pull/23807
Differential Revision: D14436103
Pulled By: cpojer
fbshipit-source-id: fa4bbd87d429f70167253aa38ff20049c9df58b4
Summary:
After some works, we already support some attributes to text input's placeholder, so we can add example to show it in RNTester.
[iOS] [Added] - Added placeholder attributes example to RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/23769
Differential Revision: D14436086
Pulled By: cpojer
fbshipit-source-id: 8637dcb82a2e6aa51e351fd696b049aaee893997
Summary: This diff wires up everything from the previous 8 diffs. After this, all codepaths that execute `modulesConformingToProtocol` in `RCTImageLoader.m` will instead use iOS plugins to retrieve the modules on FBiOS.
Reviewed By: fkgozali
Differential Revision: D14360252
fbshipit-source-id: 6f0cecfa8dffa1955ba2f9ed54bc1c130fb23341
Summary:
This fixes a few memory leaks in fabrics handling of colors for borders, when using CGColorRef's we must be diligent about releasing the memory back.
[iOS] [Fixed] - Border style memory leaks
Pull Request resolved: https://github.com/facebook/react-native/pull/23815
Differential Revision: D14431250
Pulled By: shergin
fbshipit-source-id: dc663c633ae24809cb4841800d31a6ac6eeb8aa5
Summary:
<!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? -->
I have used RN for a long time, and for all this time, crash reporting has been less great than native development crash reporting. At some point, companies like sentry, bugsnag and a bunch of others started supporting sourcemaps for js crashes in RN, which helped a lot.
But native crashes were (and still are) much harder to diagnose.
..Until now :D
I have make a repo of a sample RN app, included this PR in it, and some code and screenshots to help.
The repo is [here](https://github.com/pvinis/react-native-project-with-crash-heaven-pr).
I was trying to get good crash reports from native crashes in iOS for a looong time. I spoke with people in sentry, in bugsnag and more, and I could not get this solved. There was no clear way to get the **native** crashed to display correctly.
I made two repos here, one for [sentry](https://github.com/pvinis/SentryBadStack) and one for [bugsnag](https://github.com/pvinis/BugsnagBadStack), demonstrating the correct js handling and the bad native handling.
After all this, and talks with their support, twitter etc, I investigated further, on **why** this was happening. I thought there must be some reason that native crashes look bad in all the tools, and in the same way. Maybe it's not their fault, or up to them to fix it, or maybe they didn't have the experience to fix it.
In a test project I created, I checked what's up with the `RCTFatalException`, and I found out that the React Native code is catching the `NSException`s that come from any native modules of a RN app and converting it into an string and sending it to `RCTFatal` that created an `NSError` out of that string. Then it checks if the app has set a fatal error handler and if not, goes ahead and throws that `NSError`.
The problem here is that `NSException` has a bunch more info that the resulting `NSError` is missing or is altering. Turning the callstack into a string renders crash reporting tools useless as they are missing the original place the exception was thrown, symbols, return addresses etc. In both repos above it can be seen that both tools were thinking that the error happened somewhere in the `RCTFatal` function, and it did, since we create it there, losing all the previous useful info of the original exception. That leaves us with just a very long name including a callstack, but very hard to actually map this to the code and dsym.
I added a fatal exception handler, that mirrors the fatal error handler, as the error handler is used around React Native internal code.
Then I stopped making a string out of the original `NSException` and calling `RCTFatal`, and I simply throw the exception. This way no info is lost!
Finally, I added some code examples of native and js crashes and added a part in the `RNTester` app, so people can see how a js and a native error look like while debugging, as well as try to compile the app in release mode and see how the crash report would look like if they connect it to bugsnag or sentry or their tool of choice.
I have attached some images at the bottom of this PR, and you can find some in the 3 repos I linked above.
[iOS] [Fixed] - Changed the way iOS native module exceptions get handled. Instead of making them into an `NSError` and lose the context and callstack, we keep them as `NSException`s and propagate them.
[General] [Added] - Example code for native crashes in iOS and Android, with buttons on RNTester, so developers can see how these look when debugging, as well as the crash reports in release mode.
Pull Request resolved: https://github.com/facebook/react-native/pull/23691
Reviewed By: fkgozali
Differential Revision: D14276366
Pulled By: cpojer
fbshipit-source-id: b308d5608e1432d7676447347ae77c0721094e62
Summary:
This adds new functionality to the `Image` component by allowing you to retrieve the width and height of an image just like you'd do with [`Image.getSize`](https://facebook.github.io/react-native/docs/image.html#getsize) but _with_ the ability to provide headers to your request.
Why would you need this you ask? Well, imagine that you have an image that you're loading into your `Image` component that is protected and you get access by using a token in a header (or something similar). That would work. However, getting the dimensions isn't possible since you can't provide those same headers.
This is something that is bothering me when using a third-party library (https://github.com/archriss/react-native-image-gallery) and instead of implementing this just for that single library I imagined that it would be useful for anyone else that needs to get the image dimensions before displaying it.
[Android] [Added] - Added Image.getSizeWithHeaders
[iOS] [Added] - Added Image.getSizeWithHeaders
Pull Request resolved: https://github.com/facebook/react-native/pull/18850
Differential Revision: D14434599
Pulled By: cpojer
fbshipit-source-id: 56d5e58889ddf7ddc12d5f6f7d9dc6921fa17884
Summary:
DatePickerIOS tests stopped working after US changed their time zone on CircleCI. I decided to update the tests to be more reliable, by:
- removing "timezoneoffset" from the examples - I don't think it's needed. We don't demonstrate other props and it was causing us some troubles when timezones actually changed
- changing "interval" example from "time-only" to "datetime" because there's a known bug that prevented the previous example from working https://github.com/facebook/react-native/issues/9566
- splitting the label to two: one for date and other one for time, so that we can match the date only when we test "date" mode only
[IOS] [FIXED] - Improved reliability of DatePickerIOS e2e tests
Pull Request resolved: https://github.com/facebook/react-native/pull/23861
Differential Revision: D14434324
Pulled By: cpojer
fbshipit-source-id: 0f82b7e94bb1cb6ce75b44badd0064d1754370b9
Summary:
The Stale bot closes issues that have been inactive for 97 days (90 days until marked as stale, then 7 days of no activity before it is closed). This helps us focus on issues that affect new releases, and gets rid of drive-by issues where there has been no follow up. This process, however, does not acknowledge there's a type of issue that trascends releases and which the team might want to keep track of in order to fix in a future release.
The "Resolution: Backlog" label can be used to mark these types of issues, and keep the bot from closing them.
[General] [Added] - GitHub: Add Backlog label
Pull Request resolved: https://github.com/facebook/react-native/pull/23789
Differential Revision: D14429112
Pulled By: hramos
fbshipit-source-id: ddec7d994a40e46b43de45b79a812fd4dbd28e6a
Summary:
@public
Removes the configuration field to avoid weak JNI refs. It is no longer used.
Reviewed By: marco-cova
Differential Revision: D14424594
fbshipit-source-id: f0877022615a11ac5079354e0977c6893b7d58d7
Summary:
@public
Completely removes the usage of weak JNI refs.
This is great, because node allocation and deallocation no longer go through a VM-global lock to access the weak reference table.
This is also great, because we can no longer overflow that ref table.
Performance is comparable to weak refs.
Reviewed By: marco-cova
Differential Revision: D14423068
fbshipit-source-id: 62003d2d6fd971e91460a26fb3477046f26e2ba5
Summary:
Fixes#21639 , seems we tried to fix this before, please see related `PR` like [D10392176](36507e4a3c), #18627, but they don't solve it totally.
[iOS] [Fixed] - Fix TextInput maxLength when insert characters at begin
Pull Request resolved: https://github.com/facebook/react-native/pull/23472
Reviewed By: mmmulani
Differential Revision: D14366406
Pulled By: ejanzer
fbshipit-source-id: fc983810703997b48824f84f2f9198984afba9cd
