Fixed
Status Update
Comments
lp...@google.com <lp...@google.com> #2
Thanks! This looks like a bug, thank you for reporting!
nj...@google.com <nj...@google.com> #3
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 <ap...@google.com> #4
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
na...@google.com <na...@google.com> #5
Any estimate on when will this release?
Description
See: b/336270922
Currently Modifier.drawWithCache queries the current density and layout direction from
DelegatableNode#requireDensity
andDelegatableNode#requireLayoutDirection
. However, LayoutNode currently does not broadcast changes back to the modifier chain whenever the density or layout direction change. That leads to issues where Modifier.drawWithCache does not update based on the latest density/layout direction that was available.There is already prior art that special cases PointerInput modifiers to receive updates to density/layoutdirection changes and the fix for b/336270922 does the same for Modifier.drawWithCache. This is because at the time b/336270922 was addressed, API changes to add APIs to DelegatableNode are disallowed. So introduce a stopgap solution to fix the bug now and introduce a more holistic solution going forward.
Discussions with the wider team in the Modifier task force group lead to consensus that introducinghttps://chat.google.com/room/AAAAbSAVMlo/m_-HpV0vl1o
DelegateableNode#onLayoutDirectionChanged
andDelegatabelNode#onDensityChanged
would be a preferable longer term solution. See: