IssueTracker

Hi, this support channel is intended for YouTube API related issues. For anything specific to Youtube website, Android or iOS app, please follow the guide posted in the link below.

https://support.google.com/youtube/answer/4347644

You may also ask this question through our community forum:

https://support.google.com/youtube/community?hl=en

Might this issue be related to my flings being broken in nestedScolls?

I am using a nestedScroll(...) to create a collapsing toolbar. However implementing it this way is disabling any flinging on the list. I am not sure why, because I am not consuming the Flings in my nested scroll, or do I? Will I have to reimplement flinging animations when using nested scrolling?

modifier = Modifier
  .nestedScroll(
    connection = object : NestedScrollConnection {
      override fun onPreScroll(available: Offset, source: NestedScrollSource): Offset {
        val scrollInDp = available.y / density
        if (scrollInDp > 0 && state.value != 0)
          return Offset.Zero
        val newHeight = (headerHeight + scrollInDp)
            .coerceIn(0f..maxHeaderHeight)
        val consumed = newHeight - headerHeight
        headerHeight = newHeight
        return Offset(0f, consumed * density)
      }
    },
  )

It's hard to tell from your snipped. We cann onPreScroll on any fling frame as well, since it's still a scrolling action. You might be able to disambiguate between sources (drag or fling) using the source: NEstedScrollSource parameter.

In general this bug is about incorrect velocity calculation, not about fling not working, so if you will be able to come up with the small repro sample -- please file another bug.

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.

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

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.

I noticed that the fix for this bug has been reverted. Is there any update on this bug?

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 to make fling to continue properly curve-wise, because now it is starting the curve from the beginning again when jumps from child to the parent.

Stay tuned.

This issue is a blocker for building a simple bottom sheet with a LazyColumn inside, which is a fairly common pattern.

FWIW compose-collapsing-toolbar's implementation uses a custom VelocityTracker and feels much nicer than the one provided by Compose UI right now.

https://github.com/onebone/compose-collapsing-toolbar/blob/master/lib/src/main/java/me/onebone/toolbar/Internals.kt

Hi, thanks for posting this. The improvements for VelocityTracker should be available in the next alpha version of compose UI, so stay tuned :)

Hi, we've landed a fix for velocity tracker in https://developer.android.com/jetpack/androidx/releases/compose-ui#1.3.0-alpha02 that might help remediate some of the issues listed here.

Yes, the nested fling issue will be followed-on https://issuetracker.google.com/issues/175010956 Thanks for checking!

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

• androidx.compose.foundation:foundation:1.3.0-beta03

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.compose.foundation:foundation:1.7.0-alpha03
• androidx.compose.foundation:foundation-android:1.7.0-alpha03
• androidx.compose.foundation:foundation-desktop:1.7.0-alpha03