Summary:
Ok so this is a doozy.
## Overview
There was a report that some console.error calls were being shown as warnings in LogBox but as console.error in the console. The only time we should downlevel an error to a warning is if the custom warning filter says so (which is used for some noisy legacy warning filter warnings internally).
However, in when I switched from using the `Warning: ` prefix, to using the presence of component stacks, I subtly missed the default warning filter case.
In the internal warning filter, the `monitorEvent` is always set to something other than `unknown` and if it's set to `warning_unhandled` then `suppressDialog_LEGACY` is always false.
However, the default values for the warning filter are that `monitorEvent = 'unknown'` and `suppressDialog_LEGACY = true`. In this case, we would downlevel the error to a warning.
## What's the fix?
Change the default settings for the warning filter.
## What's the root cause?
Bad configuration combinations in a fragile system that needs cleaned up, and really really bad testing practices with excessive mocking and snapshot testing (I can say that, I wrote the tests)
## How could it have been caught?
It was, but I turned off the integration tests while landing the component stack changes because of mismatches between flags internally and in OSS, and never turned them back on.
Changelog: [General] [Fixed] - Fix logbox reporting React errors as Warnings
Pull Request resolved: https://github.com/facebook/react-native/pull/46637
Reviewed By: huntie
Differential Revision: D63349613
Pulled By: rickhanlonii
fbshipit-source-id: 32e3fa4e2f2077114a6e9f4feac73673973ab50c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46638
This is annoying, but in the next diff that fixes a bug I need to test using the default warning filter instead of a mock (really, all this mocking is terrible, idk why I did it this way).
Unfortunately, in Jest you can't just reset mocks from `jest.mock`, `restoreMocks` only resets spies and not mocks (wild right).
So in this diff I converted all the `jest.mock` calls to `jest.spyOn`. I also corrected some of the mocks that require `monitorEvent: 'warning',` like the warning filter sets.
I also added a test that works without the fix.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D63349615
fbshipit-source-id: 4f2a5a8800c8fe1a10e3613d3c2d0ed02fca773e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46636
Adds more integration tests for LogBox (currently incorrect, but fixed in a later diff).
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D63349614
fbshipit-source-id: 8f5c6545b48a1ed18aea08d4ecbecd7a6b9fa05a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46639
These tests were skipped when we were switching to component stacks, which also hid a bug later in the stack. Re-enable them.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D63349616
fbshipit-source-id: ccde7d5bb3fcd9a27adf4af2068a160f02f7432a
Summary:
This fixes an issue where `POST /open-debugger?appId&device&target` does not return a proper status code, meaning that the request will never be answered and clients might hang until the request timeout is hit.
## 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] - Respond with status code `200` when successfully launching RNDT
Pull Request resolved: https://github.com/facebook/react-native/pull/46814
Test Plan:
- `curl -v -X POST "<deviceUrl>"`
- This should show a proper response for the request.
before | after
--- | ---
 | 
