onPress is not called after using useNativeDriver transform button #36504

ThinkerLu · 2023-03-16T17:36:32Z

Description

After using useNativeDriver transform button, finger movement occurs when the button is pressed, the button's onPress will not be called, but the visual feedback of the button is normal.
The bug only occurs on Android devices, and when the new architecture is enabled, useNativeDriver=true is set.

React Native Version

0.71.4

Output of `npx react-native info`

System:
OS: macOS 13.1
CPU: (10) arm64 Apple M1 Pro
Memory: 148.16 MB / 16.00 GB
Shell: 5.8.1 - /bin/zsh
Binaries:
Node: 19.7.0 - /opt/homebrew/bin/node
Yarn: 1.22.19 - /opt/homebrew/bin/yarn
npm: 9.5.0 - /opt/homebrew/bin/npm
Watchman: 2023.03.06.00 - /opt/homebrew/bin/watchman
Managers:
CocoaPods: Not Found
SDKs:
iOS SDK:
Platforms: DriverKit 22.2, iOS 16.2, macOS 13.1, tvOS 16.1, watchOS 9.1
Android SDK:
API Levels: 28, 29, 30, 31, 32, 33
Build Tools: 28.0.3, 30.0.2, 30.0.3, 31.0.0, 33.0.0
System Images: android-31 | Google APIs ARM 64 v8a, android-33 | Google APIs ARM 64 v8a
Android NDK: Not Found
IDEs:
Android Studio: Electric Eel 2022.1.1 Patch 2 Electric Eel 2022.1.1 Patch 2
Xcode: 14.2/14C18 - /usr/bin/xcodebuild
Languages:
Java: 11.0.15 - /opt/homebrew/opt/openjdk@11/bin/javac
npmPackages:
@react-native-community/cli: Not Found
react: 18.2.0 => 18.2.0
react-native: 0.71.4 => 0.71.4
react-native-macos: Not Found
npmGlobalPackages:
react-native: Not Found

Steps to reproduce

Run my code, Press the button after scrolling the FlatList, move your finger slightly and lift it up.

Snack, code example, screenshot, or link to a repository

import React, {useRef, useState} from 'react';
import {View, Text, Button, Animated} from 'react-native';

const componentList: number[] = Array.from(new Array(100).keys());

const App = () => {
const currScroll = useRef(new Animated.Value(0)).current;
const [count, setCount] = useState(0);

return (
<View style={{flex: 1}}>
<Animated.View
style={{
position: 'absolute',
zIndex: 2,
width: '100%',
transform: [{translateY: currScroll}],
}}>
<Button
title={Press count : ${count}}
onPress={() => {
console.log('pressed');
setCount(count + 1);
}}>
</Animated.View>
<Animated.FlatList
style={{width: '100%', height: '100%', position: 'absolute', zIndex: 1}}
data={componentList}
renderItem={({index}) => (
<Text
style={{
backgroundColor: 'white',
height: 28,
}}>
{index}

)}
keyExtractor={item => item.toString()}
onScroll={Animated.event(
[
{
nativeEvent: {
contentOffset: {
y: currScroll,
},
},
},
],
{useNativeDriver: true},
)}></Animated.FlatList>

);
};

export default App;

The text was updated successfully, but these errors were encountered:

iMonk777 · 2023-05-05T07:09:57Z

Hi @ThinkerLu , we still have this issue. Did you find any solution for this?

jugshaurya · 2023-05-29T11:25:34Z

+1, after applying transform: translateX/Y/Z(*), on Animated.View, internal content of this View become non-responsive, works after multiple clicking.

It comes after using New Arch.Even used latest 0.72.0-RC.3

Tested Today: 29/05/23

skinsapp · 2023-06-11T12:04:28Z

@jugshaurya I can confirm I'm having the same issue, using 71.10, android. It basically makes the new architecture unusable on Android, unless you plan to have no animation. It's occurring with all touchables and pressables.

related: #36710

