Summary:
This change removes Content-Length header from proxy inspector response.
The presence of this header was resulting in the response being cropped under some circumstances because of erroneously calculated length.
The `Content-Length` header value represents the number of bytes in the response. In the code, `string.length` was used to calculate that value, but in JavaScript it gives the number of characters in a string instead of its size in bytes. Specifically, if there are some UTF characters in the string that occupy more than byte, there would be a mismatch in this size. This mismatch resulted in the response being cropped.
The easiest way to reproduce this problem is to set the simulator name to contain a two-byte UTF character.
This change works according to the HTTP spec, which states that when Content-Length is not present, the end of the response stream indicates the end of the response. Since in the code `response.end(data)` is use, it terminates the stream and hence there is no need to provide the length in the header.
## Changelog:
[GENERAL] [FIXED] - fix issue with debugger not working when device name contain two-byte UTF characters
Pull Request resolved: https://github.com/facebook/react-native/pull/42590
Test Plan:
1. Change your iOS simulator name to contain some two-byte UTF character (for example this one: "–")
2. Run metro and connect your app with it
3. Go to http://localhost:8081/json/list in your browser – see the response being marked invalid as it is cropped
4. Apply the change and see that the resulting JSON in the response is now correct
5. Open debugger workflow to confirm it sees the connected device
Reviewed By: robhogan
Differential Revision: D52958725
Pulled By: motiz88
fbshipit-source-id: 92c32893cbbf8552237585d824e4a44737fa3968
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42388
This was our last call site still using the legacy `dispatch` API.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D52906894
fbshipit-source-id: b1c838ee695ce4c60aaed409e7dc46a0dd3f6c2e
Summary:
Over in React Native macOS land, I opened https://github.com/microsoft/react-native-macos/pull/2030 to update our mono repo to use Yarn 4. As a side effect, all the `package.json` files are formatted as a side effect of running `yarn install`. So that React Native macOS doesn't maintain this diff (and because they should only be good / no harm), let's upstream the formatting changes.
## Changelog:
[INTERNAL] [CHANGED] - Format package.json files in the monorepo
Pull Request resolved: https://github.com/facebook/react-native/pull/42256
Test Plan: This change should be a no-op, CI should pass.
Reviewed By: cortinico
Differential Revision: D52727623
Pulled By: huntie
fbshipit-source-id: 67862b16d576b0903abd91e016d7add4c19853dc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42394
Changelog: [Internal][iOS] - Enable stub modern CDP backend in Bridge behind a feature flag
Minimally integrates the stub native CDP backend implementation (D50936932) into iOS Bridge.
This integration registers itself as a "Modern" target (D50967794, D50967795) to instruct `inspector-proxy` to disable its CDP hacks related to source map fetching, reloads, etc. This gives us a mostly-clean slate on which to develop and test native CDP functionality.
Reviewed By: huntie
Differential Revision: D50951138
fbshipit-source-id: 8c5ad9207e73265595884380c91e38f8d0ead84d
Summary:
Changelog: [Internal][iOS] - Enable stub modern CDP backend in Bridgeless behind a feature flag
Minimally integrates the stub native CDP backend implementation (D50936932) into iOS Bridgeless.
This integration registers itself as a "Modern" target (D50967794, D50967795) to instruct `inspector-proxy` to disable its CDP hacks related to source map fetching, reloads, etc. This gives us a mostly-clean slate on which to develop and test native CDP functionality.
Pull Request resolved: https://github.com/facebook/react-native/pull/42393
Test Plan:
1. `js1 run`
2. Enable the modern CDP backend by grafting D52844391
3. Enable Bridgeless in RNTester by grafting D52910646
4. `buck2 install rntester-ios`
5. Dev Menu -> Open Debugger
6. Observe console message self-identifying the backend + iOS Bridgeless
7. Observe that the debugger stays connected when the app is reloaded (albeit without doing anything very interesting just yet)
{F1329876835}
Reviewed By: huntie
Differential Revision: D50936931
Pulled By: motiz88
fbshipit-source-id: ff8f919d0370266aea2916da349520bc76d690ab
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42294
This changes enables the Fabric Intrerop Layer automatically for all the users.
Practically I'm removing the fallback `ComponentDescriptor` inside the `ComponentDescriptorRegistry` so that if a component hasn't been automatically registered by a user, instead of showing the UnimplementedView, it loads a `UnstableLegacyViewManagerAutomaticComponentDescriptor`.
This ComponentDescriptor is built starting from the legacy component name, and responds with correct `ComponentName` and `ComponentHandle` (similarly to the `UnstableLegacyViewManagerInteropComponentDescriptor` but without using C++ templates).
Changelog:
[Internal] [Changed] - Fabric Automatic Interop for Android
Reviewed By: sammy-SC
Differential Revision: D52663244
fbshipit-source-id: f466486c638bb1362ef59128cd69bb9731bb9739
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42402
Now that we have 2 top level directories for JS files in the `react-native` package, we need to choose where to put the native module and native component specs, because our current infra only supports a single directory.
The options we had are:
1. Keep specs in the current directory (`Libraries`). This is a problem because it encourages us to keep adding modules in this "deprecated" directory.
2. Move specs to the new `src` directory. This requires moving the current files, but from now only we can create new specs in a private directory.
3. Modify the infra to allow multiple directories. This changes the public API for something it's likely only going to be used here.
In this PR I went for option 2) because it's the most future-proof, even though it requires a little bit more work now. I created a script to automatically copy all the specs for modules and components to `src/private/specs/components` and `src/private/specs/modules`, and changed their current locations to serve as a proxy for the new location (to avoid breaking a potentially public API).
`src/private/specs` isn't meant to be their final location. We should probably still colocate native module/component specs with the rest of their code, but we can do so when we move the code from `Libraries` to `src/private`.
Changelog: [internal]
Reviewed By: cortinico
Differential Revision: D52919566
fbshipit-source-id: 6de8a2d2b6077e4f884386567721c6bd2b88a5d3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42386
The new DOM APIs are completely private at the moment, so they make them a good candidate to test the new directory structure (and make sure everything works correctly in CI, etc.). This moves those files to `src/private/dom`.
Changelog: [internal]
Reviewed By: huntie
Differential Revision: D52875998
fbshipit-source-id: c6c96eedcc54d47e3afff98fa2d912f9d83f3460
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42385
This adds support for having JS files in a `src` directory within the `react-native` package. The plan is to have 2 subdirectories there:
* `react-native/src/private` for private modules, with any nested directories (e.g.: `react-native/src/private/dom/nodes/ReadOnlyNode.js`).
* `react-native/src/public` for public modules, without nested directories. The plan is that the individual modules created in this directory will be public through the index module or directly via something like `react-native/View` (mapped to `react-native/src/public/View`, or a `dist` directory in the published npm package—details TBD).
The enforcement of private modules being inaccessible from outside the `react-native` package will be added soon by huntie.
Changelog: [internal]
Reviewed By: huntie
Differential Revision: D52875999
fbshipit-source-id: 914ed806f2cb86857e2cb7b760292c2190b5b14e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42585
Just a minor bump of AGP to 8.2.1
Changelog:
[Internal] [Changed] - Bump AGP to 8.2.1
Reviewed By: NickGerleman
Differential Revision: D52912324
fbshipit-source-id: 2856861f2ccedb3470a0fa548a31dd36252924c3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42131
X-link: https://github.com/facebook/yoga/pull/1534
Now that the storage method is a hidden implementation detail, this changes the underlying data structure used to store styles, from `CompactValue` (a customized 32-bit float with tag bits), to `StyleValuePool`.
This new structure operates on 16-bit handles, and a shared small buffer. The vast majority of real-world values can be stored directly in the handle, but we allow arbitrary 32 bit (and soon 64-bit) values to be stored, where the handle then becomes an index into the styles buffer.
This results in a real-world memory usage win, while also letting us store the 64-bit values we are wanting to use for math function support (compared to doubling the storage requirements).
This does seem to make style reads slower, which due to their heavy frequency, does have a performance impact observable by synthetics. In an example laying out a tree of 10,000 nodes, we originally read from `StyleValuePool` 2.4 million times.
This originally resulted in a ~10% regression, but when combined with the changes in the last diff, most style reads become simple bitwise operations on the handle, and we are actually 14% faster than before.
| | Before | After | Δ |
| `sizeof(yoga::Style)` | 208B | 144B | -64B/-31% |
| `sizeof(yoga::Node)` | 640B | 576B | -64B/-10% |
| `sizeof(YogaLayoutableShadowNode) ` | 920B | 856B | -64B/-7% |
| `sizeof(YogaLayoutableShadowNode) + sizeof(YogaStylableProps)` | 1296B | 1168B | -128B/-10% |
| `sizeof(ViewShadowNode)` | 920B | 856B | -64B/-7% |
| `sizeof(ViewShadowNode) + sizeof(ViewShadowNodeProps)` | 2000B | 1872B | -128B/-6% |
| "Huge nested layout" microbenchmark (M1 Ultra) | 11.5ms | 9.9ms | -1.6ms/-14% |
| Quest Store C++ heap usage (avg over 10 runs) | 86.2MB | 84.9MB | -1.3MB/-1.5% |
Reviewed By: joevilches
Differential Revision: D52223122
fbshipit-source-id: 990f4b7e991e8e22d198ce20f7da66d9c6ba637b
Summary:
A first step in my work on https://github.com/react-native-community/discussions-and-proposals/issues/695
De-duplicate the code for creating `Spannable` on Android. I'm planning to add quite serious new features to this module. This would be really hard with the current level of code duplication.
## Changelog:
[INTERNAL] [CHANGED] - De-duplicate building `Spannable` on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/39630
Test Plan: I tried to ensure that the refactored code is relatively easy to prove to be equivalent to the original duplicated one, but there's always a risk of a human mistake in this process. So far, I have been testing this by ensuring that nothing broke in the `Text` example section in RNTester.
Reviewed By: mdvacca
Differential Revision: D51016244
Pulled By: NickGerleman
fbshipit-source-id: e9f873c01b2af0685c7b0943aebea170c997d22e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42399
Mark CallInvokerHolder APIs as FrameworkAPI only, these APIs are meant to be used only for partner frameworks
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D52913739
fbshipit-source-id: 5a2c8be629e90a33e0cfb66b28e0171c71f5940d
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
Rubén Norte
Krzysztof Magiera
Pieter De Baets
Saad Najmi
Himanshi Goyal
LIM Albert
Moti Zilberman
Moti Zilberman
Nicola Corti
Erica Klein
Nick Gerleman
Jakub Trzebiatowski
David Vacca
szymonrybczak
Fabrizio Cucci
Oskar Kwaśniewski
Frieder Bluemle
Alex Hunt
Christoph Purrer
Samuel Susla
Eric Rozell
Joe Vilches
Pieter Vanderwerff