Em um navegador real, o gerenciador de senhas oferece a credencial salva no instante em que o campo de login aparece. Dentro de um WebView esse campo fica vazio. No iOS, um WKWebView não mostra as senhas que o usuário salvou no Keychain do Safari para conteúdo web; no Android, o preenchimento automático do WebView vem desativado por padrão e bloqueado por dicas de autopreenchimento, um contexto de atividade e um serviço do sistema. Um runtime próprio do host conecta um provedor de credenciais nativo: um campo de login que se preenche em todo lugar.
iOS: sem senhas do Keychain para conteúdo web
A documentação de Password AutoFill da Apple explica como o sistema oferece credenciais salvas via textContentType, mas isso se aplica aos próprios UITextField nativos do app. Para o conteúdo web renderizado dentro de um WKWebView, o sistema não oferece as senhas que o usuário salvou no Safari como o Safari faz. A barra QuickType que aparece no Safari para um login salvo não está disponível de forma confiável em um WKWebView embutido qualquer; as sugestões de credenciais a nível de página que o usuário espera simplesmente não aparecem. Os gerenciadores de senhas de terceiros que rodam como extensões do Safari ou de provedor de credenciais também não estão presentes dentro da página embutida. O resultado: o usuário que tem a senha salva no Safari a digita manualmente de novo, dentro do seu app.
Android: o preenchimento automático vem desativado por padrão
O framework Autofill do Android suporta o WebView desde o Chrome 61, mas é condicional e frágil. O WebView deve ser criado com um contexto de atividade, os campos devem trazer autofillHints (ou importantForAutofill deve ser configurado corretamente) e o serviço do sistema Autofill do dispositivo deve estar ativado e não substituído pelo app ou pela ROM. Muitos WebViews desativam o preenchimento automático por completo, e o autopreenchimento de gerenciadores de senhas de terceiros dentro do conteúdo do WebView é, na melhor das hipóteses, inconsistente. O mesmo login que se autopreenche perfeitamente no Chrome pode ficar vazio dentro do navegador embutido, e, ao contrário do Chrome, a página não pode pedir ao usuário que salve ou preencha.
O que quebra quando o preenchimento automático morre
- Cada login é uma redigitada manual. A senha que o usuário salvou no navegador fica inalcançável a partir do WebView, em ambas as plataformas.
- Vêm depois senhas mais fracas e reutilizadas. Quando preencher é difícil, os usuários recorrem a senhas memoráveis ou duplicadas: o oposto do que um app financeiro quer.
- Os códigos de uso único também ficam mais difíceis. O preenchimento automático de SMS / TOTP vinculado ao domínio que o Safari oferece nativamente não é mostrado de forma confiável na página embutida.
- Suporte e abandono sobem. Um login que «simplesmente funciona» no navegador vira um ponto de fricção no app, e os tickets de suporte aumentam em consequência.
A solução do runtime
Um runtime próprio do host conecta um provedor de credenciais nativo. A página marca um campo com uma dica de autopreenchimento padrão, e o host o resolve por meio do provedor de credenciais da plataforma: ASPasswordCredentialIdentity / QuickType de domínio associado no iOS, o framework Autofill e as extensões de provedor de credenciais no Android. Logins salvos, senhas geradas e códigos de uso único são oferecidos de forma nativa e consistente. Uma integração, cada motor, um campo preenchido.
| Dimensão | WebView | Runtime próprio do host |
|---|---|---|
| Senhas salvas iOS | Não mostradas para web | Provedor de credenciais nativo |
| Preenchimento automático Android | Desativado por padrão, bloqueado | Autofill nativo + provedor |
| Gerenciadores de terceiros | Ausentes na página | Conectados ao host |
| Códigos de uso único | Pouco confiável | Preenchimento nativo vinculado ao domínio |
| Consistência | Conforme o motor | Uniforme |
Um app nativo oferece o login salvo em todos os dispositivos. Um WebView padrão o oferece em quase nenhum. Um runtime dá à página um campo de login —e a credencial salva do próprio usuário no final.
Fontes
- Apple Developer — Password AutoFill — o sistema oferece credenciais salvas via
textContentType; recomendaASWebAuthenticationSessionpara login de terceiros, que suporta Password AutoFill. - Apple Developer — Habilitar Password AutoFill em um elemento de entrada HTML — «garanta que uma web view ou página web forneça as sugestões de autopreenchimento corretas»; o autopreenchimento web depende do contêiner e dos domínios associados.
- Breeze — Guia de apps móveis embutidos — «Preenchimento automático: não suportado em WebViews iOS, por motivos de segurança. WebViews Android suportam»; descreve os compromissos de WKWebView/SFSafariViewController.
- Android Developers — Framework Autofill — WebView suporta Autofill desde o Chrome 61; requer
autofillHints/importantForAutofille um serviço do sistema Autofill ativado. - CodingTechRoom — Habilitar Autofill em WebView com contexto de atividade — WebView precisa de contexto de atividade e
setAutofillHints; o contexto de aplicação o quebra em silêncio.
