Status Update
Comments
ma...@google.com <ma...@google.com> #2
Triage notes: Assigning for a response.
na...@gmail.com <na...@gmail.com> #3
When updating the providers, startProvider()
is comparing the new scope produces with the previous scope produced, instead of the current parent scope, to determine if the content of the provider needs to change, ignoring if the parent changed. That has the effect of, if a provider provides a value that is identical to the parent value, the composer thinks that none of the the static composition locals changed and it doesn't need to force updates of the content of the provider.
The temporary work-around for this is to use a compositionLocalOf
instead. Using compositionLocalOf
is recommended for composition locals that can change and static should are not recommended for values that can change.
However, in the above example, LocalOtherValue
only changes once so using a staticCompositionLocal
is recommended as it avoids the overhead for tracking reads of a value that rarely changes, making this work-around temporary for LocalOtherValue
or similar locals.
an...@google.com <an...@google.com> #5
This issue also affects Material theming changes because they use staticCompositionLocalOf
under the hood. And those cannot be changed by a work-around.
je...@google.com <je...@google.com> #6
Project: platform/frameworks/support
Branch: androidx-main
Author: Chuck Jazdzewski <
Link:
Fixed providesDefault
for a single provide
Expand for full commit details
Fixed `providesDefault` for a single provide
If `providesDefault` is used as the sole provided value
of a `CompostionLocalProvider` then the content of the
provider may not update if a parent changes the value
of a static composition local. Providing more than
one value does not have this issue.
Fixes: 374263387
Test: new test, ./gradlew :compose:r:r:test
Change-Id: Iabd4fbba6191abad4073ab5f302d252750683258
Files:
- M
compose/runtime/runtime/src/commonMain/kotlin/androidx/compose/runtime/Composer.kt
- M
compose/runtime/runtime/src/nonEmulatorCommonTest/kotlin/androidx/compose/runtime/CompositionLocalTests.kt
Hash: b70a4268ba4985d4a5baf9c14edd81290d2ded1d
Date: Thu Oct 24 17:16:39 2024
ap...@google.com <ap...@google.com> #7
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.runtime:runtime:1.8.0-alpha06
androidx.compose.runtime:runtime-android:1.8.0-alpha06
androidx.compose.runtime:runtime-jvmstubs:1.8.0-alpha06
androidx.compose.runtime:runtime-linuxx64stubs:1.8.0-alpha06
ap...@google.com <ap...@google.com> #8
Branch: androidx-main
commit 59dca3bb1906b988bcc55a2bc44f93063e87a48f
Author: Jelle Fresen <jellefresen@google.com>
Date: Thu Apr 08 16:20:32 2021
Add scroll to matcher action for LazyLists in tests
Adds an action to SemanticsNodeInteraction to scroll to content in a
LazyList identified by a SemanticsMatcher. Adds a filter as well to find
nodes that support this scroll action.
Fix: 161584524
Fix: 182259407
Fix: 182260995
Test: Added ScrollToNodeTest
Relnote: "Added `performScrollToNode(matcher: SemanticsMatcher)` that
scrolls a scrollable container to the content that is matched by the
given matcher."
Change-Id: Ic1cb855e351c7bb683962d618d68782628b70f62
M compose/ui/ui-test/src/commonMain/kotlin/androidx/compose/ui/test/Actions.kt
M compose/ui/ui-test/api/current.txt
M compose/ui/ui-test/api/public_plus_experimental_current.txt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/lazy/LazyListState.kt
A compose/ui/ui-test/src/androidAndroidTest/kotlin/androidx/compose/ui/test/actions/ScrollToNodeTest.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/lazy/LazySemantics.kt
M compose/ui/ui-test/src/commonMain/kotlin/androidx/compose/ui/test/Filters.kt
M compose/ui/ui-test/api/restricted_current.txt
Description
It would be very useful if the ScrollerPosition class had one or multiple methods for scrolling to a specific element index instead of a position in pixels. The current API forces developers to do the calculate the height of each element themselves and figure out at which pixel location the desired element is from that.