Thanks for submitting your issue. Can you take another look at your description and make sure the issue template has been filled in its entirety?

👉 Click here if you want to take another look at the Bug Report issue template.

System:
OS: macOS 10.14.5
CPU: (4) x64 Intel(R) Core(TM) m3-7Y32 CPU @ 1.10GHz
Memory: 43.45 MB / 8.00 GB
Shell: 3.2.57 - /bin/bash
Binaries:
Node: 10.13.0 - /usr/local/bin/node
Yarn: 1.16.0 - /usr/local/bin/yarn
npm: 6.4.1 - /usr/local/bin/npm
SDKs:
iOS SDK:
Platforms: iOS 13.0, DriverKit 19.0, macOS 10.15, tvOS 13.0, watchOS 6.0
Android SDK:
API Levels: 23, 26, 27, 28
Build Tools: 27.0.3, 28.0.3
System Images: android-26 | Google APIs Intel x86 Atom, android-28 | Google Play Intel x86 Atom
IDEs:
Android Studio: 3.4 AI-183.6156.11.34.5522156
Xcode: 11.0/11A420a - /usr/bin/xcodebuild
npmPackages:
react: 16.8.3 => 16.8.3
react-native: 0.59.9 => 0.59.9
npmGlobalPackages:
react-native-cli: 2.0.1

Same issue here

Hey, I have the same issue with FlatList component.

Same issue here

I'm actually experiencing this with react-native-webview from react-native-community... didn't know it affected more than just the webview.

I can see the same on react-native 0.60.5 with SectionList.

I don't know if this happened with anyone else or is that related but incase anyone experienced it: I saw my custom contact list for a second and then it changed to something like this with the scroll bar in the middle and then the thing disappeared.

This appears to have something to do with SafeAreaView's forceInset property, at least in my case. Removing that property causes this issue to not appear anymore.

Changing <SafeAreaView forceInset={{ bottom: 'never'}}> to <SafeAreaView forceInset={{ bottom: 'never', vertical: 'never'}}> also fixed the issue for me.

Possibly related: #16997

We can reproduce this on 59.10 on a ScrollView with contentContainerStyle={[{ paddingBottom: 60 ]} prop.

We're not sure why but removing the prop, or navigating to another page and back fix the scroll indicator somehow.

Updates:

• We found that adding scrollIndicatorInsets={{ right: 1 }} will force the scrollbar to be rendered correctly
• Additionally, adding scrollIndicatorInsets={{ right: 0 }} does nothing. So we guess there's buggy code in iOS 13 that overrides contentInsets default since we didn't use SafeAreaView in our app.

This appears to have something to do with SafeAreaView's forceInset property, at least in my case. Removing that property causes this issue to not appear anymore.

Changing <SafeAreaView forceInset={{ bottom: 'never'}}> to <SafeAreaView forceInset={{ bottom: 'never', vertical: 'never'}}> also fixed the issue for me.

Possibly related: #16997

I'm not sure about the forceInset property, but it's definitely related to the SafeAreaView. I did some tests with different device sizes on the simulator, and the problem only occurs on devices that have the "notch" on the top of the screen, thus, devices that use the SafeAreaView.

Same issue here. It's not possible to reproduce with 100% success, but so far we noticed this on iPhone Xs running iOS 13.0 and 13.1 on expo@35.0.0 & react-native@0.59.8

Same issue here

Same issue here with ios 13.1.3 "react": "16.3.1", "react-native": "0.55.3",

Hey, I have the same issue with FlatList component.

Same happened to me, but the issue was with ScrollView. Removed the as we used FlatList and the problem was gone.

Same issue here with ios 13, react 16.9.0, react-native 0.61.2

I initially dug into this thinking it was something I did incorrectly– after stripping away SafeAreaView, using different versions of react-native, digging into react-navigation, and a million other little tests– I narrowed it down to the following:

• Only occurs on iOS 13
• Only occurs when a FlatList/ScrollView is scrolling into an "inset" area

Fiddling with SafeAreaView props and everything else didn't help– but @sbycrosz's workaround of adding scrollIndicatorInsets={{ right: 1 }} to the FlatList worked perfectly. (thanks sbycrosz! 🙇)

We just ran into this issue as well. On a physical iPhone Xs (iOS 13.2.3) the issue does not appear but on the iPhone 11 Pro (iOS 13.3) using the simulator it does appear. We are updating the physical iPhone at the moment to iOS 13.3 to see if we can replicate the issue.

@sbycrosz's workaround fixes it but a bit annoying having to update our ScrollViews.

I had the same issue both on an iPhone XR 13.1.3 and in the Simulator - iPhone 11 13.3. Occurred when a View component with style={{ flex: 1 }} was the highest component in the component tree.
Replacing it with ScrollView with contentContainerStyle={{ flex: 1 }} seems to have "fixed" it.

I am experiencing the same issue on iOS13 iPhone Xs .How did you fix it for react-native-webview?
Thanks!

Had the same problem for iPhone XR in Simulator (13.3) using ScrollView. Adding scrollIndicatorInsets={{ right: 1 }} put the scrollbar in its place.

Linking this PR here, because it fixes the issue: #29809

Mar 20, 2021... no fixed yet 🤘

The workaround suggested by @sbycrosz moves the scrollbar 1px to left. To keep original position, you can use:

scrollIndicatorInsets={{right: Number.MIN_VALUE}}

The workaround suggested by @sbycrosz moves the scrollbar 1px to left. To keep original position, you can use:

scrollIndicatorInsets={{right: Number.MIN_VALUE}}

How we will add that property to Webview?

How we will add that property to Webview?

Dunno, this issue is about ScrollView.

add style flexGrow: 1 to parent component fixed this in my situation:

<View style={{ flexGrow: 1 }}>
  <FlatList />
</View>

Mar 20, 2021... no fixed yet 🤘
update to the latest version. automaticallyAdjustsScrollIndicatorInsets default is YES will casue this issue.

if (@available(iOS 13.0, *)) {
        webView.scrollView.automaticallyAdjustsScrollIndicatorInsets = NO;
    } 

It looks like this issue happens when the ScrollView (and probably other scrollable components too) is mounted in a screen while the navigation animation is running. For example when rendering the ScrollView only after receiving data from an API. The position of the scroll bar seems to be set depending on where the ScrollView is on the screen when it's mounted / rendered. Here is a repro that simulates waiting for data with a setTimeout: https://snack.expo.dev/@l3m3a3/scrollview-bug Changing the timeout value changes where the scroll bar appears.
https://www.dropbox.com/s/yli1ion0mjdus2i/scroll-view-bug.mov?dl=0
Setting automaticallyAdjustsScrollIndicatorInsets={false} (available in React Native 0.66) for the ScrollView seems to fix the issue, so it looks like it's related to this prop (can't see this in expo snack now, since it uses RN 0.64, but I tested locally).

