Um app nativo traz um layout ciente do teclado: quando o teclado virtual aparece, o campo em foco rola para a vista e nada fica escondido. Dentro de um WebView essa garantia some. O WebView não redimensiona o viewport visual de forma independente quando o IME aparece; a página não vê a geometria do teclado; e no Android e no iOS o input em que o usuário digita fica rotineiramente coberto. Formulários de login e pagamento viram uma caixa cega. Um runtime próprio do host oferece uma ponte ciente do teclado: o host reporta o retângulo do IME à página e mantém o campo em foco visível.
O WebView não vê o teclado
No Android, o Chrome 108+ mudou o tratamento do teclado para que o navegador redimensione apenas o viewport visual e deixe o layout intacto (resizes-visual). O WebView foi explicitamente excluído dessa mudança. Um bug ainda aberto no Chromium (issue 40287394) confirma que o WebView "não consegue redimensionar o Viewport Visual independentemente do Viewport de Layout", e a Virtual Keyboard API simplesmente não funciona lá: o boundingRect fica zerado e o evento geometrychange nunca dispara. Assim, com adjustResize todo o layout salta; com adjustPan o layout desliza mas o topo é cortado; e a página não tem sinal confiável de onde o teclado está.
O iOS também esconde o campo
No iOS, o WKWebView não rola automaticamente o input em foco para a vista quando o teclado aparece, e a API visualViewport se comporta de forma inconsistente entre versões. O resultado é o mesmo: o campo em que o usuário digita fica atrás do teclado, e a página não consegue trazê-lo para frente porque nunca sabe o tamanho nem a posição do teclado.
O que quebra quando o campo está oculto
- O login falha em silêncio. O campo de senha fica sob o teclado; o usuário digita às cegas e envia credenciais erradas.
- Os pagamentos travam. Os inputs de cartão e OTP ficam cobertos; o checkout não avança.
- O layout salta. O
adjustResizereflui a página inteira; elementos sticky e fixed quebram. - Roleta de versões. O WebView 139+ agora redimensiona o viewport visual com o teclado, mas observou-se que o evento resize apaga o foco do input e esconde o teclado de novo.
- Sem API consistente. As unidades
dvhajudam só em motores novos; WebViews antigos ainda calculam100vhincluindo a área do teclado.
A solução do runtime
Um runtime próprio do host assume o controle do teclado. O host ouve mostrar/ocultar do IME na camada nativa, calcula o retângulo do teclado e o ponteia à página como um sinal de inset do teclado. A página então mantém o campo em foco dentro da área visível — rolendo-o para a vista ou dirigindo o layout a partir do inset — sem depender do redimensionamento pouco confiável do motor. Um comportamento, todos os dispositivos, todas as versões do SO.
| Dimensão | WebView | Runtime próprio do host |
|---|---|---|
| Geometria do teclado | Invisível para a página | A ponte reporta o ret IME |
| Redimensionado do viewport visual | Não independente (Android) | Dirigido pelo host, consistente |
| Campo em foco no iOS | Não rola sozinho | O host rola para a vista |
| Efeitos do adjustResize | Salto de layout | Nenhum — ciente do inset |
| Comportamento entre versões | Quebra por build do WebView | Estável |
| Foco do input | Perdido em alguns redimensionados | Preservado |
Um app nativo nunca deixa o teclado comer o campo. Um WebView puro faz isso com frequência. Um runtime coloca o teclado onde a página pode vê-lo — e o campo de volta onde o usuário pode vê-lo.
Fontes
- Chromium Issue Tracker — WebView não redimensiona o Viewport Visual de forma independente — bug aberto; Virtual Keyboard API não funciona no WebView.
- Android Developers — Entender os insets de janela no WebView — como o WebView recebe os insets do teclado.
- Chrome for Developers — Comportamento de redimensionado do viewport (Chrome 108+) — resizes-visual que o WebView nunca recebeu.
- Honor — Guia de compatibilidade Android 17 (WebView 139 teclado + bug de foco) — resize apaga foco, esconde teclado.
- MDN — Visual Viewport API — o viewport que o teclado deveria redimensionar.
