Bug 230225 - Implement the VirtualKeyboard API
Summary: Implement the VirtualKeyboard API
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2021-09-13 11:43 PDT by Bramus
Modified: 2024-04-05 17:43 PDT (History)
15 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bramus 2021-09-13 11:43:11 PDT
> 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/
Comment 1 Bramus 2021-09-13 11:45:32 PDT
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
Comment 2 Radar WebKit Bug Importer 2021-09-15 09:40:27 PDT
<rdar://problem/83154723>
Comment 3 Kevin Neal 2021-09-15 09:41:30 PDT
Thank you for filing. The appropriate engineers have been notified.
Comment 4 N 2023-01-05 08:40:55 PST
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
Comment 5 Alex 23 2023-09-07 10:05:51 PDT
Adding a vote that this is an important iOS Safari enhancement for many web developers, and working well on Chrome/Android.
Comment 6 John Crim 2023-09-08 14:16:48 PDT
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.
Comment 7 Fred Rivett 2024-04-05 17:43:44 PDT
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.