Allow GestureHandlerRootView to be manually made active#2401
Allow GestureHandlerRootView to be manually made active#2401j-piasecki merged 3 commits intomainfrom
GestureHandlerRootView to be manually made active#2401Conversation
|
Can we expect this to be merged? It's approved after all |
|
Actually, I'm not sure if this is the best solution to this problem. I'll try to get back to it in the near future to see if I can find other approaches to this. |
|
@j-piasecki thank you for the quick response |
|
Hi still has same problem in 2024, any suggestions? thanks |
|
@j-piasecki Issue is still reproducible in Nested Tabs with "@react-navigation/material-top-tabs": "7.3.7" |
j-piasecki
force-pushed
the
@jpiasecki/root-view-always-active
branch
from
b9f236c to
ad3f731
Compare
|
As I mentioned in the previous message, this is more of a workaround than a solution, hence I changed the prop name with an Given that it will take time to make it possible to implement a proper fix, I think we can merge this as a temporary solution. Keep in mind that this API will be removed in the future, and will cause unexpected behavior when trying to reference gestures attached under different root views in gesture relations. |
This PR allows users to override whether a particular `GestureHandlerRootView` is enabled or not. By default, only the topmost root view would be active, allowing all gestures to interact with each other. The problem with that approach is that if any of the native views underneath called`requestDisallowInterceptTouchEvent`, all gestures would be canceled. It comes from the fact that `requestDisallowInterceptTouchEvent` calls are propagated up the view hierarchy and we expect `GestureHandlerRootView` to be relatively close to the top. The simple solution would be to add another root view underneath the view that may call `requestDisallowInterceptTouchEvent` to prevent gestures from being canceled, this, however, resulted in two problems: - the inner root view would not be enabled - after adding the option to enable it manually, both root views would start handling the event, resulting in duplicated event streams I've fixed the second problem by adding checks at the beginning of `extractGestureHandlers` and `traverseWithPointerEvents` to ensure that we're not extracting gestures attached under another enabled root view. This allows for solving the problem described in #2383. Tested on the reproduction from #2383
6 participants
Description
This PR allows users to override whether a particular
GestureHandlerRootViewis enabled or not. By default, only the topmost root view would be active, allowing all gestures to interact with each other.The problem with that approach is that if any of the native views underneath called
requestDisallowInterceptTouchEvent, all gestures would be canceled. It comes from the fact thatrequestDisallowInterceptTouchEventcalls are propagated up the view hierarchy and we expectGestureHandlerRootViewto be relatively close to the top.The simple solution would be to add another root view underneath the view that may call
requestDisallowInterceptTouchEventto prevent gestures from being canceled, this, however, resulted in two problems:I've fixed the second problem by adding checks at the beginning of
extractGestureHandlersandtraverseWithPointerEventsto ensure that we're not extracting gestures attached under another enabled root view.This allows for solving the problem described in #2383.
Test plan
Tested on the reproduction from #2383