Safe area paddings are not taken into account when use a customer header height

[pybuche]

Current Behavior

• What code are you running and what is happening?
  Hi, I noticed that when you are precising height in headerStyle options, safe area paddings for devices with a notch are not taken into account.
  That's a shame because if forces me to add manually the safe insets and it's not that convenient.

• Include a screenshot or video if it makes sense.
  With default height:

const AccountStackNavigator = () => {
    return (
        <AccountStack.Navigator>
            <AccountStack.Screen
                name="Profile"
                component={Profile}
                options={{ title: 'Profile' }}
            />
        </AccountStack.Navigator>
    );
};

With custom height:

const AccountStackNavigator = () => {
    return (
        <AccountStack.Navigator>
            <AccountStack.Screen
                name="Profile"
                component={Profile}
                options={{ title: 'Profile', headerStyle: { height: 64 } }}
            />
        </AccountStack.Navigator>
    );
};

The header is smaller than the standard one, although the standard header is 44px high...

With custom height and insets:

const AccountStackNavigator = () => {
    return (
        <AccountStack.Navigator>
            <AccountStack.Screen
                name="Profile"
                component={Profile}
                options={{ title: 'Profile', headerStyle: { height: 64 + insets.top } }}
            />
        </AccountStack.Navigator>
    );
};

Expected Behavior

• What do you expect should be happening?
  I understand why insets are not taken into account, since you override the default param. But I'd like at least to be able to set a custom height and not having to deal with the safe areas.
  Would it be possible?

• Include a screenshot or video if it makes sense.
  I'd like have this result:
  
  with this piece of code:

const AccountStackNavigator = () => {
    return (
        <AccountStack.Navigator>
            <AccountStack.Screen
                name="Profile"
                component={Profile}
                options={{ title: 'Profile', headerStyle: { height: 64 } }}
            />
        </AccountStack.Navigator>
    );
};

How to reproduce

You should be able to reproduce everything with the code snippets above.
Thanks !

• You must provide a way to reproduce the problem. If you are having an issue with your machine or build tools, the issue belongs on another repository as that is outside of the scope of React Navigation.
• Either re-create the bug on Snack or link to a GitHub repository with code that reproduces the bug.
• Explain how to run the example app and any steps that we need to take to reproduce the issue from the example app.
• Keep the repro code as simple as possible, with the minimum amount of code required to repro the issue.
• Before reporting an issue, make sure you are on latest version of the package.

Your Environment

software	version
iOS or Android	iOS 12+
@react-navigation/native	5.0.10
@react-navigation/stack	5.2.0
react-native-gesture-handler	1.5.0 (do I need it with the RN nav v5?)
react-native-safe-area-context	0.6.0
react-native-screens	2.0.0-alpha.12 (do I need it with the RN nav v5?)
react-native	I guess it's expo 36's v0.60
expo	36.0.0
node	12
npm or yarn	1.19.1

[WoLewicki]

I understand why insets are not taken into account, since you override the default param. But I'd like at least to be able to set a custom height and not having to deal with the safe areas.
Would it be possible?

It is understandable that overriding the header's height will not take safe area insets into account by default, because it would destroy the customizability. The best way I can think of is to just always add the top inset plus the value you would like to be changed, it would look somehow like this: headerStyle: { height: useSafeArea().top + yourValue }.

[pybuche]

That's what I did, I just wanted to know if there is another way, since it's now pretty standard to take safe areas into account !

[WoLewicki]

Do you have anything specific in mind? I can't think of any other sensible solution.

[pybuche]

Well, if react-navigation already has the safe insets values, maybe just a param like headerHeight instead of headerStyle.height would do the trick.

It's already done for other params that could be handled with style, why not this one ?
Moreover, it's recommanded to set headerStyle.height when using a custom header component with a non-standard height according to the docs, so there may be some thoughts to give to this height problem :)

[maersk96]

Current Behavior

• What code are you running and what is happening?
  Hi, I noticed that when you are precising height in headerStyle options, safe area paddings for devices with a notch are not taken into account.
  That's a shame because if forces me to add manually the safe insets and it's not that convenient.
• Include a screenshot or video if it makes sense.
  With default height:

const AccountStackNavigator = () => {
    return (
        <AccountStack.Navigator>
            <AccountStack.Screen
                name="Profile"
                component={Profile}
                options={{ title: 'Profile' }}
            />
        </AccountStack.Navigator>
    );
};

With custom height:

const AccountStackNavigator = () => {
    return (
        <AccountStack.Navigator>
            <AccountStack.Screen
                name="Profile"
                component={Profile}
                options={{ title: 'Profile', headerStyle: { height: 64 } }}
            />
        </AccountStack.Navigator>
    );
};

The header is smaller than the standard one, although the standard header is 44px high...

With custom height and insets:

const AccountStackNavigator = () => {
    return (
        <AccountStack.Navigator>
            <AccountStack.Screen
                name="Profile"
                component={Profile}
                options={{ title: 'Profile', headerStyle: { height: 64 + insets.top } }}
            />
        </AccountStack.Navigator>
    );
};

Expected Behavior

• What do you expect should be happening?
  I understand why insets are not taken into account, since you override the default param. But I'd like at least to be able to set a custom height and not having to deal with the safe areas.
  Would it be possible?
• Include a screenshot or video if it makes sense.
  I'd like have this result:
  
  with this piece of code:

const AccountStackNavigator = () => {
    return (
        <AccountStack.Navigator>
            <AccountStack.Screen
                name="Profile"
                component={Profile}
                options={{ title: 'Profile', headerStyle: { height: 64 } }}
            />
        </AccountStack.Navigator>
    );
};

How to reproduce

You should be able to reproduce everything with the code snippets above. Thanks !

• You must provide a way to reproduce the problem. If you are having an issue with your machine or build tools, the issue belongs on another repository as that is outside of the scope of React Navigation.
• Either re-create the bug on Snack or link to a GitHub repository with code that reproduces the bug.
• Explain how to run the example app and any steps that we need to take to reproduce the issue from the example app.
• Keep the repro code as simple as possible, with the minimum amount of code required to repro the issue.
• Before reporting an issue, make sure you are on latest version of the package.

Your Environment

software version
iOS or Android iOS 12+
@react-navigation/native 5.0.10
@react-navigation/stack 5.2.0
react-native-gesture-handler 1.5.0 (do I need it with the RN nav v5?)
react-native-safe-area-context 0.6.0
react-native-screens 2.0.0-alpha.12 (do I need it with the RN nav v5?)
react-native I guess it's expo 36's v0.60
expo 36.0.0
node 12
npm or yarn 1.19.1

Just wondering. What font is this?

[github-actions]

Hey! This issue is closed and isn't watched by the core team. You are welcome to discuss the issue with others in this thread, but if you think this issue is still valid and needs to be tracked, please open a new issue with a repro.