When I want to go to the previous page, everything suddenly disappears #1685
Assignees
Labels
Missing repro
This issue need minimum repro scenario
Platform: Android
This issue is specific to Android
Comments
github-actions
bot
added
Platform: Android
|
Hey! 👋 The issue doesn't seem to contain a minimal reproduction. Could you provide a snack or a link to a GitHub repository under your username that reproduces the problem? |
|
I have now installed the updated version (3.19.0) and checked again but the problem persists. 😥 Probably the problem is not related to the react-native-screens package. Can we say that the problem is caused by the react-navigation package? |
|
Hi @ugurdalkiran!
No, the problem definitely lies in We still need to find a proper solution to this problem. |
|
I am glad that you are aware of the problem and that you are looking for a solution. I hope it will be resolved as soon as possible, thanks for your efforts. ❤️ |
|
Similar problem happening on iOS, without Fabric enabled. The screen goes blank and just like flies out of place instead of animating out. Before (correct)Here is screens version RPReplay_Final1674498235.movAfterHere is Notice it looks weird when going back. If I swipe back, it works fine. The issue only happens if I call RPReplay_Final1674498490.movAny idea which version this started with? Would be useful to downgrade to avoid it happening. Thank you! |
|
It seems to be the same issue as this: #1532 |
|
Similar problem happening on android with fabric enabled |
|
same issue here +1 platform ios enable fabric and using some navigation method (reset , replace) any solution? |
|
Might be related to #1661 |
Please is there a quick fix or any hack to get around this behaviour. Thanks for your reply |
|
Hi everyone! I know that this problem is unfortunately still relevant and I want to really say sorry that some of you may experience it. From our side we're still waiting to merge @WoLewicki PR to official React Native repo about adding listeners for screen mount operations so we could perform proper logic when the screen will unmount on Android. With those listeners it will be possible to fix this issue, but for now we only have to wait 😓 |
48 tasks
|
Hey @tboba @WoLewicki @kkafar I think As I can understand the problem now is that views are getting actually removed from the screen before root |
|
Hi @kirillzyusko! Yeah, we know this PR has been rejected, sadly 😢 AFAIK, currently @kkafar is working on possible fix for that bug, do you know Kacper what's the current state of it? |
|
@tboba Cool, glad to hear that progress is moving 😎 I just thought to suggest that potentially we can pospone unmounting a component in JS (I guess it's managed by react-navigation). Just potentially instead of excluding a component from JS tree we can assign a new prop (like But I'll be glad to hear how you managed to overcome this problem 💪 👀 |
|
Hey all, could you check #2134 fixes this problem and does not introduce any new ones? |
|
@WoLewicki I can check only next week (currently on a short vacation and don't have an access to my laptop) 👀 |
|
I believe #2134 fixes the issue. |
|
Well that was quick, I can confirm the issue is back in |
2 tasks
|
@alduzy I can confirm that your PR fixed the issue on 4.0.0-beta.14. But looks like @maciekstosio is working on a separate PR, so for now I will patch the changes to use it temporarily |
|
got same issue with 4.1.0 since migrating to expo sdk 52 newArch |
facebook-github-bot
pushed a commit
to facebook/react-native
that referenced
this issue
Dec 4, 2024
Summary: Related PR in `react-native-screens`: * software-mansion/react-native-screens#2495 Additional context: * [my detailed explanation of **one of the issues**](software-mansion/react-native-screens#2495 (comment)) * [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](software-mansion/react-native-screens#2495 (comment))): 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)](software-mansion/react-native-screens#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: #47634 Test Plan: WIP WIP Reviewed By: javache Differential Revision: D66539065 Pulled By: tdn120 fbshipit-source-id: cf1add67000ebd1b5dfdb2048461a55deac10b16
2 tasks
cipolleschi
pushed a commit
to facebook/react-native
that referenced
this issue
Dec 16, 2024
Summary: Related PR in `react-native-screens`: * software-mansion/react-native-screens#2495 Additional context: * [my detailed explanation of **one of the issues**](software-mansion/react-native-screens#2495 (comment)) * [Android Developer: ViewGroup.startViewTransition docs](https://developer.android.com/reference/android/view/ViewGroup#startViewTransition(android.view.View)) 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. 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](software-mansion/react-native-screens#2495 (comment))): 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. 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)](software-mansion/react-native-screens#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). [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. [ANDROID] [FIXED] - Handle removal of in-transition views. Pull Request resolved: #47634 Test Plan: WIP WIP Reviewed By: javache Differential Revision: D66539065 Pulled By: tdn120 fbshipit-source-id: cf1add67000ebd1b5dfdb2048461a55deac10b16
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
I'm opening a new page on Android and everything is fine. When I want to come back from that opened page, all Views and Texts disappear from the screen. A white screen appears. Then my back page opens.
At this stage, I want the objects on my screen not to disappear.
In my opinion such a problem occurs when FABRIC is enabled. If fabric is not enabled, everything continues as normal. Could it be that the react-navigation package's fabric support is not working properly?
Here is the video.
ezgif-1-be282d7b39.mp4
Steps to reproduce
Snack or a link to a repository
https://stackoverflow.com/help/mcve
Screens version
3.18.2
React Native version
0.71.0
Platforms
Android
JavaScript runtime
Hermes
Workflow
React Native (without Expo)
Architecture
Fabric (New Architecture)
Build type
Debug mode
Device
Android emulator
Device model
No response
Acknowledgements
Yes
The text was updated successfully, but these errors were encountered: