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

onLongPress (and delayLongPress) triggers immediately #4944

Closed
yonatanmn opened this issue Dec 23, 2015 · 34 comments
Closed

onLongPress (and delayLongPress) triggers immediately #4944

yonatanmn opened this issue Dec 23, 2015 · 34 comments
Labels
Good first issue Interested in collaborating? Take a stab at fixing one of these issues. Help Wanted :octocat: Issues ideal for external contributors. Resolution: Locked This issue was locked by the bot.

Comments

@yonatanmn
Copy link

For some reason (I have no clue why) onLongPress triggers immediately, and onPress doesn't.
tested on : android simulator with genymotion (galaxy5) and real galaxy3 device

After adding delayLongPress i figured out that it's "stealing" 1000ms from the delay, and I guess the default delay is 1000, so it's triggering immediately.

for example :

  <TouchableOpacity      
               delayLongPress={3800}
               onPress={()=>{
                  console.log(' onPress');  
                  console.log(Date.now())}}
               onPressIn ={()=>{
                  console.log('TouchableOpacity onPressIn'); 
                  console.log(Date.now())
                }}
               onLongPress ={(e)=>{
                  console.log(' onLongPress');
                  console.log(Date.now());
                  console.log(e.type); //undefined
               }}
           >

when I calculate : onLongPress time - onPressIn time , I get ~2800ms
without delayLongPress or with delayLongPress={1000} I get 10-20ms

@yonatanmn yonatanmn changed the title onLongPress (and delayLongPress) bug onLongPress (and delayLongPress) triggers immediately Dec 23, 2015
@facebook-github-bot
Copy link
Contributor

Hey yonatanmn, thanks for reporting this issue!

React Native, as you've probably heard, is getting really popular and truth is we're getting a bit overwhelmed by the activity surrounding it. There are just too many issues for us to manage properly.

  • If you don't know how to do something or not sure whether some behavior is expected or a bug, please ask on StackOverflow with the tag react-native or for more real time interactions, ask on Discord in the #react-native channel.
  • If this is a feature request or a bug that you would like to be fixed, please report it on Product Pains. It has a ranking feature that lets us focus on the most important issues the community is experiencing.
  • We welcome clear issues and PRs that are ready for in-depth discussion. Please provide screenshots where appropriate and always mention the version of React Native you're using, as well as the platform you're on e.g.- Android, iOS. Thank you for your contributions!

@satya164
Copy link
Contributor

Duplicate of this? #4088

@yonatanmn
Copy link
Author

Looks like the same problem,
closed dev-tools (and added other display - not console.log) and it's working fine

@jozn
Copy link

jozn commented Dec 24, 2015

+1 when i debugging in chrome i see this behavior.

@satya164 satya164 added the Help Wanted :octocat: Issues ideal for external contributors. label Dec 24, 2015
@brentvatne brentvatne added Good first issue Interested in collaborating? Take a stab at fixing one of these issues. Community Responsibility labels Dec 24, 2015
@yonatanmn
Copy link
Author

similar thing happens for ScrollView.onScroll- also blocking the scroll

@martincox
Copy link

I tried to investigate this problem but could not replicate the behaviour. I used the example code provided by @yonatanmn and the onPress and onLongPress fired as expected.

Is there more to this, or has it been fixed?

@christopherdro
Copy link
Contributor

Confirming that this happens only with chrome debugger enabled.

@IjzerenHein
Copy link
Contributor

Also confirming that this happens only with chrome debugger enabled.

@nicastelo
Copy link

Same. Confirming that this happens only with chrome debugger enabled.

@sharnik
Copy link
Contributor

sharnik commented Oct 27, 2016

I've just tested that and it looks like it's reversed now ;)

Without debugging tools the longPress triggers after holding for ~500-600ms, but with Chrome debugging open you need to wait ~3400ms.

I don't know whether it's a bug or a feature, but it seems that the original problem (launching onLongPress instead of onPress) has been solved.

@zyxcambridge
Copy link

ExceptionsManager.js:71 Attempted to transition from state RESPONDER_INACTIVE_PRESS_IN to RESPONDER_ACTIVE_LONG_PRESS_IN, which is not supported. This is most likely due to Touchable.longPressDelayTimeout not being cancelled.reactConsoleErrorHandler @ ExceptionsManager.js:71console.error @ YellowBox.js:61_handleLongDelay @ Touchable.js:596proxiedMethod @ createPrototypeProxy.js:44(anonymous function) @ JSTimers.js:80callTimer @ JSTimersExecution.js:95callTimers @ JSTimersExecution.js:136__callFunction @ MessageQueue.js:236(anonymous function) @ MessageQueue.js:108guard @ MessageQueue.js:46callFunctionReturnFlushedQueue @ MessageQueue.js:107onmessage @ debuggerWorker.js:44

@pocesar
Copy link

pocesar commented Feb 27, 2017

Hmm it randomly started happening, after testing on real device with RN Debugger. it was working fine, and suddenly stopped working, onLongPress is being called on quick single tap instead of onPress.

@battuashwik
Copy link

Im seeing this issue too.

@ThisIsMissEm
Copy link

@brentvatne @satya164 How can I help? (I'm seeing this, and it's causing me issues with my workflow, and also may be resulting in the app just randomly exiting).

