Status Update
No update yet.
Comments
ma...@google.com
ap...@google.com
Related to this, there seems to be another issue with this setup: if I set a nestedScroll modifier that consumes all the available scroll in the scrollable column inside, this should take precedence over the swipe gesture in the BottomSheetScaffold, but that's not the case, the bottom sheet swipe gesture consumed the scroll.
However, I tried duplicating the BottomSheetScaffold implementation and switched the anchoredDraggable modifier, DraggableAnchors and other M3 APIs with their equivalents in the Foundation library, and then it worked as expected. The code in androidx.compose.material3.AnchoredDraggable has this comment:
/**
* This is a copy of androidx.compose.foundation.gestures.AnchoredDraggable until that API is
* promoted to stable in foundation. Any changes there should be replicated here.
*/
So it seems like both APIs are interchangeable, but either the M3 ones aren't up to date with the changes in foundation or its implementation has differed and has this bug.
ap...@google.com
Maybe someone has nice workaround?
ap...@google.com
Branch: androidx-main
commit bbd9f1020330ba0373d7588091578aa678239d4b
Author: Max Alfonso-Ying <maxying@google.com>
Date: Fri Mar 29 19:05:03 2024
Fix BottomSheetScaffold nested scroll when sheet gestures disabled
Fixes:
Test: added unit test
Relnote: "`BottomSheetScaffold` will no longer scroll from nested scroll if `sheetSwipeEnabled` is false"
Change-Id: I5e1c1adb83167184f2baa4457cf1b3c70272a72c
M compose/material3/material3/src/androidInstrumentedTest/kotlin/androidx/compose/material3/BottomSheetScaffoldTest.kt
M compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/BottomSheetScaffold.kt
ap...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.material3:material3:1.3.0-alpha05androidx.compose.material3:material3-android:1.3.0-alpha05androidx.compose.material3:material3-desktop:1.3.0-alpha05
ma...@google.com
pr...@google.com
xe...@gmail.com
ma...@google.com
Can you elaborate on what you mean? The animation is dependent on where the search bar is on the screen, so if you want an animation like in the design guidelines, it has to be placed at the top like TopSearchBar provides.
Description
The current implementation uses the same component for the unexpanded search bar and the expanded search view. This makes it hard to use the search bar in the middle of other content, since you have to ensure not to accidentally pass constraints that prevent it from being full screen.
Making the full-screen search view into a dialog would avoid most of these issues.
If there is enough interest (by +1-ing this issue), we could explore the possibility of using this approach.