material-components / material-components/material-components-android

[FloatingActionButton / Snackbar] FAB triggering Snackbar resets color of Toolbar and repositions FAB

Open
#3,508 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug Widget: Snackbar
Dominant language
Java
Stars
17.4k
Forks
3.2k
PR merge metrics
No merged PRs in 30d

Description

**Description:**
I'm getting started with edge-to-edge. Having some issues implementing it I came back to the basics i.e. the android studio templates. Using the "Basic Views Activity" I noticed a wired behavior:

Starting with the fresh project template, applying `WindowCompat.setDecorFitsSystemWindows(window, false)` like mentioned in the [guide](https://developer.android.com/develop/ui/views/layout/edge-to-edge#lay-out-in-full-screen) leads to the `FloatingActionButton` being initially layed out over the navigation bar (in contrast to the `NestedScrollView` text content).

![Over](https://github.com/material-components/material-components-android/assets/72392544/8d9eec94-3446-4d46-8ad5-35227f577854)

Scrolling down, the `AppBarLayout` / `Toolbar` changes its color, like expected (hard to see in the picture, should have changed the color):

![Over_appbar_colored](https://github.com/material-components/material-components-android/assets/72392544/d568ffc1-8fcd-48a0-84ff-6fa76d973956)

Now, in the scrolled state, clicking the `FloatingActionButton` brings the `Snackbar` into view. Now the color resets back to white and once the `Snackbar` disappears the `FloatingActionButton` doesn't reposition to its starting position but "falls" through, behind the navigation bar. Scrolling brings back the color though.

![Under_appbar_white](https://github.com/material-components/material-components-android/assets/72392544/6a92c667-8bcb-4890-9c95-9e505df4bd9d)

**Expected behavior:**
I know setting `WindowCompat.setDecorFitsSystemWindows(window, false)` is only the start of getting edge-to-edge but from reading the rest of the guide (and trying to implement with varying degrees of success) the expected behavior would be that at this point, the `FloatingActionButton` should start already behind the navigation bar (where it falls to once clicked).

Furthermore the color of the `AppBarLayout` / `Toolbar` shouldn't reset imho?!

**Source code:**

In template `MainActivity`
```kotlin
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
WindowCompat.setDecorFitsSystemWindows(window,false)

// ...
}
```

**Minimal sample app repro:**
Android Studio Giraffe | 2022.3.1 -> "Basic Views Activity"

**Android API version:**
30

**Material Library version:**
1.9.0

**Device:**
AVD Pixel 6

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the behavior in the Android Studio Giraffe Basic Views Activity sample using the MainActivity WindowCompat.setDecorFitsSystemWindows call, on API 30 with Material Library 1.9.0. Trace the FAB, Snackbar, AppBarLayout, and Toolbar behavior during scrolling and Snackbar dismissal; done means the expected edge-to-edge positioning and toolbar color persist without the reported reset or repositioning.

Written by the indexing model from the issue text.

Assessment

Tech stack
android, kotlin
Domain
mobile
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.