Bugzilla

(In reply to Markus Stange [:mstange] from comment #8)
> A diagonal drag over a tab in the tabs tray can have the following outcomes:
> 
>  1. The tab is swiped away horizontally, no vertical scrolling is performed.
>  2. The tab is swiped a bit horizontally but bounces back (remains open), no vertical scrolling is performed.
>  3. The tab is not moved, only vertical scrolling is performed.
> 
> What I'm suggesting would turn more cases of 1 into 2. But you're saying you'd like 3 to happen in more cases. And I think I agree.

Ah gotcha. Then yeah, increasing the velocity threshold might reduce the scenario where flings to scroll the tabs tray are triggering swipe to dismiss flings. Interestingly though, Google's default in their samples and a component (noted below) is only [125](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/SwipeToDismissBox.kt;l=264?q=file:androidx%2Fcompose%2Fmaterial3%2FSwipeToDismissBox.kt%20class:androidx.compose.material3.SwipeToDismissBoxState)

> So for this we'd want the AnchoredDraggable view to detect that the scroll direction (within the touch slop) is more vertical than horizontal, and we'd want it to pass off scrolling to the outer scroll view. I found [this issue](https://issuetracker.google.com/issues/287882994) which sounds similar (though it is about ViewPager2 rather than about AnchoredDraggable): 
> 
> I also found https://developer.android.com/develop/ui/compose/touch-input/pointer-input/scroll#nested-scrolling but haven't spent enough time with it to fully understand it.

Good find on that Google Issue. Yes, that's exactly what I've been looking into: is it possible to manually ignore swipes within a certain y-axis threshold. 

Much to my dismay, the `Modifier.anchoredDraggable` we leverage simply looks for a non-zero x-axis drag delta and declares this as a drag occurring, regardless of whatever the y delta is. It's also not clear how it is differentiating between scroll and drag gestures in this scenario. 

I think I've ran into a wall though. After investigating a few hours yesterday and today, I've tried the following:
- Pass-in a `InteractionSource` to `Modifier.anchoredDraggable`
    - The `InteractionSource` provides no drag measurement data. It simply returns a `Flow` of `Interaction` events that we can listen to.
- Listen to drag gestures via `detectDragGestures` within `Modifier.pointerInput`
    - `pointerInput` consumes any drag gestures, so even trying to log drags prevents `Modifier.anchoredDraggable` from being triggered. Similarly, if I place this Modifier before `anchoredDraggable`, it doesn't get called because the drag handling has been consumed downstream.
- Replace our in-house `SwipeToDismissBox` (which utilizes `Modifier.anchoredDraggable`) with the Material 3 `SwipeToDismissBox`
    - Even the official Google component has the exact same bug.

My educated assumption is that a nested scroll isn't at play here, but it might be worth investigating a little.

From there, the only approach I have not tried is completely rewriting our `SwipeToDismissBox` from scratch to use a custom `Modifier.anchoredDraggable` that would be able to be less sensitive to consuming drag gestures with a "large" y-axis delta.

`SwipeToDismissBox` was already a rewrite from earlier this year, as Google deprecated the `SwipeToDismiss` Composable in favor of `Modifier.anchoredDraggable`, so trying to handle the drag gesture within a scrolling parent in Compose has been fraught with development churn.

(In reply to Markus Stange [:mstange] from comment #8)
> A diagonal drag over a tab in the tabs tray can have the following outcomes:
> 
>  1. The tab is swiped away horizontally, no vertical scrolling is performed.
>  2. The tab is swiped a bit horizontally but bounces back (remains open), no vertical scrolling is performed.
>  3. The tab is not moved, only vertical scrolling is performed.
> 
> What I'm suggesting would turn more cases of 1 into 2. But you're saying you'd like 3 to happen in more cases. And I think I agree.

Ah gotcha. Then yeah, increasing the velocity threshold might reduce the scenario where flings to scroll the tabs tray are triggering swipe to dismiss flings. Interestingly though, Google's default in their samples and a component (noted below) is only [125](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/SwipeToDismissBox.kt;l=264?q=file:androidx%2Fcompose%2Fmaterial3%2FSwipeToDismissBox.kt%20class:androidx.compose.material3.SwipeToDismissBoxState)

> So for this we'd want the AnchoredDraggable view to detect that the scroll direction (within the touch slop) is more vertical than horizontal, and we'd want it to pass off scrolling to the outer scroll view. I found [this issue](https://issuetracker.google.com/issues/287882994) which sounds similar (though it is about ViewPager2 rather than about AnchoredDraggable): 
> 
> I also found https://developer.android.com/develop/ui/compose/touch-input/pointer-input/scroll#nested-scrolling but haven't spent enough time with it to fully understand it.

Good find on that Google Issue. Yes, that's exactly what I've been looking into: is it possible to manually ignore swipes within a certain y-axis threshold. 

Much to my dismay, the `Modifier.anchoredDraggable` we leverage simply looks for a non-zero x-axis drag delta and declares this as a drag occurring, regardless of whatever the y delta is. It's also not clear how it is differentiating between scroll and drag gestures in this scenario. 

I think I've ran into a wall though. After investigating a few hours yesterday and today, I've tried the following:
- Pass-in a `InteractionSource` to `Modifier.anchoredDraggable`
    - The `InteractionSource` provides no drag measurement data. It simply returns a `Flow` of `Interaction` events that we can listen to.
- Listen to drag gestures via `detectDragGestures` within `Modifier.pointerInput`
    - `pointerInput` consumes any drag gestures, so even trying to log drags prevents `Modifier.anchoredDraggable` from being triggered. Similarly, if I place this Modifier before `anchoredDraggable`, it doesn't get called because the drag handling has been consumed downstream.
- Replace our in-house `SwipeToDismissBox` (which utilizes `Modifier.anchoredDraggable`) with the [Material 3 `SwipeToDismissBox`](https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/SwipeToDismissBox.kt;l=216?q=file:androidx%2Fcompose%2Fmaterial3%2FSwipeToDismissBox.kt%20class:androidx.compose.material3.SwipeToDismissBoxState)
    - Even the official Google component has the exact same bug.

My educated assumption is that a nested scroll isn't at play here, but it might be worth investigating a little.

From there, the only approach I have not tried is completely rewriting our `SwipeToDismissBox` from scratch to use a custom `Modifier.anchoredDraggable` that would be able to be less sensitive to consuming drag gestures with a "large" y-axis delta.

`SwipeToDismissBox` was already a rewrite from earlier this year, as Google deprecated the `SwipeToDismiss` Composable in favor of `Modifier.anchoredDraggable`, so trying to handle the drag gesture within a scrolling parent in Compose has been fraught with development churn.