This project is mirrored from https://github.com/facebook/react-native.git.
Pull mirroring updated .
- Apr 09, 2024
-
-
Evert Eti authored
Summary: In https://github.com/th3rdwave/react-native-safe-area-context/issues/448 it was noticed that from 0.72 (https://github.com/facebook/react-native/commit/bc766ec7f8b18ddc0ff72a2fff5783eeeff24857 https://github.com/facebook/react-native/pull/35889) it was possible to get a deadlock in dispatchViewUpdates. ([More details](https://github.com/th3rdwave/react-native-safe-area-context/issues/448#issuecomment-1871155936)) This deadlock resulted in a laggy experience for all users using https://github.com/th3rdwave/react-native-safe-area-context/ on Android. To avoid this problem, the author of the original fix [proposed](https://github.com/th3rdwave/react-native-safe-area-context/issues/448#issuecomment-1872121172) this solution which was tested by Discord and many other users. It would be great to have this backported to 0.72 and 0.73 because of the large userbase using react-native-safe-area-context since it's recommended by expo and react-navigation. <!-- Help reviewers and the release process by writing your own changelog entry. Pick one each for the category and type tags: [ANDROID] [FIXED] - Fixed possible deadlock in dispatchViewUpdates For more details, see: https://reactnative.dev/contributing/changelogs-in-pull-requests --> [ANDROID] [FIXED] - Fixed possible deadlock in dispatchViewUpdates Pull Request resolved: https://github.com/facebook/react-native/pull/43643 Test Plan: The original memory leak remains fixed, and can be verified in https://github.com/feiyin0719/RNMemoryLeakAndroid. To verify the deadlock is gone, every app using https://github.com/th3rdwave/react-native-safe-area-context will work smoothly and not log any excessive `Timed out waiting for layout` (https://github.com/17Amir17/SafeAreaContext) Reviewed By: arushikesarwani94 Differential Revision: D55339059 Pulled By: zeyap fbshipit-source-id: c067997364fbec734510ce99b9994e89d044384a
-
- Mar 12, 2024
-
-
Alfonso Curbelo authored
-
- Mar 11, 2024
-
- Mar 09, 2024
-
-
Rick Hanlon authored
Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/43370 Component stacks with files ending in .ts, .tsx, or .jsx were skipped in LogBox reporting. This diff fixes the regex. Changelog: [General][Fixed] - Support .tsx, .ts, and .jsx in component stacks Reviewed By: yungsters Differential Revision: D54638526 fbshipit-source-id: a5271daaa7b687e8e075be3f94ab9b9c03f79b66
-
- Mar 08, 2024
-
-
Alfonso Curbelo authored
[RN][iOS][0.72] Fix flipper for Xcode 15.3
-
- Mar 07, 2024
-
-
Riccardo Cipolleschi authored
-
- Mar 01, 2024
-
-
Riccardo Cipolleschi authored
-
Riccardo Cipolleschi authored
-
- Feb 29, 2024
-
- Feb 27, 2024
- Feb 20, 2024
-
-
Szymon Rybczak authored
-
- Feb 17, 2024
-
-
Ken Tominaga authored
-
LIM Albert authored
Summary: This change allows activities to handle onRequestPermissionsResult callbacks (eg: registerForActivityResult) Fixes #42403 [Android][Changed] - Call super.onRequestPermissionsResult in ReactActivity's onRequestPermissionsResult() Pull Request resolved: https://github.com/facebook/react-native/pull/42478 Test Plan: **Without super.onRequestPermissionsResult() call**  **With super.onRequestPermissionsResult() call**  Reviewed By: cipolleschi Differential Revision: D52952198 Pulled By: cortinico fbshipit-source-id: 53b5dac65f6b5409d87b5fe7f8be659d7b48f70d
-
huangtaibin authored
Summary: Problem Causes: In ReactViewGroup, there is a conflict between the zIndex attribute and the removeClippedSubviews optimization attribute. When both are used at the same time, the array mDrawingOrderIndices in ViewGroupDrawingOrderHelper that records the rendering order of subviews is not reset when super is called in the updateSubviewClipStatus method to add and remove subviews. Solution:�Because there are many third-party components that inherit from or depend on ReactViewGroup, all methods for adding and removing subviews in ViewGroup need to be override in ReactViewGroup, and ViewGroupDrawingOrderHelper corresponding to handleAddView and handleRemoveView needs to be called in these methods. And all the precautions for directly calling super to add and remove subviews are changed to calling the overridden method by ReactViewGroup. Special Note: All addView related methods in ViewGroup will eventually be called to the addView(View child, int index, LayoutParams params) method, except addViewInLayout. Regarding the method of adding subviews, we only need to override addView(View child, int index, LayoutParams params) and addViewInLayout(View child, int index, LayoutParams params,boolean preventRequestLayout) in ReactViewGroup. ## Changelog: [Android] [Fixed] - Fix the crash in ReactViewGroup of https://github.com/facebook/react-native/issues/30785 Pull Request resolved: https://github.com/facebook/react-native/pull/40859 Reviewed By: NickGerleman Differential Revision: D50321718 Pulled By: javache fbshipit-source-id: 7fa7069937b8c2afb9f30dd10554370b1be5d515
-
Riccardo Cipolleschi authored
-
Luna Wei authored
-
- Feb 09, 2024
-
-
Rob Hogan authored
-
- Jan 29, 2024
-
-
Blake Friedman authored
Summary: Cocoapods 1.15 (https://github.com/facebook/react-native/issues/42698) current breaks the build, limit to version >= 1.13 & < 1.15 This is currently broken and affecting users, we'll remove this limit once Cocopods fixes the regression. It's currently blocking 0.73.3. ## Changelog: [iOS][Fixed] don't allow cocoapods 1.15.
-
- Jan 18, 2024
-
- Jan 15, 2024
-
-
Alex Hunt authored
Manually applied version of https://github.com/facebook/react-native/pull/42232
-
Oscar Franco authored
Summary: This is a continuation of my [last PR](https://github.com/facebook/react-native/pull/40914) which improved the symbolication of unhandled promise rejections. While I was developing another library I noticed I still got an error stack of the log adding and not of the error itself. The library I'm trying to debug does not throw a standard error object but rather a custom one, but it still contains the stack field. By passing this stack field to the logbox call I was able to get a better symbolicated stack trace. The exact line of the failure is not displayed but at least the correct file is. ## Changelog: <!-- Help reviewers and the release process by writing your own changelog entry. Pick one each for the category and type tags: [GENERAL] [ADDED] - Unhandled promise rejection - attach non-standard Error object stack info if possible For more details, see: https://reactnative.dev/contributing/changelogs-in-pull-requests Pull Request resolved: https://github.com/facebook/react-native/pull/42079 Test Plan: Test any unhandled promise rejection with a non-standard error (line 23, toString must not return `[object Error]`) and see if the correct (or at least a better) stack trace is shown. Here is the one I got before and after this change: <img src="https://github.com/facebook/react-native/assets/1634213/3d07faad-9535-42c9-8032-b4d8fe407e88" width="200" /> <img src="https://github.com/facebook/react-native/assets/1634213/2c39bd82-c7a1-4f58-8ac4-5c479bb96b6e" width="200" /> Reviewed By: huntie Differential Revision: D52431711 Pulled By: cipolleschi fbshipit-source-id: be2172d3b1e2fc3f72812faac372c83bc6dface2
-
Riccardo Cipolleschi authored
-
Alex Hunt authored
-
Riccardo Cipolleschi authored
-
- Jan 08, 2024
-
-
Riccardo Cipolleschi authored
- Jan 06, 2024
-
-
Tommy Nguyen authored
-
- Jan 05, 2024
-
-
Riccardo Cipolleschi authored
-
- Jan 04, 2024
-
-
Riccardo Cipolleschi authored
-
- Dec 20, 2023
-
-
Luna Wei authored
- Dec 19, 2023
-
-
fortmarek authored
#publish-packages-to-npm
-
Marek Fořt authored
* Prevent LogBox from crashing on long messages (#38005) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/38005 Fixes https://github.com/facebook/react-native/issues/32093 by guarding the expensive `BABEL_CODE_FRAME_ERROR_FORMAT` regex with a cheaper initial scan. (Longer term, we should reduce our reliance on string parsing and propagate more structured errors.) Changelog: [General][Fixed] Prevent LogBox from crashing on very long messages Reviewed By: GijsWeterings Differential Revision: D46892454 fbshipit-source-id: 3afadcdd75969c2589bbb06f47d1c4c1c2690abd * Update RNTester Podfile.lock * Check for major ruby version --------- Co-authored-by:
Moti Zilberman <moti@meta.com>
-
Riccardo Cipolleschi authored
Summary: Since yesterday evening (why it is always friday evening???) CircleCI or Gem decided to update the default bundler version that is installed with `gem bundle install`. Therefore, CI for iOS stopped working. This change installs bundler's versions so that they are compatible with the Ruby version. [Internal] - Fix CI for iOS installing versions of bundler that are compatible with Ruby Pull Request resolved: https://github.com/facebook/react-native/pull/41962 Test Plan: CircleCI is green Reviewed By: GijsWeterings Differential Revision: D52230544 Pulled By: cipolleschi fbshipit-source-id: 2f96e16ecb94159953056e8de757ea4d249f80f0
-
Pieter De Baets authored
Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/37481 ViewManagers inherit from BaseJavaModule so we should honour the same lifecycle for them as we do for native modules, which is to call `invalidate` / `onCatalystInstanceDestroy` when the ReactContext is destroyed. This allows the ViewManager to do any cleanup which cannot happen at the View level. Changelog: [Android][Fixed] ViewManagers now receive an invalidate callback Reviewed By: cortinico Differential Revision: D45945678 fbshipit-source-id: 27c26d951b50a734c42eb033a46e599ef939e29f
-
- Dec 07, 2023
-
-
Tommy Nguyen authored
`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.
-
Tommy Nguyen authored
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`.
-
- Nov 14, 2023
-
- Nov 10, 2023
-
-
Marek Fořt authored
Summary: For a very long time when a promise rejects without an attached catch we get this warning screen without a correct stack trace, only some internal calls to the RN internals. <img src="https://github.com/facebook/react-native/assets/1634213/75aa7615-ee3e-4229-80d6-1744130de6e5" width="200" /> I created [an issue for discussion](https://github.com/react-native-community/discussions-and-proposals/discussions/718) in the react-native-community repo and we figured out it was only a matter of symbolication. While it cannot be done on release without external packages and source maps, at least while developing we can provide a symbolicated stack-trace so developers can better debug the source of rejected promise. I got the stack trace symbolicated and the correct code frame. I'm missing some help trying to display it in the warning view but at the very least I can now correctly show the line of the error and log the codeframe to the console. <!-- Help reviewers and the release process by writing your own changelog entry. Pick one each for the category and type tags: [GENERAL] [FIXED] - Show correct stack frame on unhandled promise rejections on development mode. For more details, see: https://reactnative.dev/contributing/changelogs-in-pull-requests Pull Request resolved: https://github.com/facebook/react-native/pull/40914 Test Plan: I simply created a throwing function on a dummy app, and checked the output of the console and the warning view: ```ts import React from 'react'; import {SafeAreaView, Text} from 'react-native'; async function throwme() { throw new Error('UNHANDLED'); } function App(): JSX.Element { throwme(); return ( <SafeAreaView> <Text>Throw test</Text> </SafeAreaView> ); } export default App; ``` Here is the output <img src="https://github.com/facebook/react-native/assets/1634213/2c100e4d-618e-4143-8d64-4095e8370f4f" width="200" /> Edit: I got the warning window working properly: <img src="https://github.com/facebook/react-native/assets/1634213/f02a2568-da3e-4daa-8132-e05cbe591737 " width="200" /> Reviewed By: yungsters Differential Revision: D50324344 Pulled By: javache fbshipit-source-id: 66850312d444cf1ae5333b493222ae0868d47056 Co-authored-by:
Oscar Franco <ospfranco@gmail.com>
-