El formulario es donde ocurre la transacción, y es el primer lugar donde la WebView te traiciona. El checkout, el registro, el buscador: cada pantalla que pide al usuario que escriba es una pantalla donde el motor y el sistema operativo no se ponen de acuerdo sobre el teclado, el cursor y el método de entrada. El usuario lo siente como lentitud, campos que saltan y texto que no aterriza. No lo depura: abandona el carrito.
El teclado que no redimensiona
En iOS, una WKWebView no se comporta como Safari cuando aparece el teclado en pantalla. La ventana no se redimensiona; window.innerHeight no se reduce; las barras position: fixed se quedan quietas y quedan cubiertas por el teclado. La solución es conectar a mano la Visual Viewport API y desplazar la barra —un detalle que una página de comerciante escrita para la web abierta nunca hace. Peor aún, cuando un campo al final de la página obtiene el foco, WKWebView lo desplaza automáticamente a la vista, pero el objetivo a veces es incorrecto: el campo salta fuera de pantalla o queda bajo el teclado. Y iOS prohíbe el foco programático para evitar que las páginas abran el teclado a su antojo, así que cualquier flujo que quiera avanzar el cursor debe esperar un gesto del usuario. Un formulario que funciona en Chrome de escritorio y Safari mobile se desvía en cuanto se carga en una WebView.
El IME que pierde tus caracteres
En Android, el editor de método de entrada —lo que convierte pinyin o kana en chino, japonés o coreano— es donde los formularios WebView pierden datos en silencio. Durante la composición, compositionend puede aterrizar un carácter o un párrafo entero corto; el cursor se congela al inicio hasta que termina la composición; una entrada controlada que escribe el pinyin intermedio de vuelta al estado corrompe el campo, duplica sílabas o entra en un bucle. Un caso documentado en 2026 mostró que la entrada de voz de Android WebView con un salto de línea en la composición dejaba caer el primer párrafo por completo: el texto nunca llegó al DOM. El mismo código en una pestaña del navegador funciona; en una WebView no, porque el motor reconstruye el DOM de bloque durante la composición y la región de composición se invalida.
El autocompletado de contraseña que desaparece
Pasa una página de inicio de sesión de Safari a una WKWebView y el aviso del gestor de contraseñas a menudo desaparece. El AutoFill del sistema depende de dos condiciones: la WebView debe usar el WKWebsiteDataStore predeterminado, y la app debe configurar Associated Domains con webcredentials que la vinculen al sitio. Usa un almacén no persistente para modo privado y AutoFill se bloquea directamente. Y aunque el autocompletado funcione, el diálogo de guardar contraseña a menudo nunca se dispara en WKWebView, así que los usuarios pueden rellenar pero nunca guardar: lo opuesto a la experiencia Safari. Una app de tráfico cuyo inicio de sesión es una página alojada está pidiendo a los usuarios que tecleen credenciales a mano en cada visita.
La solución del runtime
Un runtime propio del anfitrión no envía el formulario del comerciante y espera que el motor y el sistema operativo coincidan. Aporta una capa de entrada de primera parte: es dueño del manejo de teclado/visual-viewport para que las barras fijas nunca se oculten, normaliza el foco y el scroll entre motores, pre-maneja la composición del IME para que los caracteres y el cursor aterricen correctamente, y provee una ruta de autocompletado sancionada y segura ligada al almacén de credenciales propio del anfitrión en lugar de rogar a cada página de comerciante que configure dominios. El formulario se vuelve una superficie que la plataforma garantiza, no un juego de azar por página.
| Dimensión | WebView | Runtime propio del anfitrión |
|---|---|---|
| Teclado vs layout | Sin resize; barras fijas ocultas | Visual-viewport manejado; barras visibles |
| Scroll de foco | Objetivo erróneo; campo salta | Normalizado entre motores |
| Composición IME | Pierde texto; cursor congelado | Pre-manejado; caracteres aterrizan |
| Autocompletado | Desaparece; diálogo de guardado ausente | Ruta segura de primera parte |
| Quién lo posee | Página de comerciante, depende del motor | Capa de entrada garantizada por la plataforma |
El hilo conductor de esta serie es el control. Una WebView deja el formulario de un comerciante en tu app pero entrega el teclado, el cursor y el método de entrada a una negociación entre dos capas que no coinciden del todo. Un runtime te hace dueño de la entrada. Para un catálogo de páginas de checkout ajenas, esa titularidad es la diferencia entre una compra completada y un carrito abandonado.
Fuentes
- WKWebView gotchas: el teclado no redimensiona la ventana; el scroll de foco salta — iOS WebView necesita Visual Viewport API; el auto-scroll puede ocultar el campo.
- El autocompletado iOS WKWebView requiere almacén predeterminado + Associated Domains — almacén no persistente bloquea AutoFill; se necesita webcredentials.
- Autocompletado de contraseña WKWebView: el diálogo de guardado a menudo no se dispara — autocompletado parcial; guardado de contraseña no soportado en WebView.
- Bugs de composición IME en Android WebView: texto perdido, cursor congelado — conflicto entre entrada controlada y composición; común en iOS WebView.
- Entrada de voz Android WebView pierde primer párrafo con salto de línea en composición — el texto nunca llega al DOM cuando la composición cruza el límite de bloque.
