Conversation
|
Looks like there still are some things left to iron out screen-20231031-095931.2.movscreen-20231031-100142.2.movscreen-20231031-100455.2.movAll captured on Android 13, Chrome 118.0.5993.111 |
|
@j-piasecki I agree that there are some problems that should be fixed. However, I've checked the one with |
Works fine for me on the current screen-20231107-091954.2.mov |
|
@m-bert What's blocking this pull request from getting a review? |
|
iOS doesn't seem to work at all yet - all handlers are running simultaneously with scrolling the page and navigation gestures |
|
Hi @GuestInCorle! Problems that @j-piasecki described seem to affect both platforms, Android and iOS. I'm not sure about the navigation part and I have yet to check that. However, most of the issues seem to originate from default |
## Description This PR adds new prop to gesture handlers - `touchAction`. While working on [fix scroll interactions PR](#2631) we've found it difficult to remove `touch-action: none;` and ensure correct behavior of handlers with scroll, especially with swipeable components. What made it even harder were differences between platforms. We decided to kill two birds with one stone - give our users possibility to manipulate `touchAction`, which will also make it easier for us to properly handle scroll. ## Test plan Tested on example app.
Description
During development of web version we initially decided to set
touchAction: noneto all gesture handlers' views in order to avoid scrolling while gestures like pan are active. Now it turns out that because of this decision, components likeFlatListorScrollViewmay become useless when combined with some handlers (or, like in the issue mentioned below -Swipeablecomponents).This PR aims to fix that problem by replacing
touchAction: nonewithe.preventDefault().Fixes #2617
Test plan
Tested on:
ScrollViewandLoremIpsum)Modified code from issue