@skhan02
Copy link

skhan02 commented Apr 11, 2017

i am seeing this issue as well

@loune
Copy link

loune commented May 1, 2017

I've just encountered this issue as well when debugging on Android. React Native 0.43.4. I think this is due to #4470 The default press delay is 130ms and long press delay 470ms. This means that to be considered for a normal press, the release event needs to come before 600ms. If I log the Touchable events I see this:

1493638393648 RESPONDER_GRANT
1493638393694 DELAY
1493638393696 LONG_PRESS_DETECTED
1493638393716 RESPONDER_RELEASE

DELAY fires 46ms after press, not 130ms which what is supposed to happen. LONG_PRESS_DETECTED fires 48ms after press, not 600ms, then release comes 68ms.
This shows that there's something wrong with setTimeout, which is noted in #4470 - although it's marked as fixed, I'm not confident it is.

Also, notice that DELAY and LONG_PRESS_DETECTED is so close together - that's because the two setTimeout calls are made simultaneously but with different timeouts (130, 600). However, this bug makes them fire really close together, and sometimes flipped around, which causes bugs like #1693 which @zyxcambridge mentioned above

This is with no debugging, which is much more reasonable:

1493639762975 RESPONDER_GRANT
1493639763124 DELAY
1493639763492 LONG_PRESS_DETECTED
1493639764786 RESPONDER_RELEASE

@hramos
Copy link
Contributor

hramos commented Jul 20, 2017

Hi there! This issue is being closed because it has been inactive for a while. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. Either way, we're automatically closing issues after a period of inactivity. Please do not take it personally!

If you think this issue should definitely remain open, please let us know. The following information is helpful when it comes to determining if the issue should be re-opened:

  • Does the issue still reproduce on the latest release candidate? Post a comment with the version you tested.
  • If so, is there any information missing from the bug report? Post a comment with all the information required by the issue template.
  • Is there a pull request that addresses this issue? Post a comment with the PR number so we can follow up.

If you would like to work on a patch to fix the issue, contributions are very welcome! Read through the contribution guide, and feel free to hop into #react-native if you need help planning your contribution.

@hramos hramos added the Icebox label Jul 20, 2017
@hramos hramos closed this as completed Jul 20, 2017
@pocesar
Copy link

pocesar commented Jul 21, 2017

it's been inactive but still happening and should not be closed. it's even worse lately when using react-native-router-flux because it brings up a red box when transitioning between scenes with the error mentioned by @zyxcambridge

@foufee
Copy link

foufee commented Jul 31, 2017

I started seeing this today too...using react native, and RNRF too.

@digitalmaster
Copy link

digitalmaster commented Aug 27, 2017

Confirmed.. this is still happening. Only when dev tools is connected tho.

@Athosone
Copy link

Athosone commented Sep 3, 2017

Yes still happening.. (i am on ios)
Was working fine yesterday and today bam...

@oakis
Copy link

oakis commented Sep 29, 2017

The opposite happens to me. onLongPress takes around 2 seconds to fire, regardless of delayLongPress time. If I turn off remote debugging it is working as expected.

Edit: Actually in my case it was a firebase async call that caused the delay.

@themakerman
Copy link

+1 happening only with chrome debugger. I hope this doesn't happens in production.

@whylifes
Copy link

A competition

@whylifes
Copy link

hello,I am go away!

@whylifes
Copy link

forgive

@ricklove
Copy link

Ah, I thought I broke everything. Thankfully it's just because of Chrome debugger.

Works fine when I disable debugger. (Using Expo)

@gorvinsky
Copy link

Still having this issue and only happen when connected to Chrome debugger.

@ghost
Copy link

ghost commented Feb 26, 2018

This breaks only when debug JS remotely is enabled. im using VSCode debugger.
this needs to be reopened

@hramos hramos added Help Wanted :octocat: Issues ideal for external contributors. and removed Help Wanted :octocat: Issues ideal for external contributors. labels Mar 8, 2018
@james-lopez
Copy link

maybe a obvious mistake on my part but i was not passing onLongPress a function initially i was declaring a method instance which caused it to fire on load.

<TouchableWithoutFeedback onLongPress={this.someHandlerFunction}/>

whereas it should be

<TouchableWithoutFeedback onLongPress={() => this.someHandlerFunction}/>

@ricklove
Copy link

@apn-james both of those should be ok (what might be missing in the first is a bind function unless that is an arrow function instance).

Did you write the first call with parans maybe?

<TouchableWithoutFeedback onLongPress={this.someHandlerFunction()}/>

@james-lopez
Copy link

@ricklove true i did pass params and did not bind the first instance.

@Gennady77
Copy link

The same problem while remote debugging.

@PaulPourtout
Copy link

Still happening randomly (but at high frequency) on external device when remote debbuger is on. Tested it on Android devices only not sure if it happens on iOS.

@facebook facebook locked as resolved and limited conversation to collaborators Jul 20, 2018
@react-native-bot react-native-bot added the Resolution: Locked This issue was locked by the bot. label Jul 20, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Good first issue Interested in collaborating? Take a stab at fixing one of these issues. Help Wanted :octocat: Issues ideal for external contributors. Resolution: Locked This issue was locked by the bot.
Projects
None yet
Development

No branches or pull requests