Fixed
Status Update
Comments
ap...@google.com <ap...@google.com> #2
Project: platform/frameworks/support
Branch: androidx-main
commit 89251b3129e1895f169dd8df404a420c5785519c
Author: Matvei Malkov <malkov@google.com>
Date: Tue Feb 09 17:35:30 2021
Support enabled parameter is slider and convert it to use SliderColor interface instead.
Slider has enabled/disabled states per spec and we need to support it for component to be stable.
Also, since we add even more color parameters, it is time to convert it to use SliderColors interface.
Fixes: 179793072
Test: added screenshot tests and a11y test for disabled
Change-Id: I6d56b992042f54b63daf4936ef6f6c27319b0498
Relnote: Slider now supports enabled/disabled state
Relnote: Slider custom colors are available now via SliderDefaults.colors() function
M compose/material/material/api/current.txt
M compose/material/material/api/public_plus_experimental_current.txt
M compose/material/material/api/restricted_current.txt
M compose/material/material/samples/src/main/java/androidx/compose/material/samples/SliderSample.kt
M compose/material/material/src/androidAndroidTest/kotlin/androidx/compose/material/SliderScreenshotTest.kt
M compose/material/material/src/androidAndroidTest/kotlin/androidx/compose/material/SliderTest.kt
M compose/material/material/src/commonMain/kotlin/androidx/compose/material/Slider.kt
https://android-review.googlesource.com/1581663
Branch: androidx-main
commit 89251b3129e1895f169dd8df404a420c5785519c
Author: Matvei Malkov <malkov@google.com>
Date: Tue Feb 09 17:35:30 2021
Support enabled parameter is slider and convert it to use SliderColor interface instead.
Slider has enabled/disabled states per spec and we need to support it for component to be stable.
Also, since we add even more color parameters, it is time to convert it to use SliderColors interface.
Fixes: 179793072
Test: added screenshot tests and a11y test for disabled
Change-Id: I6d56b992042f54b63daf4936ef6f6c27319b0498
Relnote: Slider now supports enabled/disabled state
Relnote: Slider custom colors are available now via SliderDefaults.colors() function
M compose/material/material/api/current.txt
M compose/material/material/api/public_plus_experimental_current.txt
M compose/material/material/api/restricted_current.txt
M compose/material/material/samples/src/main/java/androidx/compose/material/samples/SliderSample.kt
M compose/material/material/src/androidAndroidTest/kotlin/androidx/compose/material/SliderScreenshotTest.kt
M compose/material/material/src/androidAndroidTest/kotlin/androidx/compose/material/SliderTest.kt
M compose/material/material/src/commonMain/kotlin/androidx/compose/material/Slider.kt
pr...@google.com <pr...@google.com> #3
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.annotation:annotation-jvm:1.6.0-rc01
androidx.compose.material:material:1.4.0-beta01
Description
If you drag pull refresh, and release / fling downwards with some velocity, overscroll will show on top of the pull refresh animation.
Previously scrollable used to check if overscroll should dispatch (if the list can scroll in either direction) before dispatching preFling and dispatching postFling - sincehttps://android-review.googlesource.com/c/platform/frameworks/support/+/2384227 we now only check before the overall pass, so if preFling / the scrolling fling causes this to change (such as causing the list to refresh and now have no items) then the behaviour change is we now will dispatch postFling to overscroll, and show overscroll because pullRefresh did not consume.
Separately we might want to consider adding that check again and consuming all the velocity before we return from the lambda if the list can no longer scroll (but still calling it for correctness, so overscroll can clean up - before we might only call preFling and then never postFling), but the proper fix for pull refresh is to consume positive velocity if pull refresh is showing.
Theoretically in the future we may want to consider also consuming delta / velocity while pull refresh is showing, but at least for now it makes more sense to remain consistent with SwipeRefreshLayout, which does not do this.