IssueTracker

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.

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.

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.setWindowInsetsAnimationCallback to listen for when the keyboard stops animating and bring your text field into view using the BringIntoViewRequester API.