React-native: Scrolling interacts strangely with SafeAreaView on iPhone X

Created on 28 Nov 2017  Â·  25Comments  Â·  Source: facebook/react-native

Is this a bug report?

Yes

Have you read the Contributing Guidelines?

Yes

Environment

(Expo)
Packages: (wanted => installed)
react: 16.0.0 => 16.0.0
react-native: https://github.com/expo/react-native/archive/sdk-23.0.0.tar.gz => 0.50.3

Steps to Reproduce

  1. Put a SafeAreaView around content inside of a ScrollView.
  2. Make sure there is plenty of content to scroll through.
  3. Run the app on an iPhone X or in the iPhone X Simulator.

Expected Behavior

Scrolling should behave as normally, with the SafeAreaView in effect when the scroll position is at the beginning and end of the content.

Actual Behavior

Scrolling is difficult, and often results in janky behavior. The more complex and long the content, the worse it is.

Here's a gif of the behavior:

example

Note how the content continuously changes position, even when not scrolling.

Reproducible Demo

https://snack.expo.io/rkiomUcgz

Make sure to use an iPhone X device, or download and open in XDE to install it on the iPhone X Simulator.

Bug iOS Ran Commands Stale

Most helpful comment

I had the same situation, and contentInsetAdjustmentBehavior worked for me

<ScrollView contentInsetAdjustmentBehavior="automatic">
      <SafeAreaView>
            {/* long content here */}
      </SafeAreaView>
</ScrollView>

from react-native repo, ScrollView code says:

/**
   * This property specifies how the safe area insets are used to modify the
   * content area of the scroll view. The default value of this property is
   * "never". Available on iOS 11 and later.
   * @platform ios
   */
  contentInsetAdjustmentBehavior?: ?(
    | 'automatic'
    | 'scrollableAxes'
    | 'never'
    | 'always'
  ),

All 25 comments

Are you using react-native-navigation? Got same problem on Android

I'm not using using react-native-navigation or any other third party components. The demo reproduces the problem using just the ScrollView and SafeAreaView components that ship with RN.

Experiencing the same issue. Even if you put it the other way around and and assign the safeAreaView a backgroundColor, you will notice a „smoothly, jumping“ background in the status bar area (similar to changing paddings while using transitions in css).

I'm experiencing the same issue. Not only with scrolling, but also with elements (e.g. ActionSheet) that are animated into view. In my case, while the janky behaviour as shown above occurs, I'm not able to tap on anything.

I'm experiencing the same issue. When coming into the view, before I scroll the view flickers a lot just if it was trying to remove the padding and add it back.

Putting a SafeAreaView at the top and at the end of the ScrollView seems to make it better, the issue doesn't happen in the middle of the scrollview but does happen when at the top/bottom.

For a FlatList that would be ListHeaderComponent={SafeAreaView} and ListFooterComponent={SafeAreaView}

Maybe something like this forceInset property would be helpful to have in react-native?
https://github.com/react-community/react-native-safe-area-view#forceinset

forceInset
Sometimes you will observe unexpected behavior and jank because SafeAreaView uses onLayout then calls measureInWindow on the view. If you know your view will touch certain edges, use forceInset to force it to apply the inset padding on the view.

@brunolemos I thought that API was already in React Native? I'm running on 0.51.0 and tried this API, but that didn't work for me. If it's not in React Native yet, that'd explain :-)

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. If you think this issue should definitely remain open, please let us know why. Thank you for your contributions.

Remove stale.

Thanks for posting this! It looks like you may not be using the latest version of React Native, v0.53.0, released on January 2018. Can you make sure this issue can still be reproduced in the latest version?

I am going to close this, but please feel free to open a new issue if you are able to confirm that this is still a problem in v0.53.0 or newer.

How to Contribute • What to Expect from Maintainers

+1 I cannot scroll up if Flatlist is inside ScrollView inside SafeAreaView

@nthgol that does not sound like the same issue. From the original post in this thread:

export default class App extends Component {
  render() {
    return (
      <ScrollView style={styles.container} contentContainerStyle={styles.contentContainer}>
        <SafeAreaView>
          {new Array(100).fill(Paragraph).map((fn, key) => React.createElement(fn, {key}))}
        </SafeAreaView>
      </ScrollView>
    );
  }
}

It's a SafeAreaView within a ScrollView.

@hramos completely agree, but the experienced behavior in his GIF is what I'm experiencing, so I figured it tag on that something weird is going on. in particular, I notice it ONLY on the iphone X, not on other models, and so I think safeareaview is to blame here, as it treats the devices differently

I confirm I'm having this issue too.

I had the same situation, and contentInsetAdjustmentBehavior worked for me

<ScrollView contentInsetAdjustmentBehavior="automatic">
      <SafeAreaView>
            {/* long content here */}
      </SafeAreaView>
</ScrollView>

from react-native repo, ScrollView code says:

/**
   * This property specifies how the safe area insets are used to modify the
   * content area of the scroll view. The default value of this property is
   * "never". Available on iOS 11 and later.
   * @platform ios
   */
  contentInsetAdjustmentBehavior?: ?(
    | 'automatic'
    | 'scrollableAxes'
    | 'never'
    | 'always'
  ),

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as "For Discussion" or "Good first issue" and I will leave it open. Thank you for your contributions.

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as a "Discussion" or add it to the "Backlog" and I will leave it open. Thank you for your contributions.

I am experiencing a similar problem using ScrollView nested within a SafeAreaView. It breaks my positioning on elements by reducing their width. Please help!

Not sure if it's the same issue, but if I run this code as my root component, on an iPhone X, with iOS 12.4 and RN 0.59.10, and reload a few times, the black box in the bottom will jump a few pixels up and down, while all the phones' memory and CPU is consumed until the app freezes completely

However, if I change the marginBottom below to 0, the issue goes away.

function MainScreen() {
  return (
    <View style={{ flex: 1 }}>
      <ScrollView />
      <View style={{ backgroundColor: 'black' }}>
        <SafeAreaView style={{ marginBottom: 8 }} />
      </View>
    </View>
  )
}

I am on react-native 0.59.9 and when I set contentInsetAdjustmentBehavior="automatic" on ScrollView, FlatList or SectionList, the padding is correctly added at the bottom and the content is allowed to scroll beneath the bottom part where the "home button" is.
There is no need to use a SafeAreaView to achieve this.

@david-arteaga in my case, I wanted a static positioned box in the bottom of the screen showing the current user below the scrollview. That's why I needed to put it into a SafeAreaView, so the box content did not go underneath the iPhone X "home button"

@esbenvb In that case I’d put the SafeAreaView as the outermost element, instead of the plain view you have right now (and keep the flex:1 in the style)

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as a "Discussion" or add it to the "Backlog" and I will leave it open. Thank you for your contributions.

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please feel free to create a new issue with up-to-date information.

Was this page helpful?
0 / 5 - 0 ratings