Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46231
Removes this option from `npx react-native start`. Flipper will no longer be the default launch flow in 0.76.
The debugger frontend variant remains controlled by `target.reactNative.capabilities?.prefersFuseboxFrontend`. This will always be Fusebox, since D60893243.
Changelog:
[General][Changed] Remove `--experimental-debugger` option from start command
Reviewed By: robhogan
Differential Revision: D61852415
fbshipit-source-id: 3351f0e12c24717916a70dd1ea28f8690bb5509f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46223
Changelog: [internal]
This introduces a new feature flag to fix some problems with `IntersectionObserver` on Android.
## Context
Our current implementation works as follows:
1. When observing a new target, we synchronously check if there are pending transactions in the mounting layer for that surface.
a) If there are, then we don't dispatch an initial notification for the current state of that target and we wait for those transactions to the applied. When they are, mount hooks are executed and the notifications are dispatched.
b) If there aren't, then we cannot rely on receiving a notification via mount hooks, so we dispatch the notification immediately.
This works well to ensure that when observing a target that was just mounted by React we'll receive a notification with the paint time for that target.
The problem we currently have on Android is that that platform uses a "push" model for the mounting layer, which means we consume transactions immediately after commit. Because of that, when we check whether there are pending transactions, the mounting layer would report "no" but the consumed transactions haven't actually been mounted. In that case, we dispatch the notification immediately.
The result of that behavior is that we don't wait for the transactions that will paint a new target and instead report its intersection immediately, providing incorrect data about when it was first mounted.
## Changes
The way the new feature flag fixes the problem is by adding a new parameter in `MountingCoordinator::pullTransaction` to tell the coordinator that it should continue reporting pending transactions if there were any when that was called. We also add a new method to clear pending transactions when we execute mount hooks for that surface.
Reviewed By: javache
Differential Revision: D61831209
fbshipit-source-id: ed6e5a3d27bd3e802c79a203e920d247b1715c61
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46234
We were seeing some cases of these not working and that was because CoreFeatures::enablePropIteratorSetter was set to true and we need to add this line for it to parse with that
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D61861547
fbshipit-source-id: 47356671dc61e99ffa3df9834eb5856f29b07c59
Summary:
RN Android has historically delegated any responsibilities for background and border rendering to individual view managers.
When we enforced that SVCs didn't allow more properties than native view configs, it meant that unlike for iOS, we needed to structure these SVCs to only apply to single view managers, to avoid warnings.
This creates issues for third-party view managers extending ReactViewGroupManager, which don't seem to get these attributes added to their SVCs under current setup. RNSVG also uses `codegenNativeComponent` on TS `ViewProps`, but for historically reasons around hiding props from the new arch, that does not include these props (and would not have a way to associate with the right process function if it did).
After we clean up an old experiment path (waiting a little bit longer for safety), BaseViewManager on Android will be able to influence rendering, and we can put these in BaseViewManager (see D61658737).
In the meantime, D60575253 allows us to make SVCs a superset of native view config, which means we can declare this for `BaseViewConfig`, before Java view managers catch up, without creating warnings.
Changelog:
[Android][Changed] - Move `experimental_boxShadow` and `experimental_backgroundImage` to BaseViewConfig
Reviewed By: RSNara
Differential Revision: D61744706
fbshipit-source-id: dcf3511ee6f826ef260f557703c182b361b7a2d7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46043
# Changelog: [Internal]
Defined JavaScript interface, which can be used by other modules, such as LogBox, which will be migrated in the next diff
Reviewed By: robhogan
Differential Revision: D61301333
fbshipit-source-id: 63bb8581b893d0fdcb36e1fa16d243f1a5b08ac4
Summary:
Solves this issue: https://github.com/facebook/react-native/issues/29763
## 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
-->
[ANDROID] [ADDED] - Added a conditional check in the `resolveThemeAttribute` function to reattempt resource resolution with the "android" package name if the resource ID is 0.
**Reason why app is getting crashes?**
The crash was occurring due to an issue with resolving certain color attributes in the Android theme. Specifically, when attempting to resolve attributes like textColorPrimary, the getIdentifier method returned a resource ID of 0, indicating that the resource could not be found. This issue resulted in the resolveThemeAttribute function failing, as it attempted to resolve a non-existent resource ID, which led to a crash.
**Key Points:**
**Problem**: Resource ID returned as 0 for specific attributes like textColorPrimary.
**Cause**: The resource ID of 0 indicates that the attribute was not found in the app's resources.
**Impact**: The resolveThemeAttribute function attempted to resolve an invalid resource ID, leading to crash because of this line: https://github.com/facebook/react-native/blob/6cfe51ded006e55617a6f4f2587ca2026306c58d/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/bridge/ColorPropConverter.java#L227
The introduced fix includes a fallback mechanism to attempt resolution with the "android" package name when the initial lookup returns 0. This helps in correctly resolving theme attributes that might be part of the Android system's default resources, thereby preventing the crash.
Pull Request resolved: https://github.com/facebook/react-native/pull/46202
Test Plan: - Tested the app with above colors mentioned. Ensured that app is not getting crashed.
Reviewed By: cipolleschi
Differential Revision: D61847357
Pulled By: cortinico
fbshipit-source-id: 50895a8fd7956e001dbbad9a505ae65151209bd9
Summary:
Replicates https://github.com/react-native-community/cli/commit/48d4c29bba4e8b16cbc8307bd1b4c5349f3651d8, which landed inside `cli-plugin-metro` inside RNC CLI, but because of migration of code to `community-cli-plugin` it looks like apparently the fix wasn't replicated.
## Changelog:
[GENERAL] [FIXED] - Ensure `--build-output` destination exists
Pull Request resolved: https://github.com/facebook/react-native/pull/45182
Test Plan:
Specify a new directory that doesn't exists inside `--build-output`:
`npx react-native bundle --build-output dist/new-dir/index.bundle`
and this command shouldn't fail.
Reviewed By: christophpurrer
Differential Revision: D61850942
Pulled By: huntie
fbshipit-source-id: 90e57f19c661ace8206162d6fa2e6a27acb31e20
Summary:
This PR solves a small issue I've encountered when working with the repo.
When changing branches we often run `yarn` to reinstall dependencies (let's say we change from 0.74-stable to main).
There are lots of changes between those two versions in the `react-native-codegen` package. This causes an issue when we install pods in `packages/rn-tester` the old version of codegen is used (the one cached from 0.74-stable) leading to a big error that's hard to solve at first.
This PR solves this by building codegen on `postinstall`. I've seen many newcomers blocked by this issue (and rerunning `yarn` is the natural thing to do in this situation)
## Changelog:
[INTERNAL] [ADDED] - Build codegen on postinstall when working with the monorepo
Pull Request resolved: https://github.com/facebook/react-native/pull/46227
Test Plan: Run `yarn`
Reviewed By: cipolleschi
Differential Revision: D61849150
Pulled By: huntie
fbshipit-source-id: 24fc5cf9b6a2510298f7bcdce59043e5dcfbfdd4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46229
When running codegen from `pod install`, something affects `require.resolve`, and it starts looking for codegen-enabled dependencies from the workspace root, not the current RN project root.
This is bad if we have different versions of same dependency across multiple workspaces. One of them will be hoisted to the workspace root, and will be used for all the workspaces.
This issue is described in details here https://github.com/facebook/react-native/issues/46196
This diff is supposed to fix this by adding the project root path to the `require.resolve` call.
Changelog: [iOS][Fixed] - Codegen will start looking for codegen-enabled dependencies from the project root.
Reviewed By: cipolleschi
Differential Revision: D61850219
fbshipit-source-id: d60a0e72e9c60e862c0d64e227ea3652d1be5a90
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46216
Regarding [issue](https://github.com/facebook/react-native/issues/45817) with incorrect layout when `left` is set to `auto`. This PR introduces handling `auto` whenever inline or flex position is checked to be defined and it fixes above issue.
Changelog:
[General][Fixed] - Fix handling 'auto' checks in absolute layout
## Tests:
I have run the provided unit tests and everything passes.
X-link: https://github.com/facebook/yoga/pull/1689
Reviewed By: cipolleschi
Differential Revision: D61737876
Pulled By: NickGerleman
fbshipit-source-id: 531199a91c5e122b930b49725ea567cbb1d592ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46215
These cause a build error in RN and need to be updated any time a thick Yoga API changes. This change replaces them with mocking the factories with Mockito instead.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D61804855
fbshipit-source-id: 24fbf10a12102de2975ba3aee45efe7350e294ec
Summary:
This PR modifies hermes-engine.podspec to resolve the path to `react-native` dynamically.
In OOT platforms case we often have slightly different versioning, let's say `react-native` is at 0.75.1 and `react-native-visionos` is at 0.75.2. This causes an issue while resolving the prebuilt version of Hermes. We should always get the Hermes tied to the `react-native` package version, not the OOT platform.
## Changelog:
[IOS] [FIXED] - Resolve Hermes prebuilt version based on react-native packge
Pull Request resolved: https://github.com/facebook/react-native/pull/46181
Test Plan: Install pods
Reviewed By: blakef
Differential Revision: D61720652
Pulled By: cipolleschi
fbshipit-source-id: a99c3261ae8738979f30e831ac6cb494a5c06e31
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46220
We'll want to eventually combine the module and component capabilities more, but these are at least the trivially shared ones.
More work is required to merge the more complex object types.
This change also makes it more clear where capabilities are different between native modules and components
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D61740140
fbshipit-source-id: 9e7bf740cf6cd2431be8cad822ec69903dbbc71f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46218
Changelog: [internal]
https://github.com/facebook/react-native/pull/42975 added some logic to fix modal on iOS for Paper but introduced a state update in `componentWillUnmount`. Doing this is incorrect and we've seen cases where it leads to forcing passive effects synchronously, which can affect performance.
This removes that unnecessary call to update the state, because the component will be unmounted anyway.
Reviewed By: bgirard
Differential Revision: D61813988
fbshipit-source-id: bb203578376d86a907544fa62a0d04e93ca132ef
Summary:
flattenStyle may return an object which is already frozen (in development), so it is incorrect to further mutate this.
related to https://github.com/facebook/react-native/issues/45285
## Changelog:
[GENERAL] [FIXED] - fixed fontWeight number value error for text optimized
Pull Request resolved: https://github.com/facebook/react-native/pull/45932
Reviewed By: NickGerleman
Differential Revision: D61773721
Pulled By: javache
fbshipit-source-id: c5e23becf3af0b4303dda7b9d48628b2bca3285a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46214
This tries to represent a few operations which have previously been observed to be costly in a sampling profiler (showing more granularity than the trace events):
1. TextView getting measurements via `onMeasure()` when updating layout metrics during mount, which may [trigger UI-thread text layout](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/widget/TextView.java;l=11217).
2. Text drawing, which may do layout as well
3. State updates, where we construct a new Spannable and set content to it
Changelog: [Internal]
Reviewed By: tdn120, mdvacca
Differential Revision: D61705770
fbshipit-source-id: 199a6c65c18296f2ff948642701a331ba656e9d9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46205
When React.Activity unmounts and remounts effects, we fail to re-attach the native view to the NativeAnimated nodes, which causes animations to stop working.
Changelog: [Internal]
Reviewed By: sammy-SC, bvanderhoof
Differential Revision: D61662164
fbshipit-source-id: 8e86502f7258beba02d5e60b31864974d7288af5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46179
Changelog: [Internal]
**Context**
- When debugging E2E tests, we found RNTester Legacy Arch builds were rendering border radius w/ percentages in a strange way
- The issues was only noticeable on production e2e builds
- Support for percentage on borderRadius ViewStyle props was added in D56198302
- This should be fabric only, but the same props are parsed on Paper
**Change**
- Add Custom Conversion for BorderRadius on Paper
- Only Parse integer border radius values
Reviewed By: philIip
Differential Revision: D61686841
fbshipit-source-id: cc24d3dbdb82b1dcb90f18fc44d5d13d3e6465b4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46188
UBSAN identified undefined behavior when argCount == 0 (defining a variable array of zero length).
Plus variable arrays in C++ are a clang extension.
[ChangeLog]: [General] [Fixed] - Undefined behavior fix in MethodInvoker
Reviewed By: nlutsenko
Differential Revision: D61725776
fbshipit-source-id: 3729080eae8e78b65a558305f68782ae99edbc0a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46143
Before `drop-shadow` was not creating a stacking context causing its children to get flattened and not receive the shadow effect.
This was due to incorrect parsing on C++. We didn't notice since we don't support `drop-shadow` on iOS and Android gets the parsed prop directly
Changelog: [Internal]
Reviewed By: NickGerleman, joevilches
Differential Revision: D61617699
fbshipit-source-id: a8bfbb0043fcd2b2867923eb937a6be8e9004f13
Summary:
Solves this issue: https://github.com/facebook/react-native/issues/44107
## 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] [ADDED] - Line break mode for TextInput components. **This includes iOS updates to consume new cpp functions.**
This PR is a breakdown of [this](https://github.com/facebook/react-native/pull/45968) PR.
Pull Request resolved: https://github.com/facebook/react-native/pull/46129
Test Plan: - Tested builds in new and old architecture mode.
Reviewed By: andrewdacenko
Differential Revision: D61656969
Pulled By: cipolleschi
fbshipit-source-id: 4c6ed983ad15841ce52443bba13962d45c04e756
Summary:
Solves this issue: https://github.com/facebook/react-native/issues/44107
## 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] [ADDED] - Line break mode for TextInput components. **This includes cpp changes and new functions.**
This PR is a breakdown of [this](https://github.com/facebook/react-native/pull/45968) PR.
Pull Request resolved: https://github.com/facebook/react-native/pull/46130
Test Plan: - Tested builds in new and old architecture mode.
Reviewed By: andrewdacenko
Differential Revision: D61656894
Pulled By: cipolleschi
fbshipit-source-id: 9a25387cb27cded072e76575e6d2fca01963c621
Summary:
A previous attempt at fixing this issue used a relative path (https://github.com/facebook/react-native/issues/45208), this doesn't work if the user runs bundle install outside of the `ios/`
folder, using the `--project-directory=ios` argument.
## Changelog:
[iOS][Fixed] support bundle install from outside the ios folder using --project-directory
Pull Request resolved: https://github.com/facebook/react-native/pull/46186
Test Plan:
Ran the command in a project with `react-native-firebase/app` using the
`--project-directory`, confirmed that it's fixed when using the absolute
path.
closes: reactwg/react-native-releases#341
Reviewed By: cipolleschi
Differential Revision: D61719821
Pulled By: blakef
fbshipit-source-id: d83429dd29c9e8cc066ab9843ad95fdfc0af8dea
Summary:
This PR adds few missing text content types on iOS (available from iOS 15)
- dateTime
- flightNumber
- shipmentTrackingNumber
## Changelog:
[IOS] [ADDED] - Add support for missing text content types
Pull Request resolved: https://github.com/facebook/react-native/pull/42788
Test Plan: Make sure that `RNTester` builds and runs successfully
Reviewed By: robhogan
Differential Revision: D61656748
Pulled By: cipolleschi
fbshipit-source-id: e960eded5f049d3c4bf76a5a4e3159b240546288
Summary:
I couldn't find a reference nor a reason for this method. It's a bit hard to grep, so let me know if I missed something.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D61558809
fbshipit-source-id: d977440ff98b2a5bf115d19bfa4acbcf6d216b2a
Summary:
FIXES https://github.com/facebook/react-native/issues/45858
When working with UIRefreshControl in a custom React Native component, we encountered a problem where the refresh control did not behave correctly if it was offscreen. Specifically, attempts to programmatically begin or end refreshing were ignored if the control was not visible. This typically manifested as the refresh control not updating its state properly when it was re-rendered or moved in the view hierarchy.
Happening only on old-arch.
**Problem Details**
**Offscreen Refresh Control Ignored:** The UIRefreshControl would ignore calls to beginRefreshing and endRefreshing if it was not currently visible on the screen.
**Inconsistent State:** The internal state _currentRefreshingState might not match the actual state of the UIRefreshControl, leading to unexpected behavior.
**Steps to Fix**
**Track Visibility with didMoveToWindow:**
Implement the didMoveToWindow method to track when the refresh control is added to or removed from the window.
Use a flag _hasMovedToWindow to keep track of this state.
And check this flag should be true whenever we start or end refreshing
## Changelog:
[IOS] [FIXED] - Fixed an issue where the refresh control would not behave correctly if it was offscreen.
Pull Request resolved: https://github.com/facebook/react-native/pull/45996
Test Plan:
Issue Screen recording
https://github.com/user-attachments/assets/73b45c27-19c2-4eeb-991e-33b45f0a6d97
Fix Screen Recording :
https://github.com/user-attachments/assets/ffc6b6e6-fc68-498c-abdf-3144c31caa86
Reviewed By: realsoelynn
Differential Revision: D61657472
Pulled By: cipolleschi
fbshipit-source-id: 7a369f8e3ca902536a7608fbe1b89cec7734c418
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46176
Noticed that ModalHostView's event dispatching would sometimes fallback to RCTEventEmitter, which is not supported in the new architecture. Instead, we should propagate the reactTag to the inner content view so we can correctly associate the right UIManager and host component with events emitted.
Changelog: [Android][Fixed] PointerEvents from Modal would not be dispatched correctly in new architecture.
Reviewed By: bvanderhoof
Differential Revision: D61671005
fbshipit-source-id: 6aad1ff609da81cf5e8f71c4e91be30713494679
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45966
JSI performs the check itself, no need to do it here. Plus, bytecode
bundles must not be zero terminated.
## Changelog:
[IOS] [FIXED] - Fixes NSDataBigString length calculation
Reviewed By: realsoelynn
Differential Revision: D61058869
fbshipit-source-id: 15b99ef13f9aebd11ff410d02c21db8e46cc6ac3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46156
Changelog: [internal]
This improves the handling of disconnected nodes in `IntersectionObserver`. Specifically:
* When observing a node, if the node is disconnected (unmounted) this is just a no-op (without logging errors). We can't observe an unmounted node.
* When disconnecting the observer, if the observed nodes are disconnected, we get the target shadow node from an internal map, which we always have access to if we successfully started observing the node. If this logs an error now, it's something to look into but it won't generally log it if the target is just disconnected. That will work correctly.
Reviewed By: bvanderhoof
Differential Revision: D61656597
fbshipit-source-id: 6a39c878acc976ddc0789260106da104a3f2a57f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46157
Changelog: [internal]
This improves the handling of disconnected nodes in `MutationObserver`. Specifically:
* When observing a node, if the node is disconnected (unmounted) this is just a no-op (without logging errors). We can't observe an unmounted node.
* When disconnecting the observer, if the observed nodes are disconnected, we get the target shadow node from an internal map, which we always have access to if we successfully started observing the node. If this logs an error now, it's something to look into but it won't generally log it if the target is just disconnected. That will work correctly.
Reviewed By: bvanderhoof
Differential Revision: D61655856
fbshipit-source-id: d18a885350ef000fc563c85f6775ba864d184ad1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46138
jorge-cab noticed that filters on iOS do not fit the shape of the layer if we have rounded corners. Fix is pretty straight forward.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D61612655
fbshipit-source-id: 91785ed10a039e031c5440bde131c1583ba3992a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46146
Changelog: [Internal]
`unit` is of type `UnitType`, so there's no reason to have a default case here.
i found this because my build failed when pulling in this dependency, there was a compiler flag that enforced that all cases must be enumerated. this seems like the right practice anyways.
Reviewed By: NickGerleman
Differential Revision: D61635463
fbshipit-source-id: b84b5518f2a17e792309f85ae91514a17abad295
Alex Hunt
Rubén Norte
Joe Vilches
Nick Gerleman
Ruslan Lesiutin
shubhamguptadream11
Szymon Rybczak
Edmond Chui
Oskar Kwaśniewski
Dmitry Rykun
Dawid
Eli White
Samuel Susla
meetdhanani17
Tim Yung
Pieter De Baets
Ingrid Wang
Shawn Dempsey
Riley Berton
Jorge Cabiedes Acosta
Blake Friedman
Kacper Rozniata
Jan Kassens
zhongwuzw
Deepanshu.shukla
Tzvetan Mikov
Jakub Piasecki
Phillip Pan
Thomas Nardone