material-components / material-components/material-components-android
[AppBarLayout] Scrolling under keyboard doesn't work with fitSystemWindows=true
Nobody has claimed this yet.
- 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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