when replying to a toot, input is hidden by keyboard about pinafore HOT 7 CLOSED

We could try the same trick as in mastodon/mastodon#4282 (hide the top bar when the input has focus).

from pinafore.

It seems like on iOS anyway, the browser is able to intelligently hide the nav bar when the keyboard is open:

So this appears to be a Chrome on Android issue, at least as currently implemented.

Since Chrome on Android also changed the window height when the keyboard pops up, we could just use some CSS rules to hide the nav bar when the height is below a certain threshold.

from pinafore.

Some widths and heights in Chrome:

Nexus 5

• landscape, keyboard open: 592, 80
• landscape, keyboard closed: 592, 280
• portrait, keyboard open: 360, 263
• portrait, keyboard closed: 360, 512

OnePlus 5T

• landscape, keyboard open: 775, 146
• landscape, keyboard closed: 775, 332
• portrait, keyboard open: 412, 440
• portrait, keyboard closed: 412, 695

from pinafore.

I tried to make some progress on this (dbd6fab). But I ran into several problems:

1. iOS Safari behaves differently from Android Firefox and Chrome, as described above. It autohides the nav (good) but doesn't report the height changes (bad)
2. The transition animation looks jerky on Firefox, even with transform: translate
3. It's not possible to determine when the soft keyboard is open, so you have to infer using media queries
4. It's not possible to use (orientation: landscape) or (orientation: portrait), because the definition of landscape/portrait changes when the keyboard opens and closes (since it's defined as the ratio between the width and the height)

I could try to solve these problems as in the Mastodon codebase by also listening for focus events on the textarea, but that just adds more moving parts, and I'm worried this is already getting complicated enough and very risky, since I don't own every device on the planet and thus can't anticipate what kind of screen/keyboard combinations there are out there. (Even different soft keyboards have different heights.)

I'm tempted to just call this wontfix. iOS Safari at least demonstrates that it's possible for browser vendors to fix this themselves.

from pinafore.

Also even on a Nexus 5 (just about the smallest Android device I can think of), and even when not installed as a PWA (i.e. the URL bar is there), the keyboard takes up space, but it's far from unusable:

from pinafore.

Closing as wontfix; I just think that the risk this introduces is not worth the payoff of gaining ~70px of extra height by hiding the nav bar. If there is a better solution I'm not aware of, please let me know.

from pinafore.

i think there was some JS behavior change or browser behavior change that fixed this on my device, it was a lot lot worse before

from pinafore.