Fixed
Status Update
No update yet.
Comments
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit 9082f62682f853ad5251a1c79dde9eccba7abdd9
Author: Max Alfonso-Ying <maxying@google.com>
Date: Thu Apr 18 00:34:40 2024
[M2 text field] Apply background to decoration box
...instead of to the BasicTextField, so changing the
backgroundColor will properly change the decoration
box's background color.
Fixes:
Test: added unit tests
Relnote: "Fix backgroundColor not applying to
TextFieldDecorationBox and OutlinedTextFieldDecorationBox.
Decoration boxes now accept a `shape` parameter."
Change-Id: I371c26718597cb36ac537e9412ce476532afb40d
M compose/material/material/api/current.txt
M compose/material/material/api/restricted_current.txt
M compose/material/material/integration-tests/material-demos/src/main/java/androidx/compose/material/demos/TextFieldDecorationBoxDemos.kt
M compose/material/material/src/androidInstrumentedTest/kotlin/androidx/compose/material/textfield/TextFieldDecorationBoxTest.kt
M compose/material/material/src/commonMain/kotlin/androidx/compose/material/OutlinedTextField.kt
M compose/material/material/src/commonMain/kotlin/androidx/compose/material/TextField.kt
M compose/material/material/src/commonMain/kotlin/androidx/compose/material/TextFieldDefaults.kt
M compose/material/material/src/commonMain/kotlin/androidx/compose/material/TextFieldImpl.kt
https://android-review.googlesource.com/3046833
Branch: androidx-main
commit 9082f62682f853ad5251a1c79dde9eccba7abdd9
Author: Max Alfonso-Ying <maxying@google.com>
Date: Thu Apr 18 00:34:40 2024
[M2 text field] Apply background to decoration box
...instead of to the BasicTextField, so changing the
backgroundColor will properly change the decoration
box's background color.
Fixes:
Test: added unit tests
Relnote: "Fix backgroundColor not applying to
TextFieldDecorationBox and OutlinedTextFieldDecorationBox.
Decoration boxes now accept a `shape` parameter."
Change-Id: I371c26718597cb36ac537e9412ce476532afb40d
M compose/material/material/api/current.txt
M compose/material/material/api/restricted_current.txt
M compose/material/material/integration-tests/material-demos/src/main/java/androidx/compose/material/demos/TextFieldDecorationBoxDemos.kt
M compose/material/material/src/androidInstrumentedTest/kotlin/androidx/compose/material/textfield/TextFieldDecorationBoxTest.kt
M compose/material/material/src/commonMain/kotlin/androidx/compose/material/OutlinedTextField.kt
M compose/material/material/src/commonMain/kotlin/androidx/compose/material/TextField.kt
M compose/material/material/src/commonMain/kotlin/androidx/compose/material/TextFieldDefaults.kt
M compose/material/material/src/commonMain/kotlin/androidx/compose/material/TextFieldImpl.kt
pr...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.annotation:annotation-jvm:1.6.0-rc01androidx.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.