SearchBar inside Scaffold pushes/pulls UI elements below it upon expansion/contraction [350916229]

Fixed

Bug

Status Update

No update yet.

Description

dr...@gmail.com

created issue #1

Jul 4, 2024 07:08AM

Jetpack Compose version: BOM 2024.06.00

Material Library Version (M2, M3 or Both?): M3

Material Compose component used: SearchBar

Android Studio Build: 2024.1.1

Kotlin version: 2.0.0

Steps to Reproduce or Code Sample to Reproduce:

Put a SearchBar as topBar and a LazyColumn of items as content into a Scaffold.
Run the app and click on the SearchBar.
Notice that the expand animation of SearchBar pushes content below away instead of overlaying above it, and closing it pulls back the content below.
This is a result of SearchBar increasing its layout height in-place, which means the content will be given less height during measurement.

This can be seen in blog posts about how to use SearchBar as well, e.g. https://medium.com/@shivathapaa/custom-topappbar-using-android-jetpack-compose-f9b33388a125 (disclaimer: I'm not the author of it) has a GIF recording which shows this problem if one observe carefully.

This isn't a problem in Compose Material Catalog SearchBarSamples because the sample is using a Box and a fixed top padding for the list. However, that doesn't work in most real world scenarios e.g. when people need to use Scaffold.

I think the material-components-android approach for SearchBar, which is to offer SearchBar and SearchView separately, is more flexible and will make it possible to handle layout (and window insets） correctly under all scenarios.

Stack trace (if applicable): N/A

Comments

ke...@google.com <ke...@google.com> Jul 10, 2024 11:06PM

Reassigned to ma...@google.com.

ma...@google.com <ma...@google.com> Aug 13, 2024 05:37PM

Accepted by ma...@google.com.

ap...@google.com <ap...@google.com> #2Jan 29, 2025 07:08PM

Can you rise priority please?
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?

ma...@google.com <ma...@google.com> #3Feb 6, 2025 04:14PM

Marked as fixed.

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.

pr...@google.com <pr...@google.com> #4Feb 12, 2025 06:40PM

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.

Issue 350916229