Hi all. Looks like the window inset behaviour for ...

# compose

[xxfast]

Hi all. Looks like the window inset behaviour for nested androidx.compose.material3.Scaffold has been changed at some point, and this is currently breaking my usages. I have this nested setup

Scaffold(
  bottomBar = {..},
  floatingActionButton = { FloatingActionButton(onClick = {}) { Icon(imageVector = Icons.Default.Share, contentDescription = null)} },
  floatingActionButtonPosition = FabPosition.Center,
) { outerPadding ->
  Scaffold(
    floatingActionButton = {
      FloatingActionButton(onClick = {}) {
        Icon(imageVector = Icons.Default.Edit, contentDescription = null)
      }
    },
    modifier = Modifier.padding(outerPadding),
  ) { innerPadding ->
    Box(
      modifier = Modifier
        .fillMaxSize()
        .padding(innerPadding)
    ) {
      Text(text = "Body", modifier = Modifier.align(Alignment.Center))
    }
  }
}

As you can see, the first scaffold is not consuming the window inset and is pass along to its children, resulting in multiple insets being applied. How can we make it so that the insets are consumed and nested composables dont add extra insets as padding?

[Albert Chang]

Just specify contentWindowInsets = WindowInsets(0, 0, 0, 0) for the inner scaffold.

[xxfast]

I could, but I would have to do this for each nested scaffold manually 🤔 which is a little annoying

[Ian Lake]

What version are you using? Because the 1.2.0-alpha03 release notes do say:

Scaffold's contentWindowInsets parameter now respects consumed window insets. Note that the behavior of content padding based on topBar and bottomBar remains unchanged when these parameters are provided.

https://developer.android.com/jetpack/androidx/releases/compose-material3#1.2.0-alpha03

[xxfast]

I'm using compose-multiplatform 1.4 which is compose material3 1.0.1

[xxfast]

Looks like this is addressed in compose material3 1.2.0-alpha03 👍