React-native: Remote Debugger breaks onPress on Touchable Components

[juanjsebgarcia]

React Native version: 0.61.2

Steps To Reproduce

1. Enable the remote debugger
2. Tap a TouchableOpacity with onPress and onLongPress parameters
3. Note that onLongPress is fired and not onPress even on short taps
4. Works correctly if not in remote debugging
   

Describe what you expected to happen:

Upon a quick tap the component onLongPress fires, expected onPress to fire.

Minimal example

import React, { Component } from 'react';
import { Alert, Text, TouchableOpacity, View } from 'react-native';

class ExampleComponent extends Component<Props> {
  public render() {
    return (
      <View>
        <TouchableOpacity
          onPress={() => Alert.alert('Press')}
          onLongPress={() => Alert.alert('Long Press')}>
         <Text>Hello World</Text>
        </TouchableOpacity>
      </View>
    );
  }
}

When in remote debugging onLongPress always fires.

[98ff98]

I have same problem too

[alexciarlillo]

I am seeing this on actual devices, Samsung S8 and intermittently on Pixel 2. If I tap many times very fast I can sometimes trigger the event on the Pixel 2, but it never fires on the S8.

edit: Both are running Android 9.

[stale[bot]]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as a "Discussion" or add it to the "Backlog" and I will leave it open. Thank you for your contributions.

[juanjsebgarcia]

I don't seem to have permissions to add a label, but this is definitely still an active issue and should not be closed.

[chuanhaisoft]

same problem，onpress event not work，on android6

[alexciarlillo]

I believe I ended up tracking this down to an issue with there being a time difference between the host and device. Since the time is off, the calculation for whether it was a short press or long press is broken (or something like that). You can verify this by running adb shell "date" && date to see if the times are off. I think I was usually able to fix this by going into the device settings, disabling automatic time resolution, and then re-enabling it. I think there was also a way to do this via an adb command but can't recall what it is.

[juanjsebgarcia]

Nice research @alexciarlillo. That definitely sounds plausible. Ideally this time sync would be something RN handles itself upon init.

I know if you spend too long at a breakpoint when using debugger and then resume it complains that the computer and device times have diverged. Perhaps a solution would be to have it sync times across both devices more often?

[Elias-Graf]

To sync up time on Linux and OSX: adb shell su -c date "$(date +%m%d%H%M%Y.%S)".

This command requires a rooted phone.

Can confirm that the press is now working.

[Elias-Graf]

@alexciarlillo Do you know why this occurs? Why are press events being processed on the package server and not the consumer? I just ran into this again and this is really annoying and takes a while until you realize that this is the issue (maybe anyone knows whom to bother with this? :D).

[alexciarlillo]

I'm not sure what the root cause is here, but when using remote debugging the code will always execute on the host machine, not the device itself. It's probably just mixup between the timestamp sent along with the native event not matching the actual time of the package server when it handles the event.

[Elias-Graf]

This is not just breaking onPress but also animation delays. See this SO post https://stackoverflow.com/questions/57178762/react-native-animated-delay-doesnt-respect-given-value/61652682#61652682

[juanjsebgarcia]

I have weird issues with setInterval sometimes in debug mode too.

The interval in code is usually not the interval that is followed.

What usually happens in a transition that is meant to take say 2000ms, completes in 200ms. I usually just force stop the application (Android) and then restart it.

I wonder if this issue is related to the one being discussed here.

[Elias-Graf]

@juanjsebgarcia If you're experiencing this run echo "Host\t\t$(date +%Y-%m-%d_%H:%M:%S)" && echo "Emulator\t$(adb shell date +%Y-%m-%d_%H:%M:%S)" and compare the times, if their not synced up, you probably have the issue (Linux / Unix command only, if someone can make a windows version, that would be great [I tried but failed lol])

[kenobi91]

Thing is still not working for me, i ahve Huawei P20 i tried to disable/enebale automatic time in settings but problem is still there, my phone and mac have 2 sec diff.

[abhisheq6u]

