Cancel failed buttons in reset #3350
Conversation
|
Hey, thank you for the PR! Could you please provide a repro where #2160 still occurs? I tried reproducing this issue with |
|
Hi I made a minimal reproduction here: https://snack.expo.dev/@oblador/gesture-handler-list-reproduction Note that this is Android only, see a video of the reproduction where you can notice that before I scroll the first list item responds with a highlight, but afterwards none do: screen-20250122-131111.mp4 |
|
For what it's worth, I've managed to get into this state even without |
|
I also rendomly experience when in a ScrollView there are two buttons and the second one ( (it's FAB) overlaps the first one. Sometimes pressing a FAB buttons also triggers the underlying button (the ripple animation starts). FAB triggers navigation. Then the app becomes unresponsive to This PR might help with that too. |
There was a problem hiding this comment.
Hey, I tested your solution on your repro, and I still managed to get the RectButtons stuck in the active state.
It looks like this issue is caused by NativeViewGestureHandler either never leaving the ACTIVE state, or being removed from gestureHandlers array before being reset or finished.
When i managed to get RectButton stuck, onCancel, onFail and onReset were never called, suggesting NativeViewGestureHandler was never finished in the first place (onFail doesn't exist on main, added it for debugging).
I've also tried different approaches, but haven't solved this issue yet.
I'll dig into this deeper, and keep you updated when I find any solution.
|
@RohovDmytro I think your issue is a different one from this, but I came across it today as well, and created a separate issue for it here: #3370 This PR doesn't solve that bug however. |
|
@latekvo Any progress on your end? |
|
@oblador Apologies for the delayed response — I missed your earlier message. |
## Description Addresses the issue reported in #3350. Conceptually, it's very similar to the above PR. The main difference is the timing - the above PR cancelled the button during `onReset`, while this one adds `onFail` method (analogous to `onCancel`). This method is called just before the state change, while the timing of `onReset` is dependent on the incoming touch stream and handling of other gestures. With this change, I wasn't able to reproduce the issue anymore, though @latekvo mentioned that he was able to get into a situation where none of `onCancel`, `onFail`, and `onReset` were called. This would likely manifest in the same way, but it looks like an entirely different problem. Here, the gesture was canceled, while the underlying button was still kept as a touch responder, while in the above situation, the gesture would have never finished (or never activated). ## Test plan Tested on the linked reproducer and on the Example app
|
Hey! I merged #3509, which addresses the same issue slightly differently. I'd love it if you could check if it solves the problem in your case. |
Description
This PR is an attempt at fixing bug reported in #2160.
Essentially when having a button with
shouldCancelWhenOutside={true}in aScrollViewand scrolling quickly, especially when at the bottom where the scrollview exhibit rubber band effect, all buttons becomes unresponsive. This is becausetouchResponderis never freed after it goes intoFAILEDstate, which typically otherwise happens whenACTION_UPis emitted – something that never happens.I'm not sure of the ideal solution, but I'd figured I share my half-baked workaround to emit
CANCELinonResetif the button is stuck inFAILED. Curious to hear suggestions on how to improve this.Test plan