A modern programming language that makes developers happier.

kotlinlang

Record_2023-10-06-11-29-32.mp4

When I vigorously swipe up on the bottom sheet, it moves upwards in a strange way instead of staying in place. The expected behavior should be no movement at all.

I have tested both Material 2 and 3's `ModalBottomSheet` with the most basic code, and the same issue occurs. I’m not sure if there is a known issue ticket for this bug?

I see it as a feature rather than a bug.
Is doing a nice physics animation.

Ah, while some may think this is fine, I personally believe it is more like a screen and should not be movable. Just like the launcher’s bottom drawer, its behavior is quite satisfactory, with only the list having a “physical animation” (overscroll effect). If the screen itself applied this, it would seem a bit strange. Of course, that’s just my take on it :)

and yes, perhaps it would be better to provide a boolean or something if we consider this as a feature :raised_hands:

YES I AM HAVING SAME ISSUE ON KMP SIDE AS WELL. I believe its a compose issue they need to fix this quick on all side.

I see, you have a valid point. I haven't heard complaints about it yet so I guess there's no ticket for that. Wait for some material expert feedback

`swipeable()` had a resistance config for this, not sure if there's a customizable value for `draggable()` which ModalBottomSheet uses internally

<@U01940W1PFA> the overshoot in ModalBottomSheet is due to the settle animation being started with the velocity at the end of the fling gesture. The default animation is a spring which allows overshooting the target value with high enough velocity. If you don't want overshooting you could change the animation spec to something that doesn't allow overshooting, for example `tween()`:
```val sheetState = rememberModalBottomSheetState(
    initialValue = ModalBottomSheetValue.Expanded,
    animationSpec = tween()
)```

<@U03M3G2TX9A> That’s amazing! I’ll give it a try later. However, this also means that there won’t be any spring effect at any time. This may require some trade-offs :smiling_face_with_tear:

you could implement a custom spring that doesn't overshoot

The default spring used for the bottom sheet is critically damped so it shouldn't overshoot when moving between anchors, so I'm not sure why it's overshooting in this case. You could debug and set a breakpoint in the `AnchoredDraggableState&lt;T&gt;.animateTo()`  animate call and see what the prev and targetOffset arguments are.