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