Summary:
Change the function called when an error is returned from the completionHandler of the `RCTJavaScriptLoader(loadBundleAtURL:onProgress:onComplete:)`.
* AS-IS
- `RCTLogError()`
- This error method does not post any notification for users. So users cannot receive notification when `RCTJavaScriptLoader(loadBundleAtURL:onProgress:onComplete:)` complete with error.(i.e. bundleURL is is invalid but not nil, `http://1`, `http://localho:8081/index.bundle`)
* TO-BE
- `handleError(error:)`
- Call this method will post notification for users when `completionHandler` fails with error.
[iOS] [Fixed] - Change the function called when an error is returned from the completionHandler of the `RCTJavaScriptLoader(loadBundleAtURL:onProgress:onComplete:)`.
Pull Request resolved: https://github.com/facebook/react-native/pull/23837
Differential Revision: D14538790
Pulled By: cpojer
fbshipit-source-id: da3306904c0d8113d204edfaa0f9e2a23793981a
Summary:
Put `prepareForRecycle` to last before enqueue to recycle pool, ensure only call it when count lower than RCTComponentViewRegistryRecyclePoolMaxSize.
cc. shergin .
[General] [Changed] - Reorder prepareForRecycle before adding recycle pool
Pull Request resolved: https://github.com/facebook/react-native/pull/24025
Differential Revision: D14536843
Pulled By: shergin
fbshipit-source-id: 82a816e2c0afb5a6bb72637d7d55d6a4fda708af
Summary:
We need to remove adding png file extension when path has not extension. Two reasons:
1. `imageWithContentsOfFile` or other `UIKit` methods can load png image correctly, even if path has not `png` file extension.
2. Sometimes, people may have file that actually not have file extension, it's the designated behavior for user. Like #23844 .
CC. sahrens cpojer .
[iOS] [Fixed] - Remove explicitly add png file extension when load local image
Pull Request resolved: https://github.com/facebook/react-native/pull/23864
Reviewed By: shergin
Differential Revision: D14425373
Pulled By: hramos
fbshipit-source-id: 3cc06c9a3d68cadf652c1de742f3cce26258c874
Summary:
I encountered invalid bridge error when I develop (reload high frequency) some times, and if it happened, I only can restart the app, because we would always show error invalid message if we trigger reload command. So I recommend Change invalid bridge log level from error to warn, I think it's enough.
cc. cpojer .
<img width="375" alt="892C97F4-E910-4E3B-935A-65C899916E6E" src="https://user-images.githubusercontent.com/5061845/54538344-0d32c600-49cf-11e9-818c-0e4cb5a0a518.png">
[iOS] [Fixed] - Change invalid bridge log level from error to warn
Pull Request resolved: https://github.com/facebook/react-native/pull/24005
Differential Revision: D14504820
Pulled By: cpojer
fbshipit-source-id: f24c4876fdb3e64183c09c5ddc598a8c87e405a7
Summary:
This is the couple of hacks I used after I finished #23802 in order to get fabric working on RNTester. This is inspired from prior work by kmagiera.
The goal of this PR is to show others what I’m struggling with, and to eventually merge it sans hacks.
- Yarn Install
- Uncomment the commented out pods in RNTester's pod file
- Open RNTesterPods workspace
- Run App
- this is only for pods, the non-pod RNTester will no longer work until updated with fabric too.
- `SurfaceHostingView` & `SurfaceHostingProxyRootView` both try to start the surface immediately, this leads to a race condition due to the javascript not having loaded yet, the hack here is:
1. Swizzle the `start` method on `RCTFabricSurface` to no-op when called.
2. Add observer for `RCTJavaScriptDidLoadNotification`
3. Call private method `_startAllSurfaces` on `_surfacePresenter` in AppDelegate when we receive `RCTJavaScriptDidLoadNotification`.
[General] [Added] - Use Fabric in RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/23803
Reviewed By: shergin, mdvacca
Differential Revision: D14450726
Pulled By: fkgozali
fbshipit-source-id: 8ae2d48634fecb60db539aaf0a2c89ba1f572c27
Summary: Several things need to ironed out: 1) LocalState in Fabric C++, 2) setting dimensions of BottomSheet component to 0,0 for parent.
Reviewed By: shergin
Differential Revision: D14426167
fbshipit-source-id: 45a90a7971c87672872108a9e360926b4a6095f0
Summary:
From https://github.com/facebook/react-native/pull/23861#issue-260337314
> changing "interval" example from "time-only" to "datetime" because there's a known bug that prevented the previous example from working
We need to ensure set minuteInterval after set datePickerMode, otherwise minuteInterval invalid in time mode.
cc. grabbou cpojer .
[iOS] [Fixed] - Fixed minuteInterval invalid in time mode
Pull Request resolved: https://github.com/facebook/react-native/pull/23923
Differential Revision: D14477549
Pulled By: cpojer
fbshipit-source-id: 2c612d488b6d592b1907e150df5e07fe83132829
Summary:
As a follow-up to this other PR #23839, it adds support for other, iOS only, flags into `AccessibilityInfo`.
It adds these other 4 methods:
* `isBoldTextEnabled()`
* `isGrayscaleEnabled()`
* `isInvertColorsEnabled()`
* `isReduceTransparencyEnabled()`
P.S: Android implementation for those methods just return `false` (with `Promise.resolve(false)`)
And the corresponding event listeners:
* `boldTextChanged`
* `grayscaleChanged`,
* `invertColorsChanged`,
* `reduceTransparencyChanged`
Pull Request resolved: https://github.com/facebook/react-native/pull/23913
Differential Revision: D14482214
Pulled By: cpojer
fbshipit-source-id: b97725fd12706957d4dad880a97e6b0993738272
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:
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:
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:
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
Summary:
Context: https://fb.workplace.com/groups/735885229793428/permalink/2329819300400005/
A large number of RN SSTs (https://fburl.com/screenshot_tests/itlks3mn) stopped working last week. Turns out I silently broke them with D13981728.
The issue is that SSTs were being run with `RCTRunningInTestEnvironment == false`. When D13981728 changed that, borders began drawing from a different code path (this diff). Somehow, using the graphics context to draw borders breaks https://fburl.com/pcce4y0h in SSTs.
Going forward, it doesn't make any sense to me why borders should be drawn any differently when testing.
Reviewed By: sahrens
Differential Revision: D14109654
fbshipit-source-id: b8a5c01b923c93c32a8fa8954a850070f55764bc
Summary:
There's a very old issue with reload logic: invalidation and resetting up of the bridge could be racing. In this case, we hit a redbox when:
* Chrome debugger is enabled in previous app run, then we launch the app again
* The bridge starts, then immediately reloads itself to connect to Chrome
* On the 2nd setup, the logic to update the green loading bar, with the % indicator for loading off metro, failed to find the DevLoadingView module instance because the bridge is in the middle of invalidating
See https://github.com/facebook/react-native/issues/23235
To test:
Using react-native init from github, do the steps in https://github.com/facebook/react-native/issues/23235, no more redbox. Note that the loading indicator % won't be proper still, but at least it doesn't crash/redbox.
Reviewed By: JoshuaGross
Differential Revision: D14110814
fbshipit-source-id: 835061e50acc6968bffbcc2ddfbe8da79a100df9
Summary:
React native is missing a keyboard type for iOS so I included support for it. So it can be used in react native app
https://developer.apple.com/documentation/uikit/uikeyboardtype/uikeyboardtypeasciicapablenumberpad
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/20597
Differential Revision: D14103498
Pulled By: cpojer
fbshipit-source-id: b0aa17f3e527734c6e90eadc73c96db4dd002698
Summary:
Regression, fix image load from `~/Library` not respect scale factor.
Fixes#22383 , the bug comes from [Clean up some URL path handling](998197f444).
[iOS] [Fixed] - Fix image wrong scale factor when load image from file system
Pull Request resolved: https://github.com/facebook/react-native/pull/23446
Differential Revision: D14099614
Pulled By: cpojer
fbshipit-source-id: eb2267b195a05eb70cdc4671536a4c1d47fb03e2
Summary:
This adds a new jsi API prepareJavaScript. This accepts the same
parameters as evaluateJavaScript() but does not evaluate anything; instead
it returns a new object PreparedJavaScript which can itself be evaluated,
via the new API evaluatePreparedJavaScript().
There is a new empty class PreparedJavaScript which may be subclassed by
each Runtime variant to store its particular prepared form.
Reviewed By: mhorowitz
Differential Revision: D10491585
fbshipit-source-id: 702b9e23f2ff03d71a8ab17efb7e154b16dd8e87
Summary:
Sometimes, when we deal with ImageRequest and ImageResponseObserverCoordinator we subscribe for status (or access the coordinator) without owning an ImageRequest. In those cases, we have to retain the coordinator explicitly.
For those cases, ImageRequest now exposes `ImageResponseObserverCoordinator` as a `std::shared_ptr`.
Eg, concretely in the code, `completionBlock` and `progressBlock` copied a raw pointer to the observer inside which can lead to a crash when ImageRequest is being deallocated before we received an image data.
Reviewed By: JoshuaGross
Differential Revision: D14072079
fbshipit-source-id: e10120bc05bf685e288f7b3d69092714dcd91d43
Summary:
https://our.intern.facebook.com/intern/sandcastle/job/18014398585083744
```
xplat/js/react-native-github/React/Views/ScrollView/RCTScrollViewManager.m:38:20: warning: 'UIScrollViewContentInsetAdjustmentBehavior' is only available on iOS 11.0 or newer [-Wunguarded-availability-new]
```
Reviewed By: mattrobmattrob
Differential Revision: D14076127
fbshipit-source-id: 4050131c4f5211757383069567a2cf5382979735
Summary: Apparently, I haven't modify all files in D14018903. Here is the last (I hope) chunk.
Reviewed By: JoshuaGross
Differential Revision: D14058288
fbshipit-source-id: b21950cdd1aa9aa55b0c72fac0f8b44e4a7d131c
Summary:
Fixes#22824#21945 , the bug comes from #21208 , it was to fix#11897. Now Let's constrain edge adjust only when view has corners.
[iOS] [Fixed] - Fix triangle views on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/23402
Differential Revision: D14059192
Pulled By: hramos
fbshipit-source-id: be613bf056d3cc484f281f7ea3d08f251971700a
Summary:
Trivial.
If you have troubles with rebasing on top of this revision, run this on your diff:
$ find */*.h */*.mm */*.cpp */*.m -exec clang-format -style=file -i {} \;
Reviewed By: JoshuaGross
Differential Revision: D14018903
fbshipit-source-id: fd0ce2da0e11954e683385402738c701045e727c
Summary: I found that clang-format config file allows to specify rules on a per-language basis, so I moved Objective-C specific rules to the unified config. Now we have only one clang-format file. Yay!
Reviewed By: JoshuaGross
Differential Revision: D14018902
fbshipit-source-id: 45c1e185b8f2b8151ea202b3d9a68a3886597198
Summary:
There is no reason to allocate views ahead of time on the main thread.
There is a chance that this view will not be mounted and we are not saving any time because it's a sequential process anyway (because we are doing it on the main thread). Moreover, the switching context can only slowdown JS execution.
Reviewed By: JoshuaGross
Differential Revision: D14019433
fbshipit-source-id: 83ac05a91e4b70cb382a55d6687752480984404e
Summary:
A common util from RN to gate on testing code is `Platform.isTesting()`
Unfortunately, this util does not account for ServerSnapshotTests, since they don't use apple's XCTest infra.
Reviewed By: sahrens
Differential Revision: D13981728
fbshipit-source-id: bf902a04f5d7fcb98a06816f5c2c9b082e7d14b8
Summary: Recycling and dealloc were not implemented at all before for Slider, so I've taken a first stab at it. It's a little more complex than I initially thought, due to things I don't 100% understand about UISlider as well as Fabric, so I've left a TODO note to fix this at some point. We should be aware that view recycling doesn't appear to be working the way I would expect currently though.
Reviewed By: shergin
Differential Revision: D13965475
fbshipit-source-id: fd18a219cead770b63b514fdc868e23214e735b7
Summary: Don't use shared_ptr in this case, it's not needed.
Reviewed By: shergin
Differential Revision: D13965413
fbshipit-source-id: ec98c13f53c7d558a0cb68cea0f97568dd202cd8
Summary: The biggest change is that (1) the image proxy/observer code from the Image component has been generalized, (2) the four image props for the Slider component are fully supported, (3) a handful of props that were ignored or buggy on iOS now perform as expected.
Reviewed By: shergin
Differential Revision: D13954892
fbshipit-source-id: bec8ad3407c39a1cb186d9541a73b509dccc92ce
Summary:
TurboModules depend on a getConstants method. Existing ObjectiveC modules do not have this method. Therefore, I moved the contents of `constantsToExport` to `getConstants` and then had `constantsToExports` call `getConstants`.
facebook
Since all NativeModules will eventually need to be migrated to the TurboModule system, I didn't restrict this to just the NativeModules in Marketplace.
```
const fs = require('fs');
if (process.argv.length < 3) {
throw new Error('Expected a file containing a list of native modules as the third param');
}
function read(filename) {
return fs.readFileSync(filename, 'utf8');
}
const nativeModuleFilenames = read(process.argv[2]).split('\n').filter(Boolean);
nativeModuleFilenames.forEach((fileName) => {
if (fileName.endsWith('.h')) {
return;
}
const absPath = `${process.env.HOME}/${fileName}`;
const fileSource = read(absPath);
if (/(\n|^)-\s*\((.+)\)getConstants/.test(fileSource)) {
return;
}
const constantsToExportRegex = /(\n|^)-\s*\((.+)\)constantsToExport/;
const result = constantsToExportRegex.exec(fileSource);
if (result == null) {
throw new Error(`Didn't find a constantsToExport function inside NativeModule ${fileName}`);
}
const returnType = result[2];
const newFileSource = fileSource.replace(
constantsToExportRegex,
'$1- ($2)constantsToExport\n' +
'{\n' +
` return ${returnType.includes('ModuleConstants') ? '($2)' : ''}[self getConstants];\n` +
'}\n' +
'\n' +
'- ($2)getConstants'
);
fs.writeFileSync(absPath, newFileSource);
});
```
```
> xbgs -l ')constantsToExport'
```
Reviewed By: fkgozali
Differential Revision: D13951197
fbshipit-source-id: 394a319d42aff466c56a3d748e17c335307a8f47
Summary:
This diff adds performance loggers for Fabric in Android to be able to compare current version or RN with Fabric
This is the summary of Points and Annotations:
- **UIManager_CommitStart**: time that React starts the commit (react tree is ready to start rendering in native)
- **UIManager_LayoutTime**: this is the time it takes to calculate layout in yoga
- **UIManager_FabricFinishTransactionTime**: Time it takes transform "C++ mutationInstructions" into "Java MountItems" and cross boundaries from C++ to Java (including serialization of data) (THIS IS ONLY FABRIC)
- **UIManager_DispatchViewUpdates**: time right before RN moves the mount operations to the Queue that is going to be processed in the next tick UI thread
- **UIManager_BatchRunStart**: time right before the mountItems are going to be process in the UI Thread
- **UIManager_BatchedExecutionTime**: time it took to run batched mountItems (usually layout and prop updates on views)
- **UIManager_NonBatchedExecutionTime**: time it took to run non-batched mountItems (usually creation of views)
Reviewed By: fkgozali
Differential Revision: D13838337
fbshipit-source-id: 0a707619829e7d95ce94d9305ff434d1224afc46
Summary:
When using building React Native using the `.xcodeproj` (either via linked projects in Xcode, or precompiling React Native, which is what we do), you'll get a duplicate symbol error:
```
duplicate symbol __ZN8facebook5react10IInspectorD0Ev ...
```
And a few more.
This is because the `InspectorInterfaces.cpp` file is included in _both_ the `React` target _and_ the `jsinspector` target, and since the `jsinspector` target gets linked into the `React` target, this means the symbols from `InspectorInterfaces.cpp` end up in `libReact.a` twice.
<img width="187" alt="screen shot 2019-02-04 at 11 43 39 am" src="https://user-images.githubusercontent.com/819705/52189088-93190880-288a-11e9-8411-b44b59e8e461.png">
This PR removes `InspectorInterfaces.cpp` from the `React` target, as I believe was the original intent.
Since this bug is in the `xcodeproj` it only affects builds that use that, so CocoaPods and Buck users are unaffected.
[iOS][Fixed] - Fix potential linker issues when using xcode project
Pull Request resolved: https://github.com/facebook/react-native/pull/23284
Differential Revision: D13941777
Pulled By: cpojer
fbshipit-source-id: 8a3ffb4fc916ff6570bbff8794b4515b48055667
Summary:
Given two apps loaded side-by-side and when a `Keyboard` event is triggered, there is no way to ascertain which app triggered the keyboard event. This ambiguity can arise in slide over/split view scenarios.
This pull request exposes the `isLocalUserInfoKey` property of the native `UIKeyboard` iOS events to the `Keyboard` event listener; this property will return `true` for the app that triggered the keyboard event.
(Also, I threw in a couple of Keyboard.js tests just for fun 😅)
[iOS][Added] - Expose isLocalUserInfoKey to keyboard event notifications
1. Load two apps side-by-side, with the app on the left side subscribing to the keyboard events (and logging out the events as they happen)
1. Trigger a keyboard to appear with the left app. The logged keyboard event will contain the `isEventFromThisApp` property which will be true.
1. Dismiss the keyboard
1. Trigger a keyboard to appear with the right app. The left app will still log the keyboard event, but the event's `isEventFromThisApp` property will be false (because the left app didn't trigger the keyboard event)
Pull Request resolved: https://github.com/facebook/react-native/pull/23245
Differential Revision: D13928612
Pulled By: hramos
fbshipit-source-id: 6d74d2565e2af62328485fd9da86f15f9e2ccfab
Summary:
Fixes#23076 , the reason is `blur()` is managed by `UIManager`, `UIManager` maintains all operations and execute them each `batchDidComplete`, which means every time `JS` finish callback native , but `Alert` module would call directly, this mess up the order of method call, for example like below, even `this.$input.blur()` is called before `Alert.alert()`, but in native side, `Alert.alert()` is called before `this.$input.blur()`.
```
<TextInput style={{ borderWidth: 1 }} ref={$input => this.$input = $input} />
<Button title="Show Alert" onPress={() => {
// // `blur` works if using without `Alert`
this.$input && this.$input.blur()
// // `blur` is not working
Alert.alert('show alert', 'desc', [
{ text: 'cancel', style: 'cancel' },
{ text: 'show', onPress: () => {
}},
])
}} />
```
[iOS] [Fixed] - Fixes alert view block first responder
After fix, example like below, `blur` can works.
```
import * as React from 'react';
import { TextInput, View, Alert, Button } from 'react-native';
export default class App extends React.Component {
render() {
return (
<View style={{ flex: 1, justifyContent: 'center' }}>
<TextInput style={{ borderWidth: 1 }} ref={$input => this.$input = $input} />
<Button title="Show Alert" onPress={() => {
this.$input && this.$input.blur()
Alert.alert('show alert', 'desc', [
{ text: 'cancel', style: 'cancel' },
{ text: 'show', onPress: () => {
}},
])
}} />
</View>
);
}
}
```
Pull Request resolved: https://github.com/facebook/react-native/pull/23240
Differential Revision: D13915920
Pulled By: cpojer
fbshipit-source-id: fe1916fcb5913e2b8128d045a6364c5e3d39c516
Summary:
NativeModules are instantiated by the bridge. If they choose, they can capture the bridge instance that instantiated them. From within the NativeModule, the bridge can then be used to lookup other NativeModules. TurboModules have no way to do such a lookup.
Both NativeModules and TurboModules need to be able to query for one another. Therefore, we have four cases:
1. NativeModule accesses NativeModule.
2. NativeModule accesses TurboModule.
3. TurboModule accesses NativeModule.
4. TurboModule accesses TurboModule.
In summary, this solution extends the bridge to support querying TurboModules. It also introduces a `RCTTurboModuleLookupDelegate` protocol, which, implemented by `RCTTurboModuleManager`, supports querying TurboModules:
```
protocol RCTTurboModuleLookupDelegate <NSObject>
- (id)moduleForName:(NSString *)moduleName;
- (id)moduleForName:(NSString *)moduleName warnOnLookupFailure:(BOOL)warnOnLookupFailure;
- (BOOL)moduleIsInitialized:(NSString *)moduleName
end
```
If TurboModules want to query other TurboModules, then they need to implement this protocol and synthesize `turboModuleLookupDelegate`:
```
protocol RCTTurboModuleWithLookupCapabilities
property (nonatomic, weak) id<RCTTurboModuleLookupDelegate> turboModuleLookupDelegate;
end
```
NativeModules will continue to use `RCTBridge` to access other NativeModules. Nothing needs to change.
When we attach the bridge to `RCTTurboModuleManager`, we also attach `RCTTurboModuleManager` to the bridge as a `RCTTurboModuleLookupDelegate`. This allows the bridge to query TurboModules, which enables our NativeModules to transparently (i.e: without any NativeModule code modification) query TurboModules.
In an ideal world, all modules would be TurboModules. Until then, we're going to require that TurboModules use the bridge to query for NativeModules or TurboModules.
`RCTTurboModuleManager` keeps a map of all TurboModules that we instantiated. We simply search in this map and return the TurboModule.
This setup allows us to switch NativeModules to TurboModules without compromising their ability to use the bridge to search for other NativeModules (and TurboModules). When we write new TurboModules, we can have them use `RCTTurboModuleLookupDelegate` to do access other TurboModules. Eventually, after we migrate all NativeModules to TurboModules, we can migrate all old callsites to use `RCTTurboModuleLookupDelegate`.
Reviewed By: fkgozali
Differential Revision: D13553186
fbshipit-source-id: 4d0488eef081332c8b70782e1337eccf10717dae
Summary:
For better modularity, each module conforming to RCTTurboModule should provide a getter for the specific TurboModule instance for itself. This is a bit more extra work for devs, but simplify tooling and allow better modularity vs having a central function that provides the correct instance based on name.
Note: Android may or may not follow this new pattern -- TBD.
Reviewed By: RSNara
Differential Revision: D13882073
fbshipit-source-id: 6d5f82af67278c39c43c4f7970995690d4a82a98
Summary:
@public
Adds a class for triggering markers.
This calls `startMarker()` on construction, and `endMarker()` on destruction, thus being usable like a "scope guard": the object is instantiated, and automatically destroyed when going out of scope.
Reviewed By: SidharthGuglani
Differential Revision: D13817589
fbshipit-source-id: fd88884af970c1c0933d9ca6843f3f8f5d28b9e6
Summary:
RCTAsyncLocalStorage did not write the manifest after removing a value that was larger than RCTInlineValueThreshold. This meant that the values would still be on disk as null in the manifest.json, and if the app didn't do anything to make the manifest get written out again the null values would persist in the AsyncStorage and be returned by getAllKeys. We need to always write out the manifest.json even if the value is in the overflow storage files.
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.
Fixes#9196.
Not sure where the tests are for this?
none.
[IOS] [BUGFIX] [AsyncStorage] - Correctly remove keys of large values from AsyncStorage.
tadeuzagallo nicklockwood dannycochran
Pull Request resolved: https://github.com/facebook/react-native/pull/18613
Differential Revision: D13860820
Pulled By: cpojer
fbshipit-source-id: ced1cd40273140335cd9b1f29fc1c1881ab8cebd
Summary:
Currently, if an app uses AsyncStorage on the JS side, there is no public interface to access stored data from the native side.
In our app, written in Swift, I have written a [helper](https://gist.github.com/ejmartin504/d501abe55c28450a0e52ac39aee7b0e6) that pulls out the data. I accomplished this by reverse-engineering the code in RCTAsyncLocalStorage.m. It would have been far easier had this code been exposed to native.
I made this change locally and tested out getting the data from Swift code. This worked like a charm:
```swift
let storage = RCTAsyncLocalStorage()
let cacheKey = "test"
storage.methodQueue?.async {
self.storage.multiGet([cacheKey]) { values in
print(values)
}
}
```
[IOS ][ENHANCEMENT ][RCTAsyncLocalStorage.h] - Expose AsyncLocalStorage get/set methods to native code.
<!--
**INTERNAL and MINOR tagged notes will not be included in the next version's final release notes.**
CATEGORY
[----------] TYPE
[ CLI ] [-------------] LOCATION
[ DOCS ] [ BREAKING ] [-------------]
[ GENERAL ] [ BUGFIX ] [ {Component} ]
[ INTERNAL ] [ ENHANCEMENT ] [ {Filename} ]
[ IOS ] [ FEATURE ] [ {Directory} ] |-----------|
[ ANDROID ] [ MINOR ] [ {Framework} ] - | {Message} |
[----------] [-------------] [-------------] |-----------|
EXAMPLES:
[IOS] [BREAKING] [FlatList] - Change a thing that breaks other things
[ANDROID] [BUGFIX] [TextInput] - Did a thing to TextInput
[CLI] [FEATURE] [local-cli/info/info.js] - CLI easier to do things with
[DOCS] [BUGFIX] [GettingStarted.md] - Accidentally a thing/word
[GENERAL] [ENHANCEMENT] [Yoga] - Added new yoga thing/position
[INTERNAL] [FEATURE] [./scripts] - Added thing to script that nobody will see
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/18454
Differential Revision: D13860333
Pulled By: cpojer
fbshipit-source-id: b33ee5bf1ec65c8291bfcb76b0d6f0df39376a7e
Summary:
Motivation:
----------
This is one of the more sought after feature requests for RN:
react-native.canny.io/feature-requests/p/add-speed-attribute-to-scrollto
This PR adds the support to add a "duration" whenever using "scrollTo" or "scrollToEnd" with
a scrollView. Currently this only exists for Android as the iOS implementation will be somewhat more involved.
This PR is also backwards compatible and does not yet deprecate the "animated" boolean. It may not make sense to ever deprecate "animated", as it could be the flag that is used when devs want the system default duration (which is 250ms for Android). I'm not sure what it is for iOS. It would simplify things to remove "animated", though.
Pull Request resolved: https://github.com/facebook/react-native/pull/22884
Differential Revision: D13860038
Pulled By: cpojer
fbshipit-source-id: f06751d063a33d7046241c95348b6abbb327d36f
Summary:
@public
Adds a function to allow to configure markers. The function is declared in `YGMarker.h`
Reviewed By: SidharthGuglani
Differential Revision: D13819111
fbshipit-source-id: f9158b3d4e5727da4e151c84b523c7c7e8158620
Summary: Small changes to get Profile build working. Compiler errors or immediate crashes occur without these lines, when running a profile build on device.
Reviewed By: fkgozali
Differential Revision: D13823136
fbshipit-source-id: a1777d5337d8bd78ef3eb11bbeeb7e23c383ab83
Summary: Folly promises/futures have been replaced by an observer model which keeps track of loading state. This resolves at least one crash that I can no longer repro and simplifies the code a bit (IMO).
Reviewed By: shergin
Differential Revision: D13743393
fbshipit-source-id: 2b650841525db98b2f67add85f2097f24259c6cf
Summary: Objective-C side of the Fabric-compatible slider component for iOS.
Reviewed By: mdvacca
Differential Revision: D13745263
fbshipit-source-id: 647631d6fc86f81a5d4f735c507636ed9c468093
Summary:
…it doesn't exist (#21593)
Fixes#21593
RCTTVView.m contains a method called `setHasTVPreferredFocus`, where the following function call breaks the build:
[(RCTRootView *)rootview setReactPreferredFocusedView:self];
`setReactPreferredFocusedView` was formerly part of **RCTRootViewInternal.h** but was removed sometime.
Pull Request resolved: https://github.com/facebook/react-native/pull/21596
Differential Revision: D13761925
Pulled By: cpojer
fbshipit-source-id: be536786d7a8209f3a97b039e17d68d0aa653a0d
Summary:
Applies the `thumbTintColor` prop to Sliders on iOS (which has been supported since iOS 5.0). Updates other documentation so that it is not labeled as Android-only, including the RNTester app
Pull Request resolved: https://github.com/facebook/react-native/pull/22177
Differential Revision: D13695554
Pulled By: hramos
fbshipit-source-id: 250f6574b193a37b3cd237bcf42612c3e91bf813
Summary: This diff open sources Fabric Android implementation and it extracts ComponentDescriptorFactory into a function that can be "injected" per application
Reviewed By: shergin
Differential Revision: D13616172
fbshipit-source-id: 7b7a6461216740b5a1ad5ebbead9e37de4570221
Summary: I need this to set up QPL hooks in Instagram on iOS (see D13668326).
Reviewed By: mhorowitz
Differential Revision: D13668327
fbshipit-source-id: ee17d29ec0bbf4ef74736b1d7a095f955c0a7cc1
Summary:
Xcode 9 has compiler settings that are more strict. This can occur if someone updates there project to use the default settings.
This patch declares the default type instead of allowing the compiler to determine it. Instead of () we now say (void) in a block call.
Motivation
It was just trying to get my project totally empty of warnings, and it has no side effects. If there are side effects, then we should fix the type and not go with empty to represent void.
Test Plan
Update project settings in Xcode. This code doesn't have any known side effects since the compiler assumes the type is void when not declared.
Release Notes
[DOCS] - Fixed potential compiler build issue on Xcode 9 after updating settings in project.
Pull Request resolved: https://github.com/facebook/react-native/pull/17872
Differential Revision: D6981435
Pulled By: hramos
fbshipit-source-id: 508ecea0f8874dc16a25f1dee6255481b309f8c2
Summary: We are now generating the native cpp files for Switch via Buck. Deleting the hand written files and switching over.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D13666672
fbshipit-source-id: 72cf6f6af9374511f2742f8f0d996fa52e1bff5b
Summary:
The bug is described in #22891.
It's possible this might not be the right fix, since the original type comes from the commit introducing the feature (36ad813899). But after making this change custom VoiceOver actions work in my real project and my reduced test project.
Changelog:
----------
[iOS] [Fixed] - Fix supplying an array of custom VoiceOver actions via accessibilityActions prop
Pull Request resolved: https://github.com/facebook/react-native/pull/22892
Differential Revision: D13682727
Pulled By: hramos
fbshipit-source-id: a165af4ba78d2dbeca5bffbf60beb9ba50498f8d
Summary:
Motivation:
----------
As developers want to handle multiple actions on Siri Remote input when using TVEventHandler, it is crucial to differentiate 'swap' and 'tap' events.
Changelog:
----------
[tvOS] [Changed] - 'up', 'down', 'left' and 'right' events are now connected with tapping on edges of remote. New events 'swipeUp', 'swipeDown', 'swipeLeft' and 'swipeRight' added to detect swipes.
Pull Request resolved: https://github.com/facebook/react-native/pull/22916
Differential Revision: D13682705
Pulled By: hramos
fbshipit-source-id: 233ad1cecc04ca4ced75cd00e7fcb65d224ed3ca
Summary:
On iOS platform, RN retains launchOptions dictionary after bridge reload which can lead to unexpected consequences to a developer. The app will receive the same value for `Linking.getInitialURL` during initial launch and during bridge reload. Here's an example from our application. We use deeplinks via custom URL scheme so a user can open the app via link. Also, we reload the bridge when a user signs out. So if a user opens the app via URL, logs out, and a second user logs into the app, the app will behave as though the second user launched the app via the same deeplink. Because reload destroys the JS engine, there's nowhere for our app to remember that it already handled the deeplink activation.
On iOS Linking.getInitialURL() gets URL from the _launchOptions dictionary, so by setting it to nil we prevent retention of initialURL after reload.
This change makes iOS's behavior consistent with Android's. On Android, the launch URL is stored on the `Intent` and reloading the app involves creating a new `Intent`. Consequently, the launch URL is dropped as desired during the reload process.
Pull Request resolved: https://github.com/facebook/react-native/pull/22659
Differential Revision: D13564251
Pulled By: cpojer
fbshipit-source-id: 4c6d81f1775eb3c41b100582436f1c0f1ee6dc36
Summary: In some rare race condition (usually involving network request handling vs bridge shutting down), there may be bad access to an RCTModuleData that may have been de-allocated. To prevent crashes, let's guard the access and return nil appropriately.
Reviewed By: yungsters
Differential Revision: D13548755
fbshipit-source-id: b97326524cd9ca70a13d15098a1eaadfc7f1a6a8
Summary:
shergin mentioned that he'd like to move away from RTTI a bit and use explicit key strings for context container instances rather than relying on the `typeid`, so this does this.
We also fatal with a useful error message if we get a collision, rather than failing silently.
Reviewed By: shergin
Differential Revision: D13384308
fbshipit-source-id: 0b06d7555b082be89e8f130c23e94be99749a7a3
Summary:
`RCTSurfaceHostingProxyRootView` surfaces are still automatically started right after the initialization to match `RCTRootView` interface, but `RCTSurfaceHostingView` must be started explicitly now. Also fixed some internal stuff so start and register are clear and distinct.
Background / initial motivation:
One tricky bit - we render the template as part of init`ing the rootView, so we don't know what the surfaceId will be before hand to register the UITemplate. Two possible solutions:
1) Require start be called explicitly after initializing the rootView, and setup the context in between.
2) Do something like "setUITemplateConfigForNextSurface" before creating the rootView, and have some hook when the surfaceId is assigned that associates the surfaceId with that "next" UITemplate stuff before.
(1) seems a lot cleaner, but it requires ever user of rootView to explicitly call start on it - how do you feel about that? Seems like we could also use that start call to decide if the initial render should be synchronous or not? start vs. startSync?
Reviewed By: mdvacca
Differential Revision: D13372914
fbshipit-source-id: 6db297870610e6c231f8a78c0dd74d584cb64910
Summary: We need a way for different apps to inject dependencies or additional functionality into Fabric - ReactNativeConfig might be a special case, but I think this could clean up it's integration nicely, and I'm using this for a uitemplate cache system so we can use CompactDisk or other storage systems for caching depending on the app.
Reviewed By: mdvacca
Differential Revision: D13407287
fbshipit-source-id: 45481908434e6235850aa4d2d6b2bfb936a23be7
Summary:
So, it does not start itself automatically right after instantiation.
(Classic RCTSurface still kinda start itself automatically but only because start/stop concept is not implemented for this yet.)
Reviewed By: sahrens
Differential Revision: D13461294
fbshipit-source-id: 05430688f69a0d9bf75d03e6d25f02ccd5d3176a
Summary:
@public
Switches the storage in `facebook::yoga::detail::Values` from `YGValue` to `facebook::yoga::detail::CompactValue`.
This cuts heap size for arrays of values in half.
Reviewed By: SidharthGuglani
Differential Revision: D13465586
fbshipit-source-id: 49a4d6d29a73bdd44843b1f3c57bf746050c94d6
Summary: Some logic to check for surface stage should've done bitwise `&` operation instead of equality check, because we do bitwise `|` whenever we "set stage".
Reviewed By: shergin
Differential Revision: D13459156
fbshipit-source-id: 94e2f5279fb1a31060beb7d6195953b25ce603c9
Summary:
@public
Creates a single header file for `YGValue`. This is in preparation of a more compact representation of `YGValue` within `YGStyle`.
Also fixes the incorrect definition of NAN.
Reviewed By: SidharthGuglani
Differential Revision: D13439602
fbshipit-source-id: 68eef2c391b6c9810f3c995b86fff7204ebe6511
Summary:
Adds two additional UIBarStyles to RCTConvert
- [x] UIBarStyleBlackOpaque
- [x] UIBarStyleBlackTranslucent
Does not affect any tests or current usage of this conversion.
Pull Request resolved: https://github.com/facebook/react-native/pull/20102
Differential Revision: D13421942
Pulled By: hramos
fbshipit-source-id: 1e609eca0fdea2b56b9f6ac87e759c661bdee12b
Summary: Currently, bridge delegate can provide extra modules during bridge start up path. For TurboModules, we don't need this mechanism (if we need eager init, it will be done in a different way). So, let's ignore modules marked as RCTTurboModule if they are supplied as "extra native modules".
Reviewed By: axe-fb
Differential Revision: D13383710
fbshipit-source-id: c88d32739be9f66e0daf07ef5465ea6457f8d1c6
Summary:
Fixes#22530
As described in the issue, the previous behavior for the `RCTFatal` macro was to truncate the `reason` on the resulting `NSException` to 75 characters. This would ensure the reason would fit on a single line, but resulted in issues debugging errors that occurred in the wild, as many crash logging tools (like Sentry) discard the `name` value of the exception and use the `reason` as their primary identifier. At 75 characters, useful information like the location of the error would usually be truncated.
- [x] This extends the truncation threshold to 175 characters, which should be short enough to prevent full-screen-takeover length errors, but long enough to provide useful context to the error.
- [x] This adds a `userInfo` value to the resulting `NSException`. It copies over the `userInfo` from the `NSError` passed to the macro, and adds an "untruncated message" value that contains the untruncated version of the `NSException`'s reason.
[iOS] [Changed] - RCTFatalExceptions now include more information in their reason and a userInfo.
<!--
CATEGORY may be:
- [General]
- [iOS]
- [Android]
TYPE may be:
- [Added] for new features.
- [Changed] for changes in existing functionality.
- [Deprecated] for soon-to-be removed features.
- [Removed] for now removed features.
- [Fixed] for any bug fixes.
- [Security] in case of vulnerabilities.
For more detail, see https://keepachangelog.com/en/1.0.0/#how
MESSAGE may answer "what and why" on a feature level. Use this to briefly tell React Native users about notable changes.
EXAMPLES:
[General] [Added] - Add snapToOffsets prop to ScrollView component
[General] [Fixed] - Fix various issues in snapToInterval on ScrollView component
[iOS] [Fixed] - Fix crash in RCTImagePicker
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/22532
Differential Revision: D13373469
Pulled By: cpojer
fbshipit-source-id: ac140d14ce76e1664869437c2c178bdd65ab6e0e
Summary:
@public
Creates a single header file for `YGValue`. This is in preparation of a more compact representation of `YGValue` within `YGStyle`.
Also fixes the incorrect definition of NAN.
Reviewed By: SidharthGuglani
Differential Revision: D13172444
fbshipit-source-id: 4250dbcf8fe15ec3ecdee3913360a73bab633ce3
Summary: Each app may provide different impl for its runtime specific behaviors, then Fabric and other new infra can share the same config instance to configure stuffs.
Reviewed By: sahrens
Differential Revision: D13290319
fbshipit-source-id: 30e3eeedc6ff6ef250ed233b27e38cb7c1062b55
Summary:
There is a problem that the `mediaPlaybackRequiresUserAction` property does not work in WKWebView(`useWebKit`) under iOS 10.
I fully know you are currently working to migrate the core's WebView to the standalone `react-native-webview` project. This has already been submitted to PR in `react-native-webview` and will be merged soon. I hope this fix applies to `react-native` before your migration is done.
Pull Request resolved: https://github.com/facebook/react-native/pull/22208
Differential Revision: D13334868
Pulled By: cpojer
fbshipit-source-id: f2a811a477054155ed5fe62ab31e4d63f70e7848
Summary:
This avoids an intermittent reentrancy bug in JSC on iOS 11
(https://bugs.webkit.org/show_bug.cgi?id=186827). It also makes the
code more consistent with android.
Reviewed By: amnn
Differential Revision: D13313265
fbshipit-source-id: f42476b2f660e127ecfc9c72584554817eea1010
Calling -[UIScrollView setContentOffset] with NaN values can cause a crash. That's not clear why exactly the computation returns NaN sometime, but the implemented sanitizing should help to detect this problem during development (and this also prevents the app from crashing).
See attached task for more details.
Reviewed By: fkgozali
Differential Revision: D13242729
fbshipit-source-id: 747bf1b42e02597e9f1300eee24547563ab29b27
Summary:
ShadowView, ShadowViewMutation, and Differentiator were decoupled to separate module.
That enables us to use ShadowView more widely without facing a circular dependency problem.
Reviewed By: mdvacca
Differential Revision: D13205229
fbshipit-source-id: 7373864bf153a7813c2f97edb263a41454ce0b88
Summary:
This may be controversial.
Right now, RelayPrefetcher is initialized [here](https://fburl.com/p01iunr1), after bridge is initialized. I want to create a FBRelayPrefetcherModule instance eagerly (diff 3 in stack), and then pass that into the bridge module registry. This way, native side gets to use RelayPrefetcher before bridge is init, and JS still accesses the same instance of FBRelayPrefetcherModule.
The only other option is drastically change bridge init, to allow passing in some eagerly initialized instances.
Reviewed By: shergin
Differential Revision: D13164277
fbshipit-source-id: b45111cd68d78820e61e4fca7e54a7e8df32a3f0
Summary:
Previously, we stored a pointer to ShadowNode inside NSAttributedString's attributes to make possible retrieving an EventEmitter associated with some text fragment.
That worked fine besides only one caveat: the internal implementation of NSAttributedString is quite strange and that causes a memory leak. Because of some reason, NSAttributedString does not release stored attributes after own destruction (maybe OS uses some kind of caching).
So, now, instead of storing a strong pointer to ShadowNode inside NSAttributedString, we store a weak pointer to EventEmitter. Storing a weak pointer is okay because a desired lifetime of EventEmitter is guaranteed by LocalData stored inside a View. Storing a weak EventEmitter instead of weak ShadowNode will also help us with migration to ShadowView (we cannot store ShadowView weakly because it's a stack allocated object).
Reviewed By: sahrens
Differential Revision: D13196886
fbshipit-source-id: f8714e4b3709765629d6456edf0c635bf5f7c53b
Summary: Over-retaining a LocalData object inside the View can cause a crash during tearing down JS VM because LocalData can indirectly retain EventEmitter objects which were not properly "disabled".
Reviewed By: sahrens
Differential Revision: D13196887
fbshipit-source-id: 001d9fadf775c89f750c84fe8da9b84d4636631c
Summary: RCTViewComponentView retains an EventEmitter, so we have to clear this up after we recyled the view.
Reviewed By: sahrens
Differential Revision: D13196884
fbshipit-source-id: e9f2e2400be864c5c6177227255012101ed8c4d1
Summary:
[Folly upgrade](a70625abd7) introduced changes that have to be applied to `Install Third Party` script in order to use `New build system` from Xcode 10. Unfortunately, this might happen again if someone changes folly. Also removes non-existent files from folly podspec.
Pull Request resolved: https://github.com/facebook/react-native/pull/22394
Differential Revision: D13192463
Pulled By: hramos
fbshipit-source-id: ea0eeb6e1e7f6d7dfcdb6d1dee28b1a640ee7097
Summary: View recycling can be pretty aggressive and memory intensive, so we can properly react on system memory-pressure notification.
Reviewed By: mdvacca
Differential Revision: D13176278
fbshipit-source-id: 38ea1b27da988aeaaa5db6ac0b94389a0bd2799e
Summary:
Apparently, the previous behavior brings more problems than some *possible-in-the-future* features and flexibility.
The new model allows us to easily implement "nested text" feature.
(We temporary hope the old behavious for Android only for compatibility reasons.)
Reviewed By: mdvacca
Differential Revision: D13176277
fbshipit-source-id: 01f7bfb3c2e70cc89d76ecb78add016ee91cbd63
Summary:
The whole mounting iOS infra now uses `ComponentHandle` instead of `std::string` as a reference to particular `ComponentView` implementation. All changes are pretty straightforward, we use a different thing/type to refer to the particular class; no changes in the logic besides a new `RCTComponentViewFactory` that serves the same role of classes registry as Objective-C runtime served previously.
That has several benefits:
* It should be slightly faster, mostly because we don't need to convert `char *` strings to `std::string` and then to `NSString *`.
* We don't need string-based component-name maps anymore (at least on this layer). We can call classes as we want and it will work because of classes are now explicit about which ShadowNodes they are compatible with.
* Most importantly, it's explicit now! That means that no runtime magic is involved anymore and we can rely on static linting tool now and not be afraid of improper code stripping/overoptimization.
Reviewed By: mdvacca
Differential Revision: D13130760
fbshipit-source-id: aadf70525a1335b96992443abae4da359efdc829
Summary: The new method in the protocol enforces view component classes to expose a component handle of the component that the view component represents. That will allow us to wire up those classes with shadow views in runtime explicitly and in a much more performant way than it is now.
Reviewed By: mdvacca
Differential Revision: D13114663
fbshipit-source-id: 853187d978aab200f85719d9c1d9fea2e3ad4e55
Summary: Future::then taking a value-taking function is deprecated and being deleted. This cleans up a few more callsites.
Reviewed By: yfeldblum, shergin
Differential Revision: D13163277
fbshipit-source-id: 98d1f78c5b34ca34603cc24d79157a4718573576
Summary:
If text is truncated and an inline view appears after the truncation point, the user should not see the inline view. Instead, we have a bug such that the inline view is always visible at the end of the visible text.
This commit fixes this by marking the inline view as hidden if it appears after the truncation point.
This appears to be a regression. React Native used to have logic similar to what this commit is adding: 1e2a924ba6/Libraries/Text/RCTShadowText.m (L186-L192)
**Before fix**
Inline view (blue square) is visible even though it appears after the truncation point:
![image](https://user-images.githubusercontent.com/199935/46382038-d3a71200-c65d-11e8-8179-2ce4aad8d010.png)
The full text being rendered was:
```
<Text numberOfLines={1}>
Lorem ipsum dolor sit amet, consectetur adipiscing elit,
sed do eiusmod tempor incididunt ut labore et dolore magna
<View style={{width: 50, height: 50, backgroundColor: 'steelblue'}} />
</Text>
```
**After fix**
Inline view is properly truncated:
![image](https://user-images.githubusercontent.com/199935/46382067-fdf8cf80-c65d-11e8-84ea-e2b71c229dae.png)
**Test Plan**
Tested that the inline view is hidden if it appears after the truncation point when `numberOfLines` is 1 and 2. Similarly, verified that the inline view is visible if it appears before the truncation point.
**Release Notes**
[IOS] [BUGFIX] [Text] - Fix case where inline view is visible even though it should have been truncated
Adam Comella
Microsoft Corp.
Pull Request resolved: https://github.com/facebook/react-native/pull/21456
Differential Revision: D10182991
Pulled By: shergin
fbshipit-source-id: a5bddddb1bb8672b61d4feaa04013a92c8224155
Summary:
Update reference to property in code comment in `RCTBridgeModule`. There is no such thing as `requiresMainThreadSetup` in the codebase. Its called `requiresMainQueueSetup` now.
Pull Request resolved: https://github.com/facebook/react-native/pull/22328
Differential Revision: D13115352
Pulled By: shergin
fbshipit-source-id: 511d627388b51029821c4b1ddf4caac30e573040
Summary: That's a temporary change that useful only while we don't have deeper/proper intergration with UIKit's navigation infra.
Reviewed By: mdvacca
Differential Revision: D13104172
fbshipit-source-id: 024e71e04470d56d2c5e9b3f6c3392555ce50b63
Summary:
Apparently, if a gesture recognizer got 'reset', OS does not call `touchesCancelled:` method, so we have to do it manually.
To implement this we have to split `_dispatchTouches:eventType:` into two methods: the first converts Objective-C touches to C++ touches, the second consumes that. We have to do this because during reset we don't have a collection of UIKit touches.
Reviewed By: mdvacca
Differential Revision: D13072807
fbshipit-source-id: 677e2febf9f96dcdfaadfadf5b9ab3893f93e796
Summary: Every C++ engineer (except me several months ago) knows that `operator []` can mutate the collection (Yeah! Don't ask), so this is especially dangerous if your hash function is broken (see the previous diff).
Reviewed By: mdvacca
Differential Revision: D13072805
fbshipit-source-id: 4436a8ff12fb27a57bfb6ee0ff986d7a9a825549
Summary:
Without this fix the PointerHasher hashed not a pointer, but an address where the pointer is stored, which is obviously incorrect.
The incorrect hash function compromised the whole `_activeTouches` caused many issues with logically invalid invariants (e.g. removing element from the collection silently didn't work).
Reviewed By: mdvacca
Differential Revision: D13072804
fbshipit-source-id: d68289e940fe21e2df08a31439619b7e2fe0fa13
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/22316
Pull Request resolved: https://github.com/facebook/react-native/pull/22315
In order for TLS Mutual Auth to work for webviews, the caller must present a credential. Expose a setter that can be called to set a credential.
Reviewed By: RSNara
Differential Revision: D13095969
fbshipit-source-id: d136556a0030f799651d574b6e47ce38295b108e
Summary:
Now, Objective-C part of RN is in `xplat` directory, so global Objective-C clang-format does not affect that.
Explicit clang-format is also useful for external contributors who don't have access to the rest of monorepo.
The actual rules are copy-paste from ReactCommon folder with small changes (like 120 characters max line length) that conform to regular Facebook code style and which make sense only for Objective-C.
Reviewed By: fkgozali
Differential Revision: D13093150
fbshipit-source-id: 79d64b4fba6eeb94e9b8d87ef9c3f86b3a5ed94e
Summary:
Some module classes may not be loaded yet, so looking up via classes may not always give the correct instance. This diff added a new lookup method that delegate to the bridge delegate to force load the modules as needed.
The existing moduleForName: method was left untouched because it's solely used by RCTUIManager at the moment.
Reviewed By: dshahidehpour
Differential Revision: D13033876
fbshipit-source-id: 4082fcd68498004f678b4b95adc82b5b134fefdf
Summary: This diff changes the behavior of the Scheduler.schedulerDidRequestPreliminaryViewAllocation to avoid pre-allocating views that are non-layoutables
Reviewed By: shergin
Differential Revision: D12962008
fbshipit-source-id: cb2670beafdcbd2116fbdaf2dc5d1b4726330ec2
Summary: We are moving to more stable APIs removing all mentiones of the effort name from the codebase.
Reviewed By: mdvacca
Differential Revision: D12912894
fbshipit-source-id: 4a0c6b9e7454b8b14e62d419e9e9311dc0c56e7a
Summary:
D12911108 fixed a UBN race condition by adding a flag for module registry.
This flag was never reset if react instance gets reset, causing an assert to fire in IG.
Reviewed By: fkgozali
Differential Revision: D13010651
fbshipit-source-id: e20453f3c546d759a58fd7fb93553f774410905f
Summary: Depending on when Chrome debugger is attached, modules may get double registered. Simply ignore it for this case. The redbox was not a fatal error, which can be dismissed.
Reviewed By: shergin
Differential Revision: D12996107
fbshipit-source-id: 292f63102337077848842ca46b3daed08b1cae12
Summary:
it's possible that moduleForName won't return anything, so we should return.
Created from Diffusion's 'Open in Editor' feature.
Reviewed By: spredolac
Differential Revision: D12963342
fbshipit-source-id: c059595a68bfcaa38221e05fb62d70cc29887ca7
Summary:
It does not supported on Android and nobody uses it.
I could find only one use cases: Very old versin of `SectionList` library (4 years ago).
Reviewed By: sahrens
Differential Revision: D12972361
fbshipit-source-id: a5dfef5e877e996adec2d4941417b4a2e727cfb7
Summary: This diff exposes rootTag as part of SchedulerDelegate.schedulerDidRequestPreliminaryViewAllocation(). This will be necessary to be able to pool views per Surface in Android
Reviewed By: shergin
Differential Revision: D12875656
fbshipit-source-id: d2a8c1f9bcc6b14c17b34bf59085da44ae3c3416
Summary: Before lazily-loading code existed, modules that were already loaded into memory took precedent over modules that were additionally registered. With lazily loading modules, instead of giving eagerly loaded modules precdence, it throws a redbox. This diff fixes that behavior.
Reviewed By: PeteTheHeat
Differential Revision: D12983805
fbshipit-source-id: fe4fcf35d5c2ca6f9f4e3f0d1d8c2ca35468fb1b
Summary:
Previously, asking for an instance of NativeModule from the native side gave `nil` if the lazy modules have not been loaded, which is not consistent with the access from JS. This at least attempts to force load the lazy modules when asked from native.
p.s. one asks for a module by doing `[bridge moduleForClass:[FooBar class]]`.
Reviewed By: spredolac
Differential Revision: D12931640
fbshipit-source-id: 15d2dc574067d3386ef921512ce4bc837749dabd
Summary: Trivial. We don't use it anymore.
Reviewed By: mdvacca
Differential Revision: D12876743
fbshipit-source-id: dc979aaea1fef443b8caf2e58d44b0c7aad90246
Summary:
We double down on JSI in Fabric. So, practically, JSI is now a hard dependency for Fabric. I hope it's for good.
Now `jsi::Runtime` is coupled with scheduling via `EventExecuter`, so we have to make `jsi::Runtime` a part of `EventBeat` to proxy runtime reference to bindgings.
Reviewed By: sahrens
Differential Revision: D12837225
fbshipit-source-id: 98edc33d6a3358e6c2905f2f03ce0004a9ca0503
Summary: Now we use RuntimeExecutor instead of MessageQueue; that's more clear and remove a dependency from Bridge.
Reviewed By: sahrens
Differential Revision: D12837226
fbshipit-source-id: 0ea3782ce2f49c7f3a91425880863e3b3ea37712
Summary:
It works great on iOS, and mostly works on Android, and is now OTA'able as part of the screen config! Haven't done template view yet. One remaining issue:
Layout is borked on Android. I'm guessing the issue has to do with the timing of setting the constraints in `updateRootLayoutSpecs` and calling `mBinding.startSurface` which actually builds the shadow tree. If I try to call `updateRootLayoutSpecs` earlier, it just crashes immediately. Here's the layout it spits out, which clearly has -440 for the x of 420006, which is the RCTText component, causing it to get cut off on the left of the screen:
```
updateLayoutMountItem for reactTag: 420006 x: -440, y: -13, width: 931, height: 78
updateLayoutMountItem for reactTag: 420010 x: 26, y: 79, width: 0, height: 1651
updateLayoutMountItem for reactTag: 420012 x: 0, y: 26, width: 0, height: 158
updateLayoutMountItem for reactTag: 420016 x: 0, y: 210, width: 454, height: 454
updateLayoutMountItem for reactTag: 420018 x: 454, y: 210, width: 455, height: 454
updateLayoutMountItem for reactTag: 420022 x: 0, y: 690, width: 454, height: 454
updateLayoutMountItem for reactTag: 420024 x: 454, y: 690, width: 455, height: 454
updateLayoutMountItem for reactTag: 420028 x: 0, y: 1171, width: 454, height: 454
updateLayoutMountItem for reactTag: 420030 x: 454, y: 1171, width: 455, height: 454
updateLayoutMountItem for reactTag: 420032 x: 0, y: 1651, width: 0, height: 0
```
Reviewed By: mdvacca
Differential Revision: D12813192
fbshipit-source-id: 450d646af4883ff25184141721351da67b091b7c
Summary:
D12904277 was my sad, optimistic attempt to fix this crash.
As @[100006577537606:Slobodan] mentioned on T35879909, the real issue is that moduleRegistry is being created (using _moduleDataByID dict) concurrently while we try to append to this dict.
I added locks around these usage of _moduleDataByID.
Reviewed By: fkgozali
Differential Revision: D12911108
fbshipit-source-id: 2435b7a477c27585898f351c4a0d4c1bd4056756
Summary:
T35879909 is a UBN caused by a race condition in RN initialization. I haven't been able to repro, but the crash logs point to a bad memory access in this method. Another thread must be deallocating something concurrently.
This is a quick fix to patch into v197.
Reviewed By: fkgozali
Differential Revision: D12904277
fbshipit-source-id: 5740183f9a7c8f2c45ca627662891cb0c1048764
Summary:
@public
This allows apps to specify custom lazy modules that they need to load during chrome debugging. This is because lazy modules won't be available on start up, hence these modules will be missing in JS land, causing problems.
Reviewed By: shergin
Differential Revision: D12899408
fbshipit-source-id: dca313648e994b22e3ee5afec856ef76470065f9
Summary: Simply changing RCTLogWarn() to RCTLogInfo(), since some modules can be loaded without explicit export (experimental).
Reviewed By: mdvacca
Differential Revision: D12899442
fbshipit-source-id: 524d345265eda4a601101d878d51c244a8441fb5
Summary: Adds copyright headers to all files that are missing them.
Reviewed By: hramos
Differential Revision: D12837494
fbshipit-source-id: 6330a18919676dec9ff2c03b7c9329ed9127d930
Summary:
Fix the lazily LaodedView to avoid weird naming issues
This makes more sense. i would like to not have this suffix Manager at all in play, but it is possible that some of the names should be tweaked for that. Since TurboModule is coming we should probably not invest in that removal.
Reviewed By: dshahidehpour
Differential Revision: D12831482
fbshipit-source-id: 1cc557cf0bdfaca35032f75823b2facb778dc3ac
Summary:
This diff introduces a new integration concept (called RuntimeExecutor) which consolidates `Runtime` and the dispatching mechanism.
As simple as that:
`using RuntimeExecutor = std::function<void(std::function<void(facebook::jsi::Runtime &runtime)> &&callback)>;`
Reviewed By: fkgozali
Differential Revision: D12816746
fbshipit-source-id: 9e27ef16b98af861d494fe50c7e50bd0536e6aaf
Summary:
Fixes#20302 (For iOS)
Note:
------
1. Checked the changes did not break CocoaPods integration.
2. The change for glog copying header into exported/ is to prevent build break for folly.
`folly/detail/Demangle.h` will try to use libstdc++'s demangle.h. Unfortunately, glog also has a demangle.h in source code. So I copy exported headers and only search headers in exported/ folder during build.
Pull Request resolved: https://github.com/facebook/react-native/pull/21976
Reviewed By: hramos
Differential Revision: D12818131
Pulled By: fkgozali
fbshipit-source-id: b3c637d09d1b3adde0ea15c82eb56e28f846885b
Summary:
While debugging internally, we have found that modules are almost always registered
with their "RK" or "RCT" prefixes dropped.
However, if a view is named `RCTFooView` and needs `RCTFooViewManager` to render natively, it will almost never find it because `RCT` was dropped from the key to the ViewManager instance.
In the event you look for a `ViewManager` and don't find it, this strips any "React" prefixes from your key and tries ones more time.
Reviewed By: spredolac
Differential Revision: D10734005
fbshipit-source-id: 2bfa6f19830f14f09af2fe7dc7e44b7e26e0ac3f
Summary:
This class contains metrics about RN bridge startup that was being sent via FBAnalytics.
This diff refactors out any timespans being collected into a separate method. This refactor is NOT ENOUGH to format the data into a format QPL accepts. I still need to refactor these timespans into _start and _end points for QPL points to work correctly. This diff is a starting point.
Reviewed By: ejanzer
Differential Revision: D10466982
fbshipit-source-id: 4bc1159c4e53328f2252a8c606c8d6ff8d657489
Summary:
[RN] Relax the requirement that lazy module cannot be initialized on the main thread
I tried to understand the D5364734 that intoduced this, and I am not sure, but belive that asserting here is too strict. If you have a module that you want to lazily initialize, and module does not demand the main queue, it should be just a warning if you run on the main queue, not necessarily an error.
Reviewed By: mmmulani
Differential Revision: D10429880
fbshipit-source-id: 018c211d45b98dd8c552bf0289fe517d05e56d47
Summary:
Marc deleted a few files from react-native-github, so I removed them from the RNTester XCode project. I also included the files he created, and created new targets: `jsiexecutor-tvOS`, `jsiexecutor`, `jsi`, `jsi-tvOS`.
**Note:** The tvOS build of RNTester is broken in this diff because of a few `WKWebView` changes I landed earlier. D9844322 includes the fix.
Reviewed By: axe-fb
Differential Revision: D9875409
fbshipit-source-id: 31a9f241a524de91e78dfff0555aec5d1373d789
Summary:
JSI+JSCRuntime replaces direct use of JSC. This is like the previous
diff, except for iOS.
Reviewed By: RSNara
Differential Revision: D9369108
fbshipit-source-id: 4ed2c0d660ba2a30edf699d95278c72cabcc9203
Summary:
change RCTCxxBridge to use JSIExecutorFactory+JSCRuntime
instead of JSCExecutorFactory. Also remove JSC usage from RN in other
files. This allows deleting files, too, which is done further down
the stack.
Reviewed By: RSNara
Differential Revision: D9369111
fbshipit-source-id: 67ef3146e3abe5244b6cf3249a0268598f91b277
Summary: The code fragment `super.accessibilityLabel` always meant "use stored value which came from Props". But after we override the implementation of this getter in the base class, this starts working differently (wrong). This change basically reverts that to original intent.
Reviewed By: sahrens
Differential Revision: D10350597
fbshipit-source-id: 913951eb08c4ede76fc0e9be76b48d86599bcc62
Summary: Empty string in AccessibilityProps basically means same as `nil` in iOS Accessibility API.
Reviewed By: sahrens
Differential Revision: D10350596
fbshipit-source-id: fad9cdc914388c72e1b8261b27f14cbfa9a037db
Summary: We didn't have support for them... and now we have it.
Reviewed By: sahrens
Differential Revision: D10280430
fbshipit-source-id: 7275d4617ed3994366f673a17c24b823293d7092
Summary:
This diff fixes previously broken custom border rendering.
We need a dedicated CALayer for border bitmap in order to fully support all UIView capabilities in case if some subclass uses that. Otherwise, any call of `drawRect:` method can override any content which is stored inside `contents` property of CALayer.
Q&A:
How does it work in current RN? - It does not. All `drawRect:` methods in RCTView subclasses are dysfunctional.
How does text view work in current RN? - RCTTextView does not inherit RCTView, so it does not have this problem.
How does text view support custom borders in current RN then? - It does not.
Reviewed By: PeteTheHeat
Differential Revision: D10228805
fbshipit-source-id: 22bc31f41ab1914a97f3a5981cd1b24ebca725cd
Summary:
Fixes#20774
The new Xcode build system uses parallel execution to run build steps that don't have an obvious dependency. Our Xcode project was written with the assumption that the **Install Third Party** build step is run _before_ compiling the `third-party` libraries. To address this issue, this PR adds dependency information to the project to teach Xcode that `ios-install-third-party.sh` is generating the files under `third-party`. With this additional information, Xcode correctly waits for `ios-install-third-party.sh` to finish before advancing to the compile step.
In addition to the Xcode project changes, I had to make some changes to the script `ios-install-third-party.sh` so that
1. it would always execute the `ios-configure-glog.sh` script regardless of how it was invoked
2. it would always install the libraries even if Xcode had partially created the tree or if a previous install was interrupted
Pull Request resolved: https://github.com/facebook/react-native/pull/21458
Differential Revision: D10365495
Pulled By: hramos
fbshipit-source-id: c88042583f21d2447a16f6ae2b6abb929c659a26
Summary:
Size constraints are essential part of the running Surface, decoupling them from starting process means that we will have to perform additional commit later.
This and previous couple diffs fix a problem with initial zero size of the surface and following visible "jumpy" relayout.
Reviewed By: sahrens
Differential Revision: D10174280
fbshipit-source-id: 0ec48692cb814fd46cc3a1d044c5eb8ab9ecb031
Summary:
New `ShadowTree::synchronize` method allows to perform operations on ShadowTree without a risk of an unsuccessful commit. To make it happen, the `commitMutex_` is now recursive and `synchronize` acquires it before calling the callback.
Using that we finally can implement reliable `constraintLayout`.
Reviewed By: mdvacca
Differential Revision: D10174281
fbshipit-source-id: 9864ebb5343d40e2da205272a834710f0ab730db
Summary:
Setting the right expectations: setting layout constraints might fail. Nothing really changed.
Implementing a reliable `constraintLayout` which locks instead of returning immediately requires some additional work and new/additional API.
Reviewed By: mdvacca
Differential Revision: D10159457
fbshipit-source-id: bb23c7de105629ef086ae0b04667ff32c6ffb81d
Summary:
This adds a synchronous method that JS can call to load view managers.
Notably, we don't have an exact way to go from a JS name to the native view manager, so this naively adds 'Manager' to the end.
After lazily loading the view, it makes sure to cache all its values in native and JS, as further calls from JS will fail.
Reviewed By: PeteTheHeat
Differential Revision: D10204314
fbshipit-source-id: ebf42a85dcc467f3b4c5d6e18e49e04f9e8aa4f9