Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46540
changelog: [internal]
avoid calling `runEventLoopTick` and execute task directly. runEventLoopTick is not designed to be called on re-entries.
Reviewed By: rubennorte
Differential Revision: D62871782
fbshipit-source-id: 259514d05eebed2e09d54233729994e56f2aa1a4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46551
We crash if we pass a shadow color with 0 alpha due to some divide by 0 logic. This fixes that for inset and outset shadows and adds a test for that case.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D62899047
fbshipit-source-id: 2aff1d016dd97bed024df1c3f89bcc62e49f0306
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46563
Changelog: [internal]
Our current implementation of view preallocation on Android runs very early in the frame (during the `animation` stage, after `input` and before `traversal`). In that implementation, we check the remaining time in the frame and we allocate half of that time for view preallocation.
This logic can make us drop frames unnecessarily, if the work that we need to do after this allocated time is longer than we expect. Because we don't know how long the `traversal` stage will be, we don't account for that time at all (or, at best, we do only use half of the remaining time).
This creates a feature flag to move view preallocation outside of the choreographer, so we can compute the remaining time considering all the work we did in the frame, and not just the work we did in the input stage.
Reviewed By: javache
Differential Revision: D62962341
fbshipit-source-id: 69aaeecc8596906e61b47af9adad23c1075a091a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46565
UIManager is initialized elsewhere in NativeAnimatedNodesManager so this is no longer required
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D62958646
fbshipit-source-id: af77ddbbc65124ed29d301340ad339d2a916f58c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46564
Changelog: [internal]
I incorrectly set up an experiment to fix reported scroll position during smooth scroll animations on Android in D59233069. It was incorrect because I fixed the issue in "control", and I re-enabled the bug in "test".
That means we actually shipped the fix the moment we set up the experiment.
We can just apply the fix ungated.
Reviewed By: Abbondanzo
Differential Revision: D62965254
fbshipit-source-id: edf855619ff9ede6fd406f7f19b3c504ce89f1d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46561
Changelog: [internal]
We have some logic in `MountItemDispatcher.tryDispatchMountItems` to recursively call itself for as long as there are new items to mount in the general queue. This queue is copied and processed every time `tryDispatchMountItems` is called, but it's possible that during this time new mount operations are added (either from JS or from the mount operations themselves).
This logic can cause frame drops, as we could be finish processing the current frame without processing new mount items (we could do that in the next frame, and in many cases it's just pre-rendering work and state updates that the user can't perceive anyway).
This creates a feature flag to test disabling this behavior and only process whatever mount items are queued at the start of the frame.
Reviewed By: sammy-SC
Differential Revision: D62958009
fbshipit-source-id: ca038c827715411375410215deb5d5e374f5fdb4
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:
This PR adds iOS ifdefs to `RCTUIManager` to subscribe to orientation changes on this platform.
The `UIDeviceOrientationDidChangeNotification` symbol is only available there.
## Changelog:
[IOS] [FIXED] - subscribe to orientation changes in RCTUIManager only on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/46531
Test Plan: CI Green
Reviewed By: philIip
Differential Revision: D62864013
Pulled By: cipolleschi
fbshipit-source-id: 341df9ac765735273378d017b63fcb7a4d8e98e5
Summary:
Analyze code was still using the CIRCLECI env variable to retrieve the PR number.
This change uses the github one and also removes a duplicated flow check
## Changelog:
[Internal] - Remove duplicated flow check and use gh PR number rather than CircleCI one
Pull Request resolved: https://github.com/facebook/react-native/pull/46548
Test Plan: Tested locally and in CI
Reviewed By: NickGerleman
Differential Revision: D62883758
Pulled By: cipolleschi
fbshipit-source-id: 0c7e97ea9caf4465972424e0b69a899ecfd07095
Summary:
This chang introduces a patch file that can be applied to run the E2E tests in CI.
From the root folder `react-native`, a user can just run:
```sh
git apply packages/rn-tester/scripts/enable-e2e-tests.patch
```
And then add a commit to their PR to see whether the newly added E2E tests are actually running
## Changelog:
[Internal] - add patch to simplify running E2E tests in CI
Pull Request resolved: https://github.com/facebook/react-native/pull/46546
Test Plan: Tested locally
Reviewed By: NickGerleman
Differential Revision: D62880559
Pulled By: cipolleschi
fbshipit-source-id: 19d639b2641aaa50e4f3e0753018d426d2da81c9
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
Samuel Susla
Joe Vilches
David Vacca
Rubén Norte
Pieter De Baets
Thomas Nardone
Dawid
Riccardo Cipolleschi
Dmitry Rykun
Oskar Kwaśniewski
Benoit Girard
Rodolfo Gomez Sirimarco
Nishan
Alex Taylor (alta)
javache (Meta Employee)
Eli White
Rexogamer
Alex Hunt
Yedidya Feldblum
MasGaNo
anirudh.bharti
legobt
Vin Xi
Shawn Dempsey
Nick Gerleman
Eric Rozell
Alan Lee
Vincenzo Vitale
Stephanie Nicholson