Summary:
This behaviour diverges from the original SafeAreaView implementation and causes issues when you try to use SafeAreaView in non-root placements (not recommended)
Changelog: [iOS][Internal]
Reviewed By: sammy-SC
Differential Revision: D39497303
fbshipit-source-id: 03bc288557f611bd4a8c16b3a6df8887e89ee9ec
Summary:
Adding support for application to hook into further tracing methods
## Changelog
[General][Added] - Add additional Systrace support
Reviewed By: NickGerleman
Differential Revision: D38673212
fbshipit-source-id: 55a90a0cd57809bca5f01da7acddcf253e5852ba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34514
Changelog: [Internal][iOS] Modularlize RCTBridgeModule.h 3/n - Move RCTTurboModuleRegistry.h to its own file in ReactInternal target
# Why clean up RCTBridgeModule.h?
Clean up one unnecessary import of RCTBridgeModule.h.
RCTBridgeModule includes a lot of header files, and this header is imported everywhere. The ultimate goal is that files (especially React Native infra files) should only import only what they need and not import the entirety of RCTBridgeModule.h whenever possible.
This way, certain headers that are Bridge-only can be compiled out of the new architecture with a flag.
Reviewed By: RSNara
Differential Revision: D38971168
fbshipit-source-id: 3b1b23d422f965a5a14bc4178d32b844906f2c8b
Summary:
changelog: [internal]
preemtive view allocation has been disabled on iOS for over a year. We kept the code in but didn't do anything with it. This diff removes the code and related mobile config.
Post where we decided to turn preemtive view allocation off: https://fb.workplace.com/groups/215742978987717/permalink/832644567297552/
jest_e2e[run_all_tests]
Reviewed By: mdvacca
Differential Revision: D37922589
fbshipit-source-id: 1af8949cbbd9d48a2d80ca238b280178cbe2ead5
Summary:
Changelog: [Internal] Move Bridge-only constants into a separate file
- Move Bridge only constants from RCTBridge.h into RCTBridgeConstants.h.
- Move shared constants from RCTBridge.h into RCTConstants.h.
This way, new architecture does not need to import RCTBridge.h just for the constants.
Reviewed By: sammy-SC
Differential Revision: D39085713
fbshipit-source-id: 40177cbed72a326b40ec448c98751d1dd3464504
Summary:
In an app using `UIScene`, `Alert` no longer pops up because the window
that gets created are not attached to a scene.
## Changelog
[iOS] [Fixed] - Fix `Alert` not showing in an app using `UIScene`
Pull Request resolved: https://github.com/facebook/react-native/pull/34562
Test Plan: Use the test plan in https://github.com/facebook/react-native/issues/29295. This should not regress that fix.
Reviewed By: cipolleschi
Differential Revision: D39276976
Pulled By: lunaleaps
fbshipit-source-id: e48e985ed4abec77d6f01a6c17292d664ed88f13
Summary:
D38460203 (e6ef0836c1) was reverted because it broke OSS, the root cause is that OSS doesn't have MapBuffer module.
Fixed the issue in this diff by moving MapBuffer usage to fb internal class (FBReactModule) and will re-land.
Changelog:
[iOS][Changed] Replace Folly with MapBuffer for passing js error data
Reviewed By: sammy-SC
Differential Revision: D39210957
fbshipit-source-id: dda0e8c55dbd13bc96310e10a3b09ea53978e8bc
Summary:
Changelog: [iOS][Internal] - Rework button/buttons handling on pointer events & add a new test checking for move events on chorded mouse button presses
This is a larger diff that largely stems from implementing a new pointer event platform test about chorded mouse button presses (adapted from https://github.com/web-platform-tests/wpt/blob/master/pointerevents/pointerevent_pointermove_on_chorded_mouse_button.html). In order to implement this test I added a new method, `step`, to an async test instance to allow you to run ad-hoc assertions labeled by the async test (like it's done in the original web platform test).
Once implementing the test I also discovered my current logic for handling the `button` and `buttons` properties was insufficient so I reworked it to handle more/most cases by making the `button` property instead determined by the change in the `buttons` property. This largely works but unfortunately due to what seems to be a bug in UIKit, chorded pointer "up" events receive the wrong button mask values so it's currently impossible to get this test fully passing on iOS. I've since submitted a bug report to Apple but my hopes aren't high that it will be focused on since it's such a niche issue.
Reviewed By: lunaleaps
Differential Revision: D38951159
fbshipit-source-id: 426b7cf7930ed8329151382fafee487493e568de
Summary:
when integrates with swift, the compiler will build clang module based on the *React-Core-umbrella.h*. however, the include chain reaches some c++ headers that are not available from swift. it will cause build error.
this pr adds `#ifdef __cplusplus` guard for it.
## Changelog
[iOS] [Fixed] - Fix React module build error with swift integration on new architecture mode
Pull Request resolved: https://github.com/facebook/react-native/pull/34527
Test Plan:
one thing we didn't figure out is that we require reanimated to repro the build error.
1. `npx react-native init RN070 --version 0.70.0-rc.4`. # can also repro this issue on 0.69
2. `cd RN070`
3. `yarn add react-native-reanimated@next`
4. `cd ios && rm -rf Pods build && RCT_NEW_ARCH_ENABLED=1 pod install`
5. add `import React;` in `main.m` for clang module generation
```diff
--- a/ios/RN070/main.m
+++ b/ios/RN070/main.m
@@ -1,5 +1,6 @@
#import <UIKit/UIKit.h>
+@import React;
#import "AppDelegate.h"
int main(int argc, char *argv[])
```
6. `yarn ios`
Reviewed By: cipolleschi
Differential Revision: D39128716
Pulled By: jacdebug
fbshipit-source-id: d9e9130f99e3b9e5f7807c475a24cdd84880e720
Summary:
Changelog: [Internal][iOS] Modularlize RCTBridgeModule.h 1/n - Move RCTBundleManager.h to its own file in ReactInternal target
# Why clean up RCTBridgeModule.h?
Clean up one unnecessary import of RCTBridgeModule.h.
RCTBridgeModule includes a lot of header files, and this header is imported everywhere. The ultimate goal is that files (especially React Native infra files) should only import only what they need and not import the entirely of RCTBridgeModule.h whenever possible.
This way, certain headers that are Bridge-only can be compiled out of the new architecture with a flag.
The other benefit of splitting up the headers like this is that it'll be much easier for developers to navigate between the .h and .mm files.
Reviewed By: philIip
Differential Revision: D38943262
fbshipit-source-id: 90876324de9fae25bf33c7aef820a32d7c6ce2f8
Summary:
The motivation of this PR is for the Alert to follow the same style override (`overrideUserInterfaceStyle` being light/dark) as the one used by the root window (`UIApplication.sharedApplication.delegate.window`).
This is something that has worked previously because `RCTPResentedViewController()` was used to present the Alert (the behavior has changed in f319ff321c). With the former approach, the alert would "inherit" the `userInterfaceStyle` of the view controller it was presented within (and that one, in turn, would "inherit" from `UIApplication.sharedApplication.delegate.window`).
With the current approach, the "style inheritance" does not work with the view controller being created [here](f3db6cc527/React/CoreModules/RCTAlertController.m (L24)).
Because this viewcontroller instance does not have where to "inherit" the styling from, the styling might be different from the rest of the app. This PR fixes that.
## Changelog
[iOS] [Fixed] - fix: RCTAlertController's UserInterfaceStyle to follow root window
Pull Request resolved: https://github.com/facebook/react-native/pull/34218
Test Plan:
Instead of
```
self.overrideUserInterfaceStyle = UIApplication.sharedApplication.delegate.window.overrideUserInterfaceStyle;
```
you can do
```
self.overrideUserInterfaceStyle = UIUserInterfaceStyleDark;
```
and observe the result. So if the override is set, it'll manifest itself. If it's not set, the value of `UIApplication.sharedApplication.delegate.window.overrideUserInterfaceStyle` will be `UIUserInterfaceStyleUnspecified`, and it'll have no effect.
<details>
<summary>screenshot</summary>
</details>
Reviewed By: dmitryrykun
Differential Revision: D38660799
Pulled By: cipolleschi
fbshipit-source-id: c979266900e27be7a4732bdb6e9a496906534931
Summary:
Changelog: [iOS][Internal] - Fix buttons property value for non-hoverable pointers
The previous diff ensured that on iOS you could run through the entirety of the non-hoverable pointer event attributes test but that also revealed some failing tests related to the `buttons` property when using a non-hoverable pointer. This diff fixes that by ensuring that we only forward the result of the `buttonMask` to `buttons` when the pointer is a mouse, and assume that it is an emulated left click otherwise.
Reviewed By: lunaleaps
Differential Revision: D38914239
fbshipit-source-id: c573e934d0e9c0ac2af4945dc5360840ddc87d4d
Summary:
Changelog: [iOS][Internal] - Apply pointer entering/leaving tracking to touch-initiated pointer events
This diff takes the refactoring done in the previous diff in this stack and applies it to the pointer events which are converted from discrete touch events. In addition this adds a check when an ActiveTouch is created to see if the pointer in question was hovering before the touch started or not, which is stored and leveraged once the touch is lifted to determine if we should treat the pointer as leaving the screen entirely or not.
Reviewed By: lunaleaps
Differential Revision: D38762330
fbshipit-source-id: 08452783e01bf5944c57b94a292805b2d69d4384
Summary:
Changelog: [iOS][Internal] - Refactor hover tracking to prepare for support of tracking the entering/leaving of poitners on non-hover pointer events
This diff begins the work in preparing the touch handler class to track pointer's entering & leaving of views on events other than a hover move by refactoring it to 1) support multiple/simultaneous pointers and 2) abstract the pointer tracking out of the hover recognizer callback so that it can be used for other events in the future (to be done in future diffs, this diff is simply a refactor and keeps the status quo).
Reviewed By: lunaleaps
Differential Revision: D38760358
fbshipit-source-id: f05629ddaa76daed9a3e59ce5d4af6f62ba83755
Summary:
Changelog: [iOS][Internal] - Add iOS implementation of the button property of the PointerEvent object
This implements the `button` property on the PointerEvent object by storing the button which caused the down event in the `ActiveTouch` and reporting that button through `pointerdown` and `pointerup` events and -1 on all others. This diff also includes a small fix to the `pressure` property which was introduced due to `button` being correctly implemented.
Reviewed By: yungsters
Differential Revision: D38632543
fbshipit-source-id: 9dbbb23a9251f2e661faf37fdf206b9f0b26bc5f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34384
This Diff aims to create a RCTAppDelegate library to offer a subclass which automates some operations required to set up the new architecture.
## Changelog
[iOS][Added] - Added the RCTAppDelegate library
Reviewed By: cortinico
Differential Revision: D38580424
fbshipit-source-id: 38f6c4b8ff2790a2ce9e23d385b36307701cffb7
Summary:
React Native is compiled downstream with MSVC, meaning the introduction of code depending on language extensions specific to gcc/clang may cause breakage.
We can enable `-Wpedantic` to flag any behavior not officially supported by the specified C++ standard. This will includes rules beyond what MSVC has trouble with, but seems to not have too many "noisy warnings".
This change enables -Wpedantic in BUCK targets within ReactCommon.
This makes the OSS C++ build for Android/iOS slightly more permissive than the internal build, A followup is to add the changes to OSS build logic as well, to avoid contributors seeing more errors upon internal submission. (checking with cortinico on how to do this for Android).
react-native-windows uses a higher warning level than `-Wall`, which is an additional cause of compilation failures, but is not addressed as part of this change.
Changelog:
[Internal][Changed] - Enable -Wpedantic for targets inside ReactCommon
Reviewed By: rshest
Differential Revision: D38457812
fbshipit-source-id: 014da1ac0b7ad8f78154e6e447ed58def6bd0d47
Summary:
Changelog: [iOS][Internal] - Fix ghost pointer leave/out events firing due to view recycling on iOS
While implementing the properties on the PointerEvent object on iOS I noticed that in certain specific scenarios I was seeing pointerLeave events being fired seemingly without corresponding pointerEvent events and even more strangely, when the pointer wasn't even close to the view in question.
After a lot of research I discovered that this was caused by an incompatibility between my strategy of keeping track/identifying views which are being hovered and RN's handling of creating/deleting views on iOS. See on iOS RN has the `RCTComponentViewRegistry` class which manages the creation & deletion of UIViews and adds an optimization of recycling views instead of outright deleting them.
This is causing issues with my tracking of which views are hovered because I compare the view's object references which, while accurate towards confirming equality of an underlying UIView — isn't accurate in confirming the equality of views from react's perspective.
This diff addresses this issue by adding a simple wrapper class that can be used around the UIViews which stores the view's react ID at initialization time ensuring it doesn't get updated even if the underlying view's react id is. As an additional precaution the wrapper class will also not return the view it's wrapping if their react tags do not match.
Reviewed By: lunaleaps
Differential Revision: D38546628
fbshipit-source-id: 8b732d52da0e61a5447001e8940e4439f49c6baf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34373
By introducing a RCTAppDelegate base class, we can simplify the migration step to supports TM
## Changelog
[iOS][Changed] - Simplified migration steps for TM
Reviewed By: cortinico
Differential Revision: D38509891
fbshipit-source-id: 716c1e668a05ecbd9c679558889564780816e491
Summary:
changelog: [internal]
`_forceDispatchNextScrollEvent` is already called inside `- (void)scrollToOffset:(CGPoint)offset animated:(BOOL)animated`. No need to call it before.
Reviewed By: cipolleschi
Differential Revision: D38499299
fbshipit-source-id: cf6635e02bf582346869f77194cf06be7939351f
Summary:
Use of `__attribute__` and `__unused` is compiler specific. Opt for standard `[[maybe_unused]]` instead.
## Changelog
[General] [Fixed] - Remove compiler-specific syntax.
Pull Request resolved: https://github.com/facebook/react-native/pull/34357
Test Plan: Built on react-native-windows.
Reviewed By: cipolleschi
Differential Revision: D38498481
Pulled By: javache
fbshipit-source-id: af43206788f54dda3b747b6417e20096c7d520e8
Summary:
Changelog: [iOS][Internal] - Add isPrimary property implementation to the PointerEvent object
This diff adds the `isPrimary` property to the PointerEvent object iOS implementation. In addition this adds a related change where we "reserve" the 0 touch identifier for mouse events and the 1 identifier for apple pencil events. This is an easy way to ensure that these pointers are always consistent no matter what happens. Since mouse & pencil pointers should always be considered the primary pointer, that allows us to focus the more advanced primary pointer differentiation purely on touch events.
The logic for this touch event primary pointer differentiation is essentially setting the first touch it recieves as a primary pointer, setting it on touch registration, and sets all subsequent touchs (while the first touch is down) as not the primary pointers. When that primary pointer is lifted, the class property keeping track of the primary pointer is reset and then the **next** pointer (secondary pointers which had already started before the previous primary pointer was lifted are not "upgraded" to primary) is marked as primary. A new platform test is also included in this diff in order to verify the aforementioned behavior.
Reviewed By: lunaleaps
Differential Revision: D37961707
fbshipit-source-id: ae8b78c5bfea6902fb73094fca1552e4e648ea44
Summary:
A crash encountered in react-native-macOS is very similar to one fixed by https://github.com/microsoft/react-native-macos/pull/489#discussion_r451789471 (see discussion), and it's possible this `replacement` string also suffers from sharing the same backing store as the attributed string (maybe only when the range encompasses the entire string?) and therefore should be copied as well.
Changelog:
[iOS][Fixed] - Possible fix for convertIdToFollyDynamic crash in RCTBaseTextInputView and RCTEventDispatcher
Reviewed By: sammy-SC
Differential Revision: D38064551
fbshipit-source-id: 9c15f2a980155ab3cbb3fde79fcb93b24ee2091a
Summary:
Currently, with the Alert API on iOS, the only way to bold one of the buttons is by setting the style to "cancel". This has the side-effect of moving it to the left. The underlying UIKit API has a way of setting a "preferred" button, which does not have this negative side-effect, so this PR wires this up.
See preferredAction on UIAlertController https://developer.apple.com/documentation/uikit/uialertcontroller/
Docs PR: https://github.com/facebook/react-native-website/pull/2839
## Changelog
[iOS] [Added] - Support setting an Alert button as "preferred", to emphasize it without needing to set it as a "cancel" button.
Pull Request resolved: https://github.com/facebook/react-native/pull/32538
Test Plan:
I ran the RNTesterPods app and added an example. It has a button styled with "preferred" and another with "cancel", to demonstrate that the "preferred" button takes emphasis over the "cancel" button.
Luna:
* Also tested this on Catalyst
{F754959632}
Reviewed By: sammy-SC
Differential Revision: D34357811
Pulled By: lunaleaps
fbshipit-source-id: 3d860702c49cb219f950904ae0b9fabef03b5588
Summary:
changelog: [internal]
This was used as a kill switch, it has been in place for over 4 months, let's get rid of it.
Reviewed By: mdvacca
Differential Revision: D37921377
fbshipit-source-id: 594586033694766e13d0f2ab2bcd73b28ba180a9
Summary:
There are many files across fbobjc relying on -include_pch and therefore they miss Foundation.h and UIKit.h includes. This diff was generated by a codemod and fixes these missing includes.
More details on the missing imports https://fb.workplace.com/groups/929548250966094/permalink/981237982463787/
Changelog: [Internal]
Reviewed By: yannickl
Differential Revision: D37282740
fbshipit-source-id: 0f419025b3cf2f811e96ff464cb19e8e5a25aa09
Summary:
Changelog: [iOS][Internal] - Add key modifier properties to the PointerEvent interface
This diff adds implementations of the `ctrlKey`, `shiftKey`, `altKey`, and `metaKey` properties on the PointerEvent interface for iOS.
Reviewed By: lunaleaps
Differential Revision: D37869377
fbshipit-source-id: b187bae93fbfc97b6ca1d8d9786ad85343484b3d
Summary:
Changelog: [iOS][Internal] - Implement offsetX/offsetY properties on the PointerEvent interface
Simple diff implementing the offsetX/offsetY properties on PointerEvent — thankfully the touch events already kept track of these so it was mostly a matter of forwarding that data to the pointer events.
Reviewed By: lunaleaps
Differential Revision: D37830139
fbshipit-source-id: 77f33a99393350d32cbe449e6a009bdeb2a12d08
Summary:
Changelog: [iOS][Internal] - Implement screenX/screenY properties on the PointerEvent interface
This diff implements the screenX/screenY properties which report the position of a pointer in the device's physical screen coordinates.
Reviewed By: lunaleaps
Differential Revision: D37794415
fbshipit-source-id: 6c39c3651812f99e66b93647579a2935598ef6f2
Summary:
Similarly to D37653146 (13a0556aaa), standardize on one type to refer to this.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D37658743
fbshipit-source-id: 9834cfc4bbe4ca1a19f10c2c8718e3f74b88d9b6
Summary:
Changelog: [iOS][internal] - Add twist property to PointerEvent interface
This adds the twist property to the PointerEvent implementation on iOS which similarly to tangentialPressure doesn't really apply so we default to a hard-coded value of 0.
Reviewed By: lunaleaps
Differential Revision: D37760511
fbshipit-source-id: f1fccfd6b5d07024cea83d86925a9bfc2e6cc8cf
Summary:
Changelog: [iOS][internal] - Add tangentialPressure property to PointerEvent interface
This diff adds the tangentialPressure property to the PointerEvent implementation on iOS. This one is pretty simple considering iOS doesn't have the concept of tangential pressure so we just hard code it to 0 as defined by the spec.
Reviewed By: lunaleaps
Differential Revision: D37759634
fbshipit-source-id: 7ca0e47267f5fde76ace2b96d05ea2e154cb4b8f
Summary:
Changelog: [Internal][iOS] Minor: Rename RCTNotAllowedInAppWideFabric to RCTNotAllowedInFabricWithoutLegacy
`RCTNewArchitectureValidationPlaceholder(RCTNotAllowedInBridgeless` is to track Bridge APIs that are okay in Fabric but not in Bridgeless.
`RCTNewArchitectureValidationPlaceholder(RCTNotAllowedInFabricWithoutLegacy` is to track legacy APIs that should not exist if the app was using Fabric **without any legacy architecture**. e.g. RCTBridgeModule, legacy interop view components.
Reviewed By: fkgozali
Differential Revision: D37659105
fbshipit-source-id: aee4e083820e83a8dac19eb3b5efc49b37d90039
Summary:
Changelog: [iOS][Internal] - Add `buttons` implementation to the PointerEvent interface
This diff adds an implementation of the `buttons` property by leveraging `UIEvent`'s `buttonMask` property.
Reviewed By: lunaleaps
Differential Revision: D37430270
fbshipit-source-id: 69fd3aebcb403e665349a24283a04c0eb82ff3e2
Summary:
Changelog: [Internal]
Add `RCTNewArchitectureValidationPlaceholder(RCTNotAllowedInAppWideFabric)` to track RCTViewManagers used in Fabric using the legacy interop layer. They work for now in the interop layer, but they need to be migrated to Fabric to remove potential issues with using the legacy architecture and the new architecture simultaneously. RCTNewArchitectureValidationPlaceholder is a no-op used for tracking unmigrated callsites that may be used often.
`RCTNewArchitectureValidationPlaceholder(RCTNotAllowedInBridgeless` is to track Bridge APIs that are okay in Fabric but not in Bridgeless.
This diff adds the validation placeholder to legacy components registered in [RCTLegacyViewManagerInteropComponentView.mm](743d0706e2/React/Fabric/Mounting/ComponentViews/LegacyViewManagerInterop/RCTLegacyViewManagerInteropComponentView.mm (L92-L99)).
Reviewed By: fkgozali
Differential Revision: D37635613
fbshipit-source-id: 5399dad822c8f5c11ef3b32297bf25214fd857dd
Summary: Changelog: [Internal] - We can now remove the '2' suffix as we had an internal implementation that was not truly aligned with W3C pointers but used the same name. We have aligned the internal types to match w3c so we can now remove the suffix that differentiates them.
Reviewed By: vincentriemer
Differential Revision: D37545813
fbshipit-source-id: 6f2336ae9e314066c340161113268c1f28621a71
Summary:
Changelog: [Internal]
- Make the new architecture validation easier to understand by enabling validation with `RCTNewArchitectureSetMinValidationLevel(level)`.
- When `RCT_ONLY_NEW_ARCHITECTURE` flag is enabled:
- `RCTErrorNewArchitectureValidation` calls `RCTLogAssert` instead of `RCTLogError`.
- `RCTNewArchitectureValidationPlaceholder` calls `RCTLog`, instead of no-op.
Reviewed By: fkgozali
Differential Revision: D37555667
fbshipit-source-id: 2c725c287a2dec19e8946c7fe5d8fa111e4a17fa
Summary:
This fix solves a problem very well evaluated [here](https://github.com/Expensify/App/issues/2727) as well as this [one](https://github.com/facebook/react-native/issues/29290).
The issue is that when the app goes to background, in landscape mode, the RCTDeviceInfo code triggers an orientation change event that did not physically happen. Due to that, we get swapped values returned when going back to the app.
I debugged the react-native code, and to me it seems that react native publishes the orientation change event one extra time when switching the state of the app to 'inactive'. Here is what is happening:
1. iPad is in landscape.
2. We move the app to inactive state.
3. Native Code queues portrait orientation change (no such change happened physically), and immediately after it triggers landscape change (same as we had in point 1).
4. We restore the app to active state.
5. The app receives two queued orientation change events, one after another.
6. The quick transition between portrait and landscape happens even though it never went back to portrait.
Fresh `react-native init` app repro case can be found here: https://github.com/lbaldy/issue-34014-repro
Video presenting the issue (recorded while working on: https://github.com/Expensify/App/issues/2727 ): https://www.youtube.com/watch?v=nFDOml9M8w4
## 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] - Fix the way the orientation events are published, to avoid false publish on orientation change when app changes state to inactive
Pull Request resolved: https://github.com/facebook/react-native/pull/34014
Test Plan:
### Test Preparation
1. Make sure you have a working version of E/App.
2. Open App/src/components/withWindowDimensions.js and update the constructor by changing this line:
`this.onDimensionChange = _.debounce(this.onDimensionChange.bind(this), 100);`
to
`this.onDimensionChange = this.onDimensionChange.bind(this);`
3. Open the NewExpensify.xcodeproj in xCode.
4. Open the RCTDeviceInfo.mm file and replace it's contents with the file from this PR.
5. Select your device of choice (I suggest starting with iPad mini) and run the app though xCode.
6. From this point you can move to the test scenarios described below.
### iPad Mini tests:
Reproduction + Fix test video (Test 1): https://youtu.be/jyzoNHLYHPo
Reproduction + Fix test video (Test 2): https://youtu.be/CLimE-Fba-g
**Test 1:**
1. Launch app in portrait, open chat - no sidebar visible.
7. Switch to landscape - sidebar shows.
8. Put app to background.
9. Put app back to foreground - make sure the side menu doesn't flicker.
**Test 2:**
1. Launch app in portrait, open chat - no sidebar visible.
2. Switch to landscape - sidebar shows.
3. Put app to background. Switch orientation back to portrait.
4. Put app back to foreground - make sure the side menu hides again as it should be in portrait.
### iPad Pro tests:
Reproduction + Fix test video (Test 3, Test 4): https://youtu.be/EJkUUQCiLRg
iPad mini test 1 applies.
Scenario 2 does not as the screen is too wide in both orientations and iPad pro shows sidebar always.
**Test 3:**
1. launch the app.
2. Make sure you're in landscape mode.
3. See split screen with some other app. Make sure the side bar is visible.
4. Play with the size of the view, resize it a bit. When the view shrinks it should hide the sidebar, when it grows it should show it.
10. Move the app to background and back to foreground, please observe there are no flickers.
**Test 4:**
1. Launch the app.
2. Make sure you're in landscape mode.
3. Make the multitasking view and make Expensify app a slide over app.
4. Move back to fullscreen/split screen. Make sure the menu is shown accordingly
5. Move the app to background and back to foreground, please observe there are no flickers.
### iPhone:
Non reg with and without the fix video: https://youtu.be/kuv9in8vtbk
Please perform standard smoke tests on transformation changes.
Reviewed By: cipolleschi
Differential Revision: D37239891
Pulled By: jacdebug
fbshipit-source-id: e6090153820e921dcfb0d823e0377abd25225bdf
Summary:
We will use this error reporting pipeline for all js errors not only early js errors, so remove all "early" prefixes.
Changelog:
[General][Changed] - Remove "Early" in Js error reporting pipeline
Reviewed By: fkgozali
Differential Revision: D37379339
fbshipit-source-id: d44772818ead977a164c8632c081863851046be6
Summary:
TL;DR: For applications using JS navigation, save 50-95% of CPU during mounting phase in N>2 navigations that replace ~most of screen.
During investigation of performance on the UI thread of React Native applications, I noticed that the /initial/ render of an screen for an application using JS navigation is /mostly/ consumed (on the UI thread) by tearing-down the previous View hierarchy. In one 185ms segment on the UI thread in production, 95% of the CPU time was Remove/Delete instructions and only 5% of CPU time was consumed by actually displaying the new hierarchy (this is specific to Android and also assumes that View Preallocation is being used, so post-commit work consists of Insert and UpdateLayout mutations primarily).
There are /some/ cases where the C++ differ knows that we are deleting an entire subtree and therefore we could communicate this to the mounting layer. All that matters is that these Views are removed from the View hierarchy immediately; and secondarily that their memory is cleaned up ASAP, but that doesn't need to happen immediately.
Some additional constraints and notes:
1) As noted in the comments, we cannot simply stop producing Remove and Delete instructions. We need to produce /both/ the new RemoveDeleteTree instruction, /and/ produce all the Remove/Delete instructions, primarily because LayoutAnimations relies heavily on these Remove/Delete instructions and certain things would break if we removed those instructions entirely. However, we can mark those Remove/Delete instructions as redundant, process them only in LayoutAnimations, and not send them to the Android mounting layer.
2) We want to make sure that View Recycling is not impacted. Since Android cannot take advantage of View Recycling until /after/ the second major render (preallocation of views will happen before any views are recycled), this doesn't impact View Recycling and we'll make sure Views are recycled whenever they are deleted.
Thus, we do two things:
1) Introduce a new RemoveDeleteTree operation that can delete an entire subtree recursively as part of one operation. This allows us to avoid serializing hundreds or thousands of instructions and prevents JNI traffic.
2) Besides removing the topmost View from the View hierarchy, and ensuring it's not drawn, the full teardown and recycling of the tree can happen /after/ the paint.
In some flows with JS navigation this saves us 95% of CPU during the mount phase. In the general case it is probably closer to 25-50% of CPU time that is saved and/or deferred.
Changelog: [Android][Changed] Significant perf optimization to Fabric Remove/Delete operations
Reviewed By: ryancat
Differential Revision: D37257864
fbshipit-source-id: a7d33fc74683939965cfb98be4db7890644110b2
Summary:
Changelog: [iOS][Internal] - Emit move PointerEvents when hovering with an indirect pointer
This diff ensures that when a user is hovering an RN app w/ an indirect pointer (mouse/trackpad/ect.) that `pointermove` events are emitted. Previously `pointermove` was only fired on touch interactions on iOS.
Reviewed By: lunaleaps
Differential Revision: D37353158
fbshipit-source-id: 30366324ea10c91a38dbbc1be1032c021fd8a0e0
Summary:
Bumping RTC-Folly version used to address CVE-2022-24440.
## 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
-->
[General][Security] - Bump RTC-Folly to 2021-07-22
Pull Request resolved: https://github.com/facebook/react-native/pull/33841
Reviewed By: Andjeliko, philIip
Differential Revision: D36425598
Pulled By: cortinico
fbshipit-source-id: d38c5f020dbecf794b10f12ed2da30e1825071af
Summary:
Original commit changeset: 78387999f94e
Original Phabricator Diff: D34392529 (086c13dd5f)
Backing this out because it breaks univeral hot reload support. We should probably find a way to support this *without* relying on swizzling. This was originally backed out it because it was blocking app store submission, but this is gated by `RN_DEV` so should never be included in a release build.
Changelog:
[General][Removed] - The diffs renames the required variable which was causing conflicts in names with Apple core SDK's
Reviewed By: cipolleschi
Differential Revision: D37311377
fbshipit-source-id: 18abb1b53a5be054098cd3717705ea5086c4f595
Summary:
# Context
ScrollView sticky headers rely on this bit of code to work:
```
AnimatedImplementation.attachNativeEvent(
this._scrollViewRef,
'onScroll',
[{nativeEvent: {contentOffset: {y: this._scrollAnimatedValue}}}],
);
```
What this code means:
When the ScrollView host component receives the "onScroll" event, assign event.nativeEvent.contentOffSet.y to the this._scrollAnimatedValue AnimatedValue.
How this subscription mechanism is set up:
NativeAnimatedTurboModule subscribes to events dispatched by RCTEventDispatcher sendEvent. Then, whenever RCTEventEmitter sendEvent executes, NativeAnimatedTurboModule also updates the AnimatedValue for that event.
# Problem
Previously, in bridgeless, we started dispatching RCTScrollView via the RCTEventDispatcher sendEvent to update the AnimatedValue for ScrollView. This meant that we started dispatching the onScroll event to JavaScript via RCTEventEmitter.receiveEvent JSModule, which isn't supported in the Fabric renderer.
With this diff, we dialed back that solution. Instead of (1) notifying NativeAnimatedTurboModule and (2) sending the onScroll event to JavaScript, we're only doing (1) (i.e: notifying NativeAnimatedTurboModule).
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D37257719
fbshipit-source-id: 7dea3cf8b9ae78f6b0fd40414b8f224d43367a5a
Summary: Some files relying on -include_pch and therefore they miss Foundation.h and UIKit.h includes. This diff is fixing missing imports
Reviewed By: rmaz
Differential Revision: D37140239
fbshipit-source-id: bc57921e0c8365e0e9a5a571d607ba40ff1b31f3
Summary:
In https://github.com/facebook/react-native/pull/32695, the `Performance.now()` implementation changed to use unix epoch timestamps instead of a monotonic clock.
This is problematic, because it means that performance measurements get skewed if the device clock changes between two measurements.
With this change, the clock is now monotonic (and the implementation stays consistent between platforms).
More details and repro steps can be found in [this issue](https://github.com/facebook/react-native/issues/33977)
Closes https://github.com/facebook/react-native/issues/33977
## Changelog
[General] [Fixed] - Use monotonic clock for performance.now()
Pull Request resolved: https://github.com/facebook/react-native/pull/33983
Test Plan:
Run on iOS and Android:
```
const now = global.performance.now()
console.log(`${Platform.OS}: ${now}`)
```
Reviewed By: JoshuaGross, cipolleschi
Differential Revision: D37066999
Pulled By: dmitryrykun
fbshipit-source-id: 298547bf39faea1b025c17ff2d2e1a03f929865b
Summary:
Changelog: [iOS][Fixed] - `_scrollViewComponentView` is set to `RCTPullToRefreshViewComponentView's` superview:
```
_scrollViewComponentView = [RCTScrollViewComponentView findScrollViewComponentViewForView:self];
```
It should be safe to make it weak.
Reviewed By: javache
Differential Revision: D36998626
fbshipit-source-id: 2130b743d181e15986cb68636d60507a986968e1
Summary:
Problem - Error when trying to publish to Apple Store in debug scheme
Error thread - https://github.com/facebook/react-native/issues/31507
## 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
-->
[General][Removed] - The diffs renames the required variable which was causing conflicts in names with Apple core SDK's
Pull Request resolved: https://github.com/facebook/react-native/pull/33153
Reviewed By: lunaleaps
Differential Revision: D34392529
Pulled By: sshic
fbshipit-source-id: 78387999f94e0db71f5d3dafff51e58d7d0c1847
Summary:
Due to invalid utf-8 data NSString may return nil during initialisation and this leads to crash when nil goes to NSDictionary or NSArray
Changelog: [Internal]
Differential Revision: D36623628
fbshipit-source-id: 23efad87cc9fe4a23c5e90dad63e0d74036b62fa
Summary:
Noticed we were copying ShadowView, where a reference should suffice.
Changelog: [Internal]
Reviewed By: appden
Differential Revision: D36455200
fbshipit-source-id: 2cd3cf66b9e5ec05bce9ce1d739fbed66f3a6d89
Summary: [RN][iOS] Changelog: [Internal][Fix] Minor fix: Don't display a legacy surface from Logbox if Bridge is invalid
Reviewed By: RSNara
Differential Revision: D36268234
fbshipit-source-id: 227f465fb1fc2953b5d6813485ed6750b1d3dea3
Summary: Changelog: [iOS][Internal] - Only fire pointerEnter/Leave events if a view in the event path is listening to that event
Reviewed By: yungsters
Differential Revision: D35911045
fbshipit-source-id: 8b3021619622c3e83c15acea46c23bfe3e0f9284
Summary:
Using Fabric with a Swift native module is currently broken. There are currently two issues.
If you try to integrate a native module with Swift code, you will get the following error when running `pod install` with Fabric enabled:
```
[!] The following Swift pods cannot yet be integrated as static libraries:
The Swift pod `MyNativeView` depends upon `React-RCTFabric`, `React-Codegen`, `RCTTypeSafety`, and `ReactCommon`, which do not define modules.
To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries),
you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies.
```
To resolve this, I have applied the suggestion from the error (set `:modular_headers => true` for the appropriate modules inside `react_native_pods.rb`.
Afterwards, `pod install` succeeds but I still got `Redefinition of module 'React'` during the build due to the conflict inside the generated modulesmaps `React-Core.modulemap` and `React-RCTFabric.modulemap`. This makes sense since `React-RCTFabric.podspec` has `s.header_dir = "React"` (see [here](https://github.com/facebook/react-native/blob/main/React/React-RCTFabric.podspec#L37)) and the module inherits that. However, we can explicitly specify `module_name` for the podspec which is what I have done. I have named the module `Fabric`, let me know if you think there's a better name.
## 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] - Fix using Swift in a native module with Fabric enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/33743
Test Plan:
1. Clone [this](https://github.com/fortmarek/react-native) repo
2. From `main`, apply changes from [this](26958fccf4) commit (adding Swift file to the `MyNativeView` native module in the RN tester app)
3. Try to run `USE_FABRIC=1 RCT_NEW_ARCH_ENABLED=1 USE_CODEGEN_DISCOVERY=1 USE_HERMES=0 bundle exec pod install` inside the `packages/rn-tester`
4. Observe errors
5. Apply [the commit](9772c6209d) from this PR
6. Both pod install and the subsequent build should succeed.
I can also make changes to the current `MyNativeView` module to include Swift as well if it's something that the React Native Core team would be interested in - in case you want the Swift native modules to be always buildable on `main`
Reviewed By: dmitryrykun
Differential Revision: D36097852
Pulled By: cipolleschi
fbshipit-source-id: 2faebcffd1115339f89a406e265a6a040218dc9c
Summary:
Changelog: [Internal][iOS] Fix AppState in Bridgeless mode by removing guard for bridge, since it doesn't use bridge
AppState doesn't use bridge because RCTAppState subclasses RCTEventEmitter, which calls `_callableJSModules invokeModule` in both Bridge and Bridgeless mode to send events to JS.
Reviewed By: fkgozali
Differential Revision: D35988515
fbshipit-source-id: fb19f0f2df5b270f0ef57637930f94686e39a9a1
Summary:
This would fix test errors caused by including <string> in non-C++ compatible files.
Changelog:
[General][Changed] - Remove usage of std::string in EarlyJsErrorHandler.
Reviewed By: RSNara
Differential Revision: D35645334
fbshipit-source-id: 7f04d2c66d53dc1eef63367de1a64ed9273898f5
Summary:
Changelog:
[iOS][Fixed] - Expose the extraData dict attached to JavaScript errors to the native ExceptionManager on iOS, similar to Android
Attaching the `extraData` dict to JavaScript crash reports is something that was done for Android only in 2019 (D16133080 (3a825c0360)), and somehow we never really got around to adding it in iOS. This diff finally adds the capability to iOS as well. `extraData` can be used to attach various bits of data to a crash report for better debugging and categorization. As with the Android implementation, `extraData` is not attached if the `reportException` API is not used.
Reviewed By: dmitryrykun
Differential Revision: D35743658
fbshipit-source-id: de4060cb6e514db1d85907441a8962f98e9b8392
Summary:
Apple suggested to this new API on iOS 10+.
> // Any new bitmap drawing code is encouraged to use UIGraphicsImageRenderer in lieu of this API.
WWDC18 Reference: https://developer.apple.com/videos/play/wwdc2018/219/
> Use UIGraphicsImageRenderer to create and draw to an image buffer
Supports Wide Color, unlike UIGraphicsBeginImageContext()
Combine with UIImageView for efficient offscreen rendering
Per https://nshipster.com/image-resizing/#performance-benchmarks, the new API runs even faster than the C version, probably due to more smart context reuses/management.
Changelog:
[iOS][Changed] - Adopt UIGraphicsImageRenderer API
Reviewed By: philIip
Differential Revision: D35699584
fbshipit-source-id: 7a1e2109d5e121fb396c1014f4ed0a892211b0cc
Summary:
https://fb.workplace.com/groups/fbapp.commerce.engsupport/permalink/2074812256012212/
Back out "[react-native][PR] Pass mutation list to RCTMountingTransactionObserving callbacks"
Original commit changeset: f40afc512f2c
Original Phabricator Diff: D35214478 (91fc2c0091)
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D35825832
fbshipit-source-id: b53b616dca39c84b3a8e8e4cbaa4a45834e53fe3
Summary:
This PR updates `RCTMountingTransactionObserving` protocol to accept full `MountingTransaction` object as an argument to its methods as opposed to just `MountingTransactionMetdata` which contained only some subset of information.
This change makes it possible for components implementing the protocol to analyze the list of mutations and hence only take action when certain mutations are about to happen.
One of the use cases for `RCTMountingTransactionObserving` protocol is to allow for Modal to take view snapshot before it is closed, such that an animated close transition can be performed over the snapshotted content. Note that when modal is removed from the view hierarchy its children are gone too and therefore the snapshot mechanism makes it possible for children to still be visible while the animated closing transition is ongoing. A similar use-case to that can be seen in react-native-screens library, where we use the same snapshot mechanism for views that are removed from navigation stack.
Before this change, we'd use `mountingTransactionDidMountWithMetadata` to take a snapshot. However, making a snapshot of relatively complex view hierarchy can be expensive, and we'd like to make sure that we only perform a snapshot when the given modal is about to be removed. Because the mentioned method does not provide an information about what changes are going to be performed in a given transaction, we'd make the snapshot for every single view transaction that happens while the modal is mounted.
In this PR we're updating `RCTMountingTransactionObserving` protocol's methods, in particular, we rename methods to no longer contain "Metadata" in them and to accept `MountingTransaction` as the only argument instead of `MountingTransactionMetadata` object. With this change we are also deleting `MountingTransactionMetadata` altogether as it has no uses outside the protocol. Finally, we update the two uses of the protocol in `RCTScrollViewComponentView` and `RCTModalHostViewComponentView`.
## Changelog
[iOS][Fabric] - Update RCTMountingTransactionObserving protocol to consume MountingTransaction objects
Pull Request resolved: https://github.com/facebook/react-native/pull/33510
Test Plan:
As there are not that many uses of `RCTMountingTransactionObserving` protocol during testing I focused on checking if the updated method is called and if the provided objects contains the proper data. Unfortunately, despite code for the modal protocol being present in OSS version it does seem like some parts of modal implementation are still missing and the component only renders an unimplemented view (checked this with rn-tester). I only managed to verify the use in `RCTScrollViewComponentView` with the following steps:
1. Build for iOS
2. Put a breakpoint in mountingTransactionDidMount method in `RCTScrollViewComponentView.mm`
3. Verify that the program stops on the breakpoint when a scrollview is rendered (use any screen on rn-tester app)
4. Inspect the provided object in the debugger (ensure the list of transactions is not empty)
Outside of that we verified the transactions can be processed in `mountingTransactionDidMount` after the changes from this PR are applied in FabricExample app in [react-native-screens](https://github.com/software-mansion/react-native-screens/tree/main/FabricExample) repo.
Reviewed By: cipolleschi
Differential Revision: D35214478
Pulled By: ShikaSD
fbshipit-source-id: f40afc512f2c8cfa6262d2fb82fb1ccb05aa734c
Summary:
`hotkeysEnabled` property is added to `RCTDevMenu` which allows enabling/disabling hotkeys that triggers developer menu popup
Changelog:
[iOS][Added] - `hotkeysEnabled` property is added to `RCTDevMenu` which allows enabling/disabling hotkeys that triggers developer menu popup
Reviewed By: arhelmus
Differential Revision: D35777883
fbshipit-source-id: a7435358701bedb54e33198724180eb1c27248b8
Summary:
We've seen a couple of `EXC_BAD_ACCESS` crashes in [`RCTParagraphComponentAccessibilityProvider.mm:L125`](52d8a797e7/React/Fabric/Mounting/ComponentViews/Text/RCTParagraphComponentAccessibilityProvider.mm (L125)), most likely explained by [RCTLocalizationProvider RCTLocalizedString] returning nil, which will happen in the case that a language pack has no entry for the input string.
This is a small defensive change to fall back to the input if there's no better alternative.
Changelog:
[iOS][Fixed] - `RCTLocalizationProvider` Fall back to input when no localization is available
Reviewed By: luluonet
Differential Revision: D35583786
fbshipit-source-id: e8ae6ff61518e105301e7e51f5d8f43290fb20bf
Summary:
Changelog: [Internal][iOS] Add validation log to the only static method in RCTUIManager, JSResponder
When all surfaces of an app has been fully migrated to Fabric, we don't expect `[RCTUIManager JSResponder]` to be called, so I'm expecting this API to be broken on Fabric and Bridgeless.
Reviewed By: RSNara
Differential Revision: D35723794
fbshipit-source-id: ec786946a33fca98c89e8cad0e0467bf45dc1735
Summary:
Changelog: [internal]
we have an issue where the moduleRegistry that the TM uses is released, adding this log to check if it's bc the bridge was released
Reviewed By: RSNara
Differential Revision: D35420922
fbshipit-source-id: 93c206b5afefeac3121df148940d9658736cb9d2
Summary:
Changelog: [Internal][Bridgeless] Fix sticky headers for scrollviews by sending onScroll event to legacy RCTEventDispatcher
## Extra Context
FYI. <ScrollView> is the only Fabric component view that needs to send events via the legacy RCTEventDispatcher. Ideally, all component views should only use `ViewEventEmitter` to send events to JS and not use RCTEventDispatcher. This ScrollView does use ScrollViewEventEmitter, a subclass of ViewEventEmitter:
```
std::static_pointer_cast<ScrollViewEventEmitter const>(_eventEmitter)->onScroll([self _scrollViewMetrics]);
```
However, it also needs RCTEventDispatcher for animations using `Animated.event` for `useNativeDriver: true`. See [ScrollView.js](370c65b943/Libraries/Components/ScrollView/ScrollView.js (L1124-L1129)).
Reviewed By: RSNara
Differential Revision: D35540277
fbshipit-source-id: a28535ed10cac8e003523ecda6080574fbb89b85
Summary:
The reason why I'm working on this is to reduce the delta between this and the react-native-macos fork, in particular with the android patch folder "Build": https://github.com/microsoft/react-native-macos/tree/main/android-patches/patches/Build (it's a long story)
While checking the changes in there, I noticed that one of them was a bump of boost. Looking back into main (here), I then noticed that there have been two bumps to boot in the repo so far:
* a combo update 5 years ago to 1.63:
* 193afff926
* 5c24a9110a
* and an update for the iOS side to 1.76 by Kudo last year: https://github.com/facebook/react-native/pull/31840
So this quickly turned into this: the PR wants to re-align the version of boost used in both iOS and Android.
I explored the option of bumping both to 1.78 (latest at the time of writing: https://www.boost.org/users/history/version_1_78_0.html) but then I noticed that there's a Flipper dependency, `Flipper-Boost-iOSX`, on the iOS pods side that has been released only once and it seems to imply that it's 1.76 only compatible https://github.com/priteshrnandgaonkar/Flipper-Boost-iOSX/releases/tag/1.76.0.1.11.
So going to 1.78 at least for now seems like a no-go, and I've settled for just aligning everything to 1.76 and just like iOS, move away from `boost-for-react-native` in favour of the original one.
While doing so, I also noticed that the `React/third-party.xcconfig` still had a reference to 1.68 instead of 1.76 which seems like a leftover from Kudo's PR... it's probably because it was not doing anything in the first place, so lmk if you want me to delete 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
-->
[Android] [Changed] - Bump boost for Android to 1.76 to align with iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/33565
Test Plan:
CI is green (aside an unrelated ios rntester job that is also broken on main) ✅
Locally both RNTester and new app work:
<img width="432" alt="Screenshot 2022-04-05 at 16 42 31" src="https://user-images.githubusercontent.com/16104054/161815444-0de63919-b90d-4a48-963a-872f0cc4ce79.png">
<img width="346" alt="Screenshot 2022-04-05 at 18 06 01" src="https://user-images.githubusercontent.com/16104054/161815438-b7b1c997-9dcd-47bd-acbe-732155941bb0.png">
Reviewed By: sshic
Differential Revision: D35433032
Pulled By: cortinico
fbshipit-source-id: 0d93f61f8c26eda1dd04127a8b20e799ab6828cb
Summary:
Changelog: [Fabric][iOS] Fix: Make RCTSurfacePresenter weakly retain its observers
There is retain cycle because RCTSurfacePresenter is keeping an array of RCTSurfacePresenterObserver, which is strongly retaining the class that owns this RCTSurfacePresenter.
This diff makes RCTSurfacePresenter weakly retain observers instead.
Reviewed By: RSNara
Differential Revision: D35439589
fbshipit-source-id: ddc7813976b543de12af6173b2f1b31c69b043a8
Summary:
changelog: [internal]
this never fired, so it's not the cause of the nil moduleRegistry issue
Reviewed By: christophpurrer
Differential Revision: D35419873
fbshipit-source-id: 45693d3aa97d9efed2fe5085c281b57f1629764d
Summary:
Now that the PFH node has been renamed this updates the pfh label.
Produced via `xbgs -l -e '"pfh:ReactNative_CommonInfrastructurePlaceholde"' | xargs sed -i 's/"pfh:ReactNative_CommonInfrastructurePlaceholde"/"pfh:ReactNative_CommonInfrastructurePlaceholder"/'`
Reviewed By: jkeljo
Differential Revision: D35374087
fbshipit-source-id: 61590f69de5a69ec3b8a0478f6dd43409de3c70b
Summary:
While it would be better to be able to do all of the ownership metadata at the Buck macro level, that proved to be more work than expected.
This diff adds the corresponding pfh label to all targets in `xplat/js/react-native-github` that have a Supermodule label. Once the migration is complete the Supermodules labels will be able to be removed.
Reviewed By: cortinico
Differential Revision: D35221544
fbshipit-source-id: d87d5e266dfb5e6ee087251dc34dff5db299bbaf
Summary:
Changelog: [iOS][Internal] Add api to disable New validation reporting
Previously `RCTNewArchitectureValidationSetEnabled` was not set to false once it was set to true when a use is in app-wide Bridgeless mode.
This resulted it being in an incorrect state if a user:
1) Opens RN while in app-wide Bridgeless enabled
2) Logout
3) Re-login as another user without killing the app.
The fix is to set `RCTNewArchitectureValidationSetEnabled(RCTNotAllowedValidationDisabled)` in FBReactModule initialization.
Reviewed By: RSNara
Differential Revision: D35233335
fbshipit-source-id: 82a2c2ed030df5d68267a40b14322e652eb29e96
Summary:
Changelog: [iOS][Internal] Refactor: Migrate Logbox surface initialization to Fabric when available, in Bridge and Bridgeless modes
# Why
This diff main purpose is to add `RCTErrorNewArchitectureValidation(RCTNotAllowedInAppWideFabric)` in `RCTSurface`, to ensure Paper surfaces are never created in FBiOS.
# The Situation
Before this diff, in Bridged Fabric, `[RCTLogbox show]` initializes a Paper `RCTSurface`, [using `[RCTLogBoxView initWithWindow]`](https://github.com/facebook/react-native/blob/main/React/CoreModules/RCTLogBoxView.mm#L46))
In this diff, in Bridged and Bridgeless Fabric, `[RCTLogbox show]` initializes a Fabric `RCTFabricSurface`.
Before this diff, in Bridgeless Fabric, RCTLogBox posts a "CreateLogBoxSurface" notification to RCTInstance.
In this diff, the notification hack is replaced by the same `RCTFabricSurface` initialization above.
Behavior is the same.
Reviewed By: RSNara
Differential Revision: D35177311
fbshipit-source-id: 6de418af8a01f914c9a806bb8d74915015f9087a
Summary:
Changelog: [iOS][Internal] Remove RCTNotAllowedInBridgeless validation for RCTRegisterModule
In the TurboModule system, `RCTRegisterModule` gets called for all `RCTBridgeModules` that calls `RCT_EXPORT_MODULE()` and it works fine in Bridgeless mode.
Reviewed By: RSNara
Differential Revision: D35203039
fbshipit-source-id: 8ae2be4487fe21653a7f1628fa92606a7d36d467
Summary:
In short, if an RCTEventDispatcher observer sends an event on the same thread that the observer was initially on, there will be a deadlock due to `sendEvent` already having the lock active on the `_observers` NSHashTable. An example where this occurred was when we had react-native-gesture-handler trigger an animated event, which then triggered an event on the underlying component being animated as a result of it being an observer on the animation event. Since this all occurred on the main thread, we ended up with a deadlock and the app froze.
To prevent this scenario, I used a `NSRecursiveLock` for _observersLock to be able to dispatch events on the same thread from observers.
joebernard
## 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] [Fix] - Prevent deadlock when dispatching events from observers on the same thread.
Pull Request resolved: https://github.com/facebook/react-native/pull/33490
Test Plan:
Not sure if there are any tests present for sending events with RCTEventDispatcher already in place, but In regular app usage this solution has proved to be a viable and stable option so far and has prevented the deadlock from occurring.
This would still be thread-safe since we are now allowing the event to be sent through observers on the same thread the initial event was dispatched on. The only issue I could see here is the behavior of sending an event could be changed.
Reviewed By: RSNara
Differential Revision: D35118752
Pulled By: charlesbdudley
fbshipit-source-id: 7e93a8d49841e001b235a437ccca1e072dcc7ab1
Summary:
Changelog: [iOS][Internal] Rename RCTNotAllowedInFabric to RCTNotAllowedInAppWideFabric
Clarify that methods marked with `RCTNotAllowedInAppWideFabric` are only NOT available when Fabric is app-wide (which is necessary for app-wide Bridgeless mode). These methods may still be called in apps with legacy pre-Fabric surfaces.
Reviewed By: RSNara
Differential Revision: D35194789
fbshipit-source-id: e16fa54d22ea67be995e93f6ff60567a117398be
Summary:
If an RN app is embedded in a Mac Catalyst app that uses the UIWindowScene API to manage multiple windows, LogBox would fail to render because it didn't know which UIWindowScene to render to. This diff fixes that situation by ensuring that the LogBox window gets rendered in the key window's scene.
Changelog:
[iOS][Fixed] - Update iOS LogBox to render its UIWindow with the key window's UIWindowScene
Reviewed By: appden
Differential Revision: D35027831
fbshipit-source-id: e0df5865f95323b03d08d6b1fb3ec912aa9a9167
Summary:
Changelog: [Internal][iOS] Add validation reporting APIs for unexpected uses of Paper when Fabric is enabled
## RCTNotAllowedInBridgeless
Previously, we only had violation reporting APIs for when **Bridge APIs** are used in **Bridgeless mode**, which was only enabled in Bridgeless mode.
## RCTNotAllowedInFabric
This diff adds violation reporting APIs to use when **pre-Fabric Bridge APIs** are used in **Bridge or Bridgeless mode**. This allows us to add RCTAssert/RCTError/RCTLog to more APIs in Bridge mode. The main purpose is to distinguish between Bridge APIs that still work in Fabric, versus Bridge APIs that are no longer used in Fabric, so that the latter can be removed.
Reviewed By: philIip
Differential Revision: D35015758
fbshipit-source-id: 35366bc5143a59ee9a16d75da4de546ebfe250e6
Summary:
Changelog: [Internal]
this doesn't really make any sense, first of all CGFloat is a primitive data type so comparing it against nil only will return true if it's 0. but that won't catch cases where CGFloat is uninitialized bc it will be holding junk in memory.
the error checking of the value is already handled in the accessibility manager, so just remove it here.
Reviewed By: p-sun
Differential Revision: D34909365
fbshipit-source-id: 483f9c100433f8533edd784622523c5469c616c2
Summary:
Changelog: [Internal]
for the last 6 months or so, we've been getting this task where the moduleRegistry in RCTDeviceInfo is nil. in this change, i add some logs to see what might be setting this to nil.
in all honestly, i don't really think this is happening, but it would be good to verify.
Reviewed By: sshic
Differential Revision: D34908902
fbshipit-source-id: d375285467a87453605ba0fecfc124bc3bff6e63
Summary:
When starting the surface, _propagateStageChange is called. This checks the delegate to call surface:didChangeStage: on it.
When initWithSurface:sizeMeasureMode: is called after start, then the delegate will be nil and thus not be called.
This turns it around so a delegate is present for the surface to propagate its state to.
This fixes RCTContentDidAppearNotification not getting posted otherwise.
## Changelog
[iOS] [Fixed] - Post RCTContentDidAppearNotification with new arch
Pull Request resolved: https://github.com/facebook/react-native/pull/33402
Test Plan:
I found it best to set a breakpoint in XCode to where RCTContentDidAppearNotification is being posted.
Prior to the patch that breakpoint will not be called. After applying the patch, it will be called.
Reviewed By: philIip
Differential Revision: D34753329
Pulled By: ShikaSD
fbshipit-source-id: cc44a4c3a787d49e22e9d0c3a82c0f11ed281a0a
Summary:
This PR adds a `dismissActionSheet` method to `ActionSheetIOS` in order to allow dismissing an ActionSheet programmatically. This is especially useful in apps where a user has the ability to open an ActionSheet and then open a push notification that will redirect them to another screen which usually leads to scenarios where the presented ActionSheet has no relation with the current screen.
#### TODO
- [ ] Submit react-native-website PR updating ActionSheetIOS documentation.
## Changelog
[iOS] [Added] - Add dismissActionSheet method to ActionSheetIOS
Pull Request resolved: https://github.com/facebook/react-native/pull/33189
Test Plan:
1. Open the RNTester app and navigate to the ActionSheetIOS page
2. Test `dismissActionSheet` through the `Show Action Sheet and automatically dismiss it` example
https://user-images.githubusercontent.com/11707729/155867546-c6770a49-9b09-45e3-a6b1-4f7645d67dbf.mov
Reviewed By: lunaleaps
Differential Revision: D34518952
Pulled By: cortinico
fbshipit-source-id: 912a9b83ee078f791b42efddf5abb7e1cd09d520
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:
changelog: [internal]
For embedded React Native screens, we need to calculate the intrinsic size. To do that, we need to pass Yoga value `YGUndefined`. However, if available size was `CGFLOAT_MAX` (which is not inifinity), we would pass it to Yoga and it would calculate layout with available height/width `CGFLOAT_MAX`.
To fix this, we convert `CGFLOAT_MAX` to infinity. Which in YogaLayoutableShadowNode gets converted to YGUndefined.
Reviewed By: ShikaSD
Differential Revision: D34719047
fbshipit-source-id: e6fd40724f81abfba164e67efc9ca8fc74e9b235
Summary:
We're seeing a red box that `Component 'RCTModalHostView' re-registered bubbling event 'topDismiss' as a direct event moduleConstantsForComponent` in some downstream react-native-macOS builds.
Looking at other usage of this object, we treat it as a direct event block everywhere else, just this one spot it's a bubbling event block. It was added with [this PR](7bf78eae5e) which doesn't explicitly address the desire for the prop to bubble up through the view hierarchy or not, so I'm guessing it was just mislabeled and should be direct like the other usages.
## Changelog
[iOS] [Bug] - Fix modal redbox for onDismiss
Pull Request resolved: https://github.com/facebook/react-native/pull/33222
Test Plan: We don't redbox downstream anymore
Reviewed By: p-sun, RSNara
Differential Revision: D34628759
Pulled By: philIip
fbshipit-source-id: bb3cc78fa43d20808579c614e25716880d002d88
Summary:
Changelog: [iOS] Add `_viewRegistry_DEPRECATED addUIBlock` to replace `uiManager addUIBlock` for Fabric migration
Allow people to directly replace `uiManager addUIBlock` with `_viewRegistry_DEPRECATED addUIBlock` when they migrate the method in RCTViewManagers.
Currently we add an if check in the RCTViewManager, which makes migration a bit harder for OSS.
```
if (self.bridge) {
[self.bridge.uiManager addUIBlock:^(__unused RCTUIManager *uiManager, NSDictionary<NSNumber *, UIView *> *viewRegistry) {
work();
}];
} else {
RCTExecuteOnMainQueue(work);
}
```
Reviewed By: sammy-SC
Differential Revision: D34532609
fbshipit-source-id: 19647fea03be8fd71d8f46dfe216275894d8165c
Summary:
Changelog: [iOS][Internal] Use synthesize viewRegistry_DEPRECATED for Keyframes to remove RCTWeakViewHolder
Remove the `RCTWeakViewHolder` hack, since it can be replaced with `viewRegistry_DEPRECATED viewForReactTag`.
Reviewed By: RSNara
Differential Revision: D34468082
fbshipit-source-id: be41ed2df6ee195409724f6069fd99a793dca01a
Summary:
In c974cbff04 I changed the borderColor from CGColor to UIColor. I missed this view property which should also be updated to reflect the original change.
## Changelog
[iOS] [Fixed] - Set RCTView borderColor to UIColor
Pull Request resolved: https://github.com/facebook/react-native/pull/33176
Test Plan: Nothing to test. See PR https://github.com/facebook/react-native/pull/29728
Reviewed By: javache
Differential Revision: D34461141
Pulled By: genkikondo
fbshipit-source-id: 51adf39c1cebe8e3b53285961358e4c7f26192db
Summary:
Changelog: 2/n Refactor RCTModuleData to use RCTBridgeModuleDecorator, to attach synthesize ivars to non-TurboModule RCTBridgeModules in Bridge mode
I decided to not include the `RCT_PROFILE_BEGIN_EVENT`s in [RCTBridgeModuleDecorator attachInteropAPIsToModule] because people don't override the set methods for the 4 synthesize ivars, so setting each ivar should be instant.
Reviewed By: RSNara
Differential Revision: D34438180
fbshipit-source-id: 871ac4cadd7a36821dac1274f0645c19d63943fc
Summary:
Changelog: [iOS][Internal] Refactor CxxBridge: Introduce RCTBridgeModuleDecorator to attach synthesize ivars to RCTTurboModules, in Bridge mode
This doesn't change any logic. RCTBridgeModuleDecorator was created to consolidate several nearly identical implementations of the `attachInteropAPIsToModule` method to one place.
Most importantly, it allows us to attach interop APIs in RCTBridgeModuleDecorator to RCTViewManagers in diff 4/4, using `attachInteropAPIsToModule`. Before this stack, these four synthesize ivars in RCTViewManagers are nil in Bridgeless mode, and point to instances in Bridge mode.
# Context
These are used in RCTBridgeModules to access APIs for view managers. These APIs are necessary and compatible with Bridgeless mode.
* synthesize viewRegistry_DEPRECATED
* synthesize bundleManager
* synthesize callableJSModules
* synthesize moduleRegistry
Reviewed By: RSNara
Differential Revision: D34437802
fbshipit-source-id: b773d511cf877d4896436fabf4893c978e5f8dd9
Summary:
Changelog: [Internal]
In the new architecture, when an interop component is being called, log instead of warn/error, since at the moment we expect this to happen often.
Reviewed By: fkgozali
Differential Revision: D34252666
fbshipit-source-id: 971156a1cd9ef9b788f677c49fa2c55bd86ad4fa
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:
Changelog: [Internal]
# Diff Changes
- Set `RCTEnableNewArchitectureViolationReporting` to YES in app-wide Bridgeless mode.
- Rename `RCTWarnNotAllowedForNewArchitecture` to `RCTErrorNotAllowedForNewArchitecture`, and use `RCTLogError` instead of `RCTLogWarn` so the error goes to Logview.
Reviewed By: RSNara
Differential Revision: D34202682
fbshipit-source-id: 471486c65f7a42f8f11140e61ff60592dc826f61
Pieter De Baets
Luna Wei
Christoph Purrer
Paige Sun
Samuel Susla
Tommy Nguyen
Lulu Wu
Vincent Riemer
Kudo Chien
Gabriel Donadel Dall'Agnol
Vojtech Novak
Thuong Tran
Riccardo Cipolleschi
Nick Gerleman
Chiara Mooney
Michael Sokolnicki
Robbie Coomber
Tony Du
Eric Edouard
Graham Mendick
Ruslan Latypov
Pieter De Baets
Dusan Klinec
lbaldy
Joshua Gross
Luis Santana
Ramanpreet Nara
CodemodService FBSourceClangFormatLinterBot
Olivier Payen
Dmitry Rykun
luoxuhai
Arinjay Sharma
Rubén Norte
Vlad Hnatiuk
Ken Tominaga
fortmarek
Nicola Corti
Oleksandr Melnykov
Gijs Weterings
Chaoshuai Lu
Richard Howell
Krzysztof Magiera
Ersan Kavafoglu
Rob Hogan
Phillip Pan
Lorenzo Sciandra
Chris Olszewski
Imran Shitta-Bey
Erich Graham
Danilo Bürger
Diego Pasquali
HeyImChris
Danilo Bürger
Amy Lee
Janic Duplessis
