Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46525
While debugging I noticed that my setTimout was being cleared by someone else. Upon further inspection I found NativeAnimatedHelper which was mismatching setImmediate timer handle with a clearTimeout. This isn't safe and needs to be fixed.
I used this to rename the timer to be more clear to reduce the changes of mismatches.
Changelog:
[General][Fixed] - Fix setImmediate/clearTimeout mismatch in NativeAnimatedHelper that could clear an unrelated setTimeout.
Reviewed By: javache, yungsters
Differential Revision: D62775703
fbshipit-source-id: c1669c60bd08f13a59dd6159be2f471a6c1beebd
Summary:
There is a crash on iOS when trying to show an action sheet, but `RCTPresentedViewController` returns null. The code attempts to print an error but fails when casting values.
The issue is that some values, like _title_ or _message_ could be `nil`, which causes a failure when casting them to use in `RCTLogError`.
Fixes: https://github.com/facebook/react-native/issues/46549
## Stacktrace:
```
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[__NSPlaceholderDictionary initWithObjects:forKeys:count:]: attempt to insert nil object from objects[0]'
0 CoreFoundation 0x00000001804ae0f8 __exceptionPreprocess + 172
1 libobjc.A.dylib 0x0000000180087db4 objc_exception_throw + 56
2 CoreFoundation 0x000000018051c84c -[__NSPlaceholderDictionary initWithObjects:forKeys:count:] + 660
3 CoreFoundation 0x00000001804ac9cc +[NSDictionary dictionaryWithObjects:forKeys:count:] + 48
4 AwesomeProject.debug.dylib 0x0000000106ed9138 __61-[RCTActionSheetManager showActionSheetWithOptions:callback:]_block_invoke_4 + 340
5 libdispatch.dylib 0x0000000103f3bec4 _dispatch_call_block_and_release + 24
6 libdispatch.dylib 0x0000000103f3d73c _dispatch_client_callout + 16
7 libdispatch.dylib 0x0000000103f4d3f8 _dispatch_main_queue_drain + 1228
8 libdispatch.dylib 0x0000000103f4cf1c _dispatch_main_queue_callback_4CF + 40
9 CoreFoundation 0x000000018040e960 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
10 CoreFoundation 0x0000000180409078 __CFRunLoopRun + 1936
11 CoreFoundation 0x00000001804084d4 CFRunLoopRunSpecific + 572
12 GraphicsServices 0x000000018ef2aae4 GSEventRunModal + 160
13 UIKitCore 0x00000001853d0a28 -[UIApplication _run] + 868
14 UIKitCore 0x00000001853d46b0 UIApplicationMain + 124
15 AwesomeProject.debug.dylib 0x0000000106d47bec __debug_main_executable_dylib_entry_point + 96
16 dyld 0x0000000102fbd544 start_sim + 20
17 ??? 0x00000001030620e0 0x0 + 4345700576
18 ??? 0x4e6d800000000000 0x0 + 5651313844908195840
```
## Changelog:
[IOS] [FIXED] - Fix ActionSheetIOS crash `attempt to insert nil object from objects`
Pull Request resolved: https://github.com/facebook/react-native/pull/46550
Test Plan:
I created an example project.
Example: https://github.com/RodolfoGS/react-native-fix-ios-actionsheet
### How to reproduce using the example above:
1. `git clone git@github.com:RodolfoGS/react-native-fix-ios-actionsheet.git`
2. `cd react-native-fix-ios-actionsheet`
3. `npm install`
4. `npm run ios`
5. Tap on _Show Action Sheet_ button on the app
6. Notice the crash
### Steps to create the example from scratch and reproduce the crash:
1. `npx react-native-community/cli@latest init AwesomeProject`
2. `cd AwesomeProject`
3. Install `patch-package` and add this patch to simulate a situation where `RCTPresentedViewController` returns null (https://github.com/RodolfoGS/react-native-fix-ios-actionsheet/blob/main/patches/react-native%2B0.75.3.patch)
4. `npm run ios`
5. Tap on _Show Action Sheet_ button on the app
6. Notice the crash
Reviewed By: caodoan
Differential Revision: D62897554
Pulled By: philIip
fbshipit-source-id: fb978c4648a6c4e36c609783e59367a5997e42cb
Summary:
Fix platform color on android with linear gradient.
## Changelog:
[ANDROID] [FIXED] - Linear gradient with platform colors
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/46290
Test Plan: Added example and testcases
Reviewed By: mdvacca
Differential Revision: D62277253
Pulled By: NickGerleman
fbshipit-source-id: 376ee5ebde61f3cb1ed32e82f71ad5479ebc50a5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46518
## Summary
When a view config can not be found, it currently errors with
`TypeError: Cannot read property 'bubblingEventTypes' of null`. Instead
invariant at the correct location and prevent further processing of the
null viewConfig to improve the error logged.
## How did you test this change?
Build and run RN playground app referencing an invalid native view
through `requireNativeComponent`.
Changelog: [General][Fixed] Improved error message when no view config is found.
DiffTrain build for commit https://github.com/facebook/react/commit/26855e4680dedb21f2c73a069ed691822a242db1.
Test Plan: Sandcastle tests
Reviewed By: jackpope
Differential Revision: D62760863
Pulled By: javache
fbshipit-source-id: c71dacc48fe8795b28840cfb3f53c1f9fc664a16
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46528
This is needed for a script that needs to switch over all possible type annotations in the codegen schema.
Reviewed By: GijsWeterings
Differential Revision: D62805189
fbshipit-source-id: 8fd113f4ad0b695b38e92b8d0fc45a991f597fb8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46538
changelog: [internal]
When we run synchronous task, it was able to get into a state where RuntimeScheduler stopped executing tasks in the queue and it wouldn't get unstuck. This appeared as non-responsive app.
The problem was that `isEventLoopScheduled_` was not being restarted in case `syncTaskRequests_` was bigger than 0. There is a unit test covering this scenario.
Reviewed By: rubennorte
Differential Revision: D62756582
fbshipit-source-id: 878b8445baea05e8b9eddae05ca0d11d5e93acb6
Summary:
this PR fixes a few small ESLint issues that were showing up under PR diffs.
## Changelog:
[INTERNAL] [FIXED] - Fix various ESLint issues
Pull Request resolved: https://github.com/facebook/react-native/pull/46379
Test Plan: ran JS tests + linter; all passing
Reviewed By: cipolleschi
Differential Revision: D62385788
Pulled By: NickGerleman
fbshipit-source-id: b33d7ade4696bbaed2ac1a3fc2e0b3dff9bb04b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46547
While testing the 0.76 RCs, it was initially unclear to me that `npx react-native init` was both deprecated and **removed** (performs a noop). Update message for clarity.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D62881266
fbshipit-source-id: b9017e63360c7aee5483d437ce1510be9a14ef42
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46533
Changelog: [internal]
When defining overrides for feature flags, it's common to have this pattern:
```javascript
myFeatureFlag: () => someCondition ? value : defaultValueForFlag
```
But it's not always obvious how to get the default value defined in the feature flag system. This modifies the API so we receive the default value as a parameter to simplify the logic:
```javascript
myFeatureFlag: (defaultValueForFlag) => someCondition ? value : defaultValueForFlag
```
Reviewed By: mdvacca, rshest
Differential Revision: D62853299
fbshipit-source-id: 9421e31d00662e2a23f1e3fb43bdc9f5cf03fdf3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46530
Changelog: [internal]
There's nothing preventing these modules from being `flow strict` instead of `flow strict-local`, so we can just make the change.
Reviewed By: mdvacca
Differential Revision: D62763719
fbshipit-source-id: 1821ef9ad2e8dc67b754eccc77e35ef34400ca0a
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:
This pull request replaces the use of mkdirp with Node.js's built-in fs.mkdirSync({ recursive: true }) function, which is available in Node.js version 10.12.0 and above. This change reduces the number of external dependencies and simplifies the codebase by using the native capabilities of Node.js.
The motivation behind this change is to remove the unnecessary mkdirp dependency, as Node.js natively supports recursive directory creation since version 10.12.0. This streamlines the code and reduces the reliance on external libraries.
## Changelog:
[INTERNAL] [REMOVED] - Replaced mkdirp with fs.mkdirSync({ recursive: true }) in build scripts and codegen. Requires Node.js 10.12.0 and above.
Pull Request resolved: https://github.com/facebook/react-native/pull/46388
Test Plan: I ran the build and codegen scripts locally with Node.js version 10.12.0 and above after replacing mkdirp, ensuring the scripts work as expected. No issues were encountered, and all processes, including directory creation and file handling, function correctly.
Reviewed By: cortinico
Differential Revision: D62852488
Pulled By: huntie
fbshipit-source-id: 76f44102a80b499521c156308d276a17d279ce38
Summary:
This PR does some further cleanup on the flags passed to cocoapods.
I've moved `boost_compiler_flags` and `folly_dep_name` to `helpers.rb` file.
## Changelog:
[INTERNAL] [FIXED] - move boost compiler flags and folly dep name to centralized config
Pull Request resolved: https://github.com/facebook/react-native/pull/46513
Test Plan: CI Green
Reviewed By: cortinico
Differential Revision: D62846105
Pulled By: cipolleschi
fbshipit-source-id: dff07ddb49f1f4b559125f2ed8508b32f08d4975
Summary:
This PR is a small fix for the indentation of `tsconfig.json`
## Changelog:
[INTERNAL] [FIXED] - fix for the indentation of `tsconfig.json`
Pull Request resolved: https://github.com/facebook/react-native/pull/46529
Test Plan: N/A
Reviewed By: cortinico
Differential Revision: D62845892
Pulled By: cipolleschi
fbshipit-source-id: 52a0309027350cd9bba8c2c158887b23ea093876
Summary:
Due to `set -e` shell option, missing `xcrun` may cause the setup script to fail on Linux.
Also makes the script continue even if the glog `./configure` call does not succeed.
### Related
- Follow-up to https://github.com/facebook/react-native/pull/44417
## Changelog:
- [Internal] [Fixed] - react-native: make missing xcrun not throw in `ios-configure-glog.sh`
- [Internal] [Fixed] - react-native: accept failing glog ./configure in `ios-configure-glog.sh`
Pull Request resolved: https://github.com/facebook/react-native/pull/46358
Reviewed By: cortinico
Differential Revision: D62851737
Pulled By: cipolleschi
fbshipit-source-id: 3ed76a81b6f428a1697c364698a0dfdd3bbb74f2
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/46527
Changelog: [Internal]
**Context**
- `DefaultTurboModuleManagerDelegate.kt` was being stripped by redex since there was no direct dependency.
- This was causing a crash in prod builds
```
Trace: java.lang.RuntimeException: Unable to create application com.facebook.mobilehome.MobileHomeAppShell: java.lang.ClassNotFoundException: Didn't find class "com.facebook.react.defaults.DefaultTurboModuleManagerDelegate" on path: DexPathList
```
**Change**
- Annotate `DefaultTurboModuleManagerDelegate.kt` with `DoNotStripAny`
- Don't strip `DoNotStripAny` annotated classes
Reviewed By: mdvacca
Differential Revision: D62766339
fbshipit-source-id: 7d9bfa04e252c392b94f739443bacf34f593e481
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46166
## This Diff
This removes some of the legacy utilties used for background manipulation, no longer used anywhere (and very rarely used externally from some previous tests). These conflict with BackgroundStyleApplicator, which should be used instead.
## This Stack
This removes the non-Style-applicator background management paths of the different native components. There have been multiple conflicting changes, and bugs added bc harder to reason about, which motivates making this change as soon as possible. This also lets us formalize guarantees that BaseViewManager may safely manipulate background styling of all built in native components.
There is one still known issue, where BackgroundStyleApplicator does not propagate I18nManager derived layout direction to borders (compared to Android derived root direction). This is mostly an issue for apps that with LTR and RTL context, or force a layout direction, which I would guess is relatively rare, so my plan is to forward fix this later this by enabling set_android_layout_direction which will solve that problem mopre generically.
Changelog:
[Android][Breaking] - Remove ReactViewBackgroundManager and ReactViewBackgroundDrawable
Reviewed By: sammy-SC
Differential Revision: D61658084
fbshipit-source-id: 611f6d78fa4859574c063e9f0395c3dadc1588cc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46168
## This Diff
This removes the legacy path from ReactScrollView and its view manager.
## This Stack
This removes the non-Style-applicator background management paths of the different native components. There have been multiple conflicting changes, and bugs added bc harder to reason about, which motivates making this change as soon as possible. This also lets us formalize guarantees that BaseViewManager may safely manipulate background styling of all built in native components.
There is one still known issue, where BackgroundStyleApplicator does not propagate I18nManager derived layout direction to borders (compared to Android derived root direction). This is mostly an issue for apps that with LTR and RTL context, or force a layout direction, which I would guess is relatively rare, so my plan is to forward fix this later this by enabling set_android_layout_direction which will solve that problem mopre generically.
Changelog: [Internal]
Reviewed By: tdn120
Differential Revision: D61658081
fbshipit-source-id: d6db43e25faf8e1ebd42d2816c7a915b3ed9404e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46161
## This Diff
This removes the legacy path from ReactHorizontalScrollView and its view manager.
## This Stack
This removes the non-Style-applicator background management paths of the different native components. There have been multiple conflicting changes, and bugs added bc harder to reason about, which motivates making this change as soon as possible. This also lets us formalize guarantees that BaseViewManager may safely manipulate background styling of all built in native components.
There is one still known issue, where BackgroundStyleApplicator does not propagate I18nManager derived layout direction to borders (compared to Android derived root direction). This is mostly an issue for apps that with LTR and RTL context, or force a layout direction, which I would guess is relatively rare, so my plan is to forward fix this later this by enabling set_android_layout_direction which will solve that problem mopre generically.
Changelog: [Internal]
Reviewed By: tdn120
Differential Revision: D61658082
fbshipit-source-id: 98cab5dfcad8beee6d131fcfe122313730a6f665
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46162
## This Diff
This removes the legacy path from ReactEditText and its view manager.
## This Stack
This removes the non-Style-applicator background management paths of the different native components. There have been multiple conflicting changes, and bugs added bc harder to reason about, which motivates making this change as soon as possible. This also lets us formalize guarantees that BaseViewManager may safely manipulate background styling of all built in native components.
There is one still known issue, where BackgroundStyleApplicator does not propagate I18nManager derived layout direction to borders (compared to Android derived root direction). This is mostly an issue for apps that with LTR and RTL context, or force a layout direction, which I would guess is relatively rare, so my plan is to forward fix this later this by enabling set_android_layout_direction which will solve that problem mopre generically.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D61658080
fbshipit-source-id: 6ac7c5ed230e44fe307640a730e076b903e0674a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46171
## This Diff
This removes the legacy path from ReactTextView and its view manager.
## This Stack
This removes the non-Style-applicator background management paths of the different native components. There have been multiple conflicting changes, and bugs added bc harder to reason about, which motivates making this change as soon as possible. This also lets us formalize guarantees that BaseViewManager may safely manipulate background styling of all built in native components.
There is one still known issue, where BackgroundStyleApplicator does not propagate I18nManager derived layout direction to borders (compared to Android derived root direction). This is mostly an issue for apps that with LTR and RTL context, or force a layout direction, which I would guess is relatively rare, so my plan is to forward fix this later this by enabling set_android_layout_direction which will solve that problem mopre generically.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D61658083
fbshipit-source-id: b753d4eb45091aa31ea870a684c35b71c1ee5036
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46159
## This Diff
This removes the legacy path from ReactViewGroup and its view manager.
## This Stack
This removes the non-Style-applicator background management paths of the different native components. There have been multiple conflicting changes, and bugs added bc harder to reason about, which motivates making this change as soon as possible. This also lets us formalize guarantees that BaseViewManager may safely manipulate background styling of all built in native components.
There is one still known issue, where BackgroundStyleApplicator does not propagate I18nManager derived layout direction to borders (compared to Android derived root direction). This is mostly an issue for apps that with LTR and RTL context, or force a layout direction, which I would guess is relatively rare, so my plan is to forward fix this later this by enabling set_android_layout_direction which will solve that problem mopre generically.
Changelog: [Internal]
Reviewed By: tdn120
Differential Revision: D61657251
fbshipit-source-id: 6d00a1cac79450d306cf28446e6397d31ceffb19
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46167
## This Diff
This removes the legacy path from ReactImageView and its view manager.
## This Stack
This removes the non-Style-applicator background management paths of the different native components. There have been multiple conflicting changes, and bugs added bc harder to reason about, which motivates making this change as soon as possible. This also lets us formalize guarantees that BaseViewManager may safely manipulate background styling of all built in native components.
There is one still known issue, where BackgroundStyleApplicator does not propagate I18nManager derived layout direction to borders (compared to Android derived root direction). This is mostly an issue for apps that with LTR and RTL context, or force a layout direction, which I would guess is relatively rare, so my plan is to forward fix this later this by enabling set_android_layout_direction which will solve that problem mopre generically.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D61657253
fbshipit-source-id: 96cf1160e466de78c2f133f0e4fb2d9b2e7cf478
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46524
There's an interesting behavior in Animated where we effectively perform an O(N + M) traversal of the Animated graph, calling `__makeNative` on each "input", which in turn tends to call `__makeNative` on each "output" (so we revisit the current node M times when calling `__makeNative` on the M inputs). In practice, the behavior is still O(N), because M is small and finite (most Animated nodes have 1 or 2 inputs).
All that said, some platforms (e.g., react-native-windows) rely on this revisiting behavior, where on the first visit, we recurse the node to its inputs, and on the subsequent visit, we update the `_platformConfig` value without recursion (see https://github.com/facebook/react-native/pull/32736 for the original change adding platformConfig).
A recent change to AnimatedWithChildren (https://github.com/facebook/react-native/pull/46286) eagerly invokes `__getNativeTag` on AnimatedWithChildren in the initial recursion step, which forces materialization of the NativeAnimated node *before* it's `_platformConfig` is set.
There is certainly some refactoring that needs to be done to improve all this, but for now, this change reverts to delay the call to `__getNativeTag` until after at least one `__makeNative` occurs on an input.
## Changelog
[General][Fixed]: Order of operations related to platformConfig propagation in NativeAnimated
Reviewed By: yungsters
Differential Revision: D62768179
fbshipit-source-id: ca9d911503e0630bc3a1309b21f9686aa77ac8b9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46509
With ARG_DISABLE_HOST_LIFECYCLE_EVENTS it's possible to conditionally set mDisableHostLifecycleEvents when the ReactFragment gets created.
## Changelog:
[Android][Fixed] ARG_DISABLE_HOST_LIFECYCLE_EVENTS in ReactFragment to allow unmounting a surface without destroying ReactHost.
Reviewed By: rozele
Differential Revision: D62714185
fbshipit-source-id: b6518ff67a9644421b8fe9c7cdc2aa6d62a23651
Summary:
This PR adds an ifdef to declare `supportedInterfaceOrientations` only on iOS as this property does not affect other platforms causing a build issue.
## Changelog:
[IOS] [ADDED] - declare supportedInterfaceOrientations only on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/46512
Test Plan: CI Green
Reviewed By: christophpurrer
Differential Revision: D62754746
Pulled By: javache
fbshipit-source-id: e2ca5d96cba87e611c48a87f10bf7831e9051646
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46508
Changelog: [internal]
This cleans up the "fixMissedFabricStateUpdatesOnAndroid" feature flag and enables the fix permanently.
This fixes some state updates in the Fabric shadow tree being missed in some edge cases.
See https://github.com/facebook/react-native/pull/45236 for context.
Reviewed By: rshest
Differential Revision: D62743019
fbshipit-source-id: c24ab8a49a97ca26e60efa2fa4bc6a21ccac52d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46515
Changelog: [internal]
This reduces the depth of the Systrace/Perfetto blocks by 1 removing this unnecessary nesting. If for some reason `ShadowTree::tryCommit` runs more than once, it will still show up.
Reviewed By: bgirard, sammy-SC
Differential Revision: D62499855
fbshipit-source-id: 48cce7532a308221c22d04de874870be509fe315
Summary:
This PR removes `available` for `RCTKeyWindow` after minimum version bump to iOS 15 this check is not needed anymore.
## Changelog:
[IOS] [REMOVED] - remove available for RCTKeyWindow check
Pull Request resolved: https://github.com/facebook/react-native/pull/46510
Test Plan: CI Green
Reviewed By: rshest
Differential Revision: D62752434
Pulled By: javache
fbshipit-source-id: 7b7745d4f27128cdb66053f7fa1cc234435eac31
Summary:
Solves these issues:
- https://github.com/facebook/react-native/issues/18398
- https://github.com/facebook/react-native/issues/12478
Solves this proposal: https://github.com/react-native-community/discussions-and-proposals/discussions/774
## 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] [ADDED] - added overlayColor prop to modal component for customisable background overlay
**Motivation:**
Currently, the React Native Modal component only allows the background to be set to either `transparent` or `white`. This limits the ability to dim the background or apply custom colors, which is essential for creating a more polished and user-friendly interface.
**Change Log:**
Modal Component Enhancements:
- Introduced a new optional prop `overlayColor` to the Modal component.
- Updated the background color logic to prioritize `overlayColor` when transparent is `false`.
- Ensured backward compatibility by defaulting to `white` when `overlayColor` is not provided.
Pull Request resolved: https://github.com/facebook/react-native/pull/46322
Test Plan:
- Test the changes on both iOS and Android devices/emulators to ensure consistent behavior.
- Added example in **rn-tester** app
**Sample screenshot with custom overlayColor passed as 'red'.**
Reviewed By: cipolleschi
Differential Revision: D62201559
Pulled By: alanleedev
fbshipit-source-id: e990d7f18f5edf61f0107026ea899c5f22d47bfd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46506
Changelog: [Android][Fixed] Fixed incorrect scroll event/position for scroll views when doing a smooth scroll animation.
We tested this in production and the fix is safe to land.
Reviewed By: rshest
Differential Revision: D62738925
fbshipit-source-id: e1198dac76cf850dfa76a5cee1ef205d5b367d19
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46511
changelog: [internal]
task is not used after this line of code. Let's avoid copy shared_ptr's copy constructor.
Reviewed By: rubennorte
Differential Revision: D62751612
fbshipit-source-id: 92b0da44972b200870ef66f3a8482fbde55052ac
Summary:
This reverts commit 0cb97f0261.
Revert this commit that adds a `post install` script for a couple of reasons:
1. (EDIT: This turns out to be unrelated) The `postinstall` script causes `yarn install` to fail on React Native macOS, where we use Yarn 4. I'm not entirely sure why, but I probably won't debug it for the rest of the reasons.
2. `postinstall` scripts (at least inside Microsoft) are viewed as a security risk. Any package in your dependency tree can get compromised, add the phase, and run arbitrary code. This has happened in the past with React Native past if I recall correctly. As such, we disable `postinstall` scripts in many of our repos (including `rnx-kit` and `react-native-test-app`).
3. The issue this is trying to solve is to help newcomers avoid a stale cache when they switch branches in the React Native monorepo and only run `yarn install`. I think it would be sufficient to add some documentation somewhere that it is expected one runs `yarn && yarn build` to use this repo locally? That's a fairly common practice in monorepos, at least ones inside Microsoft.
## Changelog:
[INTERNAL] [SECURITY] - Remove post install script phase in the React Native monorepo
Pull Request resolved: https://github.com/facebook/react-native/pull/46420
Test Plan: CI should pass
Reviewed By: christophpurrer, robhogan, cortinico, rshest
Differential Revision: D62755022
Pulled By: huntie
fbshipit-source-id: bf94ed33e3e451ea337ef7a6984f7ba964d0b212
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46462
While adding D62583337, I noticed that `react-native` doesn't specify `babel-jest` as a dependency, despite referencing it in the included `jest-preset.js` — instead this would need to be installed by the template/project.
If we want to change this in future, we should consider a separate `react-native/jest-preset` package. However, I strongly believe this is the right location for this dependency: installing `react-native` = all parts of it work.
(Note that in the React Native monorepo, we are using `dependencies` for both dev and runtime deps in packages.)
Changelog: [Internal]
allow-executable-binary
## allow-executable-binary: Bypassed as this is a managed JavaScript dependency that is pre-existing in other parts of the codebase
Reviewed By: robhogan
Differential Revision: D62583665
fbshipit-source-id: 8bbcc8736e2740e45793d7b7e225ccfd1ca7f898
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46502
changelog: [internal]
At the moment, Linking module has undocumented restriction that if you call it twice when Android Activity is not available, it will return with an error.
This is unnecessary and can be handled more sensibly.
Reviewed By: javache, yungsters
Differential Revision: D62708123
fbshipit-source-id: 79a6beb70e834e631f7bedaf6a64076b050a7daa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46484
We recently realized that we don't have TS types for Codegen.
These are needed to let our users use these types when writing Specs in TS
## Changelog
[General][Added] - Add CodegenTypes for TS
Reviewed By: christophpurrer
Differential Revision: D62644516
fbshipit-source-id: 92bb7e8998d31806f6eb63319fb6d406fcd65ad8
Summary:
Following one of my previous PRs: https://github.com/facebook/react-native/pull/45176 I'm adding same conditionals to another module.
StatusBar API is supported on this platforms:
| Platform | Support |
| ------------- | ------------- |
| macOS | ❌ |
| tvOS | ❌ |
| visionOS | ❌ |
| iOS/iPadOS | ✅ |
## 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
-->
[INTERNAL] [ADDED] - Conditionals for iOS only code in RCTStatusBarManager.mm
Pull Request resolved: https://github.com/facebook/react-native/pull/45896
Test Plan: CI Green / Make sure everything works as before
Reviewed By: cortinico
Differential Revision: D62579943
Pulled By: cipolleschi
fbshipit-source-id: 0c198c7732d253993638d825ca83be076bb09b90
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46452
`babel-plugin-codegen` transforms `codegenNativeComponent`s by expending it with a whole set of many commands (~40 lines) that don't have a good equivalent on the source file.
Currently these lines are pointing to random parts of the due to a bug that causes the source maps to be incorrect and confusing.
Instead, I point all these generated lines of code to the default export as the only line that can represent them.
This way, if an error is thrown from that generated code it would point to that export.
If the users are confused by how it works, there's a comment in the function that is used in the default export in these that explains it:
```
// If this function runs then that means the view configs were not
// generated at build time using `GenerateViewConfigJs.js`. Thus
// we need to `requireNativeComponent` to get the view configs from view managers.
// `requireNativeComponent` is not available in Bridgeless mode.
// e.g. This function runs at runtime if `codegenNativeComponent` was not called
// from a file suffixed with NativeComponent.js.
function codegenNativeComponent<Props>(
componentName: string,
options?: Options,
): NativeComponentType<Props> {
```
The transformation is from all the types and exports after the imports:
[`MyNativeViewNativeComponent` for example](https://github.com/facebook/react-native/blob/773a02ad5d3cc38e0f5837b42ba9a5e05a206bf9/packages/rn-tester/NativeComponentExample/js/MyNativeViewNativeComponent.js#L4)
Which is roughly (ignoring all typing):
```
// types and exports
export const Commands: NativeCommands = codegenNativeCommands<NativeCommands>({
supportedCommands: [
'callNativeMethodToChangeBackgroundColor',
'callNativeMethodToAddOverlays',
'callNativeMethodToRemoveOverlays',
'fireLagacyStyleEvent',
],
});
export default (codegenNativeComponent<NativeProps>(
'RNTMyNativeView',
): MyNativeViewType);
```
to roughly:
```
var React = require('react');
var nativeComponentName = 'RNTMyNativeView';
var __INTERNAL_VIEW_CONFIG = {
uiViewClassName: 'RNTMyNativeView',
bubblingEventTypes: {
topIntArrayChanged: { /* */ },
topAlternativeLegacyName: { /* */ },
},
validAttributes: {
opacity: true,
values: true,
...require('ViewConfigIgnore').ConditionallyIgnoredEventHandlers({
onIntArrayChanged: true,
onLegacyStyleEvent: true
})
}
};
var _default = require('NativeComponentRegistry').get(nativeComponentName, () => __INTERNAL_VIEW_CONFIG);
var Commands = {
callNativeMethodToChangeBackgroundColor(ref, color) {
require('RendererProxy').dispatchCommand(ref, "callNativeMethodToChangeBackgroundColor", [color]);
},
callNativeMethodToAddOverlays(ref, overlayColors) {
require('RendererProxy').dispatchCommand(ref, "callNativeMethodToAddOverlays", [overlayColors]);
},
callNativeMethodToRemoveOverlays(ref) {
require('RendererProxy').dispatchCommand(ref, "callNativeMethodToRemoveOverlays", []);
},
fireLagacyStyleEvent(ref) {
require('RendererProxy').dispatchCommand(ref, "fireLagacyStyleEvent", []);
}
};
exports.default = _default;
exports.__INTERNAL_VIEW_CONFIG = __INTERNAL_VIEW_CONFIG;
exports.Commands = Commands;
```
Changelog: [Fix] Fixed source maps in Native Components JS files that use codegenNativeComponent
Reviewed By: robhogan, huntie
Differential Revision: D62443699
fbshipit-source-id: 522b4382736a8fed93a1bc687a78d6885fe7c9d5
Benoit Girard
Rodolfo Gomez Sirimarco
Nishan
Alex Taylor (alta)
javache (Meta Employee)
Eli White
Samuel Susla
Rexogamer
Alex Hunt
Yedidya Feldblum
Rubén Norte
MasGaNo
anirudh.bharti
Oskar Kwaśniewski
legobt
Vin Xi
Riccardo Cipolleschi
Shawn Dempsey
Nick Gerleman
Eric Rozell
Alan Lee
Vincenzo Vitale
Stephanie Nicholson
shubhamguptadream11
Saad Najmi
Pascoal Júnior
Vitali Zaidman