React-native-web: Touchable: onPress is triggered when scrolling at the top of a ScrollView

[wjielim]

Do you want to request a feature or report a bug?
Bug

What is the current behavior?
TouchableOpacity inside a ScrollView will be triggered if one try to scroll up while the ScrollView is already at its top. See the below gif for better understanding:

This also happens to horizontal ScrollView.

If the current behavior is a bug, please provide the steps to reproduce and
if a minimal demo of the problem via Glitch or similar (template:
https://glitch.com/edit/#!/react-native-web-playground).

copy paste this code:

<ScrollView style={{backgroundColor: '#f1f2f3', flex: 1, height: Dimensions.get('window').height, width: Dimensions.get('window').width}}>
{
          (() => {for (let i=0; i < 10; i++){
            buttons.push(
              <TouchableOpacity onPress={() => {alert(`button ${i} Pressed!`)}}
                                style={{width: 300, height: 150, backgroundColor: 'blue', color: 'white', margin: 10}}>
                <Text>Button {i}</Text>
              </TouchableOpacity>
            )
          }})()
}

{buttons}
</ScrollView>

What is the expected behavior?

TouchableOpacity should not trigger onPress when it's inside a ScrollView (with height set to screen/window height) when scrolling under any circumstances.

Environment (include versions). Did this work in previous versions?

• OS: Windows
• Device: Microsoft Surface Pro 3
• Browser: Google Chrome v62.0.3202.94 (Official Build) (64-bit)
• React Native for Web (version): 0.1.16
• React (version): 16.2.0

[aizigao]

same problem, mark

[jondkoon]

I made a glitch to try and repro this and it seems to be working as expected when using a ScrollView:

View: https://giant-planet.glitch.me/
Edit: https://glitch.com/edit/#!/giant-planet?path=src/App/index.js:1:0

If you replace the ScrollView with a View then it fails as described

[necolas]

I can't reproduce this issue either. Perhaps it is Windows-only, but that seems unlikely given the browser is Chrome.

[aizigao]

@jondkoon @necolas it seems bug with TouchableHighlight but not TouchableOpacity https://glitch.com/edit/#!/cultured-bracket
https://glitch.com/edit/#!/join/6adbab14-d2f7-4ebf-b7e1-c4e7cd49f28b

[necolas]

I can actually reproduce this with both Touchables when you drag-down and release while still over the button. On native, the scrollview becomes the responder as soon as you start to drag after pressing on a touchable. On web, the touchable remains the responder.

[necolas]

I think I understand the root of the issue. In React Native, ScrollView will trigger onScroll events if you're dragging down when at the top of the scroll view - this allows the responder system to transfer the responder grant from the touchable back to the scroll view. But the web stops dispatching scroll events when scrollTop === 0, so the responder system leaves the touchable as the responder.

The reported issue goes away when ScrollView dispatches a DOM scroll event after it receives a touchmove that occurs when scrollTop === 0. But I will need to investigate a more sophisticated solution that accounts for drag/scroll direction, and think about what problems this approach might introduce.

[mho79]

has there been any progress on this issue? or a workaround?

[hushicai]

I think custom scroller that supports momentum scroll event will solve this problem.

[MoOx]

I think I found something that might help to debug this. While investigating for #829, I tried to wrap my app with a ScrollView without any actual scroll (no specific height or flex). A sort of useless ScrollView, but not that useless as touch events are still triggered. It's just that scroll is never fired.
And with this setup, I experienced some weird cases, while touching/moving. I didn't always get a cancel for a given touch. I am not able yet to reproduce but playing with on mobile clearly show that the opacity effect is not always canceled while scrolling... https://v84xmm7l37.codesandbox.io/

We can clearly see most scroll trigger onPress, but not all. And we know it before releasing the finger.

[necolas]

Closing this issue so we can coordinate findings and solutions in #1219