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

default hitSlop values to 0 #22281

Closed
wants to merge 1 commit into from
Closed

Conversation

Taylor123
Copy link
Contributor

Motiviation

Experienced a TouchableOpacity releasing the PanResponder without invoking onPress due to a missing a direction key in the hitSlop prop; The missing key caused the corresponding pressExpand to become NaN which causes isTouchWithinActive to become falsey, when it should be truthy.

If defaulting to 0 is undesired behavior, I'm happy to take a different approach.

Test Plan:

Used local version of react-native within the application as well as running existing test suite.

New tests don't seem necessary based on the added code.

Changelog:

[General] [Fixed] - Fix unexpected responder release by defaulting hitSlop object values to 0 within touchableHandleResponderMove

@facebook-github-bot facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Nov 15, 2018
@pull-bot
Copy link

Warnings
⚠️

📋 Release Notes - This PR appears to be missing Release Notes.

Generated by 🚫 dangerJS

@tychota
Copy link
Contributor

tychota commented Nov 16, 2018

That super nice.

I encountred the same issue just 2 weeks ago (as it was preventing apple validation on some device) and I was trying to find the cause in native which did not works (RCTConvert correctly convert incomplete hitslop). Now it makes sense since the part of the touch handling is handle in JS (so happy to learn that).

That make it it crystal clear why the native component did seems to receive the touch (touchable opacity got the touched opacity) but nothing changed on JS.

I think 0 is the good default.

@facebook-github-bot facebook-github-bot added the Import Started This pull request has been imported. This does not imply the PR has been approved. label Dec 7, 2018
Copy link
Contributor

@facebook-github-bot facebook-github-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cpojer is landing this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

@react-native-bot
Copy link
Collaborator

@Taylor123 merged commit f6d3a61 into facebook:master.

@facebook facebook locked as resolved and limited conversation to collaborators Dec 7, 2018
@react-native-bot react-native-bot added the Merged This PR has been merged. label Dec 7, 2018
kelset pushed a commit that referenced this pull request Dec 12, 2018
Summary:
Experienced a `TouchableOpacity` releasing the `PanResponder` without invoking `onPress` due to a missing a direction key in the `hitSlop` prop; The missing key caused the corresponding pressExpand to become NaN which causes `isTouchWithinActive` to become falsey, when it should be truthy.

If defaulting to 0 is undesired behavior, I'm happy to take a different approach.
Pull Request resolved: #22281

Differential Revision: D13374335

Pulled By: cpojer

fbshipit-source-id: f9d28e51b9d9c45aed42bea2df3d844a799fa827
@hramos hramos removed Import Started This pull request has been imported. This does not imply the PR has been approved. labels Feb 6, 2019
aleclarson pushed a commit to alloc/react-native-macos that referenced this pull request Jan 29, 2020
Summary:
Experienced a `TouchableOpacity` releasing the `PanResponder` without invoking `onPress` due to a missing a direction key in the `hitSlop` prop; The missing key caused the corresponding pressExpand to become NaN which causes `isTouchWithinActive` to become falsey, when it should be truthy.

If defaulting to 0 is undesired behavior, I'm happy to take a different approach.
Pull Request resolved: facebook/react-native#22281

Differential Revision: D13374335

Pulled By: cpojer

fbshipit-source-id: f9d28e51b9d9c45aed42bea2df3d844a799fa827
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. Merged This PR has been merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants