Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48092
Changelog: [internal]
This is just in preparation to expand the scope of that function to include configuration for feature flags.
Reviewed By: javache
Differential Revision: D66760119
fbshipit-source-id: e955e8f596697ac6a0a87013bec3fc3e09caf19d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48087
Changelog: [internal]
Now that we have Fantom tests for these unit tests that use mocks, we can remove the JS tests and the mocks :)
Reviewed By: sammy-SC
Differential Revision: D66599197
fbshipit-source-id: 33822588c2176ffe2f2631da56c671b299f8058d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48086
Changelog: [internal]
Just adding a bit of coverage for the `expect` API adding `toBeLessThan` and `toBeGreaterThan`.
Reviewed By: sammy-SC
Differential Revision: D66753268
fbshipit-source-id: 6a26f558f985ccbb5eb0daacecd93759841149e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48083
Changelog: [internal]
Just a small refactor to have a better code organization for the testing runtime infra.
Reviewed By: sammy-SC
Differential Revision: D66753269
fbshipit-source-id: e68727fe45fabe0be3528e21d5a60cef3045c252
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48063
Changelog: [internal]
This allows async functions to be passed to `runTask` (just a type change really) and adds tests for ReactNativeTester. Error handling isn't currently set up correctly, so those tests are disabled for now.
Reviewed By: sammy-SC
Differential Revision: D66698547
fbshipit-source-id: 41d1fccc80f90cdf764f6fa3d3d34365eeef8ec6
Summary:
Handling `long` values is not implemented in Writables. I added it on the native side.
## 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] - Support Long values in WritableMap and WritableArray
Pull Request resolved: https://github.com/facebook/react-native/pull/48017
Test Plan: Run https://github.com/WoLewicki/reproducer-react-native/tree/%40wolewicki/long-in-writeable-map and see it doesn't work without those changes.
Reviewed By: javache
Differential Revision: D66754194
Pulled By: cortinico
fbshipit-source-id: 7f8d4eb3c4069f890460525ddffdf9f4324550b0
Summary:
This action is no longer necessary and we can remove it
## Changelog:
[Internal] [Fixed] - Use `refs/pulls` namespace in trigger action
Pull Request resolved: https://github.com/facebook/react-native/pull/47923
Reviewed By: NickGerleman
Differential Revision: D66578573
Pulled By: cortinico
fbshipit-source-id: 87cdbc1544873a2669e82c7763c78d18ff7881fd
Summary:
Related PR in `react-native-screens`:
* https://github.com/software-mansion/react-native-screens/pull/2495
Additional context:
* [my detailed explanation of **one of the issues**](https://github.com/software-mansion/react-native-screens/pull/2495#issuecomment-2478915818)
* [Android Developer: ViewGroup.startViewTransition docs](https://developer.android.com/reference/android/view/ViewGroup#startViewTransition(android.view.View))
### Background
On Android view groups can be marked as "transitioning" with a `ViewGroup.startViewTransition` call. This effectively ensures, that in case a view group is marked with this call and its children are removed, they will be still drawn until `endViewTransition` is not called.
This mechanism is implemented in Android by [keeping track of "transitioning" children in auxiliary `mTransitioningViews` array](https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/view/ViewGroup.java#7178). Then when such "transitioning" child is removed, [it is removed from children array](https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/view/ViewGroup.java#5595) but it's [parent-child relationship is not cleared](https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/view/ViewGroup.java#5397) and it is still retained in the auxiliary array.
Having that established we can proceed with problem description.
### Problem
https://github.com/user-attachments/assets/d0356bf5-2f17-4b06-ba53-bfca659a1071
<details>
<summary>Full code</summary>
```javascript
import { NavigationContainer } from 'react-navigation/native';
import React from 'react';
import { createNativeStackNavigator } from 'react-navigation/native-stack';
import { enableScreens } from 'react-native-screens';
import {
StyleSheet,
Text,
View,
FlatList,
Button,
ViewProps,
Image,
FlatListProps,
findNodeHandle,
} from 'react-native';
enableScreens(true);
function Item({ children, ...props }: ViewProps) {
return (
<View style={styles.item} {...props}>
<Image source={require('../assets/trees.jpg')} style={styles.image} />
<Text style={styles.text}>{children}</Text>
</View>
);
}
function Home({ navigation }: any) {
return (
<View style={styles.container}>
<Button title="Go to List" onPress={() => navigation.navigate('List')} />
</View>
);
}
function ListScreenSimplified({secondVisible}: {secondVisible?: (visible: boolean) => void}) {
const containerRef = React.useRef<View>(null);
const innerViewRef = React.useRef<View>(null);
const childViewRef = React.useRef<View>(null);
React.useEffect(() => {
if (containerRef.current != null) {
const tag = findNodeHandle(containerRef.current);
console.log(`Container has tag [${tag}]`);
}
if (innerViewRef.current != null) {
const tag = findNodeHandle(innerViewRef.current);
console.log(`InnerView has tag [${tag}]`);
}
if (childViewRef.current != null) {
const tag = findNodeHandle(childViewRef.current);
console.log(`ChildView has tag [${tag}]`);
}
}, [containerRef.current, innerViewRef.current, childViewRef.current]);
return (
<View
ref={containerRef}
style={{ flex: 1, backgroundColor: 'slateblue', overflow: 'hidden' }}
removeClippedSubviews={false}>
<View ref={innerViewRef} removeClippedSubviews style={{ height: '100%' }}>
<View ref={childViewRef} style={{ backgroundColor: 'pink', width: '100%', height: 50 }} removeClippedSubviews={false}>
{secondVisible && (<Button title='Hide second' onPress={() => secondVisible(false)} />)}
</View>
</View>
</View>
);
}
function ParentFlatlist(props: Partial<FlatListProps<number>>) {
return (
<FlatList
data={Array.from({ length: 30 }).fill(0) as number[]}
renderItem={({ index }) => {
if (index === 10) {
return <NestedFlatlist key={index} />;
} else if (index === 15) {
return <ExtraNestedFlatlist key={index} />;
} else if (index === 20) {
return <NestedFlatlist key={index} horizontal />;
} else if (index === 25) {
return <ExtraNestedFlatlist key={index} horizontal />;
} else {
return <Item key={index}>List item {index + 1}</Item>;
}
}}
{...props}
/>
);
}
function NestedFlatlist(props: Partial<FlatListProps<number>>) {
return (
<FlatList
style={[styles.nestedList, props.style]}
data={Array.from({ length: 10 }).fill(0) as number[]}
renderItem={({ index }) => (
<Item key={'nested' + index}>Nested list item {index + 1}</Item>
)}
{...props}
/>
);
}
function ExtraNestedFlatlist(props: Partial<FlatListProps<number>>) {
return (
<FlatList
style={styles.nestedList}
data={Array.from({ length: 10 }).fill(0) as number[]}
renderItem={({ index }) =>
index === 4 ? (
<NestedFlatlist key={index} style={{ backgroundColor: '#d24729' }} />
) : (
<Item key={'nested' + index}>Nested list item {index + 1}</Item>
)
}
{...props}
/>
);
}
const Stack = createNativeStackNavigator();
export default function App(): React.JSX.Element {
return (
<NavigationContainer>
<Stack.Navigator screenOptions={{ animation: 'slide_from_right' }}>
<Stack.Screen name="Home" component={Home} />
<Stack.Screen name="List" component={ListScreenSimplified}/>
</Stack.Navigator>
</NavigationContainer>
);
}
export function AppSimple(): React.JSX.Element {
const [secondVisible, setSecondVisible] = React.useState(false);
return (
<View style={{ flex: 1, backgroundColor: 'lightsalmon' }}>
{!secondVisible && (
<View style={{ flex: 1, backgroundColor: 'lightblue' }} >
<Button title='Show second' onPress={() => setSecondVisible(true)} />
</View>
)}
{secondVisible && (
<ListScreenSimplified secondVisible={setSecondVisible} />
)}
</View>
);
}
const styles = StyleSheet.create({
container: {
flex: 1,
alignItems: 'center',
justifyContent: 'center',
},
nestedList: {
backgroundColor: '#FFA07A',
},
item: {
flexDirection: 'row',
alignItems: 'center',
padding: 10,
gap: 10,
},
text: {
fontSize: 24,
fontWeight: 'bold',
color: 'black',
},
image: {
width: 50,
height: 50,
},
});
```
</details>
Explanation (copied from [here](https://github.com/software-mansion/react-native-screens/pull/2495#issuecomment-2478915818)):
I've debugged this for a while now & I have good understanding of what's going on. This bug is caused by our usage of `startViewTransition` and its implications. We use it well, however React does not account for case that some view might be in transition. Error mechanism is as follows:
1. Let's have initially simple stack with two screens: "A, B". This is component rendered under "B":
```javascript
<View //<-- ContainerView (CV)
removeClippedSubviews={false}
style={{ flex: 1, backgroundColor: 'slateblue', overflow: 'hidden' }}>
<View removeClippedSubviews style={{ height: '100%' }}> // <--- IntermediateView (IV)
<View removeClippedSubviews={false} style={{ backgroundColor: 'pink', width: '100%', height: 50 }} /> // <--- ChildView (ChV)
</View>
</View>
```
2. We press the back button.
3. We're on Fabric, therefore subtree of B gets destroyed before B itself is unmounted -> in our commit hook we detect that the screen B will be unmounted & we mark every node under B as transitioning by calling `startViewTransition`.
4. React Mounting stage starts, view hierarchy is disassembled in bottom-up fashion (leafs first).
5. ReactViewGroupManager receives MountItem to detach ChV from IV.
6. A call to [`IV.removeView(ChV)` is made](https://github.com/facebook/react-native/blob/9c11d7ca68c5c62ab7bab9919161d8417e96b28b/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/view/ReactClippingViewManager.kt#L58-L73), which effectively removes ChV from `IV.children`, ***HOWEVER*** it does not clear `ChV.parent`, meaning that after the call, `ChV.parent == IV`. This happens, due to view being marked as in-transition by our call to `startViewTransition`. If the view is not marked as in-transition this parent-child relationship is removed.
7. IV has `removeClippedSubviews` enabled, therefore a [call to `IV.removeViewWithSubviewsClippingEnabled(ChV)` is made](https://github.com/facebook/react-native/blob/9c11d7ca68c5c62ab7bab9919161d8417e96b28b/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/view/ReactClippingViewManager.kt#L68). [This function](https://github.com/facebook/react-native/blob/9c11d7ca68c5c62ab7bab9919161d8417e96b28b/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/view/ReactViewGroup.java#L726-L744) does effectively two things:
1. if the ChV has parent (interpretation: it has not yet been detached from parent), we compute it's index in `IV.children` (Android.ViewGroup's state) and remove it from the array,
2. remove the ChV from `mAllChildren` array (this is state maintained by ReactViewGroup for purposes of implementing the "subview clipping" mechanism".
The crash happens in 7.1, because ChV has been removed from `IV.children` in step 6, but the parent-child relationship has not been broken up there. Under usual circumstances (this is my hypothesis now, yet unconfirmed) 7.1 does not execute, because `ChV.parent` is nulled in step no. 6.
### Rationale for `startViewTransition` usage
Transitions. On Fabric, when some subtree is unmounted, views in the subtree are unmounted in bottom-up order. This leads to uncomfortable situation, where our components (react-native-screens), who want to drive & manage transitions are notified that their children will be removed after the subtrees mounted in screen subviews are already disassembled. **If we start animation in this very moment we will have staggering effect of white flash** [(issue)](https://github.com/software-mansion/react-native-screens/issues/1685) (we animate just the screen with white background without it's children). This was not a problem on Paper, because the order of subtree disassembling was opposite - top-down. While we've managed to workaround this issue on Fabric using `MountingTransactionObserving` protocol on iOS and a commit hook on Android (we can inspect mutations in incoming transaction before it starts being applied) we still need to prevent view hierarchy from being disassembled in the middle of transition (on Paper this has also been less of an issue) - and this is where `startViewTransition` comes in. It allows us to draw views throughout transition after React Native removes them from HostTree model. On iOS we exchange subtree for its snapshot for transition time, however this approach isn't feasible on Android, because [snapshots do not capture shadows](https://stackoverflow.com/questions/42212600/android-screenshot-of-view-with-shadow).
### Possible solutions
[Android does not expose a method to verify whether a view is in transition](https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/view/ViewGroup.java#7162) (it has `package` visibility), therefore we need to retrieve this information with some workaround. I see two posibilities:
* first approach would be to override `startViewTransition` & `endViewTransition` in ReactViewGroup and keep the state on whether the view is transitioning there,
* second possible approach would be as follows: we can check for "transitioning" view by checking whether a view has parent but is not it's parent child (this **should** be reliable),
Having information on whether the view is in transition or not, we can prevent multiple removals of the same view in every call site (currently only in `removeViewAt` if `parent.removeClippingSubviews == true`).
Another option would be to do just as this PR does: having in mind this "transitioning" state we can pass a flag to `removeViewWithSubviewClippingEnabled` and prevent duplicated removal from parent if we already know that this has been requested.
I can also add override of this method:
```java
/*package*/ void removeViewWithSubviewClippingEnabled(View view) {
this.removeViewWithSubviewClippingEnabled(view, false);
}
```
to make this parameter optional.
## Changelog:
[ANDROID] [FIXED] - Handle removal of in-transition views.
Pull Request resolved: https://github.com/facebook/react-native/pull/47634
Test Plan: WIP WIP
Reviewed By: javache
Differential Revision: D66539065
Pulled By: tdn120
fbshipit-source-id: cf1add67000ebd1b5dfdb2048461a55deac10b16
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48090
This alleviates a breaking change on `ReactModuleInfo` constructor.
While the ctor was deprecated, we realized that there are more than 250 usages in OSS.
We'll need to properly communicate this removal before we do it.
Changelog:
[Android] [Fixed] - Re-introduce the deprecated constructor on ReactModuleInfo
Reviewed By: cipolleschi
Differential Revision: D66755541
fbshipit-source-id: 3673d8f2af278d55491cea89f1594d368513e3d8
Summary:
Currently the class `ResponseUtil` is still in Java, I'm adding some unit tests so it is safer to migrate it to Kotlin.
## Changelog:
[INTERNAL] - `ResponseUtil` unit tests
Pull Request resolved: https://github.com/facebook/react-native/pull/48075
Test Plan:
```bash
yarn test-android
```
Reviewed By: cortinico
Differential Revision: D66727736
Pulled By: lunaleaps
fbshipit-source-id: 9c89c75905b4e0c9c4820a556245a07e135e0f17
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48076
JSC for Android does not implement `String.prototype.replaceAll`:
{F1971791988}
https://github.com/facebook/react-native/pull/47466 introduced a use of it into runtime code, breaking JSC compatibility.
This.. replaces it.. with `replace`. Since the argument is already a regex with a `g` modifier, `replaceAll` wasn't necessary anyway.
Changelog:
[ANDROID][FIXED] Fix JSC by avoiding use of unavailable `str.replaceAll()`
Reviewed By: javache
Differential Revision: D66712312
fbshipit-source-id: 534b6db6834a2fda46ae8457437de3caa24f4eb0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48053
Changelog: [Internal]
`getModuleInstanceFromClass:` is a delegate method intended to be implemented by the product layer to provide modules. if it is not implemented to return a module for a given key, `RCTTurboModuleManager` will simply call `new` on the TM class.
however, these two paths differentiate - for `getModuleInstanceFromClass:`, we will call `_attachBridgelessAPIsToModule:` which provides objects like surfacePresenter to the native module.
if we fallback to calling `new`, then this attachment does not happen, even if the app has already been migrated to bridgeless modules.
thus, the fix in the case is to lift the fallback into RCTInstance as well, and decorate the APIs onto the new fallback.
Reviewed By: cipolleschi
Differential Revision: D66675034
fbshipit-source-id: 1ab89a4006d05f744f5d42b5de786ccea4d4a55d
Summary:
X-link: https://github.com/facebook/yoga/pull/1762
Pull Request resolved: https://github.com/facebook/react-native/pull/48077
OCD strikes again. Grepped this time to make sure we didn't miss any cases for this specific param name
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D66715777
fbshipit-source-id: 3e881a15b3b2836a4a55b11d7ec621541b92a05d
Summary:
why: running `yarn test-e2e-local -t "RNTestProject" -p "Android" -h false -c $GITHUB_TOKEN` would actually build the app with Hermes even though it's specified as disabled.
This is because of the `if (argv.hermes == null)` condition whose body would not execute.
The condition was changed [recently](https://github.com/facebook/react-native/commit/f322dc7a84eb72370910f6933d0a4fa7780f49bc#diff-56f57bf0eac99b0fda1b2938aceb8d9b663db82c07cb405bd53a01c8689710ffR258).
Reason for `await` being used:
```
Error ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ scripts/release-testing/test-e2e-local.js:303:32
Cannot get argv.hermes because property hermes is missing in Promise [1]. [prop-missing]
scripts/release-testing/test-e2e-local.js
300│ 'reactNativeArchitectures=arm64-v8a',
301│ 'android/gradle.properties',
302│ );
303│ const hermesEnabled = (argv).hermes === true;
304│
305│ // Update gradle properties to set Hermes as false
306│ if (!hermesEnabled) {
flow-typed/npm/yargs_v17.x.x.js
[1] 80│ argv: Argv | Promise<Argv>;
```
## Changelog:
[INTERNAL] [FIXED] - fix `hermes` param handling in `test-e2e-local.js`
Pull Request resolved: https://github.com/facebook/react-native/pull/48068
Test Plan: tested locally
Reviewed By: cipolleschi
Differential Revision: D66704263
Pulled By: robhogan
fbshipit-source-id: f05f23b95e67bd20025e0b3448df0d284fcb62da
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48071
Changelog: [Internal]
- Write fantom test for rn_rootThreshold given current implementation of IntersectionObserver
- Rename `rn_rootThreshold` to `rnRootThreshold`
- Rename `rn_intersectionRootRatio` to `rnRootIntersectionRatio`
- Rename `rootThresholds` on observer to `rnRootThresholds`
Reviewed By: rubennorte
Differential Revision: D66464509
fbshipit-source-id: 8ed66afa54bab99a28625ebe6f227d59d0bd7389
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48055
Address the test-case identified in D66557919, where Differentiator could emit updates for views referencing an incorrect parentTag.
The longer-term fix here is to avoid emitting any updates for nodes which are being reparented, but that requires bigger changes, including to the LayoutAnimation system. As a short-term patch, we're passing through an explicit `parentShadowViewForUpdate` which will be used as the current parent for update purposes.
{F1971278019}
Changelog: [Android][Fixed] Fix Fabric mutations sometimes triggering a `getViewState` crash when referencing an invalid parentTag.
Reviewed By: rubennorte
Differential Revision: D66654293
fbshipit-source-id: cd5b3e577ad1eede1b6dea834582ac6d750cbb81
Summary:
Make it clearer to the release crew to avoid using an outdated artifact
for testing a release.
{F1971030533}
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/48046
Test Plan:
```
yarn test-e2e-local -t "RNTester" -p "Android" -h true -c $GITHUB_TOKEN
```
Reviewed By: robhogan
Differential Revision: D66657082
Pulled By: blakef
fbshipit-source-id: 225128690c180bee7a3d28fdcc7f8c9885a37f0d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48066
Minor edits to this build spec to align with other packages in `ReactCommon/`.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D66700351
fbshipit-source-id: 47942c27d6154b78c165508447a3056f1354f5c3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47930
This diff adds a list of props that will be used by the Android `ImagePrefetcher` to create an `ImageRequest`. This list is derived from all the props that `ReactImageView` uses to create its `ImageOptions` and `ImageRequest` objects.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D66453306
fbshipit-source-id: ca4f59784c81f2b94ed4b052f6fbe5e8c6b97a2a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48052
LLVM-15 has a warning `-Wunused-variable` which we treat as an error because it's so often diagnostic of a code issue. Unused variables can compromise readability or, worse, performance.
This diff either (a) removes an unused variable and, possibly, it's associated code or (b) qualifies the variable with `[[maybe_unused]]`.
#buildsonlynotests - Builds are sufficient
- If you approve of this diff, please use the "Accept & Ship" button :-)
Reviewed By: javache, wuyuoss
Differential Revision: D66143498
fbshipit-source-id: a461f115610258777bd1173f91cf4d4472e2fc5e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48057
FabricViewStateManager has been deprecated for a long time and it's unused, let's delete it
changelog: [Android][Breaking] Delete deprecated class FabricViewStateManager
Reviewed By: javache, cortinico
Differential Revision: D66403219
fbshipit-source-id: e8f893b6a240ca09c0e86821c0a15fa345ffd221
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48056
ComponentNameResolver is meant to be used only internaly, we reduce its visbility to internal
changelog: [Android][Breaking] Removed ComponentNameResolver from public API
Reviewed By: javache
Differential Revision: D66403218
fbshipit-source-id: bf08284400a6dc6446b771c894488ed3fb371e25
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47349
This is needed to be able to recurse into the literals and compare them.
I'm primarily unsure if there is a problem representing doubles/floats as numbers instead of strings though.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D65284058
fbshipit-source-id: b2de9ed5fb7f079a432c94aaea69027863879909
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47987
Store a tag value for whether the view is added or removed, to better track the state instead of checking view.getParent().
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D66383241
fbshipit-source-id: 16521eb4052e9473be058a00cfe29d7f198b7861
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47915
## Purpose of this noop-ing
If an fatal js error happens during js runtime init, the js thread continues executing and raises **yet another** fatal error.
This noop-ing was an **attempt** to prevent that second inactionable fatal from happening: That fatal is usually inactionable.
## Problems with this noop-ing
I don't think this is the right approach: There could be legitimate reasons to continue executing native -> js calls post first js fatal.
I don't think it does *much*: it doesn't noop native -> js calls executed on the runtime scheduler, which should be most of them.
## Changes
Instead of trying to prevent that fatal, just let it happen. Then, don't report the second fatal: D66193194 and D66392706.
## Safetly
The production impact is negligible: This codepath is executed only after early js errors. There shouldn't be any in production right now.
We've spent a lot of time making our javascript error handling pipeline's coverage compresive. So, after an early js fatal error happens, subsequent js fatals should get handled properly.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D66394278
fbshipit-source-id: ef342fc2eba9ae9f27b15a0f412fb69bd92aed43
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48020
Progress towards Performance panel display parity for User Timing events in Chrome DevTools.
- Support nullable `track` name in `ReactPerfLogger`, passing track name directly to `FuseboxTracer`.
- Update `FuseboxTracer` to register "Main" process and send V8-aligned `blink.user_timing`-categorised tracing events.
The previous track naming strategy continues to be used under Perfetto.
Changelog: [Internal]
**Better, but not perfect yet**
For now, this is probably the upper limit of how aligned we can be with Chrome on web, since our forked DevTools frontend is 6mo+ behind `main`. Notably, it does not include equivalent custom track handling today: https://github.com/ChromeDevTools/devtools-frontend/commit/4b4435feef14c5c0ac71d932940c6ea7613f8afe
{F1969750671}
> Importing an exact trace from Chrome into RNDT is unable to sub-group the "Timings" track.
Reviewed By: rubennorte
Differential Revision: D66579308
fbshipit-source-id: fa57151d2be477eaa15f62e5c19ee09b1a0ef43a
Nikita Rubilov
zhongwuzw
Rubén Norte
Wojciech Lewicki
jodeppo
Kacper Kafara
Nicola Corti
Mateo Guzmán
Andrew Datsenko
Nick Gerleman
Soe Lynn
Rob Hogan
Rob Hogan
Phillip Pan
Joe Vilches
Eli White
Vojtech Novak
Richard Barnes
Dmitry Rykun
Luna Wei
Pieter De Baets
Fabrizio Cucci
Blake Friedman
Alex Hunt
David Vacca
Thomas Nardone
Ramanpreet Nara