jugshaurya · 2023-06-11T13:20:54Z

@jugshaurya I can confirm I'm having the same issue, using 71.10, android. It basically makes the new architecture unusable on Android, unless you plan to have no animation. It's occurring with all touchables and pressables.

related: #36710

I found a temp/possible solution for it, after researching for more than 2 weeks.

Use onPressIn instead of onPress !

Let me know if it also works for you. Also to increase tappable area to make button more responsive, you can use hitslop prop.

vrgimael · 2023-06-28T13:22:41Z

@jugshaurya I can confirm I'm having the same issue, using 71.10, android. It basically makes the new architecture unusable on Android, unless you plan to have no animation. It's occurring with all touchables and pressables.
related: #36710

I found a temp/possible solution for it, after researching for more than 2 weeks.

Use onPressIn instead of onPress !

Let me know if it also works for you. Also to increase tappable area to make button more responsive, you can use hitslop prop.

This is not a solution as it triggers accidentally on any scrollable item

jugshaurya · 2023-06-28T13:33:35Z

@jugshaurya I can confirm I'm having the same issue, using 71.10, android. It basically makes the new architecture unusable on Android, unless you plan to have no animation. It's occurring with all touchables and pressables.
related: #36710

I found a temp/possible solution for it, after researching for more than 2 weeks.

Use onPressIn instead of onPress !

Let me know if it also works for you. Also to increase tappable area to make button more responsive, you can use hitslop prop.

This is not a solution as it triggers accidentally on any scrollable item

Can you share an example gif or something to get the better context, because i used this solution for codebase, it is working fine.

github-actions · 2023-12-26T05:13:29Z

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

github-actions · 2024-01-02T05:23:59Z

This issue was closed because it has been stalled for 7 days with no activity.

cipolleschi · 2024-01-24T12:19:59Z

Hi everyone, we have this investigation marked as high priority, so we hopefully would be able to make progress on this as fast as we can.

To help us out, we would greatly appreciate a reproducer starting from this repo. I understand that the issue does not reproduce consistently, but if you can set up something and tell us how and how much we need to interact with the repro to get the issue happening, this will help us a lot.

Thank you all for the cooperation! 🙏

sonicbaume · 2024-04-17T11:38:47Z

@cipolleschi Here's the example from @ThinkerLu as a reproducer repo, and a video of the result.

Reproducer: https://github.com/sonicbaume/fabric-onpress-bug-reproducer

Video:

onpress-example.mp4

sonicbaume · 2024-04-26T11:10:48Z

@cipolleschi Is this still considered high priority? Is there anything else you need?

cortinico · 2024-04-26T16:59:52Z

@cipolleschi Is this still considered high priority? Is there anything else you need?

Yes it is. If someone is willing to attempt to fix it and send a PR, it would be greatly appreaciated. Otherwise we'll eventually fix it in the (hopefully soon) future

cipolleschi · 2024-05-01T13:21:48Z

