Fixed
Status Update
No update yet.
Comments
ma...@google.com
kl...@google.com
kl...@google.com
Thanks! This looks like a bug, thank you for reporting!
kl...@google.com
I would also recommend setting the value to 10%. When you do that, the behavior is wild.
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.
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.
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
Author: Jossi Wolf <
Link:
Update AnchoredDraggable target calculation logic
Expand for full commit details
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
Files:
- M
compose/foundation/foundation/src/androidInstrumentedTest/kotlin/androidx/compose/foundation/anchoredDraggable/AnchoredDraggableStateTest.kt - D
compose/foundation/foundation/src/androidInstrumentedTest/kotlin/androidx/compose/foundation/anchoredDraggable/AnchoredDraggableTestState.kt - M
compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/AnchoredDraggable.kt
Hash: eff53304942e9fd4fa5382e0cf487a734c5b8d28
Date: Thu Sep 19 16:24:55 2024
Description
If two requests are made concurrently on the same BringIntoViewRequester, if the responder is using standard animation APIs (like scrollable is) then the last request to be processed will cancel all the animations for the other requests.
This currently happens when text fields gain focus. Consider a text field with a large decoration box (eg a material text field). The focusable first gets the focus event and makes a request to bring the entire decoration box into view. Then the text field gets the focus event and makes a request to bring the cursor area into view. The cursor area is always inside the decoration box. If the cursor area is already in view, that second request noops and the first request completes, bringing the entire decoration box into view. However, if the cursor area started off hidden (as is common, eg if the entire text field would be covered by the newly shown keyboard), then the second request cancels the first and only the cursor area is brought into view, which means part of the decoration box will stay clipped.
I think the solution is that the bring into view responder should detect when a request comes in while a previous request is still being processed, somehow calculate the merge of the two requests, and only cancel the animation if it needs to adjust it to handle the merge result.
The merge algorithm might look something like this:
In particular, in the case where the entire text field can fit in the responder, this algorithm would always prioritize requests for bringing the entire text field into view over requests to bring the cursor into view.
This logic must happen at each responder node. Because text fields contain their own scrollable below the focusable, even if the cursor request will be ignore by a scrollable much higher up in the tree, the text field's own scrollable still needs to process it.