IssueTracker

Thanks! This looks like a bug, thank you for reporting!

Project: platform/frameworks/support
Branch: androidx-main
Author: Jossi Wolf <jossiwolf@google.com>
Link:      https://android-review.googlesource.com/3278651

Update AnchoredDraggable target calculation logic

Update AnchoredDraggable target calculation logic

We were previously relying on currentValue and the next closest anchor in the drag direction, but the simpler and more reliable way is to look at the left and right anchors as the window.

Relnote: Fixed a bug where positional thresholds passed to AnchoredDraggableDefaults.flingBehavior were not considered correctly in some scenarios.
Test: anchoredDraggable_fling_offsetPastHalfwayBetweenAnchors_beforePosThreshold_doesntAdvance
Bug: 367660226
Bug: 366003852
Change-Id: Ifdf0dfcf3d7ff8288affee56e7092bbed473d6ab

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

• androidx.compose.foundation:foundation:1.8.0-alpha04
• androidx.compose.foundation:foundation-android:1.8.0-alpha04
• androidx.compose.foundation:foundation-jvmstubs:1.8.0-alpha04

Using the new version 1.8.0-alpha04 does not seem to resolve the issue for me. I tested with the same setting as the reported issue:

            // it doesn't matter what you put here a the multiplier, the positionalThreshold is always 50%
            positionalThreshold = { d -> d * 0.9f },
            velocityThreshold = { Float.POSITIVE_INFINITY },

Same. I've run this again on 1.8.0-alpha04. When using

positionalThreshold = { d -> d * 0.1f }

Dragging up to 10% or between 50% and 90% will cause it to snap back to the start anchor. Dragging between 10% and 50% or past 90% will cause it to snap to the end anchor.

I would expect It to only return if dragged less than or equal to 10% and snap to the end if dragged greater than 10%.

When using

positionalThreshold = { d -> d * 0.9f }

It acts as if the threshold has been set to 50%.

From what I can tell, nothing has changed about the behavior.

Thanks, we will investigate and update this issue.

Project: platform/frameworks/support
Branch: androidx-main
Author: Jossi Wolf <jossiwolf@google.com>
Link:      https://android-review.googlesource.com/3343747

Update AnchoredDraggable target calculation logic

Update AnchoredDraggable target calculation logic 
 
There was a missed case when the velocity was negative. 
 
Test: New tests with more parameter permutations 
Fixes: 367660226 
Bug: 376931805 
Relnote: "Follow-up fix for an issue in AnchoredDraggable's target calculation where it could settle at the wrong anchor for specific swipes." 
Change-Id: I23b8773d3a694aa3c8de6a8f34b9d7fb54cfe560

What is the fix version?

We will comment on the issue when it has been included in a release. Until then, you can try the snapshot versions from androidx.dev.

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

• androidx.compose.foundation:foundation:1.8.0-alpha07
• androidx.compose.foundation:foundation-android:1.8.0-alpha07
• androidx.compose.foundation:foundation-jvmstubs:1.8.0-alpha07
• androidx.compose.foundation:foundation-linuxx64stubs:1.8.0-alpha07

#15, please report a new issue with a full reproduction case and the versions you are using. Thank you!

Running compose foundation 1.8.0-alpha07

