Status Update
No update yet.
Comments
to...@gmail.com
Does this happen if you temporarily remove/disable the pull-refresh part?
se...@google.com
va...@google.com
to...@gmail.com
to...@gmail.com
We're facing the same issue with TopAppBar and TopAppBarDefaults.pinnedScrollBehavior. When scrolling quickly on a lazy layout, the app bar container color does not respond.
Repo:
Video:
val scrollBehavior = TopAppBarDefaults.pinnedScrollBehavior()
Scaffold(
modifier = Modifier
.fillMaxSize()
.nestedScroll(scrollBehavior.nestedScrollConnection),
topBar = {
TopAppBar(
title = {
Text(
modifier = Modifier.fillMaxWidth(),
text = "Hello!",
textAlign = TextAlign.Center,
)
},
scrollBehavior = scrollBehavior,
)
},
) { innerPadding ->
LazyColumn(
modifier = Modifier.padding(innerPadding),
contentPadding = PaddingValues(16.dp),
verticalArrangement = Arrangement.spacedBy(8.dp),
) {
items(100) {
Text(
text = "Item $it",
modifier = Modifier
.fillMaxWidth()
.background(MaterialTheme.colorScheme.surfaceContainerHigh)
.padding(24.dp),
)
}
}
}
to...@gmail.com
I am facing the same bug and i think the root case for it is that the PinnedScrollBehavior doesn't override the onPostFling in its NestedScrollConnection implementation.
I made a crude simple custom version and added
override suspend fun onPostFling(consumed: Velocity, available: Velocity): Velocity {
if (available.y > Velocity.Zero.y)
state.contentOffset = 0f
return super.onPostFling(consumed, available)
}
and then it works fine for me!
to...@gmail.com
Project: platform/frameworks/support
Branch: androidx-main
Author: Shalom Gibly <
Link:
Fix the app-bars behaviors to detect end of scroll
Expand for full commit details
Fix the app-bars behaviors to detect end of scroll
Apply a fix to all the behaviors to detect the end of scroll in the post
fling function. This will better ensure an app-bar color change when the
content is scrolled all the way.
Bug: 293665988
Test: Manual
Relnote: "Fix the top and bottom app-bar behaviors to reliably change
color when content is scrolled all the way."
Change-Id: Idc4e834695cbd7cb8099f7b63cf21d5b764f1c81
Files:
- M
compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/AppBar.kt
Hash: 792c8cdf7db425c674de1214e60c7d01f46e9750
Date: Mon Nov 25 06:03:57 2024
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
Author: Jose Figueroa <
Link:
[Material3][ModalBottomSheet] Update inset handling to move modalbottomsheet content out of status bars
Expand for full commit details
[Material3][ModalBottomSheet] Update inset handling to move modalbottomsheet content out of status bars
This makes content more visible and interactable, per material spec
RelNote: "ModalBottomSheet content now moves content away from status bar."
Bug: 336553431
Bug: 321877275
Bug: 336962418
Bug: 342093067
Test: Manual testing
Change-Id: I5114c66808d155f5db97908520bad2efd93be08e
Files:
- M
compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/ModalBottomSheet.kt
Hash: 8e198d739211999723660d6394ba6274730f564a
Date: Tue Oct 01 11:59:21 2024
be...@gmail.com
"Reason for revert: Causes a potential regression with content visibility" ??
Since 1.3, ended up creating my own shape with a top offset + top content offset.
How on earth could anyone think it's a good idea to have the bottom sheet going under the status bar ?!
Anything behind it becomes unaccessible, and adding a top offset makes the design super ugly (one could think of a solution where depending on the screen height and content height, the offset is applied, but man things are supposed to be simple and straightforward...)
Description
Jetpack Compose version: Last snapshot 11763555 (So containshttps://github.com/androidx/androidx/commit/33c32f65dd7879954cfa7a46a76eb959c977e291 )
Material Library Version (M2, M3 or Both?): M3
Material Compose component used: ModalBottomSheet
Applying content padding does not work for modalbottomsheets and status bar.
Try to build a proper modalbottomsheet that properly take in account the status bar when the sheet is longer than the screen.
This is currently not possible without setting contentColor to transparent and manually apply the shape to the header we use, completely breaking the purpose of the API that expose the color and the shape and should work.