@danilo900 Updating react-native-webview to at least version 11.1.0 should fix the issue, since the automaticallyAdjustsScrollIndicatorInsets prop was added in that version (react-native-webview/react-native-webview@d46a6d3) with a default value of false.

So my fix for now will be to change the default value for ScrollView's automaticallyAdjustsScrollIndicatorInsets prop to false at the beginning of the root index.js file. I tested it and this fixes the issue for ScrollView, FlatList, SectionList.

import { ScrollView } from 'react-native';

ScrollView.defaultProps = ScrollView.defaultProps || {};
ScrollView.defaultProps.automaticallyAdjustsScrollIndicatorInsets = false;

Same here guys, thanks @sbycrosz for save my day, to preserve the pixel proportions, it would be better to use top/ bottom instead of right, here my code:

<ScrollView
  scrollIndicatorInsets={{ top: 1, bottom: 1 }}
  contentInsetAdjustmentBehavior="always"
  {...props}
/>

before fix:

after @sbycrosz workaround:

@hramos any update with this issue?

Same here guys, thanks @sbycrosz for save my day, to preserve the pixel proportions, it would be better to use top/ bottom instead of right, here my code:

<ScrollView
  scrollIndicatorInsets={{ top: 1, bottom: 1 }}
  contentInsetAdjustmentBehavior="always"
  {...props}
/>

before fix:

after @sbycrosz workaround:

@hramos any update with this issue?

this working for me

This error occurred in our app when data was loaded while the react navigation screen transition was still underway, causing the screen to re-render and introduce a ScrollView mid-transition.

These solutions all fixed the problem:

• load data before navigation
• load data after transition
• add scrollIndicatorInsets={{ right: 1 }} to the ScrollView
• render the ScrollView with flex:1 even when data hasn't finished loading yet

We went with the 4th solution.

In my case adding

// @ts-ignore
automaticallyAdjustsScrollIndicatorInsets={false}

to FlatList or ScrollView helped.

https://reactnative.dev/docs/scrollview#automaticallyadjustsscrollindicatorinsets-ios

This issue is still appearing, specifically in my case only when wrapped in a KeyboardAvoidingView. Configured as the following:

<KeyboardAvoidingView
      style={{flex: 1, flexDirection: 'column', justifyContent: 'center'}}
      behavior="padding"
      enabled
      keyboardVerticalOffset={100}>
    <ScrollView
        contentContainerStyle={{paddingHorizontal: spacing.m}}>
         {....}
    </ScrollView>
</KeyboardAvoidingView>

Can confirm @sbycrosz's solution of scrollIndicatorInsets={{ right: 1 }} did fix it.

For my instance of this bug, it was caused by conditionally rendering a FlatList. My pseudo-code was:

if (initialLoading) return <FullScreenLoadingPage/>
    
else return <FlatList data={...} />

When I re-worked this to:

return (
  <FlatList 
    data={...} 
    ListEmptyState={initialLoading ? FullScreenLoadingPage : NormalEmptyState} 
  />
)

The problem went away. I encourage you to try this solution before you start messing around with manually forcing the indicator insets. Everyone here seems to be recommending you to change the right inset. What about people who have right-to-left displays? Is their indicator on the left? I don't even know. I don't want to know. Try my solution and you might be able to avoid all this.

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

This issue was closed because it has been stalled for 7 days with no activity.