forked from facebook/react-native
-
Notifications
You must be signed in to change notification settings - Fork 157
Merge up to 0.73.8 upstream release
#2124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…archive_0.73 [Yoga][0.73] Fix archive for MacOS Catalyst
Summary: In AppAndFlow/react-native-safe-area-context#448 it was noticed that from 0.72 (facebook@bc766ec facebook#35889) it was possible to get a deadlock in dispatchViewUpdates. ([More details](AppAndFlow/react-native-safe-area-context#448 (comment))) 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](AppAndFlow/react-native-safe-area-context#448 (comment)) 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: facebook#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
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 facebook#30785 Pull Request resolved: facebook#40859 Reviewed By: NickGerleman Differential Revision: D50321718 Pulled By: javache fbshipit-source-id: 7fa7069937b8c2afb9f30dd10554370b1be5d515
…ScrollView length (facebook#43563) Summary: Pull Request resolved: facebook#43563 Fixes facebook#42874 ## Sumary D9405703 added some custom logic for Flings, to support FlatList scenarios where content is being added on the fly, during Fling animation. This works by allowing start Fling to not have bounds, then correcting/cancelling Fling when overscroll happens over a bound that would normally be allowed. This has some math to try to determine max content length, and will clamp to this when scrolling over it. This logic is incorrect when content length is less than scrollview length, and we end up snapping to a negative offset. This change adds clamping, so that we don't snap to negative position in horizontal scroll view. This clamping was already indirectly present on vertical scroll view. https://www.internalfb.com/code/fbsource/[b43cdf9b2fec71f5341ec8ff2d47e28a066f052e]/xplat/js/react-native-github/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/scroll/ReactScrollView.java?lines=609 ## Test Plan Above issue no longer reproes. Flinging while content is being added to horizontal FlatList still works correctly. Changelog: [Android][Fixed] - Fix Android HorizontalScrollView fling when content length less than ScrollView length Reviewed By: javache Differential Revision: D55108818 fbshipit-source-id: 7cf0065f9f92832cc2606d1c7534fc150407b9c9
Summary: This allows build configuration named like `StagingDebug` to match with settings applied to `Debug` This fixes facebook#43185 Custom build setting were only applied to `Debug` build configurations, preventing configurations named `StagingDebug` or similar to access the new experimental debugger, as reported in facebook#43185 This now applies the setting to every configuration ending with `Debug` ## Changelog: [IOS] [CHANGED] - fix: build settings for custom build configuration Pull Request resolved: facebook#43780 Reviewed By: dmytrorykun Differential Revision: D55688996 Pulled By: cipolleschi fbshipit-source-id: 1f34cd722f6acfaa08d3377e19a04d08af97ed7c
Summary: Changelog: [iOS][Added] this creates the RN privacy manifest in the ios build step if user has not created one yet. the reasons have been added for the following APIs: NSPrivacyAccessedAPICategoryFileTimestamp - C617.1: We use fstat and stat in a few places in the C++ layer. We use these to read information about the JavaScript files in RN. NSPrivacyAccessedAPICategoryUserDefaults - CA92.1: We access NSUserDefaults in a few places. 1) To store RTL preferences 2) As part of caching server URLs for developer mode 3) A generic native module that wraps NSUserDefaults NSPrivacyAccessedAPICategorySystemBootTime - 35F9.1: Best guess reason from RR API pulled in by boost Reviewed By: cipolleschi Differential Revision: D53687232 fbshipit-source-id: 6dffb1a6013f8f29438a49752e47ed75c13f4a5c
For pick request reactwg/react-native-releases#242
Summary: Pull Request resolved: facebook#44185 This change will fix a symbol not found for JSC Runtime. The `if` check was not a compile time check, therefore the symbol ended up in the binary even if it is not available. Following this post on [Apple forum](https://forums.developer.apple.com/forums/thread/749534), this changes should do the trick. ## Changelog [iOS][Fixed] - Fix Symbol not found: (_JSGlobalContextSetInspectable) Reviewed By: hash3r Differential Revision: D56425834 fbshipit-source-id: a37af51b078bd47a938e6b65d9d8e0f7506e746f
Summary: Set the proper build flags for debugging in Bridgeless mode. This fixes [facebook#44240](facebook#44240) ## Changelog: [iOS][Fixed] - Add `HERMES_ENABLE_DEBUGGER=1` flag to React-RuntimeApple Reviewed By: cortinico Differential Revision: D56575647 fbshipit-source-id: a0613a5d46caeb1d3e636e54ecd43428fbaf46e8
mganandraj
approved these changes
May 21, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary:
Merge up to RN Core's
0.73.8release, with one notable change:Test Plan:
CI should pass.