Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38967
Changelog: [IOS][Added] - Now it is possible to build Hermes form local source directory. Just set REACT_NATIVE_OVERRIDE_HERMES_DIR to the path to that directory.
Known shortcoming: changes made to the Hermes source will not be reflected in the RN project. You should manually delete `Pods/hermes-engine` and rerun `pod install`.
Reviewed By: cipolleschi
Differential Revision: D48121314
fbshipit-source-id: 0389662396921bdf120d390de36a586c52eb47f1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38963
This diff refactors `hermes-utils.rb` in the following way:
- Explicitly define all the scenarios how `hermes-engine.podspec` can consume its source.
- Try to be explicit and verbose about when those scenarios take place.
- Split `compute_hermes_source` into two functions:
- `hermes_source_type` that determines the podspec source type.
- `podspec_source` that builds the podspec source based on the source type provided.
Also `hermes-engine.podspec` now uses source type returned by `hermes_source_type` instead of derived values `:git` and `:http`, which were not descriptive and granular enough.
This refactoring should make adding new cases and altering existing ones easier. Conditions, precedence and how to act for each scenario is much more explicit.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D48161239
fbshipit-source-id: 3d3d24aa1e05458e1f877153e43ebc2b437352e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39122
Updates the `devtoolsFrontendUrl` value returned in the `/json/list` endpoint, to match the fixed DevTools frontend revision we set for `/open-debugger` — which now uses this as the source of truth.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D48561005
fbshipit-source-id: 19409d013366f82782a071a0ec01d1ce8fab8c38
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38871
Changelog: [Internal]
these tests are the last callsite where we are getting event emitter off of RCTRootView... these particular tests have been disabled and they're like 8 years old, sooooooo i think it's just easier for me to delete them
Reviewed By: cipolleschi
Differential Revision: D48179389
fbshipit-source-id: 9fe36323606f53c9b6fde8b4c20d51a2cb1f6c9c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38326
This diff adds the iOS side of changes that the platform would notify `ReactMarker` in C++ for selected list of events. This helps us collect and send startup performance timing values via the `performance.reactNativeStartupTiming` API.
Changelog:
[iOS][Internal] - Notify ReactMarker in C++ from iOS platform for startup perf API
Reviewed By: rshest
Differential Revision: D43931719
fbshipit-source-id: 480ad8d53e541be6200cf8f7336f698a11d9600e
Summary:
Android builds with new arch fail on Windows build host (https://github.com/facebook/react-native/issues/36475). This tiny correction fixes generation of `schema.json` (without it codegen failed to find any files, and generated empty schema). Unfortunately, does not fixes the issue with Windows host entirely, as builds still fail later (on ninja build step).
## Changelog:
[Android] [Fixed] - A bug fix for Android builds with new arch on Windows host.
Pull Request resolved: https://github.com/facebook/react-native/pull/36542
Reviewed By: NickGerleman
Differential Revision: D48563587
Pulled By: cortinico
fbshipit-source-id: acd510308ce9768fb17d3a33c7927de3237748ac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38870
## Changelog:
[iOS][Breaking] - hasBridge is removed from RCTRootView and RCTSurfaceHostingProxyRootView
i'm looking to limit callsites to the bridge in new architecture. in GH search i didn't see anyone using this method.
Reviewed By: cipolleschi
Differential Revision: D48175886
fbshipit-source-id: 367bfd549f658a64c5f9defac6eb66b92e681216
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38865
Changelog: [Internal] - Add basic active pointer tracking to the pointer event processor
This diff lays the groundwork for keeping track of all the "active" pointers. The ActivePointer struct right now only contains a copy of the PointerEvent data but in future diffs this will be extended to include additional stateful metadata.
It's important to note that the code as written in this diff only "tracks" pointers when they are down and won't track pointers that are only hovering. I do want to include this in future diffs but I couldn't include that handling here as it requires changes to the iOS native pointer handling to stop deriving its own hover events which ends up snowballing even more changes. I will be making this change in (hopefully) the next diff where I refactor the hover event derivation to the fabric C++ layer.
Reviewed By: rozele
Differential Revision: D48167438
fbshipit-source-id: d1c7146e7b8d46b2f8defd4785618ee1cd54f155
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39106
## Changelog:
[Internal] -
`ReactNativeFeatureFlags` are not guaranteed to be initialized before everything else, and one case popped up with this being a problem, in particular when creating `GlobalPerformanceLogger` instance (which may be created quite early on).
If the order of initialization of `ReactNativeFeatureFlags` and reading a value from there is flipped, then we'd just get a default value, without using any `MobileConfig` backing or anything.
This diff works this around for the particular case of `GlobalPerformanceLogger` initialization by making the corresponding flag tri-state (unititalized/true/false) and making sure that its value is only really taken into account after its initialized.
Reviewed By: ryancat
Differential Revision: D48559981
fbshipit-source-id: 7fa842d3b845866e15f89731c7e5c9036b83fb24
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
Dmitry Rykun
Xin Chen
FabianSolheim
Alex Hunt
Phillip Pan
Dr. Sergey Pogodin
Vincent Riemer
Ruslan Shestopalyuk
Neil Dhar
Yupeng Li
Riccardo Cipolleschi
Moti Zilberman
Samuel Susla
Michał Mąka
imalgrab
Jesse Watts-Russell
Intl Scheduler
Lulu Wu
Pieter De Baets
Nick Gerleman
Ramanpreet Nara
yardenPhy
Rob Hogan