Summary:
I discovered that 0.69 and 0.70 could run React Native as Dynamic framework with JSC and starting from 0.71 that's not possible anymore.
This diff restore that possibility.
## Changelog
[iOS][Fixed] - Add Back dynamic framework support for the old architecture
Reviewed By: cortinico
Differential Revision: D42829137
fbshipit-source-id: 848672f714d8bab133e42f5e3b80202b350d5261
Summary:
In a mono-repo the `react-native` package could be hoisted compared to the app directory, in which case it's not a good strategy for the `react-native-xcode.sh` script to guess the app project root relative to the location of itself. Instead I suggest to relying on a build setting provided by Xcode to derive the default app path.
I could have use the `SRCROOT` instead. According to https://stackoverflow.com/questions/36323031/what-the-different-between-srcroot-and-project-dir this is equivalent and also a bit less ambiguous as I see it. I.e. I would expect most Xcode projects to be located in the `ios` directory of the app.
As a workaround, before this merge, users can add the following to their "Bundle React Native code and images" build phase or `ios/.xcode.env` file:
```shell
export PROJECT_ROOT="$PROJECT_DIR/.."
```
This build phase can also be used for users wanting to revert this default behaviour once merged.
## Changelog
[iOS] [Changed] - Changed default `PROJECT_ROOT` (used in when bundling for iOS) to rely on the `PROJECT_DIR` build setting.
Pull Request resolved: https://github.com/facebook/react-native/pull/35970
Test Plan:
I've updated this locally and verified this does indeed pick up the correct app path - even in a mono-repo.
To verify this:
- Instantiate the template with this patch applied.
- Update the "Run scheme"'s "Build Configuration" to "Release".
- Build the app without errors.
Reviewed By: cortinico
Differential Revision: D42842636
Pulled By: cipolleschi
fbshipit-source-id: 040c31ac59a8abec5f5b38f795c8e74649420bac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35991
Changelog: [Internal]
While cherry-picking all this logic to `0.71-stable` branch, we've discovered several issues where some packages were failing to be published on Verdaccio proxy
This was failing only on node v16+, after some research, I've noticed that there might be a race-condition and npm unable to grab this token before first `npm publish` executes
Although this still work well on `main` branch, I am backporting it to keep aligned with `0.71-stable`
Reviewed By: christophpurrer, cortinico
Differential Revision: D42806081
fbshipit-source-id: af244d26ea529e6085ed5b2d731623dfaf78a14d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35984
[Changelog][Internal]
Codegen for props parsing was failing to add a required include for the case when the type is an array of objects, which in turn use non-trivial types.
Something like:
```
export type NativeProps = $ReadOnly<{
...ViewProps,
bounds: $ReadOnlyArray<
$ReadOnly<{
height?: Float,
left?: Float,
top?: Float,
width?: Float,
}>,
>,
}>;
```
would cause compilation errors on C++ side, since the required header for the `Float` conversion wasn't included.
Reviewed By: cipolleschi
Differential Revision: D42781128
fbshipit-source-id: d5b133b931a60e414761db0b3ed09893d3fcc9aa
Summary:
I'm moving nightlies from scheduled workflow to scheduled pipeline.
We're not able to manually retrigger nightlies as they're a scheduled workflow and don't expose a parameter. Here I'm cleaning it up.
Plus I'm:
1. Removing the `main_only` reference which is unused
2. Setting up the `run_release_workflow` and `run_nightly_workflow` parameters.
## Changelog
[INTERNAL] - Migrate nightly from scheduled workflow to scheduled pipeline
Pull Request resolved: https://github.com/facebook/react-native/pull/35977
Test Plan: Will wait for CI results.
Reviewed By: cipolleschi
Differential Revision: D42776969
Pulled By: cortinico
fbshipit-source-id: d4ef9654d23cb91f85ce2b38e75e27dc0c575e95
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35953
DimensionValue is a reserved prop type that can be a number or string (such as '50%'). On Java, it will get converted to a YogaValue (converter added to this diff); on C++ it will get converted to a YGValue (converter already exists as it's used in Fabric).
Changelog:
[Internal][Added] - Add codegen support for DimensionValue for components
Reviewed By: cipolleschi
Differential Revision: D42650799
fbshipit-source-id: 1d2bc30bbd93837dedbbb4c74f814963c8140957
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35961
Pull Request resolved: https://github.com/facebook/react-native/pull/35960
This fixes#35864
This feature allows using `$Partial<Obj>` in flow and `Partial<Obj>` in TypeScript based on the spec mentioned here: https://flow.org/en/docs/types/utilities/#toc-partial.
We currently only allow passing an Obj to Partial so
```
export type SomeObj = {
a: string,
b?: boolean,
};
export type PartialSomeObj = Partial<SomeObj>;
```
should work.
and also-
```
export type PartialSomeObj = Partial<{
a: string,
b?: boolean,
}>;
```
But not
```
export type PartialSomeObj = Partial<Partial<{
a: string,
b?: boolean,
}>>;
```
This can be improved in the future by a recursive unwrapping of the value inside the `Partial` annotation.
Changelog:
[General] [Added] - Allow the use of "Partial<T>" in Turbo Module specs.
Reviewed By: christophpurrer, cipolleschi
Differential Revision: D42640880
fbshipit-source-id: 03a3fccc38ccfc7a5440fe11893beb68e77753f3
Summary:
We still see crashes for T112157805 and this diff is to add missing information to help diagnose the issue better.
We added a line of log to indicate which `mountItem` triggered the exception.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D42556576
fbshipit-source-id: 4283c34cb18d601ca7b80d3524c9c65cc4ae3f8a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35967
In https://github.com/facebook/react-native/issues/35936 we observed that the presence of AbsoluteSizeSpan may lead to hangs when using the Grammarly keyboard on Samsung.
This mitigation makes it so that we do not emit this span in any case where it is sufficient to rely on already set EditText textSize. In simple cases, tested on two devices, it causes typing into the TextInput to no longer hang.
This does not fully resolve the issue for TextInputs which meaningfully use layout-effecting spans (or at least font size), such as non-uniform text size within the input. We instead just try to reduce to minimum AbsoluteSizeSpan possible.
Testing the first commit was able to resolve hangs in some simpler inputs tested, by me and cortinico.
Changelog:
[Android][Fixed] - Mitigation for Samsung TextInput Hangs
Reviewed By: cortinico
Differential Revision: D42721684
fbshipit-source-id: e0388dfb4617f0217bc1d0b71752c733e10261dd
Summary:
changelog: Enable Layout Animations on iOS
[LayoutAnimations](https://reactnative.dev/docs/next/layoutanimation) in New Architecture have been disabled in OSS on iOS because of unresolved crash. This crash only happens rarely. Turning on LayoutAnimations in OSS should be safe and brings New Architecture to parity with old.
Reviewed By: fkgozali
Differential Revision: D42708774
fbshipit-source-id: b0f7febee3aa4f0ddac25556644198ebe79378c1
Summary:
While buildling locally, those two warnings pop up.
- ANDROID_LD being unused by the CMake toolchain. I'm removing it.
- The Download task encountering a weak eTag. I'm updating it:
https://github.com/michel-kraemer/gradle-download-task
Changelog:
[Internal] [Changed] - Fix a couple of warnings in the ReactAndroid:hermes-engine build
Reviewed By: dmytrorykun
Differential Revision: D42738919
fbshipit-source-id: 7bd8785ad5b7431d557e2f8c8876b7c3f7294a43
Summary:
Fixes conflicts in pod build settings like the one below:
Example warning
> Can't merge user_target_xcconfig for pod targets: ["RNReanimated", "hermes-engine"]. Singular build setting CLANG_CXX_LANGUAGE_STANDARD has different values.
Background:
> The former attribute xcconfig is deprecated and will cause a linter error when pushing new versions to trunk. The new attributes are available as pod_target_xcconfig and user_target_xcconfig, which makes their effects more clear. The latter attribute (user_target_xcconfig) should be used with great care, because well designed Pods should be self-contained and make as few assumptions about their environment as possible. Furthermore, this attribute can cause conflicts when different values are specified by two Pods for a build setting which doesn't allow multiple values and so cannot be merged.
- https://blog.cocoapods.org/CocoaPods-0.38/
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [FIXED] - Fix cocoapods warning about merging user_target_xcconfig
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/35954
Test Plan:
- Run in example app
## Related PR
- https://github.com/facebook/hermes/pull/903
Reviewed By: christophpurrer
Differential Revision: D42737921
Pulled By: jacdebug
fbshipit-source-id: 75d087a5287e660a703342d6e0ad6632f05f3c4c
Summary:
Bringing the typescript function signature in-line with the js code.
## Changelog
[GENERAL] [FIXED] - Added AlertOptions argument to the type definition for Alert.prompt to bring it into parity with the js code.
<!-- 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/35957
Test Plan: Before the change, VS Code would show a typescript error when I pass AlertOptions to Alert.prompt (even though the js would execute successfully and respect the options I passed. After the change, when I use an Alert.prompt in VS code the function signature was recognized without errors.
Reviewed By: christophpurrer
Differential Revision: D42737818
Pulled By: jacdebug
fbshipit-source-id: 4d4318f38f5c7b7302aae62de5ce224db67e088a
Summary:
This is a [change](https://github.com/microsoft/react-native-macos/pull/1120) we made in our fork (React Native macOS) that we are now upstreaming to reduce the number of diffs between React Native Core and React Native macOS. Also.. one less crash �!
Resolves https://github.com/microsoft/react-native-macos/issues/1679
Original PR notes:
> We've seen a crash downstream where -[NSString stringByReplacingCharactersInRange:withString:] receives a nil value as the replacement string. This is not good, since we expect that argument to be non-null.
>
>We believe that a cause of this is that -[RCTUITextField textView:shouldChangeTextInRange:replacementString:] is being called with nil as the replacement string. (This is legal, as per [Apple's documentation](https://developer.apple.com/documentation/appkit/nstextviewdelegate/1449325-textview?language=objc).) Right now, the only check that this delegate method does is enforcing the maxLength parameter if it exists, and changes in attributes shouldn't affect the length of the string.
## Changelog
[IOS] [FIXED] - `-[RCTUITextField textView:shouldChangeTextInRange:replacementString:]` no longer crashes when we pass in a `nil` replacement string
Pull Request resolved: https://github.com/facebook/react-native/pull/35941
Test Plan: Build should pass. This change has been running in our fork in production for a while so we're fairly confident of it.
Reviewed By: cipolleschi
Differential Revision: D42705382
Pulled By: jacdebug
fbshipit-source-id: 066cd8a4ba134a681f0f4c955594b1fcda61a30e
Summary:
Similar to the issue here https://github.com/facebook/react-native/pull/34503 but this is also happening if we just use `ScrollView` and `TextInput` with `automaticallyAdjustKeyboardInsets` enabled.
When we enable `Prefer Cross-Fade Transitions` in `iOS` we get a keyboard height of `0` which causes the inset/offset miscalculation and the content jumps up when the keyboard gets hidden.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [FIXED] - Fix ScrollView `automaticallyAdjustKeyboardInsets` not resetting when Prefer Cross-Fade Transitions is enabled and keyboard hides
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [FIXED] - Fix ScrollView `automaticallyAdjustKeyboardInsets` not resetting when Prefer Cross-Fade Transitions is enabled and keyboard hides
Pull Request resolved: https://github.com/facebook/react-native/pull/35933
Test Plan:
Tested with brand new react native project with/without the fix
before fix `automaticallyAdjustKeyboardInsets` with enabled/disabled opening/closing keyboard
https://user-images.githubusercontent.com/6507800/214039873-33bfb016-f99f-4644-9174-20bf32cf07d6.mov
after fix `automaticallyAdjustKeyboardInsets` with enabled/disabled opening/closing keyboard
https://user-images.githubusercontent.com/6507800/214039887-4054a749-ab15-4399-b6a9-73dc9283aa6b.mov
Reviewed By: christophpurrer
Differential Revision: D42686390
Pulled By: jacdebug
fbshipit-source-id: 98488e0c9639c19a4acae1a1de1a5fde411e2462
Summary:
Just a couple of minor fixes in the `template/` folder:
- Remove a trailing space in `rn_edit_text_material.xml` (this was the _only_ trailing space present in a newly generated RN project), which results in the check against the empty tree object failing:
```
$ git diff --check 4b825dc -- template/
template/android/app/src/main/res/drawable/rn_edit_text_material.xml:23: trailing whitespace.
+ <!--
```
- Add missing newline at end of file in `.watchmanconfig` and `app.json` - Both are text files, and each line (including the last) is expected to end with a newline character (flagged by Git, and also visible as a warning on GitHub):
<img width="369" alt="image" src="https://user-images.githubusercontent.com/743291/214195867-81c8e622-2130-44d4-bdaf-588e3510c109.png">
## Changelog
[GENERAL] [FIXED] - Fix whitespace and newline at EOF in template
Pull Request resolved: https://github.com/facebook/react-native/pull/35939
Reviewed By: christophpurrer
Differential Revision: D42698256
Pulled By: rshest
fbshipit-source-id: 765fd41d4f501aec578755c754ea0ecb290ae6ca
Summary:
Added comment on Podfile under template directory.
I'm working with monorepo and didn't realize it easily to specify the path for react_native_post_install, so I thought it would be better to add this comment.
## Changelog
[IOS] [ADDED] - add comments for specifying the path to React Native
<!-- 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
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/35931
Reviewed By: cipolleschi
Differential Revision: D42673707
Pulled By: jacdebug
fbshipit-source-id: 39e424a051d238f6dad42cb0b7748d4f4c400787
Summary:
This adds support for `maintainVisibleContentPosition` on Android. The implementation is heavily inspired from iOS, it works by finding the first visible view and its frame before views are update, then adjusting the scroll position once the views are updated.
Most of the logic is abstracted away in MaintainVisibleScrollPositionHelper to be used in both vertical and horizontal scrollview implementations.
Note that this only works for the old architecture, I have a follow up ready to add fabric support.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Added] - Add maintainVisibleContentPosition support on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/35049
Test Plan:
Test in RN tester example on Android
https://user-images.githubusercontent.com/2677334/197319855-d81ced33-a80b-495f-a688-4106fc699f3c.mov
Reviewed By: ryancat
Differential Revision: D40642469
Pulled By: skinsshark
fbshipit-source-id: d60f3e2d0613d21af5f150ca0d099beeac6feb91
Summary:
Changelog:
[Internal][Added] - Add support for props of type Array<EdgeInsetsValue>
Reviewed By: christophpurrer
Differential Revision: D42651078
fbshipit-source-id: 3b8683ab199c3d590136cec0e6a67e9e85aaa2c0
Summary:
This change aligns requestAnimationFrame implementation used in Jest environment with web standard, and with the implementation that runs in the application environment.
As per specification https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame#parameters – requestAnimationFrame callback gets a single parameter, which represents the current frame timestamp. The current polyfill maps requestAnimationFrame directly to setTimeout which makes the callback execute without any parameters.
## Changelog
[General] [Fixed] - Jest mocked requestAnimationFrame callbacks now receive a timestamp parameter
Pull Request resolved: https://github.com/facebook/react-native/pull/35919
Test Plan:
1. execute jest test suite to make sure nothing breaks
2. add the below code to one of the tests:
```
jest.useFakeTimers();
requestAnimationFrame((timestamp) => console.log("rAF", timestamp));
jest.runOnlyPendingTimers();
jest.useRealTimers();
```
this code will print `undefined` before and numer `0` representing the mocked frame time after this change.
Reviewed By: jacdebug
Differential Revision: D42676544
Pulled By: robhogan
fbshipit-source-id: 363dc506ccc4bd034408fbb35ad3151875a8d309
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35790
This diff apply to RNTester the same logic we have in the template to control the `use_framework!` setting
This is a preliminary change to solve the `use_frameworks!` problems in the New Architecture for both the Template and RNTester.
## Changelog:
[iOS][Changed] - Align RNTester usage of the USE_FRAMEWORKS flag to the template
Reviewed By: cortinico, dmytrorykun
Differential Revision: D42387701
fbshipit-source-id: 28baf5a65b727269d55382de286a17de30e8895b
Summary:
Fixed typo with the word "running" in 2 places when failing to open Flipper.
Fixes https://github.com/facebook/react-native/issues/35899 .
Changelog:
[Internal] [Changed] - Fix typo with the word "running" when failing to open Flipper
Pull Request resolved: https://github.com/facebook/react-native/pull/35910
Reviewed By: christophpurrer
Differential Revision: D42641042
Pulled By: sshic
fbshipit-source-id: acebb26ab921e98235c4f8e8535fa89be2ffa8cd
Summary:
Constructing a `JSError` currently catches all exceptions that occur,
regardless of their type, and embeds the information from them in the
newly created `JSError`. This means that the type of exceptions can be
silently changed.
This results in a bug if Hermes is built with
`HERMESVM_EXCEPTION_ON_OOM` enabled. The OOM exception will get
converted to a `JSError`, which in turn can get converted into a
regular JS exception. The regular JS exception can then be caught by JS
and ignored. This leads to the VM continuing to execute in a bad
state.
I considered three ways to fix this:
1. Add a new type of exception to JSI that is intentionally meant to be
ignored, and the Hermes OOM exception then subclasses it.
2. Propagate all exceptions that happen when constructing `JSError`.
3. Propagate all exceptions except `JSIException`s when constructing
`JSError`.
The first is technically the most surgical, but it adds complexity to
JSI, and will require some extra machinery to implement since we
wouldn't be able to throw it directly from inside the VM. I'm also not
comfortable with the idea of JSI suppressing exceptions that are
completely unrelated to JSI.
The second is the simplest, and seems to match what JS would do if
`throw new Error()` itself threw, but there is some possibility that it
is a change in behaviour for existing code.
So the third approach, which is implemented in this diff, tries to
compromise between the two. Hermes can only ever throw `JSIException`s
from regular JS operations, so there should be no change for existing
code (except code that uses exceptions on OOM, which is what we're
trying to fix). Any other exception gets passed through to the caller.
Changelog:
[Internal][Fixed] - Fixed handling of Hermes OOM exceptions in JSI.
Reviewed By: jpporto
Differential Revision: D41831616
fbshipit-source-id: 42e0dde1c4acc016ab19533941c58fc1797ba1c2
Summary: Changelog: [Internal] Infer whether a pointer supports hover or not by presence of events
Reviewed By: vincentriemer, NickGerleman
Differential Revision: D42589958
fbshipit-source-id: aa42affc98ef78ebbf9a6e420684ed098869b905
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35888
Changelog:
[Android][Removed] - For supporting Dev Loading View across multiple platforms, changed the Loading View of Android to rely on the native implementation instead of Toast. Getting rid of the JS changes relying on Toast for Dev Loading View now that the native module is released.
Reviewed By: rshest
Differential Revision: D42599220
fbshipit-source-id: ec7098b508c766c07384d48d3bffed075b092b72
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35901
[Changelog][Internal]
Partially reverts the change that was redirecting `performance` instance to the new implementation in WebPerformance, until the actual implementation becomes public and native modules are included by default.
Reviewed By: rubennorte
Differential Revision: D42607379
fbshipit-source-id: c1ce995d20b9dfe7aef8436cea00d89b81e32932
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35897
Fixes https://github.com/facebook/react-native/issues/35894
Android 11 added native support for querying whether the IME is present along with its size, as part of the WindowInsets API. D38500859 (1e48274223) changed our logic for Android keyboard events to use it when available, fixing a longstanding issues where we could not reliably tell where the keyboard was open depending on softInputMode.
An androidx library WindowInsetsCompat aimed to backport some of the functionality to older versions of Android, with the same API, documenting IME queries to work down to API level 23 (Android 6). I used this, so that we would be able to remove our own logic for detecting keyboard insets once we supported 23+.
From an issue report, WindowInsetsCompat is not accurately returning whether the IME is open on at least Android 9. So this change makes it so we only use WindowInsets methods when they are provided by the OS (a tested golden path), and otherwise use the previously working heuristics on anything older.
Changelog:
[Android][Fixed] - Do not use WindowInsetsCompat for Keyboard Events
Reviewed By: christophpurrer
Differential Revision: D42604176
fbshipit-source-id: da6a0bbc34c36f8e6d4e4ac07bc96da048fd6aa8
Summary:
This removes some unused flags which will cause Yoga to layout every tree twice, then diffing the tree, reporting whether the whole tree is different. This is too expensive to run outside of local experimentation, but we have more nuanced ways to implement the `YGNodeLayoutAffectedByQuirk` I am wanting to add.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D42406917
fbshipit-source-id: b415ed02768f6b59de3a6fa90c60c750d56fd4b0
Summary:
`accessibilityLabelledBy` is missing from `AccessibilityPropsAndroid` TypeScript interface
## Changelog
[GENERAL] [FIXED] - Added missing `accessibilityLabelledBy` TypeScript type
<!-- 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/35883
Test Plan: Ran `yarn test-typescript` and `yarn test-typescript-offline` and there were no errors.
Reviewed By: christophpurrer
Differential Revision: D42604287
Pulled By: NickGerleman
fbshipit-source-id: 476d24d1c0257be787b7e84c2c11bcadc3527979
Summary:
TurboModuleRegistry export functions and not a TurboModuleRegistry object. See https://github.com/facebook/react-native/blob/main/Libraries/TurboModule/TurboModuleRegistry.js#L37
## Changelog
[GENERAL] [FIXED] - Fix TurboModuleRegistry TS type
Pull Request resolved: https://github.com/facebook/react-native/pull/35885
Test Plan:
Tested that the import doesn't generate a type error when used correctly.
```ts
import * as TurboModuleRegistry from 'react-native/Libraries/TurboModule/TurboModuleRegistry';
export default TurboModuleRegistry.get<Spec>('RNCSafeAreaContext');
```
Reviewed By: christophpurrer
Differential Revision: D42604208
Pulled By: NickGerleman
fbshipit-source-id: e6259df24aaf6e37b32cc4b51947294fd655837e
Summary:
`accessibilityLanguage` is missing from `AccessibilityPropsIOS` TypeScript interface
## Changelog
[GENERAL] [FIXED] - Added missing `accessibilityLanguage` TypeScript type
<!-- 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/35882
Test Plan: Ran `yarn test-typescript` and `yarn test-typescript-offline` and there were no errors.
Reviewed By: christophpurrer
Differential Revision: D42604363
Pulled By: NickGerleman
fbshipit-source-id: fb8dd4b5bba78a080473a9dc7b49a07587530229
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35875
Fixes https://github.com/facebook/react-native/issues/35871
Nested VirtualizedLists register to their parents for updates, associated to a specfific cellKey set by VirtualizedListCellContextProvider. This cellKey is usually set when rendering a cell for a data item, but we can also render a nested VirtualizedList by putting one in a ListHeaderComponent/ListFooterComponent/ListEmptyComponent.
D6603342 (a010a0cebd) added cellKeys when we render from a header/footer, but not ListEmptyComponent, so that association would silently fail earlier.
D39466677 (010da67bef) added extra invariants to child list handling, that are now triggered by this case, complaining because we are trying to unregister a child list we never successfully registered, due to a missing cellKey.
This fixes the issue by providing a cellKey for ListEmptyComponent as well.
Changelog:
[General][Fixed] - Fix invariant violation when nesting VirtualizedList inside ListEmptyComponent
Reviewed By: christophpurrer
Differential Revision: D42574462
fbshipit-source-id: f76fa795bf471cb8a929c2efdbd814ea51927663
Summary:
react-native-navigation allows to register React components to be included in the navigation top bar as buttons, the way this work is by using the AppRegistry. When the ViewTreeObserver executes the `CustomGlobalLayout` we are checking for the RootWindowInsets in the `checkKeyboardEvents` which in the case for the top bar component it returns null and the **WindowInsetsCompat.toWindowInsetsCompat** function throws if the insets are null causing the app to crash.
Interestingly in the function `checkForKeyboardEventsLegacy` the null value is being checked, so I guess it was overlooked in the newer function.
## Changelog
[ANDROID] [FIXED] - Fix ReactRootView crash when root view window insets are null
Pull Request resolved: https://github.com/facebook/react-native/pull/35869
Test Plan:
The following videos show how the app crashes as soon as we attempt to pop a screen that contains a react component as a button in the navigation top bar and how it correctly pops to the previous screen after applying the fix
| Crash | Fix |
| -- | -- |
| https://user-images.githubusercontent.com/6757047/213116971-fe693989-f978-438c-b8f9-fc56f2a477c8.mp4 | https://user-images.githubusercontent.com/6757047/213118352-fe258f28-07aa-4d17-98d2-97136464ffd5.mp4 |
Reviewed By: cipolleschi
Differential Revision: D42580156
Pulled By: cortinico
fbshipit-source-id: 4dbd656d7c8148df67668a2a50913206bc35c07f
Riccardo Cipolleschi
Kræn Hansen
Samuel Susla
Ruslan Lesiutin
Sebastian Silbermann
Ruslan Shestopalyuk
SheetJS
Nicola Corti
Genki Kondo
Vitali Zaidman
Xin Chen
Marshall Roch
Nick Gerleman
mym0404
MaeIg
Joshua Kaplan
Paul Mandel
Saad Najmi
Prakash Gurung
Frieder Bluemle
sottar
Janic Duplessis
Arthur Kushka
fabriziobertoglio1987
Krzysztof Magiera
Mikhail Mikhaylov
Sheikh Jamir Alam
Vicary A
Neil Dhar
Luna Wei
Arushi Kesarwani
Devon Mars
Thibault Malbranche
Dimitar Nestorov
Elias Nahum
