Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42387
Changelog: [Internal]
Documents that it's legal for a Page's connection function to return null, and adds new logic to `InspectorPackagerConnection` (NOTE: to the C++ implementation *only*) to handle this case without crashing.
The legacy RN CDP backend (`ConnectionDemux`) has a case similar to this that causes crashes depending on the timing of connection requests.
Reviewed By: cortinico
Differential Revision: D52905490
fbshipit-source-id: 2102adc859d1509647a31f92737a1e164781fadf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42384
Changelog: [Internal]
Similar to D52894171, adds a console log message identifying the specific CDP backend integration, based on an optional `SessionMetadata` object passed to `PageTarget::connect()`. This is helpful during development+rollout as we will have 4+ such call sites (iOS/Android, Bridge/Bridgeless).
Reviewed By: huntie
Differential Revision: D52905488
fbshipit-source-id: d26aae1d07c2c42965498a81f03d826de98fa222
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42383
Changelog: [Internal]
During development / experimental rollout of the modern CDP backend, it can be helpful to have a user-visible message that makes it clear that the new backend is in use. Here, we add one using the [`Log.entryAdded`](https://chromedevtools.github.io/devtools-protocol/tot/Log/#type-LogEntry) CDP event. We also add some styling using [ANSI escape sequences](https://developer.chrome.com/docs/devtools/console/format-style#style-ansi) to make the message stand out from normal application logs.
We could have used [`Runtime.consoleAPICalled`](https://chromedevtools.github.io/devtools-protocol/tot/Runtime/#event-consoleAPICalled) instead, but:
1. `Runtime.consoleAPICalled` requires an `executionContextId` which is not available at the `Page` level (it is a concept that's managed closer to the instance/VM), and it's slightly cleaner if we don't have to send a fake context ID.
2. It's slightly easier to follow the CDP dispatching logic / grep for relevant code if we use `Log` for "system logs" (from the Page) and reserve `Runtime` for real application logs from the instance/VM.
NOTE: We'll probably want to remove this before the stable release.
Reviewed By: huntie
Differential Revision: D52894171
fbshipit-source-id: 3208e01f2ee31acef2e8cd58767f40ad724c9a39
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42397
Changelog: [Internal]
Adds a stub `PageTarget` class to serve as the entry point to the modern CDP backend in React Native.
The primary method exposed by `PageTarget` is `connect()` which is designed to fit directly as a connection callback passed to `InspectorPackagerConnection::addPage()`. This constructs a `PageTargetSession` containing a `PageAgent` where the actual CDP message handling/routing will occur. For now, `PageAgent` implements no CDP methods, and always responds with a "not implemented" error.
Basic unit tests are included, though we might want to migrate to a more integration-style test suite (with fewer mocks and real bindings to RN) once we've implemented more of the protocol.
## What is a Page
In Chrome's implementation of CDP, a Page represents a single browser tab. A Chrome DevTools session connects to one Page at a time (though it can potentially inspect multiple JavaScript contexts owned by that Page, such as those found in frames and workers).
In our system, a Page will correspond 1:1 to React Native's concept of a *Host* (implemented as `RCTHost`, `RCTBridge`, `ReactHostImpl` or `ReactInstanceManager`, depending on the platform). In all cases, the Host is the object that has a stable identity across reloads, and manages the lifetime of an *Instance* where the JSVM and other application state lives. There can be multiple Hosts in a React Native process, though this is somewhat unusual; those would be treated as independent "tabs" from the perspective of the debugger.
NOTE: The concepts of Target, Session and Agent are new (to this codebase) and are *broadly* inspired by the [corresponding Chromium / V8 concepts](https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/public/devtools_protocol/#Agents_Targets-and-Sessions), though some details differ.
## Next steps
Each core platform implementation in React Native (iOS Bridgeless, iOS Bridge, Android Bridgeless, Android Bridge), as well as out-of-tree platforms that want to support the new debugger, will need to create and register a `PageTarget` instance. We'll do this piecemeal in subsequent diffs.
We'll also gradually add APIs and logic to `PageTarget` / `PageAgent` to allow us to implement some "interesting" CDP methods - some of them directly (e.g. handling reload commands) and others by dispatching to nested agents (e.g. a JS debugging agent powered by Hermes).
Reviewed By: huntie
Differential Revision: D50936932
fbshipit-source-id: ebe5856d7badb361d4971dd9aabeb9982f8aed1b
Summary:
Recently inside React Native Community CLI we added bumping Yarn version inside `init` command, more information here: https://github.com/react-native-community/cli/pull/2134. In this Pull Request I added required rules in `.gitignore` for new projects created.
## Changelog:
[GENERAL] [ADDED] - Add Yarn files to `.gitignore` in template
Pull Request resolved: https://github.com/facebook/react-native/pull/42313
Test Plan:
1. Follow [Contributing guide](https://github.com/react-native-community/cli/blob/main/CONTRIBUTING.md) from React Native Community CLI repository to setup locally newest version of CLI.
2. Run this command:
```sh
node /path/to/react-native-cli/packages/cli/build/bin.js init --template path/to/template
```
3. Appropriate should be ignored.
Reviewed By: NickGerleman
Differential Revision: D52907962
Pulled By: cortinico
fbshipit-source-id: f12dce8836e7e94257f8c690434b11227aa46446
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42254
X-link: https://github.com/facebook/yoga/pull/1550
This change aims to simplify how we resolve edges. This operation happens many, many times, and has gotten complex and slow when paired with StyleValuePool.
This starts reshaping so that `yoga::Style` can resolve a style prop for a given edge. This is closer to the ideal computed style API to avoid recalcing this so many times, but doesn't address that.
This relies on removing the errata related to row-reverse, and cleans up the removal started in the last change.
This has no measurable perf effect under CompactValue, but has a >10% uplift in perf when using StyleValueHandle, where we can trivially check if a handle points to a defined value without resolving it, but only within `yoga::Style` since we don't expose the handle outside of it.
More quantifiably, we go from 2.35 million StyleValuePool reads to 993k. The rest are checks on the handle.
Reviewed By: joevilches
Differential Revision: D52605596
fbshipit-source-id: 0b366963a899e376f99ce3d75cd5f14a25d60cec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42314
X-link: https://github.com/facebook/yoga/pull/1555
The next diff moves a bunch of methods to `yoga::Style`. This renames the function to be a tad bit shorter, for more readable callsites. It also makes it more consistent with style property getters.
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D52803393
fbshipit-source-id: 557df34a9f0fb0ee42ad23b1fda99c1e0eb1d4e3
Summary:
This removes the 4 ineffective and redundant entries from the `exclude` list in `tsconfig.json` (`typescript-config` package).
These entries have no effect as they are relative to the typescript-config package. Explained in detail here: https://github.com/tsconfig/bases/issues/207
A newly generated RN app shows this config:
```
$ yarn tsc --showConfig | grep -A 5 exclude
"exclude": [
"node_modules/tsconfig/react-native/node_modules",
"node_modules/tsconfig/react-native/babel.config.js",
"node_modules/tsconfig/react-native/metro.config.js",
"node_modules/tsconfig/react-native/jest.config.js"
]
```
Clearly, none of these files exist, therefore to remove ambiguity and reduce the complexity of the config, they should be removed.
## Changelog:
[GENERAL] [REMOVED] - Remove ineffective excludes from typescript-config
Pull Request resolved: https://github.com/facebook/react-native/pull/42375
Test Plan:
- Create new RN app (`npx react-native init`), install dependencies, run `yarn tsc`
- It works
- Recreate config, but _without_ the `exclude` section
- Everything works exactly the same
Reviewed By: huntie
Differential Revision: D52904713
Pulled By: NickGerleman
fbshipit-source-id: d1d6f65b164053f9a1e611022178ced032a38aef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42390
Changelog: [Internal]
Add an optional mechanism for inspector pages to be registered with the "modern" or "legacy" type (defaulting to legacy). This is aligned with the inspector-proxy implementation of the `type` property in D50967795.
NOTE: This mechanism is experimental, only takes effect if `InspectorPackagerConnection.cpp` is in use, and will likely evolve before the RN 0.74 branch cut.
Reviewed By: huntie
Differential Revision: D50967794
fbshipit-source-id: e7521267dfc0b0811c4d369e63f4f1756ce22d60
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42380
Changelog: [Internal]
Makes it explicitly legal to call `IRemoteConnection`'s methods from any thread when used as part of the C++ implementation of `InspectorPackagerConnection`.
Implementation details:
* This relies on `InspectorPackagerConnectionDelegate::scheduleCallback` being thread-safe and handling any necessary synchronisation (which is already required for the existing `reconnect()` use case).
* We add *very basic* tracking of *sessions* within `InspectorPackagerConnection` to make sure events don't leak from one `RemoteConnection` instance to the next.
* In the future we'll want to build on this to properly allow multiple concurrent sessions to a single page. That's not the primary goal here though.
Reviewed By: rubennorte
Differential Revision: D52807388
fbshipit-source-id: 6900386a1f047c99f15dc91597f308c82adf5281
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42362
This undos a change of CallInvokerHolder bringing it back in the public package: https://github.com/facebook/react-native/commit/b7191cde4e36
The problem is that if a developer wants to use the C++ CallInvokerHolder to schedule work on the JS thread from C++, they're forced to import the `.internal`
Java/Kotlin class.
Plus this is going to be a massive breaking change for the ecosystem:
https://github.com/search?type=code&q=%2Fimport.*CallInvokerHolderImpl%2F
So unless we come with a clear deprecation/replacement path, I'm undoing this change for now.
Changelog:
[Internal] [Changed] - Undo move of CallInvokerHolder to `.internal`
Reviewed By: cipolleschi
Differential Revision: D52873256
fbshipit-source-id: 900c3170ed2100ec706b03112bc23a0ba0171bcc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42358
Just converting those two classes to Kotlin as I was going over them.
Changelog:
[Internal] [Changed] - Convert InteropEvent and InteropEventEmitter to Kotlin
Reviewed By: javache
Differential Revision: D52869490
fbshipit-source-id: 2d585dd3d21dc89c5e55de645e9519d36f67b849
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42360
In cases where you merge out-of-tree platforms like react-native-windows with react-native mobile JS files, codegen awareness of the Windows suffix is useful. This helps prevent the creation of generated code for iOS and Android in mixed out-of-tree platform folders.
## Changelog
[Internal]
Reviewed By: mdvacca
Differential Revision: D52873212
fbshipit-source-id: ad6b1471e63d68057f54c79141123fb15f8aab5e
Summary:
X-link: https://github.com/facebook/yoga/pull/1558
Pull Request resolved: https://github.com/facebook/react-native/pull/42318
AbsolutePositioning -> AbsolutePositioningCatchAll
A bit more clear. This errata is for various issues with positioning absolute nodes. There really isn't a clear description as to what specifically this enables/disables, so I just opted to say "catch all" to indicate that this controls various bugs
Reviewed By: NickGerleman
Differential Revision: D52820117
fbshipit-source-id: 80b77832baf65e68e57ca523c418422dd346ef0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42317
Added a complicated zIndex test and corresponding screenshot test for it.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D52439963
fbshipit-source-id: 54bc8cfc9aa2e3c985279fe43027b3db88057c68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42316
We need to change the typing to allow for 'static'. An issue here is that Paper will not have `static` due to missing z-index logic. Unfortunately, we cannot create a fabric-only version of the typing as we cannot have conditional elements of the same name in ts. To remedy this we took out the parsing of the string 'static' in Paper. Instead we will just emit a warning and default to `relative`.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D51431524
fbshipit-source-id: 0444b2f8432f172b2e8a084b307b0e624dba8085
Summary:
X-link: https://github.com/facebook/yoga/pull/1556
Pull Request resolved: https://github.com/facebook/react-native/pull/42315
Since we aim to ship static to all users of yoga (not just XPR), we need to remove the errata that is gating most of the features. This should be a non breaking change. To ensure that, I added a new errata which, if on, will use the inner size of the containing node as the containing block. This is how it has been for a while and resolving this is risky and time consuming so for the time being we will stick with that.
Reviewed By: NickGerleman
Differential Revision: D52706161
fbshipit-source-id: 30a93f29cb0d97b20b2947eaa21f36cdc78c4961
Summary:
X-link: https://github.com/facebook/yoga/pull/1549
Pull Request resolved: https://github.com/facebook/react-native/pull/42253
This experimental feature is always false, and with the next diff I will be deleting the branch that actually calls into this. Separating this diff out to simplify the review process.
Reviewed By: NickGerleman
Differential Revision: D52705765
fbshipit-source-id: 705f4aa297eae730af9b44753eb01c9dec385dcf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42308
Changelog: [Internal]
Guarantees cleanup of `ILocalConnection` when the associated page is unregistered from `IInspector`.
NOTE: This only applies to the C++ version of `InspectorPackagerConnection`. The legacy pure-Java and pure-ObjC implementations are of this class are unchanged.
In the upcoming modern CDP backend architecture, this will help guarantee the validity of Target references (specifically PageTarget) held by Agents (specifically PageAgent), without introducing unnecessary shared ownership and dynamism.
Reviewed By: hoxyq
Differential Revision: D52786331
fbshipit-source-id: 162425d6435246a95ac9c076bc5c59a34f331f16
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42304
Changelog: [Internal]
Light refactor of `InspectorImpl`'s storage from two separate maps (one of them with tuples for values!) to a single map of objects.
Reviewed By: hoxyq
Differential Revision: D52786335
fbshipit-source-id: a49466ed7189fd032e486319bbdf77097a30885f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42301
Changelog: [Internal]
To simplify testing and rolling out the modern CDP backend in React Native, let's require the use of the C++ version of `InspectorPackagerConnection` whenever the modern CDP backend is in use, regardless of the `InspectorPackagerConnection` rollout setting.
Reviewed By: hoxyq
Differential Revision: D52786334
fbshipit-source-id: 5c12794e3faa2c094a23f69a5677f66905d1763e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42355
`RemoveDeleteTreeUIFrameCallback` operated directly on the view to clean up its children, which does not correctly account for subviews which have been clipped because they're outside the visible frame.
Changelog: [Android][Added] Added `removeAllViews` to IViewGroupManager.
Reviewed By: jehartzog, sammy-SC
Differential Revision: D52834835
fbshipit-source-id: fb7f07a17d07467eecd3ce9721afc2f3abcc0caa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42302
Changelog: [Internal][Added] Support launching experimental debugger frontend for CDP targets marked as "modern"
See the definition of "modern" targets in D50967795.
Reviewed By: hoxyq
Differential Revision: D52786332
fbshipit-source-id: 13718e9ddf3ec050049ef7ec9a77f6cf1a7f82ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42303
Changelog: [Internal]
Adds a coarse-grained mechanism to `inspector-proxy` for distinguishing between legacy and modern debug targets. The guiding principles are:
1. `inspector-proxy` does not interfere in the CDP message stream between the debugger frontend and a modern target, or in the lifecycle of a target.
2. Legacy runtimes (current React Native, React Native Desktop, etc) that rely on `inspector-proxy`'s existing invasive semantics must continue to work seamlessly for now. We'll decide on the right time to deprecate/remove this legacy code in the future.
NOTE: This is an experimental addition to the proxy protocol that may be replaced at any time.
Reviewed By: hoxyq
Differential Revision: D50967795
fbshipit-source-id: bb9c39a8fe755ef3661e2c61507dd324d8dc8894
Summary:
Added `--custom-resolver-options` to `--bundle` command. This options is also [available](https://github.com/facebook/metro/blob/main/docs/CLI.md#options) in Metro's CLI.
## Changelog:
[INTERNAL] [ADDED] - Add `--resolver-options` to `bundle` command
Pull Request resolved: https://github.com/facebook/react-native/pull/42333
Test Plan:
1. Build all packages by running `yarn build` in the root
2. Go to `packages/rn-tester` and run `npx react-native bundle --custom-resolver-options key=value` and the options should be passed to the Config.
Reviewed By: blakef
Differential Revision: D52869452
Pulled By: huntie
fbshipit-source-id: 9a2c2d94b72cfb47477cf58b9c0472c5a8551c84
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42282
Changelog: [Internal] `inspector-proxy` now assumes each app will report pages with locally unique IDs.
In order to simplify some upcoming logic changes in `inspector-proxy`, in this diff we begin to enforce the assumption that each app ( = platform-specific implementation of `InspectorPackagerConnection`) assigns a locally unique ID to each inspector page. The inspector proxy will silently drop page descriptors that have conflicting IDs, and log a message to `debug()`.
NOTE: As an implementation detail, integrators may use `DEBUG=Metro:InspectorProxy` to see debug messages from `inspector-proxy`.
Reviewed By: huntie
Differential Revision: D50969752
fbshipit-source-id: a4e6faa91d97594fc5343ce4bee66233523cd175
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42271
Changelog: [Internal]
Adds a util function to determine the `TurboModuleMethodValueKind` based on the `jsi:Value` type
Reviewed By: javache
Differential Revision: D52761045
fbshipit-source-id: de937cda67198aad962e63f41ccd42be6c00c0b8
Summary:
`UIMenuController` is deprecated as of iOS 16. https://github.com/facebook/react-native/commit/e08a1973f67d85acc157111c749c43572469e4c2 migrated a usage into an `available` check. However, it does not properly fall back to the deprecated API in the "else" block of the availability check, instead it uses an early return. It seems this means Xcode still sees the API as used, and spits out a deprecated warning. Let's just refactor the code so we don't have that anymore.
## Changelog:
[IOS] [FIXED] - Remove an early return to suppress a deprecated API warning for `UIMenuController`
Pull Request resolved: https://github.com/facebook/react-native/pull/42277
Test Plan: CI should pass.
Reviewed By: cipolleschi
Differential Revision: D52785488
Pulled By: sammy-SC
fbshipit-source-id: 0b47e8aa8d7c94728e3d68332fbb8f97f8ded34e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42328
This method was deprecated in 0.72. We're going to remove it in 0.74
Technically a breaking change, but users should not be using this method at all at this point.
Changelog:
[Android] [Removed] - Remove deprecated DefaultNewArchitectureEntryPoint.load overload
Reviewed By: mdvacca
Differential Revision: D52802644
fbshipit-source-id: f7c1db783959d93b81407847377f805d7ee2602d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42329
As the title says, this checks against illegal configurations of ReactFeatureFlags in DefaultNewArchitectureEntrypoint
and let the app crash if the user specified and illegal configuration
Changelog:
[Internal] [Changed] - Prevent illegal configurations of ReactFeatureFlags in DefaultNewArchitectureEntrypoint
Reviewed By: mdvacca
Differential Revision: D52802609
fbshipit-source-id: 7bc0a08c17430d7fd2448f65838ce47fad738883
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42327
This diff is the result of running
`buck2 run //xplat/js/scripts/rn-api:generate-rn-api-metadata`
After this lands, `react-native-android-breaking-change-detector` will actually be green again, after the previous diff fixed the infra setup.
Changelog: [General][Fix] Update stale ReactAndroid.api values after CI breakage
Reviewed By: cortinico, mdvacca
Differential Revision: D52800160
fbshipit-source-id: b96533baa1cb704ad43482d7a52db50e6dce9821
Summary:
This PR introduces the `vision` interfaceIdiom to check if the app runs on visionOS.
An update to the documentation should follow this change.
## Changelog:
[IOS] [ADDED] - Introduce `vision` interfaceIdiom
Pull Request resolved: https://github.com/facebook/react-native/pull/42243
Test Plan: This change has been used in `react-native-visionos` and the interfaceIdiom changes **only** when running in the non-compatibility mode. But it's still useful to have this upstream if at some point React native would compile to visionOS natively
Reviewed By: cortinico
Differential Revision: D52730028
Pulled By: cipolleschi
fbshipit-source-id: 711c5c2c6c7fe05b3ff8da7383b5e63e9e04acfa
Summary:
X-link: https://github.com/facebook/yoga/pull/1553
Pull Request resolved: https://github.com/facebook/react-native/pull/42274
Separate from `YGConfigSetPrintTreeFlag` we have a public API `YGNodeSetPrintFunc` which sets a function called, if you manually change a constant in source code during debugging.
This is not debug-only, is exposed as part of the public API (without a way to turn it on from the public API), and takes up a pointer per node doing nothing.
I'm not aware of anyone recently using the capability, and the tracing/event related work done since then would be more powerful for this anyway.
Remove the API.
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D52767445
fbshipit-source-id: f72927b47cffa4fe6fe886b42f07cc1ba55f141e
Summary:
1. Modal onDismiss is not working on iOS (Fabric).
2. Modal onDismiss is currently only available on iOS. On Android, we don't have a way to know when exactly a modal is dismissed.
Currently, the onDismiss is emitted using a device event as a workaround to the RCTModalHostView unable to receive the component event as it's already unmounted when visible is false.
This PR removes the workaround and keeps RCTModalHostView mounted until the onDismiss event is emitted from the host and sends the onDismiss event on Android.
bypass-github-export-checks
## Changelog:
[ANDROID] [ADDED] - Added support for Modal onDismiss prop
[IOS] [FIXED] - Fix onDismiss is not working on Fabric
[General][Breaking] - The public API of Modal has changed. We don't have anymore a NativeModalManger turbomodule; RCTModalHostViewNtiveComponent's Prop does not require to pass an identifier anymore.
Pull Request resolved: https://github.com/facebook/react-native/pull/42014
Test Plan:
1. Run rn-tester
2. Open the Modal example
3. The second example shows the counter for the show and dismiss count
4. Show and dismiss the modal and verify the count is incremented correctly
https://github.com/facebook/react-native/assets/50919443/108bfb26-c8f6-43b2-ac40-f0b46e48771b
Reviewed By: javache, sammy-SC
Differential Revision: D52445670
Pulled By: cipolleschi
fbshipit-source-id: f419164032c3bef67387200778b274299bf0659f