Thanks for your patience, competing priorities took most of my time. :(

As @cortinico said, we want to fix this issue, together with some other that are affecting the New Architecture. Bear with us, we will get there.

cipolleschi · 2024-05-31T14:50:04Z

Hi @sonicbaume @ThinkerLu @iMonk777 @jugshaurya @vrgimael, sorry that this took us so long.

I was trying the reproducer and it feels like it is fixed on 0.74.1 with regular touches.

There is still something weird related to when you tap-drag-release within the button. It looks that onPress is not invoked in that case. It works if you click-drat to the top-release: it looks like that when we 'release' the touch, we are not considering the translated position.

nativeDriver.mov

Let's note that this behavior happens also on iOS:

Screen.Recording.2024-05-31.at.15.52.51.mov

Summary: ## Changes Add an example in RNTester to test that pressability with NativeDrivers works properly. ## Context The pressability handling is a bit peculiar. We have to handle 3 main behaviors: * `PressIn` -> `PressOut` => triggers the `onPress` * `PressIn` -> move inside the rectangle -> `PressOut` => triggers the `onPress` * `PressIn` -> move outside the rectangle -> `PressOut` => cancel `onPress`. For the first case, we detect whether the press happens inside a component in the Native layer only. And everything works. When a move is involved, we: 1. Detect the initial press in the Native layer 2. We move the coursor and we delegate the detection of whether we are inside of a rect or not to the JS layer 3. The JS layer asks the C++ layer about the layout and decide whether we are in case 2 (move but still inside the rect) or in case 3 (move but outside the rect). The problem is that with `nativeDriver` and animations, the C++ layer doesn't know about where the receiver view actually is. This results in issues like the one shown by [facebook#36504](facebook#36504), where the onMove is not handled correctly. ## Solution The solution is to keep detecting whether we are in the receiver view or not in the Native layer and pass the receiver view position and size back to JS so that the JS layer don't have to jump to C++ to make this decision. We decided to pass the frame information because the JS layer is adding some padding and configurations to the final rectangle and we don't want to lose those configurations. ## Changelog [General][Added] - Add example in RNTester to show that pressability works properly with NativeDrivers Differential Revision: D58182480

…#45413) Summary: Pull Request resolved: facebook#45413 ## Changes Add an example in RNTester to test that pressability with NativeDrivers works properly. ## Context The pressability handling is a bit peculiar. We have to handle 3 main behaviors: * `PressIn` -> `PressOut` => triggers the `onPress` * `PressIn` -> move inside the rectangle -> `PressOut` => triggers the `onPress` * `PressIn` -> move outside the rectangle -> `PressOut` => cancel `onPress`. For the first case, we detect whether the press happens inside a component in the Native layer only. And everything works. When a move is involved, we: 1. Detect the initial press in the Native layer 2. We move the coursor and we delegate the detection of whether we are inside of a rect or not to the JS layer 3. The JS layer asks the C++ layer about the layout and decide whether we are in case 2 (move but still inside the rect) or in case 3 (move but outside the rect). The problem is that with `nativeDriver` and animations, the C++ layer doesn't know about where the receiver view actually is. This results in issues like the one shown by [facebook#36504](facebook#36504), where the onMove is not handled correctly. ## Solution The solution is to keep detecting whether we are in the receiver view or not in the Native layer and pass the receiver view position and size back to JS so that the JS layer don't have to jump to C++ to make this decision. We decided to pass the frame information because the JS layer is adding some padding and configurations to the final rectangle and we don't want to lose those configurations. ## Changelog [General][Added] - Add example in RNTester to show that pressability works properly with NativeDrivers Reviewed By: sammy-SC Differential Revision: D58182480

…#45413) Summary: Pull Request resolved: facebook#45413 ## Changes Add an example in RNTester to test that pressability with NativeDrivers works properly. ## Context The pressability handling is a bit peculiar. We have to handle 3 main behaviors: * `PressIn` -> `PressOut` => triggers the `onPress` * `PressIn` -> move inside the rectangle -> `PressOut` => triggers the `onPress` * `PressIn` -> move outside the rectangle -> `PressOut` => cancel `onPress`. For the first case, we detect whether the press happens inside a component in the Native layer only. And everything works. When a move is involved, we: 1. Detect the initial press in the Native layer 2. We move the coursor and we delegate the detection of whether we are inside of a rect or not to the JS layer 3. The JS layer asks the C++ layer about the layout and decide whether we are in case 2 (move but still inside the rect) or in case 3 (move but outside the rect). The problem is that with `nativeDriver` and animations, the C++ layer doesn't know about where the receiver view actually is. This results in issues like the one shown by [facebook#36504](facebook#36504), where the onMove is not handled correctly. ## Solution The solution is to keep detecting whether we are in the receiver view or not in the Native layer and pass the receiver view position and size back to JS so that the JS layer don't have to jump to C++ to make this decision. We decided to pass the frame information because the JS layer is adding some padding and configurations to the final rectangle and we don't want to lose those configurations. ## Changelog [General][Added] - Add example in RNTester to show that pressability works properly with NativeDrivers Differential Revision: D58182480 Reviewed By: sammy-SC

…#45413) Summary: Pull Request resolved: facebook#45413 ## Changes Add an example in RNTester to test that pressability with NativeDrivers works properly. ## Context The pressability handling is a bit peculiar. We have to handle 3 main behaviors: * `PressIn` -> `PressOut` => triggers the `onPress` * `PressIn` -> move inside the rectangle -> `PressOut` => triggers the `onPress` * `PressIn` -> move outside the rectangle -> `PressOut` => cancel `onPress`. For the first case, we detect whether the press happens inside a component in the Native layer only. And everything works. When a move is involved, we: 1. Detect the initial press in the Native layer 2. We move the coursor and we delegate the detection of whether we are inside of a rect or not to the JS layer 3. The JS layer asks the C++ layer about the layout and decide whether we are in case 2 (move but still inside the rect) or in case 3 (move but outside the rect). The problem is that with `nativeDriver` and animations, the C++ layer doesn't know about where the receiver view actually is. This results in issues like the one shown by [facebook#36504](facebook#36504), where the onMove is not handled correctly. ## Solution The solution is to keep detecting whether we are in the receiver view or not in the Native layer and pass the receiver view position and size back to JS so that the JS layer don't have to jump to C++ to make this decision. We decided to pass the frame information because the JS layer is adding some padding and configurations to the final rectangle and we don't want to lose those configurations. ## Changelog [General][Added] - Add example in RNTester to show that pressability works properly with NativeDrivers Reviewed By: sammy-SC Differential Revision: D58182480

…#45413) Summary: Pull Request resolved: facebook#45413 ## Changes Add an example in RNTester to test that pressability with NativeDrivers works properly. ## Context The pressability handling is a bit peculiar. We have to handle 3 main behaviors: * `PressIn` -> `PressOut` => triggers the `onPress` * `PressIn` -> move inside the rectangle -> `PressOut` => triggers the `onPress` * `PressIn` -> move outside the rectangle -> `PressOut` => cancel `onPress`. For the first case, we detect whether the press happens inside a component in the Native layer only. And everything works. When a move is involved, we: 1. Detect the initial press in the Native layer 2. We move the coursor and we delegate the detection of whether we are inside of a rect or not to the JS layer 3. The JS layer asks the C++ layer about the layout and decide whether we are in case 2 (move but still inside the rect) or in case 3 (move but outside the rect). The problem is that with `nativeDriver` and animations, the C++ layer doesn't know about where the receiver view actually is. This results in issues like the one shown by [facebook#36504](facebook#36504), where the onMove is not handled correctly. ## Solution The solution is to keep detecting whether we are in the receiver view or not in the Native layer and pass the receiver view position and size back to JS so that the JS layer don't have to jump to C++ to make this decision. We decided to pass the frame information because the JS layer is adding some padding and configurations to the final rectangle and we don't want to lose those configurations. ## Changelog [General][Added] - Add example in RNTester to show that pressability works properly with NativeDrivers Differential Revision: D58182480 Reviewed By: sammy-SC

Summary: Pull Request resolved: #45413 ## Changes Add an example in RNTester to test that pressability with NativeDrivers works properly. ## Context The pressability handling is a bit peculiar. We have to handle 3 main behaviors: * `PressIn` -> `PressOut` => triggers the `onPress` * `PressIn` -> move inside the rectangle -> `PressOut` => triggers the `onPress` * `PressIn` -> move outside the rectangle -> `PressOut` => cancel `onPress`. For the first case, we detect whether the press happens inside a component in the Native layer only. And everything works. When a move is involved, we: 1. Detect the initial press in the Native layer 2. We move the coursor and we delegate the detection of whether we are inside of a rect or not to the JS layer 3. The JS layer asks the C++ layer about the layout and decide whether we are in case 2 (move but still inside the rect) or in case 3 (move but outside the rect). The problem is that with `nativeDriver` and animations, the C++ layer doesn't know about where the receiver view actually is. This results in issues like the one shown by [#36504](#36504), where the onMove is not handled correctly. ## Solution The solution is to keep detecting whether we are in the receiver view or not in the Native layer and pass the receiver view position and size back to JS so that the JS layer don't have to jump to C++ to make this decision. We decided to pass the frame information because the JS layer is adding some padding and configurations to the final rectangle and we don't want to lose those configurations. ## Changelog [General][Added] - Add example in RNTester to show that pressability works properly with NativeDrivers Reviewed By: sammy-SC Differential Revision: D58182480 fbshipit-source-id: 9ca4fb9a3ca1a8af52ccbe208cbfe8434175f87d

cipolleschi · 2024-09-23T13:55:20Z

This will be fixes in 0.76.

61xin · 2024-10-28T02:12:32Z

This will be fixes in 0.76.

Hi @cipolleschi, what is the commit id that fixed this bug? Will the fixes be synced to previous versions, such as 0.75?

cipolleschi · 2024-10-28T12:19:46Z

@61xin there are multiple commits required to fix this issue. It will be quite hard to backport the fix to previous versions, plus the New Architecture is considered stable and ready for production in 0.76.
So I strongly suggest to update to 0.76 if you want to migrate to the New Architecture, also because that version will contains many more fixes for the New Arch.

61xin · 2024-10-29T01:32:25Z

@61xin there are multiple commits required to fix this issue. It will be quite hard to backport the fix to previous versions, plus the New Architecture is considered stable and ready for production in 0.76. So I strongly suggest to update to 0.76 if you want to migrate to the New Architecture, also because that version will contains many more fixes for the New Arch.

ok，thank you!

fdecampredon · 2024-10-29T21:53:35Z

@61xin After upgrading to 0.76.1 I can say that the issue is still present

cipolleschi · 2024-10-31T15:21:52Z

@fdecampredon can you share a reproducer? We have a screen in RNTester to test this case and I'm sure it was fixed. Maybe we missed some edge case.

fdecampredon · 2024-11-22T08:58:11Z

@cipolleschi I'm really sorry after more investigation I think it is more related to this one : #44768.
We'll try to make a minimal reproduction example but it's a bit hard since the problem is deeply nested in a very complex screen.

ZhangBinglei2015 · 2024-12-12T08:06:03Z

I am using react native 0.72 and this solve my problem，you can try it!

import type {ViewProps} from 'react-native'
import {PanResponder, View} from 'react-native'

export type TouchComponentProps = {
  onPress: () => void
}

export default (props: ViewProps & TouchComponentProps) => {
  const panresponder = PanResponder.create({
    onStartShouldSetPanResponder: () => true,
    onShouldBlockNativeResponder: () => false,
    onPanResponderRelease: () => {
      props.onPress()
    },
  })

  return (
    <View {...props} {...panresponder.panHandlers}>
      {props.children}
    </View>
  )
}

ThinkerLu added Needs: Triage 🔍 Type: New Architecture Issues and PRs related to new architecture (Fabric/Turbo Modules) labels Mar 16, 2023

react-native-bot added the Component: Button label Mar 16, 2023

cjshearer mentioned this issue Jun 1, 2023

React-navigation Drawer Buttons Not Working With New Architecture Enabled on Android react-navigation/react-navigation#11021

Open

12 tasks

skinsapp mentioned this issue Jun 11, 2023

Touchable components stop responding randomly #36710

Closed

Flewp mentioned this issue Oct 10, 2023

NativeMeasurer for Android discord/react-native#44

Merged

github-actions bot added the Stale There has been a lack of activity on this issue and it may be closed soon. label Dec 26, 2023

github-actions bot closed this as completed Jan 2, 2024

sammy-SC reopened this Jan 6, 2024

github-actions bot removed the Stale There has been a lack of activity on this issue and it may be closed soon. label Jan 7, 2024

j-piasecki mentioned this issue May 7, 2024

Trigger render when Animated.Event stream pauses #44447

Draft

cortinico mentioned this issue Jun 4, 2024

On Android horizontal Animated.ScrollView, animated children with a transform: translate are not pressable correctly #44768

Open

cipolleschi mentioned this issue Jul 12, 2024

Add example for Pressability with Native Driver in RNTester #45413

Closed

CyberAndrii mentioned this issue Aug 13, 2024

[$500] Android- Workspace- Unable to open workspaces that out of view after creating new workspace Expensify/App#45738

Closed

6 tasks

cipolleschi closed this as completed Sep 23, 2024

cortinico added Resolution: Fixed A PR that fixes this issue has been merged. and removed Needs: Triage 🔍 labels Sep 23, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

onPress is not called after using useNativeDriver transform button #36504

onPress is not called after using useNativeDriver transform button #36504

ThinkerLu commented Mar 16, 2023 •

edited

Loading

iMonk777 commented May 5, 2023

jugshaurya commented May 29, 2023 •

edited

Loading

skinsapp commented Jun 11, 2023 •

edited

Loading

jugshaurya commented Jun 11, 2023 •

edited

Loading

vrgimael commented Jun 28, 2023

jugshaurya commented Jun 28, 2023

github-actions bot commented Dec 26, 2023

github-actions bot commented Jan 2, 2024

cipolleschi commented Jan 24, 2024

sonicbaume commented Apr 17, 2024

sonicbaume commented Apr 26, 2024

cortinico commented Apr 26, 2024

cipolleschi commented May 1, 2024

cipolleschi commented May 31, 2024 •

edited

Loading

cipolleschi commented Sep 23, 2024

61xin commented Oct 28, 2024 •

edited

Loading

cipolleschi commented Oct 28, 2024

61xin commented Oct 29, 2024

fdecampredon commented Oct 29, 2024

cipolleschi commented Oct 31, 2024

fdecampredon commented Nov 22, 2024

ZhangBinglei2015 commented Dec 12, 2024

onPress is not called after using useNativeDriver transform button #36504

onPress is not called after using useNativeDriver transform button #36504

Comments

ThinkerLu commented Mar 16, 2023 • edited Loading

Description

React Native Version

Output of npx react-native info

Steps to reproduce

Snack, code example, screenshot, or link to a repository

iMonk777 commented May 5, 2023

jugshaurya commented May 29, 2023 • edited Loading

skinsapp commented Jun 11, 2023 • edited Loading

jugshaurya commented Jun 11, 2023 • edited Loading

vrgimael commented Jun 28, 2023

jugshaurya commented Jun 28, 2023

github-actions bot commented Dec 26, 2023

github-actions bot commented Jan 2, 2024

cipolleschi commented Jan 24, 2024

sonicbaume commented Apr 17, 2024

sonicbaume commented Apr 26, 2024

cortinico commented Apr 26, 2024

cipolleschi commented May 1, 2024

cipolleschi commented May 31, 2024 • edited Loading

cipolleschi commented Sep 23, 2024

61xin commented Oct 28, 2024 • edited Loading

cipolleschi commented Oct 28, 2024

61xin commented Oct 29, 2024

fdecampredon commented Oct 29, 2024

cipolleschi commented Oct 31, 2024

fdecampredon commented Nov 22, 2024

ZhangBinglei2015 commented Dec 12, 2024

ThinkerLu commented Mar 16, 2023 •

edited

Loading

Output of `npx react-native info`

jugshaurya commented May 29, 2023 •

edited

Loading

skinsapp commented Jun 11, 2023 •

edited

Loading

jugshaurya commented Jun 11, 2023 •

edited

Loading

cipolleschi commented May 31, 2024 •

edited

Loading

61xin commented Oct 28, 2024 •

edited

Loading