Bug 230225 – Implement the VirtualKeyboard API

• Component: New Bugs
• Status: NEW

[Bramus]

> The VirtualKeyboard API provides authors with greater control over the visibility of the virtual keyboard (VK), and greater ability to adapt the layout of web pages when VK visibility changes.

Relevant Links:

- Explainer: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/VirtualKeyboardAPI/explainer.md
- Spec: https://www.w3.org/TR/virtual-keyboard/

[Bramus]

Other Browsers/Engines:

- Chromium: https://www.chromestatus.com/feature/5680057076940800 (Shipping with Chromium 94)
- Gecko/Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1730568

[Radar WebKit Bug Importer]

<rdar://problem/83154723>

[Kevin Neal]

Thank you for filing. The appropriate engineers have been notified.

[N]

Hello,

Any update on this?

It's very hard (if possible at all) to control whether the Keyboard hides the bottom contents of the screen, which is different from the behavior of the other browsers on Android.

Chrome v108 allows to control this via viewport meta - https://developer.chrome.com/blog/viewport-resize-behavior/

which gives more flexibility to devs.

Would be nice to see Safari implementing any kind of flexibility, as at the moment we have none.

Thanks

[Alex 23]

Adding a vote that this is an important iOS Safari enhancement for many web developers, and working well on Chrome/Android.

[John Crim]

I would love to see the VirtualKeyboard API implemented in Safari/iOS browsers, but at a minimum we need a way to control the viewport when the On Screen keyboard appears. 

The Safari viewport is always full-screen, even when the On Screen keyboard displays, as described here:
https://developer.chrome.com/blog/viewport-resize-behavior/ 

Chrome/Android supports `interactive-widget=resizes-content` in the meta viewport tag, which has the desired behavior of shrinking the viewport to what is visible.

The Safari behavior means that any dialog that is shown has the full screen height, and can't be constrained to the part of the screen that is visible above the keyboard - the area behind the keyboard always exists, even if it's not needed.

Imagine a short dialog - on Safari you can still scroll to the bottom of the full screen height, and there is no way to reduce the scroll height below a full screen. 

On Chrome/Android with `viewport interactive-widget=resizes-content`, the short dialog is all that is displayed. If the dialog is taller than the visual viewport, it can be scrolled to the bottom, but there is no additional space below the page content. I can provide a video of this issue if my description is lacking.

With some hacks, you can currently detect when the On Screen Keyboard is shown (`visualViewport.resize` event, plus input or textarea is focused). We currently don't use the VirtualKeyboard API to detect this even though it would be a better way, b/c it wouldn't work on Safari. 

Even with On Screen Keyboard detection solved, there is no way to control the max viewport height on Safari.

[Fred Rivett]

Totally appreciate there's always more in the backlog than can be done, just adding my vote in for this one to be prioritised.

I've just spent 3 days banging my head against this desperately trying to find a way to simply put a div at the bottom of the screen regardless of whether the virtual keyboard is open. In the end we've implemented a very hacky solution that *seems* to work, and I can rest a little easier this weekend.

I feel like it's a relatively common requirement and as such many devs will be losing time (and sleep) over this, so it would be great if safari (& FF) could bridge the gap as the only two major browsers holding developers back from using this feature.

Thanks folks,
Fred.

[Mahmood Sagharjooghi]

After a day of trying to position an input element to the bottom of the screen regardless of virtual keyboard being open or not, I find myself in this bug report. Please prioritize this. It not working on IOS is a truly a headage for many.

[Mahmood Sagharjooghi]

(In reply to Fred Rivett from comment #7)
> Totally appreciate there's always more in the backlog than can be done, just
> adding my vote in for this one to be prioritised.
> 
> I've just spent 3 days banging my head against this desperately trying to
> find a way to simply put a div at the bottom of the screen regardless of
> whether the virtual keyboard is open. In the end we've implemented a very
> hacky solution that *seems* to work, and I can rest a little easier this
> weekend.
> 
> I feel like it's a relatively common requirement and as such many devs will
> be losing time (and sleep) over this, so it would be great if safari (& FF)
> could bridge the gap as the only two major browsers holding developers back
> from using this feature.
> 
> Thanks folks,
> Fred.

Hi Fred!
Can you share the solution? It'll be much appreciated 🙏

Id like to throw my vote in to prioritize this as well for ios. (works well on android chrome) 

navigator.virtualKeyboard is desperately needed to help us developers meet user expectations. 

the visualViewport or measuring the client in any current manner is completely inadequate at detecting the visibity of the keyboard,  as the keyboard visibity does not necesasrily trigger the changes to the viewport siize.  Take for example the case where an input exists at the top of the screen with enough padding to allow the keyboard to open.  in that case there is no way that i can find to understand if the keyboard has been shown or hidden.  

I agree in general with other comments that we should be able to have more control over the visualViewport and how it responds to the keyboard,but i know fromo my own development that simply reliable detcting the keyboard would be a huge benefit in it's own right.  

Thanks,
Brian

I also would love to see development of this. 

For a potential workaround in the meantime, see https://stackoverflow.com/a/71547560/4185989 for VisualViewport use (ref https://developer.mozilla.org/en-US/docs/Web/API/VisualViewport)

[Offickind1939]

Thank you for your submission. The relevant engineers have been informed.

[Offickind1939]

@[url=https://fallguysonline.com]fall guys online[/url]

Friendly ping, what's the WK-team's position on this? Thanks!

This is very much needed to create chat ui's, there are a considerable number of hacks to get an OK experience on iOS whereas Chrome just works

Ping as well, extremely needed for rich chat applications!