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
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48054
Web debugging should be fully removed as of recent, so lets remove some of the gunk that was powering it, and checks for that environment.
I did some string searches for the following:
* isAsyncDebugging
* debugRemotely
* isDebuggingRemotely
* isRemoteDebuggingAvailable
* WebSocketExecutor
* JavaJSExecutor
* ProxyJavaScriptExecutor
* RELOAD_APP_EXTRA_JS_PROXY
* getJSBundleURLForRemoteDebugging
* onReloadWithJSDebugger
* setRemoteJSDebugEnabled
* WebsocketJavaScriptExecutor
* createRemoteDebuggerBundleLoader
1. `expo-modules-core` exposes its own `isAsyncDebugging` by checking for `nativeCallSyncHook`, but does not depend on `DebugEnvironment`.
2. `expo-dev-menu` does read `isDebuggingRemotely` from `DevSettings`.
3. Realm does a check in Native using `objc_lookUpClass("RCTWebSocketExecutor")` but will gracefully handle `nil` if it does not exist
4. Some more usages (e.g. `onReloadWithJSDebugger`) in vendored packages of `expo-dev-launcher` for RN 0.74
I created an issue for Expo mentioning both here: https://github.com/expo/expo/issues/33371
Changelog:
[General][Breaking] - Remove some web debugging remnants
Reviewed By: huntie
Differential Revision: D66553934
fbshipit-source-id: deec382b1c8bda393fddb8682aa91b26afd9fbe3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48913
This brings us to parity with normalize-color, and is mostly similar to hsl, with the notable exception there is not a separate alpha variant, and only modern function syntax is supported. Again, I took the math from normalize-color, and sanity tested it against reference function provided by Color Spec.
I'm going to let that cap off color function support for now, and leave the rest as TODO.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D68594471
fbshipit-source-id: 95702d576e068655d34e52a714d38e4fd718bbc9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48912
The implementation of `hwb()` color functions added in https://github.com/facebook/react-native/pull/34600 is pretty flawed.
`hwb()` color functions do not allow comma delimited values. So most of the examples in the unit test here will fail to parse on web. Like `hsl()`, these should also allow numeric non-hue components (instead of just %), and angle values for hue (instead of just numbers), and this is also missing support for alpha values, though these are less dangerous compared to allowing and encouraging incorrect delimiters.
https://www.w3.org/TR/css-color-4/#the-hwb-notation
These were added for web compat, and the examples fail to parse on web, so I'm opting to just remove this incorrect support before implementing this more correctly in the Fabric CSS parser in next diff. I did not attempt to fix the other issues I discovered with the PR implementation in the last couple diffs, around mixing and matching syntax allowed in legacy/modern, along with allowing inconsistent delimiters.
Changelog:
[General][Breaking] - Remove incorrect hwb() syntax support from normalize-color
Reviewed By: lenaic
Differential Revision: D68591172
fbshipit-source-id: 36d670b096ae9fac4bc24938877ad083d4dd336a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48878
Creates a new `scheduleAnimatedCleanupInMicrotask` feature flag to experiment with deferring the `AnimatedProps` cleanup using the microtask queue.
This is different from the previous approach of deferring invocation of the completion callback, which impacted the timing of composite animations such as `Animated.parallel` and `Animated.sequence`, because we are deferring detaching the `AnimatedNode` graph instead. This will only impact the timing of completion callbacks as a result of invalidating `AnimatedProps` (either by passing in new `AnimatedValue` instances or unmounting the component).
This should minimally impact scheduling and have lower risk of user-visible behavior change because React already provides minimal guarantees around when updates are committed (and effects attached/detached).
This also enables us to significantly simplify the current convoluted dance we do to optimized around reference counting in the AnimatedNode graph.
Changelog:
[General][Changed] - When an Animated component is updated or unmounted, `AnimatedNode` instances will now detach in a microtask instead of synchronously in the commit phase of React. This will cause the completion callback of finished animations to execute after the commit phase instead of during it.
Reviewed By: rickhanlonii
Differential Revision: D68527096
fbshipit-source-id: 99346b8ddbf6a01725376c692b0351be679b9e89
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48975
After cutting 0.78-stable, we need to bump the monorepo packages to `0.79.0-main`
## Changelog:
[Internal] - Bump monorepo packages to `0.79.0-main`
Reviewed By: cortinico, huntie
Differential Revision: D68715005
fbshipit-source-id: cb5abbf05e8638683687be8d61d66b3037111572
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48973
changelog: [internal]
This test is broken, let's disable it until it is fixed.
Reviewed By: javache
Differential Revision: D68709385
fbshipit-source-id: f61b287ad7ef921dd26fa290cc7a484d0b550091
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48968
I've noticed we have a lot of `public` and `protected` modifiers for classes that are actually `internal`.
Those are unnecessary as the class itself is `internal` and there is no way to extend the visibility of single fields.
Changelog:
[Internal] [Changed] -
Reviewed By: mdvacca
Differential Revision: D68707255
fbshipit-source-id: 5b93d01dceba1b5031ac608e58ec898c1a1eaf51
Summary:
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` - which is rejected by Cloudflare's infrastructure even before we can redirect or mitigate this issue.
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/48970
Test Plan: 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.
Reviewed By: fabriziocucci
Differential Revision: D68711137
Pulled By: javache
fbshipit-source-id: 230c1c91c8189c0a109d20defe085966ac8f5721
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48922
Changelog: [internal]
This is a basic subclass of Event that allows setting custom values (as opposed to `Event` that is meant to be used as a superclass).
Reviewed By: yungsters
Differential Revision: D67804060
fbshipit-source-id: 9e140cc436f8e230f37275a74df23efd4841071b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48962
Changelog: [internal]
We moved away from private fields for `EventTarget` for performance, in favor of normal fields prefixed with underscore, but this would pollute the global scope when we make it extend `EventTarget`.
This refactors the implementation to use symbols for all properties to avoid that problem, leaving only `addEventListener` and `removeEventListener` as regular properties in the prototype.
Performance-wise this is neutral or a slight improvement according to the existing benchmark.
Reviewed By: javache
Differential Revision: D68672215
fbshipit-source-id: b329548efce6059ae2b9f33afa0719e057d3b8ba
Nicola Corti
Iwo Plaza
Ruslan Lesiutin
Nick Gerleman
Nolan O'Brien
zhongwuzw
Vitali Zaidman
Dawid Małecki
Rubén Norte
Cedric van Putten
Alex Hunt
Eric Rozell
Mateo Guzmán
VidocqH
Riccardo Cipolleschi
CHOIMINSEOK
Dmitry Rykun
Jorge Cabiedes Acosta
Pieter De Baets
Christoph Purrer
Tim Yung
Samuel Susla
Håkon Knutzen