Keyboard overlaps app

[frederikheld]

Describe the bug

See screenshots.

Left: app without keyboard as reference. App bar aligned with bottom of the viewport plus safe area inset bottom.

Right: open keyboard overlaps app for an amount of pixels that seems to match the safe area inset bottom (see red boxes).

I've tested this with the current alpha-8, but it's most probably a regression from PR #31.

[tafelnl]

I'm not able to reproduce this. Also it seems weird if #31 would actually cause this. The only thing that that PR takes care of, is making sure that the value won't be less than zero. You could easily test and verify if that's really the case for you by removing the coerceAtLeast(0) part from within Android Studio

[frederikheld]

So maybe I had my own fix in place that now causes the overlap. I'll look into it.

But I don't seem to be the only one with the issue: #31 (comment)

[frederikheld]

I can't see any issue on my side. The last version that works properly for me is alpha.5. All other versions have issues with either too much or too little safe area inset bottom.

But one thing I noticed with all versions: when I open the keyboard, the bottom bar jumps up for "keyboard height + safe area inset bottom" pixels and a brief moment later jumps back to "keyboard height" (which it should be because the keyboard already covers the bottom bar). The same happens the other way round when closing the keyboard.

I assume this happens because "safe area inset bottom" takes a noticeable amount of time to be updated updated.

EDIT: in alpha.8, this behavior means, that the app bar jumps up "keyboard height" pixels but then jumps back to "keyboard height - safe are inset bottom" (as showed in the screenshots). Other from that, I feel no difference between .5 and .8 (they are both very slow in updating the values).

[JanPolasek]

@frederikheld I've come cross what I believe is the same issue, but on my end I was able to fix it by setting resizeOnFullScreen in my capacitor Keyboard plugin config

The description of the bug this property is working around seems to match what's happening here, so maybe it'll work in your case as well?

EDIT: Oh, wait, what I didn't notice at first is that now it overcompensates and there's a bunch of extra margin

[frederikheld]

Yeah, this is exactly the path I went down as well 😄 There's something broken in this plugin for sure.

[JanPolasek]

The reason why it worked in alpha.5 is this commit in alpha.6 acfaa0c
Without resizeOnFullScreen IME height already includes the navbar height, so just imeHeight = imeInsets.bottom works (at least on my devices and emulators)

With resizeOnFullScreen things get a little weird. The view is resized by the Keyboard plugin in a way which doesn't affect the insets that this plugin receives, but it affects the paddings it sets, so not only is it not necessary to subtract navbar height from IME height, it is necessary to add it instead. Not quite sure how all of that works, I don't know much about Android development and Views and FrameLayouts and such.

I guess if this plugin wanted to support both options it would either need to read the Keyboard plugin's settings, which doesn't sound like a great solution, or somehow find out whether the Keyboard plugin did some resizing and account for that (and I'm not even sure how to go about that)
Alternatively, this plugin could just document that resizeOnFullScreen shouldn't be used along with this plugin. Even if it didn't break things, I don't think it would do anything useful either.

But in both cases there's one more unfortunate bug and that is that custom navbar colours get pushed up

While experimenting with that I just set the background to fully transparent when imeInsets.bottom > 0 && systemBarsInsets.bottom > 0 (and back when it's no longer the case) which did work and accounts for landscape mode as well, but that doesn't sound like an amazing solution either, there's gotta be a way to hide it correctly or make sure it doesn't get pushed up by the decor view paddings, I just don't know how (yet at least)

EDIT: Now I know of at least one way - instead of adding padding to the decor view, which includes the system bars, it's possible to apply it to the content (incidentally the same view that the capacitor Keyboard plugin resizes when it's set to do that)
activity.window.decorView.findViewById<FrameLayout>(android.R.id.content).getChildAt(0).setPadding(0, 0, 0, imeInsets.bottom)

[datawaslost]

PR looks good, looking forward to it being reviewed and merged into a new version