O formulário é onde a transação acontece, e é o primeiro lugar onde a WebView trai você. O checkout, o cadastro, a caixa de busca — toda tela que pede ao usuário que digite é uma tela onde o motor e o sistema operacional discordam sobre o teclado, o cursor e o método de entrada. O usuário sente como lentidão, campos que pulam e texto que não aterrisa. Ele não depura: abandona o carrinho.
O teclado que não redimensiona
No iOS, uma WKWebView não se comporta como o Safari quando o teclado virtual aparece. A janela não redimensiona; window.innerHeight não encolhe; barras position: fixed ficam paradas e são cobertas pelo teclado. A solução é conectar manualmente a Visual Viewport API e deslocar a barra —detalhe que uma página de lojista feita para a web aberta nunca faz. Pior, quando um campo no fim da página ganha foco, a WKWebView rola automaticamente para trazê-lo à vista, mas o alvo às vezes está errado: o campo salta para fora da tela ou fica sob o teclado. E o iOS proíbe foco programático para impedir que páginas abram o teclado sem aviso, então qualquer fluxo que queira avançar o cursor precisa esperar um gesto do usuário. Um formulário que funciona no Chrome desktop e no Safari mobile derrapa assim que é carregado numa WebView.
O IME que perde seus caracteres
No Android, o editor de método de entrada —o que transforma pinyin ou kana em chinês, japonês ou coreano— é onde os formulários WebView perdem dados em silêncio. Durante a composição, compositionend pode aterrisar um caractere ou um parágrafo inteiro a menos; o cursor congela no início até a composição terminar; uma entrada controlada que escreve o pinyin intermediário de volta no estado corrompe o campo, duplica sílabas ou entra em loop. Um caso documentado em 2026 mostrou que a entrada de voz do Android WebView com quebra de linha na composição descartava o primeiro parágrafo inteiro — o texto nunca chegou ao DOM. O mesmo código numa aba do navegador funciona; numa WebView não, porque o motor reconstrói o DOM de bloco durante a composição e a região de composição é invalidada.
O preenchimento automático de senha que desaparece
Leve uma página de login do Safari para uma WKWebView e o aviso do gerenciador de senhas frequentemente some. O AutoFill do sistema depende de duas condições: a WebView deve usar o WKWebsiteDataStore padrão, e o app deve configurar Associated Domains com webcredentials que o vinculam ao site. Use um armazenamento não persistente para modo privado e o AutoFill é bloqueado direto. E mesmo quando o preenchimento funciona, o diálogo de salvar senha frequentemente nunca dispara na WKWebView, então os usuários conseguem preencher mas nunca salvar — o oposto da experiência Safari. Um app de tráfego cujo login é uma página hospedada está pedindo aos usuários que digitem credenciais manualmente a cada visita.
A solução do runtime
Um runtime próprio do host não envia o formulário do lojista e espera que o motor e o sistema operacional concordem. Ele oferece uma camada de entrada de primeira parte: assume o tratamento de teclado/visual-viewport para que barras fixas nunca se escondam, normaliza foco e scroll entre motores, pré-trata a composição do IME para que caracteres e cursor aterrisem corretamente, e provê uma rota de preenchimento sancionada e segura ligada ao próprio cofre de credenciais do host em vez de implorar a cada página de lojista que configure domínios. O formulário vira uma superfície que a plataforma garante, não um jogo de azar por página.
| Dimensão | WebView | Runtime próprio do host |
|---|---|---|
| Teclado vs layout | Sem resize; barras fixas escondidas | Visual-viewport tratado; barras visíveis |
| Scroll de foco | Alvo errado; campo salta | Normalizado entre motores |
| Composição IME | Perde texto; cursor congelado | Pré-tratado; caracteres aterrisam |
| Preenchimento automático | Desaparece; diálogo de salvar ausente | Rota segura de primeira parte |
| Quem o possui | Página de lojista, depende do motor | Camada de entrada garantida pela plataforma |
O fio condutor desta série é o controle. Uma WebView deixa o formulário de um lojista subir no seu app, mas entrega o teclado, o cursor e o método de entrada a uma negociação entre duas camadas que não concordam totalmente. Um runtime faz você ser dono da entrada. Para um catálogo de páginas de checkout alheias, essa titularidade é a diferença entre uma compra concluída e um carrinho abandonado.
Fontes
- WKWebView gotchas: teclado não redimensiona a janela; scroll de foco salta — iOS WebView precisa de Visual Viewport API; auto-scroll pode esconder o campo.
- Autopreenchimento iOS WKWebView exige armazenamento padrão + Associated Domains — armazenamento não persistente bloqueia AutoFill; precisa webcredentials.
- Preenchimento de senha WKWebView: diálogo de salvar frequentemente não dispara — autopreenchimento parcial; salvar senha não suportado na WebView.
- Bugs de composição IME no Android WebView: texto perdido, cursor congelado — conflito entre entrada controlada e composição; comum na iOS WebView.
- Entrada de voz Android WebView descarta primeiro parágrafo com quebra de linha na composição — texto nunca chega ao DOM quando a composição cruza o limite de bloco.
