facebook / react-native

A framework for building native applications using React
https://reactnative.dev
MIT License
119.3k stars 24.35k forks source link

[Touchable* + Text] "Touchable cannot transition" error about 20% of the time #1693

Closed uoroaix closed 1 month ago

uoroaix commented 9 years ago

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.

matt-oakes commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

+1

On RN 0.31.0 with a TouchableHighlight

<TouchableHighlight onPress={onPress} underlayColor={'transparent'}>
      <View style={style}>
        {children}
      </View>
    </TouchableHighlight>
AugustoL commented 8 years ago

+1 still happening on RN 0.30

alexHlebnikov commented 8 years ago

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

neiker commented 8 years ago

Change TouchableHighlight by TouchableOpacity works for me

smallpath commented 8 years ago

+1

On RN 0.32.0 with a TouchableNativeFeedback

Only happenned on remote debugging using Chrome

ansmonjol commented 8 years ago

+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 commented 8 years ago

@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 commented 8 years ago

+1

b1ngx commented 8 years ago

0.32

dantman commented 8 years ago

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: screen shot 2016-09-04 at 5 51 09 pm

martinezguillaume commented 8 years ago

Same on react-native v0.32.0

forsen commented 8 years ago

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 commented 8 years ago

:+1:

KevinHu2014 commented 8 years ago

Same on react-native v0.33.0

JonesN3 commented 8 years ago

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 commented 8 years ago

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

koraniar commented 8 years ago

+1

gitikent commented 8 years ago

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 commented 8 years ago

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

nikolal commented 7 years ago

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

gustavjf commented 7 years ago

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 commented 7 years ago

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

braco commented 7 years ago

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

fungilation commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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.

ghost commented 7 years ago

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 commented 7 years ago

I got the same error with RN 0.40

xixiflying commented 7 years ago

+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 commented 7 years ago

+1 RN 0.44

pietgk commented 7 years ago

+1 RN 0.45.1

finetimi commented 7 years ago

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

BerndWessels commented 7 years ago

+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>
            )}/>
        );
    }
ghost commented 7 years ago

+1 RN 0.46.4

trajakovic commented 7 years ago

+1 RN 0.47.1

tundak commented 7 years ago

RN 0.48.3 still getting with List view

inform880 commented 7 years ago

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 commented 7 years ago

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

gino8080 commented 7 years ago

Solved using React Native debugger instead of plain Chrome window

ricardosasilva commented 6 years ago

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

nikolal commented 6 years ago

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.

AlexHuicu commented 6 years ago

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 commented 6 years ago

+1

jamsch commented 6 years ago

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 commented 6 years ago

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

strindhaug commented 6 years ago

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 commented 6 years ago

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.