Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49022
These modules support the in-app Inspector Overlay.
Breaking change that's unlikely to hit any users. Unreferenced by Expo.
Changelog:
[General][Breaking] Move `Libraries/Inspector/` modules to `src/private/`
Reviewed By: cortinico
Differential Revision: D68781896
fbshipit-source-id: 8fcd72d56684319019f64a375c2e2ef317a47c13
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49010
Changelog: [internal]
This adds a stub method for `ReactNativePrivateInterface.createPublicRootInstance`, which just returns `null` for now, so we can synchronize the React renderer that will try to use it to create root instances.
Initially, this will not do anything and React will just pass the `null` value around. When we implement the document API, we will return a proper instance and React will pass it to `createPublicInstance` so we can link things at runtime.
Reviewed By: javache
Differential Revision: D68561173
fbshipit-source-id: 632a7c3523910059a1f63f35b5f0f52f5660a961
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49009
Changelog: [internal]
Native APIs so far have returned instance handles from React to reference nodes in the rendered UI tree, but now that we're adding support for the document API, this isn't sufficient to represent all types of nodes. Both for the document and for its `documentElement`, we don't have an instance handle from React that links to the node, but we're going to represent that differently.
This is a refactor so the existing methods use a mostly opaque `NativeNodeReference` type so we can implement it as a union of React instance handles and the future types we're going to introduce to support document.
Reviewed By: javache
Differential Revision: D67704855
fbshipit-source-id: 0568143d9ce39be65986e1a4b92fdaebd79e4f66
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49008
Changelog: [internal]
We're modifying some core APIs in the RN render in following diffs, so this adds a simple benchmark as a safety mechanism to verify those don't regress performance significantly.
Reviewed By: yungsters
Differential Revision: D68772175
fbshipit-source-id: 3bc446e68495dc04590b613297baa00589fb5f8d
Summary:
The `maxFontSizeMultiplier` prop for `Text` and `TextInput` was not handled in Fabric / New Architecture as documented in https://github.com/facebook/react-native/issues/47499.
bypass-github-export-checks
## Changelog:
[GENERAL] [FIXED] - Fix `maxFontSizeMultiplier` prop on `Text` and `TextInput` components in Fabric / New Architecture
Pull Request resolved: https://github.com/facebook/react-native/pull/47614
Test Plan:
I have not added any automated tests for this change but try to do so if requested. I have however added examples to RN Tester for both the Text and TextInput components, as well as compared the behaviour with Paper / Old Architecture. Both on version 0.76.
Noticed now I didn't do exactly the same steps in both videos, oops! Be aware that reapplying changes made in the Settings are currently half-broken on the new architecture, thus I'm restarting the app on Android and iOS. But this issue is unrelated to my changes. I've tested on main branch and it has the same issue.
Here are comparison videos between Paper and Fabric on iOS *after* I've made my fix.
### Text
| Paper | Fabric |
| ------------- | ------------- |
| <video src="https://github.com/user-attachments/assets/f4fd009f-aa6d-41ab-92fa-8dcf1e351ba1" /> | <video src="https://github.com/user-attachments/assets/fda42cc6-34c2-42a7-a6e2-028e7c866075" /> |
### TextInput
| Paper | Fabric |
| ------------- | ------------- |
| <video src="https://github.com/user-attachments/assets/59b59f7b-25d2-4b5b-a8e2-d2054cc6390b" /> | <video src="https://github.com/user-attachments/assets/72068566-8f2a-4463-874c-45a6f5b63b0d" /> |
Reviewed By: Abbondanzo
Differential Revision: D65953019
Pulled By: cipolleschi
fbshipit-source-id: 90c3c7e236229e9ad9bd346941fafe4af8a9d9fc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49032
Add a native API to validate the RuntimeScheduler has no pending tasks, and automatically validate after every test that there's no pending tasks left to execute.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D68797481
fbshipit-source-id: dbbef894a57bd29eb5a033ac8aaeedef770dcba2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49030
Overwriting another RawProps object via `operator=` is rarely what we want, and these objects should be considered immutable once constructed.
This will catch issues such as D68633985
Changelog: [General][Changed] Removed `RawProps::operator=`
Reviewed By: sammy-SC
Differential Revision: D68797484
fbshipit-source-id: 766a65db1dbf4485c78007f8f69cc9426d27a943
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49029
This was never being compiled, because we didn't import the header that set `RN_DEBUG_STRING_CONVERTIBLE`
Will look at enabling `-Wundef` to catch these.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D68797482
fbshipit-source-id: 6a01192c799903b6f956f9b0acea94bd93183f3b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49033
Those methods are not used at all in the codebase, let's clean them up.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D68826893
fbshipit-source-id: 36e2f0ae247ed72305c1d9d346c6cf32cef6f8f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49034
This class was still in Java. I'm converting it to Kotlin + I'm making it internal.
As this class was inside the `com.facebook.react.internal.turbomodule.core` package,
we don't consider this a breaking change.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D68826892
fbshipit-source-id: b1f7aea984ab333faea66a9e8ccbb1492767333e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49024
## Motivation
Modernising the RN codebase to allow for modern Flow tooling to process it.
## This diff
- Migrates files in `Libraries/Lists/*.js` to use the `export` syntax.
- Updates deep-imports of these files to use `.default`
- Updates the current iteration of API snapshots (intended).
Changelog:
[General][Breaking] - Deep imports to modules inside `Libraries/Lists` with `require` syntax may need to be appended with '.default'.
Reviewed By: huntie
Differential Revision: D68783945
fbshipit-source-id: 7563155254fed40b6fe7d280d9e040ea24a5c870
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49007
# Changelog: [Internal]
Before sending `Tracing.start`, CDT will also send `Debugger.disable`.
You don't want to hit your breakpoints when you are profiling an appplication, this is by design.
We won't just delegate this to Hermes to handle. We will explicitly check that this condition is satisfied on React Native side. This is done to avoid regression in case the implementation details will change on CDT side.
Later in D68414421, we will also check that samples JavaScript stack don't contain debugger frames. This is necessary to distinguish garbage collector frames from debugger frames, which share the same type in Hermes VM - "Suspend".
We need garbage collector frames. If debugger frame was found we would throw an error, because this is unexpected after Debugger domain was disabled.
Right now Hermes is not disabling local VM Debugger on `Debugger.disable` method - this is a known bug, which I am addressing in a stack from D68772900.
Reviewed By: huntie
Differential Revision: D68776863
fbshipit-source-id: 4346ac5eb850578265a179b5fd687539ae7d15bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48988
The only unitless `<length>` value allowed is `0`, so most of the examples in the `processBoxShadow` unit tests are parse errors on web 🫠. Lets update the tests, and disallow these invalid values.
Changelog:
[General][Breaking] - Disallow invalid unitless lengths in box shadows
Reviewed By: jorge-cab
Differential Revision: D68740553
fbshipit-source-id: ea935819f773c5d516dd9b3367e5d2c808941c28
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48984
Noticed this in conjunction with another change, that I misinterpreted the ratio spec a bit. Ratios with a part less than zero are parse errors, while degenerate ratios are not (Chrome and Firefox both treat like this).
Removing usage of visitorless `consumeComponentValue()` here in preparation for next diff.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D68733519
fbshipit-source-id: 9afc7b7295b067a3e1469e2f80f5c9a6bea41fae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49027
Make constants more specific to `METAHash` (avoid potential conflicts) and unify the APIs with a shared attribute definition (will be used to mark these APIs as unavailable from Swift).
## Changelog:
[iOS] [Changed] - Change prime constants to have prefix in order to avoid any potential conflicts
Reviewed By: adamjernst
Differential Revision: D68790450
fbshipit-source-id: 69c8b73063cf57d6a4ec25f6cd52a906c77694f0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49000
Just found those nits around while looking at the codebase.
This clears things out and should have no runtime impact.
Changelog:
[Internal] [Changed] -
Reviewed By: mdvacca
Differential Revision: D68768384
fbshipit-source-id: bd3a30f1792a6f662d1f5b25855c89b6d43e72bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48650
## Motivation
Modernising the RN codebase to allow for modern Flow tooling to process it.
## This diff
- Migrates the `Libraries/ReactNative/*.js` files to use the `export` syntax.
- Updates deep-imports of these files to use `.default`
- Updates the current iteration of API snapshots (intended).
Changelog:
[General][Breaking] - Deep imports to modules inside `Libraries/ReactNative` with `require` syntax need to be appended with '.default'.
Reviewed By: huntie
Differential Revision: D68109193
fbshipit-source-id: 3444bf6b2152f7ed72d2923149a10041d718aaf0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49001
In {D42973408}, `Debugger.scriptParsed` was tweaked to be intercepted in `inspector-proxy`, which:
1. Rewrote the `sourceMapURL` to be relative to debugger.
2. Attempted to fetch the contents of the source map from `sourceMapURL` after re-writing again to a server-relative URL, and if successful replaced `sourceMapURL` with a base64 data URL.
1 is still needed until we have `Network.loadNetworkResource`, but 2 was only needed for frontends that did not support http fetch, and is not needed with Fusebox.
Changelog: [General][Changed] `Debugger.scriptParsed` now includes the field `sourceMapURL` as a (rewritten) remote url as opposed to base64 data url
Reviewed By: robhogan
Differential Revision: D68708899
fbshipit-source-id: 95242582c79ce4e9a573d4a3e639b0dc3290869e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49004
This just converts yet another class to Kotlin.
Changelog:
[Internal] [Changed] -
Reviewed By: tdn120
Differential Revision: D68772336
fbshipit-source-id: 428cb3a0d54bf7a22f0e4eb07268cdc27ef6f2c3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48905
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling.
## This diff
- Updates `Libraries/StyleSheet/processColorArray.js` to use `export` syntax.
- Appends `.default` to requires of the changed files.
- Updates test files.
- Updated View Config codegen (requires an MSDK bump).
- Updates the public API snapshot *(intented breaking change)*
Changelog:
[General][Breaking] - Files inside `Libraries/Text`, `Libraries/Share` and `Libraries/Settings` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: robhogan
Differential Revision: D68564304
fbshipit-source-id: 2fbd058be1a715cccfce4f2a68146118d8ac66ad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48807
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling.
## This diff
- Updates a handful of components in `Libraries/Components` to use `export` syntax
- `export default` for qualified objects, many `export` statements for collections (determined by how it's imported)
- Appends `.default` to requires of the changed files.
- Updates test files.
- Updates the public API snapshot (intented breaking change)
Changelog:
[General][Breaking] - Files inside `Libraries/Components` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: huntie
Differential Revision: D68436127
fbshipit-source-id: e3496fe69d66932dd4ed82f41d810f3ef1f850f5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49003
Changelog: [internal]
I was adding a benchmark for rendering thousands of views and it was surprisingly fast, until I realized I wasn't wrapping the call to `root.render` in `runTask`, which means the benchmark wasn't really doing the rendering, only scheduling a microtask that was never executed.
This is a safety mechanism to prevent those mistakes.
Reviewed By: sammy-SC
Differential Revision: D68771170
fbshipit-source-id: 5bd8e6ba9e1168db2320572c99b3a01ebd6aeeed
Summary:
This is another attempt at fixing the Android HMR client for HTTPS proxied Metro instances. The previous one unintentionally [caused the following error](https://github.com/facebook/react-native/pull/48970#issuecomment-2617047184):
```
java.lang.AssertionError: Method overloading is unsupported: com.facebook.react.devsupport.HMRClient#setup
```
This PR removes the overloading, and only adds the `scheme` property as a parameter to the existing `.setup` method. Aligning with the exact behavior we have on iOS.
The alternative fix, which should NOT be backward breaking (if this is) - is to move this "infer the protocol from the bundle URL" to the JS side of the HMR client. Where we don't just always default to `http`, but instead default to `https IF port === 443, otherwise http`. It's a bit more hacky, but shouldn't cause any other issues. _**Ideally**_, we have the same working behavior on both Android and iOS without workarounds.
<details><summary>Alternative workaround</summary>
See [this change](https://github.com/facebook/react-native/compare/main...byCedric:react-native:patch-2).
<img width="1179" alt="image" src="https://github.com/user-attachments/assets/47c365bc-6df8-43e6-ad7d-5a667e350cd4" />
</details>
See full explanation on https://github.com/facebook/react-native/issues/48970
> We've noticed that the HMR on Android doesn't seem to be connecting when using a HTTPS-proxied Metro instance, where the proxy is hosted through Cloudflare. This is only an issue on Android - not iOS - and likely caused by the HMR Client not being set up properly on Android.
>
>- On Android, we run `.setup('android', <bundleEntryPath>, <proxiedMetroHost>, <proxiedMetroPort>, <hmrEnabled>)` in the [**react/devsupport/DevSupportManagerBase.java**](https://github.com/facebook/react-native/blob/53d94c3abe3fcd2168b512652bc0169956bffa39/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/devsupport/DevSupportManagerBase.java#L689-L691) file.
>- On iOS, we run `[self.callableJSModules invokeModule:@"HMRClient" method:@"setup" withArgs:@[ RCTPlatformName, path, host, RCTNullIfNil(port), @(isHotLoadingEnabled), scheme ]];` in the [**React/CoreModules
/RCTDevSettings.mm**](https://github.com/facebook/react-native/blob/53d94c3abe3fcd2168b512652bc0169956bffa39/packages/react-native/React/CoreModules/RCTDevSettings.mm#L488-L491) file.
>
>Notice how Android does not pass in the scheme/protocol of the bundle URL, while iOS actually does? Unfortunately, because the default protocol (`http`) mismatches on Android when using HTTPS proxies, we actually try to connect the HMR client over `http` instead of `https` - while still using port 443 - which is rejected by Cloudflare's infrastructure even before we can redirect or mitigate this issue. And the rejection is valid, as we basically try to connect on `http://<host>:443` (the source URL is `https`, so the port is infered as `443`).
>
>This change adds scheme propagation to Android, exactly like we do on iOS for the HMR Client.
## Changelog:
[ANDROID] [FIXED] Pass the bundle URL protocol when setting up HMR client on Android
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/48998
Test Plan:
See full explanation on https://github.com/facebook/react-native/issues/48970
> It's a little bit hard to test this out yourself, since you'd need a HTTPS-based proxy and reject HTTP connections for HTTPS/WSS Websocket requests.
>
>You can set this up through:
>- `bun create expo@latest ./test-app`
>- `cd ./test-app`
>- `touch .env`
>- Set `EXPO_PACKAGER_PROXY_URL=https://<proxied-metro-hostname>` in **.env**
>- Set `REACT_NATIVE_PACKAGER_HOSTNAME=<proxied-metro-hostname>` in **.env**
>- `bun run start`
>
>Setting both these envvars, the bundle URL in the manifest is set to `https://...` - which triggers this HMR issue on Android. You can validate the **.env** setup through:
>
>```bash
>curl "http://localhost:8081" -H "expo-platform: android" | jq .launchAsset.url
>```
>
>This should point the entry bundle URL towards the `EXPO_PACKAGER_PROXY_URL`.
Reviewed By: cortinico
Differential Revision: D68768351
Pulled By: javache
fbshipit-source-id: 49bf1dc60f11b2af6e57177141270632d62ab564
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48940
The PerformanceObserver (marks and measures) example clears it's output each time a new PerformanceObserver event fires, which makes it not particularly useful.
This change makes it so the output is only updated if a non-empty list of performance events is observed.
## Changelog
[Internal]
Reviewed By: rubennorte
Differential Revision: D68634361
fbshipit-source-id: 71b97e1c66aabd090cae63d55c8fa0a425d0c2f4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48931
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling
## This diff
- Updates files in Libraries/Inspector to use `export` syntax
- Appends `.default` to requires of the changed files.
- Updates the public API snapshot (intented breaking change)
Changelog:
[General][Breaking] - Files inside `Libraries/Inspector` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: robhogan
Differential Revision: D68629285
fbshipit-source-id: ee0904ea5e8f9389aecfb197d05225c88137fb08
Summary:
Currently, the class OkHttpClientProvider is still in Java. Adding some tests before migrating it to Kotlin
## Changelog:
[INTERNAL] - Add OkHttpClientProvider tests
Pull Request resolved: https://github.com/facebook/react-native/pull/48958
Test Plan:
```bash
./gradlew :packages:react-native:ReactAndroid:test -Dtest.single=com.facebook.react.modules.network
```
Reviewed By: javache
Differential Revision: D68706173
Pulled By: cortinico
fbshipit-source-id: 7b4b1cbe17ff39d3775075682dcb8d253892e062
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48995
This change adds an extra parameter to the codegen script that allow our users to trigger codegen for Apps or for Libraries.
When running codegen for Apps, we have to generate some extra files that are not needed by the Libraries. This is causing issues to our library maintainers and this change will provide more flexibility in the DevX of libraries.
The default value is App, so if the new parameter is not passed, nothing will change in the current behavior.
## Changelog:
[iOS][Added] - Add the `source` parameter to generate-codegen-artifacts to avoid generating files not needed by libraries.
Reviewed By: cortinico
Differential Revision: D68765478
fbshipit-source-id: 8030b4472ad4f5058e58b1c91089de5122a4f60a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48934
This class is publicly exposed but effectively unused at all (neither internally, nor externally).
I'm removing it as this should not affect anyone.
Changelog:
[Android] [Breaking] - Removed `RuntimeConfig` class for Hermes which was unused.
Reviewed By: tdn120
Differential Revision: D68631945
fbshipit-source-id: 6a62ccda9e62f4bae650c11bc17a95efc8c88baf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48980
Changelog: [internal]
This will be properly removed soon, but disabling for now to avoid showing up in all PRs.
Reviewed By: cortinico
Differential Revision: D68719573
fbshipit-source-id: 6a631ba2556f1399d0ade52f19b79f5a3212e007
Summary:
Fixes https://github.com/facebook/react-native/issues/37801
This PR fixes the system bars visibility not being in sync as with the activity it is displayed on.
Here I am also taking into account the feedback given in [this PR](https://github.com/facebook/react-native/pull/36854) which was also aiming to address this issue. Unfortunately, I tried in multiple ways to get this to work by simply extending the whole system bars behaviour in the dialog with the activity system bars behaviour but found out that that solution won't work as we [currently clear the flag "FLAG_NOT_FOCUSABLE"](https://github.com/facebook/react-native/blob/main/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/modal/ReactModalHostView.kt#L314) and unless we remove that line, extending the behaviour won't work. Removing that line is not an option as it would cause other side effects in the dialog itself.
With the above said, I ended up doing this in a more explicit way, by checking whether the status or navigation bars are hidden in the activity and then hiding then as well in the dialog or otherwise, similar as we are currently doing with the status bars appearance.
## Changelog:
[ANDROID] [FIXED] - Sync Modal system bars visibility with current activity
Pull Request resolved: https://github.com/facebook/react-native/pull/48516
Test Plan:
In order to test this, you need to trigger any method that hides or shows the system bars using `window.insetsController`. Here a very small example of it:
```kt
fun toggleSystemBarsVisibility(shouldHide: Boolean) {
val window = currentActivity?.window
val controller = window?.insetsController
if (shouldHide) {
controller?.hide(WindowInsets.Type.systemBars())
} else {
controller?.show(WindowInsets.Type.systemBars())
}
}
```
You can do this optionally from JS to make testing different cases easier. Below is a screen recording of how the solutions looks like:
<details>
<summary>Screen recording showcasing the solution in the test plan</summary>
https://github.com/user-attachments/assets/c497c1cb-5e65-4f31-98cc-aefd2d7b0339
</details>
Reviewed By: mdvacca, Abbondanzo
Differential Revision: D67906071
Pulled By: alanleedev
fbshipit-source-id: cbb2d15520d7729a9e9eafb5f5efb8d20d796c60
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48982
We were missing a conversion to px on the `getOutline()` function of `CompositeBackgroundDrawable` which led to incorrect elevation prop rendering
Changelog: [Android][Fixed] - Elevation prop on android has incorrect border-radius
Reviewed By: NickGerleman
Differential Revision: D68724947
fbshipit-source-id: b3a7a4919bfd7c60fac7c3d6e3ba760e3f74d190
Alex Hunt
Ian Elliott
Rubén Norte
Rickard Zrinski
Pieter De Baets
Mateo Guzmán
Jakub Piasecki
Nicola Corti
Iwo Plaza
Ruslan Lesiutin
Fabrizio Cucci
Nick Gerleman
Nolan O'Brien
zhongwuzw
Vitali Zaidman
Dawid Małecki
Cedric van Putten
Eric Rozell
VidocqH
Riccardo Cipolleschi
CHOIMINSEOK
Dmitry Rykun
Jorge Cabiedes Acosta