Summary:
alternative solution for https://github.com/facebook/react-native/issues/33379
> when `use_frameworks!` is on, there are errors like:
> ```
> 'FBReactNativeSpec/FBReactNativeSpec.h' file not found
> #import <FBReactNativeSpec/FBReactNativeSpec.h>
> ```
> this error may come from from https://github.com/facebook/react-native/commit/f7e4c07c84b6 regression.
>
> when `use_frameworks!` is on, xcode will search headers from framework directories, the correct imports would be `#import <React_Codegen/FBReactNativeSpec/FBReactNativeSpec.h>` (xcode will transform dash to underscore, so it is `React_Codegen` but not `React-Codegen`). in the other hand, when `use_frameworks!` is off, the correct import is `#import <React-Codegen/FBReactNativeSpec/FBReactNativeSpec.h>`.
>
>
> this fix is specific for old architecture (fabric is off).
>
> when fabric is on, there are other errors from duplicated headers when copying to build folder. [the reason is that framework build would try to flatten headers](https://mkonrad.net/2015/03/29/xcode-static-libraries-preserving-header-directory-structure.html). we have `primitives.h` in different folders and they would be flattened into `React_Fabric.framework/Headers`. to be honest, i don't know how to deal with the problem in the meantime, maybe subspecs are not enough, we should separate them from subspecs to dedicated podspecs so that we can have these targets as different frameworks.
in this alternative fix, i try to add `React-Codegen/React_Codegen.framework/Headers` into header search paths and make original `#import <FBReactNativeSpec/FBReactNativeSpec.h>` reachable.
[this change](7a0398c331) in the pr is just a workaround to solve breaking in latest main branch and this is not important to the `use_frameworks!` fix at all. this breaking was coming from 1804951595.
## Changelog
[iOS] [Fixed] - Fix iOS build error when Podfile `use_frameworks!` is on and Fabric is off
Pull Request resolved: https://github.com/facebook/react-native/pull/33409
Test Plan:
verify with rn-tester
1. change `fabric_enabled` to false in `packages/rn-tester/Podfile`
2. `USE_FRAMEWORKS=1 pod install`
3. build rn-tester in xcode
Reviewed By: dmitryrykun
Differential Revision: D34817041
Pulled By: cortinico
fbshipit-source-id: 4d1a610e99a807793eb3f64461e0d735c0a9ca9c
Summary:
Hoop up EarlyJsErrorHandler so we could pass js error data to object-c to report.
Changelog:
[iOS][Chagned] - Add function to report early js errors
Reviewed By: RSNara
Differential Revision: D34096343
fbshipit-source-id: fdbc6ea5d1f3cc6ab55fcd22b48bbe8fb1f1ca8f
Summary:
In iOS, the native LogBox that gets rendered for JS errors/warnings is statically sized once and bases that size off of the entire screen's size. This causes issues when being run in a Mac Catalyst app since 1) the sizing is not static since we can resize the window and 2) the size of the LogBox's root should fill the *window* and not the screen. This diff fixes both of these issues.
Changelog:
[iOS][Fixed] - Ensure LogBoxView is sized relative to the key window instead of the full screen
Reviewed By: appden
Differential Revision: D34697076
fbshipit-source-id: 9665fd51bc86ed29837672cec882bac97904b0c8
Summary:
iOS will sometimes invoke the UIAlertAction handler for the cancel button more than once on iPad. This can be reproduced relatively easily by having a button that opens an action sheet and spam tapping outside the action sheet while it is opening. Since native module callbacks can only be invoked once this causes the app to crash here https://github.com/facebook/react-native/blob/main/ReactCommon/react/nativemodule/core/platform/ios/RCTTurboModule.mm#L206.
## Changelog
[iOS] [Fixed] - Fix action sheet callback invoked more than once on iPad
Pull Request resolved: https://github.com/facebook/react-native/pull/33099
Test Plan: Tested on iPad simulator to reproduce the crash and verified that this fixes it.
Reviewed By: philIip
Differential Revision: D34215327
Pulled By: ShikaSD
fbshipit-source-id: 6f406e4df737a57e6dd702dd54260aa72eab31d6
Summary:
Fix for iOS displaying a RedBox for LogBox handled errors, this has been happening since RN 0.65 (in 64.2 and earlier, if it was handled by LogBox then it wouldn't trigger RedBox)
Fixes https://github.com/facebook/react-native/issues/32106
## Changelog
[iOS] [Fixed] - Stop RedBox from appearing for LogBox handled errors
Pull Request resolved: https://github.com/facebook/react-native/pull/32641
Test Plan: Manually tested. Seems to fix things (and RedBox still displays for things like 'Could not connect to development server') but I would appreciate RSNara or someone else who is more familiar with the code to confirm that the original switch was a mistake and not something deliberately changed.
Reviewed By: christophpurrer
Differential Revision: D33661481
Pulled By: cortinico
fbshipit-source-id: c9c262adb3f977ae3f13beb9575d3eaa2445f663
Summary:
Resolves this issue: https://github.com/facebook/react-native/issues/32304.
**NOTE:** This PR is based on a prior PR for this fix: https://github.com/facebook/react-native/pull/32305, I've co-authorized its creator for this change (paddlefish).
Without this change, calling to hide an alert, leaves a `UIWindow` that blocks user interactions with the screen.
The correct way to remove a `UIWindow` in iOS is to set its hidden property to `YES`. Also, it is required to remove all references to the window (the associated `windowScene` for example) and ARC will automatically free this `UIWindow`.
The line after this change, set the `_alertWindow` reference to `nil`, but the window is already associated with a scene (see the screenshots from [this PR](https://github.com/facebook/react-native/pull/32305#discussion_r720521707)). So we also need to remove the `windowScene` from that window, as recommended by Apple: https://developer.apple.com/documentation/uikit/uiwindowscene/3198091-windows.
>To remove the window from the current scene, or move it to a different scene, change the value of the window's windowScene property.
## 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
-->
[iOS] [Fixed] - remove alert's window when call to `hide`.
Pull Request resolved: https://github.com/facebook/react-native/pull/32833
Test Plan: See https://github.com/facebook/react-native/pull/32305
Reviewed By: hramos
Differential Revision: D33460430
Pulled By: lunaleaps
fbshipit-source-id: b13c2c7ee6404f1e1c787265bc4af8a31005bcf1
Summary: Insert casts for implicit int -> CGFloat conversions. This warning category is generally benign and explicitly casting will preserve existing behavior.
Reviewed By: NSProgrammer
Differential Revision: D33303887
fbshipit-source-id: b21adbcf754e707adfe3f8eaa0fe9c3a65380cc5
Summary:
`_labelsForTags` is an array with string labels used only for local profiling, that we had to manually keep it in sync with `RCTPLTag`. Refactor so labels are assigned with switch instead.
Changelog: [iOS] Refactor: Assign string label to each case in RCTPLTag enum for startup performance logging
Reviewed By: fkgozali
Differential Revision: D32889043
fbshipit-source-id: 81da592a160a31b91e78289be0990cc2ff960f29
Summary:
The current implementation of the prelive composer is setting the RN override preference to nil when live shopping ends. However, if the user had a previously set appearance override, this would clear it out.
To resolve this, I cache the user's override preference before we override it, and restore it when live shopping ends.
Additionally, I'm adding a missing callback to restore the override pref when live shopping is dismissed, but not cancelled.
Changelog:
[ReactiveNative][Appearance] - Add function to retrieve overridden RN appearance
Differential Revision: D32564739
fbshipit-source-id: d0b4e06d2bbadad68f172d951609cba3e4587e5d
Summary:
The current implementation of `AccessibilityInfo.announceForAccessibility` will immediately interrupt any existing in progress speech with the announcement. Sometimes this is desirable behaviour, but often you will want to wait until existing speech is finished before reading the new announcement. This change gives us that option.
My personal use case for this feature is a custom text input. When typing on iOS with voiceover enabled, each character is read out after being selected. I wanted to add some additional information after each character to help with the context of what has changed in the input, but I didn't want to override the reading of the character itself.
This feature is supported natively on iOS by constructing an `NSAttributedString` with the property [`accessibilitySpeechQueueAnnouncement`](https://developer.apple.com/documentation/foundation/nsattributedstring/key/2865770-accessibilityspeechqueueannounce), so this change just adds an extra parameter to `AccessibilityInfo.announceForAccessibility` which controls the value of that property on the native side. Adding this as an extra optional parameter with false as the default ensures that existing uses of the function won't be affected.
Unfortunately, this feature doesn't appear to be supported on Android, so the new second property will be iOS only.
## Changelog
[iOS] [Added] - add new argument to announceForAccessibility to allow queueing on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/32637
Test Plan:
I've updated the `announceForAccessibility` section in RNTester with multiple buttons to demonstrate the difference between `queue: false` (default) and `queue: true` and show they work as intended.
Here's the expectation for each button:
- "Announce for Accessibility Immediately": on press, should start reading the button label, then be interrupted by the announcement
- "Announce for Accessibility Queued": on press, should read the button label then read the announcement afterwards
- "Announce for Accessibility Queue Multiple": on press, should read the button label, then read three announcements sequentially, no interruptions
You can see the realisation of those expectations in the following video recorded on an iPhone 12 running iOS 15.0.2:
https://user-images.githubusercontent.com/14826539/142770536-d57bfd69-eba5-444d-9c89-4bf4851ea062.mov
I've also tested the same way on an iPhone 8 running iOS 13.4 and it works exactly the same.
Reviewed By: yungsters
Differential Revision: D32637989
Pulled By: philIip
fbshipit-source-id: 3e90add523f11eb0eb34ea623211249263f257e2
Summary:
Fixes a build error relating to RCTAlertController import when embedding react-native into existing iOS app. This PR resolves the issue detailed in https://github.com/facebook/react-native/issues/32356
## Changelog
Adjusts the import syntax which was added in:
f319ff321c (diff-56beca6ee071cdd162c269ce765ab12d5af8c8c0ca840bca1e9d1f59e9fab790)
Existing:
#import "RCTAlertController.h"
New:
#import <React/RCTAlertController.h>
[iOS] [Fix] - Fix RCTAlertController import build error when embedded in existing iOS projects
Pull Request resolved: https://github.com/facebook/react-native/pull/32457
Test Plan:
Build this branch in existing iOS project using swift, and should not have the build error described in the issue above.
Would also like to have this fix cherry-pick'd to release 0.63 after merging.
Reviewed By: RSNara
Differential Revision: D31861814
Pulled By: charlesbdudley
fbshipit-source-id: e60f80c8ea982e400cbf6d9375037d4197bbb8a3
Summary:
In this diff, it moves the codegen output location out of node_modules and to build/generated/ios folder.
A temp pod spec will be created so that those files will be included in the Xcode project.
Changelog: [Internal]
Reviewed By: hramos, cortinico
Differential Revision: D31809012
fbshipit-source-id: ba1c884c8024306ba0fd2102837b7dbebc6e18ac
Summary:
Fixes https://github.com/facebook/react-native/issues/32434: RCTLogBox window is orphaned, covering entire screen.
After this change, the logbox window once again is removed from the screen.
## Changelog
Some third-party SDKs may hold references to created UIWindow, UIViewController, or UIView objects. Doing so means that the current code's `hide` method that releases the reference to the UIWindow in LogBox will not cause the window to be dealloc'd, and thus instead it will remain on the screen. This change explicitly hides the LogBox window when the reference is released, so that even if some other SDK holds onto the window it will still be taken off the screen.
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fixed] - 32434
Pull Request resolved: https://github.com/facebook/react-native/pull/32435
Test Plan:
1. Use console.warn to generate a yellow warning message in log box. Also install a third-party SDK that holds onto a reference to UIWindow -- for example the Facebook SDK, the Data Dog SDK, or any number of other SDKs that use `swizzling` to intercept calls like `viewDidAppear:`.
2. click the log
3. tap "dismiss"
4. try to tap anywhere
5. Use Xcode view debugger to inspect the UI state
## Expected
The app still responds to the touch.
In Xcode, there is not an extra UIWindow covering the screen
Reviewed By: philIip
Differential Revision: D31794242
Pulled By: sshic
fbshipit-source-id: 28aa247b3ed3fd60b8e7c2ed7d0606cbf5c42408
Summary:
i saw this a lot in the codebase, it's not optimal bc we're using two selectors when we only need one.
fastmod --extensions m,mm '\[\[(.*) alloc] init]' '[${1} new]' --dir xplat/js/react-native-github/*
i manually updated the callsites that this codemod couldn't handle (e.g., where there were more than one of these instances in a single line)
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D31776561
fbshipit-source-id: 1b16da240e8a79b54da67383d548921b82b05a9f
Summary:
## Context
Right now we are using both LogBox and ExceptionsManager native module to report JS errors in ExceptionsManager.js, from below code we can tell they have some overlapping - when ```__DEV__ === true``` both could report the error.
https://www.internalfb.com/code/fbsource/[5fb44bc926de87e62e6e538082496f22017698eb]/xplat/js/react-native-github/Libraries/Core/ExceptionsManager.js?lines=109-141
## Changes
In this diff overlapping is removed: in ```ExceptionsManager.js``` LogBox will be responsible for showing the error with dialog when ```__DEV__ === true```, when it's prod we'll use ExceptionsManager native module to report the error. As a result LogBox and ExceptionsManager native module don't share responsibilities any more.
Changelog:
[General][Changed] - Remove shared responsibility between LogBox and ExceptionsManager native module
Reviewed By: philIip
Differential Revision: D30942433
fbshipit-source-id: 8fceaaa431e5a460c0ccd151fe9831dcccbcf237
Summary:
This PR fixes a few issues with the Appearance API (as noted here https://github.com/facebook/react-native/issues/28823).
1. For the Appearance API to work correctly on Android you need to call `AppearanceModule.onConfigurationChanged` when the current Activity goes through a configuration change. This was being called in the RNTester app but not in `ReactActivity` so it meant the Appearance API wouldn't work for Android in newly generated RN projects (or ones upgraded to the latest version of RN).
2. The Appearance API wasn't working correctly for brownfield scenarios on Android. It's possible to force an app light or dark natively on Android by calling `AppCompatDelegate.setDefaultNightMode()`. The Appearance API wasn't picking up changes from this function because it was using the Application context instead of the current Activity context.
3. The Appearance API wasn't working correctly for brownfield scenarios on iOS. Just like on Android its possible to force an app light or dark natively by setting `window.overrideUserInterfaceStyle`. The Appearance API didn't work with this override because we were overwriting `_currentColorScheme` back to default as soon as we set it.
## 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
-->
### Fixed
https://github.com/facebook/react-native/issues/28823
* [Android] [Fixed] - Appearance API now works on Android
* [Android] [Fixed] - Appearance API now works correctly when calling `AppCompatDelegate.setDefaultNightMode()`
* [iOS] [Fixed] - Appearance API now works correctly when setting `window.overrideUserInterfaceStyle`
Pull Request resolved: https://github.com/facebook/react-native/pull/29106
Test Plan: Ran RNTester on iOS and Android and verified the Appearance examples still worked [correctly.](url)
Reviewed By: hramos
Differential Revision: D31284331
Pulled By: sota000
fbshipit-source-id: 45bbe33983e506eb177d596d33ddf15f846708fd
Summary:
Changelog: [Internal]
https://fb.workplace.com/groups/rn.support/posts/6677051292343429
ax team is building a tool to extract information about the views for design reviewers, and RN has some AX information that is not working atm because of dependency on whether voiceover is on or not. so, this will give them the ability to programmatically set that field and hopefully be able to get accurate ax info
Reviewed By: ikenwoo
Differential Revision: D31010566
fbshipit-source-id: 4c8a33fce40266b270dd5994442c8472ca88f5dd
Summary:
This pull request aims to remove iOS 11 version check which is no longer needed.
The minimum iOS deployment target for React Native is `iOS 11` but we still have iOS 11 version check like below.
```
#if __IPHONE_OS_VERSION_MAX_ALLOWED >= 110000 /* __IPHONE_11_0 */
if (available(iOS 11.0, *)) {
```
> React Native apps may target iOS 11.0 and Android 5.0 (API 21) or newer.
ref: https://github.com/facebook/react-native#-requirements
------
If there is a team motivation to remove the deprecated methods and classes before iOS 10, I can continue the work in this pull request or in the continuing pull requests.
We have deprecated warnings for these in the project.
- `UIUserNotificationSettings`
- `UILocalNotification`
- `topLayoutGuide` and `bottomLayoutGuide`
- `automaticallyAdjustsScrollViewInsets`
## Changelog
[iOS] [Changed] - Remove iOS 11 version check
Pull Request resolved: https://github.com/facebook/react-native/pull/32151
Reviewed By: sammy-SC
Differential Revision: D30877917
Pulled By: yungsters
fbshipit-source-id: d903ea5d557beeb65ef87bfce572e4db3532b3c5
Summary:
Folly now depends on libc++abi. This solves linker error for RCT-Folly.podspec like this:
```
Undefined symbols for architecture arm64:
"___cxa_increment_exception_refcount", referenced from:
folly::exception_ptr_get_type(std::exception_ptr const&) in libRCT-Folly.a(Exception.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
See https://github.com/react-native-community/releases/issues/251
Note: RNTester was not affected by this bug for some reason, so the only way to verify is via the new app generated via `npx react-native init`.
Changelog: [Fixed][iOS] Unbreak Folly linker error
Reviewed By: lunaleaps
Differential Revision: D30950944
fbshipit-source-id: 3eb146e23faa308a02363761d08849d6801e21ca
Summary:
Changelog:
* Rename `ENABLE_PACKAGER_CONNECTION` macro to a more appropriate name `RCT_DEV_SETTINGS_ENABLE_PACKAGER_CONNECTION` to reflect this is only used in RCT_DEV_SETTINGS
* Introduce `RCT_PACKAGER_LOADING_FUNCTIONALITY` that can be separate from `RCT_DEV_MENU`, by default, it equals to `RCT_DEV_MENU`
Reviewed By: fkgozali
Differential Revision: D30546025
fbshipit-source-id: f409c02dc1486041d7db5abdbf7eb482520fa171
Summary:
RCTBaseViewController uses RCTRootView.bridge to call RCTViewEventEmitter.emit.
## Changes
- RCTEventDispatcher now exposes a method to dispatch RCTViewEventEmitter events.
- RCTRootView (for paper), and RCTSurfaceHostingProxyRootView (for fabric and bridgeless mode) now exports the RCTEventDispatcher by grabbing it from the bridge
- RCTBaseViewController now uses the event dispatcher exported from RCTRootView to dispatch the RCTViewEventEmitter event.
## Benefits
- RCTBaseViewController no longer uses the bridge to dispatch RCTViewEventEmitter events
- In the future, we'll make RCTSurfaceHostingProxyRootView work with bridgeless mode, which'll allow us to remove the bridge/bridgeless fork in RCTBaseViewController.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D30434884
fbshipit-source-id: d961a56ac2abc08a661f8fe7c37926f219b731d0
Summary: Bridge can get invalidated during tear down. If a JS error is thrown then, don't display a LogBox so we don't hit the invalid bridge assert in RCTSurface.
Reviewed By: fkgozali
Differential Revision: D30464848
fbshipit-source-id: 87a8daa95fd06342d194a4805ecfa97279820f2e
Summary:
Merges the Facebook-internal Buck target definitions in `Libraries/` into the BUCK file at the root of the repo (which is currently not synced to GitHub at all). This does not affect how React Native is built in open source.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D27967499
fbshipit-source-id: 39c51a544b3868242598072d24cb6cfb5a6e2d8c
Summary:
I'm going to be flipping the default from autoglob on `fb_apple_library` to `True`. This prepares the target so that there are no behavior changes.
## Changelog: [Internal]
Reviewed By: natestedman
Differential Revision: D29769275
fbshipit-source-id: 7ac04f8a8f7e41ce8d43a81b25ebd063b3a9f3de
Summary:
1. [ios] upgrade folly to 2021.06.28.00 which aligned to android.
2. folly compile setting from c++14 -> c++17: _this folly requires c++17 for `std::unordered_map::insert_or_assign`._
3. boost 1.63.0 -> 1.76.0: _the old boost does not support c++17._
4. deprecating react-native-community/boost-for-react-native: _by cocoapods installer, we could download the official target._
## Changelog
[iOS] [Changed] - Upgrade folly to 2021.06.28.00 and boost to 1.76.0
Pull Request resolved: https://github.com/facebook/react-native/pull/31840
Test Plan: CI passed
Reviewed By: fkgozali
Differential Revision: D29668480
Pulled By: yungsters
fbshipit-source-id: 98eae9ca47f489dcea91974e6f5e9dcb4d66c40c
Summary:
When you reload React Native surfaces via the CMD + OPT + R keystroke, this is the actual code that executes:
https://www.internalfb.com/code/fbsource/[9c79fc6a17b7738b391a605412abf1cb15ef8ea1]/xplat/js/react-native-github/React/CoreModules/RCTDevSettings.mm?lines=172-175%2C179-183
It's only executed when RCTDevSettings is instantiated by the bridge. So, if only bridgeless surfaces are loaded, then CMD + OPT + R doesn't work.
## Fix
In this diff, I ensure that
1. We set up the reload listener when RCTDevSettings is *first* instantiated
2. We clear the reload listener when all instances of RCTDevSettings are invalidated.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D29437952
fbshipit-source-id: 9f2ff8340575c0ed881df26249433b2075bbd2ac
Summary:
The Facebook app can have both bridge and bridgeless surface. Each type of surface has its own DevMenu. It's important to specify which DevMenu is being rendered, because not doing so can make for some confusing/frustrating devx (e.g: the bridgeless dev menu shows up for bridge surfaces: https://pxl.cl/1L1m7).
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D29439980
fbshipit-source-id: 24de1e6b44e5315c0cee0684d0db5df31514d3e2
Summary:
This migrates all ObjC NativeModule setBridge: calls to the bridge compatible initialize: call. I filtered out ViewManagers.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28595520
fbshipit-source-id: b0e5dd681fb3563894f1aa3da1728f0c694f04bb
Summary:
When we initialize RCTDevLoadingView, we dispatch_sync to the main thread. There isn't anything in the NativeModule that requires us to initialize it on the main thread. So, this diff toggles requiresMainQueueSetup to NO. This should mitigate this prefetch-related deadlock: T90970812. Please read the task comments for the rationale.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28490715
fbshipit-source-id: 7efceb392ec9e0cabe7f7cd8867cf4b07f8fff19
Summary:
This diff removes all synthesize invokeJS = _invokeJS calls, and instead funnels them through synthesize callableJSModules = _callableJSModules. Now, all these NativeModules shouldn't have different branching in bridgeless mode vs bridge mode.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28395445
fbshipit-source-id: 41a58d54c60be55e6bf5031e5417728f5eb6285c
Summary:
When RCTDevLoadingView is created, it checks to see if the bridge is loading. If so, displays the loading banner with the bundleURL. This logic is better placed in the bridge, because the bridge is also responsible for updating progress on the DevLoadingView.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28301524
fbshipit-source-id: fb6c259b546d8cd9e08568a88c7046d06c70ed6f
Summary:
RCTJSInvokerModule invokeJS can do the work done by setInvokeJSWithModuleDotMethod. Therefore, this diff reduces the surface area of Venice, and gets rid of setInvokeJSWithModuleDotMethod.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D28232947
fbshipit-source-id: aa0d8497a1e0fba29109ca86a39de5d9e5b10c9c
Summary:
This diff migrated RCTDevSettings to the RCTBundleManager, which works both in bridge/bridgeless mode. RCTDevSettings is the last TurboModule that synthesizes the bundleURL. So, after this diff, we can get rid of the RCTBundleHolderModule protocol.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D28232320
fbshipit-source-id: ab53278fea0ea7e025cf748be62bc5d610593e7f
Summary:
Changelog: Fix main thread access to UIKit in RCTRedBox
{F611784226}
Xcode's main thread checker complains about this during reload. it is not needed to set `dataSource` and `delegate` to nil because the table view is about to be destroyed.
Reviewed By: mdvacca
Differential Revision: D28089039
fbshipit-source-id: 13b62cafb4790fc15b5a5dde131d4ae64bd97c82
Summary:
This fixes an error where folly fails to build on Xcode 12.5, by bumping the various folly deps in RN to builds with a fix.
Next step is to commit this to 0.64 release branch
allow-large-files
Changelog: [iOS] Fix builds on Xcode 12.5
Reviewed By: fkgozali
Differential Revision: D28071808
fbshipit-source-id: 236b66bf8294db0c76ff25b11632c1bf89525921
Summary:
All NativeModules/TurboModules can use the following Venice-compatible API instead:
```
synthesize moduleRegistry = _moduleRegistry
```
In bridge mode, it'll look up the module via the TurboModule system/bridge.
In bridgeless mode, it'll look up the module via the TurboModule system.
Therefore, there's no need to support this API.
Changelog: [iOS][Removed] - Delete synthesize turboModuleRegistry API in RCTTurboModule
Reviewed By: fkgozali
Differential Revision: D28070740
fbshipit-source-id: d2c8285fd4c05b67fb03ce82217bf6ddfd1dd685
Summary:
This intentionally leaks the static map, since it still might be accessed after static destructors are run. This is a common approach to this problem, see https://github.com/facebook/react-native/pull/22607 and https://github.com/facebook/componentkit/pull/906 as examples. It also sets up an autorelease pool from `RCTNativeModule::invoke` as a precaution since there's no strict guarantee one exists when it is called.
Changelog:
[iOS][Fixed] - Fix crash in RCTCoreModulesClassProvider during quit
Reviewed By: RSNara
Differential Revision: D27932062
fbshipit-source-id: fa75da4b78290027a762440ac6943c81b8594a57
Summary:
CocoaPods will display a "fatal: not a git repository" when these podspecs are consumed within Facebook's internal Mercurial repository due to the reliance on `git` to obtain the current commit hash.
In these cases, the podspec is being consumed locally and the commit hash is unnecessary.
The error is removed by avoiding the use of `git` if the current working directory is not a git repository (or any of the parent directories).
Changelog:
[Internal] [iOS] - Remove CocoaPods error within Facebook's repository
Reviewed By: fkgozali
Differential Revision: D27750974
fbshipit-source-id: 99159611c580baf5526f116948c5ff60e1c02e5c
Summary:
We're making the getTurboModule: method required for all classes that conform to RCTTurboModule.
Many of our ObjC-only and Cxx NativeModules don't implement this method. This diff implements a getTurboModule: method on all those modules that returns nullptr.
**Question:** Why is it fine to make ObjC-only NativeModules return nullptr from their getTurboModule: method?
- Because they're only accessed from ObjC, and should appear as null on the JavaScript side. Longer term, these NativeModules will also go away.
**Question:** Why is it fine to make Cxx NativeModules return nullptr from getTurboModule: method?
- Because after D27316872, the TurboModuleManager checks if the module is a CxxModule first. If it is, we do an early return, and never call the module's getTurboModule: method.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D27316871
fbshipit-source-id: bc693f2927ab3b0de24e6e9e7699390ec0f7d729
Summary:
`RCTDevSettings` uses the API `bridge.isInspectable` to understand if the runtime can be debugged. In bridgeless mode, let's use `RuntimeExecutor` to check the same property.
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D27095935
fbshipit-source-id: 93785774b175bd7da17269e1590b5d92eba2b0cf
Summary:
Live reloading has been deprecated in favor of fast refresh for years, this diff removes remaining references to it.
Changelog: [iOS] Delete deprecated "live reloading" setting
Reviewed By: fkgozali
Differential Revision: D26983596
fbshipit-source-id: c7f86e7ec511f80e53659bccd8f40ac4f0cac27c
Summary:
Changelog: [Internal]
This moves enabling/disabling fast refresh off of `bridge.enqueueJSCall` in bridgeless mode.
Reviewed By: sammy-SC
Differential Revision: D26290378
fbshipit-source-id: ed8a3389b9812cedf7181971656dacd98ff7ecfd
Summary:
Changelog: [Internal]
This diff allows `RCTDevSettings` to access bundleURL directly instead of relying on the bridge.
Reviewed By: RSNara
Differential Revision: D26289592
fbshipit-source-id: e22e583e51323bfe66f6e424d9f47edf71b1ed9f
Summary:
Changelog: [Internal]
This removes a couple dependencies on bridge in dev menu native module. So far reloading works, will get inspector and other options working in follow ups.
Reviewed By: sammy-SC
Differential Revision: D26240391
fbshipit-source-id: 7c9d585f4efa6cc9db995ef8a33865831bc8d526
Summary:
Live reload was removed as a user facing feature in 2019 in favour of fast refresh. The native code was left in case "automation" relied on it. I'm quite sure no automation is using this dev feature. Remember, the dev feature made it so that hitting save in a text editor auto reloaded in metro.
Cleanup the native implementation.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D26239628
fbshipit-source-id: 7f61c7204727bb2d739600a459f69c72842265c5
Summary:
IIUC `isDebuggingRemotely` will never be set when `isDeviceDebuggingAvailable` is true. This was just a failsafe so that noone was trapped in an intermediate state.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D26239570
fbshipit-source-id: 8db6b022a0ea581216a1fa97b9d41f5ab6160562
Summary:
In bridegless mode, `setBridge` is never called on native modules. This diff refactors out some setup logic into the module's init method.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D26211620
fbshipit-source-id: 7a9910198852dea5ac679762aa93dfea6fc47d70
Summary: Changelog: [iOS] Only show Dev Menu on shake if RN view is visible
Reviewed By: fkgozali
Differential Revision: D26138659
fbshipit-source-id: e2db287728675c7ead5fcbf569ed591638e2187e
Summary:
## Description
Suppose this was the codegen declaration before:
```
rn_library(
name = "FooModule",
native_module_spec_name = "FBReactNativeSpec",
codegen_modules = True,
# ...
)
```
Previously, this would generate the following BUCK targets:
- generated_objcpp_modules-FooModuleApple
- generated_java_modules-FooModuleAndroid
- generated_java_modules-FooModule-jniAndroid
## Changes
We will now generate:
- FBReactNativeSpecApple
- FBReactNativeSpecAndroid
- FBReactNativeSpec-jniAndroid
This matches the naming scheme of the old codegen.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D25680224
fbshipit-source-id: 617ac18fd915f3277f6bd98072d147f20fb193e5
Summary:
All NativeModules that used to use the bridge to require other NativeModules now require other NativeModules via the Venice-compatible RCTModuleRegistry abstraction. Therefore, we can safely get rid of synthesize bridge = _bridge from them.
## How did I generate this diff?
1. Search for all NativeModules that have `synthesize bridge =`
2. Remove the `synthesize bridge = _bridge` from each NativeModule, and if it doesn't contain `_bridge`, `setBridge:`, or `elf.bridge`, add it to this codemod.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25551295
fbshipit-source-id: 585d50ad55cb9ab083e430b07e1cf30e31f0d3c5
Summary:
Ran `xbgs .accibilityManager`, and found all the NativeModules that used the bridge to access AccessibilityManager. Then, I migrated them to use RCTModuleRegistry.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25504726
fbshipit-source-id: fcfb1fffbeedc136ee160d043949d9859300b1e3
Summary:
Ran `xbgs .redBox`, and found all the NativeModules that used the bridge to access RedBox. Then, I migrated them to use RCTModuleRegistry.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25507829
fbshipit-source-id: 91033ca4c57d5be5e8e6fa904b636960ec12c584
Summary:
Ran `xbgs .devSettings`, and found all the NativeModules that used the bridge to access DevSettings. Then, I migrated them to use RCTModuleRegistry.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25503402
fbshipit-source-id: 26afc45cd1bc63d5de99ea331e7b2949b66be7ce
Summary:
All NativeModules that access the _bridge from self to require the DevSettings NativeModule now instead get the DevSettings NativeModule from the _moduleRegistry.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25503289
fbshipit-source-id: ebd1fd45d40aca37c0ead83bbaab59fa99d45044
Summary:
Ran xbgs `.devMenu`, and found all the NativeModules that used the bridge to access DevMenu. Then, I migrated them to use RCTModuleRegistry.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25499960
fbshipit-source-id: 70478616d44808f3788dd0b194da155db0877db9
Summary:
This is an extension of D25449795. I searched for all usages of .eventDispatcher within NativeModules, and migrated them all to the Venice-compatible RCTModuleRegistry API.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25473844
fbshipit-source-id: 2b8deec236e019f3adfb59fadd745c249ff822f4
Summary:
All NativeModules that use the bridge to require the eventDispatcher are now instead using the RCTModuleRegistry I introduced in D25412847 (0ed81b28d3).
## What does this codemod do?
For all ObjC files that contain `synthesize bridge = _bridge`, migrate calls that access the React Native bridge from `self`, and use it to load the event dispatcher.
**Thoughts on Codemod Safety:** If we can access the bridge from self, then that means that if we synthesize the module registry, we can access the module registry from self. Therefore, this codemod is safe.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25449795
fbshipit-source-id: 2f7235d14659e73d673ae08763dc2cccdde55a19
Summary:
`RCTAlertController` creates a new window, and presents itself in that window.
RCTAlertController strongly retains the window, and the window strongly retains RCTAlertController when presenting it.
This adds a new method to break that cycle once alert is dismissed.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25312413
fbshipit-source-id: e4048922aa697eb42c4c149827bac61bc7bc5528
Summary:
According to the crash, RCTEventEmitter is being asked to emit events before RN is set up {emoji:1f928}. Neither the bridge, nor bridgeless mode is ready to send events.
In this scenario, drop the events on the floor instead of crashing.
Changelog: [Internal]
Reviewed By: naftaly
Differential Revision: D24634701
fbshipit-source-id: 933e5dfd15e5ee7c2215489305c71de46e78a9e5
Summary:
To unify with Android, this uses the target off the same BUCK file.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24522269
fbshipit-source-id: 5aa0c08962890b884081faeb1ec801aebec9c2dd
Summary:
Removes the generated FBReactNativeSpec files from source control.
## Generating FBReactNativeSpec files
The files will be generated automatically by CocoaPods when the `RNTesterPods` Xcode workspace is generated:
```
cd packages/rn-tester
pod install
```
The spec files can be re-generated by invoking the script directly:
```
./scripts/generate-native-modules-specs.sh
```
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24261167
fbshipit-source-id: acb7ac856e5e519932e4f587f79e24f49cd84a91
Summary:
Although the interface for both NativeModules is the same, we'd like to enforce 1 `TurboModuleRegistry.get` call per NativeModule spec file. Therefore this diff splits the one spec into two.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24325260
fbshipit-source-id: f18718e4235b7b8ccbfc44a7e48571ecf483a36c
Summary:
This diff ended up being a bit more complicated than I anticipated, since the source files in `ReactInternal` were depending on `RCTEventDispatcher`. I made the following changes:
1. Make `RCTEventDispatcher` a `protocol`, keep it in `ReactInternal`.
2. Rename the `RCTEventDispatcher` NativeModule to `RCTEventDispatcherModule`, make it conform to the `RCTEventEmitter` `protocol`, and move it to `CoreModules`.
3. Where necessary, replace categories of `RCTEventDispatcher` with functions.
Changelog:
[iOS][Added] - Make RCTEventDispatcher TurboModule-comaptible
Reviewed By: fkgozali
Differential Revision: D18439488
fbshipit-source-id: b3da15c29459fddf884519f33b0c3b8c036b5539
Summary:
shergin added a new assert to dimensions calculations in D24038911 (e853722981). This crashes in bridgeless mode b/c no bridge.
This diff uses `turboModuleRegistry` as a bridge workaround. The registry is a [weak property](https://www.fburl.com/diffusion/sunv3bx9) so retain cycles shouldn't be an issue here, let me know if that's incorrect.
As a nice bonus, this fixes dynamic font sizing in bridgeless mode. It was broken before since it relied on the bridge.
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D24256338
fbshipit-source-id: 141d36239ac6a6e9e87ca96eea7aeec56729095d
Summary:
This PR attempts to fix issue https://github.com/facebook/react-native/issues/28278 and https://github.com/facebook/react-native/issues/29525
On Crashlytics, the following error occurs in file `RCTWebSocketModule.m` at method `-[RCTWebSocketModule webSocket:didFailWithError:]` when a nil value is inserted into a dictionary as a value.
```
Fatal Exception: NSInvalidArgumentException
*** -[__NSPlaceholderDictionary initWithObjects:forKeys:count:]: attempt to insert nil object from objects[0]
```
This PR is following the suggestion of this: https://github.com/facebook/react-native/issues/28278#issuecomment-597461650 and it replaces the values of any property if it is nil. In detail:
- it converts `error` to empty NSString if the original value is nil
- it converts `socketID` to a NSNumber object, which stores `-1` if the original value is nil
## Changelog
[iOS] [Fixed] - A crash in WebSocket module
Pull Request resolved: https://github.com/facebook/react-native/pull/30066
Test Plan: We were not able to reproduce the crash, but the report itself provided enough information to find a solution for this issue.
Reviewed By: shergin
Differential Revision: D24241147
Pulled By: sammy-SC
fbshipit-source-id: d5d632b49ca77b5d8be8b9c32358bef68f17d30a
Summary:
At this point, I think we are ready to enable validation
Changelog: [INTERNAL]
Differential Revision: D24062829
fbshipit-source-id: c82dcd2c376e5cdeb164451e16b6fb3a666106f4
Summary: We need this checks to make the results of those function more reliable.
Reviewed By: sammy-SC
Differential Revision: D24038911
fbshipit-source-id: 3b54fe3056c9508cde84ea157beebea57e7e49b6
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:
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:
Disabling Fast Refresh won't be persisted when restarting the app.
I believe this regressed with 824e171117. 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
Kudo Chien
Lulu Wu
Vincent Riemer
Samuel Susla
Janic Duplessis
Moses DeJong
Liam Jones
Asaf Korem
Andres Suarez
CodemodService FBSourceClangFormatLinterBot
Richard Howell
Phillip Pan
Paige Sun
David Ashinsky
Peter Carpenter
Nick Fujita
Sota Ogo
Andrew Rahn
Brent Kelly
Muhammad Numan
Ken Tominaga
Kevin Gozali
Jimmy Zhang
Ramanpreet Nara
Moti Zilberman
Jason Safaiyeh
Dustin Shahidehpour
Peter Argany
Scott Kyle
Héctor Ramos
Aditya Kumar
generatedunixname89002005325676
Luke Walczak
Mark Sinkovics
Valentin Shergin
simek
Ullrich Schäfer
