Summary:
This PR fixes https://github.com/facebook/react-native/issues/41874.
## 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] - Fix NSAppTransportSecurity being overwritten during pod install
Pull Request resolved: https://github.com/facebook/react-native/pull/41875
Test Plan:
1. Delete the whole `NSAppTransportSecurity` in Info.plist and run `pod install`: `NSAllowsArbitraryLoads` and `NSAllowsLocalNetworking` are added as expected.
2. Modify `NSAppTransportSecurity` to only contain `NSExceptionDomains` and run `pod install`: `NSAllowsArbitraryLoads` and `NSAllowsLocalNetworking` are added, and `NSExceptionDomains` is still there.
3. Run `pod install` again: nothing changes.
Reviewed By: christophpurrer
Differential Revision: D52032400
Pulled By: dmytrorykun
fbshipit-source-id: 48cf29809c283af80613ffbf1ac0dc663a0a2fb5
Summary:
The logic to constrain the last spacer size is incorrect in some cases where the spacer is the last spacer, but not the last section in the list.
For more context, the role of spacer constraining is explained in this comment:
```
// Without getItemLayout, we limit our tail spacer to the _highestMeasuredFrameIndex to
// prevent the user for hyperscrolling into un-measured area because otherwise content will
// likely jump around as it renders in above the viewport.
```
For example it is incorrect in the case where we have:
ITEMS
SPACER
ITEMS
In this case the spacer is not actually the tail spacer so the constraining is incorrectly appied.
This causes issues mainly when using `maintainVisibleContentPosition` since it will cause it to scroll to an incorrect position and then cause the view that was supposed to stay visible to be virtualized away.
## Changelog:
[GENERAL] [FIXED] - Fix last spacer constrain logic in VirtualizedList
Pull Request resolved: https://github.com/facebook/react-native/pull/41846
Test Plan:
Tested using https://gist.github.com/janicduplessis/b67d1fafc08ef848378263208ab93d4c in RN tester, before the change content will jump on first click on add items.
Tested using the same example and setting initial posts to 1000, then we can see our content view size is still constrained properly (see scrolling indicator as reference).
Reviewed By: yungsters
Differential Revision: D51964500
Pulled By: NickGerleman
fbshipit-source-id: 4465aa5a36c95466aef6571314973c1e2c9a0f2c
Summary:
This enables the network panel/inspector by passing the `unstable_enableNetworkPanel=true` to the React Native JS Inspector. (See https://github.com/facebookexperimental/rn-chrome-devtools-frontend/pull/2)
By setting this inside the `experiments`, we can enable/disable network related CDP handlers within the proxy.
## Changelog:
[GENERAL] [ADDED] - Add `enableNetworkInspector` experiment to enable Network panel and CDP handlers in inspector proxy
Pull Request resolved: https://github.com/facebook/react-native/pull/41787
Test Plan: TBD, will provide a repository using an Expo canary / RN 0.73.0-rc release.
Reviewed By: NickGerleman
Differential Revision: D51811892
Pulled By: huntie
fbshipit-source-id: 541d96b6f0735104a4050a24a152e1158871ed1d
Summary:
This diff is reverting D49509633
D49509633: [react-native][PR] fix: Text cut off issues when adjusting text size and font weight in system settings by ryancat has been identified to be causing the following test or build failures:
Tests affected:
- [xplat/endtoend/jest-e2e/apps/facebook_xplat/ReactNativeTTRCTester/__tests__/ReactNativeTTRCTester-errorReportedManually-android-e2e.js](https://www.internalfb.com/intern/test/281475019301157/)
Here's the Multisect link:
https://www.internalfb.com/multisect/3131615
Here are the tasks that are relevant to this breakage:
We're generating a revert to back out the changes in this diff, please note the backout may land if someone accepts it.
If you believe this diff has been generated in error you may Commandeer and Abandon it.
Reviewed By: NickGerleman
Differential Revision: D49645585
fbshipit-source-id: 414531e067cffa109d0663d6af185dcaf8fb9c4e
Summary:
This is my proposed solution to https://github.com/facebook/react-native/issues/41677.
Fixes https://github.com/facebook/react-native/issues/41677.
## Changelog:
[ANDROID] [FIXED] - Fix android root view group removal during instance re-creation
Pull Request resolved: https://github.com/facebook/react-native/pull/41678
Test Plan:
Both with fabric enabled and disabled (new architecture):
1. Clone repro repo: https://github.com/wschurman/rn-reload-repro
2. Build and run on android (I use android studio)
3. Click reload button, see timestamp doesn't change (indicating that the view is not removed)
4. Apply this PR as a patch.
5. Re-build and run.
6. Click reload button, see view is correctly disposed of and the new view is set.
Reviewed By: cortinico
Differential Revision: D51658524
Pulled By: javache
fbshipit-source-id: d9a026cde677ad1ec113230bc31bd9297bca8bfc
Summary:
`build_codegen!` currently assumes that `react-native/codegen` gets installed next to `react-native`. In a pnpm setup, it's found under `/~/react-native/node_modules/react-native/codegen` instead.
However, as dmytrorykun pointed out, we don't actually need to build it outside of this repository.
## Changelog:
[GENERAL] [FIXED] - `react-native/codegen` shouldn't be built unless it's in the repo — fixes `pod install` failures in pnpm setups
Pull Request resolved: https://github.com/facebook/react-native/pull/41399
Test Plan: We have a patched version of `react-native` working in a pnpm setup here: https://github.com/microsoft/rnx-kit/pull/2811
Reviewed By: dmytrorykun
Differential Revision: D51201643
Pulled By: cipolleschi
fbshipit-source-id: 53767ae08686a20f03b3b93abcbc7d5383083872
In pnpm setups, codegen will fail during build because it cannot find
its dependencies. Some of the dependencies it relies on at runtime are
currently declared under `devDependencies`. This change moves them to
`dependencies`.
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41621
Currently, if you have a dependency that is alphabetically smaller than `app`, it's evaluation will happen before `app`.
This means that the namespace auto-discovery and the JVM toolchain configuration won't be working and the project will fail to buid.
This fixes it by introducing a root-project Gradle Plugin that takes care of enforcing the evaluation order on the `app` project.
Fixes#41620
Changelog:
[Android] [Fixed] - Fix projects being broken on dependencies starting with `a..`
Reviewed By: huntie
Differential Revision: D51547294
fbshipit-source-id: 65df7149548b7087dd8928e556fb803b3baf7b79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41614
Fixes https://github.com/facebook/react-native/issues/41545
SafeAreaView works by adding padding in order to shift content out of the safe area. This may change the layout dimensions of the SafeAreaView, in turn effecting its safe area insets.
This can cause layout results to change, which in turn changes the inset value. Because of this, there is a tolerance, where safe area inset changes do not trigger a new update.
Yoga is instructed to round layout dimensions to the closest physical pixel, so a very small difference in layout may result being off by about a pixel. Right now the tolerance is exactly one physical pixel, and if there is FP error here, we may not pass the test, and start oscillating with different layout values.
After changing affected ShadowNode order to always be root-first, the first call to set the frame of the `SafeAreaView` happens when a non-zero-sized RootView is present, which I think may lead to a safe area inset update communicated that wasn't before? Or other cosmic butterflies. Layout rounds to one physical pixel in difference, and our tolerance is `0.00001` dips off (not helped that 1/3 screen scale cannot be represented as decimal, even without FP error).
This adds a small tolerance beyond just the pixel boundary, matching the logic in Fabric, which seems to resolve the issue.
Changelog:
[iOS][Fixed] - FP Tolerance in iOS Paper SafeAreaView debouncing
Reviewed By: philIip
Differential Revision: D51539091
fbshipit-source-id: 88bddc38c7cd8d93feef5f12da64b124af22f46d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41535
## Context
**Remote JS Debugging removal**
In React Native 0.73, we have deprecated Remote JS Debugging (execution of JavaScript in a separate V8 process) and also removed the Dev Menu launcher (https://github.com/facebook/react-native/pull/36754).
## This diff
Follows D46187942 — this option wasn't correctly removed for Android when running JSC. This is now consistent with iOS.
Changelog:
[Android][Changed] "Open Debugger" is no longer available for remote JS debugging from the Dev Menu (non-Hermes). Please use `NativeDevSettings.setIsDebuggingRemotely()`.
Reviewed By: blakef
Differential Revision: D50555095
fbshipit-source-id: 1aeb48ab1390dc12ce300d6f321c30de5343cf0a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41036
Changelog:
[Added] - Shipping the new event dispatching pipeline that immediately moves events over to the C++ queue. This should unblock useDeferredValue + useTransition interruptibility on Android.
Reviewed By: javache
Differential Revision: D50365981
fbshipit-source-id: ecf60e5bc29fb4568463568a6ede4330e0294fd3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39671
Since minsdk version was increased to 23, we are deleting code using Android APIs < 23 for class ReactEditText
changelog: [Android][Breaking] Remove support for Android API < 23 in ReactEditText
Reviewed By: NickGerleman
Differential Revision: D48545507
fbshipit-source-id: 98be52ba36248962864e99e80ff648bbb351ff61
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41499
After D48152876 we consume JSI from `ReactCommon/jsi`, and ignore JSI that is distributed with `hermes-engine`.
This diff removes `include/jsi` from `source_files` of `hermes-engine` so we don't get two sets of JSI headers - one from `ReactCommon`, and the other one from `hermes-engine`.
This diff also fixes accidental breakage of ODR violation. We will no longer compile JSI into `react-native` when linking against `hermes-engine`, which already has JSI in it.
Changelog: [iOS][Fixed] - Exclude JSI headers when using hermes-engine prebuilt.
Reviewed By: cipolleschi
Differential Revision: D51347562
fbshipit-source-id: 6e4b9940c43d74d227a05999926b8752d7685670
Summary:
Recently, both `metro-inspector-proxy`(https://github.com/facebook/react-native/pull/39045) and `react-native-community/cli-plugin-metro`(https://github.com/facebook/react-native/pull/38795) were moved to this repo and in the process of moving these packages, the `exports` field inside package.json was added, only exporting the `index.js` file.
The problem is that Expo CLI (and possibly other community packages) rely on functions and classes that are not exported in the `index.js` file, e.g. Importing the InspectorProxy class from `react-native/dev-middleware/dist/inspector-proxy/InspectorProxy`. Normally this wouldn't be a problem and we would just import from `dist/` but due to the `exports` field, attempting to import from any other file not specified on this field will result in a `ERR_PACKAGE_PATH_NOT_EXPORTED` error.
As a short-term fix, we should create `unstable_`-prefixed exports of individual features Expo currently depends on.
## Changelog:
[INTERNAL] [CHANGED] - Expose unstable_InspectorProxy and unstable_Device from `react-native/dev-middleware`
Pull Request resolved: https://github.com/facebook/react-native/pull/41370
Test Plan: N / A
Reviewed By: robhogan
Differential Revision: D51163134
Pulled By: blakef
fbshipit-source-id: e67adaedc4fc64131e4c9dd8383c9877b8202283
Summary:
There is a problem in the way that we check if Fabric is enabled inside `react_native_post_install`.
https://github.com/facebook/react-native/blob/899e7cdb55197fc17a96a93af4f8bcc7519553c2/packages/react-native/scripts/react_native_pods.rb#L239
We're determining if fabric is enabled by checking if the `React-Fabric pod `is present, but since we always call `setup_fabric!(:react_native_path => prefix)` (https://github.com/facebook/react-native/pull/39057) inside `use_react_native` the `React-Fabric` pod is always present causing the `-DRN_FABRIC_ENABLED` flag to always be added to `project.pbxproj` even if the new arch is disabled.
[IOS] [FIXED] - Fix ios pod post_install logic for detecting if fabric is enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/41284
Test Plan: Run `use_react_native!(fabric => false)` should not add the `-DRN_FABRIC_ENABLED` flag to `project.pbxproj`
Reviewed By: fkgozali
Differential Revision: D50896487
Pulled By: cipolleschi
fbshipit-source-id: 78154407ce52b09fd3a317b7dc64bd4bba56363e
Distiller
Luna Wei
Alex Hunt
szymonrybczak
Rui Ying
Janic Duplessis
Alex Hunt
Cedric van Putten
Krzysztof Piaskowy
Michał Pierzchała
Distiller
Distiller
generatedunixname89002005232357
Distiller
Will Schurman
Distiller
Tommy Nguyen
Nicola Corti
Riccardo Cipolleschi
Nick Gerleman
Christoph Purrer
Distiller
Thibault Malbranche
Luna Wei
Jesse Watts-Russell
David Vacca
Dmitry Rykun
Gabriel Donadel
Kacper Kafara
Riccardo Cipolleschi
Distiller