React-native: [Android] onResponderMove nativeEvent locationX does not change

Created on 26 Apr 2016 · 28Comments · Source: facebook/react-native

Hey guys,

Running into a bug (on Android only) where locationX of onResponderMove never changes as you drag along the view.

var MyComponent = React.createClass({
  onStartShouldSetResponder: function(e) {
    return true;
  },

  onMoveShouldSetResponder: function(e) {
    return true;
  },

  onResponderMove: function(e) {
    var evt = e.nativeEvent;
    console.log(evt.locationX);
  },

  render: function() {
    return (
      <View
        style={styles.box}
        onStartShouldSetResponder={this.onStartShouldSetResponder}
        onMoveShouldSetResponder={this.onMoveShouldSetResponder}
        onResponderMove={this.onResponderMove}>
      </View>
    );
  }
});

var styles = StyleSheet.create({
  box: {
    flexDirection: 'row',
    alignSelf: 'center',
    width: 200,
    height: 50,
    backgroundColor: 'red'
  }
});

React Native 0.22.0
OSX

Ran Commands Stale

Source

erickreutz

👍5

Most helpful comment

Still seeing in 0.35.0

leecade on 13 Oct 2016

👍3

All 28 comments

@facebook-github-bot bugfix

christopherdro on 27 Apr 2016

Confirming this is a bug. Took time last night to dig in and narrowed the problem down to these 2 lines.
For some reasons the subtraction of the 2 floats only happens on first touch and not during the entire interaction. What's strange is console logging those two values separately shows that both update throughout the entire touch interaction.

Will look into it a bit more.

/cc @dmmiller Thoughts?

Example https://rnplay.org/apps/i0rjeQ

christopherdro on 27 Apr 2016

Hey @erickreutz, we're a small team and rely on the community to fix issues that don't affect fb apps. If you're sure this is a bug can you send a pull request with a fix?

ghost on 27 Apr 2016

This is a bug. I have an internal bug to fix it but haven't gotten to it yet. If you'd like to send a pull request to fix it, I'm happy to check it out.

dmmiller on 27 Apr 2016

@dmmiller Whats the issue?

christopherdro on 27 Apr 2016

We just haven't fixed it. I just mean to let you know that I know about it.

dmmiller on 27 Apr 2016

Ah I see, I thought you might of known what was causing that bug.

christopherdro on 27 Apr 2016

Honestly, I haven't looked into it yet. Too many other things to look at. If you want to dive in and see, that would be great :)

dmmiller on 27 Apr 2016

What's happening is the the two values you are trying to subtract to get locationX and locationY both increment/decrement in parallel so the subtracted value is always going to be the same.

christopherdro on 27 Apr 2016

Not sure if I'll have the time to send a PR for this one. As a work around I've just been calculating my own locationX with pageX minus the x origin of the target view.

erickreutz on 29 Apr 2016

Was this ever able to be fixed? My hack is broken now onLayout has the x origin of the view as 0 in the 0.28

erickreutz on 16 Jul 2016

So sad. We encountered the same issue in 0.29 version.

YongX on 21 Jul 2016

Still seeing in 0.30.0.

eremzeit on 1 Sep 2016

@erickreutz

onLayout is returning the page offset correctly for me as of 0.30.0 so I'm able to use your hack to work.

eremzeit on 1 Sep 2016

confirm this is still happening in 0.32.1

following code is sufficient to reproduce it:

      <View
        onTouchMove={(e) => {console.log('touchMove', e.nativeEvent)}}
        style={{flex: 1}}
       />

chunghe on 9 Sep 2016

Can confirm, happening on 0.33.0.

robclouth on 16 Sep 2016

Still seeing in 0.35.0

leecade on 13 Oct 2016

👍3

the trouble is that in
float targetViewCoordinateX = motionEvent.getX() - event.getViewX();

the motionEvent.getX() changes (when dragging) while event.getViewX() stays the same and denotes when the touch started. These coordinates are assigned once and continue to be passed here.

vonovak on 12 Dec 2016

Still seeing this on 0.40

robclouth on 13 Jan 2017

Still exists on 0.41.2.
any plan to fix it ?

richmonkey on 24 Feb 2017

Still seeing this in 0.43.4

JonesN3 on 25 Apr 2017

😕3

Still seeing in 0.45.0

umitalp on 18 Jul 2017

😕2

@janicduplessis or @kmagiera?

sahrens on 19 Jul 2017

👍1

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 on 21 Sep 2017

Unfortunately this still happens on react-native 0.47.2. The workaround was a pain to create, so anyone solving this issue would be amazing.

WeeJeWel on 21 Sep 2017

Let's reopen this one

janicduplessis on 21 Sep 2017

Actually I think https://github.com/facebook/react-native/commit/1a262a7c7ddab1ec67112731e6bebef3f185f91c should fix it, can someone test it with 0.49-rc

janicduplessis on 21 Sep 2017

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. If you think this issue should definitely remain open, please let us know why. Thank you for your contributions.