Touch/Mouse Input Will Not Leak To Child Components of ScrollView After Focus is in TextInput (Since 0.62)

[NickGerleman]

From @KAnder425

I've got a repro in the playground. It's in my repo at https://github.com/KAnder425/react-native-windows/commit/93a31c0dca5c08c8ef82bf6ff4887ffc8db40eba

To repro you must put your focus back in the Text Input after bringing up the Popup. The first touch event after that will be ignored (see ("I'm touched" counter).

I also have a gif of the repro attached.

The key pieces are;

• Popup must be isLightDismissEnable (false)
• The Touchable must be in a ScrollView
• Focus must be in a TextInput outside of the Popup (or maybe just outside the Touchable, IDK)

I did notice that the same behavior (eg. swallowing a touch event) occurs more broadly in our app as well as in RNTester, because it really doesn't depend on the Popup. You can repro this in the FlatList example in RNTester if you just put focus into a TextInput before clicking on the FlatList elements.

For now, I've been able to workaround this in our app by setting the 'keyboardShouldPersistTaps' property (either 'always' | 'handled') on the ScrollView that contains the TextInput, but I'd prefer a solution in RNW. agree it's quite tricky

[NickGerleman]

Confirmed the regression started with ae37f8e which was the upgrade to 0.62.

In the above case, the ScrollView sees onResponderGrant instead of the TouchableHighlight. The responder state machine is controlled by upstream JS in RN, depending on touchStart, touchEnd, and seemingly some other factors. Confirmed that in the repro case, we still correctly send touchStart from native using the react tag for TouchableHighlight instead of the ScrollView.

[NickGerleman]

ScrollResponder has some logic to take precedent over nested views if their is a TextInput focused and keyboardPersistTaps is undefined or never https://github.com/facebook/react-native/blob/0.62-stable/Libraries/Components/ScrollResponder.js#L153-L243 This is what's triggering the logic. Debugging to figure out why we weren't hitting it before.

[NickGerleman]

We saw the behavior change because the 0.62 merge fixed the implementation of TextInputState.currentlyFocusedField(), which triggers upstream logic around it that only really makes sense on phones. We should change this to only eat input in the case where a soft-keyboard is up, since that's the intent.