> 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/
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
<rdar://problem/83154723>
Thank you for filing. The appropriate engineers have been notified.
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
Adding a vote that this is an important iOS Safari enhancement for many web developers, and working well on Chrome/Android.
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.
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.
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.
(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 🙏