Status Update
No update yet.
Comments
ri...@google.com
Thanks for the report!
se...@google.com
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 style = LocalTextStyle.current.copy(lineHeight = TextUnit.Unspecified), or create a custom Typography entirely.
co...@google.com
ri...@google.com
co...@google.com
se...@google.com
ap...@google.com
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).
se...@google.com
ju...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.material3:material3:1.2.0-alpha02androidx.compose.material3:material3-android:1.2.0-alpha02
pr...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.material3:material3:1.1.1
di...@zillowgroup.com
When I try to replace the default windowInsets value with something like WindowInsets.navigationBars, it doesn't help because the values are zero at the time of calling ModalBottomSheet(). Placing a hard-coded bottom padding value in the windowInsets object does have an effect when the bottom sheet is expanded, but I can't figure out how to determine the correct padding value since the WindowInsets.navigationBars values are zero.
Specifically, I am experiencing the issue when using Compose BOM 2023.06.01, but not with 2023.05.01.
ar...@gmail.com
On affected systems the ModalBottomSheet is always aligned to the bottom of the screen.
We see this on Android <= 10 (you can easily see this on an Android 10 emulator, while the Android 13 emulator works).
However, some users report this for Android 13 (only three reports, yet).
I guess it doesn't bother many Android 13 users (most of our users have it), because I think the default is gesture navigation, and while you can see that it overlaps, it doesn't hurt much.
At least with 3-button navigation, you have a hard time to touch the application buttons behind the navigation buttons.
id...@trivago.com
hu...@gmail.com
Facing the same issue. ModalBottomSheet does not allow the sheet content to be padded rather it places the sheet dialog on top of navigation bars. This way if the sheet container has a background color there's an obvious white line equal to navigation bar inset. Supplying WindowInsets(0,0,0,0) to cancel out bottom paddings & trying to pad content manually doesn't work since within the content navigation insets are returned 0.
ex...@isn.com
I’m experiencing the same issue with ModalBottomSheet when using material3 B.O.M 2023.06.01 (v1.1.1). This problem does not occur with B.O.M 2023.05.01 (v1.1.0).
Things I Tried (No Luck):
- No modifiers: Used only the default
BottomSheetDefaults.windowInsets. - Applied the
.safeDrawingPadding()modifier. - Applied the
.statusBarsPadding()modifier.
Observations (Screenshots Below):
- #1: The BottomSheet is
edgeToEdge, covering the status bar content. - #2: Adds way too much padding—more than what’s necessary.
- #3: Adds extra padding, but slightly less than #2.
Temporary Solution:
For now, I’ve downgraded back to B.O.M 2023.05.01, hopefully, newer versions of material3 (v1.1.1+) will resolve this issue, however, updating to the most recent ones (1.3+) requires tackling significant tech debt.
Description
After looking through all components that support Insets,
ModalBottomSheetdoesn't expose the option to change theWindowInsetthat it applies. This goes against the other components that use insets.All the other components (
TopAppBar,BottomAppBaretc), expose awindowInsetsparameter. Any component that consumes a window inset, should allow for this to be changed as not everyone is using insets in the exact same standard way.