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

[AppBarLayout] Scrolling under keyboard doesn't work with fitSystemWindows=true

Open
#2,097 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

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

Description

Building off of the issue described here which is still unresolved: https://issuetracker.google.com/issues/114009783

**Description:**
With `fitsSystemWindows=true` on `AppBarLayout` and a `NestedScrollView`, the `NestedScrollView` doesn't scroll appropriately when the keyboard is showing and the Activity has `windowSoftInputMode="adjustResize"`. The keyboard's visibility does not affect how much the view scrolls, so when the keyboard is showing, there is content that's hidden by it and unable to be scrolled above it.

**Expected behavior:** Expected behavior is that when the keyboard is visible, all content that would be behind the keyboard when it is shown, is able to be scrolled above it. This is achievable by setting `fitsSystemWindows=false` on the `AppBarLayout`

**Source code:** [coordinator-scroll-issue copy.zip](https://github.com/material-components/material-components-android/files/6032954/coordinator-scroll-issue.copy.zip)

**Android API version:** 30

**Material Library version:** 1.3.0

**Device:** Pixel 2 emulator

Looking into the source, I believe I've traced the issue to the following block at `HeaderScrollingViewBehavior:72`

```
if (ViewCompat.getFitsSystemWindows(header)) {
final WindowInsetsCompat parentInsets = parent.getLastWindowInsets();
if (parentInsets != null) {
availableHeight += parentInsets.getSystemWindowInsetTop()
+ parentInsets.getSystemWindowInsetBottom();
}
}
```
Looks like `getSystemWindowInsetBottom()` will return the height of the keyboard, so when that's added to `availableHeight` and passed to layout the `NestedScrollView` it's as if the keyboard isn't showing. I was going to open a PR, but I'm having trouble getting the instrumentation tests to run locally, depending on timing here, I may end up opening it eventually.

My other concern is that it's unclear to me what the intention of adding those insets to the available height originally was. I see @chrisbanes commit message:
`Another issue is with HeaderScrollingViewBehavior. To workaround CoordinatorLayout using its 'compatible measuring' for insets, the behavior manually sets the scrolling view to fit system windows. This has other issues though because that view will get padded in. Fixed by manually adding the insets back into the measured dimensions.`
Which describes the view being padded in as a problem, however to me it seems like that's what we need to happen in this case, and I'm not sure I fully appreciate the issues caused by padding in the scrolling view.

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

Start with HeaderScrollingViewBehavior around line 72 and reproduce the attached coordinator-scroll issue copy.zip on API 30 with Material 1.3.0, adjustResize, fitsSystemWindows=true, and a NestedScrollView. Compare scrolling with the keyboard visible and verify that content hidden by the keyboard can be scrolled above it; add or run instrumentation coverage for the corrected behavior.

Written by the indexing model from the issue text.

Assessment

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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.