Status Update
No update yet.
Comments
ma...@google.com
Over to Ralston to take a look. I imagine with the new relocation logic it should be fixed?
ki...@gmail.com
What is happening here is that the TextField does not know that it is in a scrollable container, and since the keyboard is going to hide the currently focused text, the text field calls View.requestRectangleOnScreen which causes the entire app to pan up, and that clips the top bar.
The Relocation APIs are experimental right now. It is not used in TextField as we are past the alpha stage and can only use stable APIs in TextField. So this bug can only be fixed post 1.0
ma...@google.com
This should be fixed by
I verified that this sample code now works when soft input mode is AdjustResize.
ap...@google.com
Branch: androidx-main
commit df1da916ff4c7fc0acff00e8988923f53aa6e0d2
Author: Matvei Malkov <malkov@google.com>
Date: Wed May 26 17:39:48 2021
Make scrollable to adjust velocity if some delta consumed during "pre"-stage of the nested scroll
We need to calculate the velocity based on the fact that some of it might be preconsumed by the parent above. If we're not to account for that, there are cases when the velocity can have different vector, causing bad UX
Fixes: 179417109
Test: added for relative velocity tracker and for scrollable logic with regards to velocity calculation when preconsuming
Relnote: n/a
Change-Id: I74290c15a3ffd50bef3f358b22a6294854d9baf9
M compose/foundation/foundation/api/1.0.0-beta09.txt
M compose/foundation/foundation/api/current.txt
M compose/foundation/foundation/api/public_plus_experimental_1.0.0-beta09.txt
M compose/foundation/foundation/api/public_plus_experimental_current.txt
M compose/foundation/foundation/api/restricted_1.0.0-beta09.txt
M compose/foundation/foundation/api/restricted_current.txt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/DraggableTest.kt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/ScrollableTest.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/Draggable.kt
A compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/RelativeVelocityTracker.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/Scrollable.kt
M compose/foundation/foundation/src/test/kotlin/androidx/compose/foundation/gestures/DragGestureDetectorTest.kt
M development/build_log_simplifier/messages.ignore
mx...@gmail.com
This problem doesn't seem to have been fully fixed, or at least the behavior is still different from that in the view system.
Current behavior is that when the scroll ends during the parent is consuming pre-scrolling offset, the scrolling layout will not fling as the velocity is zero.
Typical usages of nested scroll include scroll-to-hide toolbar, collapsing toolbar and bottom sheet like layout. In these cases, not flinging seems wired. I've attached a simple example of a bottom sheet like layout and a video demonstrating the issue.
ma...@google.com
Thanks for getting back to this!
Not sure what are you suggesting here. It seems like preconsuming parent should either track the velocity on his own or react to the onPre/onPost Fling and settle as needed. The latter is what we do in the material implementation of bottom sheets.
Ccing Chris for views input here
mx...@gmail.com
If I understood it correctly, the latter is only usable when there are some anchors like Modifier.swipeable().
The former method, however, doesn't allow the scrolling child to continue the fling when the parent has consumed all the delta it can consume.
I've attached the video of a new example of scroll-to-hide toolbar, in which the first half is implemented using Compose UI and the second half is implemented using the view system. You can see that in the view version, when the scroll stops when the action bar is half-hidden, the action bar flings until it's completely hidden, and then the scrolling child continues to fling, which is my expected behavior.
In the view system, the scrolling child (NestedScrollView, RecyclerView, etc) will always record touch events, calculate the correct velocity and start fling with the velocity, even if itself is not actually scrolling, which results in the behavior above.
mx...@gmail.com
I noticed that the fix for this bug has been reverted. Is there any update on this bug?
ma...@google.com
We decided to postpone the investigation in this particular issue for now. No updated yet unfortunately.
The next thing on our list in this regard is
Stay tuned.
an...@google.com
al...@gmail.com
This issue is a blocker for building a simple bottom sheet with a LazyColumn inside, which is a fairly common pattern.
je...@team.bumble.com
My hypothesis is that the fling coordinates being processed by the LazyColumn are not being treated as absolute coords relative to the screen and so as the LazyColumn's origin moves within its parent the gesture handler incorrectly generates another fling in the opposite direction.
Example rough code:
var offset by remember { mutableStateOf(0f) }
val nestedScrollConnection = remember {
object : NestedScrollConnection {
override fun onPreScroll(available: Offset, source: NestedScrollSource): Offset {
val currentOffset = offset
offset = (offset - available.y).coerceIn(0f, 200f)
val delta = offset - currentOffset
return Offset(x = 0f, y = -delta)
}
}
}
Column {
Box(Modifier.fillMaxWidth().height((240f - offset).dp)
Box(Modifier.nestedScroll(nestedScrollConnection) {
LazyColumn(Modifier.fillMaxSize()) {
...
}
}
}
ma...@google.com
le...@google.com
Hi, thanks for posting this. The improvements for VelocityTracker should be available in the next alpha version of compose UI, so stay tuned :)
le...@google.com
je...@team.bumble.com
le...@google.com
Yes, the nested fling issue will be followed-on
ap...@google.com
Branch: androidx-main
commit 6e48495cd4bf5a0af6747eea45b2cd49128ffcb2
Author: Levi Albuquerque <levima@google.com>
Date: Tue Aug 16 15:12:46 2022
Fix fling animation cancellation issue
Test: Add tests to verify behavior
Fixes: 179417109
Fixes: 175010956
Change-Id: Ic31ab56737b410b09c33c9e1c158697fe8d259de
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/ScrollableTest.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/Scrollable.kt
na...@google.com
This bug was linked in a change in the following release(s):
androidx.compose.foundation:foundation:1.3.0-beta03
ap...@google.com
Branch: androidx-main
commit 418f3a6588d2384e49d996cebcb2d5678ceeb3ea
Author: Levi Albuquerque <levima@google.com>
Date: Mon Feb 12 16:23:19 2024
Click on moving list initial issue
Due to an early fix we were prioritizing continuing the scroll of nested lists in any direction when taping on a parent list. The actual intended behavior was to consider nested children that scroll -on the same direction- if the click happened on the said child. In this CL I'm reverting those changes as we will revisit the nested scrolling UX and there will be more benefits to having the original behavior without the issues the fix introduced.
Test: Added test to check behavior.
Relnote: N/A
Fixes: 293777304
Fixes: 289685606
Fixes: 296064317
Bug: 175010956
Bug: 179417109
Change-Id: Ia71ed02e06603c6c27ad4648cfc8e32587397d63
M compose/foundation/foundation/src/androidInstrumentedTest/kotlin/androidx/compose/foundation/ScrollableTest.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/Scrollable.kt
pr...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.foundation:foundation:1.7.0-alpha03androidx.compose.foundation:foundation-android:1.7.0-alpha03androidx.compose.foundation:foundation-desktop:1.7.0-alpha03
Description
Version used: 1.0.0-alpha11
Devices/Android versions reproduced on: All devices
Offset consumed by nested scroll parent is not taken into account when calculating scrolling velocity. This sometimes causes the fling velocity to be in the opposite direction if the scroll ends when the parent is consuming pre-scrolling offset.