Status Update
No update yet.
Comments
il...@google.com
It's a real stopper to use in not helloworld apps.
It must be joke, define it as "An issue that should be addressed eventually. Such an issue is not relevant to core organizational functions or the work of other teams, or else it relates only to the attractiveness or pleasantness of the system."
Why use compose in production, if this base things resolved for years?
ap...@google.com
This is high priority for us. The "Priority" field on buganizer is misleading, it has a very specific internal meaning and interaction with other systems so we don't use it for actual prioritization for compose text issues. Unfortunately, the way we track actual priority is not visible externally.
il...@google.com
Does this work as expected for you with Views? I was able to reproduce this bug with views as well – an EditText inside a ScrollView will not cause the view to scroll to keep the EditText in view if the keyboard covers it.
tf...@gmail.com
We've been taking a closer look at this bug and considered alternatives to fixing it, which require larger changes to the Compose keyboard controller and BringIntoView APIs.
Unfortunately since Compose 1.2 is already in beta, the API is effectively frozen. We could explore more hacky ways to fix it in 1.2, but considering this behaviour matches what happens with Views, we decided it was better to fix properly with more time as opposed to fix it with a hack, increasing the tech debt and potentially creating other bugs.
As a workaround, either don't call setDecorFitsSystemWindows(false) for now, or if you do, use ViewCompat.setWindowInsetsAnimationCallbackBringIntoViewRequester API.
il...@google.com
Branch: androidx-main
commit d15475fecc931bf1044888b10eddd1a13db2e64c
Author: Zach Klippenstein <klippenstein@google.com>
Date: Mon May 23 15:17:11 2022
Improve WindowInsets.ime kdoc to include API 23.
The WindowInsets.ime value is actually supported on API 23+,
so I updated the kdoc to say that. However, it's only *animated* on 30+,
so I clarified that in the kdoc as well.
This change also adds a demo to the demo app that shows the actual
insets.
Bug:
Test: n/a, only a docs change
Relnote: "Clarified the documentation for `WindowInsets.ime` to state
that `ime` insets are reported as far back as API 23, but only
_animated_ on 30+."
Change-Id: Ia7fc002bde64074be7a176121483bff3017f24a8
A compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/WindowInsetsDemo.kt
M compose/foundation/foundation-layout/src/androidMain/kotlin/androidx/compose/foundation/layout/WindowInsets.android.kt
M compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/FoundationDemos.kt
b9...@gmail.com
I'm trying the workaround, but the ViewCompat.setWindowInsetsAnimationCallback is already set on the Compose side.
Is it okay to overwrite this?
il...@google.com
I realized that overwriting setWindowInsetsAnimationCallback disables ime animation on all screens when using navigation-compose.
Below code is the workaround I tried.
var text by remember { mutableStateOf("") }
val view = LocalView.current
val bringIntoViewRequester = remember { BringIntoViewRequester() }
val coroutineScope = rememberCoroutineScope()
// Workaround: Call it first to overwrite the setWindowInsetsAnimationCallback set by Compose.
WindowInsets.ime
DisposableEffect(view) {
ViewCompat.setWindowInsetsAnimationCallback(
view,
object : WindowInsetsAnimationCompat.Callback(DISPATCH_MODE_STOP) {
override fun onProgress(
insets: WindowInsetsCompat,
runningAnimations: MutableList<WindowInsetsAnimationCompat>
): WindowInsetsCompat {
return WindowInsetsCompat.CONSUMED
}
override fun onEnd(animation: WindowInsetsAnimationCompat) {
val isImeVisible =
WindowInsetsCompat.toWindowInsetsCompat(view.rootWindowInsets)
.isVisible(WindowInsetsCompat.Type.ime())
if (isImeVisible) {
coroutineScope.launch {
bringIntoViewRequester.bringIntoView()
}
}
}
}
)
onDispose {
ViewCompat.setWindowInsetsAnimationCallback(view, null)
}
}
Column(
modifier = Modifier
.fillMaxSize()
.imePadding()
.verticalScroll(rememberScrollState())
) {
// ...
TextField(
value = text,
onValueChange = { text = it },
modifier = Modifier
.bringIntoViewRequester(bringIntoViewRequester)
)
}
It may be enough to just disable the setWindowInsetsAnimationCallback set by Compose.
val view = LocalView.current
// Workaround: Call it first to overwrite the setWindowInsetsAnimationCallback set by Compose.
WindowInsets.ime
LaunchedEffect(Unit) {
ViewCompat.setWindowInsetsAnimationCallback(view, null)
}
il...@google.com
Branch: androidx-main
commit 787a2f8056da406e0631a6c27b3ea67252e05f46
Author: Zach Klippenstein <klippenstein@google.com>
Date: Thu Jun 23 15:15:48 2022
Update ScrollState's maxValue in measure, not place.
The old behavior, setting maxValue in the placement pass, prevented
Modifier.scrollable from dispatching scroll events in onRemeasured,
which is called after the measurement pass but before placement.
Test: ./gradlew :compose:f:f:cDAT
Bug:
Change-Id: I68ad542100438c8a6b4430827f28c2ccbfa6a037
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/Scroll.kt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/ScrollTest.kt
b9...@gmail.com
Branch: androidx-main
commit cb90e2addc50ff6f4e7f48df0dc0a03343898ccb
Author: Zach Klippenstein <klippenstein@google.com>
Date: Wed Jun 15 12:13:03 2022
Fix scrollable focused child tracking.
When calculating whether we need to scroll to keep the focused child
in-view after the scrollable viewport is resized, we were using the
bounds of the focused child to figure out if it was previously visible.
That was incorrect, because if the viewport is animating while the
scroll animation is running, it's possible for the viewport to shrink
fast enough that the focused child isn't actually visible, but would
have eventually became visible after the animation, so we need to
continue to animate.
This approach is documented as Option 0 in the design doc:
Note that while this fixes
end up in the correct final state, it makes
since it looks like the scroll animation doesn't start at all until the
viewport animation stops.
Fixes:
Test: Manually using the 'Foundation > Scrollable with focused child"
and "Text > Input fields > Inside scrollable" demos."
Test: ./gradlew :compose:f:f:cDAT
Relnote: "When a scrollable has a focused child, it will now correctly
scroll to keep the focused child in view when its size is decreased,
even when the size is animated."
Change-Id: I8086717b14174e566b299f2643f1dd6c0b250773
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/ScrollableFocusableInteractionTest.kt
M compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/ScrollableFocusedChildDemo.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/Scrollable.kt
Description
Component used:
lifecycle-viewmodel-ktxVersion used: 2.3.0
Devices/Android versions reproduced on: Pixel 4 running Android 10
Sample project to trigger the issue:https://github.com/tfcporciuncula/view-tree-owner-bug
You can repro the issue by cloning that repo, running it, and then rotating the screen causing a config change.
This is the code I'm using to create a
ViewModelin aView(as you can seeEverything works fine, but the app crashes on orientation change with the following stacktrace:
The crash has a pretty clear cause which is
So it seems there's this implicit requirement of having the
SavedStateRegistryOwneralso be aViewModelStoreOwner, and that's not the case for the view when it's in a fragment: itsSavedStateRegistryOwneris aFragmentViewLifecycleOwnerSavedStateRegistryOwnerand not aViewModelStoreOwner.It feels like
findViewTreeSavedStateRegistryOwner()should return the fragment itself (likefindViewTreeSavedStateRegistryOwner()) instead of theFragmentViewLifecycleOwner, so this would work. Or am I doing something wrong here?If the view is in an activity everything works fine --
findViewTreeSavedStateRegistryOwner()returns the activity in this case, which is also aViewModelStoreOwnerso everything is good.