Hi!
During the work on react-native-screens I found a strange bug in useSafeAreaInsets hook on Android side.
Currently, area insets received by useSafeAreaInsets seem to be invalid. On the first render, as the hook is sending proper values (I assume it uses getSafeAreaInsets method on getting initial window metrics) it sends incorrect inset (which is 0) after a while.
This Pull Request introduces a fix that adds takes windowInsets into comparing values of each inset when the native side reports negative or zero value. It fixes possibly #364 and #234 (if flickering is caused by insets being equal to 0).
BeforeAfter
Test Plan
Wrap your code with <SafeAreaInsetsContext.Consumer> and <SafeAreaProvider>
Try to use useSafeAreaInsets().top and then simply console.log it.
Launch the android emulator.
Before adding the changes it should return 24 on the initial render and 0 on the next render. After adding the changes it should only return 24, which is expected value.
Summary
Hi! During the work on
react-native-screens
I found a strange bug inuseSafeAreaInsets
hook on Android side. Currently, area insets received byuseSafeAreaInsets
seem to be invalid. On the first render, as the hook is sending proper values (I assume it usesgetSafeAreaInsets
method on getting initial window metrics) it sends incorrect inset (which is 0) after a while.This Pull Request introduces a fix that adds takes
windowInsets
into comparing values of each inset when the native side reports negative or zero value. It fixes possibly #364 and #234 (if flickering is caused by insets being equal to 0).Before
After
Test Plan
<SafeAreaInsetsContext.Consumer>
and<SafeAreaProvider>
useSafeAreaInsets().top
and then simplyconsole.log
it.Before adding the changes it should return
24
on the initial render and0
on the next render. After adding the changes it should only return24
, which is expected value.