Header jump when animation is set for bottom tab navigator

[matinzd]

Description

Moving this issue from react-navigation/react-navigation#12273.

I can't repro this on JS stack, and the headerTopInsetEnabled prop for screens is always set to true. So it seems to be an issue with react-native-screens.

The header will have an initial jump when animation is set for tab navigator. It doesn't matter if it's set to fade or shift.

Simulator.Screen.Recording.-.iPhone.16.Pro.-.2024-11-18.at.14.15.22.mp4

Expected behavior

The header should not flicker or have jumps.

Simulator.Screen.Recording.-.iPhone.16.Pro.-.2024-11-18.at.14.15.10.mp4

Steps to reproduce

Set bottom tab animation to fade or shift.

Snack or a link to a repository

https://github.com/matinzd/ReactNavigationHeaderFlicker

Screens version

4.1.0

React Native version

0.76.2

Platforms

iOS

JavaScript runtime

Hermes

Workflow

React Native (without Expo)

Architecture

Fabric (New Architecture)

Build type

Debug mode

Device

iOS simulator

Device model

No response

Acknowledgements

Yes

[za01br]

@matinzd After almost 4 hours on this bug, this hack fixed the issue for me: #1779 (comment)

This doesn't fix the issue.

[matinzd]

That is the same issue but it's not caused by the same thing. Now the new tab animation is causing this issue which is not the same as that one.

The workaround may work but it's not a correct solution. I also usually use scroll view with automatic inset adjustment so that I don't need to take care of the header height.

[za01br]

I agree with you. And that hack actually doesn't fix the issue.

[hirbod]

Alright, I could pretty much narrow it down. It is indeed related to the new animation I guess, and in my case it was triggered because we enabled fullScreenGestureEnabled, which under the hood switches to simple_push.

It's now also reproducible in the Expo Snack using stock react navigation v7. https://snack.expo.dev/@hirbod/native-stack-navigator-header-to-non-header

I suspect this PR caused it: https://github.com/software-mansion/react-native-screens/pull/2477
@kkafar

ScreenRecording_12-05-2024.03-40-32_1.MP4

EDIT: 100% isolated reproducible with react-native-screens alone.
Here is the issue for it: #2550

[matinzd]

Any attempts to fix this?

[matinzd]

I also found out that useHeaderHeight changes to some weird values when screen is mounted within tab navigation.

Here is how useHeaderHeight behaves when component re-renders when it's inside tab navigator:

 LOG  headerHeight 100.66666666666666
 LOG  headerHeight 44
 LOG  headerHeight 100.33333333333334

Here is how it behvaes when we navigate to another stack:

 LOG  headerHeight 100.66666666666666
 LOG  headerHeight 100.33333333333334

You can see it here as well:

matinzd/ReactNavigationHeaderFlicker@31a4338

[matinzd]

UPDATE

useHeaderHeight still behaves the same even if animation is not set to fade in tab navigator. It starts with a correct values then it jumps back to much lower value then back to the same value causing jumps if someone is using this hook.

---

I updated the reproducible. Please take a look at it. This is so annoying.

[matinzd]

I digged more into the react navigation code and I found that those incorrect values are being emitted from onHeaderHeightChange which comes from ScreenStackItem:

https://github.com/react-navigation/react-navigation/blob/main/packages/native-stack/src/views/NativeStackView.native.tsx#L343C11-L343C31

[matinzd]

I tried to debug it a bit with xcode.

This is what happens in the first calculation for the header height:

Then the value is now corrected in the second run:

navbarInset is in the first run.

[matinzd]

Sorry for mentioning you here but It's been a long time I opened this issue and I am still waiting for your response. I know you are very busy with all the new arch changes but it would be so helpful if we can also get this issue fixed. I am also available to hop on a call with you on discord to dig into this. Thank you @kkafar for all the work you are putting in for this repo!

[kkafar]

I haven't had opportunity to work on this yet, but I should have capacity to look into it tomorrow / at Monday.