Reviewed By: NickGerleman
Differential Revision: D63837025
Pulled By: huntie
fbshipit-source-id: ac72fc793e015f0eec498f4a35b4fb9e301c5b32
Summary:
On the old architecture you could take control of loading the bundle by implementing
```objc
- (void)loadSourceForBridge:(RCTBridge *)bridge
onProgress:(RCTSourceLoadProgressBlock)onProgress
onComplete:(RCTSourceLoadBlock)loadCallback;
```
in your `RCTBridgeDelegate`. This is not currently possible in the new architecture.
I've added this using a pretty much identical api by adding a function to both the `RCTInstanceDelegate` and `RCTHostDelegate` protocols. This will be called on the `RCTRootViewFactory`. I've added two properties to the `RCTRootViewFactoryConfiguration`, `loadSourceForHost` and `loadSourceWithProgressForHost`. If one is present, we call it, otherwise we fallback to the normal loading process
## Changelog:
[iOS] [Breaking] - Add ability to control bundle loading on the new architecture similar to `loadSourceForBridge`. Removed some properties from the `RCTRootViewFactory`.
Pull Request resolved: https://github.com/facebook/react-native/pull/46731
Test Plan: Rn-tester works as normal and it is working for our use case in expo go.
Reviewed By: blakef
Differential Revision: D63755188
Pulled By: cipolleschi
fbshipit-source-id: f1f26b2775b9e547ce7a23028665797c19bfdd9b
Summary:
I discovered this while working on my shim of `UIGraphicsImageRenderer` for macOS (See https://github.com/microsoft/react-native-macos/pull/2209). A variable of type`CGColorRef` is not automatically retained and released when passed into a block. There was a case in `RCTBorderDrawing` where we were doing so. To fix this, we have two options:
1. Pass a `UIColor` instead (Requires a change to the signature of the function calling it)
2. Properly retain and release the variable.
The first option would technically be a breaking change (we would need to change the signature of `RCTGetBorderImage`, so I'm opting for option 2.
## Changelog:
[IOS] [FIXED] - Properly retain/release backgroundColor in RCTBorderDrawing
Pull Request resolved: https://github.com/facebook/react-native/pull/46797
Test Plan: CI should pass. Locally, borders still draw fine for me.
Reviewed By: joevilches
Differential Revision: D63827824
Pulled By: cipolleschi
fbshipit-source-id: 926601d062b90a7d741d7a1af3070cec4b8795ae
Summary:
Because `UIGraphicsImageRenderer` doesn't exist on macOS, I need to shim it for React Native macOS (See https://github.com/microsoft/react-native-macos/pull/2209). I planned to use the name `RCTUIGraphicsImageRenderer`. However.. it seems that is used by a static helper function in `RCTBorderDrawing.m`. So.. let's rename it? The function is just a helper method to make an instance of the class, so I think the name `RCTMakeUIGraphicsImageRenderer` is slightly more idiomatic anyway.
This method is not public, so it should not break the public API of React Native.
## Changelog:
[IOS] [CHANGED] - Rename `RCTUIGraphicsImageRenderer` to `RCTMakeUIGraphicsImageRenderer`
Pull Request resolved: https://github.com/facebook/react-native/pull/46772
Test Plan: CI should pass
Reviewed By: joevilches
Differential Revision: D63765490
Pulled By: cipolleschi
fbshipit-source-id: de68dce0f92ec249ea8586dbf7b9ba34a8476074
Summary:
Solve a part of this issue: https://github.com/facebook/react-native/issues/46631
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [CHANGED] - Passed correct title and titleColor prop to updateTitle function
**What's the Issue:**
When updating the PullToRefreshViewProps in a React Native iOS app, changes to the title and titleColor were not being reflected properly in the RefreshControl. This happened because the function responsible for updating the title (_updateTitle) was not always receiving the correct or updated values for title and titleColor.
**Updated `_updateTitle` function:**
The _updateTitle method was modified to accept both title and titleColor as parameters. This ensures that the latest values are always used when updating the refresh control's attributedTitle.
If the title is empty, the attributedTitle is cleared by setting it to nil. Otherwise, both the title and titleColor (if present) are applied correctly.
Pull Request resolved: https://github.com/facebook/react-native/pull/46655
Test Plan:
**Without fix:**
https://github.com/user-attachments/assets/8a83c247-bf78-4080-bdc1-ac5a852481e8
**With Fix:**
https://github.com/user-attachments/assets/52e2495a-4419-41d1-b308-acb64600f9f7
Reviewed By: javache
Differential Revision: D63466516
Pulled By: cipolleschi
fbshipit-source-id: fef61a003b658b20a25b61b6d07ee9fe0750dae7
Summary:
Fixes https://github.com/facebook/react-native/issues/46568 . cc cipolleschi
## Changelog:
[IOS] [FIXED] - Fabric: Fixes animations strict weak ordering sorted check failed
Pull Request resolved: https://github.com/facebook/react-native/pull/46582
Test Plan:
See issue in https://github.com/facebook/react-native/issues/46568
## Repro steps
- Install Xcode 16.0
- navigate to react-native-github
- yarn install
- cd packages/rn-tester
- bundle install
- RCT_NEW_ARCH_ENABLED=1 bundle exec pod install
open RNTesterPods.xcworkspace to open Xcode
{F1885373361}
Testing with Reproducer from OSS
| Paper | Fabric (With Fix) |
|--------|-----------------|
| {F1885395747} | {F1885395870} |
Android - LayoutAnimation (Looks like it has been broken and not working way before this changes.)
https://pxl.cl/5DGVv
Reviewed By: cipolleschi
Differential Revision: D63399017
Pulled By: realsoelynn
fbshipit-source-id: aaf4ac2884ccca2da7e90a52a8ef10df6ae4fc8a
Summary:
React Native [app template provided by the CLI](https://github.com/react-native-community/template) currently uses [`metro-config` directly for `MetroConfig` type](https://github.com/react-native-community/template/blob/main/template/metro.config.js#L7).
However, it doesn't have `metro-config` as neither a dependency or dev dependency, which can lead to version mismatches.
While this is obviously a mistake on the template repo side, `metro-config` versions aren't matched with `react-native` versions. Therefore, getting the correct version of `metro-config` from `react-native/metro-config` would require reflecting on `react-native/metro-config`'s package.json etc. which is far from ideal. In my opinion it's would be much better to expose `MetroConfig` type from `react-native/metro-config` directly.
Version mismatching can happen in a monorepo setup. Say we have the monorepo structure using Yarn Modern:
```tree
.
├── RN75-app (workspace)
├── RN76-app (workspace)
│ ├── metro.config.js
│ └── node_modules
│ └── react-native
│ └── metro-config (0.76)
│ └── node_modules
│ └── metro-config (version for 0.76)
└── node_modules
├── react-native
│ └── metro-config (0.75)
└── metro-config (version for 0.75)
```
`react-native@0.75` gets hoisted to the monorepo root while `react-native@0.76` sits in an RN 0.76 app workspace.
Say we have the following `RN76-app/metro.config.js` contents:
```js
const {getDefaultConfig, mergeConfig} = require('react-native/metro-config');
/**
* Metro configuration
* https://reactnative.dev/docs/metro
*
* type {import('metro-config').MetroConfig}
*/
const config = {};
module.exports = mergeConfig(getDefaultConfig(__dirname), config);
```
In this case, `require('react-native/metro-config')` would resolve to `RN76-app/node_modules/react-native/node_modules/metro-config` since `react-native/metro-config` is a (dev) dependency of the App.
However `import('metro-config).MetroConfig` would resolve to `node_modules/metro-config` since it's not a direct dependency.
This is how we have a mismatch - imported functions come from different packages than imported type.
## Changelog:
[GENERAL] [ADDED] - Expose `MetroConfig` type directly from `react-native/metro-config`.
Pull Request resolved: https://github.com/facebook/react-native/pull/46602
Test Plan:
`yarn build` to generate dist for `react-native/metro-config`, see it has the export of `MetroConfig`.
## Notes
If this PR gets approved, I'll submit relevant one to the CLI template.
Reviewed By: huntie
Differential Revision: D63258881
Pulled By: robhogan
fbshipit-source-id: e6f3c880eb4a0aa902c62932d58f243c38b07c2e
Summary:
Similar to D63541483, modernises our Flow syntax support for our published ESLint config to use `hermes-eslint` (`hermes-parser`).
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D63541856
fbshipit-source-id: 06cc5725faf5934fda07713ec1dac54ff9c32ddf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46696
Following D62161923, we began to lose sync with modern Flow syntax when Metro's `transformer.hermesParser` option is disabled. This config option loads Babel for transformation (instead of `hermes-parser`), which requires a Babel plugin to parse (not strip) Flow syntax.
This diff migrates us away from `babel/plugin-syntax-flow` (see also https://github.com/babel/babel/issues/16264) and uses the modern [`babel-plugin-syntax-hermes-parser`](https://www.npmjs.com/package/babel-plugin-syntax-hermes-parser) instead (a component of the modern Hermes Parser stack).
Following this change, new projects that unset `transformer.hermesParser` will compile.
Resolves https://github.com/facebook/react-native/issues/46601.
Changelog:
[General][Fixed] - Fix parsing of modern Flow syntax when `transformer.hermesParser = false` is configured in Metro config
Reviewed By: cipolleschi
Differential Revision: D63535216
fbshipit-source-id: d2c6ddec030d89e2698e03b76194cf3568d04e6b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46699
Switch from legacy Babel Flow parser integrations to the Meta-maintained `hermes-eslint` and `babel-plugin-syntax-hermes-parser` packages (both part of the `hermes-parser` codebase).
Required to unblock D63535216.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D63541483
fbshipit-source-id: 04ccfa04c9a2b8c0a87ef1a5c38e952971838b77
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46694
The DevMenu module was never implemented on Android. This adds its implementation by mirroring the iOS implementation.
Fixes https://github.com/facebook/react-native/issues/46679
Changelog:
[Android] [Fixed] - Add missing Android implementation for DevMenu Module
Reviewed By: cipolleschi
Differential Revision: D63535172
fbshipit-source-id: 791e72b46b7d3264b98e85a73f2d9025dc3a2c7d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46677
Since removing `react-native-community/cli` as a dependency in 0.76 the `npx react-native init` command isn't working. This is the deprecated way to run this command, but users should still expect it to work for now.
This now forks this kind of request to `npx react-native-community/cli init <args>` as described in the warning logs to the user.
Changelog: [Internal]
Issue: reactwg/react-native-releases#508
Reviewed By: cortinico
Differential Revision: D63467046
fbshipit-source-id: 84560bdae8d6f62629dee61da3cbbf544b9a83b2
Summary:
I've noticed that some users are reporting build failures due to warnings inside RNGP.
We do have `allWarningsAsErrors` set to true for everyone (also for users).
That's too aggressive, and can cause build failures which are not necessary. Let's keep it enabled only on our CI (when the `enableWarningsAsErrors` property is set).
## Changelog:
[INTERNAL] - RNGP: Read `enableWarningsAsErrors` property correctly
Pull Request resolved: https://github.com/facebook/react-native/pull/46657
Test Plan: CI
Reviewed By: NickGerleman
Differential Revision: D63459601
Pulled By: cortinico
fbshipit-source-id: 0307e8d6771518038a5abe27ca5a993cb0a9f8c0
Summary:
While developing my project with New Architecture enabled I've found out that properties `tintColor` and `progressViewOffset` of component `RefreshControl` don't apply on iOS. This happens due to the lack of handling of these properties in the `RCTPullToRefreshViewComponentView.mm` class.
The bug can be easily reproduced in RNTester app on RefreshControlExample.js screen, since it has property `tintColor="#ff0000"` (Red color), but RefreshControl renders with gray color:
<img width="300" alt="RefreshControlExample.js" src="https://github.com/user-attachments/assets/10931204-dbe8-4cbd-9adc-d0f38319febd">
<img width="300" alt="gray Refresh Control" src="https://github.com/user-attachments/assets/e5d088e8-b3f5-46b8-9284-9b452232ad10">
<br />
<br />
This PR is opened to fix that by applying `tintColor` and `progressViewOffset` props to `_refreshControl` in `RCTPullToRefreshViewComponentView.mm` class.
Fixes https://github.com/facebook/react-native/pull/46628
## Changelog:
[IOS][FIXED] - Fix applying of tintColor and progressViewOffset props for RefreshControl component with New Architecture enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/46628
Test Plan:
1. Run rn-tester app with New Architecture enabled on iOS
2. Open screen of RefreshControl component:
<img width="300" alt="Снимок экрана 2024-09-24 в 19 48 49" src="https://github.com/user-attachments/assets/94a2d02d-f3e3-4e18-a345-87c22d4a2620">
3. Open `/packages/rn-tester/js/examples/RefreshControl/RefreshControlExample.js` file and change properties `tintColor` and `progressViewOffset` of RefreshControl components on the line 85:
<img width="300" alt="Снимок экрана 2024-09-24 в 22 01 19" src="https://github.com/user-attachments/assets/425826a6-d34c-4316-8484-e65f125a8b28">
4. check that your changes applied:
<img width="300" alt="Снимок экрана 2024-09-24 в 19 54 46" src="https://github.com/user-attachments/assets/b97621f1-b553-48c9-bc81-e04a99a7e099">
Reviewed By: cortinico
Differential Revision: D63381050
Pulled By: cipolleschi
fbshipit-source-id: 4f3aed8bd7a1e42ce2a75aa19740fd8be1623c86
Summary:
On iPadOS, users can change the kind of keyboard displayed onscreen, going from normal keyboard, to split keyboard (one half on the left of the screen, one half on the right), or a floating keyboard that you can move around the screen.
When a non-normal kind of keyboard is used, `<KeyboardAvoidingView>` calculations are all wrong and, depending on the `behavior` prop, can make your screen completely hidden.
This PR attempts to detect that the keyboard is not the "normal displayed-at-bottom-of-screen" keyboard, and forces `enable={false}` if this happens.
The approach of comparing the keyboard width with the window width comes from this comment: https://github.com/facebook/react-native/issues/29473#issuecomment-696658937
A better fix might be to detect the kind of keyboard used, but this involves native code changes and I do not know iOS enough to do that. In addition, I have not found an easy way to do it using iOS APIs after a quick search.
I also chose to cache the window width as a class attribute. Maybe this is not needed as `Dimensions.get('window').width` is very fast and can be called on every keyboard event?
This fixes https://github.com/facebook/react-native/issues/44068 and https://github.com/facebook/react-native/issues/29473
## Changelog:
[IOS] [FIXED] - Fix `<KeyboardAvoidingView>` with floating keyboard on iPadOS
Pull Request resolved: https://github.com/facebook/react-native/pull/44859
Test Plan:
Tested using RNTester and the "Keyboard Avoiding View with different behaviors" example.
Before:
https://github.com/facebook/react-native/assets/42070/111598a3-286c-464d-8db8-73afb35cd7f9
After:
https://github.com/facebook/react-native/assets/42070/0b3bc94f-8b67-4f42-8a83-e11555080268
Reviewed By: cortinico
Differential Revision: D62844854
Pulled By: cipolleschi
fbshipit-source-id: 577444be50019572955a013969d78178914b5b8d
Summary:
A typo means TextLayoutManager will incorrectly measure text as if `LineBreaker.HYPHENATION_FREQUENCY_NORMAL` is set, instead of the correct default of `LineBreaker.HYPHENATION_FREQUENCY_NONE` which we use to display the `TextView`. This causes truncation if hyphenation would have caused text to be shorter than if not hyphenated. Fix the typo.
Changelog: [Android][Fixed] - Fix measuring text with incorrect hyphenationFrequency
Reviewed By: mellyeliu
Differential Revision: D63293027
fbshipit-source-id: baaf2ae2676548cf0815ae96e324af273be6f99e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46559
There is an edge case when we navigate away from a screen that contains a scroll view where one of the UISCrollViewDelegates does not implement the scrollViewDidEndDecelerating method.
This happens because the Macro used assumes that the event that we are forwarding is the actual method from where the macro is called. Which is not true when it comes to `didMoveToWindow`.
This change fixes that by explicitly expanding the macro in this scenario and passing the right selector.
## Changelog:
[iOS][Fixed] - Fixed a crash when navigating away from a screen that contains a scrollView
## Facebook
This should fix T201780472
Reviewed By: philIip
Differential Revision: D62935876
fbshipit-source-id: e29aadf201c8066b5d3b7b0ada21fa8d763e9af0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46560
The `init` command should still keep on working till 2024-12-31
This handles this scenario as currently `npx react-native@next init` is broken.
Changelog:
[Internal] [Changed] - Clarify init behavior for 0.76
Reviewed By: huntie, cipolleschi
Differential Revision: D62958747
fbshipit-source-id: ce3d974df55162720d59a7ece7fcb816e257185d
Summary:
Regarding the [issue](https://github.com/facebook/react-native/issues/44755) where the app sometimes crashes due to race condition when two reloads overlap in unfortunate way. This PR fixes it in some way by introducing throttling on reload command. For now I set it to 700ms as I was still able to reproduce it on 500-550ms for provided repro in the issue. The problem may still happen for bigger apps where reload may take more time to finish.
## 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] - throttle reload command
Pull Request resolved: https://github.com/facebook/react-native/pull/46416
Test Plan: I've tested on provided repro and a smaller app trying to brake it.
Reviewed By: huntie
Differential Revision: D62847076
Pulled By: cipolleschi
fbshipit-source-id: 6471f792d6b692e87e3e98a699443a88c6ef43cd
Summary:
Following the discussion on https://github.com/facebook/react-native/issues/46505, this PR aims to allow mixte type configuration (String and/or Array of String) during the post installation of pods.
## 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] - allow pods mixte type settings on post-install
Pull Request resolved: https://github.com/facebook/react-native/pull/46536
Test Plan: `packages/react-native/scripts/cocoapods/__tests__/utils-test.rb` test suits was updated to support array and works as expected
Reviewed By: shwanton
Differential Revision: D62870582
Pulled By: cipolleschi
fbshipit-source-id: c0ace6d9d20e6609ceae5aafd236d97fc9e86ddf
Summary:
In this PR https://github.com/facebook/react-native/issues/45560 the BUNDLE_COMMAND initialization was removed while it is still being used. Without it, building from Xcode throws unknown options error for Physical iOS devices.
I have just brought back the initialization from the PR before that, so the bundle phase is successful.
## Changelog:
[IOS][Fixed] - Add back the BUNDLE_COMMAND
Pull Request resolved: https://github.com/facebook/react-native/pull/46495
Test Plan: I have bundled release builds in Xcode. Everything seems to be fine.
Reviewed By: cortinico
Differential Revision: D62846877
Pulled By: cipolleschi
fbshipit-source-id: 3f07e8c0bc5acf98177582f1fee9a55ae77b31a1
Summary:
Solves this issue: https://github.com/facebook/react-native/issues/46276
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [ADDED] - fire onMomentumScrollEnd when UIScrollView is removed from window
**Why the issue is happening?**
The `onMomentumScrollEnd` event is typically triggered by the `UIScrollView` delegate methods `scrollViewDidEndDecelerating` and `scrollViewDidEndScrollingAnimation`. However, if the scroll view is removed from the window while navigating away, these delegate methods are not called, resulting in the event not being dispatched.
This behaviour was particularly problematic in scenarios where a scroll view is in motion, and the user navigates away from the screen before the scrolling completes. In such cases, the `onMomentumScrollEnd` event would never fire, which further make scroll area un touchable or un responsive.
**What we changed?**
In the didMoveToWindow method, we added logic to handle the scenario where the UIScrollView is being removed from the window (i.e., when the component is unmounted or the user navigates away). Here’s a breakdown of the changes:
- **Added a Check for Scroll State:** We check if the UIScrollView was decelerating or had stopped tracking (_scrollView.isDecelerating || _scrollView.isTracking == NO).
- **Manually Triggered onMomentumScrollEnd:** If the scroll view was in motion and is being removed from the window, we manually trigger the `onMomentumScrollEnd` event to ensure that the final scroll state is captured.
**_I had fixed this issue on both Old and New arch._**
Pull Request resolved: https://github.com/facebook/react-native/pull/46277
Test Plan:
Attaching a video with working solution:
https://github.com/user-attachments/assets/1a1f3765-3f11-46c3-af18-330c88478db8
Reviewed By: andrewdacenko
Differential Revision: D62374798
Pulled By: cipolleschi
fbshipit-source-id: 014be8d313bab0257459dc4e53f5b0386a39d5e0
Rob Hogan
Blake Friedman
React Native Bot
Alex Hunt
Nicola Corti
Rick Hanlon
Cedric van Putten
Alan Hughes
Saad Najmi
shubhamguptadream11
Riccardo Cipolleschi
zhongwuzw
Tomasz Żelawski
Alex Hunt
Blake Friedman
tutejsy
Oskar Kwaśniewski
Hailey
Renaud Chaput
Nick Gerleman
Dawid
MasGaNo
Vin Xi