# compose

Is this a bug? When I'm using Scaffold(contentWindowInsets = WindowInsets.safeDrawing) (Material3) with a LargeTopAppBar it works when it's collapsed but not when it's expanded

device-2023-02-03-134250.webm

Sorry for the weird orientation 😅

Are you applying the insets to the top bar itself too? Maybe you should. Throw the relevant code here if you don’t mind.

I would imagine Scaffold does it by the contentWindowInsets ? I'm trying to do a simple reproduction example here

val systemUiController = rememberSystemUiController()
systemUiController.setSystemBarsColor(color = Color.Transparent)
val topAppBarScrollState = rememberTopAppBarState()
val scrollBehavior = TopAppBarDefaults.exitUntilCollapsedScrollBehavior(topAppBarScrollState)
Scaffold(
    contentWindowInsets = WindowInsets.safeDrawing,
    topBar = {
        LargeTopAppBar(
            title = { Text("Foobar") },
            scrollBehavior = scrollBehavior
        )
    },
    content = {
        LazyColumn(
            contentPadding = it,
            content = { items(50) { Text("123", modifier = Modifier.fillMaxWidth()) } },
            modifier = Modifier
                .nestedScroll(scrollBehavior.nestedScrollConnection)
                .fillMaxSize(),
        )
    },
    modifier = Modifier.fillMaxSize()
)

I can see inside the AppBar that one uses windowInsetPadding and the other one doesn't

so maybe that's why

https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/[…]ommonMain/kotlin/androidx/compose/material3/Scaffold.kt;l=120 This seems to show that contentWindowInsets isn’t automatically passed in any way to the topBar composable, so you gotta rely on what you pass inside topBar = {} in your call to Scaffold. Then it seems like LargeTopAppBar defaults to TopAppBarDefaults.windowInsets so that by itself should work no? Which scrollBehavior are you passing in btw?

Aha, for the double top app bar case, it seems like maybe, just from looking at the code, the paddings are passed to the first top app bar here, but not the second one https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/[…]nMain/kotlin/androidx/compose/material3/AppBar.kt;l=1208-1229 Could it be that the text that shows “under” when you’re scrolling is this second call, and it would also need to be insetted?

Exactly 🙂

I’ll +1 if you make a bug report. Maybe link this discussion too, with a link to the Kotlin slack archives (like this one https://slack-chats.kotlinlang.org/t/8623692/is-this-a-bug-when-i-m-using-scaffold-contentwindowinsets-wi) so that it’s accessible by everyone. Or just link them the code too to see if we’re missing something and we’re making the wrong assumption as to what’s going wrong here.

Oh wow, I didn't know you could like this haha I'll try to find where to report Compose Material issues and post the link here

https://issuetracker.google.com/issues/new?component=742043&template=1590761 😊

And it’s not rotated 90°. That’s peak bug reporting right there 😅

Yeah, I fixed it for the bug reporting haha Here I posted straight from the emulator recording file and I didn't expect it to be in the wrong direction haha

Great bug, and I think your assumption is spot on 👍

This must be the fastest turnaround of: Someone reports a bug in slack, a solution is found, a bug report is made, you pick it up, it's already merged ⚡⚡ https://android-review.googlesource.com/c/platform/frameworks/support/+/2420556

Uh oh, don’t expect that always 😅

Haha, no pressure of course. But we can still celebrate those exceptions 😅