React-native: [Touchable* + Text] "Touchable cannot transition" error about 20% of the time

[uoroaix]

Hi I am not really sure if this is an issue or not, but I thought i posted here so if anyone have the same problem, they know what was going on.

Apparently if you render some touchablebutton to be like this

render: function() {
   return (
     <View style={styles.contentContainer}>
       <TouchableOpacity onPress={this._onPressQRCode}>
         <Text style={styles.scanButtonText}>Click To Start Scanning</Text>
       </TouchableOpacity>
     </View>
   );
 },

you will run into this error very frequently

Error: Touchable cannot transition from `RESPONDER_INACTIVE_PRESS_IN` to `LONG_PRESS_DETECTED` for responder `.r[1]{TOP_LEVEL}[0].0.0.$nav2.0.1`
 stack: 
  TouchableMixin._receiveSignal                               index.ios.bundle:33197
  TouchableMixin._handleLongDelay                             index.ios.bundle:33176
  JSTimers.setTimeout.JSTimersExecution.callbacks.(anonymous  index.ios.bundle:8273
  JSTimersExecution.callTimer                                 index.ios.bundle:8062
  Object.JSTimersExecution.callTimers                         index.ios.bundle:8085
  jsCall                                                      index.ios.bundle:7511
  MessageQueueMixin._callFunction                             index.ios.bundle:7774
  <unknown>                                                   index.ios.bundle:7801
 URL: undefined
 line: undefined
 message: Touchable cannot transition from `RESPONDER_INACTIVE_PRESS_IN` to `LONG_PRESS_DETECTED` for responder `.r[1]{TOP_LEVEL}[0].0.0.$nav2.0.1`

To solve the problem just wrap the text inside the
touchableopacity/touchablehighlight with a child view like this

render: function() {
   return (
     <View style={styles.contentContainer}>
       <TouchableOpacity onPress={this._onPressQRCode}>
         <View>
           <Text style={styles.scanButtonText}>Click To Start Scanning</Text>
         </View>
       </TouchableOpacity>
     </View>
   ); 

and seems to not run into that error anymore.

[arypurnomoz]

+1

[gkrimer]

This happens for me with regularity but only when running on the device and debugging in Chrome. If I run on the device without debugging this error does not occur. Anyone seeing the same behavior?

[brentvatne]

@spicyj - assigned you because it seems related to responders :smile:

[sophiebits]

I don't actually know anything about this stuff… maybe @vjeux does.

[philharton]

I've been getting the same error with a TouchableHighlight wrapping an Image, so it doesn't seem related to Text. I've only seen this while debugging in Chrome thus far but will update if that changes.

[piyushchauhan2011]

It is same when i'm wrapping the <Icon /> from react-native-icons. I'm really stressed out with the production app we are building and the error keeps coming up :cry:

[piyushchauhan2011]

@brentvatne @vjeux @spicyj The same error comes up when we try to use inspect element mode. It seems the elements there are also TouchableHighlight and when we press on one of them in random order the same error comes up. So I think this is really an issue needs to be handled immediately.

[piyushchauhan2011]

??

[palmovitsch]

I had the same issue with Image surrounded by TouchableHighlight. Also just coming up on a real device while debugging in Chrome. Thanks uoroaix. Surrounding the Image with View solved the problem.

[ilansas]

Do we have an official fix or explanation ? This error is so annoying !

[aleclarson]

Any update on this, @vjeux? The error message is cryptic and the stack trace is useless to us.

[piyushchauhan2011]

:+1:

[vjeux]

No update sorry, if anyone of you can investigate what is happening and figure out if you can make a fix that would be awesome!

[deanmcpherson]

For reference, I was seeing a heap of these warnings, and it turned out I had removed the LaunchScreen from the project (also fixed #2018 for me). No idea why the LaunchScreen would be so important, but it fixed if for me.

[satya164]

Also happening on Android, real device.

[ghost]

Seeing this too on Nexus 6 + Chromium debugging. App is just a very simple test of Navigator, and it works without debugging, though route transitions are sluggish. As soon as I debug it, I get a red screen of death with the above message.

[satya164]

@RoryHunter Check https://facebook.github.io/react-native/docs/performance.html#slow-navigator-transitions for the transitions issue

[kanerogers]

Encountered this same issue:

• On iOS
• Real device (iPhone 6 Plus)
• Debugging in Chrome.

Only started happening to me this morning, but went through the following steps to resolve it:

1. Wrapping text in a view (as mentioned above) - no success.
2. Checking out to an earlier revision - no success.
3. Cleaning project, quitting XCode, Chrome, etc - no success.
4. Restarted device, re-opened app with inspector enabled - no success.
5. Disabled inspector after restart - issue resolved.

Given that the restart and some further fiddling resolved the issue, could this be memory related?

Here's further details:

Stack Trace

Error: Touchable cannot transition from `RESPONDER_INACTIVE_PRESS_IN` to `LONG_PRESS_DETECTED` for responder `.r[1]{TOP_LEVEL}[0].2.1.0.1.0`
 stack: 
  TouchableMixin._receiveSignal           index.ios.bundle?…:41098
  TouchableMixin._handleLongDelay         index.ios.bundle?…:41077
  JSTimersExecution.callbacks.(anonymous  index.ios.bundle?…:6158
  JSTimersExecution.callTimer             index.ios.bundle?…:5942
  Object.JSTimersExecution.callTimers     index.ios.bundle?…:5965
  MessageQueue.__callFunction             index.ios.bundle?…:5574
  <unknown>                               index.ios.bundle?…:5512
  guard                                   index.ios.bundle?…:5467
  <unknown>                               index.ios.bundle?…:5512
 URL: undefined
 line: undefined
 message: Touchable cannot transition from `RESPONDER_INACTIVE_PRESS_IN` to `LONG_PRESS_DETECTED` for responder `.r[1]{TOP_LEVEL}[0].2.1.0.1.0`

Component source:

      <TouchableHighlight
        style={styles.container}
        underlayColor='#eee'
        onPress={this.props.handler}>

        <View style={styles.container}>
          <View style={styles.label}>
            <Text style={styles.labelText}>{this.props.label}</Text>
          </View>
          <View style={styles.icon}>
            <Icon name={this.props.icon} size={60} color="green" />
          </View>
        </View>

      </TouchableHighlight>

Inspector screenshot:

Hope any of this helps!

[JAStanton]

+1 I have been getting this a lot lately.

[piyushchauhan2011]

:+1: same here

[theopolisme]

:+1: have been encountering repeatedly.

[abbothzhang]

when TouchableOpacity wraped by ScrollView,it occured still

[brancusi]

Not sure what changed, getting this on almost every press now. Not using ScrollView. Only happens when using chrome debug. Pretty much have to disable chrome debug now which is a big pain.

Hope there is a solution for this soon.

[yychun1217]

Encountered this error as well, TextInput inside ScrollView on iOS

[piyushchauhan2011]

:+1: repeated encounters

[Thomas101]

Hey,

I've been doing some digging on this issue. Found out that it's because of a bug with setTimeout. When using chrome debugging they can fire in the incorrect order. (See dedicated issue and example in #4470).

What happens with this one is in the function touchableHandleResponderGrant in Components/Touchable/Touchable.js you setup two setTimeouts and when they fire in the incorrect order the touch responder graph drops out to an error state which causes the red screen of death.

I've got very much a 'paint over the cracks' fix, which most probably has unforeseen side-effects but will at least enable you to debug in chrome again. I definitely remove this before deploying to production In Components/Touchable/Touchable.js change...

RESPONDER_INACTIVE_PRESS_IN: {
    DELAY: States.RESPONDER_ACTIVE_PRESS_IN,
    RESPONDER_GRANT: States.ERROR,
    RESPONDER_RELEASE: States.NOT_RESPONDER,
    RESPONDER_TERMINATED: States.NOT_RESPONDER,
    ENTER_PRESS_RECT: States.RESPONDER_INACTIVE_PRESS_IN,
    LEAVE_PRESS_RECT: States.RESPONDER_INACTIVE_PRESS_OUT,
    LONG_PRESS_DETECTED: States.ERROR,
  },

to be

RESPONDER_INACTIVE_PRESS_IN: {
    DELAY: States.RESPONDER_ACTIVE_PRESS_IN,
    RESPONDER_GRANT: States.ERROR,
    RESPONDER_RELEASE: States.NOT_RESPONDER,
    RESPONDER_TERMINATED: States.NOT_RESPONDER,
    ENTER_PRESS_RECT: States.RESPONDER_INACTIVE_PRESS_IN,
    LEAVE_PRESS_RECT: States.RESPONDER_INACTIVE_PRESS_OUT,
    LONG_PRESS_DETECTED: States.RESPONDER_ACTIVE_LONG_PRESS_IN,//States.ERROR,
  },

Again I definitely remove this before deploying to production

[kanerogers]

Awesome find!!
On Wed, 2 Dec 2015 at 1:06 AM, Thomas Beverley [email protected]
wrote:

Hey,

I've been doing some digging on this issue. Found out that it's because of
a bug with setTimeout. When using chrome debugging they can fire in the
incorrect order. (See dedicated issue and example in #4470
https://github.com/facebook/react-native/issues/4470).

What happens with this one is in the function
touchableHandleResponderGrant in Components/Touchable/Touchable.js you
setup two setTimeouts and when they fire in the incorrect order the touch
responder graph drops out to an error state which causes the red screen of
death.

I've got very much a 'paint over the cracks' fix, which most probably has _unforeseen
side-effects_ but will at least enable you to debug in chrome again. _I
definitely remove this before deploying to production_ In
Components/Touchable/Touchable.js change...

RESPONDER_INACTIVE_PRESS_IN: {
DELAY: States.RESPONDER_ACTIVE_PRESS_IN,
RESPONDER_GRANT: States.ERROR,
RESPONDER_RELEASE: States.NOT_RESPONDER,
RESPONDER_TERMINATED: States.NOT_RESPONDER,
ENTER_PRESS_RECT: States.RESPONDER_INACTIVE_PRESS_IN,
LEAVE_PRESS_RECT: States.RESPONDER_INACTIVE_PRESS_OUT,
LONG_PRESS_DETECTED: States.ERROR,
},

to be

RESPONDER_INACTIVE_PRESS_IN: {
DELAY: States.RESPONDER_ACTIVE_PRESS_IN,
RESPONDER_GRANT: States.ERROR,
RESPONDER_RELEASE: States.NOT_RESPONDER,
RESPONDER_TERMINATED: States.NOT_RESPONDER,
ENTER_PRESS_RECT: States.RESPONDER_INACTIVE_PRESS_IN,
LEAVE_PRESS_RECT: States.RESPONDER_INACTIVE_PRESS_OUT,
LONG_PRESS_DETECTED: States.RESPONDER_ACTIVE_LONG_PRESS_IN,//States.ERROR,
},

Again _I definitely remove this before deploying to production_

—
Reply to this email directly or view it on GitHub
https://github.com/facebook/react-native/issues/1693#issuecomment-160978459
.

[alubling]

@Thomas101 - seriously, great job tracking this down.

[PaulBGD]

Go vote for this issue so that the developers can see that it's important: https://productpains.com/post/react-native/settimeout-fires-incorrectly-when-using-chrome-debug/

[satya164]

Does this still happen frequently? Haven't seen this for about a month now.

[marcshilling]

Lots of people saying this only happens while debugging with chrome...I don't think that's the case.

I have a production iOS app on the store and get crash reports for this pretty frequently. Latest one happened today @satya164. Unfortunately it's hard to tell exactly where it's occurring from the crash report. The app is a few versions of React Native behind.

[jacob-israel-turner]

Getting this while building to device and debugging in Chrome. I'm on React Native 0.13.0, so this may have been resolved in more recent versions.

[corbt]

@satya164 since you asked if this was still an issue, I've been running into it debugging on the device with Chrome on master. I think there's some timing issue going on more generally, as I've started running into other errors as well.

[mylonasg88]

Encountered same issue. Replaced TouchableHighlight with react-native-button and set my <Icon ...> in <Button ...> <Icon ... /> </Button> works like a charm.
I am not an expert, perhaps the answer to this can be found in react-native-button implementation.

I hope it helps to someone!

[grabbou]

Can't reproduce this on master currently.

[esutton]

Thank you @Thomas101 !

This bug stopped me from being able to debug into UIExplorer in react-native 0.26. Now I can continue using the debugger to learn how to modify and use NavigationExperimental. Without @Thomas101 work-around this would have taken me _so_ much longer.

[stantoncbradley]

my error is slightly different:
Attempted to transition from stateRESPONDER_INACTIVE_PRESS_INtoRESPONDER_ACTIVE_LONG_PRESS_IN, which is not supported. This is most likely due toTouchable.longPressDelayTimeoutnot being cancelled. @Thomas101 's solution did not work for me unfortunately. Anyone else experiencing anything similar?

[tslater]

@stantoncbradley, I have the same issue on react-native 0.27.0.
@Thomas101 , do you have any ideas on how we can workaround this one too?
I'm trying different combos to no avail.

[KGALLET]

got the same issue

[sscaff1]

Same issue here
RN 0.28
Running on iPhone 6S+

Only occurs about 20% of the time.

[aprct]

+1

Never realized how much tapping I did until it started crashing every 3 or 4 taps.

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.

RN 0.26
Running on iPhone 6 with iOS version 9.2.1

[aprct]

We're coming close to production and there doesn't seem to be a workaround for this when deploying to a device.

@Thomas101 @satya164 Any ideas? Solution doesn't seem to work for RESPONDER_INACTIVE_PRESS_IN to RESPONDER_ACTIVE_LONG_PRESS_IN error.

:/

[Thomas101]

@aprct we found it only happens when remote debugging is enabled. Doesn't seem to happen when run under production mode

[aprct]

@Thomas101 Sweet. Thanks for the quick reply. Fingers crossed!

[liamks]

I'm just confirming that this is still an issue.

[yonahforst]

@Thomas101 I get this when running on the device, without remote debugging enabled

[npomfret]

I'm getting it remote debugging on a physical iphone

[afilp]

Still an issue, I hope this can be solved. I get it on an Android physical device with debugging mode on (not sure if it happens on production mode).

[matt-oakes]

Just started getting this after upgrading to React Native 0.30 (never saw it before that). Happens on a physical Android phone (Nexus 5X) when running in chrome debug mode. As other have said, it doesn't happen on ever tap, even if pressing for a long time.

[yozi-developer]

@matto1990, usage the Network Time both on device and pc fixed this issue for me

[matt-oakes]

@yozi-developer Thanks! Unfortunately this doesn't fix the issue for me. I have network time enabled on both my computer and my Android phone. Because one is running Android and the other is running Mac OS, there's a possibility the network times supplied are actually not in sync enough.

[Surreal9]

I'm newer to react-native dev and am seeing this fairly often, with a TouchableHighlight inside of a Listview's renderRow function. I get the variant mentioned in https://github.com/facebook/react-native/issues/1693#issuecomment-227919962

It does seem to only occur when remote debugging with Chrome. I'm on an android device.

[neiker]

+1

On RN 0.31.0 with a TouchableHighlight

<TouchableHighlight onPress={onPress} underlayColor={'transparent'}>
      <View style={style}>
        {children}
      </View>
    </TouchableHighlight>

[AugustoL]

+1 still happening on RN 0.30

[alexHlebnikov]

+1 on RN 0.33.0.RC.0 while debugging on Nexus 4.

[neiker]

Change TouchableHighlight by TouchableOpacity works for me

[smallpath]

+1

On RN 0.32.0 with a TouchableNativeFeedback

Only happenned on remote debugging using Chrome

[ansmonjol]

+1
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.
On remote device android 5X running nougat

[esutton]

@yozi-developer Thanks!

I am using react native 0.32 and I thought I was going to have to abandon Chrome debugging because touch was not responding at all.

Syncing time on my MacBook host and Android target seemed to eliminate or reduce touch problems when debugging under Chrome.

I found an internal Intranet domain server I could use as a ntp server and pointed my MacBook to it. You can query on OS X or Linux using:
ntpdate -q mycompany.com.internal

Then I installed the Android ClockSync app and configured the app's settings:

1. NTP Server: mycompany.com.internal
2. Enabled Rootless Mode
3. I turned off Automatic data & time System setting under Android Date & Time System
4. I then used ClockSync to synchronize time
5. ClockSync takes you to the system's Android Date & Time System setting where a count down timer allows you to manually set time.

Before this I was manually prompted by react to manually set time using a adb shell command. This did not seem to work for me.

[stief510]

+1

[b1ngx]

0.32

[dantman]

I have a Modal > View > [MenuItem (custom)] > Ripple (react-native-material-design) > TouchableNativeFeedback with this issue.

I inserted some console logging into Touchable.js to examine the state changes:

  var TouchableMixin = {
+   componentWillMount: function() {
+     this.id = Math.random()
+   },
...
    _handleLongDelay: function(e) {
      this.longPressDelayTimeout = null;
      var curState = this.state.touchable.touchState;
+     console.log(this.id, '_handleLongDelay', curState);
      if (curState !== States.RESPONDER_ACTIVE_PRESS_IN &&
          curState !== States.RESPONDER_ACTIVE_LONG_PRESS_IN) {
        console.error('Attempted to transition from state `' + curState + '` to `' +
          States.RESPONDER_ACTIVE_LONG_PRESS_IN + '`, which is not supported. This is ' +
          'most likely due to `Touchable.longPressDelayTimeout` not being cancelled.');
      } else {
        this._receiveSignal(Signals.LONG_PRESS_DETECTED, e);
      }
    },
...
  _receiveSignal: function(signal, e) {
...
+     console.log('%s %s -> %s', this.id, curState, nextState)
      if (curState !== nextState) {

Here's a sample of those state changes for a good tap and two taps that generated the error:

[martinezguillaume]

Same on react-native v0.32.0

[forsen]

I had the same issue. As mentioned by @yozi-developer, you should avoid any clock drift between device and developer machine. For some reason, my iMac's clock is drifting slightly, which is not automatically corrected even though the clock should be synchronised according to System Preferences. A difference of 1 second between device and debug machine was enough to trigger this issue frequently. By eliminating that difference, the issue went away. v0.32.0

[gillestasse]

:+1:

[KevinHu2014]

Same on react-native v0.33.0

[JonesN3]

Can confirm clock drift is the issue. My android clock was 1 second a head, and after correcting that the issue goes away. I could not find a way to force clock sync (on an unrooted phone), so I had to manually set the time on my phone using a an app counting down until next minute on an NTP server.

[sduqlsc]

Same on react-native v0.35, debugging with android 6.0 device.

[koraniar]

+1

[gitikent]

Same on react-native v.0.37, debugging with android 6.0.1 device
when i use example from "Pushing scenes onto the stack" https://facebook.github.io/react-native/docs/using-navigators.html#pushing-scenes-onto-the-stack

[atdrago]

Still happening, but can only repro with TouchableHighlight. Could not repro with TouchableOpacity or TouchableWithoutFeedback.

[nikolal]

I am also getting this TouchableHighlight. I am not sure about TouchableOpacity.

[gustavjf]

This started happening for me on a physical iPhone 6 device via Xcode.

I was trying to reset my Push Notification permissions per these instructions: https://developer.apple.com/library/prerelease/content/technotes/tn2265/_index.html#//apple_ref/doc/uid/DTS40010376-CH1-TNTAG42

And I had forgotten to set my date & time back to "automatic". Resetting it stopped the errors.

I can now use remote JS debugging with React Native Debugger without this problem.

[jsdario]

It always happened to me with TouchableOpacity. Even wrapping the inner components in a view.

[braco]

Happens for me while long pressing a TouchableHighlight in iOS simulator / Chrome debugging

[fungilation]

Is this still a hard to reproduce bug after all this time?

My console.error output:

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:71
console.error @ YellowBox.js:61
_handleLongDelay @ Touchable.js:596
(anonymous) @ JSTimers.js:80
callTimer @ JSTimersExecution.js:95
callTimers @ JSTimersExecution.js:136
__callFunction @ MessageQueue.js:236
(anonymous) @ MessageQueue.js:108
guard @ MessageQueue.js:46
callFunctionReturnFlushedQueue @ MessageQueue.js:107
onmessage @ debuggerWorker.js:44

I'm on RN 0.37. I haven't hit this error in iOS simulator, but got this on physical iPhone 6S on iOS 10.2.1.

[grundmanise]

RN 0.39, iPhone 5s, iOS 10.2.

Happens when debugging in chrome (via React Native Debugger app) and pressing TouchableWithouthFeedback. Wrapping child in View solves this problem for me.

[esutton]

I had not seen this on an iOS device until now. I can no longer debug.

Fiddling with my MacBook and iPad clock times does not seem to be helping as it did with Android.

RN 0.38.1
iOS 10.2.1
OS X 10.11.6

[jocjeffrey]

Don't know if this helps anyone at all (we all seem to have slightly different issues with this), but my app was crashing whenever I used TouchableOpacity with any kind of styles. It turns out there was a 'width: 100%' in my styles. When I removed that, the app stopped crashing.

[waynebloss]

I get this same error with a brand new install of react-native when I create the sample AwesomeProject from the "Getting Started" tutorial and then add a button like this:

import React, { Component } from 'react';
import {
  AppRegistry,
  Button,
  StyleSheet,
  Text,
  View
} from 'react-native';

export default class Rnsome extends Component {
  buttonClicked() {
    console.log('buttonClicked');
  }
  render() {
    return (
      <View style={styles.container}>
        <Text style={styles.welcome}>
          HELLO! Testing 1, 2, 3.
        </Text>
        <Button title="Click" onPress={() => this.buttonClicked()}></Button>
      </View>
    );
  }
}

My package.json:

{
  "name": "Rnsome",
  "version": "0.0.1",
  "private": true,
  "scripts": {
    "start": "node node_modules/react-native/local-cli/cli.js start",
    "test": "jest"
  },
  "dependencies": {
    "react": "16.0.0-alpha.6",
    "react-native": "0.43.3"
  },
  "devDependencies": {
    "babel-jest": "19.0.0",
    "babel-preset-react-native": "1.9.1",
    "jest": "19.0.2",
    "react-test-renderer": "16.0.0-alpha.6"
  },
  "jest": {
    "preset": "react-native"
  }
}

[srikanthkyatham]

I got the same error with RN 0.40

[xixiflying]

+1
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.

[maxfysho]

+1 RN 0.44

[pietgk]

+1 RN 0.45.1

[finetimi]

This is still a problem. Consistently happens during Navigation hooks for TouchableNativeFeedback on android

[BerndWessels]

+1 RN 0.45.1

still happening with this code

    render() {
        let {onNavigateToOfferScreen, navigation} = this.props;
        let {dataSource} = this.state;
        return (
            <ListView style={styles.container} dataSource={dataSource} renderRow={offer => (
                <TouchableHighlight onPress={() => onNavigateToOfferScreen(offer)}>
                    <View style={styles.row} elevation={2}>
                        <Text style={styles.businessName}>{offer.name}</Text>
                    </View>
                </TouchableHighlight>
            )}/>
        );
    }

[dooubsam]

+1 RN 0.46.4

[trajakovic]

+1 RN 0.47.1

[tundak]

RN 0.48.3 still getting with List view

[inform880]

RN 0.49.1 still getting this. I think it has something to do with doing things to "fast". Only happens when debugging on device and debugging promise heavy screens. Also, I've only been getting this when clearing warnings.

Some more details: It seems like whenever I click on a button, and then click on it again before the app reacts to my click, it throws this error. I'm 99% sure this is not intended behavior.

[gino8080]

so what can be a fix or at least a workaround?

[gino8080]

Solved using React Native debugger instead of plain Chrome window

[ricardosasilva]

Still same error on RN 0.51.0. Debugging on Android device using React Native Debugger.

[nikolal]

I got this error when I upgraded to npm 5.x.x.

Once I reverted it to 4.6.1 and rebuilt the project the error disappeared.

[alexhuiculescu]

For me, this happens when items are inside a ListView
It happens if I scrol the Scrollview and longpress a view. If the Scrollview is not scrolled, the error does not appear

Android debugging, with react-native 0.50.0

[MedinaGitHub]

+1

[jamsch]

Getting pretty tired of this bug. It prevents you from debugging effectively when every second tap leads to a popup overlay error, especially when you double tap and mistakenly click on the restart button on the overlay.

Thought after over a year of using RN this would be fixed.

[forki]

is this still open? seems to happen a lot these days

[strindhaug]

I don't really understand why clock drift should cause this... In any sensible implementation, the machine that calculates the future timestamp to wait for should be the same machine that does the waiting.

The only way I could imagine that the clock difference should have any effect is if each time a setTimeout call is performed the device calculates the future timestamp based on its clock, and sends this timestamp to the debugger that does the waiting based on its clock. But surely that cannot be how it's implemented, is it? (That would require a whole lot of extra code to make it that way, for no good reason I can think of; except it enables this bug...)

If it's really designed that way; does anyone know why? And where the code that splits the call between device and debugger is located?

[dantman]

The only way I could imagine that the clock difference should have any effect is if each time a setTimeout call is performed the device calculates the future timestamp based on its clock, and sends this timestamp to the debugger that does the waiting based on its clock. But surely that cannot be how it's implemented, is it?

React Native doesn't have a debugger communication protocol. It only has a bridge to allow a JS context and the native app code to communicate.

React Native doesn't start up the js and native code on the device and then communicate with the debugger on your computer when you run with the debugger. To my understanding when you run RN in debugger mode it runs the native app code on the device and the debugger runs the JS code, then the JS<->native bridge just communicates over the network instead of locally. And you get the debugger free because the JS code is being executed in a browser with built in dev tools.

That would by why there are different clocks in debug mode, the native app code is running on the device with the device's clock and the JS code is running on your computer with your computer's clock.

[pacozaa]

+1

[franknotbad]

+1

[tmehta2442]

I'm not sure if this will help, but I had the same error message (red box of death) that would sometimes pop up on my emulator and always cause my physical device to show a blank page.

I wasn't getting the log information needed via my emulator, so I realized I could get more from plugging in my device and logging out everything that is going on via Android Studio's "Logcat". In there I found that there was an issue with the way I was using componentDidMount (specifically "E/ReactNativeJS: TypeError: undefined is not an object (evaluating 'a.componentDidMount.bind')" ).

While your error may be different, seeing a very verbose log from your device may prove to be beneficial in narrowing down the issue :)

[Salakar]

Hey, everyone, this looks like this a developer experience issue and is a bit of a low priority for us.

We are probably not going to tackle this soon, but; the ideal solution most likely would be that this should be a warning here instead of a thrown exception. We'd encourage sending a pull request for this issue.

[japser36]

I can confirm that this issue is still happening on RN 0.60.3 on Android, Samsung Galaxy S7

[anastely]

I can confirm that this issue is still happening on RN 0.60.3 on Android, Samsung Galaxy S7

+1, xiaomi redmi 5 plus 🤷‍♂️

[simonkincaidkintronix]

Hi All

I had the same annoying error during debugging on a v0.57 app but I managed to hack/fix it.

This error occurs in

node_modules/react-native/Libraries/Components/Touchable/touchable.js

For me, you get

console.error( 'Attempted to transition from state' +
curState +
'to' +
States.RESPONDER_ACTIVE_LONG_PRESS_IN +
', which is not supported. This is ' + 'most likely due toTouchable.longPressDelayTimeoutnot being cancelled.', );

on line 666 of all places!

This only gets called by touchableHandleResponderGrant()

So I just decided to remove/comment out the lines that called it:

this.longPressDelayTimeout = setTimeout( this._handleLongDelay.bind(this, e), longDelayMS + delayMS, );

Yes, this is a hack but I wanted to debug properly so I needed that error to go away.

If your app requires long presses I assume something will break, but then I think the new pressables in RN will supercede this anyway.

Hope this helps some people! o/