Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46820
Relanding this as we had to unship due to some issues, which are fixed in the previous diff
Reviewed By: NickGerleman
Differential Revision: D63844167
fbshipit-source-id: b3e62004fe87ff732aac1c1622ac35d581b4980f
Summary:
X-link: https://github.com/facebook/yoga/pull/1715
Pull Request resolved: https://github.com/facebook/react-native/pull/46799
Content box impl had a bug where we resolved padding % against the same reference length as the dimensions. Padding should always be against containing block's width. This is also true for width, but not for height, which should be against containing block's height.
This just pipes the width into our box sizing functions.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D63787577
fbshipit-source-id: e512338770f25b66506cabab5a7cde8f04397ea0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46844
Currently we can't see when a network query is made. It makes it hard to debug performance in apps like Store because it's unclear which queries are preloaded, which are fetched as early as they can and which ones are fetched late.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D63858486
fbshipit-source-id: 29d74a68f96a7d4c7b212453d7c0ceba525f3e39
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46841
Some apps are crashing because surfaces are started and stopped concurrently and this can create a deadlock.
This is an attempt to disentangle the deadlock by not moving synchronously to the main queue when starting a surface
## Changelog
[iOS][Changed] - Do not move to the main queue synchronously when starting a new surface
Reviewed By: fkgozali
Differential Revision: D63899469
fbshipit-source-id: 98cb313ebd610c65f6b06a683912856a00102e44
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46747
You can now use unions in native modules.
Support for this pretty much existed, but one callsite was throwing for non-cpp modules which meant nobody could use this.
Previously, StructCollector would throw that this was not supported because it couldn't generate it for objc. Instead of generating something smart in the native code for each option, it just tells native to treat them like the base type (number, string, object).
Changelog: [General][Added] Codegen now supports Union Types in NativeModules
Reviewed By: GijsWeterings
Differential Revision: D63664505
fbshipit-source-id: 73278ed9cd64452173c5170aba44ced71181510f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46826
This change adds `isDarkerSystemColorsEnabled()` to `AccessibilityInfo` to enable access to iOS's "Increase Contrast" setting option. It also adds a new event, `darkerSystemColorsChanged`, to enable listeners to subscribe to changes on this setting.
## Changelog
[iOS][Added] - Added `isDarkerSystemColorsEnabled()` to `AccessibilityInfo` to read "Increase Contrast" setting value
Reviewed By: cipolleschi
Differential Revision: D63880393
fbshipit-source-id: a476f8fc4d7354826bc344876b359eb1a3485f0d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46816
This converts the same native module from Java to Kotlin.
I've converted the whole module as it was quite simple + I've fixed some of the warnings.
Changelog:
[Internal] [Changed] - Convert react/nativemodule/samples/ to Kotlin
bypass-github-export-checks
Reviewed By: javache
Differential Revision: D63837631
fbshipit-source-id: bb126d7649a6e8a36510bf2b252ecdfae91fe09f
Summary:
Part of this: https://github.com/facebook/react-native/issues/46757
Solves:
- ME2E0017
- ME2E0018
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ Internal ] [ Added ] - Add e2e test for button
Pull Request resolved: https://github.com/facebook/react-native/pull/46829
Test Plan:
yarn e2e-test-ios
yarn e2e-test-android
Reviewed By: rshest
Differential Revision: D63889079
Pulled By: cipolleschi
fbshipit-source-id: ca2ede3142d77170fcb4121b025eab56818ffb07
Summary:
This pr is part of issue https://github.com/facebook/react-native/issues/46757 solving tasks [ME2E0001] and [ME2E0002].
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ Internal ] [ Added ] - Add e2e test for modal
Pull Request resolved: https://github.com/facebook/react-native/pull/46796
Test Plan:
yarn e2e-test-ios
yarn e2e-test-android
Reviewed By: cortinico
Differential Revision: D63829299
Pulled By: cipolleschi
fbshipit-source-id: ff64d0babde8aea6e2586c2f69056a10533750f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46832
After bumping to minIOSVersion 15.1, we refactored the code to remove some check.
In the refactoring, we changed how the `keyWindow` is returned and now we are unsafely casting `UIScene` to `UIWindowScene`.
We have some internal apps that use `UIScene` that are not `UIWindowScene` and the change is causing them to crash.
This change fixes the crash by checking whether the selector is available in the UIScene and casting it only in that case.
Otherwise we return `nil`, the same behavior we used to have before the refactor.
## Changelog
[iOS][Fixed] - Cast the UIScene to UIWindowScene only if the scene respond to the selector
Reviewed By: javache
Differential Revision: D63890980
fbshipit-source-id: 3230e0075f06ed3f3d759b48f9c7bd13d8787b44
Summary:
Part of this: https://github.com/facebook/react-native/issues/46757
Solves:
- ME2E0011
- ME2E0012
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ Internal ] [ Added ] - Add e2e test for button
Pull Request resolved: https://github.com/facebook/react-native/pull/46805
Test Plan:
```
yarn e2e-test-ios
yarn e2e-test-android
```
Reviewed By: cortinico
Differential Revision: D63829243
Pulled By: cipolleschi
fbshipit-source-id: 87d8e62650c66fb07e116877a212eff79f10eaf2
Summary:
This PR moves `RCTNotifyEventDispatcherObserversOfEvent_DEPRECATED` as it was used as string in the codebase and in OSS libraries.
## Changelog:
[IOS] [FIXED] - move RCTNotifyEventDispatcherObserversOfEvent_DEPRECATED to const
Pull Request resolved: https://github.com/facebook/react-native/pull/46833
Test Plan: CI Green
Reviewed By: cipolleschi
Differential Revision: D63891220
Pulled By: javache
fbshipit-source-id: d4fa1f751b4b0cb131ab6c6d4dd0a345762d7c71
Summary:
I discovered this while working on my shim of `UIGraphicsImageRenderer` for macOS (See https://github.com/microsoft/react-native-macos/pull/2209). A variable of type`CGColorRef` is not automatically retained and released when passed into a block. There was a case in `RCTBorderDrawing` where we were doing so. To fix this, we have two options:
1. Pass a `UIColor` instead (Requires a change to the signature of the function calling it)
2. Properly retain and release the variable.
The first option would technically be a breaking change (we would need to change the signature of `RCTGetBorderImage`, so I'm opting for option 2.
## Changelog:
[IOS] [FIXED] - Properly retain/release backgroundColor in RCTBorderDrawing
Pull Request resolved: https://github.com/facebook/react-native/pull/46797
Test Plan: CI should pass. Locally, borders still draw fine for me.
Reviewed By: joevilches
Differential Revision: D63827824
Pulled By: cipolleschi
fbshipit-source-id: 926601d062b90a7d741d7a1af3070cec4b8795ae
Summary:
This fixes an issue where `POST /open-debugger?appId&device&target` does not return a proper status code, meaning that the request will never be answered and clients might hang until the request timeout is hit.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[GENERAL] [FIXED] - Respond with status code `200` when successfully launching RNDT
Pull Request resolved: https://github.com/facebook/react-native/pull/46814
Test Plan:
- `curl -v -X POST "<deviceUrl>"`
- This should show a proper response for the request.
before | after
--- | ---
 | 
Reviewed By: NickGerleman
Differential Revision: D63837025
Pulled By: huntie
fbshipit-source-id: ac72fc793e015f0eec498f4a35b4fb9e301c5b32
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46787
This issue was raised by a some partner that were integrating with libraries that were setting the wrong C++ version.
With this change, RN takes ownership of the version of C++ that must be supported.
## Changelog
[iOS][Breaking] - Cocoapods decide the C++ version for iOS pods
Reviewed By: blakef
Differential Revision: D63760271
fbshipit-source-id: 5e629c61accd97fb10a199430d31e8b4c73d482b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46160
We use this for all built-in components now, and rely on going through `BackgroundStyleApplicator` to be able to set additional background effects like borders, rounded corners, box shadow, outlines.
Let's use this in `BaseViewManager`, to allow exposing those other effects to all views, letting RN manage the background drawable for views using `BaseViewManager` and exposing the props for the managed styles.
This is technically breaking, in the case where a custom component could previously inherit directly from `BaseViewManager`/`ReactViewGroupManager`, (vs `SimpleViewManager`/`ReactViewManager`), then override `setBackgroundColor` on the Android View, instead of the view manager, but this effected zero of the [276 top libraries](https://github.com/elicwhite/react-native-libraries), so I don't think it would be common to hit.
Changelog:
[Android][Breaking] - Use BackgroundStyleApplicator when setting background color in BaseViewManager
Reviewed By: tdn120
Differential Revision: D61658739
fbshipit-source-id: 15af649328ea18fda3cd68e56d481ed1c0fd43c4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46800
X-link: https://github.com/facebook/yoga/pull/1716
Had a mini heart attack thinking I set the default to content box. Wrote this to double check and it passed. Might as well check it in
Technically the default to BoxSizing.h is ContentBox, but in the style we override that. Regardless I switched that around so border box was the default.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D63802722
fbshipit-source-id: 49ed29657c964bc12a2bf70988061ab4599267ec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46712
## Summary
Now that XML resources are loaded via Fresco decoder, this change removes the custom branch that attempts to load drawables on the main thread. Loading (i.e. binary XML decompression) is performed on a background decoder thread from Fresco the same as every other image type.
## Changelog
[Android][Fixed] - Avoid blocking the main thread when decompressing drawable resources
Reviewed By: javache
Differential Revision: D63476282
fbshipit-source-id: a8510d140f85a55b90bf4aab6fd4cf5e46dfc7fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46812
Convert to Kotlin as close a 1:1 as possible.
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D63773448
fbshipit-source-id: 72d67ec5993ffb225b016937e6a33fc8d4a8af16
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46763
Changelog: [Internal]
[iOS][DeprecatedAPI] - Deprecate UIApplication.windows access for iOS versions higher than 13.0
> 'windows' is deprecated: first deprecated in iOS 15.0 - Use UIWindowScene.windows on a relevant window scene instead [-Werror,-Wdeprecated-declarations]
Reviewed By: cipolleschi
Differential Revision: D63708635
fbshipit-source-id: 18cfeda89def996319a46573abeb88d4672f6c0d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46811
I turned this off a few weeks after we turned off in FB app in (D60273063), after discovering it defeated a check used to disable `removeClippedSubviews` in RTL (reintroducing its bugged behavior).
D63318754 fixed that bug, so this is turning back on by default. This is also needed to fix border rendering direction bug introduced in BackgroundStyleApplicator in views where the contextual layout direction is different from the root Android layout direction (either because of `direction`, or `I18nManager` forceRTL). This fixes some existing RNTester RTL screenshot test failures which are hooked via forceRTL.
This also fixes rendering of some native components like `Switch` which would previously not respect contextual direction.
Changelog:
[Android][Fixed] - Reenable `setAndroidLayoutDirection` by default
Reviewed By: javache
Differential Revision: D63815077
fbshipit-source-id: fea64191d83d366c6bfc7b8c58b215773c8e8efe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46613https://github.com/facebook/react-native/commit/bd323929dc5be5666ee36043babec7d981a095dc added a workaround to a bug where Android new arch would return incorrect measurements when the last character in dynamically sized TextInput is a newline. This workaround works by adding a placeholder character after any trailing newlines.
Apart from a minor oversight in the impl (unnecessary `toString()` copying text on every layout), approach of mutating Spannable will create problems for `PrecomputedText`, where we want to avoid mutating Spannable after set in more common cases for normal text (though mutation must happen for a few other cases, like adjustment, or EditText).
The real root cause of the issue is that StaticLayout tries to derive the size of text for area outside of what is covered by the Spannable (whose last char is the newline, considered on the previous to last line). This causes it to use text size, family, etc from `TextPaint`, which does not have this information set in new arch (the font size (but oddly nothing else) is set in Paper).
This updates TextLayoutManager to set this information on TextPaint before creating a layout. Because TextPaint is now mutable, and TextLayoutManager can be called by multiple threads, I made the variable thread local to avoid concurrent mutation. We also have the cached Spannable scenario where we have already lost the AttributedString, but in this case, we can reuse the underlying EditText paint, which I associate with the underlying cached Spannable.
I also marked a few more methods in TextLayoutManager private which nothing else is calling, to be able to better reason.
A followup, is that `ReactTextInputManager` sets all of these extra fields on the `EditText` paint (so those will be consistent), but `ReactTextAnchorViewManager` does not set all of these, so its underlying TextView would normally show newlines with an inconsistent size compared to the attributes present (though I don't think it much matters if we add the right amount of extra space to the actual layout).
Changelog:
[Android][Fixed] - Properly fix measurement of trailing newlines
Reviewed By: cortinico, mdvacca, mellyeliu
Differential Revision: D63303172
fbshipit-source-id: 63e5e24bce7fe8866524171d9acfc8f13e1efffc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46612
This information is lost by the time the AttributedString makes its way to be measured.
Pretty sure I've seen code do incorrect heuristics like grabbing first span for this (IIRC adjustFontSizeToFit does this)? Another case where we hit this on Android is when the last character is a newline (which is part of the Spannable), and layout needs to predict the size of the line which will come next (where it uses the EditText's underlying TextPaint, who is using these base attributes).
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D63303709
fbshipit-source-id: 644a97c80a9280e643514786ea6cf32faa4f1cf8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46711
## Summary
Vector drawable decompression is a blocking operation and can sometimes take upwards of 20-30ms per image, especially if that vector drawable uses complex colors. Less complex vector drawables still take several milliseconds to decompress and are served from a cache on later load attempts.
Here's a list of all the load times of vector drawable images in FBVR:
{F1891592104}
This diff aims to shift decompression to one of Fresco's decode threads, off the main thread, so we don't block while waiting for decompression operations to complete. This relies on adding a new custom decoder that reads the header of XML binary and converts encoded image requests to drawable objects that are yielded from the new `XmlDrawableFactory`.
It's important to note that this change does not stop `ReactImageView` from loading XML-based drawables on the main thread, it merely offers a new mechanism for loading them.
## Changelog
[Android][Added] - Add a new Fresco decoder for XML resource types
Reviewed By: mdvacca
Differential Revision: D63476283
fbshipit-source-id: b0f9b5af42254bcf038a9eb088e7d72dd39cdb51
Summary:
While digging through the types I came accross this TODO. Now that react-native uses version 5 of TS this can be updated
## Changelog:
[General] [Added] - Updated FlatList setNativeProps type
Pull Request resolved: https://github.com/facebook/react-native/pull/46773
Reviewed By: NickGerleman
Differential Revision: D63765333
Pulled By: cipolleschi
fbshipit-source-id: ad612205d168cd90f270da72092f8ce67f5038c4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46789
GitHub is reporting those warnings on each pull request. This clears them up as they're effectively unused.
Changelog:
[Internal] [Changed] - Remove several unused imports in Flow code
Reviewed By: cipolleschi
Differential Revision: D63757201
fbshipit-source-id: 21189136a03de8899adcbf18c8f0e29844ade340
Summary:
On the old architecture you could take control of loading the bundle by implementing
```objc
- (void)loadSourceForBridge:(RCTBridge *)bridge
onProgress:(RCTSourceLoadProgressBlock)onProgress
onComplete:(RCTSourceLoadBlock)loadCallback;
```
in your `RCTBridgeDelegate`. This is not currently possible in the new architecture.
I've added this using a pretty much identical api by adding a function to both the `RCTInstanceDelegate` and `RCTHostDelegate` protocols. This will be called on the `RCTRootViewFactory`. I've added two properties to the `RCTRootViewFactoryConfiguration`, `loadSourceForHost` and `loadSourceWithProgressForHost`. If one is present, we call it, otherwise we fallback to the normal loading process
## Changelog:
[iOS] [Breaking] - Add ability to control bundle loading on the new architecture similar to `loadSourceForBridge`. Removed some properties from the `RCTRootViewFactory`.
Pull Request resolved: https://github.com/facebook/react-native/pull/46731
Test Plan: Rn-tester works as normal and it is working for our use case in expo go.
Reviewed By: blakef
Differential Revision: D63755188
Pulled By: cipolleschi
fbshipit-source-id: f1f26b2775b9e547ce7a23028665797c19bfdd9b
Summary:
Because `UIGraphicsImageRenderer` doesn't exist on macOS, I need to shim it for React Native macOS (See https://github.com/microsoft/react-native-macos/pull/2209). I planned to use the name `RCTUIGraphicsImageRenderer`. However.. it seems that is used by a static helper function in `RCTBorderDrawing.m`. So.. let's rename it? The function is just a helper method to make an instance of the class, so I think the name `RCTMakeUIGraphicsImageRenderer` is slightly more idiomatic anyway.
This method is not public, so it should not break the public API of React Native.
## Changelog:
[IOS] [CHANGED] - Rename `RCTUIGraphicsImageRenderer` to `RCTMakeUIGraphicsImageRenderer`
Pull Request resolved: https://github.com/facebook/react-native/pull/46772
Test Plan: CI should pass
Reviewed By: joevilches
Differential Revision: D63765490
Pulled By: cipolleschi
fbshipit-source-id: de68dce0f92ec249ea8586dbf7b9ba34a8476074
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46806
This fixes the CI which is currently red due to wrong C++ imports.
Changelog:
[Internal] [Changed] - Unbreak build_android
Reviewed By: javache, cipolleschi
Differential Revision: D63826953
fbshipit-source-id: 4d9e407331af666a420cf56178420df40e598ef4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46794
Original commit changeset: f57e9a51236c
Original Phabricator Diff: D63430964
Seeing some issues with this so gonna turn it off for the meantime.
Changelog: [Internal]
Differential Revision: D63777437
fbshipit-source-id: fe8abd0110b2cf7296911c5b1e95ada40d30994c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46795
Original commit changeset: d7bb6f115bca
Original Phabricator Diff: D63471840
See previous diff, there were some problems
Changelog: [Internal]
Differential Revision: D63777438
fbshipit-source-id: ea9f370eade10282fcee84d07d709b549dde1b6d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46736
Copying the comment in code:
> We only call `onEndReached` after we render the last cell, but when getItemLayout is present, we can scroll past the last rendered cell, and never trigger a new layout or bounds change, so we need to check again after rendering more cells.
Changelog:
[General][Fixed] - Fix onEndReached not being called when getItemLayout is present and we scroll past render window
Reviewed By: yungsters
Differential Revision: D63643856
fbshipit-source-id: 9c53789cb15b225ceac353c37cbb67f7beeaf4fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46793
Currently performance logging has several problems:
- We have widly different APIs. It's hard to know which to use for what.
- Most of these APIs don't allow retroactive timestamp which is important for hero logging and react flame graphs
- These APIs aren't accessible from JS/C++/Java/Koltin (this part will be fixed in another diff)
- Logging doesn't go to the right place. It either only goes to Systrace, or Perfetto but with broken async timeline etc...
This diff start addressing the problem by refactoring. Currently performance.measure/performance.mark are the best APIs. Let's start with refactoring them so that we can call them directly without the otherwise PerformanceEntry side effects.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D63560473
fbshipit-source-id: 86755b3e8491a7cf6919173a07ba9421cd30e663
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46788
Changelog: [internal]
This fixes the reported keys for C++ TurboModules:
```
import MyNativeCppModule from 'MyNativeCppModule';
Object.keys(MyNativeCppModule); // [] - expected
Object.keys(Object.getPrototypeOf(MyNativeCppModule)); // [] - NOT expected
```
Before, we were trying to read the properties from the method map in the public `TurboModule`, but in this implementation all the logic is actually in its delegate (also a `TurboModule` instance, yeah, confusing).
This fixes the issue by forwarding the call to the delegate that has the right information.
Reviewed By: javache
Differential Revision: D63761381
fbshipit-source-id: 90bd216efa0f60352c5ca341d210d83239c80dba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46785
changelog: [internal]
Make sure logs match the class name
Reviewed By: rubennorte
Differential Revision: D63757693
fbshipit-source-id: 815e70e8ae38d99b1908d3aa2a9cfffdd9dc9851
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46780
This is primarily a debugger server change to better-align the `title` and `description` fields (visible in via the CDP `/json/list` endpoint), reporting them directly from the device.
For React Native users, the net effect of this change is to improve/align the display name for each debugger target in the CLI multi-select menu (`j` to debug). This change may also be useful for discovery in non-Fusebox frontends such as VS Code (`vscode-expo` extension).
Changes:
- Rename `title` prop on `InspectorPageDescription`/`IInspector::addPage` to `description` (no call site changes).
- Add `deviceName` param to `InspectorPackagerConnection`.
- Move the page `description` to the `description` JSON field.
- Update `InspectorPackagerConnection::Impl::pages()` to return new `title` and `description` fields.
- Align `OpenDebuggerKeyboardHandler` to display `title` field.
- Deprecate the nonstandard `deviceName` field.
**Before**
```
[
{
"id": "3c9f24bedab0e73fca6a1b295030e7af9346a8c0-1",
"title": "React Native Bridgeless [C++ connection]",
"description": "com.facebook.RNTester",
...
}
```
The `description` field was previously the closest thing we had to a target identifier. Today, this is not needed, since we have the stable `reactNative.logicalDeviceId` field.
**After**
```
[
{
"id": "3c9f24bedab0e73fca6a1b295030e7af9346a8c0-1",
"title": "com.facebook.RNTester (iPhone 16 Pro)",
"description": "React Native Bridgeless [C++ connection]",
...
}
```
The `title` field is now more human readable and aligned with what we render in the window title of React Native DevTools. The `description` field describes the type of debugger target (the specific React Native implementation).
Changelog: [Internal]
Reviewed By: vzaidman
Differential Revision: D63329456
fbshipit-source-id: cfe98f77e31c729431005925cfc66e2780ef8c72
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46782
changelog: [internal]
Avoid setting C++ state for the same contentOffset. This is redundant work and can be safely avoided.
Reviewed By: NickGerleman
Differential Revision: D63700308
fbshipit-source-id: d6ea8cf6a1da47a13787b49abd66a87e3da57d34
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46778
This has been rolled out internally already and is a good cleanup for OSS too. We no longer use this config externally (BRIDGE+FABRIC) so this shouldn't actually affect the new arch rollout.
Changelog: [Internal]
Reviewed By: fabriziocucci
Differential Revision: D63752084
fbshipit-source-id: da3025f7b072dc7b82f8de22ff247b3979ae64d0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46776
All other paths that touch `mAttachedReactRoots` uses this lock. We expect this to address a crash we're seeing in production where `startSurface` is invoked multiple times.
Changelog: [Internal]
Reviewed By: fabriziocucci
Differential Revision: D63752083
fbshipit-source-id: f06d07aa70719945f6956fbf6e0cde3e9c8e8ed0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46751
rubennorte noticed that some turbo module methods were not getting cached on the jsRepresentation as expected. This is caused by the react-native-codegen wrappers we generate overriding the `get` method and bypassing this caching layer. Instead they should be overriding `create` to lazily allocate new properties. To prevent this from re-occuring, I've made `get` final so no other overrides can happen.
## Changelog:
[General][Fixed] Properties for C++ TurboModules using codegen were not correctly cached
[General][Breaking] TurboModule::get is now a final method, override `create` to customize property lookup
Reviewed By: rubennorte
Differential Revision: D63665966
fbshipit-source-id: c614901c2f0d698147ec9ba36a4b592ed3d37652
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46697
Changelog: [internal]
This is already the case in `PerformanceMeasure` but for some reason we didn't apply it here as well.
Reviewed By: rshest
Differential Revision: D63541134
fbshipit-source-id: 262d504ed153e07e89492945f761887729bad9e0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46698
Changelog: [internal]
Small optimization to use readers/writers for locking in `PerformanceEntryReporter`.
Reviewed By: rshest
Differential Revision: D63540236
fbshipit-source-id: 80b3fd313453ad8da4f0af2deaab61a86064b4b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46693
Changelog: [internal]
This unifies the native modules for `Performance` and `PerformanceObserver` in the same module. Keeping them separate is artificial and introduces unnecessary duplication. These APIs are very closely related so it makes sense to unify
Reviewed By: javache
Differential Revision: D63471855
fbshipit-source-id: fa8c5dc7b7c68954fc11867f68909d2c6c2ee85c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46760
Changelog: [internal]
Relying on the singleton was causing issues in iOS tests for RuntimeScheduler. This fixes those issues.
Reviewed By: rshest
Differential Revision: D63702251
fbshipit-source-id: 42b98e673ffba6f45b52510cdb3eea410e55b894
Joe Vilches
Benoit Girard
Riccardo Cipolleschi
Eli White
Ariel Lin
Nicola Corti
muskan27797
Ahmed Bilal
Yasir
shubhamguptadream11
Oskar Kwaśniewski
Saad Najmi
Cedric van Putten
Nick Gerleman
Peter Abbondanzo
Thomas Nardone
Cao Doan
JDMathew
Sam Zhou
Alan Hughes
Gabriel Donadel
Alex Hunt
Rubén Norte
Samuel Susla
Pieter De Baets