Status Update
No update yet.
Comments
ia...@gmail.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?
il...@google.com
il...@google.com
il...@google.com
mg...@google.com
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.
ap...@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.
pr...@google.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.
Description
Component used:
androidx.lifecycle:lifecycle-viewmodel-ktxVersion used:
2.5.1Devices/Android versions reproduced on: n/a
Given the new APIs for adding closables to view models,
viewModelScopeshould probably be marked as discouraged or deprecated in order to promote testability.