Summary:
This pull request resolves the issue https://github.com/facebook/react-native/issues/43452
Previously, when utilizing `contextMenuHidden`, the context menu wasn't entirely hidden as the "AutoFill" option remained visible. However, it's now possible to eliminate it using the menu builder.
## 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
-->
[IOS] [FIXED] - hide AutoFill from context menu when using `contextMenuHidden`
Pull Request resolved: https://github.com/facebook/react-native/pull/43468
Test Plan:
Manual tests in RNTester:
https://github.com/facebook/react-native/assets/39670088/dc0f828c-f613-412d-b560-f3b795dd3ffb
Reviewed By: javache
Differential Revision: D54902269
Pulled By: tdn120
fbshipit-source-id: e0f3d3b5a0817db1c072caf2f01648432c7d868d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43777
It's best to avoid mutex reentrancy, even when using "read" locks (i.e., std::shared_lock). Since we already have a read lock on the ShadowTree in `UIManager::setNativeProps_DEPRECATED`, we can avoid the reentrancy by grabbing ancestor node from the shadow tree instead of relying on a recursive call to ShadowTreeRegistry::visit
## Changelog
[GENERAL][FIXED] - Avoid ShadowTreeRegistry::mutex_ read lock reentrancy
Reviewed By: rubennorte
Differential Revision: D55640201
fbshipit-source-id: 7a5c6674d290ea280ab584ae734733f12a65f6f8
Summary:
This PR removes forward declaration of `loadSourceForBridge` methods from the RCTRootViewFactory as it was causing an issue on old architecture, where the RedBox wouldn't popup when metro wasn't running.
As stated by Kudo [here](https://github.com/reactwg/react-native-releases/issues/177):
> the problem was coming from the implementation
> https://github.com/facebook/react-native/blob/00725fadff28bb3c7fed65f208e647f0dab69e75/packages/react-native/React/CxxBridge/RCTCxxBridge.mm#L519-L540
>
> we should dynamically override loadSourceForBridge:onProgress:onComplete: and loadSourceForBridge:withBlock: in RCTRootViewFactory only when AppDelegate override it. one way to achieve this might be tricky that we may need to override respondsToSelector:.
>
> otherwise, we could just skip the loadSourceForBridge:onProgress:onComplete: and loadSourceForBridge:withBlock: support.
There is no straight forward solution to implement this without some _hacks_ so I'm removing this forward block for now.
## Changelog:
[IOS] [FIXED] - remove loadSourceForBridge in RCTRootViewFactory
Pull Request resolved: https://github.com/facebook/react-native/pull/43656
Test Plan: CI Green
Reviewed By: rshest
Differential Revision: D55485094
Pulled By: cortinico
fbshipit-source-id: 1e391e0795c3d99686f2805165f64a7715b013f6
Summary:
With D55574528 and D55623682 having landed concurrently, and the latter enabling warnings-as-errors for Kotlin files vs the former having one such warning, this caused a build breakage.
This diff fixes it.
Reviewed By: andrewdacenko
Differential Revision: D55636176
fbshipit-source-id: 781b8cf40a4e9aa8a3da3005d26dca975f146c09
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43706
Changelog: [internal]
Just a small improvement of the UI for the Performance API examples in RNTester.
Reviewed By: christophpurrer
Differential Revision: D55489933
fbshipit-source-id: a1fe4f4962227941827f02cf18a0d4685e18f006
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43701
Changelog: [internal]
We were defining an `UNDEFINED` type of entry that should never happen in practice and we were using unnecessarily to signal "no type" where an optional type would be more suitable. Most importantly, **we were incorrectly allocating a buffer for entries of this type**.
This removes that type and the unnecessary buffer.
Reviewed By: rshest
Differential Revision: D55478890
fbshipit-source-id: 145210a9c4e2614a342f2d913b9eb6b3d62f676f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43702
Changelog: [internal]
Just a minor refactor to use C++20 designated initializers in `PerformanceEntryReporter` and its tests, while removing unnecessary initialization for optional fields.
Reviewed By: rshest
Differential Revision: D55477745
fbshipit-source-id: a643adf7ae48df23c5c383420fd4c4dd550e1322
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43703
Changelog: [internal]
(internal because this API isn't available in OSS yet)
I found a bug in the current implementation of `performance.measure` where the API would use the first `mark` reported under a specific name instead of the last one (found it in the new example in RNTester in D55477746 that re-logs the marks every time we click on a button).
The root cause for this problem is that we were using `insert` from `std::unordered_set` to update the value, but `insert` doesn't modify the value if it's already present.
This fixes the issue by doing a lookup and removing the value prior to inserting it.
Reviewed By: rshest
Differential Revision: D55477743
fbshipit-source-id: e72aa784a936828db64b572988fe0acb2ad78214
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43704
Changelog: [internal]
Adding examples of the rest of APIs in `Performance`/`PerformanceObserver` starting with marks and measures.
Reviewed By: rshest
Differential Revision: D55477746
fbshipit-source-id: 965796b6a97dc527192093e3c93af837a4d5b714
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43752
Gentest tests started failing because Chrome changed behavior of overflowed align-content container. Spec says should fallback to "safe center", which is really just "start", instead of previous "center" behavior. This changes behavior accordingly.
There is one bit where I think we are doing the wrong thing wrt alignment of flex start vs start (which we don't support yet), but couldn't repro a failing chrome test.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D55617689
fbshipit-source-id: 08f23d198c75f2c2f51ccaa8795289e6e4a92cb8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43730
# Changelog:
[Internal] -
As in the title, converts corresponding type declarations in `react/devsupport/LogBox*.java` to Kotlin.
Reviewed By: NickGerleman
Differential Revision: D55574528
fbshipit-source-id: 56cf5de75d18cd73929cb7f0c9375a3f62e83574
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43755
This is another place where the OSS build went ahead of the internal source of truth, which has caused build breaks more than once.
This enables warnings as errors in `rn_android_library` for consistency. This is used for a couple libraries outside of ReactAndroid that might need fixup/suppression.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D55623682
fbshipit-source-id: 37da30c642de2c3d8390334a0d0bff365a4ed7a1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43754
Moves off of deprecated `DisplayMetrics.scaledDensity` API to builtin font scaling API, while still clamping to max multiplier using previous logic.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D55623674
fbshipit-source-id: 2668eea8dbd154cc046e2c515323ad66b289dc64
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43729
# Changelog:
[Internal] -
As in the title, converts corresponding type declarations in `react/uimanager/*Util.kt` to Kotlin.
Reviewed By: tdn120
Differential Revision: D55574531
fbshipit-source-id: 974234bd57c77e863aa723388e48ffc455e73a96
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43728
# Changelog:
[Internal] -
As in the title, converts corresponding type declarations in `react/uimanager/layoutanimation/*Type.kt` to Kotlin.
Differential Revision: D55574530
fbshipit-source-id: 8527b5c9b491435c60ed9c05092ffeccd7552f9c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43727
# Changelog:
[Internal] -
As in the title, converts this one particular Java file to Kotlin.
Reviewed By: arushikesarwani94
Differential Revision: D55574526
fbshipit-source-id: 04af5b870670a5560eaba7ab8c029c580032d09a
Summary:
Fix version checker not considering nightlies:
```
WARNING: You should run npx react-native@latest to ensure you're always using the most current version of the CLI. NPX
has cached version (0.74.0-nightly-20240214-b8ad91732) != current release (0.73.6)
```
## Changelog:
[GENERAL] [FIXED] - Fix version checker not considering nightlies
Pull Request resolved: https://github.com/facebook/react-native/pull/43712
Test Plan: On a recent nightly version, run any cli command.
Reviewed By: rshest
Differential Revision: D55525055
Pulled By: zeyap
fbshipit-source-id: 6dd08e30e542d9ddd191bf95c968a26c0cc14e4e
Summary:
Currently the react-native-gradle-plugin does not allow the "react" plugin extension to already exist when running its apply block. I had a use-case where I wanted to create a new gradle plugin which would take care of applying the react plugin including setting some of its options. Without the change in this PR, this would currently turn into a build failure.
## Changelog:
[ANDROID] [FIXED] - prevent error when the "react" extension was already created by another gradle plugin
Pull Request resolved: https://github.com/facebook/react-native/pull/43694
Reviewed By: rshest
Differential Revision: D55478611
Pulled By: zeyap
fbshipit-source-id: cc743a99cb72ed315d21c52597efd5ee92a3be62
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43677
Remove `RCT_ENABLE_LOADING_FROM_PACKAGER` from `RCTDefines`, as it is not referenced anywhere and does nothing.
Changelog: [Internal]
Reviewed By: hoxyq, realsoelynn
Differential Revision: D55421282
fbshipit-source-id: ae29a8a421a6cc23d863b489eae2175392f684cd
Summary:
## Context
Prior, ReactContext used to implement bridge logic.
For bridgeless mode, we created BridgelessReactContext < ReactContext
## Problem
This could lead to failures: we could call bridge methods in bridgeless mode.
## Changes
Primary change:
- Make all the react instance methods inside ReactContext abstract.
Secondary changes: Implement react instance methods in concrete subclasses:
- **New:** BridgeReactContext: By delegating to CatalystInstance
- **New:** ThemedReactContext: By delegating to inner ReactContext
- **Unchanged:** BridgelessReactContext: By delegating to ReactHost
## Auxiliary changes
This fixes ThemedReactContext in bridgeless mode.
**Problem:** Prior, ThemedReactContext's react instance methods did not work in bridgeless mode: ThemedReactContext wasn't initialized in bridgeless mode, so all those methods had undefined behaviour.
**Solution:** ThemedReactContext now implements all react instance methods, by just forwarding to the initialized ReactContext it decorates (which has an instance).
Changelog: [Android][Removed] Delete ReactContext.initializeWithInstance(). ReactContext now no longer contains legacy react instance methods. Please use BridgeReactInstance instead.
---
Reviewed By: fkgozali
Differential Revision: D55505416
fbshipit-source-id: ce1e3ab379eb788d26130dd44a66544aada3db02
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43697
Currently, messages from a device are handled by async handlers added to a promise chain.
If a handler rejects, the end of the chain becomes a rejected promise, picked up only asynchronously by Metro's global `unhandledRejection` handler.
This triggers a warning from Node.js, and worse, prevents any `then()` callback chained by subsequent messages from being invoked at all.
Handlers *should* attempt to gracefully deal with errors (as we do with source map fetching errors, for example), but this diff adds a catch-all fallback for anything we might've missed (in this case, a frontend socket disconnecting while we're busy fetching a source map). Errors are caught and logged to EventReporter.
**To follow**: Gracefully handle socket disconnections while an async handler is working or queued.
Changelog:
[General][Fixed] Inspector proxy: prevent errors proxying a device message from blocking the handler queue or spamming logs.
Reviewed By: EdmondChuiHW
Differential Revision: D55482735
fbshipit-source-id: bb726218495e105f9cb4f723a1d110c9815abdef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43599
iOS E2E tests non-deterministic rendering happens around examples with a border set to `StyleSheet.hairlineWidth`. That value has special subpixel math, that doesn't seem to render consistently on iOS (this is its own bug).
To unblock adding some new E2E iOS TextInput tests, this removes usage of `hairlineWidth` in styles, and more generally, tries to unify TextInput styles in the examples.
This will break a whole bunch of RNTester Jest E2E baselines on different apps, which I will update from land-time runs or after continuous builds are available for different endpoints.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D55213090
fbshipit-source-id: 6d81b9355adc538a3ade6f50ef93c3ca08782ae7
Summary:
Stacked on top of #28498 for test fixes.
### Don't Rethrow
When we started React it was 1:1 setState calls a series of renders and
if they error, it errors where the setState was called. Simple. However,
then batching came and the error actually got thrown somewhere else.
With concurrent mode, it's not even possible to get setState itself to
throw anymore.
In fact, all APIs that can rethrow out of React are executed either at
the root of the scheduler or inside a DOM event handler.
If you throw inside a React.startTransition callback that's sync, then
that will bubble out of the startTransition but if you throw inside an
async callback or a useTransition we now need to handle it at the hook
site. So in 19 we need to make all React.startTransition swallow the
error (and report them to reportError).
The only one remaining that can throw is flushSync but it doesn't really
make sense for it to throw at the callsite neither because batching.
Just because something rendered in this flush doesn't mean it was
rendered due to what was just scheduled and doesn't mean that it should
abort any of the remaining code afterwards. setState is fire and forget.
It's send an instruction elsewhere, it's not part of the current
imperative code.
Error boundaries never rethrow. Since you should really always have
error boundaries, most of the time, it wouldn't rethrow anyway.
Rethrowing also actually currently drops errors on the floor since we
can only rethrow the first error, so to avoid that we'd need to call
reportError anyway. This happens in RN events.
The other issue with rethrowing is that it logs an extra console.error.
Since we're not sure that user code will actually log it anywhere we
still log it too just like we do with errors inside error boundaries
which leads all of these to log twice.
The goal of this PR is to never rethrow out of React instead, errors
outside of error boundaries get logged to reportError. Event system
errors too.
### Breaking Changes
The main thing this affects is testing where you want to inspect the
errors thrown. To make it easier to port, if you're inside `act` we
track the error into act in an aggregate error and then rethrow it at
the root of `act`. Unlike before though, if you flush synchronously
inside of act it'll still continue until the end of act before
rethrowing.
I expect most user code breakages would be to migrate from `flushSync`
to `act` if you assert on throwing.
However, in the React repo we also have `internalAct` and the
`waitForThrow` helpers. Since these have to use public production
implementations we track these using the global onerror or process
uncaughtException. Unlike regular act, includes both event handler
errors and onRecoverableError by default too. Not just render/commit
errors. So I had to account for that in our tests.
We restore logging an extra log for uncaught errors after the main log
with the component stack in it. We use `console.warn`. This is not yet
ignorable if you preventDefault to the main error event. To avoid
confusion if you don't end up logging the error to console I just added
`An error occurred`.
### Polyfill
All browsers we support really supports `reportError` but not all test
and server environments do, so I implemented a polyfill for browser and
node in `shared/reportGlobalError`. I don't love that this is included
in all builds and gets duplicated into isomorphic even though it's not
actually needed in production. Maybe in the future we can require a
polyfill for this.
### Follow Ups
In a follow up, I'll make caught vs uncaught error handling be
configurable too.
---------
DiffTrain build for commit https://github.com/facebook/react/commit/6786563f3cbbc9b16d5a8187207b5bd904386e53.
Changelog:
[Internal]
Reviewed By: kassens
Differential Revision: D55408481
Pulled By: yungsters
fbshipit-source-id: 598aa306369e21cb3e93ad6041a87bfbaa9eef9e
Co-authored-by: Ricky Hanlon <rickhanlonii@gmail.com>
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43686
Under Node 20, the use of `new Buffer(string)` is deprecated and logs a warning. This replaces it with the recommended `Buffer.from(string)`.
Changelog:
[General][Fixed] FIx "Buffer() is deprecated" warning from debugger proxy.
Reviewed By: huntie
Differential Revision: D55472025
fbshipit-source-id: 8b5af9e2d7e026cbdf6aa68f71ff0f856fb164db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43698
changelog: [internal]
RCTViewComponentView was missing isAccessibilityElement override. Here I add it and use contentView to determine if element is accessible.
Reviewed By: rubennorte
Differential Revision: D55483944
fbshipit-source-id: f29c82a42d17140ae421f27871a3bf6f7f36bc12
Summary:
## Context
Prior, ReactContext used to implement bridge logic.
For bridgeless mode, we created BridgelessReactContext < ReactContext
## Problem
This could lead to failures: we could call bridge methods in bridgeless mode.
## Changes
Primary change:
- Make all the react instance methods inside ReactContext abstract.
Secondary changes: Implement react instance methods in concrete subclasses:
- **New:** BridgeReactContext: By delegating to CatalystInstance
- **New:** ThemedReactContext: By delegating to inner ReactContext
- **Unchanged:** BridgelessReactContext: By delegating to ReactHost
## Auxiliary changes
This fixes ThemedReactContext in bridgeless mode.
**Problem:** Prior, ThemedReactContext's react instance methods did not work in bridgeless mode: ThemedReactContext wasn't initialized in bridgeless mode, so all those methods had undefined behaviour.
**Solution:** ThemedReactContext now implements all react instance methods, by just forwarding to the initialized ReactContext it decorates (which has an instance).
Changelog: [Android][Removed] Delete ReactContext.initializeWithInstance(). ReactContext now no longer contains legacy react instance methods. Please use BridgeReactInstance instead.
Reviewed By: javache
Differential Revision: D53145010
fbshipit-source-id: 2405bc24afb00864117d3c504fc9c4cbffd7203a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43696
This just sets explicitApi to true for every module inside ReactAndroid
Changelog:
[Internal] [Changed] - Flip explicitApi to True for everyone
Reviewed By: tdn120
Differential Revision: D55478674
fbshipit-source-id: c9aeba89ad5b0f88bca7fd480c6aa66e0152a456
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43699
This diff initializes `RELEASE_VERSION` with the value that is provided by the `get_react_native_version` job (it stores its output into `/tmp/react-native-version`).
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D55484988
fbshipit-source-id: f0b5bb473096f3691f50152beb3181a454916fdc