Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39084
The current behaviour of `jsi::ArrayBuffer::size` with Hermes is to
return the value of the `byteLength` property. While this is
superficially more consistent with the behaviour for `Array`, which
reads the length property, it is a problem in practice since the
`byteLength` property is easily overridden in JS, making it unsafe
to use when indexing into the backing storage.
While this is a behaviour change, it should be fine because:
1. This is already the behaviour with JSC (the newly added test also
runs against the JSC implementation) and also seems to be the behaviour
of Microsoft's [V8 implementation](https://github.com/microsoft/v8-jsi/blob/db1ca30d6e5d39ee3a88a9f81b258c3825735917/src/V8JsiRuntime.cpp#L1239C48-L1239C58).
2. The current behaviour is counterintuitive and likely to lead to
bugs.
Changelog: [Internal]
Reviewed By: tmikov
Differential Revision: D48226661
fbshipit-source-id: 043d60deeb9dc189705594415f4f262f7de1095a
Summary:
Removed deprecated function removeSubscription from the type of NativeEventEmitter, so that it lines up with its implementation. This is a fix for https://github.com/facebook/react-native/issues/39111 .
## 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] [Fixed] - Fix a type issue of NativeEventEmitter
Pull Request resolved: https://github.com/facebook/react-native/pull/39115
Test Plan: Not applicable
Reviewed By: NickGerleman
Differential Revision: D48573676
Pulled By: lunaleaps
fbshipit-source-id: e70c951e230e0d236e0bf0a1ba02b450bdc98ac5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39116
This changes updates the Glog pod to defines module.
This makes it easier to work with Glog using Swift and to work on React Native Modules
## Changelog:
[Internal] - Make Glog define modules
Reviewed By: dmytrorykun
Differential Revision: D48564026
fbshipit-source-id: 83bb45fa6387321d089528107517ffbf0874c70d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39078
Simplifies and hardens behaviour for detecting other processes / dev server instances when running `react-native start`.
- New flow:
- Exits with error message if port is taken by another process (*no longer suggests next port*).
- Exits with info message if port is taken by another instance of this dev server (**unchanged**).
- Continues if result unknown.
- *(No longer logs dedicated message for another RN server running in a different project root.)*
- This now checks if the TCP port is in use before attempting an HTTP fetch.
Previous behaviour: [`handlePortUnavailable`](https://github.com/react-native-community/cli/blob/734222118707fff41c71463528e4e0c227b31cc6/packages/cli-tools/src/handlePortUnavailable.ts#L8). This decouples us from some lower-level `react-native-community/cli-tools` utils, which remain reused by the `android` and `ios` commands.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D48433285
fbshipit-source-id: 7056001d5fe2f90faf52143f2777c9e2bdf0646e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39107
Augments D48466760 to report debugger commands (request/response pairs) through `EventReporter`. With the appropriate backend integration, this can help validate the correctness/completeness of the CDP implementation (in the client, proxy and server) and measure the latency of debugger commands - more accurately, the time between the proxy receiving a command from the client and receiving the corresponding response from the server.
Most of the new logic here is in the `DeviceEventReporter` class, which is responsible for associating responses with requests. Requests are kept in a buffer with a 10s TTL which serves as a timeout in case of an unresponsive server.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D48480372
fbshipit-source-id: 55360a14bbea05ef8ad1622e0d54f18b47483809
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39112
RNTester's `PROJECT_ROOT` should point to `packages/rn-tester` but for some reason it points to the `react-native` monorepo root.
Changelog: [iOS][Fixed] - RNTester's PROJECT_ROOT points to `packages/rn-tester`
Reviewed By: cipolleschi
Differential Revision: D48526552
fbshipit-source-id: 79047ddcbea96eb31f010a8f802aba8c6a2c403b
Summary:
During investigation of impact of PR https://github.com/facebook/react-native/pull/38706 on `reanimated` I found out that when:
- state reconciliation is turned on
- `progressState` in `ShadowTree::tryCommit` quite often returns a new pointer to updated shadow tree
- above happened due to `newState->getMostRecentStateIfObsolete()` returning precisely the same ptr as `newState` in `progressState`
- this is caused by calling `ShadowNodeFamily::setMostRecentState` with the same state as currently held and marking those states as obsolete
This PR adds additional check whether `ShadowNodeFamily::setMostRecentState` is called with the same `state` as currently set and skips setting obsolete flag if that happens.
## Changelog:
[INTERNAL][FIXED] Setting the same most recent state for ShadowNodeFamily, doesn't mark it as obsolete
Pull Request resolved: https://github.com/facebook/react-native/pull/39095
Test Plan: None
Reviewed By: cipolleschi
Differential Revision: D48526395
Pulled By: sammy-SC
fbshipit-source-id: f77cea2364611a42a3363285b4732f33aae8a0a7
Summary:
Migrate MyLegacyViewManager to Kotlin (https://github.com/facebook/react-native/issues/38825)
## Changelog:
[INTERNAL] [CHANGED] - Moved MyLegacyViewManager to Kotlin
<!-- 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/39014
Test Plan: Run `yarn && yarn android`
Reviewed By: rshest
Differential Revision: D48519780
Pulled By: cortinico
fbshipit-source-id: b43a2cfacad977c52b8552c464246b812de30855
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39059
## Context
RFC: Decoupling Flipper from React Native core: https://github.com/react-native-community/discussions-and-proposals/pull/641
## Changes
This change:
- Links the new `react-native/dev-middleware` endpoints into the recently migrated `react-native start` command.
- Adds `react-native/community-cli-plugin` (the migrated [`cli-plugin-metro`](https://github.com/react-native-community/cli/tree/main/packages/cli-plugin-metro)) as a dependency of `react-native`, and hooks in these versions of the `start`, `bundle`, and `ram-bundle` commands via `react-native.config.js`.
Functionally, this means that the new `/open-debugger` endpoint is available on the dev server started by `react-native start` (not yet linked into any UI).
After this PR is merged, the new `community-cli-plugin` package is "linked" and we can remove `cli-plugin-metro` from `react-native-community/cli`: https://github.com/react-native-community/cli/pull/2055.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D47226421
fbshipit-source-id: 123039961f93bd8183a32a2d3f30c447f7c0f132
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39097
Changelog:
[Internal][Added] - Created mechanism to have nested horizontal scrollviews (or flatlists/sectionlists) by prioritizing scrolling on deeper nested scrollviews which have the enableNestedScroll prop equal to true.
Reviewed By: NickGerleman
Differential Revision: D48504762
fbshipit-source-id: 1a6d01f68e142d99ea494e2b5630979c7be2ecce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39109
Changelog:
[Internal][Added] - Allowed metro to also receive incremental data payloads from the native side bit by bit, offloading memory to the JS side (which would have been used anyways when the final copy was done).
Reviewed By: motiz88
Differential Revision: D48449495
fbshipit-source-id: 8cb2b43c35cce28e4b82d3f0e993c0f6d5f9c008
Summary:
Changelog: [internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/39093
I was looking at Folly containers and found we were using folly::function. According to the compiler, we don't need it. It should fail during build time if its properties were needed.
Documentation for folly function: https://github.com/facebook/folly/blob/main/folly/docs/Function.md
Reviewed By: christophpurrer
Differential Revision: D48519164
fbshipit-source-id: 88002ca3a1302db2a397fc7f5e3cae354669a9ff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39094
We can construct the outer jsi::Object directly instead of going through `valueFromDynamic` for the whole thing.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D48519751
fbshipit-source-id: d3efd60472103ce7c9d13646d0a9bf4164bf73e2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39031
`UIScrollView` `contentOffset` is flow-relative, so `x` is relative to the right edge of the screen. This coordinate space disagrees with layout events, `scrollTo` coordinates, and other platforms.
This applies the same logic we use for inverting `scrollTo` coordinates to invert `contentOffset` in scroll events, in both Paper and Fabric. We then remove the iOS specific workaround we have in VirtualizedList.
I did not test `contentInset` as part of this, whose structure has explicit edges like `left` and `right`.
Changelog:
[iOS][Fixed] - Fix inverted `contentOffset` in scroll events in RTL
Reviewed By: rozele
Differential Revision: D48379915
fbshipit-source-id: 8a9cbb01608e79ef3b179a76fbe3997a0cd23845
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38539
We will use this example to:
- Showcase legacy module support in the TurboModule system in RNTester
- E2E test legacy module support in the TurboModule system
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D47529295
fbshipit-source-id: b98e315741bed7740c36997d706f48e375b0c815
Summary:
i just moved to the new react native 0.72.1 with the new Architecture and I encountered a problem when tried to archive my develop version(i have 2 Schemes one for prod and one for dev).
so i did some digging and got to the problem that was found in script file named "generate-artifacts-executor.js".
i found that after generating lib content into the temp directory(tmpOutputDir)
it copy all the content into the real output directory(iosOutputDir).
the problem was that the real output directory(iosOutputDir) containing the selected scheme name and mine was with backspace(AppTest Develop) so the cp -r command was failing.
in order to fix that i wrapped the real output directory(iosOutputDir) with double quotes.
Also updated the related test ("executeNodes with the right arguments") to include the double quotes.
## Changelog:
[GENERAL] [FIXED] - Add support to archive Schemes names with backspaces
Pull Request resolved: https://github.com/facebook/react-native/pull/39009
Test Plan:
1. After updating the related test ("executeNodes with the right arguments") to include the double quotes i run all tests by
run yarn test and yarn flow and All tests passed.
2. Also after i changed locally the script file in my project from the node_modules
i successfully Archived both my Schemes dev and prod (one with backspace and one without).
Reviewed By: cipolleschi
Differential Revision: D48414256
Pulled By: NickGerleman
fbshipit-source-id: 829440b33799251fe5ef1c0f83d0fdef7a1cc254
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39096
## React Native
Changelog:
[General][Changed]: Bump Jest version in the new project template from `^29.2.1` to `^29.6.3`
## Metro
[Internal]
Reviewed By: motiz88
Differential Revision: D48519694
fbshipit-source-id: 201f76402ac72da1f5c297a29a1212b167d1b7e4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39085
Adding arguments in systrace for event emitter event types. This is helpful to understand why sometimes JS render is triggered from native side.
Changelog:
[Internal] - Add event type information from native to js event emitter calls
Reviewed By: rshest
Differential Revision: D48448904
fbshipit-source-id: cbb4b86e781384d56205fec23931cd773e4a58a8
Summary:
When reloads fail, React Native currently just renders a blank screen.
We should provde some sort of feedback to the developer. Hence, this diff makes the RedBox show up.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D48335851
fbshipit-source-id: 0681cd40f8c83960f9133853481013765634f5cf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39000
Whenever React Native tears down (including on logout), we need to drop unconsumed Pre-rendering surfaces.
D45012714 initially implemented this change, but this diff wasn't complete: it would only drop unconsumed pre-rendered surfaces when ***the Facebook infra* initiated** React Native to tear down. But, React Native could initiate tear down **by iteself** (e.g: via an uncaught exception on the Native Modules thread).
## Changes
In this diff, make the React Manager support an onBeforeDestroy listener. Then, integrate these listeners into the teardown/reload algorithms. That way, no matter how React Native tears down, we **alwasy** drop unconsumed pre-rendered surfaces.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D48323647
fbshipit-source-id: 28f99500eea457b0e3c420fed28c434f8794ac23
Summary:
The new reload/create/destroy methods work by chaining tasks together.
This task chain has the type Task<ReactInstance>.
**The problem:** If any step in the chain fails, task.getResult() actually returns null - not the ReactInstance. Many steps in the existing reload() and destroy() task chains don't account for this case. So:
- The reload() and destroy() task chains sometimes swallow errors.
- Sometimes steps in the reload() and destroy() task chains don't execute: they use .successTask
This diff makes two changes:
1. Ensure each step **always** executes (i.e: use .continueWith vs .success)
2. Ensure each step first checks if the Task<ReactInstance> isn't faulted/cancelled. If the task is faulted/cancelled, a soft exception gets reported, and the current ReactInstance gets returned.
Changelog: [Internal
Reviewed By: mdvacca
Differential Revision: D48080779
fbshipit-source-id: 22f03ef1a54b538d01eeb5ecde6d82a84d32f1f8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38997
After React Native gets destroyed (e.g: via an exception), the ReactHost resets its current activity.
## Problem
React Native can display RedBoxes after React Native destruction (e.g: in the case of an exception).
Displaying RedBoxes requires the current activity, which gets nullified. So, the RedBox might not show up after destruction.
## Changes
This diff makes ReactHost keep a track of its last non-null activity in a WeakRef.
Then, the DevMenu just uses the last non-null activity to display RedBoxes (and everything else).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D48076893
fbshipit-source-id: 6baddf8f329c03efe92f93ef1bfc6eb9569c1b38
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38998
Instead of using the mActivity reference directly, let's just use getCurrentActivity() and setCurrentActivity().
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D48076896
fbshipit-source-id: d988deaf8778bf0e3726d13f96e9e6e480d8fdc0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38999
After React Native tears down, a RedBox can appear, prompting the user to reload.
**Problem:** After React Native reloads, the React Native screen wouldn't show up.
**Cause:** ReactContext.onHostResume() wasn't executed.
Why:
- React Native teardown moves the React manager into the **onHostDestroy()** state.
- During initialization, React Native only calls ReactContext.onHostResume(), if the React manager was *already* in the **onHostResume()** state.
https://www.internalfb.com/code/fbsource/[f82938c7cc9a0ee722c85c33d1027f326049d37c]/xplat/js/react-native-github/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/bridgeless/ReactHost.java?lines=924-925
**Question:** Why does React Native only call ReactContext.onHostResume(), **if the React manager was already in the onHostResume() state?**
In short, we want ReactContext.onHostResume() to be delayed until the user navigates to the first React Native screen. Please read the comments in the code to understand why.
## The fix
If we're initializing React Native during a reload, just always call ReactContext.onHostResume().
If React Native is reloading, it seems reasonable to assume that:
1. We must have navigated to a React Native screen in the past, or
2. We must be on a React Native screen.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D48076895
fbshipit-source-id: 6794105920ee30d62cebd745256bb5dea805e891
Summary:
During React Native teardown, we should stop all React surfaces. Otherwise, the app could crash with this error:
```
08-06 14:54:08.644 14843 14843 F DEBUG : Abort message: 'xplat/js/react-native-github/packages/react-native/ReactCommon/react/renderer/scheduler/Scheduler.cpp:171: function ~Scheduler: assertion failed (surfaceIds.empty() && "Scheduler was destroyed with outstanding Surfaces.")'
```
When can teardown occur? One case: an exception occurs on the NativeModules thread.
NOTE: This diff impacts the **new** Bridgeless mode lifecycle methods.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D47926966
fbshipit-source-id: 62be90eb49091773976dfb18db5c2a7c0668c382
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39021
Changelog: [Internal] - Refactor conditional pointer event emitting to the C++ layer
Some background: early on in the implementation of Pointer Events a concern was brought up that events related to hovering pointers could saturate the JS thread if they were fired all the time unconditionally, so as a mitigation we would check in native to see if listeners in the tree were listening for those events and only fire them if there were listeners.
Now since we're going to be moving some of the event derivation logic to the C++ layer we need to receive all the events — but recreate the conditional firing in the C++ layer so we can still avoid saturating the JS thread. That's what this diff does.
The only change I see being potentially contraversial is the fact that I needed a way to turn an EventTarget (the only information I receive regarding which node the event is firing on) to its cooresponding ShadowNode which I did in the method GetShadowNodeFromEventTarget. It essentially does the exact same thing the getNodeFromInternalInstanceHandle method in ReactNativePublicCompat.js, but in C++ against the JSI API. I don't know if there's a better way to do this but this was the best one I came up with that actually works.
(This is a second attempt at landing D48288752 which had to be backed out. It should be fine this time because of D48331909 which this diff now depends on)
Reviewed By: rozele
Differential Revision: D48322586
fbshipit-source-id: 7674c123e96ae71b18c8a3a780667ffaa2f25e7c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39091
Changelog: [Internal]
Adds a simple typed logging hook to `react-native/dev-middleware`. This is intended to allow integrators to receive events from the dev server, apply any relevant sampling/processing, and log them to a backend. (To be clear, the open source version of React Native does not and will not collect any data.)
WARNING: The API will evolve over the coming weeks/months and is *not guaranteed to be stable* - it might even break between patch releases.
Reviewed By: huntie
Differential Revision: D48466760
fbshipit-source-id: ed1e21fb0dac5d6199ff1ee26017a1d33d9b7d92
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38922
Changelog: [Internal]
This diff alows react-native to use its own copy of JSI from `ReactCommom/jsi` instead of consuming headers vendored with Hermes.
Reviewed By: NickGerleman
Differential Revision: D48152876
fbshipit-source-id: 89c7eaf899b5bfc262fbb06517db260abcc18592
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38920
Maven does not provide stable URLs for stored artifacts. Instead there can be a series of redirects for the actual download URL.
CocoaPods does not follow redirects when such URL is set as a `source` in a `podspec`. To mitigate that we download Hermes prebuild manually, and that set the `source` to that file.
This diff removes this manual download step, and utilizes `curl` to resolve redirects, and then assign final endpoint to `source[:http]` of the `hermes-engine.podspec`.
Changelog: [Internal] - Resolve redirects instead of manually downloading nightly Hermes.
Reviewed By: cipolleschi
Differential Revision: D48225199
fbshipit-source-id: d13f9ef79f7c89c317b854da1170ca8321823d8a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39061
We're suppressing JVM tests using BUCK which is causing misalignment between which tests we run on Buck vs Gradle.
Instead we should be using the Ignore annotation (which we already do) to decide which tests to skip, so that Buck can just pick all the Java/Kotlin file in this folder.
Changelog:
[Internal] [Changed] - Cleanup BUCK setup for our JVM tests
Reviewed By: cipolleschi
Differential Revision: D48433432
fbshipit-source-id: 31070ef848932aefa5d2710a8e11f97646e4b51c
Summary:
For some reason, the module registry is nil inside RCTDeviceInfo.
**Hypothesis:** DeviceInfo is outliving React Native teardown (somehow).
This diff adds additional logging inside RCTDeviceInfo so that we could better undersatnd the problem.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D48237716
fbshipit-source-id: 459306dab5cddd4da50ed767087b93e33085be67
Summary:
RCTExportedDimensions doesn't need access to the ModuleRegistry, or the bridge. It just uses those two things to get the fontScale.
We could make RCTExportedDimensions easier to understand, by making it do fewer things (i.e: computing the fontScale up front, and passing it into RCTExportedDimensions). Let's just do that.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D48237715
fbshipit-source-id: b3af648d88276846742d0e1192d33d180ee49dbb
Neil Dhar
Yupeng Li
Riccardo Cipolleschi
Alex Hunt
Moti Zilberman
Dmitry Rykun
Samuel Susla
Michał Mąka
imalgrab
Jesse Watts-Russell
fortmarek
Intl Scheduler
Lulu Wu
Pieter De Baets
Nick Gerleman
Ramanpreet Nara
yardenPhy
Vincent Riemer
Sam Zhou
Rob Hogan
Xin Chen
MJMoshiri
Nicola Corti