Anyone know why this was changed? `BottomSheetDef...
# compose-android
b
Anyone know why this was changed?
BottomSheetDefaults.windowInsets
now includes
<http://WindowInsets.safeDrawing.Top|WindowInsets.safeDrawing.Top>
. (I0ab67, b/321877275, b/336962418, b/342093067) This just makes it so the sheet is automatically padded by the statusBars, but I've been applying a color to my full screen content and not the sheet background color itself. I can fix it by setting WindowInsets(0.dp,0.dp,0.dp,0.dp) on the sheet and then consuming the WindowInsets on the content.
Alpha 1.4.0-alpha12 (normal to me)
1.4.0 release (weird). I don't see why the default behavior is to have the content at the top not move until it shrinks all the way at the top part where the drag handle is.
Anyway to disable this? Seems buggy/weird to me? "The logic is, as we move the sheet away from the anticipated top window insets, more of the known top window insets should be consumed to ensure content is appropriately spaced"
a
I think you've found the way to disable it - configuring
contentWindowInsets
allows you to adjust the default insets that are accounted for by the sheet.
b
I've still been running into issues with setting it to 0 and then trying to apply status bars padding to content and then having the weird stutter behavior
I have to use
Copy code
val statusBarsPadding = WindowInsets.statusBars.asPaddingValues()
as a hack instead of being able to use .statusBarsPadding() modifier
a
Ah I see, if you're trying to disable the consumption entirely, so that you still get the top insets as padding values in the sheet, even when the sheet doesn't overlap with the top insets?
b
I'm basically just trying to get the old behavior where I was able to pad things inside the sheet myself and not get weird behavior where the top of the content is sticky until the statusBars sized portion of the sheet is swiped past. I don't see how this isn't seen as buggy behavior.
can you see how in my second video the top where the red ends, as I drag the sheet down, the content at the top remains static, whereas the bottom is stretching out, and then once the white bar is swiped away, then the top content starts sliding.
👍 1
Copy code
ModalBottomSheet(
    contentWindowInsets = {
        WindowInsets(0.dp, 0.dp, 0.dp, 0.dp)

    },
    dragHandle = null, sheetState = sheetState, onDismissRequest = {

    }) {
    val statusBarsPadding = WindowInsets.statusBars.asPaddingValues()
    Box(
        modifier = Modifier
            .fillMaxSize()
            .background(color = Color.Red)
            .padding(
                statusBarsPadding
            )
    ) {
        Column(
            modifier = Modifier
                .fillMaxSize()
            ) {
            Text(
                text = "Hello World",
                modifier = Modifier
            )
        }
    }
}
This code gives me this on the latest version. Which is a hacky way (in my opinion since we have to use statusBarsPadding outside of the .statusBarsPadding() as to not have the insets consumed by the sheet) to get the old behavior. It basically acts like M3 1.3.0 ModalBottomSheet with statusBarsPadding applied to the content.
Copy code
ModalBottomSheet(
    dragHandle = null, sheetState = sheetState, onDismissRequest = {
    }) {
    Box(
        modifier = Modifier
            .fillMaxSize()
            .background(color = Color.Red)
    ) {
        Column(
            modifier = Modifier
                .fillMaxSize()
            ) {
            Text(
                text = "Hello World",
                modifier = Modifier
            )
        }

    }
}
This code is just an out of the box usage of ModalBottomSheet. Which gives in my opinion weird behavior. The white top slides down first, keeping the top portion of the red Box static, while the bottom portion of the red box stretches at the bottom. Then once you swipe past the white part, only then will the top portion of the content start sliding down.