@alexciarlillo You could have saved a lot more lives by recalling the adb command. Is it too much to ask for? :(

[Elias-Graf]

Linux and OSX: adb shell su -c date "$(date +%m%d%H%M%Y.%S)".

This command requires a rooted phone.

Can confirm that the press is now working.

@abhisheq6u ...

[beniaminorossini]

I believe I ended up tracking this down to an issue with there being a time difference between the host and device. Since the time is off, the calculation for whether it was a short press or long press is broken (or something like that). You can verify this by running adb shell "date" && date to see if the times are off. I think I was usually able to fix this by going into the device settings, disabling automatic time resolution, and then re-enabling it. I think there was also a way to do this via an adb command but can't recall what it is.

It solves, thx... but what a craziness!

[petergaultney]

a few of us are experiencing this after an upgrade from 0.61 to 0.62. It would be great to have this addressed; it's quite a major step backward not to be able to use the "improved" debugging mode on a physical device.

Unfortunately not all of our development devices are/can be rooted.

[Jlexyc]

I have 1 second difference that I can't fix. And app doesn't trigger onPress. Nice to see that this issue isn't fixed from Oct 25.

[bobsmits]

Same issue

[Pczek]

Also had a 2 sec difference. Disabling and enabling Automatic Date & Time didn't resolve the issue. I set the time manually in the future in the hope it will process the events now, no success as well.
However! Reenabling Automatic Date & Time after that might have forced it to pull a time back in sync with my development system. 🙌

[abhisheq6u]

In my case, none of this worked and I don't have a rooted device, so I ended up matching the time of phone and system manually. Apparently, accuracy upto milliseconds is not required, accuracy upto seconds is enough. So it worked that way. I have to do it everytime though and its really annoying.

[hariantara]

Make sure you set the real device or emulator time as the same as your pc or laptop time until the seconds part should be the exactly the same.

I have tried it and it solved

[aurangdgera]

I believe I ended up tracking this down to an issue with there being a time difference between the host and device. Since the time is off, the calculation for whether it was a short press or long press is broken (or something like that). You can verify this by running adb shell "date" && date to see if the times are off. I think I was usually able to fix this by going into the device settings, disabling automatic time resolution, and then re-enabling it. I think there was also a way to do this via an adb command but can't recall what it is.

I Ran --> $ adb shell "date" && date
Tue Jun 30 21:26:54 EDT 2020
Tue Jun 30 21:26:54 IST 2020

--> But still touchable are not working when debugging. What the heck is going on :((((
Android Device MOTO G4+
I don't know whether EDT and IST are the problems.

[hariantara]

@aurangdgera

please disable this on your device or emulator setting
use-network-provided timezone & use network-provided time

and then set time manually the same as laptop or your pc time (includes the seconds part should be exactly the same)

after that you need reinstall the app and re run

[OkancanCosar]

first of all check adb date and your pc date with
adb shell "date" && date
if this dates are different, pc and device (real phone or emulator) set automatic network-provided time. Carefull both device(pc and phone or emulator.)
this works for me

[simonpaix]

I had this bug and tracked it to having different times between my device and pc (output of adb shell "date" && date). Restarting my phone fixed it for me (even in debug mode)

[eltel]

I believe I ended up tracking this down to an issue with there being a time difference between the host and device. Since the time is off, the calculation for whether it was a short press or long press is broken (or something like that). You can verify this by running adb shell "date" && date to see if the times are off. I think I was usually able to fix this by going into the device settings, disabling automatic time resolution, and then re-enabling it. I think there was also a way to do this via an adb command but can't recall what it is.

Thanks!! This worked for me! :)

[lorenz068]

I believe I ended up tracking this down to an issue with there being a time difference between the host and device. Since the time is off, the calculation for whether it was a short press or long press is broken (or something like that). You can verify this by running adb shell "date" && date to see if the times are off. I think I was usually able to fix this by going into the device settings, disabling automatic time resolution, and then re-enabling it. I think there was also a way to do this via an adb command but can't recall what it is.

Thanks!! This worked for me! :)

me too

[AndrewMorsillo]

This issue affects far more than just onPress. Set your clock to be slightly different than the device clock and observe things such as:

• setInterval will fire immediately in an infinite loop or other broken behavior
• Animation timing and delays will be off.
• Animations will lag and run past their stop times.
• Staggered animations will animate the first element to completion then animate the rest staggered as defined.
• The app will randomly crash a lot
• Occasionally all input will be ignored until the app is restarted
• Pausing a breakpoint will crash/hang the app upon trying to resume
• General performance will be unusable when debugging, 5-10x slower than dev mode and 20+x slower than release build. Many interactions simply don't work or crash the app.
• Profiling tools are unusable due to the poor performance (although there are many other issues with them as well this one renders them unusable)
• react-devtools glitches out and loses connection

I'm pretty sure this has been an issue for a very long time, much longer than the Oct 2019 this issue was filed. I recall seeing this behavior at least 2 years ago.

Poor performance and stability when developing in the Android emulator is by far my team's number one pain point with react-native (and it's definitely RN not the emulator as Flutter dev experience is buttery smooth on the same emulated device). It seems this timing issue may be at the core of that problem so hopefully we can figure out what's going on and improve the experience!

Edit: I did some digging and seem to have made the issue significantly better by syncing the clock of the android emulator and system. Here's how:

• You must have root access. This means a "google-apis" emulator image not a "google-play" one
• Check the drift between your system and android clock with echo "Host\t\t$(date +%Y-%m-%d_%H:%M:%S:%3N)" && echo "Emulator\t$(adb shell date +%Y-%m-%d_%H:%M:%S:%3N)"
• Sync the time (from a unix shell, I used git bash on windows) with adb root && adb shell date "$(date +%m%d%H%M%Y.%S%3N)"
• Check time again, they should be in sync

After doing this things are (fingers crossed, for now) much smoother!

[AlexeyJersey]

I believe I ended up tracking this down to an issue with there being a time difference between the host and device. Since the time is off, the calculation for whether it was a short press or long press is broken (or something like that). You can verify this by running adb shell "date" && date to see if the times are off. I think I was usually able to fix this by going into the device settings, disabling automatic time resolution, and then re-enabling it. I think there was also a way to do this via an adb command but can't recall what it is.

Awesome!!! 🎉

[dumbokitty]

Is this still open? The mannual adjusting is really painful.

[Imperio8]

Had same issue. Switching Automatic Date & Time off and on on my physical device didn't fix this. I noticed the bug was on my emulator as well, so what I did was switch the automatic time on my machine (windows 10) off and on. It worked instantly!

[juanjsebgarcia]

I think what I would consider the end goal for this issue is to have the build tools run the sync time operations as part of a debug build, resolving the need for manual intervention and producing the right experience out of the box.

I'll admit I'm not sure how to approach it myself, but I do think that's the solution.

[safaiyeh]

@juanjsebgarcia it might be worth checking if the cli team would want to add this in

[WouterFlorijn]

@juanjsebgarcia I would say the only acceptable solution is to not rely on the times being synced. The debugger didn't seem to rely on this earlier, as it has always worked fine for me without syncing device and host times. Having to sync the time is unreliable, as it can go out of sync at any moment. Whenever I managed to manually or automatically sync, it always stopped working again after only a few seconds.

[petergaultney]

i'd agree (without much context for what the alternatives are, if any) that relying on timestamps being similar between two different computers for any functionality is a dangerous proposition.

[AndrewMorsillo]

@petergaultney @WouterFlorijn Agreed, relying on exact time sync between two systems seems like a pretty universally "bad idea". @safaiyeh Do you know why this time sync is a requirement or know who to tag to get that answer? I think that's probably the first step in figuring out the best solution for the issue.

[safaiyeh]

I do not, I know you've had issues with this in another issue.

@shergin or @cpojer may know!

[SimonChaumet]

Still not fixed yet ?

[farhanisml]

i have the same issue when i use firefox as debugger. Try use chrome as debugger, and when running your project try "npm start" then "npm run android/ios" . It solve my problem. Hope it solve yours too. Have a nice day everyone.

[varunraghu3112]

I believe I ended up tracking this down to an issue with there being a time difference between the host and device. Since the time is off, the calculation for whether it was a short press or long press is broken (or something like that). You can verify this by running adb shell "date" && date to see if the times are off. I think I was usually able to fix this by going into the device settings, disabling automatic time resolution, and then re-enabling it. I think there was also a way to do this via an adb command but can't recall what it is.

Re-enabling and enabling the automatic time option works (NOTE: Internet must be turned on for sure else it won't work !)

[afilp]

@varunraghu3112 I tried this and it worked sometimes (not always) do we also have to remove the cable from the device, so that we start adb reverse again? I mean, are there steps in a specific order to make this work? (when to turn off the internet, etc.). Thanks!

[verybluebot]

@alexciarlillo That was exactly my case! Would never thought about that thanks :)