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:
For every direct and bubbling event, RCTComponentData (iOS-only) creates a {eventName}: true entry in the component's ViewConfig validAttributes. This entry is unnecessary, and creates a discrepancy between ViewConfigs on iOS vs Android.
This diff removes this entry for all events to:
1. Reduce bloat in native ViewConfigs
2. Create consistency betweeen Android and iOS.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D33303950
fbshipit-source-id: 870c8a2a6d41156ac89bd8554eb09f292bb6108e
Summary: Changelog: [Internal] - Update the source of the changes in generated files, no longer bump-oss-version but set-rn-version
Reviewed By: sota000
Differential Revision: D33110408
fbshipit-source-id: 8cd5004f5d40dde82fe4d6271d5b8598cd27ca31
Summary:
`_labelsForTags` is an array with string labels used only for local profiling, that we had to manually keep it in sync with `RCTPLTag`. Refactor so labels are assigned with switch instead.
Changelog: [iOS] Refactor: Assign string label to each case in RCTPLTag enum for startup performance logging
Reviewed By: fkgozali
Differential Revision: D32889043
fbshipit-source-id: 81da592a160a31b91e78289be0990cc2ff960f29
Summary:
Changelog:
[iOS][Fixed] This is a quick speculative fix since we know `CFRunLoopPerformBlock` does not push/pop an autorelease pool.
Reviewed By: appden
Differential Revision: D32657298
fbshipit-source-id: 4641ad89baf7889ba4bf80e6e64e26de02818cb8
Summary:
as title
in practice, this doesn't make any difference, but this is to follow the apple recommendation and for us to have a more consistent codebase.
https://developer.apple.com/library/content/releasenotes/ObjectiveC/ModernizationObjC/AdoptingModernObjective-C/AdoptingModernObjective-C.html
>The NS_ENUM macro helps define both the name and type of the enumeration, in this case named UITableViewCellStyle of type NSInteger. The type for enumerations should be NSInteger.
>Like enumerations, the NS_OPTIONS macro defines both a name and a type. However, the type for options should usually be NSUInteger.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D32641990
fbshipit-source-id: 56e4cd44cdefe54f61c90844665a685ee2d6ffad
Summary:
a lot of unused code here, cleaning it up
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D32640185
fbshipit-source-id: 2917b4e3ea9c08ccb520250de509f0253d5dae61
Summary:
here's a way we can mock C apis - however i am not sure if the flag i'm using is correct
used in D31949237
Changelog:
[General][Added] - add macros to be able to stub C functions in tests
Reviewed By: RSNara
Differential Revision: D31949238
fbshipit-source-id: 0f18a65f810f1b855dbc844f11f5a304c1e5ecea
Summary:
i saw this a lot in the codebase, it's not optimal bc we're using two selectors when we only need one.
fastmod --extensions m,mm '\[\[(.*) alloc] init]' '[${1} new]' --dir xplat/js/react-native-github/*
i manually updated the callsites that this codemod couldn't handle (e.g., where there were more than one of these instances in a single line)
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D31776561
fbshipit-source-id: 1b16da240e8a79b54da67383d548921b82b05a9f
Summary:
Changelog: [Internal]
these are returning bools for some reason even though no one is using the returned value. changing them to return void
Reviewed By: RSNara
Differential Revision: D31594241
fbshipit-source-id: 04c115b573b74996eaf2fef631eedb12c6734ea8
Summary:
Changelog: [Internal]
in this diff, we add a function that allows us to retrieve screen scale. enforcing thread safety will be dependent on the consumer to make sure it's used on main thread.
i'd like for this to be a more temporary solution, i think we should have a more scalable screen solution for consumers to handle the gambit of uiscreen use cases.
Reviewed By: sammy-SC
Differential Revision: D31163909
fbshipit-source-id: 78104e9ef982b47c60697461141afb4b06eede72
Summary:
Changelog:
[iOS][changed] - fixed inaccurate comment
while looking around, i saw this comment for RCTScreenSize that says it's called on app start - i looked around and also put a breakpoint here, and this assumption doesn't seem accurate anymore. just updating the comment for clarity.
Reviewed By: sammy-SC
Differential Revision: D31136182
fbshipit-source-id: 5f02a1a9fd95e16495bb79b3645b5f4e3bc1d9c9
Summary:
This pull request aims to remove iOS 11 version check which is no longer needed.
The minimum iOS deployment target for React Native is `iOS 11` but we still have iOS 11 version check like below.
```
#if __IPHONE_OS_VERSION_MAX_ALLOWED >= 110000 /* __IPHONE_11_0 */
if (available(iOS 11.0, *)) {
```
> React Native apps may target iOS 11.0 and Android 5.0 (API 21) or newer.
ref: https://github.com/facebook/react-native#-requirements
------
If there is a team motivation to remove the deprecated methods and classes before iOS 10, I can continue the work in this pull request or in the continuing pull requests.
We have deprecated warnings for these in the project.
- `UIUserNotificationSettings`
- `UILocalNotification`
- `topLayoutGuide` and `bottomLayoutGuide`
- `automaticallyAdjustsScrollViewInsets`
## Changelog
[iOS] [Changed] - Remove iOS 11 version check
Pull Request resolved: https://github.com/facebook/react-native/pull/32151
Reviewed By: sammy-SC
Differential Revision: D30877917
Pulled By: yungsters
fbshipit-source-id: d903ea5d557beeb65ef87bfce572e4db3532b3c5
Summary:
`isPackagerRunning` check on iOS makes a http request to packager's /status endpoint to check if it's alive... The problem is if the packager can't be reached, but doesn't error out immediately. This can happen, for example, if running the app on device, and host computer's firewall doesn't allow a :8081 connection. In that case, the request will never succeed or fail until default timeout of 60s. It makes debugging the underlying issue quite unbearable. It's hard for me to imagine a legitimate packager connection that wouldn't respond in less than a second, so I propose a conservative timeout of 10s
## Changelog
[iOS] [Fixed] - Don't hang app for 60s if packager can't be reached
Pull Request resolved: https://github.com/facebook/react-native/pull/31367
Test Plan: Checked my app in dev mode to see if packager connects properly.
Reviewed By: sammy-SC
Differential Revision: D30912047
Pulled By: charlesbdudley
fbshipit-source-id: 110743dc45b9cc7d30e49f79ce3b0d5986f7aebd
Summary:
Changelog:
* Rename `ENABLE_PACKAGER_CONNECTION` macro to a more appropriate name `RCT_DEV_SETTINGS_ENABLE_PACKAGER_CONNECTION` to reflect this is only used in RCT_DEV_SETTINGS
* Introduce `RCT_PACKAGER_LOADING_FUNCTIONALITY` that can be separate from `RCT_DEV_MENU`, by default, it equals to `RCT_DEV_MENU`
Reviewed By: fkgozali
Differential Revision: D30546025
fbshipit-source-id: f409c02dc1486041d7db5abdbf7eb482520fa171
Summary:
This diff disables the TurboModuleManager delegate locking by default in the TurboModule system.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D30862260
fbshipit-source-id: 917c1e5862c69a753e33813705eead0e97cf5e9a
Summary:
## Context
In bridgeless mode, RCTRootView is actually an instance of RCTSurfaceHostingProxyRootView.
A lot of code that uses RCTRootView uses its RCTEventDispatcher or RCTModuleRegistry properties. Both of properties reach into the bridge, which means these APIs only work in bridge mode.
## Changes
- Give RCTSurfaceHostingProxyRootView access to the bridgeless RCTModuleRegistry, in bridgeless mode.
## Benefits
- This makes the RCTEventDispatcher and RCTModuleRegistry properties of RCTSurfaceHostingProxyRootView work in bridgeless mode. This allows us to eliminate branching in native code that uses these properties. Diffs incoming.
Changelog: [Internal]
Reviewed By: sshic
Differential Revision: D30753829
fbshipit-source-id: 0815f8ae5507686bd5aff20a3abc1843533bb132
Summary:
## Context
RCTModuleRegistry allows NativeModules to require other NativeModules, regardless of if they're using the old or the new system.
## Problems
Currently, the TurboModuleManager owns the RCTModuleRegistry. This results in the following ownership diagram:
{F660246242}
As you can see, for the bridge case, we're maintaining two *different* RCTModuleRegistry objects, both of which maintain a backward reference to the bridge and the TurboModuleManager.
## Changes
If we stop having TurboModuleManager own the RCTModuleRegistry, and just have React Native's initialization layer attach it to NativeModules, then we can simplify the above ownership diagram to this:
{F660246285}
## Benefits
- Less complicated design for RCTModuleRegistry
- RCTModuleRegistry understands the old and the new NativeModule system. So, it makes more sense for RCTModuleRegistry to be owned by the bridge, which also understands the old and the new NativeModule system.
- **Actual Motivation:** This allows us to start exporting RCTModuleRegistry from the bridgeless core, which is safer than leaking the TurboModuleManager from the bridgeless core. Diffs incoming.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D30753286
fbshipit-source-id: cf374092b7b939bc177c3c3448424f2fb53033c3
Summary:
RCTBaseViewController uses RCTRootView.bridge to call RCTViewEventEmitter.emit.
## Changes
- RCTEventDispatcher now exposes a method to dispatch RCTViewEventEmitter events.
- RCTRootView (for paper), and RCTSurfaceHostingProxyRootView (for fabric and bridgeless mode) now exports the RCTEventDispatcher by grabbing it from the bridge
- RCTBaseViewController now uses the event dispatcher exported from RCTRootView to dispatch the RCTViewEventEmitter event.
## Benefits
- RCTBaseViewController no longer uses the bridge to dispatch RCTViewEventEmitter events
- In the future, we'll make RCTSurfaceHostingProxyRootView work with bridgeless mode, which'll allow us to remove the bridge/bridgeless fork in RCTBaseViewController.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D30434884
fbshipit-source-id: d961a56ac2abc08a661f8fe7c37926f219b731d0
Summary:
RCTRootVeiw exports the bridge. One reason why is to allow users of RCTRootView users to access NativeModules.
## Changes
- RCTBridge now exports the RCTModuleRegistry
- RCTRootView now exports the RCTModuleRegistry exported by the bridge
- Users of RCTRootView use the RCTModuleRegistry exported by RCTRootView to access NativeModules
## Benefits
Down the line, we'll change how RCTRootView gets the RCTModuleRegistry (i.e: it won't use the bridge in bridgeless mode).
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D30434886
fbshipit-source-id: 875fce24d2fd9ee6350f128c8612e613e61e390e
Summary:
Users of RCTRootView access the bridge from it, to see if it's nil or not.
## Changes
- Instead of exposing the bridge from RCTRootView for this use-case, we're now exposing a property on RCTRootView: hasBridge. This will be false in bridgeless mode, and true in bridge mode.
## Benefits
This takes us one step closer towards removing RCTBridge leakage through RCTRootView.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D30434885
fbshipit-source-id: 02f50e16831852b5049a626e8b08d59a90b2059a
Summary:
Changelog: [internal]
There is a possibility of race between JavaScript sending "completeRoot" and maximum size set on surface. To prevent this race, we set the initial maximum size to be equal to the viewport size.
Alternative solution is to set maximumSize to {0, 0} initially instead of infinity. This is what old architecture does, even though not explicitly.
Reviewed By: fkgozali
Differential Revision: D30402207
fbshipit-source-id: 44427404eaf060a81de257797823edf971ffc1bb
Summary:
seperated -> separated
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Internal] [Fixed] - Fixed typo in comment
Pull Request resolved: https://github.com/facebook/react-native/pull/31067
Test Plan: NONE
Reviewed By: sammy-SC
Differential Revision: D30176244
Pulled By: sota000
fbshipit-source-id: 617607aaa7eb5f613344773c4bbbc09a8c5096c1
Summary:
Remove unused import
## 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] [performance] - Remove unused import
Pull Request resolved: https://github.com/facebook/react-native/pull/30544
Test Plan: Should build on CI
Reviewed By: lunaleaps
Differential Revision: D30000901
Pulled By: charlesbdudley
fbshipit-source-id: 3d3310917823b7af57564ca1ea397cd32cd0c4d5
Summary:
Fixes https://github.com/facebook/react-native/issues/31779
For more detailed explanation, see issue https://github.com/facebook/react-native/issues/31779
React Native touch handler events (onTouchStart, onTouchMoved, etc..) are intended to have "force" properties when used on devices which support pressure input (3D Touch & Apple Pencil events). However, due to a check in RCTForceTouchAvailable() function which checks for UITraitCollection's "forceTouchCapability" to be equal to UIForceTouchCapabilityAvailable, the check returns NO on iPad-based devices, due to iPad devices returning UIForceTouchCapabilityUnavailable at all times. This causes "force" values of Apple Pencils to never be passed on to React Native.
Since simply passing 0 as a value for force across the RN bridge for every touch event seemed like a change that might seem jarring to some, I decided that a simple additional boolean check if the touch event's type is UITouchTypePencil (this is the same as UITouchTypeStylus) should also suffice.
## 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] - Fixed "force" property of touch events for Apple Pencil/Stylus devices.
[iOS] [Feature] - Added "altitudeAngle" property to touch events from Apple Pencil/Stylus devices.
Pull Request resolved: https://github.com/facebook/react-native/pull/31780
Test Plan:
The code compiles and runs, and trying a simple handler for a View like
````
touchMove = (e: GestureResponderEvent) => {
console.log(`pressure, altitude (${e.nativeEvent.force}, ${e.nativeEvent.altitudeAngle})`);
````
results in
<img width="424" alt="Screen Shot 2564-06-28 at 17 13 22" src="https://user-images.githubusercontent.com/5000572/123621055-0b563f00-d835-11eb-9eff-526ba27fdf7b.png">
and when pencil is oriented perpendicular to the screen and pressed with full force shows
<img width="412" alt="Screen Shot 2564-06-28 at 17 13 58" src="https://user-images.githubusercontent.com/5000572/123621139-1c06b500-d835-11eb-8207-68a49720d708.png">
Reviewed By: sammy-SC
Differential Revision: D29964102
Pulled By: sota000
fbshipit-source-id: 5a1f41d64c6fe325afbd2b9579eaf20a522e92dc
Summary:
Changelog: [internal]
Fabric didn't have prop [removeClippedSubviews](https://reactnative.dev/docs/view#removeclippedsubviews) implemented. This diff adds it. It is
Reviewed By: JoshuaGross
Differential Revision: D29906458
fbshipit-source-id: 5851fa41d7facea9aab73ca131b4a0d23a2411ea
Summary:
Changelog: [internal]
Original commit changeset: fa4d8944ad6b
Not sending onScroll events events to Paper has no effect.
Reviewed By: mdvacca
Differential Revision: D29229662
fbshipit-source-id: b84a2614bfd42c64ca67ca6a1cd9d0a815c11ad0