Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ScrollView as child of Modal no longer scrollable on first mount/modal opening, RN >= 0.76, Android only, old-arch only #48822

Open
goguda opened this issue Jan 21, 2025 · 6 comments

Comments

@goguda
Copy link

goguda commented Jan 21, 2025

Description

Since React Native 0.76.0, a ScrollView as a child of the built-in Modal component is no longer scrollable when the modal first opens on Android.

This seems to only affect the old architecture. New architecture seems to be unaffected.
iOS seems unaffected.

The problem is still present in RN 0.77. Downgrading to 0.75.4 fixes it.

Steps to reproduce

  1. Install the reproduction app with yarn android. The reproduction is set to use the old architecture by default.
  2. Click the Open Scrollable Modal button.
  3. Observe that the screen doesn't scroll, even though it should.
  4. Leave the modal open. Try modifying the code in ScrollableModalContent.tsx by adding a style={{flex: 1}} to the ScrollView and saving the file. This hot-reloads the component without unmounting at the parent, and suddenly the ScrollView becomes scrollable.
  5. Close the modal using the hardware back button. Re-open the modal, observing the content is unscrollable again, even with style={{flex: 1}} still on the ScrollView.
  6. Remove the style={{flex: 1}} from the ScrollView and save the file.
  7. Enable newArch in Android gradle.properties.
  8. Rebuild the app and try opening the modal again.
  9. The modal opens and the content inside scrolls as expected.

React Native Version

0.77.0

Affected Platforms

Runtime - Android

Output of npx react-native info

System:
  OS: Linux 6.12 openSUSE Tumbleweed 20250117
  CPU: (8) x64 Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz
  Memory: 11.91 GB / 31.31 GB
  Shell:
    version: 5.2.37
    path: /bin/bash
Binaries:
  Node:
    version: 20.18.1
    path: ~/.nvm/versions/node/v20.18.1/bin/node
  Yarn:
    version: 1.22.22
    path: /usr/local/bin/yarn
  npm:
    version: 10.8.2
    path: ~/.nvm/versions/node/v20.18.1/bin/npm
  Watchman: Not Found
SDKs:
  Android SDK: Not Found
IDEs:
  Android Studio: Not Found
Languages:
  Java:
    version: 17.0.13
    path: /usr/bin/javac
  Ruby:
    version: 3.4.1
    path: /usr/bin/ruby
npmPackages:
  "@react-native-community/cli":
    installed: 15.0.1
    wanted: 15.0.1
  react:
    installed: 18.3.1
    wanted: 18.3.1
  react-native:
    installed: 0.77.0
    wanted: 0.77.0
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: false
iOS:
  hermesEnabled: Not found
  newArchEnabled: false

Stacktrace or Logs

N/A

Reproducer

https://github.com/goguda/react-native-android-scrollview-in-modal-not-always-scrolling-point-76-up

Screenshots and Videos

No response

@goguda goguda changed the title ScrollView as child of Modal no longer scrolls on first mount/modal opening, RN >= 0.76, Android only, old-arch only ScrollView as child of Modal no longer scrollable on first mount/modal opening, RN >= 0.76, Android only, old-arch only Jan 21, 2025
@devanshsaini11
Copy link

I also tried reproducing this issue on latest version v0.77.0 it is happening on android old arch, looks like a valid issue

@goguda
Copy link
Author

goguda commented Jan 22, 2025

I'm not sure of the exact internals for this one, but I have a feeling it's something to do with height of the parent view (or height of the ScrollView itself?) not being calculated properly anymore on mount.

@elencho
Copy link
Contributor

elencho commented Feb 3, 2025

+1

1 similar comment
@iy-913
Copy link

iy-913 commented Feb 7, 2025

+1

@lehresman
Copy link

Thanks for reporting this and for the great reproduction steps. This just bit us too, this exact scenario. Our workaround was to add style={{height: 100}} to the ScrollView inside the Modal. Setting flex:1 didn't fix it. For some reason that I don't quite understand, the height of 100px is ignored and it is actually full screen which is what we wanted. But setting height:100 made the scrolling work.

We will be switching to the new architecture soon so hopefully this is a temporary hack, or hopefully this issue can get resolved.

@goguda
Copy link
Author

goguda commented Feb 19, 2025

Thanks for reporting this and for the great reproduction steps. This just bit us too, this exact scenario. Our workaround was to add style={{height: 100}} to the ScrollView inside the Modal. Setting flex:1 didn't fix it. For some reason that I don't quite understand, the height of 100px is ignored and it is actually full screen which is what we wanted. But setting height:100 made the scrolling work.

We will be switching to the new architecture soon so hopefully this is a temporary hack, or hopefully this issue can get resolved.

This workaround concerns me a bit, just on the off chance the renderer does interpret the height correctly and tries to make the ScrollView only 100px.

BUT, you got me thinking and inspired another workaround. Conditionally render {flex: 1} on the ScrollView after render and a short timeout:

export default function ScrollableModalContent() {
  const [rendered, setRendered] = React.useState(false);

  React.useEffect(() => {
    setTimeout(() => {
      setRendered(true);
    }, 200);
  }, []);

  return (
    <View style={styles.main}>
      <ScrollView style={rendered ? {flex: 1} : undefined}>
        <Text>{LOREM_IPSUM}</Text>
      </ScrollView>
    </View>
  );
}

This seems to consistently produce the behavior we want, and the 200ms delay of unscrollable content isn't noticeable.

Something tells me this issue is very low priority, affecting the old architecture only.

Ideally I think it's best for people to just switch to the new architecture if they can. In our case, we're just waiting for one of the major libraries we use to catch up with full support for the new architecture, since it doesn't seem to work well with the interop layer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants