react-native-safe-area-context
react-native-safe-area-context copied to clipboard
th3rdwave
Does not respect hidden StatusBar
I just installed this package in order to fix notch problems on my app. However, I immediately stumbled upon a problem: The inset values don't make sense to me. I'm getting top: 20 on an iPhone 7, but the iPhone 7 doesn't have any notches or unsafe areas. At the same time, a Sony Xperia phone that I'm testing with, also without any notches, has top: 0. See below:
What are the values based upon? Is there a way for me to be able to foresee these differences so that I can work around them? I would've expected that this library provided the size of the actual unsafe areas, and not to add seemingly arbitrary additional values.
Update
Ok, so I'm guessing the 20 additional pixels stem from the status bar. But why is this automatically added, and how come it's only added on iOS? The status bar is hidden in my app on both Android and iOS, so I can't really just subtract those 20px in a very convenient way.. I'm doing it this way now, but feels like a hack: paddingTop: Platform.OS === 'ios' ? insets.top - 20 : insets.top
@AdamGerthel What version of iOS is on the phone? We polyfill the safe area api on older iOS versions that don't support it but it might not take status bar visibility in consideration. Also can you confirm if it also happens on a more recent iOS version (iOS 12 / 13)?
@janicduplessis The iPhone is running 13.1.2. react-native-safe-area-context is on ~0.3.6 (installed via expo install react-native-safe-area-context since I'm using Expo).
Ok I can repro in snack, I'll have a look. https://snack.expo.io/@janic/restless-carrot
I think the issue is fixed now, I cannot reproduce locally, I think expo is doing a release soon I'll check to make sure this library gets updated.
@janicduplessis I'm not sure I follow, the issue is reproducible in your snack (using react-native-safe-area-context 0.6.0), but you're saying the issue has already been fixed? Are you saying that this is an Expo-specific issue?
Snack uses the expo client which includes an older version of the native code (where the bug is).
I just checked and the next expo release will include version 0.6.0 which should fix your issue.
Oh, I see, I was a little confused since the package.json in your Snack example lists version 0.6.0.
Anyway, I'll just wait for the next Expo release then. Thanks!
I've upgraded Expo and I'm using 0.6.0 but the issue persists. Your snack has the same issue still.
It's been a while since I work of those parts of the code but... seems like it, yes.
Thanks, I just checked and I can confirm it still happens, will look at it again.
Weird, I can still repro in snack but not locally in my example app. This is going to be hard to investigate.
Any update on this issue? Still having the same problem today, when the StatusBar is hidden on iOS, insets.top is still 20 until I reload the app. Works fine on Android.
Confirm issue still exist in iOS when controlling hidden props of StatusBar with state
React-native by default uses the really old method of controlling the status bar - it uses this check to determine what mode you're using. Note that this is flipped - if this returns YES, the <StatusBar> component won't actually work
Ok - so call this function, and if it returns NO, you need to start listening to these events
When they fire, I think it's enough to just call this function
Happy to provide more pointers if someone wants to take this on
