Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45634
This allows the Android runtime to pass additional options to Metro. Each app can
decide what to send based on the needs. The use case is to send
transform.xyz=somevalue to Metro.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D60155757
fbshipit-source-id: 006d5ff2e3f14634fb39d44b390f30da479b1faa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45621
This allows the iOS runtime to pass additional options to Metro. Each app can
decide what to send based on the needs. The use case is to send
`transform.xyz=somevalue` to Metro.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D60143663
fbshipit-source-id: 3e35a01a0ee121096d3a5cf0547e8e0ebf77f8ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45624
Must have forgot to add this functionality in, since it was just using a Rect for the clear region. This uses the proper rounded path.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D60147035
fbshipit-source-id: 3eebb2c4a56e4dfc957213e54f3d2de2c966082b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45622
The rest of these props setters opts to use `needsInvalidateLayer`, not `_needsInvalidateLayer` the latter of which is a instance variable. This change no effect since we set `_needsInvalidateLayer` to the or of both below, but we should be consistent with the rest of the logic here.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D60144215
fbshipit-source-id: b4b863d964a688c1cb9f6fada626d390681d1542
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45620
This does not really depend on anything in the layer. It is just a prop on the layer itself, so we can just set it in place. This pattern already happens for things like transform: https://fburl.com/code/0bhsdlcy
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D60142154
fbshipit-source-id: 52ee0e1e6eacf3bba005a727a5a4325a5cc6d338
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45613
We had a bug where box shadows were not getting cleaned up. The fix here is easy - just call `[_boxShadowLayer removeFromSuperView]`. Previously we were just setting this layer to nil, which does not do the job.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D60137528
fbshipit-source-id: 310df944f63ffc73ee5fe938cfb5a48674f997ab
Summary:
## Context
During TW Bloks testing, I frequently encounter the issue of a page not loading. After investigating further, I discovered that for one XOCReactNativeHost, there are multiple instances of ReactInstanceManager created. One of them is properly initialized with XOCLoginActivity, while the other one is not initialized and its activity is null.
When calling ReactContext onHostResume, there is a small chance that the ReactInstanceManager with a null activity will be used, resulting in a "no activity" issue.
After analyzing the construction call stack of ReactInstanceManager, it appears that there is a race condition in the function of ReactNativeHost.getReactInstanceManager https://fburl.com/code/kh6o84m9.
I noticed that two threads are calling this function simultaneously, which can lead to the creation of two instances despite the `mReactInstanceManager == null check`, as it is not within a synchronized statement.
An example of one ReactNativeHost with multiple ReactInstanceManagers can be found at https://fburl.com/code/kh6o84m9.
{F1768111631}
The following are the call stack to create the ReactInstanceManagers, the line number may have slightly shift from the prod code because of debugging info.
P1490866855
P1490869412
## About this diff
Added synchronized lock to the checking of `mReactInstanceManager == null` and make mReactInstanceManager as volatile to avoid creating duplicated instance.
## Changelog:
[Android] [Fixed] - Made several methods in ReactNativeHost.java thread-safe to avoid race conditions
bypass-github-export-checks
Reviewed By: javache
Differential Revision: D60088120
fbshipit-source-id: a4c1970bb54c7395dbfc3282d02bd66d9dc95df9
Summary:
This just fixes a warning in scripts/releases-ci/__tests__/publish-updated-packages-test.js that the CI is firing on every PR
## Changelog:
[INTERNAL] - Fix warning on scripts/releases-ci/__tests__/publish-updated-packages-test.js
Pull Request resolved: https://github.com/facebook/react-native/pull/45643
Test Plan: CI
Reviewed By: blakef
Differential Revision: D60170227
Pulled By: cortinico
fbshipit-source-id: 5889f7dd530cc00651d683001e1f2624bd79c27e
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/45593
I'm guessing either there is a race condition between Github removing cache entries when we're over budget OR there is an eventual consistency issue between reported cache entries and their removal. Either way, this job is best efforts. If a entry targetted for removal isn't there, great.
This change prevents the job from stopping if an entry no longer exists.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D60106847
fbshipit-source-id: 252bba7bb0bbb91d279f06a39301491332cd5ace
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/45589
I don't know why, but we had some CCI leftovers in the repo.
This cleans them up!
## Changelog:
[Internal] - Remove CCI leftovers
Reviewed By: cortinico
Differential Revision: D60048949
fbshipit-source-id: 08792abd53ba919a7afc0922d6f7c98cc9c4544e
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
yakupozbaydar
Jan Jaworski
Miguel Daipré
Ömer Esmer
David Vacca
Kevin Gozali
Alex Hunt
Joe Vilches
Jack Su
Nicola Corti
Oskar Kaczmarzyk
Dan Melnic
Ramanpreet Nara
Jakub Piasecki
Janic Duplessis
Dong-Hwan Kim
Blake Friedman
bufgix
gustavoabel
Rubén Norte
D N
Riccardo Cipolleschi
Samuel Susla
Ruslan Lesiutin
wh201906
CHEN Xian-an