Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53334
Adds background performance tracing options to the DevMenu based on the current background tracing state. Analyzing a trace will automatically open dev tools, navigate to the performance tab, and show the last 20 seconds of recorded performance data.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D79714164
fbshipit-source-id: 72ad4be4604c5f4e304b49877b2699be36562655
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53508
Simplify the expressions for checking a type of a container by always returning instead of falling through and returning.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D81230049
fbshipit-source-id: 02fd827462c9acf05a83bf88ed6bd0e6db55ebc8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53507
We need this to be an unsigned value everywhere but all the API's and interfaces described this a signed number. While this doesn't make a difference in practice, it's better to explicit.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D81230050
fbshipit-source-id: 1eb914a79b9b94654cfa54c20a81ce689f79dcb9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53490
Changelog: [Internal]
Sending individual image prefetch request on Android over JNI is causing measurable performance regression. The idea here is batch all image prefetch request for a given shadowNodeTree and then flush it all at once - **DONE** in the next change.
Another optimization we should consider is to execute the batch on `n imagePrefetchRequest` off the JavaScript thread `mqt_v_js` and instead on e.g. the UiThread (on which currently Android Image UI initiates image resource downloads)
Reviewed By: lenaic
Differential Revision: D81186916
fbshipit-source-id: f8b24e70f2ded237be96bdb973b72acbbb8b1c20
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52910
For `get/has/setProperty`, we should also be able to take in a generic
JS Value as the property key. This change adds the Value overload for
these APIs.
The default implementation will use `Reflect.get`, `Reflect.has`, and
`Reflect.set`.
Changelog: [Internal]
Reviewed By: lavenzg
Differential Revision: D79120823
fbshipit-source-id: 7e2e5ff1ca93397c549e7dd922797fe77aa97940
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53513
D62853299 introduced the `defaultValue` argument to feature flag override functions, with the intent of enabling override functions to do something like this:
```
myFeatureFlag: (defaultValueForFlag) => someCondition ? value : defaultValueForFlag
```
However, there are no current use cases for this. This particular use case can also be solved by expanding support for override functions to return `null` or `undefined` which falls back to using the default value.
Furthermore, the type system has a difficult time representing the constraints when there are non-boolean JavaScript-only overrides (which was introduced recently).
This diff removes the argument and adds support for override functions to return `null` or `undefined`.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D81163557
fbshipit-source-id: 38876c83d51d857dbea889928248410041c5d6d7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53519
Changelog: [Internal] - Remove empty checks on the target rects and early return for empty ScrollView rects -- aligning the implementation with v1 of VirtualView
Reviewed By: yungsters
Differential Revision: D81247994
fbshipit-source-id: 4fda9f90e18d736944fe4236a4b79f0681e1564c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53518
Changelog: [Internal] - Listen to `onSizeChanged` for VirtualViewExperimental and VirtualViewContainer (ScrollView) and add more debug logs and format the virtualViewID consistently for easier grepping
Reviewed By: yungsters
Differential Revision: D81184013
fbshipit-source-id: a4314ab0f94a87e97a7d9b74696726803525c698
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53512
Noticed a lint for this so decided to change
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D81159958
fbshipit-source-id: c0b4b73055de26ea089e3cdb4edb7f073bd751d5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53502
Follows D81138169.
- This simplifies the total changes needed on implementing DevSupport classes.
- Widen outer API to accept any `String` panel name (futureproofing).
- Also add a complete set of supported values `DebuggerFrontendPanelName`.
Changelog:
[Android][Changed] - DevSupport `openDebugger()` methods now accept a `panel: String?` param. Frameworks directly implementing `DevSupportManager` will need to adjust call signatures.
Reviewed By: hoxyq, cortinico
Differential Revision: D81227870
fbshipit-source-id: 57b73703557971332e05076fb4ccac218079652a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53455
All these components have fabric replacements.
Let's deprecate them, so we can remove them eventually.
Changelog: [iOS][Deprecated] Deprecate all the legacy core components that have replacement implementations in fabric.
Reviewed By: cipolleschi
Differential Revision: D80973216
fbshipit-source-id: 2b20da0800f099244b4813abf9d8af175627a445
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53453
Let's deprecate all the classes that aren't used by interop, or the new architecture.
Changelog: [iOS][Deprecated] Deprecate all the objc classes not used by interop, or the new architecture.
Reviewed By: javache
Differential Revision: D80575768
fbshipit-source-id: ad12e4b639c21d608636eedbc7cd502fa9d7f461
Summary:
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/53489
For error
```
Identity-sensitive operation on an instance of value type 'Int?' may cause unexpected behavior or errors.
```
due to https://youtrack.jetbrains.com/issue/KT-78352/
Reviewed By: cortinico
Differential Revision: D81174630
fbshipit-source-id: c68e3a348e75b7bceb183b77a45b2729f1e70bcd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53510
Changelog: [Internal]
Electron imposes a [strange undocumented limitation](https://github.com/electron/electron/pull/13039) on the format of command-line arguments, which for some reason only affects Windows. Basically, the command line is truncated after the first argument that looks like a URL.
Electron's recommendation for avoiding this is to prefix the argument list with `--`, but I prefer switching to a different arg format (`--x=y` instead of `--x y`) that will prevent us from ever running into this issue.
NOTE: I will follow up with a diff to harden arg parsing in our Electron code so that it only accepts the `--x=y` format.
Reviewed By: huntie
Differential Revision: D81237713
fbshipit-source-id: a255dc63b6486b96d9f7ccf780d1b09bc4ddf7e0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53504
Casting directly from double to int loses precision. Instead, match the (accidental) behaviour of the folly version, which always access the value as an int64_t first.
```
double value = 4294967040
(int)value = 2147483647 (overflow)
(int)(int64_t)value = -256 (signed version of 4294967040)
```
Changelog: [General][Fixed] Casting rawValue to int was incorrectly truncating
Reviewed By: zeyap, sammy-SC
Differential Revision: D81228983
fbshipit-source-id: d68d4e63d7c7bc9a9226592756a1e53666d58978
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52672
This was used internally to work around some limitations of the bridge lifecycle. Given that we now have C++ TurboModules which are much more versatile, let's remove unnecessary concepts externally, as we move towards deprecating legacy C++ modules entirely.
Changelog: [General][Breaking] Removed CxxSharedModuleWrapper
Reviewed By: rshest
Differential Revision: D78484221
fbshipit-source-id: 95ed46b597dac55d823b70abe196264ce5b326ab
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53488
Creates a new feature flag to experiment with `Activity` in `VirtualView`.
The feature flag enables the following treatments:
- `no-activity` is the same as what we currently do — no `Activity` and we render `null` for hidden elements.
- `activity-without-mode` wraps the children in `Activity` but does not set `mode` and still renders `null` for hidden elements.
- `activity-with-hidden-mode` wraps the children in `Activity` and sets `mode="hidden"` and continues providing `children` (not `null`) for hidden elements.
Changelog:
[Internal]
Reviewed By: rickhanlonii
Differential Revision: D81149561
fbshipit-source-id: ea2c319139962de30836d80a2492d8147cbe82ba
Summary:
On iOS, if the default locale is not supported in the app, it will fall back to the first available locale to decide if RTL layout should be enabled or not; however on Android, we use the default locale. So if the first locale is a RTL locale and not supported by the app on Android, the app will fall back to the first available locale which might not be RTL, but the layout would be decided as RTL according to the default locale.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID] [FIXED] - use the first available locale instead of the default one to decide `isDevicePreferredLanguageRTL`
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID] [FIXED] - use the first available locale instead of the default one to decide `isDevicePreferredLanguageRTL`
Pull Request resolved: https://github.com/facebook/react-native/pull/53417
Test Plan:
I set my phone's locale to this order: Hebrew, English and enabled RTL layout:
```
import { I18nManager } from 'react-native';
I18nManager.allowRTL(true);
I18nManager.swapLeftAndRightInRTL(true);
```
Prior to my PR, the app would use RTL layout with English on Android which doesn't make much sense (iOS is LTR + English). With my PR Android app will behave exactly the same as the iOS app.
Reviewed By: rshest
Differential Revision: D80821903
Pulled By: zeyap
fbshipit-source-id: c1bd9b45341c344833a8fdfacc2c786ee8437415
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53480
Changelog: [Internal]
Improves the way `--version` and the User-Agent header work in `debugger-shell`.
* The same app name and version string format will be used across the `dev` and `prebuilt` flavours. Previously, `dev` would report itself as being `Electron v37.2.6` while `prebuilt` would report `react-native/debugger-shell v0.82.0-main`.
* `prebuilt` now also reports the original Meta-internal commit hash as a suffix `-rFBS..........` added to the semver string taken from `package.json`, while `dev` will have a `-dev` suffix in the same place.
* We do **not** modify the version in `package.json` during the build, nor do we pass the commit hash to `electron/packager`, because this would impose inconvenient platform-specific restrictions on the version string's format.
Reviewed By: huntie
Differential Revision: D81120181
fbshipit-source-id: e730dd35da78dfbb8de326f9a3ab76b747fdb0b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53481
Small fix to this RNTester example to clean up hanging `setInterval` side effect making repeat network fetches.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D81127809
fbshipit-source-id: 6036dd254888eb6160d2b1e116bbce63e5fd9328
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53368
This change introduces deprecation messages for several APIs used by the legacy arch in the RCTAppDelegate Library
## Changelog:
[iOS][Added] - Add deprecation message for RCTAppdelegate APIs
Reviewed By: cortinico
Differential Revision: D80618102
fbshipit-source-id: db77f8602a521557ed26822f27d54c6fc70c49bf
Summary:
To be able to handle cocoapods USE_FRAMEWORKS with both dynamic/static linkage and precompiled we needed a common way to resolve this.
The issue was that when using precompiled and USE_FRAMEWORKS our precompiled framework caused the resulting Pods project to only include header files - hence there where no need to change the header_mappings_dir which a lot of the podspecs did.
When using precompiled and building with frameworks (USE_FRAMEWORKS) we need to explicitly add the correct path to ReactCodegen when calling `create_header_search_path_for_frameworks` to ensure libraries can access their codegen files.
- Added method that handles this in a generic way
- Replaced logic for resolving header mappings and module name using the new method `resolve_use_frameworks` in all podspecs.
- Add an explicit check to make sure we add the correct path when using frameworks and the pod is ReactCodegen.
- Added includes in the NativeCXXModuleExample.cpp file to test this.
## Changelog:
[IOS] [FIXED] - Fixed using USE_FRAMEWORKS (static/dynamic) with precompiled binaries
Pull Request resolved: https://github.com/facebook/react-native/pull/53432
Test Plan:
Build RN-Tester with USE_FRAMEWORKS static and dynamic
### Tests ran:
✅ Build with source and no USE_FRAMEWORKS
✅ Build with source and USE_FRAMEWORKS = static
🔴 Build with source and USE_FRAMEWORKS = dynamic
Undefined symbols for architecture arm64:
"facebook::react::oscompat::getCurrentProcessId()", referenced from:
Reviewed By: motiz88
Differential Revision: D81127796
Pulled By: cipolleschi
fbshipit-source-id: 1f55bf31240ac93cb8b93751b3e37ff6d517f49b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53476
## Changelog:
[General] [Added] - allow calling createAnimatedNode without batching
Enable setting `nativeCreateUnbatched` config on an AnimatedNode, when it's true, the call to Animated nativeModule's createAnimatedNode will skip signal batching (will call over JSI before React rendering is finished) and batching in c++, and the creation will be executed at next UI thread render.
This will only make AnimatedNodes creation happen early, but node/view connections, node deletion or event drivers will still be batched like before
Reviewed By: yungsters
Differential Revision: D80968512
fbshipit-source-id: afb607410a174fb85107ef270b9d6f3d61617daf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53472
changelog: [internal]
I am looking into stalls when View Culling is turned on together with immediate state updates. This is one of the places where stalls are concentrated and this seems like a possible culprit:
When view is moved outside of the viewport, it is immediately reused. Therefore, we must check view's identity to make sure it is the same view before and after transaction.
Reviewed By: lenaic
Differential Revision: D81044328
fbshipit-source-id: 796b71219e5fc94c1f98319b73f4655b9c13000f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53464
Changelog: [Internal]
Minor followup from D78351937 - the Fusebox console notice still mentions that RNDT requires Chrome or Edge. Let's remove this mention for users opted into the standalone shell experiment.
Reviewed By: huntie
Differential Revision: D81040965
fbshipit-source-id: a290d3164261f8a1087229edfe3f69a2a9b49960
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53435
Changelog: [Internal] Support setting `enableStandaloneFuseboxShell: true` in OSS with no custom `BrowserLauncher`
Makes it possible for frameworks to enable the React Native DevTools standalone shell in open source by passing `unstable_experiments: {enableStandaloneFuseboxShell: true}` to `createDevMiddleware()`.
When this experiment is enabled:
* The RNDT shell binary will be prefetched in the background as soon as the dev server starts (into a local cache managed by [DotSlash](https://dotslash-cli.com/)).
* If prefetching is successful, then "Open DevTools" actions will be handled by launching the RNDT frontend in the standalone shell, instead of in Chrome/Edge.
* If prefetching is not successful, then we'll notify the user about the error, and "Open DevTools" will continue to be handled by Chrome/Edge, as before.
* If the user attempts to open DevTools more than once for the same app, the standalone shell will reuse the existing window (as opposed to the current behaviour of always creating a new Chrome/Edge window).
* The appropriate DevTools window will automatically foreground itself upon pausing on a breakpoint.
Reviewed By: huntie
Differential Revision: D78351937
fbshipit-source-id: 6d5baa8fa866760f1d527108cd3c42bcab68cf57
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53438
Changelog: [Internal]
Makes `flavor: 'prebuilt'` the default mode of launching the RNDT standalone shell, and the *only* mode supported in the published version of the package. See D78351931 for more context.
With this, we can demote `electron` from `dependencies` to `devDependencies`. This makes it possible to make `debugger-shell` a dependency of `dev-middleware` (and thus of all major frameworks) without significantly impacting `npm install` times. We'll add this dependency on `debugger-shell` in an upcoming diff (D78351937).
We also stop publishing the `dist/electron` subdirectory (and `src/electron` for good measure) since the corresponding code will always be bundled into the prebuilt binary instead.
Reviewed By: huntie
Differential Revision: D78351934
fbshipit-source-id: 2a4b03e852c4d0330250567c41dca09d1c4f3abd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53437
Changelog: [Internal]
The React Native DevTools standalone shell is distributed as a DotSlash file that downloads the required binaries lazily. This diff adds support in dev-middleware for a new `BrowserLauncher.unstable_prepareFuseboxShell` method that integrations can use to kick off the download early. Integrations are expected to implement this by calling the `unstable_prepareDebuggerShell` function (added to the `debugger-shell` package in D78413091).
If `BrowserLauncher.unstable_prepareFuseboxShell` returns an error, dev-middleware will fall back to the browser-based launch flow, even for users opted into the `enableStandaloneFuseboxShell` experiment.
Reviewed By: huntie
Differential Revision: D78413092
fbshipit-source-id: 6868bf07e16353fcd83337ae54c87c5a641a0f99
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53434
Changelog: [Internal]
The React Native DevTools standalone shell is distributed as a DotSlash file that downloads the required binaries lazily. This diff gives integrations a mechanism for kicking off the download early (but without slowing down `npm install react-native`). This will be integrated into dev-middleware in an upcoming diff.
Reviewed By: huntie
Differential Revision: D78413091
fbshipit-source-id: caf2010edd1bcdd139d37d7849212cd1cbb64f46
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53436
Changelog: [Internal]
Adds a `flavor` option to `unstable_spawnDebuggerShellWithArgs` to select between two modes:
1. `flavor: 'dev'` (current behaviour) - launching a stock Electron binary (from the `electron` package) and pointing it directly at the shell code from the `src/electron` directory.
2. `flavor: 'prebuilt'` (new in this diff) - launching the prebuilt React Native DevTools binary included in the package (built continuously at Meta and committed as a DotSlash file in automated diffs e.g. D79836825). Note that this binary includes Electron *and* a frozen version of the shell code from `src/electron`.
Going forward, `'dev'` will only be used when developing the package (e.g. in D78351934 we will move `electron` to `devDependencies`). The published version of the package is only intended to work with `flavor: 'prebuilt'`.
Reviewed By: huntie
Differential Revision: D78351931
fbshipit-source-id: d0e66b54c142dc2910619ba3d6d149d88324c872
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53468
# Changelog: [Internal]
I've just discovered today that Chrome DevTools has a native support for `panel` query parameter, we don't need a custom one.
Reviewed By: alanleedev
Differential Revision: D81052828
fbshipit-source-id: 6f8ef5b576dbff70cabd6ab792bc0f6e615928e7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53465
changelog: [internal]
I am debugging an issue with Fabric View Culling + immediate state update.
The problem appears to be in logic handling `maintainVisibleContentPosition`. I want to try to disable the prop to see if the problem goes away.
Reviewed By: rshest
Differential Revision: D81030436
fbshipit-source-id: 8efeb1151ad3e12b812cafd073348502510ef01d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53466
This is a follow-up on D80631997. When enabling View Culling on Android, wrapped Text components would lead to event handlers set by the inner Text component not being set on the attributed string.
```
<Paragraph>
<Text onPress={myHandler}> <- This handler is not set
<RawText/>
</Text>
</Paragraph>
```
This was due to the inner Text component having no size and hence being culled by the View Culling algorithm.
This diff disables view culling for views having no size, since no layout means no valid decision can be made as to the visibility of the component within the viewport.
It also removes the change made by D80631997. This means Text views with a layout size set can be culled again.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D81044841
fbshipit-source-id: e9b01dcb8030b271876329b9b2c5bda36ba2b87a
Devan Buggay
generatedunixname1395667395051502
Pieter De Baets
Christoph Purrer
Chi Tsai
Tim Yung
Luna Wei
Joe Vilches
Alex Hunt
Moti Zilberman
Ramanpreet Nara
Tiangong Li
generatedunixname537391475639613
Kaining Zhong
Sam Zhou
Riccardo Cipolleschi
Christian Falch
Christian Kruse
Zeya Peng
Samuel Susla
Ruslan Lesiutin
Nick Lefever