<RectButton> becomes unresponsive when used within a List

[nujhong]

Description

Using a RectButton in a List component (FlatList/SectionList) will become unresponsive in certain scenarios. I am not sure whether this is an incorrect usage of this library or it's something new with RN. This wasn't an issue in production before.

• It's observed that the event handler is not called when it's unresponsive
• It's observed that when RectButton is unresponsive, it's also unresponsive to swipe up to close the android app
• It's observed that using the same example, it cannot be reproduced on Snack
• Finally, setting shouldActivateOnStart=true on RectButton seems to solve the issue
• Additionally, I initially thought it's because I'm not using RectButton inside RNGH's ScrollView so I've added a SectionList export via patch-package. This also seems to solve the issue other than setting shouldActivateOnStart=true.

Platforms

• iOS
• Android
• Web

Screenshots

Screen.Recording.2022-08-09.at.4.56.25.pm.mov

Screen.Recording.2022-08-09.at.4.57.14.pm.mov

Steps To Reproduce

Using RN's SectionList

1. Scroll multiple times to the bottom of the list
2. All instances become unresponsive
3. Navigate to "Solution" by pressing the button in Header
4. All instances are still responsive (however the ripple effect is gone)
5. Exit and reload the app and navigate straight to "Solution" and repeat Step 1
6. Everything works fine

---

Using re-exported SectionList by overriding its ScrollViewComponent with RNGH's ScrollView via renderScrollComponent

1. Apply the package by running yarn patch-package
2. Scroll multiple times to the bottom of the list
3. Everything works fine

Expected behavior

• RectButton does not become unresponsive when used within a List component on Android

Actual behavior

• RectButton becomes unresponsive when used within a List component Android

Snack or minimal code example

https://github.com/nujhong/RNGH-RectButton-In-a-List

Package versions

• React: 18.0.0
• React Native: 0.69.1
• React Native Gesture Handler: 2.5.0
• React Native Reanimated: 2.9.1

[j-piasecki]

Hi! At the first glance it might be related to the overscroll animation introduced in Android 12, however when you want to use gestures or components from Gesture Handler in a list, you should use the ScrollView exported from Gesture Handler. Using renderScrollComponent to override the default ScrollView is the correct solution in my opinion.

[hirbod]

I was about to file the same exact issue. And the unresponsiveness is coming randomly. My App is wrapped correctly with GestureRoot and it was not happening before I've upgraded to SDK 46 @j-piasecki.

I also passed
renderScrollComponent={(props) => <ScrollView {...props} />}while ScrollView is an import from rngh.

Elements are not clickable anymore. Swapping to Pressable for example works. When I reload the app, it works like for 30 seconds or so and becomes broken.

Bildschirmaufnahme.2022-08-12.um.17.56.40.mp4

And its not only lists. Even my header buttons, which are BorderlessButton will break as well.

P.S: adding shouldActivateOnStart TO EVERY Button fixes the issue, but thats not a fix imho

[hirbod]

There is a much deeper issue with SDK 46 and RNGH. It also happens on iOS, there is basically no "ACTIVE" state anymore triggered. Breaking interactions with ScrollViews, also breaking @gorhom Bottom Sheet on iOS. We've tested this with Bare RN and Expo. Only happening with Expo (SDK 46, working fine with SDK 45) together with RNGH.

Will report back with more proof soon

[nujhong]

Yes we also found that the problem still persists when using RNGH's ScrollView.

Adding to @hirbod's investigation with ours, I summarised this which may be used to conclude that it's happening only for RN 0.69+ and very likely due to the Android 12 overscroll issue @j-piasecki has mentioned.

Framework	RN Version	Working
Expo SDK 45	0.68	🟢
Expo SDK 46	0.69	🔴
Bare	0.69	🔴

---

In terms of the shouldActivateOnStart workaround, we had to carry on with it for now and took it even further because that:

• the problem is still being reported after replacing all ScrollView from RNGH, one scenario is that it happens when the screen times out after inactivity
• it created another new problem with nested touch handling Nested touchables don't work correctly on Android #784 (comment), so I ended up adding another prop disallowInterruption=true to the child touch component as a workaround for us now

shouldActivateOnStart.true.mov

shouldActivateOnStart.false.disallowInterruption.mov

[hirbod]

I also experienced issues with nested buttons, good point with the interruption prop

[j-piasecki]

@nujhong Thanks for the update! I'll try to figure out why it doesn't work out-of-the-box, and look into the nested buttons.

@hirbod This seems to be a different issue than the one on iOS you mentioned. This also happens on bare workflow, and is related only to buttons. That said, have you experienced problems with nested buttons on Android, iOS, or both?

[hirbod]

Both, when I use the workaround to make them work in first place

[JoniVR]

I summarised this which may be used to conclude that it's happening only for RN 0.69+ and very likely due to the Android 12 overscroll issue

I can reproduce this issue on React Native 0.68.2 (bare) with RNGH 2.5.0.

The way to reproduce it is quite simple:
All you need is a scrollview (of any kind) with a RectButton or other pressables from RNGH.

1. Press one button
2. Drag down (with stretch effect)
3. Drag up (with stretch effect)
4. repeat until buttons are no longer pressable, usually repeating these steps once produces the issue

[nujhong]

An update that is hopefully useful @j-piasecki

This seems to be a problem specific to react-native-gesture-handler@2.5.0 + Android 12, without regards to react-native, as Expo SDK 46 also bumped it from 2.2.0 to 2.5.0.

For the peers, we eventually downgraded it to 2.3.2 and it works for us without any workarounds now.

[j-piasecki]

Could you check if the linked PR solves the issue in your case? If not, could you post how to reproduce it further?

[hirbod]

Will test tomorrow and report back! Thanks for addressing the issue.