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 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:
I measured the performance of UIMananger methods and found that `create` method spends a significant amount of time on preallocating views (around 10 ms on my device). Interestingly, this time was actually spent on dispatching operations on the main thread, not on performing those operations. That makes me think about think about the preallocation problem one more time.
(Here and later I discuss preemptive optimistic preallocation views on iOS, but the issues are more-less applicable for all platforms.)
BTW, what's view preallocation? – In React Native we believe that we can get significant TTI wins instantiating platform views ahead of time while JavaScript thread is busy doing reconciliation and the main one is idle.
So, seems the current approach has those downsides:
* We spend too much time on dispatching only (jumping threads, creation Objective-C blocks, managing them in GCD, incrementing atomic refcountes inside `ShadowView` and so on). That's wasteful.
* We don't have much information during preallocations that can help prepare something to save time in the future. We don't know the future size of the component, so we cannot e.g. pre-draw a border or even allocate memory for a future drawing.
* We pre-allocate to much. At the moment of component creation, we don't know will this component be filtered out by view-flattening infra or not, so we always allocate a view for it. That's ~30% more views that we actually need.
* We don't stop allocating (or dispatching instructions for that) after the recycle pool is already filled in. That's also wasteful.
Why is this so bad and how can we fix it properly?..
I thought about this problem for months. And I think the answer is trivial: We don't know the exact shape of the interface until we finish creating it, and there is no way to overcome this problem on the client side. In the ideal world, the server size (or hardcoded manifest somewhere) tells the renderer (at the moment where we started navigating to it) how many views of which type will some surface use.
And until our world is not so perfect, I think we can get a significant performance improvement doing simple preallocation of 100 regular views, 30 text views, and 30 image views during rendering the first React Native surface. So I hardcoded that.
Reviewed By: JoshuaGross
Differential Revision: D14333606
fbshipit-source-id: 96beeb58b546258de1b8fd58550e0ae412b78aa9
Summary:
Right now we rely on the Paper UIManager to update animated node graphs - this hooks us into `RCTSurfacePresenter` in the same way so we are no longer reliant on Paper. Should also help with complex ordering corner cases with pre vs. post operations and restoring defaults when nodes are removed. More info:
https://github.com/facebook/react-native/pull/11819/files
Note that we don't have a way to differentiate animation nodes related to fabric views vs. paper views, so if paper and fabric are both rendering updates simultaneously it's possible they could get processed by the wrong callback. That should be very rare, rarely cause problems even if it does happen, and won't be a problem at all in a post-Paper world.
Reviewed By: shergin
Differential Revision: D14336760
fbshipit-source-id: 1c6a72fa67d5fedbaefb21cd4d7e5d75484f4fae
Summary:
We currently rely on the Paper UIManager calling `uiManagerWillPerformMounting` to flush the animated operations queue, which includes starting and stopping animations. This mostly works right now because Fabric always starts after Paper, but sometimes Paper doesn't fire `uiManagerWillPerformMounting` for a while, which can delay an animation starting.
To fix this, I force a flush of the queues on the UIThread whenever start or stop is called. This should be safe because the order of animation operations is still preserved, and start/stop are (almost?) always called in dedicated event handler loops, so any other updates like changing the way nodes are attached should already have been processed from a previous JS execution loop.
Reviewed By: JoshuaGross
Differential Revision: D14313502
fbshipit-source-id: 2a2b0c614fd1a591bd04b6b3fafcc09ff6c9d6e7
Summary: Use the codegen for the Slider component with the new `inferfaceOnly` option
Reviewed By: TheSavior
Differential Revision: D14295981
fbshipit-source-id: 0482572892fbcffada43c7c6fbf17e70546300b8
Summary:
Implement TODO, implement the nativeID functionality in a more efficient way instead of searching the whole view tree.
[iOS] [Fixed] - Implement the nativeID functionality in a more efficient way
Pull Request resolved: https://github.com/facebook/react-native/pull/23662
Differential Revision: D14323747
Pulled By: shergin
fbshipit-source-id: 3d45dbf53ad2b6adb79b4331600d53b51ede76d4
Summary:
Between invalidating a bridge and suspending its JS thread, native modules may have their methods called.
Only warn when a native module has been invalidated, which happens right before its JS thread is suspended.
Avoid initializing a native module's instance if its bridge is invalidated.
/cc fkgozali f945212447 (commitcomment-32467567)
[iOS] [Fixed] - Properly validate JS->native method calls
Pull Request resolved: https://github.com/facebook/react-native/pull/23658
Differential Revision: D14287594
Pulled By: fkgozali
fbshipit-source-id: 89dd1906a0c55f3f48ba4ff220aac0cddf2eb822
Summary:
We have parse code to try to support exported method parameter annotated `__unused` and `nullable`, but actually, seems we don't support it entirely, for example, we parse `__unused` firstly, then we parse `nullable`, actually, this case not exist, because `nullable` macro must appear right after `(`, before `__unused`, so we can't parse success, leads to error signature and crash.
[iOS] [Fixed] - Fixed method invoke when both nullable and __unused exist
Pull Request resolved: https://github.com/facebook/react-native/pull/23726
Differential Revision: D14298563
Pulled By: cpojer
fbshipit-source-id: 934e1d384a5d67b7bbf117fd2dec51f50979c979
Summary:
We need to check `body[@"target"]` wether equal to `nil`, if it is, return to prevent crash.
[iOS] [Fixed] - Fixed crash if event doesn't have body parameter
Pull Request resolved: https://github.com/facebook/react-native/pull/23711
Differential Revision: D14298543
Pulled By: cpojer
fbshipit-source-id: d5e8cd69438f323ae102e61618c0371a01bee347
Summary:
For the `NullabilityPostfix`, we can use `_Nullable` or `__nullable`. Please see https://developer.apple.com/swift/blog/?id=25 , and we also use it in our code.
[iOS] [Added] - Added support of __nullable and __nonnull for module exported method signature
Pull Request resolved: https://github.com/facebook/react-native/pull/23731
Differential Revision: D14298483
Pulled By: cpojer
fbshipit-source-id: 4dd3188f51be3808ea2b97ce19aa7a85ea1f4a9e
Summary: This diff removes the "isLayoutable" parameter from SchedulerDelegate.schedulerDidRequestPreliminaryViewAllocation. This now can be infered from the shadowView parameter
Reviewed By: shergin
Differential Revision: D14296481
fbshipit-source-id: b200504f9c2bef41f0a70257f1f5a274fbe97cbb
Summary:
Update Props during pre-allocation avoiding re-updating the same props during mounting
MobileLab test showed an improvement of:
MARKETPLACE_YOU_TTI_SUCCESS: -3.34% = 58ms
Reviewed By: shergin
Differential Revision: D14252170
fbshipit-source-id: 1f4e9ad5dcecbc06651fa065135ffeed4892d984
Summary:
We are now generating the native cpp files for ActivityIndicatorView via Buck.
Deleting the hand written files and switching over.
Reviewed By: TheSavior
Differential Revision: D14247446
fbshipit-source-id: 63a6df3254e4184de6c8abb9ea2c89654ad54398
Summary: TurboModule needs sync calls from JS to native, and that's not supported with the current Chrome debugger. Until we have proper solution, disable it to avoid confusion.
Reviewed By: PeteTheHeat
Differential Revision: D14286383
fbshipit-source-id: e93903bf8fdfc714960d0d58e3f3eb0442c811bd
Summary: Add assorted missing includes in `xplat` that would be exposed by future changes.
Reviewed By: ispeters, nlutsenko
Differential Revision: D14213660
fbshipit-source-id: 329f133784015fe20ee99feaec8ef05e117fe3a6
Summary:
This is a back-out of D14214844, we noticed that this regressed TTI for Marketplace You screen running in Fabric
Original commit changeset: b81005f2bf49
Reviewed By: JoshuaGross
Differential Revision: D14247897
fbshipit-source-id: de0cea92b437b2fbcd075f0d6a0066156800e3f0
Summary: The changes allows to get the State object on mounting layer and initiate the updates.
Reviewed By: mdvacca
Differential Revision: D14217185
fbshipit-source-id: 370644e06e350932e93c39adbe46544b071c28b3
Summary:
We already only support `iOS9+`, so we can remove all compatible codes now.
[iOS] [Fixed] - Remove compatible system code for iOS8 and before
Pull Request resolved: https://github.com/facebook/react-native/pull/23656
Differential Revision: D14224986
Pulled By: hramos
fbshipit-source-id: cac9ffe6788dd3eaf4f4f5f2b219f325ba78e85f
Summary: That's bummer that we have to do it, but it's actually reasonable. Files in `core` and `events` depend on each other creating circular dependencies and other similar hard problem.
Reviewed By: mdvacca
Differential Revision: D14195022
fbshipit-source-id: 96a44ae28631cc9ccd7d7de72a94526f9e0dd12a
Summary:
This diff changes the pre-allocation of Images update the props on the ImageViews during the creation of ShadowNodes instead of during rendering.
The purpose of this change is to optimize TTI.
Reviewed By: shergin
Differential Revision: D14214844
fbshipit-source-id: b81005f2bf494f62f421dc24846e1561e13b9a87
Summary:
Not super clean, but not terrible.
Unfortunately this still relies on the old Paper UIManager calling delegate methods to flush the operations queues. This will work for Marketplace You since Paper will be active, but we need to fix this, along with Animated Events which don't work at all yet.
Random aside: it seems like taps are less responsive in fabric vs. paper, at least on iOS. There is a sporadic delay between the touches event coming in nativly to the JS callback invoking the native module function to start the animation - this will need some debugging.
Reviewed By: shergin
Differential Revision: D14143331
fbshipit-source-id: 63a17eaafa1217d77a532a2716d9f886a96fae59
Summary: [iOS] [Changed] - There seems to be a potential race condition during reloading that could cause "double registration" of modules. This should be mostly harmless, so downgrade to warning for the message instead of redboxing.
Reviewed By: cpojer
Differential Revision: D14179922
fbshipit-source-id: 5c16ac674f633a548353277d9f875544ed10ba9b
Summary:
This PR implements the first part of [RFC0004: CocoaPods Support Improvements](353d44f649/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects.
The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are:
* `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies.
* The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`.
*Next steps (not in scope of this PR):*
- Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`.
- Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR)
[iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project
Pull Request resolved: https://github.com/facebook/react-native/pull/23559
Differential Revision: D14179326
Pulled By: cpojer
fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
Summary:
When an image source is parsed via `RCTImageFromLocalAssetURL` there seem to be certain situations in which `imageName` is empty from `RCTBundlePathForURL`. Any call to `UIImage imageNamed` with a an empty parameter will throw an exception:
```
CUICatalog: Invalid asset name supplied: '(null)'
```
In my case, the asset URL was pointing to an image in the application sandbox rather than the `NSBundle`. In this case `UIImage imageNamed` was throwing before the call to `NSData dataWithContentsOfURL` below could correctly resolve the image.
This change simply skips the call to `UIImage imageNamed` if no `imageName` value is set.
Pull Request resolved: https://github.com/facebook/react-native/pull/20120
Differential Revision: D14163101
Pulled By: cpojer
fbshipit-source-id: ceec95c02bf21b739962ef5618947a5726ba0473
Summary:
Add an option to dev menu to change packager location on the fly on iOS (similar to Dev Settings in Android)
Pull Request resolved: https://github.com/facebook/react-native/pull/21970
Differential Revision: D14162776
Pulled By: cpojer
fbshipit-source-id: 3cca4f4fbd8c599bd5342ba1ae64905a03270d48
Summary:
Fix scrollview `offset` out of content size in iOS, Android uses `scrollTo` and `smoothScrollTo` which not have this issue.
Fixes like #13594#22768#19970 .
[iOS] [Fixed] - Fixed scrollView offset out of content size.
Pull Request resolved: https://github.com/facebook/react-native/pull/23427
Differential Revision: D14162663
Pulled By: cpojer
fbshipit-source-id: a95371c8d703b6d5f604af0072f86c01c2018f4a
Summary:
Fixes#23500 , if user set prop `contentInsetAdjustmentBehavior="automatic"` of ScrollView, it not works when initial on the screen. We fixes it by filter valid offset, if offset is valid, just return.
[iOS] [Fixed] - Fixed ScrollView adjust inset behavior
Pull Request resolved: https://github.com/facebook/react-native/pull/23555
Differential Revision: D14161593
Pulled By: cpojer
fbshipit-source-id: 01434e55106ffde7f8e39f66dd5b0f02df9b38b1
Summary:
I downgrade the invalid bridge warning because I believe that it is a pain that every time that the JS gets refreshed this warnings are being thrown. If the project increase size and more and more NativeModules are added this warnings just spam the emulator or the device.
I understand the reason of validating if the bridge is valid. However in case of invalidness nothing is done, just the warning is thrown. Hence, the reason of downgrading it to improve the development process.
The error message still exist and it will be in the logs. But it will not spam the development screen
[iOS] [Changed] - Downgrade the Invalid bridge warning message to a log
Pull Request resolved: https://github.com/facebook/react-native/pull/23557
Differential Revision: D14161290
Pulled By: cpojer
fbshipit-source-id: e5608a9b2db5625309fd18d133fe69a9013043f3
Summary:
As part of #22609, this fixes yet more warnings.
- Adding more __unused to params.
- Refactors `isPackagerRunning` to use NSURLSession.
- Turns off suspicious comma warnings
[iOS] [Fixed] - Xcode Warnings
Pull Request resolved: https://github.com/facebook/react-native/pull/23565
Differential Revision: D14161151
Pulled By: cpojer
fbshipit-source-id: 339874711eca718fc6151e84737ccc975225d736
Summary:
This PR reduces the number of warnings in React from 68 to 18. Mostly by marking unused variables. RNTester's warnings are more than halved.
[iOS] [Fixed] - Xcode warnings
Pull Request resolved: https://github.com/facebook/react-native/pull/23553
Differential Revision: D14151339
Pulled By: hramos
fbshipit-source-id: 8255330bf910a69a4c03051d91d7b0de3fadf2d1
Summary: If we don't group accessibility children, we can get into a state where the accessibility frame for our content lines up in such a way that VoiceOver doesn't know to scroll the scroll view, and instead jumps to the next piece of content (like the tab bar at the bottom)
Reviewed By: ikenwoo
Differential Revision: D14141532
fbshipit-source-id: 53b0971f494a39f0eba827e441a4cd9e08317663
Summary:
CALayer will crash if we pass NaN or Inf values.
It's unclear how to detect this case on cross-platform manner holistically, so we have to do it on the mounting layer as well.
NaN/Inf is a kinda valid result of some math operations. Even if we can (and should) detect (and report early) incorrect (NaN and Inf) values which come from JavaScript side, we sometimes cannot backtrace the sources of a calculation that produced an incorrect/useless result.
Besides that, I will investigate why the crash is actually happening, so we might need to fix something in layout engine. But, it general, we cannot capture all errors like that, so we need to have it here anyway.
Reviewed By: JoshuaGross, mmmulani
Differential Revision: D14126058
fbshipit-source-id: 807e5a223bdef48af9a3b7210803863431e8c507
Summary: Use the new copyright header format used elsewhere in the React Native repository.
Reviewed By: shergin
Differential Revision: D14091706
fbshipit-source-id: b27b8e6bcdf2f3d9402886dbc6b68c305150b7d5
Summary:
@public
Makes logging implementation internal to Yoga.
Breaking changes: removed `YGLog` and `YGLogWithConfig`.
The upcoming changes to the JNI layer (removal of weak global refs for each node) requires adding additional parameters to the logging functions that will only be available when calculating layout.
Reviewed By: SidharthGuglani
Differential Revision: D14123390
fbshipit-source-id: 468e4a240c190342868ffbb5f8beb92324cdfdd6
Summary:
1. We expose the `initialAppState` for Android in #19935, so we can remove the fallback check for Android.
2. Rename `RCTCurrentAppBackgroundState` to `RCTCurrentAppState`, it's a private file function, so it's safe to rename, `RCTCurrentAppState` is more suitable because we actually get app state, not app background state.
[Android] [Enhancement] - Remove android `initialAppState` fallback check.
Pull Request resolved: https://github.com/facebook/react-native/pull/23487
Differential Revision: D14121293
Pulled By: cpojer
fbshipit-source-id: fec196cef2969fe6f6f1571f4ebcafcec26266a1
Summary: The hacks we added for lazy viewmanagers don't really apply to TurboModule lookup system, so let's enable lazy lookup as needed only if TurboModule is enabled.
Reviewed By: PeteTheHeat
Differential Revision: D14116548
fbshipit-source-id: 701e963ef0593cd890198725f8cb6d0d29434cd9
