Assigned
Status Update
Comments
kl...@google.com <kl...@google.com>
ap...@google.com <ap...@google.com> #2
Thanks! This looks like a bug, thank you for reporting!
kl...@google.com <kl...@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
Description
When there are multiple focus modifiers (e.g.
onFocusChanged
) on a focus target, and all the modifiers are removed along with the target, only the lowest (closest to the target) modifier gets the event. I believe this is a regression introduced with the migration of the focus system to modifier locals, for a case that it seems we never had tests for.The situation is when there are multiple focus event modifiers listening to a single focus target, and all the event modifiers as well as the target are removed/detached at the same time. What should happen, I think, and based on talking to @Ralston Da Silva, is that all the event modifiers should get the final "focus=Inactive" event. But what is happening is:
onModifierLocalsUpdated
call first, in which they all remove themselves from the listener chain.onModifierLocalUpdated
, in which it asks the focus manager to clear focus.focusable()
.I believe this regression caused a text field bug, b/225541817 , in which the focus event modifiers applied by
CoreTextField
no longer receive that final "focus=Inactive" event and so don't hide the keyboard.Reproducing test: