Is this a bug? When I'm using `Scaffold(contentWindowInsets = WindowInsets.safeDrawing)` (Material3)...

# compose

[Tgo1014]

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

[Tgo1014]

Sorry for the weird orientation 😅

[Stylianos Gakis]

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

[Tgo1014]

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

[Tgo1014]

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()
)

[Tgo1014]

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

[Tgo1014]

so maybe that's why

[Stylianos Gakis]

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?

[Stylianos Gakis]

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?

[Tgo1014]

Exactly 🙂

[Stylianos Gakis]

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.

[Tgo1014]

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

[Stylianos Gakis]

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

[Stylianos Gakis]

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

[Tgo1014]

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

[Alex Vanyo]

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

[Stylianos Gakis]

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

[Alex Vanyo]

Uh oh, don’t expect that always 😅

[Stylianos Gakis]

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