Summary:
Remove the older implementation of image instrumentation in Fabric by removing, RCTImageInstrumentationProxy, ImageInstrumentation from ImageRequest, and trackURLImageContentDidSetForRequest from RCTImageLoaderWithAttributionProtocol.
Changelog: [RN][Fabric][Image] Remove unused Fabric image instrumentation
Reviewed By: fkgozali
Differential Revision: D23990606
fbshipit-source-id: 004d04025d031af11377a73e5bfb64b1e0449962
Summary:
Changelog: [Internal]
Fabric removes components bottom up (from leafs to the root).
This means that by the time Fabric hides Modal, it has no content and therefore it appears as if Modal disappears without Animation.
To fix this, we snapshot contents of the Modal before any of its contents are removed.
Reviewed By: shergin
Differential Revision: D23976244
fbshipit-source-id: 01c13b74e97f82816e8946fd9d1add1db10340b1
Summary:
Refs: [0.62 release](https://reactnative.dev/blog/#moving-apple-tv-to-react-native-tvos), https://github.com/facebook/react-native/issues/28706, https://github.com/facebook/react-native/issues/28743, https://github.com/facebook/react-native/issues/29018
This PR removes most of the tvOS remnants in the code. Most of the changes are related to the tvOS platform removal from `.podspec` files, tvOS specific conditionals removal (Obj-C + JS) or tvOS CI/testing pipeline related code.
In addition to the changes listed above I have removed the deprecated `Platform.isTVOS` method. I'm not sure how `Platform.isTV` method is correlated with Android TV devices support which is technically not deprecated in the core so I left this method untouched for now.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
* **[Internal] [Removed]** - remove most of tvOS remnants from the code:
* `TVEventHandler`, `TVTouchable`, `RCTTVView`, `RCTTVRemoteHandler` and `RCTTVNavigationEventEmitter`
* **[Internal] [Removed]** - remove `TARGET_TV_OS` flag and all the usages
* **[iOS] [Removed]** - remove deprecated `Platform.isTVOS` method
* **[iOS] [Removed]** - remove deprecated and TV related props from View:
* `isTVSelectable`, `hasTVPreferredFocus` and `tvParallaxProperties`
* **[iOS] [Removed]** - remove `BackHandler` utility implementation
Pull Request resolved: https://github.com/facebook/react-native/pull/29407
Test Plan: Local tests (and iOS CI run) do not yield any errors, but I'm not sure how the CI pipeline would react to those changes. That is the reason why this PR is being posted as Draft. Some tweaks and code adjustment could be required.
Reviewed By: PeteTheHeat
Differential Revision: D22619441
Pulled By: shergin
fbshipit-source-id: 9aaf3840c5e8bd469c2cfcfa7c5b441ef71b30b6
Summary:
Wrap iOS 14 SDK code in a `#if/#endif` so that the Instagram app compiles again
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23948336
fbshipit-source-id: 67e6ee48d1951ae405c12b4ad39cf8c9817df627
Summary:
Changelog: [Internal]
value needs to be set after minimum and maximum, otherwise it gets pinned to previous minimum/maximum.
Default minimum is 0 and maximum is 1. If we set value to 20 and maximum to 50, previously the value would get pinned to 1 (maximum value).
See [Apple Docs](https://developer.apple.com/documentation/uikit/uislider/1621346-value?language=objc) for more.
Reviewed By: JoshuaGross
Differential Revision: D23903545
fbshipit-source-id: 8e9dd49ced79d43b9591c7d24de59b9eaff5bdfd
Summary: In iOS when a parent UIView returns YES on [shouldGroupAccessibilityChildren](https://developer.apple.com/documentation/objectivec/nsobject/1615143-shouldgroupaccessibilitychildren), VoiceOver groups together the accessible children of the parent view, regardless of their position on screen. In iOS this defaults to NO.
Reviewed By: sammy-SC
Differential Revision: D23844265
fbshipit-source-id: eb99bf0873ccfd9fb196f8f7b6eafe055f6ae810
Summary:
iOS14 has introduced new styles for date picker. The default new calendar style breaks the old spinner type style.
This is a workaround to keep the spinner style as a default, until the calendar style is properly supported. According to [this github comment](https://github.com/react-native-community/datetimepicker/issues/285) it works well.
This will fix DatePicker for both Fabric and Paper, since Fabric uses the interop layer to render it.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23935328
fbshipit-source-id: 1a7fadba274e0537f0ac4ced60e23e7c809d57dc
Summary:
Changelog: [Internal]
There was a typo in condition. We need to be comparing step prop and not value. The same condition is implemented in Paper.
Reviewed By: JoshuaGross
Differential Revision: D23903493
fbshipit-source-id: 37506d0fac63f624332041602489ab1cf378bfcc
Summary:
Changelog: [internal]
If view was bridged from Paper, hit testing would return Paper view which doesn't have reference to Fabric's event emitter.
To fix this, if the bridged view is returned from hit testing, it is swapped with interop view which has reference to event emitter.
Reviewed By: shergin
Differential Revision: D23840054
fbshipit-source-id: d4aa4ee8da4e1da80d2e2b69b79ed82d726f04e3
Summary:
Since `dealloc` can be called from any thread, this would result `stopObserving` being called on a different thread/queue than the specified `methodQueue`. We specifically encountered this issue with a module needing the main queue having its `stopObserving` called on a background queue.
Changelog:
[iOS][Fixed] - Call [RCTEventEmitter stopObserving] on specified method queue
Reviewed By: RSNara
Differential Revision: D23821741
fbshipit-source-id: 693c3be6876f863da6dd214a829af2cc13a09c3f
Summary:
Exceptions in C++ work quite differently from exceptions in other languages. To make exceptions actually work **correctly** all the code needs to be written with "exceptions in mind" (e.g., see https://www.stroustrup.com/except.pdf). In short, if the code is not "exceptions ready", throwing an exception causes memory leaks, dangling pointers, and invariant violations all over the place, which will probably cause another crashes down the road (which will be especially hard to investigate and attribute to the original issue).
Fabric Core (Layout, Props parsing, ShadowNodes management, and so on) does not use exceptions because in most (all?) the cases the exception is now recoverable. So, if a program detects some internal state invariant violation or missing some resource, *logically* it's fatal. We also don't want to pay code-size and performance tax for exception support, so that's why we don't use them. It's just not the right fit for Fabric Core.
This does not mean that exceptions don't happen though. C++ standard library can throw them... sometimes. And if our library is compiled with exceptions enabled (still the case, unfortunately), an exception can bubble to JavaScript code and losing all context down the road. And it's hard to investigate such crashes. To isolate those occasional exceptions inside C++ core we are marking all C++/JS boundaries with `noexcept` that stops the bubbling.
I hope that will give us much more informative crash reports.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D23787492
fbshipit-source-id: 0822dbf36fc680c15b02b5cd0f2d87328296b642
Summary:
This change maps the three most used colors (black, white, clear) to corresponding predefined values in UIColor. This should meaningfully reduce the overall amount of allocated UIColor/CGColor objects. In my non-scientific measures, it reduces the number of CGColor objects from ~1500 to ~1000. And... it no much at least in terms of kilobytes. However, I still think it's a good idea to implement this because I hope that can remove some work from memory allocation infra and maybe enable some optimizations that UIKit hopefully does for black and white colors. (I tend to believe that this optimization exists because UIKit even has a classes called UIDeviceWhiteColor and UICachedDeviceWhiteColor.)
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23753506
fbshipit-source-id: 46e58dc7e6b0dcab3c83d29c7257c90ffbd95246
Summary:
This diff changes the implementation of `RCTCreateCGColorRefFromSharedColor` and `RCTUIColorFromSharedColor` in such a way that they don't rely on the fact that SharedColor is actually a `shared_ptr<CGColorRef>`. Instead, the methods just extract color components from SharedColor and create UIColor and CGColorRef objects on demand.
This allows us to change the implementation of SharedColor without worrying much about the rest of the system, which will do in the next diff.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23753510
fbshipit-source-id: 340127527888776ebd5d241ed60c7e5220564013
Summary:
Even though we have wonderful helper functions converting SharedColor to UIColor and CGColorRef, in many places we still use some hardcoded things. This diff fixes that; it will be important for the next diff.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23753508
fbshipit-source-id: 09d280b132266252753526c2735ab3e41b96c8d5
Summary:
This diff removes `RCTCGColorRefUnretainedFromSharedColor` function because it's not compatible with future changes we plan to make.
Converting SharedColor to unretained CGColorRef is actually quite dangerous because... it's an unowned pointer.
Reviewed By: JoshuaGross
Differential Revision: D23753509
fbshipit-source-id: df030ade69b63cbb872d6bdbde51575eedc6a4a6
Summary:
An experiment where we use `LayoutMetrics::overflowInset` to optimize performance of hit-testing algorithm.
In my measurements enabling this feature drastically (2x) reduced amount of calls to `hitTest:withEvent:` method.
Reviewed By: sammy-SC
Differential Revision: D23669091
fbshipit-source-id: ac6dadc90b6a2fbb45e41e0d4a113bd5ae8f1218
Summary:
Disabling Fast Refresh won't be persisted when restarting the app.
I believe this regressed with https://github.com/facebook/react-native/commit/824e1711172d14a9373209bbae63d1ae50601625. In this commit `HMRClient.setup` will always be called with `enabled` being set true. This PR loads the _enabled_ state from the user defaults (as it was done before).
## Changelog
[iOS] [Fixed] - Enable Fast Refresh gets persisted across app launches
Pull Request resolved: https://github.com/facebook/react-native/pull/29880
Test Plan:
Without this change Fast Refresh is enabled on every app restart.
Tested with this change:
- Disabling Fast Refresh
- Restarting App -> Fast Refresh still disabled
- Enabled Fast Refresh again
- Restarting App -> Fast Refresh still enabled again
Reviewed By: sammy-SC
Differential Revision: D23686435
Pulled By: PeteTheHeat
fbshipit-source-id: 42c31b22060d3dc4b1d4cb8f41792b303fc7fce8
Summary: Changelog: [Internal] Add IGviewpoint to get image visibility callbacks for when an UIImageView is in or out of view
Reviewed By: fkgozali
Differential Revision: D23428528
fbshipit-source-id: 87e4cee8fbe3c6b7da5153f87bbb530b2f990d96
Summary:
With the upgrade to React Native 0.63, we started running into nullability warnings that were breaking our build. This PR fixes those nullability warnings as well as a few other warnings in React-Core.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fixed] - Fix xcodebuild warnings in React-Core
Pull Request resolved: https://github.com/facebook/react-native/pull/29622
Test Plan:
- Nullability annotations should only affect compilation, but even though RNTester compiles, I'm not fully convinced that this won't break projects downstream. It would be good to get another opinion on this.
- The change in `RCTAllocateRootViewTag` is the only real logic change in this PR. We throw an exception if the root view tag is not in the correct format, so this change seems safe after some basic manual testing in RNTester.
Reviewed By: shergin
Differential Revision: D23386678
Pulled By: appden
fbshipit-source-id: a74875195a4614c3248e8f968aa98602e3ee2de0
Summary:
Right now, when two threads require two NativeModules, both threads fight for the same `std::mutex`. Why? Because NativeModule require can read from/write to the shared `std::unordered_map<std::string, TurboModuleHolder*>`.
**A Few Thoughts:**
- All threads should be able to read from the TurboModule cache concurrently, without issue. Only writes into the cache require exclusive access. *With our current setup, both reads and writes acquire exclusive access.*
- During the lifetime of an application, there will only be tens of NativeModule create events (i.e: writes into the TurboModule cache). However, there may be hundreds, if not thousands of TurboModule cache lookups. *We don't need to serialize those hundreds/thousands of TurboModule cache reads.*
This is a potential optimization opportunity for the TurboModule infra.
## Changes
This diff introduces a `std::shared_mutex` inside `RCTTurboModuleManager`. We use either the regular `std::mutex` or the `std::shared_mutex`, depending on whether `RCTTurboModuleSharedMutexInitEnabled()` is `YES`.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23413118
fbshipit-source-id: 0880413c691b141db98a2715648f0c3e05983307
Summary:
Fix a issue that RCTModalHostView can't be dismissed while being presented
Steps To Reproduce
A native modal presented view controller is being dismissed before the first screen shows.
A RCTModalHostView is presented when the first screen shows.
The RCTModalHostView will be dismissed after an asynchronous callback.
If the callback was called before the completion of the presenting animation, the RCTModalHostView will not be dismissed.
## Changelog
[iOS] [Fixed] - Fix that RCTModalHostView can't be dismissed while being presented
Pull Request resolved: https://github.com/facebook/react-native/pull/29745
Reviewed By: shergin
Differential Revision: D23566487
Pulled By: sammy-SC
fbshipit-source-id: bd95f200b79fa75e2387e402091d58c0f538759c
Summary:
We need this to make crash logs more actionable. For now we know that those asserts fire so we should make them actionable.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D23580103
fbshipit-source-id: 8532e33b016e738a4f128c9b547c33d204610bcc
Summary:
When we catch an Objective-C exception and convert it to NSError we need to somehow represent the call stack from NSException instance in NSError instance. For now, we just attach the stack trace to `message` field.
The next step would be to figure out how to pass the Objective-C stack trace to error reporting infra to help it to display the stack trace nicely in the web interface.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D23557600
fbshipit-source-id: a080c2e186e719e42dcfc01bb12f5811e3c5b2e6
Summary:
Changelog: [Internal]
In https://fburl.com/diffusion/3705cj0i we assert that view which is about to be recycled, has no superview.
This is a problem in Legacy interop layer which is nested within another interop layer. This originally wasn't considered.
Removing views in `finalizeUpdates` like it has been done until now is not enough because when a component is deleted, `finaliseUpdates` isn't called.
Reviewed By: shergin
Differential Revision: D23572999
fbshipit-source-id: f007dfe293b7d27d56253656c02529163304f83c
Summary:
Changelog: [internal]
[NSString UTF8String] is nullable. Therefore, we need to check if it isn't nil before passing it to std::string constructor which crashes if it's nil.
Reviewed By: shergin
Differential Revision: D23572652
fbshipit-source-id: 59e7f5e918b2e5c69333bfb687371f856555d8e0
Summary:
Changes the order of `RCTBorderColors` field designators to match their declaration order, fixing one case of `-Wreorder-init-list` when compiling the RN codebase with Xcode 12.
Changelog: [Internal]
Reviewed By: MichaReiser
Differential Revision: D23447685
fbshipit-source-id: f04a3841187f0869d2efb60e81ce075c45f27f3c
Summary:
Changelog:
Sometimes a port different than kRCTBundleURLProviderDefaultPort (8081) can be specified to RCTBundleURLProvider for packager checking or requesting resources through saving them in JSLocation, this adds support for that rather than always falling back to kRCTBundleURLProviderDefaultPort
Reviewed By: PeteTheHeat
Differential Revision: D23395548
fbshipit-source-id: b7a6f0816d1f226a2e3fb82bf2dc0ab9e79ef966
Summary:
Microsoft’s RN for macOS fork supports the Hermes engine nowadays https://github.com/microsoft/react-native-macos/pull/473. As a longer term work item, we’ve started moving bits that are not invasive for iOS but _are_ a maintenance burden on us—mostly when merging—upstream. Seeing as this one is a recent addition, it seemed like a good candidate to start with.
As to the actual changes, these include:
* Sharing Android’s Hermes executor with the objc side of the codebase.
* Adding a CocoaPods subspec to build the Hermes inspector source and its dependencies (`Folly/Futures`, `libevent`).
* Adding the bits to the Xcode build phase script that creates the JS bundle for release builds to compile Hermes bytecode and source-maps…
* …coincidentally it turns out that the Xcode build phase script did _not_ by default output source-maps for iOS, which is now fixed too.
All of the Hermes bits are automatically enabled, on macOS, when providing the `hermes-engine-darwin` [npm package](https://www.npmjs.com/package/hermes-engine-darwin) and enabling the Hermes pods.
## Changelog
[General] [Added] - Upstream RN macOS Hermes integration bits
Pull Request resolved: https://github.com/facebook/react-native/pull/29748
Test Plan:
Building RNTester for iOS and Android still works as before.
To test the actual changes themselves, you’ll have to use the macOS target in RNTester in the macOS fork, or create a new application from `master`:
<img width="812" alt="Screenshot 2020-08-18 at 16 55 06" src="https://user-images.githubusercontent.com/2320/90547606-160f6480-e18c-11ea-9a98-edbbaa755800.png">
Reviewed By: TheSavior
Differential Revision: D23304618
Pulled By: fkgozali
fbshipit-source-id: 4ef0e0f60d909f3c59f9cfc87c667189df656a3b
Summary:
Changelog: [Internal]
# Problem
`RCTModalHostViewComponentView` reuses the same UIViewController between recycles. This can be a problem if dismissal of the modal is animated as the UIViewController is still presented while it is being dismissed. That's when "Application tried to present modally an active controller" exception can happen.
# Solution
Deallocate UIViewController when `RCTModalHostViewComponentView` is recycled.
Reviewed By: PeteTheHeat
Differential Revision: D23345711
fbshipit-source-id: da540571184afcb88b52758c4a1f0b4ec5874eb1
Summary:
Changelog: [Internal]
# Problem
The problem was setting `_backedTextInputView.attributedText` to nil inside `[RCTTextInputComponentView prepareForRecycle]`.
Ordinarily this isn't a problem becase `UIManager::updateState` drops the update if the ShadowNode no longer exists. But in certain cases the ShadowNode can exist, empty string being set as its value
# Fix
Fix is trivial, invalidate state before nullifying `_backedTextInputView`. This prevents the state update from being dispatched.
# Discussion
We should go over all other components and make sure state is invalidated as first thing in `[RCTViewComponentView prepareForRecycle]`.
Reviewed By: shergin
Differential Revision: D23324929
fbshipit-source-id: 9568e920d99683ad95f965ef4b63c529f50f3283
Summary:
Changelog: [Internal]
This was set to screensize in D13104172 (https://github.com/facebook/react-native/commit/346c9d5f2c0fd99d6f05828d594d05bfaeed902f) to work around issues at that time.
The issues might not be around anymore.
Reviewed By: PeteTheHeat
Differential Revision: D23298723
fbshipit-source-id: 4f33a2cc65ae4fe5ba20b0b2b270b135878c339f
Summary:
This crash was introduced in D22962320 (https://github.com/facebook/react-native/commit/ffdfbbec08b1afb1970d2cfe75a78a203d4a79a4), which landed 8/17 and went into 8/23 cut. I plan to pick this diff into that release.
I can't repro this, but there must be a scenario (in bridged mode), where we try to flush event queue while bridge is tearing down. I plan to consider this scenario going forward.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D23306445
fbshipit-source-id: 285d4b94a17423c3b08d83e7041c4ee04b7e6d0c
Summary:
Changelog: [Internal]
# Problem
In D22274782 (https://github.com/facebook/react-native/commit/fb2b49d2982399f26b93ac02b2197c0b3813a4a9) I removed integration between Paper and Fabric. However this integration was still used by `RCTLegacyViewManagerInteropComponentView` for view commands dispatch.
Fix is to use `[RCTUIManager viewForReactTag:viewTag]` instead of viewRegistry.
Reviewed By: shergin
Differential Revision: D23291567
fbshipit-source-id: 35c50716fd8b86ae25b1534e4d8aa688c8e6e129
Paige Sun
Samuel Susla
generatedunixname89002005325676
simek
Martin Ortega
Valentin Shergin
Peter Argany
Scott Kyle
generatedunixname89002005287564
Ullrich Schäfer
Jayme Deffenbaugh
Ramanpreet Nara
Mi-ZAZ
Moti Zilberman
Jimmy Zhang
Eloy Durán
