IssueTracker

There is a report about it in kotlinlang Slack: https://kotlinlang.slack.com/archives/C01D6HTPATV/p1706005056105739

Thanks for the report!

The release notes documentation has been edited to clarify this change in behavior for line height.

To support non-standard text sizes, we encourage users to follow the Material design system and use a different type scale rather than changing the font size directly. Alternatively, users can overwrite the line height like so: style = LocalTextStyle.current.copy(lineHeight = TextUnit.Unspecified), or create a custom Typography entirely.

In my case, I have multiple font sizes in the same Text (using SpanStyle in AnnotatedString). There are legitimate reasons for this. For example, when combining Chinese and English (phonetic) together (for language-learning purposes).

otherwise content code will have to check and adjust based on the top/bottom app bar presence, which is not ideal.

The usage I'm thinking of shouldn't have the content care if the top/bottom app bar is there.

Let's say the Scaffold didn't interact with insets at all.

Then, the inner padding passed to the content will pass down the space information taken up by the app bars. That may or may not include the insets.

But what the content can do is do call consumedWindowInsets(innerPadding) unconditionally. If there are app bars, then the height of those will be consumed so that they are not reapplied later. If there aren't app bars, then the innerPadding will be empty, and the insets will be left available for an inner component to take into account.

I think that pass-through behavior should be available as an option for Scaffold, to also handle the cases for the reasons highlighted above by others.

re comment#5

With the changes, the entire screen is now reduced in size when the keyboard appears.

I'm not sure I follow what's happening in your case. This change handles no ime insets and ime insets should work as before. Please file a separate bug with the repro sample if you see something strange.

re comment#6

Got it, I'm evaluating a good API for that right now.

As for Snackbar, you can manually do it by passing SnackbarHost(modifier = Modifier.windowInsetsPadding(WindowInsets.safeDrawing.only(Horizontal + Bottom)))

Currently Scaffold is including safeDrawing, which includes IME insets as well.

So innerPadding will contain the ime insets (assuming there is no bottom bar). If there is a bottom bar, it will depend on whether the bottom bar is handling the ime insets or not.

re Alex comment#7,

But what the content can do is do call consumedWindowInsets(innerPadding) unconditionally.

calling consumedWindowInsets(innerPadding) unconditionally would consume more than intended as it will include the top and bottom app bar heights, causing the amount of unconsumed insets to be smaller then the real insets are. This will cause ime and other insets to break potentially and show incorrect padding. This is one of the reasons we might never promote the PaddingValues overload of consumeWindowInsets, it is just too dangerous.

I'm looking into what would be a sensible shape of the API

Currently Scaffold is including safeDrawing, which includes IME insets as well.

Ooooh, that's true. I don't think we want to handle ime at all here in the scaffold or in other places to be honest. Is there a reason to handle it there? Probably for snackbar only..

I don't think we want to handle ime at all here in the scaffold or in other places to be honest. Is there a reason to handle it there?

It's horrible when ime is handled there that the bottom bar moves up. It looks really weird.

It is a bug, we should only consume status and navigation bars, but not ime. It can be an opt-in behavior if desired.

snackbar and fab problem will be adressed here: https://issuetracker.google.com/issues/244400727

This bug was linked in a change in the following release(s):

• androidx.compose.material3:material3:1.0.0-beta02

As a reference, https://github.com/android/nowinandroid/pull/242/ has been updated with the new behavior changes.

Quick question, I have a problem with Scaffold not updating innerPadding as a result of me showing/hiding a topBar, so is this is a bug I should report or am I missing something?

Scaffold(
    topBar = {
        val showAppBar = true/false
        if (showAppBar) TopAppBar() //topBar shows/hides as expected based on some state
    }
) { innerPadding -> //but innerPadding never gets updated based on change in topBar visibility??
    //some content that consumes innerPadding
}

If this is actually supposed to work this way I might be forced to move TopBar onto individual screens?