Edit: Documenté par Apple bien que je ne puisse pas le faire fonctionner: Comportement de WKWebView avec écrans de clavier : "Dans iOS 10, les objets WKWebView correspondent au comportement natif de Safari en mettant à jour leur propriété window.innerHeight lorsque le clavier est affiché, et n'appelez pas les événements de redimensionnement "(peut peut-être utiliser le focus ou le focus plus le délai pour détecter le clavier au lieu d'utiliser le redimensionnement).
Modifier: le code suppose un clavier à l'écran, pas un clavier externe. Le laisser parce que les informations peuvent être utiles à d'autres personnes qui ne se soucient que des claviers à l'écran. Utilisez http://jsbin.com/AbimiQup/4 pour afficher les paramètres de page.
Nous testons pour voir si le document.activeElement
est un élément qui montre le clavier (type d'entrée = texte, zone de texte, etc.).
Le code suivant fudge les choses pour nos besoins (bien que généralement pas correct).
function getViewport() {
if (window.visualViewport && /Android/.test(navigator.userAgent)) {
// https://developers.google.com/web/updates/2017/09/visual-viewport-api Note on desktop Chrome the viewport subtracts scrollbar widths so is not same as window.innerWidth/innerHeight
return {
left: visualViewport.pageLeft,
top: visualViewport.pageTop,
width: visualViewport.width,
height: visualViewport.height
};
}
var viewport = {
left: window.pageXOffset, // http://www.quirksmode.org/mobile/tableViewport.html
top: window.pageYOffset,
width: window.innerWidth || documentElement.clientWidth,
height: window.innerHeight || documentElement.clientHeight
};
if (/iPod|iPhone|iPad/.test(navigator.platform) && isInput(document.activeElement)) { // iOS *lies* about viewport size when keyboard is visible. See http://stackoverflow.com/questions/2593139/ipad-web-app-detect-virtual-keyboard-using-javascript-in-safari Input focus/blur can indicate, also scrollTop:
return {
left: viewport.left,
top: viewport.top,
width: viewport.width,
height: viewport.height * (viewport.height > viewport.width ? 0.66 : 0.45) // Fudge factor to allow for keyboard on iPad
};
}
return viewport;
}
function isInput(el) {
var tagName = el && el.tagName && el.tagName.toLowerCase();
return (tagName == 'input' && el.type != 'button' && el.type != 'radio' && el.type != 'checkbox') || (tagName == 'textarea');
};
Le code ci-dessus n'est qu'approximatif: il est incorrect pour le clavier partagé, le clavier non ancré, le clavier physique. Selon le commentaire en haut, vous pourrez peut-être faire un meilleur travail que le code donné sur Safari (depuis iOS8?) Ou WKWebView (depuis iOS10) en utilisantwindow.innerHeight
propriété.
J'ai trouvé des échecs dans d'autres circonstances: par exemple, donnez le focus à l'entrée puis allez à l'écran d'accueil puis revenez à la page; L'iPad ne devrait pas réduire la taille de la fenêtre d'affichage; les anciens navigateurs IE ne fonctionnaient pas, Opera ne fonctionnait pas car Opera gardait le focus sur l'élément après la fermeture du clavier.
Cependant, la réponse étiquetée (changer le scrolltop pour mesurer la hauteur) a des effets secondaires désagréables sur l'interface utilisateur si la fenêtre peut zoomer (ou forcer le zoom activé dans les préférences). Je n'utilise pas l'autre solution suggérée (changer le scrolltop) car sur iOS, lorsque la fenêtre peut zoomer et faire défiler jusqu'à l'entrée focalisée, il y a des interactions boguées entre le défilement et le zoom et la mise au point (qui peuvent laisser une entrée juste focalisée en dehors de la fenêtre - non visible).