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
Summary:
Right now we have a raw pointer to the js runtime in Java and we pass that to EventBeatManager's constructor; this diff adds a setter for the runtime ptr and removes it from the member initializer list, so that you can set it later from cpp instead.
Q: Should I just rewrite this to use RuntimeExecutor instead?
Reviewed By: shergin
Differential Revision: D14318893
fbshipit-source-id: 1221dd5959927967bad870f15c901c15e5455874
Summary: Easy cleanup of commented code in TextLayoutManager, I kept the TODOs to complete the code in the future
Reviewed By: shergin
Differential Revision: D14372356
fbshipit-source-id: ff87f9b09e9f40ed021256f463e39299467b3e0e
Summary: This diff is a part of an effort to resolve build errors that appear when compiling with the latest version of clang.
Reviewed By: shergin
Differential Revision: D14369797
fbshipit-source-id: e4c6f53e293f336efad18597f9d2705c025e1051
Summary:
Initially if a `react-native-web` project were to use a library that required internals `expo/webpack-config` would polyfill those internals. This `Platform.web` was used for cases where `react-native` modules needed other internal `react-native` modules, ex: `Animated/src/AnimatedEvent -> Renderer/shims/ReactNative -> Renderer/oss/ReactNativeRenderer-dev -> Core/InitializeCore -> Devtools/setupDevtools -> WebSocket/WebSocket -> Utilities/Platform`
The consensus is that if any `react-native` library references a `react-native` internal (ex: `react-native/*`), it should continue to throw errors. We've removed the use of internals from all of the Unimodules, `react-navigation`, and `react-native-gesture-handler`. This covers a wide enough area for a lot of projects to get web support.
* Add emitters for libs referencing internals necolas/react-native-web#1275
* Remove monkey patch that bundles RN, libs that use internals will crash instead expo/expo-cli#409
* Remove all unsupported internals and polyfills from the Expo suite expo/expo#3676
* Remove internals from react-native-gesture-handler kmagiera/react-native-gesture-handler#406
* Related #23387
[GENERAL] [REMOVED] - Platform.web.js
Pull Request resolved: https://github.com/facebook/react-native/pull/23830
Differential Revision: D14406145
Pulled By: hramos
fbshipit-source-id: bdda99a334d33f5543fdb954eb80e2e7186f985a
Summary:
This change fixes https://github.com/facebook/react-native/issues/23645.
The issue is that the `YGMarker.cpp`, `YGValue.cpp`, `YGConfig.cpp` and `log.cpp` files are already included in the Yoga compilation unit, so including these files in React's compile sources too results in "duplicate symbols" errors when loading React Native with `-force_load` (which behaves slightly differently to `-ObjC` - according to a colleague, "ObjC will scan through each object file in each library and force linking of any object file that contains Objective C code, while force_load will link every object file in a particular staticlib (regardless of whether or not the object file contains Objective C code)").
These changes seemed to be introduced by a few commits:
- D13819111 -> 43601f1a17
- D13439602 -> b5c66a3fbe
- D14123390-> e8f95dc7a1
- D7530369 -> 95f625e151
Perhaps we need to check with the original authors/any C++ experts to confirm if this fix is correct - it compiles for me but I'm not sure what the original intention of these changes was.
[iOS] [Fixed] - Remove duplicated Yoga compile sources to prevent "duplicate symbols" errors when linking using -force_load
Pull Request resolved: https://github.com/facebook/react-native/pull/23823
Reviewed By: davidaurelio
Differential Revision: D14387657
Pulled By: hramos
fbshipit-source-id: d85221b6dc1a0377662624f4201b27222aed8219
Summary: D13103990 updated the flow types for ScrollView. This diff just updates our internal callsites to address the flow errors.
Reviewed By: TheSavior
Differential Revision: D14305453
fbshipit-source-id: 58fe28da06a6c83a81ba29bebe96e74c2f3ed5e5
Summary:
Relates to #22100.
I left 2 `$FlowFixMe`s as I was not sure how to handle generic `React.Element<>` and which native props can I pass to ScrollView (would be cool to document it once we got proper types there).
I also got rid of `InternalScrollViewType` because we have better typings in original `ScrollView` now.
Pull Request resolved: https://github.com/facebook/react-native/pull/22301
Reviewed By: TheSavior
Differential Revision: D13103990
Pulled By: RSNara
fbshipit-source-id: 9664ee9d7f570b00992215e10901e5317f24fe5c