I'm using AnchoredDraggable with nested scrolling. When I drag and release the lazy layout sometimes the draggable settles correctly and sometimes it doesn't even when i drag and release past the threshold (positionalThreshold = { distance -> distance / 2f }.

    internal fun nestedScrollConnection(
        dragState: AnchoredDraggableState<Anchors>,
        decayAnimationSpec: DecayAnimationSpec<Float>,
        orientation: Orientation = Orientation.Vertical,
    ): NestedScrollConnection = object : NestedScrollConnection {

        override fun onPreScroll(
            available: Offset,
            source: NestedScrollSource,
        ): Offset {
            val availableDelta = available.toFloat()

            return if (
                availableDelta < 0f
            ) dragState.dispatchRawDelta(availableDelta).toOffset()
            else Offset.Zero
        }

        override fun onPostScroll(
            consumed: Offset,
            available: Offset,
            source: NestedScrollSource,
        ): Offset {
            val availableDelta = available.toFloat()

            return if (
                availableDelta >= 0f
            ) dragState.dispatchRawDelta(availableDelta).toOffset()
            else Offset.Zero
        }

        override suspend fun onPreFling(
            available: Velocity,
        ): Velocity {
            val availableDelta = available.toFloat()

            val consumedOffset = if (availableDelta < 0f) dragState.animateToWithDecay(
                velocity = availableDelta,
                targetValue = Anchors.Collapsed,
                decayAnimationSpec = decayAnimationSpec,
            ) else 0f

            return Velocity(
                x = 0f,
                y = consumedOffset,
            )
        }

        override suspend fun onPostFling(
            consumed: Velocity,
            available: Velocity,
        ): Velocity {
            val availableDelta = available.toFloat()

            if (
                availableDelta > 0f
            ) dragState.animateToWithDecay(
                velocity = availableDelta,
                targetValue = Anchors.Expanded,
                decayAnimationSpec = decayAnimationSpec,
            )

            dragState.settle(animationSpec = spring())

            return Velocity(x = 0f, y = availableDelta)
        }

        private fun Float.toOffset(): Offset = Offset(
            y = if (orientation == Orientation.Vertical) this else 0f,
            x = if (orientation == Orientation.Horizontal) this else 0f,
        )

        @JvmName("offsetToFloat")
        private fun Offset.toFloat() = if (orientation == Orientation.Horizontal) x else y

        @JvmName("velocityToFloat")
        private fun Velocity.toFloat() = if (orientation == Orientation.Horizontal) x else y
    }

Hi, this seems to be a different issue. Please provide a full reproducer in a new issue so we can investigate. Thank you!

Looking at the release notes (https://developer.android.com/jetpack/androidx/releases/compose-foundation) is likely the most straightforward way. Since this issue has a few +1 votes, please keep the comments to the original issue :)

Unfortunately, this still does not work. I'm on 1.8.0-alpha07 and when I use 0.9f from the original example it still snaps at 50%.

#21, are you using exactly the same code shared in #1?

Yes, I'm the OP.

sdkmanager "build-tools;build-tools-version"

Apologies #23, but I am not able to reproduce the issue with the sample from #1, running on Compose 1.8.0-alpha08. Can you please provide a full reproducer project as a zip? Thanks!

Okay I just played with the new BasicTextField... and it seems like this has been only half-fixed.

Inputting anything from the keyboard brings the cursor into focus, which is great. Adding new lines keeps the cursor in view, which is great.

However, tapping the text field (which opens the IME) in an area that will eventually be under the keyboard, does not scroll the cursor to stay in view.

My wacky workaround at the very beginning of this issue does that correctly, and not only for the keyboard, but for any size changes (my app has, in addition to system keyboard, an internal keyboard, and it works the exact same way). If the cursor is in view, I keep it in view no matter what. If the cursor has been scrolled out-of-view, then it's okay to bring it in view only once there's input from the user.

Is this behavior intended? I'm not 100% sure, but I believe that Android's EditText was keeping the cursor in view once the IME is shown.

I can make a video demonstration with all of these (New BasicTextField, legacy BasicTextField, my workaround, and EditText)

#comment28 If you're talking about the cursor not scrolling to stay on top of keyboard when it opens first, I agree, this is relevant here. I just noticed it myself as well.

In terms of the keyboard not showing at all the second time you click the text field, I think that's a different bug, and should be reported as its own issue with all the context of where and how that happens to you.

Also note that BasicTextField2 from 1.6.x releases is outdated, so make sure to use the new BasicTextField in 1.7.0 betas.

To comment #29 I believe you need to handle ime insets for that to work.

#comment31 Yes, I did apply the imePadding() Modifier on the BasicTextField, and it doesn't work even with it.

This isn't even IME-specific; any change in the TextField's size should try to keep the cursor in the viewport (if it was already visible before the size change).

imePadding does exactly just that: add padding, which in turn shrinks the size of the BasicTextField from the bottom. Currently, the new BasicTextField does not react to this at all, thus causing the cursor to stay under the keyboard.

My workaround (from #comment4) does this correctly, making sure that the cursor stays in view on size changes (only if the cursor was already in view, if not, do nothing because something else may have caused the size change).

It is still, however, a workaround (a wacky one to be clear, I'm not even sure I understand my own code, but it works flawlessly in production), and there's nothing than a proper upstream fix for everybody, that would be more performant and just less wacky.

#comment33 Again, the BasicTextField2 that's in Compose 1.6.x is outdated.

If you want to try the latest API, update to Compose 1.7.0-beta03 (which is the latest beta as of now), and use BasicTextField (which now uses the new implementation). This issue is mostly fixed in 1.7.

bringIntoViewRequester is irrelevant here, because we're talking about the internal scroll of the text field (especially in the case when it takes full screen space). It's not about scrolling some LazyList to keep the field in view, it's about scrolling the field itself to keep the cursor in view.

Again, if you update to 1.7.0 and still face the issue of the keyboard not opening the second time, that's a different issue, please report it separately.

#comment35 It's... partially fixed. I guess you still have to do Modifier.imePadding(), but the cursor will still come into view... once you type something.

However, since I still have to use the older BasicTextField sometimes because I need AnnotatedString, and because the current fix doesn't satisfy me, I just use a workaround for now, using BringIntoViewRequester. It's much simpler, cleaner and easier to understand than the abomination I wrote in #comment4, and is generally more flexible.

To keep the cursor in view on text changes (like the current fix), you need to add a bringIntoViewRequester to your BasicTextField, and then get use the TextLayoutResult from onTextLayout to get the bounding of the current cursor position, and call request bringIntoView using that Rect.

To complete the fix, you'll wanna store the TextLayoutResult in a state, and add a LaunchedEffect on TextFieldValue.selection/TextFieldState.selection changes, which does the exact same thing as before (calling bringIntoView with cursor rect).

Do the same on size changes (in Modifier.onPlaced), and you're fully set. The cursor will always be brought to view on size/selection/text changes, while still allowing users to scroll it away when none of these change, works well on desktop, and you can of course choose which triggers to keep.

You can also add some padding to the Rect you pass to bringIntoView, for example to keep some space between the line where the cursor is and the IME/bottom/top of screen.

I generally use this alongside a verticalScroll modifier to apply some internal non-clipping padding, but it should work fine without it, at least on the new BasicTextField.