Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41056
As the title says,
I accidentally included this as the diff on top of it that would have made this flag toggleable was abandoned.
Changelog:
[Internal] [Changed] - Revert accidental bridgelessEnabled=true for RN Tester
Reviewed By: luluwu2032
Differential Revision: D50409804
fbshipit-source-id: 0e17883094f90e397544b2be0daee5f6cacd8756
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41058
Glog has a piece of code which looks like this:
```
namespace google {
// They need the definitions of integer types.
#include "glog/log_severity.h"
#include "glog/vlog_is_on.h"
```
This fragment is:
- Always valid when the pod does not define a module
- Valid for Xcode >= 14.3, when the pod do define a module
- Invalid for Xcode < 14.3, when the pod do define a module
Modules are required to support Swift, so, in the long run, we want to have `DEFINES_MODULE` set to `YES` for `Glog`.
This is a temporary workaround to keep supporting older versions of Xcode while Apple keeps allowing to use Xcode 14.1 to submit apps to the store.
Historically, Apple pushes the minimum version of Xcode every April, so we expect to be able to remove this workaround in April 2024.
## Changelog:
[Internal] - Make Glog work with older versions of Xcode
Reviewed By: cortinico
Differential Revision: D50410487
fbshipit-source-id: 96145cdf9ba1bc75622403d3c06454d6d4bfd967
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40948
## Changelog:
[iOS][Breaking] alertAction is deprecated in PushNotificationIOS. getScheduledLocalNotifications now uses new iOS APIs which do not expose this property.
Reviewed By: cipolleschi
Differential Revision: D50275541
fbshipit-source-id: e4ecad858cd06350c749e7f5a837f36316656183
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41063
Some tests for RuntimeScheduler broke because we used uninitialized values incorrectly (they're initialized with 0 on Android but with something like `0101010101...` on iOS).
This fixes the tests by assigning the right initial value.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D50413220
fbshipit-source-id: e1fc223e795e2ae01d6e3ba3bc32bd052c8fc2f3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41052
When we animate an Animated.Value that has multiple components (eg Animated.Color, AnimatedXY), we have no guarantee that the animation callbacks will be processed in a single React commit. Previously, we attempted to work around this by ignoring these updates in `__findAnimatedPropsNodes`, but that leads to other issues.
Instead, force all animation completions that happen in a single frame to be processed together by emitting them as a single event (Note: this only works when using the singleOpBatching flag for Animated which hasn't been rolled out)
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D50366676
fbshipit-source-id: 613920056113b6515792e80e06254b92061bc335
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40999
Fast refresh banner for Android was introduced for Bridge-only (D42286425), in this diff we enable it for Bridgeless as well.
Changelog:
[Android][Changed] - Enable fast refresh banner for Bridgeless
Reviewed By: cortinico
Differential Revision: D50318991
fbshipit-source-id: 08e3cda5e4cc6e9b7319db57627c1e6bf7fcc67b
Summary:
We've been using SocketRocket 0.7.0 (to pick up a few bug fixes) without issue in React Native macOS. Might as well bump it upstream before 0.73 if we can.
## Changelog:
[IOS] [CHANGED] - Update SocketRocket to 0.7.0
Pull Request resolved: https://github.com/facebook/react-native/pull/39571
Test Plan: CI should pass
Reviewed By: cortinico
Differential Revision: D50411361
Pulled By: cipolleschi
fbshipit-source-id: 93ab571dcfd23e699f1c066bf7aaf737e1f2d18b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41028
This removes misleading `const` modifiers from some methods in `RuntimeScheduler` that shouldn't really use it, and removes the `mutable` modifiers that were only necessary because of that.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D50364626
fbshipit-source-id: 28ed9fa923f8e787166f702ccaecd41a635d3b3a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40945
This adds some temporary logic to configure the use of the modern version of RuntimeScheduler based on values coming from the app configuration.
This logic is centralized in `ReactInstance` so from that point the code is completely cross-platform.
This doesn't use `ReactNativeConfig`/`CoreFeatures` because they're initialized after the point where we need to access them for this use case. This way is a bit uglier but this isn't intended to live for long (only until we verify this doesn't have regressions in a complex app).
Changelog: [internal]
---
Reviewed By: sammy-SC
Differential Revision: D50171297
fbshipit-source-id: 8d96e228550cc6112ffe2abec4d531514b052f82
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40944
## Summary
This creates a new version of `RuntimeScheduler` that's intended to be backwards compatible but with a few notable changes:
1. `scheduleTask` is now thread-safe.
2. `scheduleWork` is now just an alias of `scheduleTask` with immediate priority (to preserve the yielding semantics it had over other tasks).
3. Yielding mechanism has changed, to make lower priority tasks to yield to higher priority tasks, instead of just yielding to `scheduleWork` and `executeNowOnTheSameThread`.
We don't expect this to have any impact in performance or user perceivable behavior, so we consider it a short-lived refactor. When we validate this assumptions in a complex application we'll delete the old version and only keep the fork.
## Motivation
The main motivation for this refactor is to reduce the amount of unnecessary interruptions of running tasks (via `shouldYield`) that are only used to schedule asynchronous tasks from native.
The `scheduleWork` method is the only available mechanism exposed to native APIs to schedule work in the JS thread (as the existing version of `scheduleTask` is only meant to be called from JS). This mechanism **always** asks for any running tasks in the scheduler to yield, so these tasks are always considered to have the highest priority. This makes sense for discrete user events, but not for many other use cases coming from native (e.g.: notifying network responses could be UserBlocking, Normal or Low depending on the use case).
We need a way to schedule tasks from native with other kinds of priorities, so we don't always have to interrupt what's currently executing if it has a higher priority than what we're scheduling.
## Changes
**General APIs:**
This centralizes scheduling in only 2 APIs in `RuntimeScheduler` (which already exist in the legacy version):
* `scheduleTask`, which is non-blocking for the caller and can be used from any thread. This always uses the task queue in the scheduler and a new yielding mechanism.
* `executeNowOnTheSameThread`, which is blocking for the caller and asks any task executing in the scheduler to yield. These tasks don't go through the task queue and instead queue through the existing synchronization mechanism in `RuntimeExecutor`. The yielding mechanism for these tasks is preserved.
`scheduleWork` will be deprecated and it's just an alias for `scheduleTask` with an immediate priority (to preserve a similar behavior).
**Yielding behavior:**
Before, tasks would only yield to tasks scheduled via `scheduleWork` and `executeNowOnTheSameThread` (those tasks didn't go through the task queue).
With this implementation, tasks would now yield to any task that has a higher position in the task queue. That means we reuse the existing mechanism to avoid lower priority tasks to never execute because higher priority tasks never stop coming.
All tasks would yield to requests for synchronous access (via `executeNowOnTheSameThread`) as did the current implementation.
Changelog: [internal]
Reviewed By: javache, sammy-SC
Differential Revision: D49316881
fbshipit-source-id: 046afc8b6f510a8608ef3da6e27b2663d861f1b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40875
This introduces a proxy for RuntimeScheduler so we can select between 2 different implementations at runtime (current implementation vs. new implementation, done in D49316881).
Changelog: [internal]
Reviewed By: javache, sammy-SC
Differential Revision: D49316880
fbshipit-source-id: 4035ed6ba641a2316f2efb7cf4a0a86270d6ae23
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40870
This removes an old experiment to implement microtasks in React Native (which is incorrect now that the runtime scheduler executes multiple tasks per runtime executor "task"). `drainMicrotasks` is a no-op at the moment in Hermes because the flag isn't set, so this code is essentially dead.
We'll add the new iteration of microtasks in a following PR.
Changelog: [internal]
Reviewed By: christophpurrer
Differential Revision: D49536251
fbshipit-source-id: b8efba2d0310b9e33e65b79c60ad2db1c8109def
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41054
changelog: [internal]
Avoid going into a while loop if there are no preMountItems.
Reviewed By: javache
Differential Revision: D50407034
fbshipit-source-id: 5c163e02303c331b8fff46fb9a955f88f72a529c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41051
Strictifies flow to flow strict-local in files where doing that doesn't cause new flow errors.
Changelog: Internal
Reviewed By: yungsters
Differential Revision: D50369011
fbshipit-source-id: b4a5a26b839b7327a3178e6f5b35246dea365a38
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41047
Array events are currently broken in the sample for RN Tester. This is because the event name is not registered correctly.
I'm updating the event registration to be correct.
Changelog:
[Internal] [Changed] - Make IntArray events work on Bridgeless for RN-Tester
Reviewed By: cipolleschi
Differential Revision: D50266485
fbshipit-source-id: 13bbce91a41281383d4857048e573b6d9cc5387b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41020
This adds Fabric and Paper bindings to support `alignContent: "space-evenly"` as implemented in https://github.com/facebook/yoga/pull/1422
Changelog:
[General][Added] - Bindings for `alignContent: "space-evenly"`
Reviewed By: yungsters
Differential Revision: D50347978
fbshipit-source-id: 44df3b8ddc7171cddf56957c11ac7d975f706f9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41019
### Changes made
- Regenerated tests (as some aspect ratio tests seem to be out of date compared to the fixtures)
- Added SpaceEvenly variant to the "Align" enums (via enums.py)
- Implemented `align-content: space-evenly` alignment in CalculateLayout.cpp
- Added generated tests `align-content: space-evenly`
- Updated NumericBitfield test to account for the fact that the Align enum now requires more bits (this bit could do with being reviewed as I am not 100% certain that it's valid to just update the test like this).
### Changes not made
- Any attempt to improve the spec-compliance of content alignment in general (e.g. I think https://github.com/facebook/yoga/pull/1013 probably still needs to happen)
X-link: https://github.com/facebook/yoga/pull/1422
Reviewed By: yungsters
Differential Revision: D50305438
Pulled By: NickGerleman
fbshipit-source-id: ef9f6f14220a0db066bc30db8dd690a4a82a0b00
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41023
X-link: https://github.com/facebook/yoga/pull/1426
Just like D50140503 where marginStart and marginEnd were not working with row reverse, paddingStart and paddingEnd are not working either with row reverse either. The solution is similar - we were checking the flex item layout starting/ending edges and not the general layout starting/ending edges. This change makes it so that we look at the proper edge according to what direction is set.
One caveat is that in the case of padding (and also border) there is a callsite that actually wants to get the flex item layout's leading/trailing padding and not the one dictated by direction. So, I made a new function to accommodate this and just swapped that callsite out.
Reviewed By: NickGerleman
Differential Revision: D50348995
fbshipit-source-id: 85717df23de7cf5f66b38d3ff28435b053a4e68e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41022
X-link: https://github.com/facebook/yoga/pull/1425
Just like D50140503 where marginStart and marginEnd were not working with row reverse, borderStart and borderEnd are not working either with row reverse either. The solution is similar - we were checking the flex item layout starting/ending edges and not the general layout starting/ending edges. This change makes it so that we look at the proper edge according to what direction is set.
One caveat is that in the case of border (and also padding) there is a callsite that actually wants to get the flex item layout's leading/trailing border and not the one dictated by direction. So, I made a new function to accommodate this and just swapped that callsite out.
Reviewed By: NickGerleman
Differential Revision: D50348085
fbshipit-source-id: eca2702c1753dbebb503034e2f0732684ad6c56e
Summary:
X-link: https://github.com/facebook/yoga/pull/1423
Pull Request resolved: https://github.com/facebook/react-native/pull/41017
Before resolving https://github.com/facebook/yoga/issues/1208 yoga was in a state where "leading" and "trailing" only referred to the main-start and main-end directions ([definition in spec](https://drafts.csswg.org/css-flexbox/#box-model)). That is, the start/end of the layout of flex items in a container. This is distinct from something like inline-start/inline-end which is the [start of text layout as defined by direction](https://drafts.csswg.org/css-writing-modes-3/#inline-start).
The bug linked above happened because "leading" and "trailing" functions are referring to the wrong directions in certain cases. So in order to fix this we added a new set of functions to get the "leading" and "trailing" edges according to what inline-start/inline-end would refer to - i.e. those defined by the direction (ltr | rtl). In this state I think it is confusing to understand which function refers to which direction and more specific names could help that.
This diff just renames the following 4 FlexDirection.h functions:
* **leadingEdge** -> **flexStartEdge**
* **trailingEdge** -> **flexEndEdge**
* **leadingLayoutEdge** -> **inlineStartEdge**
* **trailingLayoutEdge** -> **inlineEndEdge**
The spec calls the start/end directions as dictated by the flex-direction attribute "main-start" and "main-end" respectively, but mainStartEdge might be a bit confusing given it will be compared to a non-flexbox-specific name in inlineStartEdge. As a result I landed on flexStart/flexEnd similar to what values are used with alignment attributes (justify-content, align-content).
I chose to get rid of the "leading" and "trailing" descriptors to be more in line with what terminology the spec uses.
Next diff will be to rename the functions in Node.cpp to adhere to the above patterns.
Reviewed By: NickGerleman
Differential Revision: D50342254
fbshipit-source-id: 1e83a885876af9cf363822ebdbb64537f4784520
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41033
This has been rolled out with the false value (previous client-default of false). The open-source value was already false.
Changelog: [Internal]
Reviewed By: NickGerleman, sammy-SC
Differential Revision: D50362517
fbshipit-source-id: 577a2ead047b30d196409a26fd5385f333f20b18
Summary:
This class is not referenced anywhere. It used to be part of webview, which has been removed from RN's core.
Since we still have [external users](923016204c/android/expoview/src/main/java/versioned/host/exp/exponent/modules/api/components/webview/RNCWebView.java (L133)) of this class, let's deprecate it first.
Changelog: [Android][Removed] Deprecated internal ContentSizeChangeEvent
Reviewed By: NickGerleman
Differential Revision: D50325736
fbshipit-source-id: 5e1005b92764ae08bcc10607f675b3311b3e2ddb
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/41016
This hasn't been very useful since AsyncStorage/persistence was removed, but takes up a good amount of usable screen real-estate for information in the center of the screen. Remove it.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D50297980
fbshipit-source-id: 296a377dffc89c5c203ca6264351a2a1a8281cc3
Summary:
… request to local pathname comparator variables to fix issue with other rightward elements of url such as query or fragment entering the comparison and causing 404 errors for key debugging routes.
A change in Chromium appended the query "?for_tabs" to the /json/list request made by Chrome DevTools to find remote debugger targets.
The current comparison in InspectorProxy.js compares the entire node IncomingMessage url field to the local pathname constants. The issue arises as url can also contain the query and fragment portions so the original comparison of "/json/list" === "/json/list" which resolved as true would become "/json/list?for_tabs" === "/json/list" and evaluate to false ultimately resulting in a 404 for the request.
In summary, all these changes/issues caused remote debugging of Hermes code in React Native apps to become unavailable, greatly impacting developer experience.
## Changelog:
[GENERAL] [FIXED] JS Debugging: Fix inspector-proxy to allow for DevTools requests with query strings
Pull Request resolved: https://github.com/facebook/react-native/pull/41005
Reviewed By: NickGerleman
Differential Revision: D50342265
Pulled By: robhogan
fbshipit-source-id: a65f2908f0bea9fc15e1e3e4e6d31a3b9598e81f
Summary:
- ref: https://github.com/reactwg/react-native-releases/discussions/64#discussioncomment-7270126
With react-native@0.73.0-rc.2 and fresco@3.0.0, `dlopen failed: library "libnative-imagetranscoder.so"` error made crash in android. so, I patched fresco version to 3.1.0, so that resolves the crash error according to https://github.com/facebook/fresco/issues/2722#issuecomment-1749333089 this comment.
## 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
-->
[ANDROID] [FIXED] - b1fccb05ccb306005dc7616a4eaaa182b0b1deaf bumped fresco version to 3.1.0.
Pull Request resolved: https://github.com/facebook/react-native/pull/41024
Test Plan: after bumping fresco version, error not occurs.
Reviewed By: cipolleschi
Differential Revision: D50359564
Pulled By: cortinico
fbshipit-source-id: d24caecc057bad4d9c94e378422ab18c106a7ee6
Summary:
Fix https://github.com/facebook/react-native/issues/40560
## Changelog:
[ANDROID] [FIXED] - Ensure that `configureJavaToolChains` is only executed once during configuration
Pull Request resolved: https://github.com/facebook/react-native/pull/40757
Test Plan:
- Create a fresh `react-native@0.73.0-rc.1` project
- Install `react-native-webview`
- Apply [this patch](https://github.com/react-native-webview/react-native-webview/pull/3175/files) for `react-native-webview` (caused by another issue https://github.com/facebook/react-native/issues/40559)
- Edit `android/gradle.properties` and set `newArchEnabled` to true
- Build application
- (Expected) Application fail to build
- Apply this PR
- (Expected) Application build successfully
**Additional explanation:**
According to the implementation of `configureJavaToolChains`, all the subprojects (both the app and the libraries) will have their toolchains setup in one execution of the method. Therefore, it is okay for the method to be invoked only when configuring the plugin for the app.
On the other hand, invoking the method for more than one time will cause the issue stated in https://github.com/facebook/react-native/issues/40560.
Reviewed By: cipolleschi
Differential Revision: D50361871
Pulled By: cortinico
fbshipit-source-id: bd5e18df97988122788d0482dba954e517a0cb5c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41009
This change should fix [#39971](https://github.com/facebook/react-native/issues/39971), computing the relative path from the App path to the pod installation root and using that instead of the absolute path to the `react-native.config.js` file
## Changelog
[Internal] - Stabilize RCTAppDelegate podspec
Reviewed By: cortinico
Differential Revision: D50323710
fbshipit-source-id: e29e62228d08c752e822d7a9ab5b1a2b5dcd6eb4
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
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.
## Changelog:
<!-- 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
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40941
Events are currently not working for Fabric Interop on Bridgeless. That's because the `BridgelessReactContext` is not checking for interop modules on `getJsModule` calls, so the `InteropEventEmitter` is never returned.
This extends `BridgelessReactContext` so that `InteropEventEmitter` is returned if the Interop Layer is turned on.
Changelog:
[Internal] [Changed] - Make events work for Fabric Interop on Bridgeless
Reviewed By: cipolleschi
Differential Revision: D50266484
fbshipit-source-id: 0188d71bdc7acc8c188d886d45f0258914ad7af7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41003
Following up the deprecation of Flipper in 0.73 and preparing for the removal of Flipper in 0.74, we are removing Flipper integration from the CI.
## Changelog:
[Internal] - Remove the Flipper integration from CI
Reviewed By: dmytrorykun
Differential Revision: D50321335
fbshipit-source-id: 04885d3dbaab9b2834c9461e0580dfbef386244f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41002
Following up the deprecation of Flipper in 0.73 and preparing for the removal of Flipper in 0.74, we are removing Flipper integration from the Codebase.
## Changelog:
[iOS][Breaking] - Remove the Flipper integration
Reviewed By: dmytrorykun
Differential Revision: D50321255
fbshipit-source-id: d2f4488ada7acdbd3687f54db4204ba7f09370af
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40895
This is a long running debug assert due to a race condition with BE. I have at times wanted to try to add a lock to protect this, and measure impact, but really it will go away when we get rid of BE anyway, and any strategy I have come up with to lock gets hairy quickly.
This change does not impact RN in OSS, where BE is already disabled.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D50247680
fbshipit-source-id: d004fc7db24f1f0b7c3ea8756d4678ce41579712
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40970
This cleans up 9497203957 a bit, after I did some debugging and looking through Android source code.
1. `getRootView()` gives us constant-time access to root hierarchy, and we don't need to do instanceof check once per level. It also, at least in the sample activity I tried, gives us the Window's `LayoutParams`.
2. The root of the hierarchy is documented in code to do what we want. 9497203957
3. Calling `getRootView().getLayoutParams()`, then casting to `WindowManager.LayoutParams`, seems to show up in a lot of other widgets (inc Unity, RoboElectric), as a solution to getting this information. https://github.com/search?q=getRootView%28%29.getLayoutParams%28%29&type=code
This still feels like not a 100% documented contract, so I added an assertion so we can catch if the contract isn't valid somewhere now or in the future, instead of silently breaking keyboard events.
Note that this code only runs on SDK 30+ (Android 11+).
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D50297761
fbshipit-source-id: f97fb6ea1bcdb1b8e8dfcdcc178625efc0bb6b4a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41011
changelog: [internal]
topContentSizeChange should be a direct event. Otherwise it collides with ScrollView's `onContentSizeChange` any may break FlatList
Reviewed By: javache
Differential Revision: D50323281
fbshipit-source-id: dd8713acfdd5158ac8175b8efe5027d06cd0d0a8
Alex Taylor (alta)
Thomas Nardone
Nicola Corti
Riccardo Cipolleschi
Ingrid Wang
Rubén Norte
Pieter De Baets
Lulu Wu
Saad Najmi
Samuel Susla
Gijs Weterings
Nick Gerleman
Nico Burns
Joe Vilches
Jesse Watts-Russell
116-7
DeokHyeon Wi
UNIDY2002
huangtaibin
Oscar Franco
Alex Hunt
Phillip Pan