Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45616
We want to eventually route all js error handling through JsErrorHandler in bridgeless.
This will help with that.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D60138415
fbshipit-source-id: de62edfe75066ba135225e24543628306aa5f4a0
Summary:
When trying to use the legacy view interop with `stripe/stripe-react-native` there is an issue with the `CardField` component because it tries to access module registry inside the `view` method (https://github.com/stripe/stripe-react-native/blob/master/ios/CardFieldManager.swift#L7).
The problem is that we attach the legacy view apis after creating view, so they are not available in that method.
To fix this we can change the order of the methods and attach the apis first. Note that we also need to use the `manager` method instead of `bridgelessViewManager` since `bridgelessViewManager` is not initialized otherwise, it is initialized lazily in the `manager` method.
## Changelog:
[IOS] [FIXED] - Fix legacy view interop apis not available in view method
Pull Request resolved: https://github.com/facebook/react-native/pull/45609
Test Plan: Tested in an app that legacy interop apis (`moduleRegistry`) is available in the `view` method in an app using RN 0.74 with bridgeless mode enabled.
Reviewed By: cipolleschi
Differential Revision: D60165191
Pulled By: dmytrorykun
fbshipit-source-id: 60187556fb36d342bb1ef084a093132bdb0496bd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45585
Changelog: [internal]
Just migrates the flag to the new system.
Reviewed By: sammy-SC
Differential Revision: D60050005
fbshipit-source-id: 4da39446ecdb6cd86ccf7ee75a0d489764c37be6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45598
I've noticed we attempt to load JSC from the Sonatype Snapshot repository.
That is inefficient as we already know that JSC is available only inside node modules.
This change makes the repository resolution stricter by better specifying which
repo can download which dependency.
Changelog:
[Internal] [Changed] - Do not attempt to load JSC from other repositories
Reviewed By: cipolleschi
Differential Revision: D60116002
fbshipit-source-id: 21a2213708f5b0103860a59f3342f1bc0f59cdb9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45590
This gives us more wiggle room with the release of 0.76.
Changelog: [General][Changed] Move init deprecation notice 30 Sept → 31 Dec
Reviewed By: cortinico
Differential Revision: D60105868
fbshipit-source-id: d03fcf5d4a97db9b21792eff6f993e2671b276ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45515
After some provisional hacking on macOS support for React Native DevTools last week, this revealed some incompatibilities with traditional OS X APIs, which are minimally addressed here.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D59807146
fbshipit-source-id: 39c4eab723046926b0b469232152e2f994af2366
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45575
We should move over to use AssertJ as per our linter.
I'm adding it here to a first test and will use it as a reference for some OSS contributions from outside.
Changelog:
[Internal] [Changed] - Migrate settings-plugin to Assertj
Reviewed By: cipolleschi
Differential Revision: D60037797
fbshipit-source-id: 579ed7bf5fb219e25577af3ab87934503ee7898e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45572
0.75-rc.5 is currently broken on Windows.
This is due to us invoking `npx react-native-community/cli config` without
a `cmd /c` prefix.
This fixes it by using our function `windowsAwareCommandLine`.
The problem is that this required a lot of refactoring since that util was not available for the settings plugin.
Fixes#45403
Changelog:
[Internal] [Changed] - Fix core autolinking not working on Windows
Reviewed By: cipolleschi
Differential Revision: D60037587
fbshipit-source-id: eefeda7aafc43b9ce08f0f9225b0847fad2f46b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45587
changelog: [internal]
There is a way to avoid doing large number of JNI calls from JS thread for view preallocation on Android. We can move the JNI call to the main thread by creating a queue of views to be created on the JS thread and pulling it from the main thread. This way, the expensive part of JNI call (the actual call + creating JNI values) is moved to the main thread and doesn't block the JS thread from executing rendering.
Reviewed By: javache
Differential Revision: D59966062
fbshipit-source-id: af85138cfdb9b2a7a7710d79e09e165b2be55067
Summary:
The CLI of Metro bundler only accepts key presses when the Caps Lock is off. This is somehow inconvenient because the developers might think the Metro bundler doesn't response when the Caps Lock is on.
## 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] [ADDED] - Add upper case keys to the debug key handler
Pull Request resolved: https://github.com/facebook/react-native/pull/45559
Test Plan: n/a
Reviewed By: huntie
Differential Revision: D60107316
Pulled By: dmytrorykun
fbshipit-source-id: 045dcd382d84c4781dff75a1ff913cd3ccc8d288
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45573
This makes this module now be fully in Kotlin instead of having mixed Java/Kotlin sources.
Changelog:
[Internal] [Changed] - Converted com.facebook.react.modules.dialog to Kotlin
Reviewed By: tdn120
Differential Revision: D60035771
fbshipit-source-id: b45fd099c0b353768ab6580eb6a4a3dccf68f07d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45570
We do have several methods/classes that are `deprecated` in the JavaDoc but not
with an annotation. That's not correct as users will never get those deprecation otherwise
and we'll be forced to keep both implementation around for a longer time.
Changelog:
[Internal] [Changed] - Properly annotate with Deprecated methods that are just deprecated in JavaDoc
Reviewed By: javache
Differential Revision: D60036159
fbshipit-source-id: 466072d6a3fb4f1220e1dc3deaa51a46c714a388
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45567
Changelog: [internal]
(internal because our integration for Perfetto hasn't been released in OSS yet)
In our current React integration for Perfetto we're logging arbitrary time spans via `performance.measure` in specific tracks (that can be custom based on a naming scheme).
For a given track, Perfetto doesn't allow partially overlapping segments (as it's considered to always be a stack of time spans). When logging arbitrary time spans that partially overlap, Perfetto cuts the nested ones to make sure they fit into their suspected parent. This makes the logged data incorrect and makes it hard to understand the performance of an application using this data.
There's a fix for this problem: logging these arbitrary segments/time spans in separate tracks that only share the name. In this case, Perfetto groups the data in the UI but allows overlapping (as they're not really on the same track).
Reviewed By: sammy-SC
Differential Revision: D60010696
fbshipit-source-id: 378ea492c4fafbe55ef97fa91e4fa50bbc1893ae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45564
Changelog: [internal]
(this is internal because the integration hasn't been enabled in OSS yet)
In our current React integration for Perfetto we're currently creating multiple custom tracks that are spread throughout the process section and it can be hard to identify the source of the information.
This adds a "Web Performance: " prefix to all custom tracks coming from JS to achieve 2 purposes:
* Group them together (in terms of order in the process)
* Clarify the source of the data
Reviewed By: sammy-SC
Differential Revision: D60010695
fbshipit-source-id: 081f5b6417d676c61005114337530a089142e7c6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45539
Changelog: [internal]
This exposes several classes (interfaces in the spec lingo) related to the Performance API to the global scope, so users can access them directly to do things like refinements using `instanceof`. This also prevents the need from importing the modules from `react-native` directly, which would prevent code sharing with Web.
Reviewed By: rshest
Differential Revision: D59859654
fbshipit-source-id: e1f7afb0c98b394b1f97c3790db2e570e6ba0cd9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45535
Changelog: [internal]
Small refactor to group things based on the spec where they're defined.
Reviewed By: rshest
Differential Revision: D59911334
fbshipit-source-id: 1c40d6bf82b6cc7be78bd81b652d6855c39a53eb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45526
Changelog: [internal]
Just using the right interfaces so we can expose them in the global scope and do refinements as necessary using `instanceof`.
Reviewed By: rshest
Differential Revision: D59911144
fbshipit-source-id: 9779e3220f2c6f81955f54506f97142f0f4ffdd4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45525
Changelog: [internal]
This makes several changes to the Performance API to align it closer with the spec:
* Makes fields of `PerformanceEntry` and subclasses read-only.
* Returns instances of the correct subclass of `PerformanceEntry` to observers.
* Renames `HighResTimeStamp` as `DOMHighResTimeStamp` for alignment with the spec and native
Additionally, I realized that the way we handle `performance.measure` is a bit problematic at the moment. When we call the function, we create a `PerformanceMeasure` instance with the data we receive, and return that value. In parallel, we notify the entry to native, which will in turn notify the observers. But the observers will not get those instances we just created, but new instances of `PerformanceEntry` (not even `PerformanceMeasure`) with the resolved values. At the same time, the `PerformanceMeasure` instance we return doesn't resolve its `startTime` and `duration` based on the indicated marks (when specified as strings). We need to fix this in the future by resolving the timing data synchronously when calling `performance.measure`.
Reviewed By: rshest
Differential Revision: D59911145
fbshipit-source-id: e0be0441f307cc9bdea8795ae88b6f390780fc7b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45524
Changelog: [internal]
The `durationThreshold` option is only meant to be used with `event` entry types. `mark`, `measure`, `longtask`, etc. shouldn't take that option into account, as per the spec.
Reviewed By: mdvacca
Differential Revision: D59918519
fbshipit-source-id: 0553d46944cbe80a32712ff57140763f2514f734
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45545
ReactInstance creation in bridgeless returns a callback that requires dispatching on the UI thread to complete the init. If that thread is busy (eg with other startup tasks), we delay starting the initial surface unnecessarily.
This diff adds an experiment to return early from that startup task to allow follow-up tasks to be scheduled on the JS thread without waiting for lifecycle changes to have been applied.
Changelog: [Internal]
Reviewed By: markv
Differential Revision: D59961779
fbshipit-source-id: dd6a6fe093a32144ef6823bde5ac94a61d268fd2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45554
In this diff I'm extracting the creation of borderWidth into its own method, this is necessary for next diffs of the stack.
Nh behavior change is introduced here
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D59942306
fbshipit-source-id: 85d39b64deaa4e8a8632d6f4aab72f626e594b5d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45553
This diff introduces a "temporary" method called getDiffProps to calculate the difference between 2 props and serialize its result into a folly::dynamic map.
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D59613245
fbshipit-source-id: 3e23cde0113ac2a3904c8daa48a1ca048cd0262d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45556
I missed updating this, and the e2e test we had isn't running, so switching JS objects to camel case broke this.
Changelog: [internal]
Reviewed By: jorge-cab
Differential Revision: D60003747
fbshipit-source-id: 6b7b1138e3ebbfdb982f5a089804351cc4b198ba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45550
`ConcurrentModificationException` is happening from `emitScrollEvent()`.
This usually happens if we modify the collection (add/remove) while accessing collection in a foreach loop.
Seems likely add/remove is called from a different thread while in the foreach loop.
Converting to list before we do the foreach as a quick fix.
Changelog: [Internal] - quick fix for exception
Issure reported here: https://fb.workplace.com/groups/rn.support/permalink/26557068097248454/
Reviewed By: mdvacca
Differential Revision: D59991739
fbshipit-source-id: a2fcc798430acaadd07561a5be871967cc8f2c3b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45549
## Summary
Calling `getCurrentReactContext` on an unmounted `ReactRootView` could lead to a NPE. The method currently returns a nullable value so return type is the exact same. This change checks if the react instance manager is present and returns null early if not.
## Changelog:
[Android] [Fixed] - Adds a null check in react context getter
Reviewed By: zeyap
Differential Revision: D59982179
fbshipit-source-id: bac5c12e7dc4ee3296991063eb3746141b8446bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45530
Enable viewconfig validation for RNTester to catch where static and native viewconfigs are mismatched, during development or contribution time. This relies on `useNativeViewConfigsInBridgelessMode()` which is already enabled in `DefaultNewArchitectureEntryPoint` on Android, and seems to be in iOS AppDelegate `RCTRootViewFactory` as well.
We put it in an early place in the bundle before first render, since we don't have RNTester preludes right now, but I think it is still early enough?
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D59946366
fbshipit-source-id: ae0c23b13a566489a88a7b4e408f61dce314b003
Summary:
This moves the `helloworld` app to build from the artifacts produced by build_npm_package so that we don't rebuild ReactNative Android from source 8 times.
It reduces build time of such jobs from 14mins to 4mins, resulting in 80mins of build time for every test_all run.
## Changelog:
[INTERNAL] - Move helloworld to build from artifacts on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/45517
Test Plan: CI
Reviewed By: blakef
Differential Revision: D59957613
Pulled By: cortinico
fbshipit-source-id: b6c4adcf804af6c8d2661cf56549d037e09aa2c1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45543
# Changelog:
[Internal]-
Introduced recently, this confuses viewconfig validation vs the vanilla Android view managers.
So this change effectively reverts the exposure of `ScrollView.scrollIndicatorInsets` to Android, achieving the goal in a different way (via the SVC injection workaround for the specific Android platform flavour).
Reviewed By: NickGerleman
Differential Revision: D59960782
fbshipit-source-id: 3b9a49f1466426d909e94bf4d33f1d09fbf822c2
Summary:
Added space to $(inherited) string to avoid creation of wrong cpp flags in RCTAppDelegate podspec
<img width="1157" alt="Screenshot 2024-07-18 at 8 51 19 PM" src="https://github.com/user-attachments/assets/29d32d08-e81f-4c25-b8ee-5dccc0f620ea">
## Changelog:
[IOS] [FIXED] - Building of iOS project when RCTAppDelegate is used in the project
Pull Request resolved: https://github.com/facebook/react-native/pull/45520
Test Plan: To test this you can simply change in your node modules and run pod install, the build will now work successfully
Reviewed By: cipolleschi
Differential Revision: D59950906
Pulled By: arushikesarwani94
fbshipit-source-id: 0d58620aa0be7ac4fcbcd309f06df0eef7844016
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45529
`experimental_boxShadow` is not yet part of Android view managers, and when we enable it, we are likely to do a view manager at a time before moving to BaseViewManager.
This causes user-visible errors when viewconfig validation is turned on, since we have a static view config, but not yet a native view config.
This removes the static viewconfig for Android until we start adding setters to view manager.
It is kept in `ReactNativeStyleAttributes` (which I think can have members not in the native view-config, since it has component specific props like tintColor), and iOS base viewconfig. On Fabric iOS, this is part of BaseViewProps, and handled by RCTView, but it looks like the prop (and also `experimental_filter`, `experimental_mixBlendMode`) do not have entries in iOS RCTViewManager, which is fixed in next diff in the stack.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D59939866
fbshipit-source-id: 2781029a0c29ba111ed04edfe9940c6c72f4e5ac
Summary:
Viewconfig processors may still get called for nullish values I think. Most other processors explicitly handle these (but some don't??).
This returns an empty list, like on parse error, when we have a value, but the value is nullish.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D59933611
fbshipit-source-id: 3f1d89d21977bbe01a05e708aadf1a9451d88083
Dan Melnic
Ramanpreet Nara
Jakub Piasecki
Janic Duplessis
Dong-Hwan Kim
bufgix
gustavoabel
Miguel Daipré
Rubén Norte
D N
Nicola Corti
Blake Friedman
Alex Hunt
Samuel Susla
Ruslan Lesiutin
wh201906
CHEN Xian-an
David Vacca
Pieter De Baets
Gabriel Donadel
Nick Gerleman
Alan Lee
Peter Abbondanzo
szymonrybczak
Ruslan Shestopalyuk
nik910