Qt WebEngine Características

Qt WebEngine admite las siguientes funciones:

• Codecs de audio y vídeo
• Herramientas de desarrollo de Chromium
• Certificados de cliente
• Esquemas personalizados
• Arrastrar y soltar
• Favicon
• Pantalla completa
• Aceleración de hardware
• HTML5 DRM
• Geolocalización HTML5
• WebSockets HTML5
• Protocolo HTTP/2
• Almacenamiento local
• Diálogos nativos
• Visualización de archivos PDF
• API del ciclo de vida de la página
• Imprimir en PDF
• Notificaciones Push
• Corrector ortográfico
• Toque
• Ver fuente
• Notificaciones web
• WebEngineDriver
• WebGL
• WebRTC

Códecs de audio y vídeo

Qt WebEngine es compatible con el formato de archivo MPEG-4 Parte 14 (MP4) sólo si se han habilitado los códecs de audio y vídeo propietarios necesarios, como H.264 y MPEG capa 3 (MP3). Los códecs propietarios pueden activarse pasando la siguiente opción a la herramienta configure al configurar Qt:

-webengine-proprietary-codecs

Por ejemplo, se podría pasar la siguiente opción al configurar Qt para construirlo en el nivel superior:

configure -webengine-proprietary-codecs

Para obtener más información, consulte Opciones de configuración de Qt.

Cuando se utiliza cmake para construir sólo el módulo Qt WebEngine, se puede utilizar el siguiente comando para configurar y construir (en este ejemplo, el código fuente de Qt WebEngine se encuentra en C:\qt\qtwebengine):

qt-configure-module C:\qt\qtwebengine -webengine-proprietary-codecs
cmake --build . --parallel

FFmpeg es una solución multiplataforma para grabar, convertir y transmitir audio y vídeo. Puede configurarse para su uso con varios códecs, lo que plantea problemas de licencias durante la distribución con las bibliotecas de códecs. Para algunos códecs, existen implementaciones de código abierto, como OpenH264.

Herramientas de desarrollo de Chromium

Las Chromium DevTools permiten inspeccionar y depurar problemas de diseño y rendimiento de cualquier contenido web.

Esta característica puede probarse lanzando una aplicación Qt WebEngine con la opción de línea de comandos --remote-debugging-port=[your-port] o estableciendo la variable de entorno QTWEBENGINE_REMOTE_DEBUGGING y utilizando un navegador basado en Chromium (como Simple Browser o Nano Browser) para conectarse a http://localhost:[your-port].

--webEngineArgs --remote-debugging-port=5000

Para evitar errores de WebSocket durante la depuración remota, añada un argumento adicional en la línea de comandos --remote-allow-origins=<origin>[,<origin>, ...], donde <origin> hace referencia al origen de la solicitud. Utilice --remote-allow-origins=* para permitir conexiones desde todos los orígenes. Si no se especifica nada, Qt WebEngine añadirá --remote-allow-origins=* a los argumentos de la línea de comandos cuando la depuración remota esté activada, permitiendo así peticiones de todos los orígenes.

La página de Chromium DevTools también puede mostrarse dentro de la aplicación. Para configurar esto, puedes llamar a QWebEnginePage::setInspectedPage() a la página a inspeccionar, que implícitamente carga las DevTools en la página this, o QWebEnginePage::setDevToolsPage() para dejar que la página this sea inspeccionada.

Las propiedades QML respectivas son WebEngineView.devToolsView y WebEngineView.inspectedView.

Para más información, consulte Qt WebEngine Depuración y perfiles.

Certificados de cliente

Algunos servidores web, en particular muchos sitios de intranet, requieren que el cliente se autentique con un certificado, denominado certificado de cliente. Qt WebEngine leerá los certificados de cliente instalados en la configuración del sistema en macOS y Windows, y en Linux los instalados en la base de datos del NSS. Los certificados pueden instalarse en la base de datos NSS utilizando la herramienta pk12util.

Por defecto, Qt WebEngine no ofrecerá ningún certificado de cliente a los servidores, ya que al hacerlo se identifica de forma única al usuario y podría violar las expectativas de privacidad.

Para activar la compatibilidad con certificados de cliente, una aplicación debe escuchar las señales QWebEnginePage::selectClientCertificate o WebEngineView.selectClientCertificate y seleccionar uno de los certificados ofrecidos. En el caso de las aplicaciones que pueden navegar a sitios web no fiables, se recomienda dar siempre al usuario la opción de elegir antes de identificarlo de forma única ante un servidor remoto.

Además del certificado de cliente almacenado en la configuración del sistema, Qt WebEngine ofrece también el almacén en memoria. La instancia QWebEngineClientCertificateStore puede obtenerse con el método QWebEngineProfile::clientCertificateStore(). Una aplicación puede utilizar esta clase para añadir un nuevo certificado con una llamada a QWebEngineClientCertificateStore::add(). Tenga en cuenta que durante las llamadas a selectClientCertificate, Qt WebEngine lista tanto los certificados de cliente del sistema como los almacenados en memoria.

Véase también Ejemplo de certificado de cliente para más detalles de implementación.

Esquemas personalizados

Qt WebEngine permite a la aplicación definir sus propios esquemas de URL personalizados con políticas de seguridad y mecanismos de transporte especializados.

Los esquemas personalizados pueden utilizarse para implementar protocolos de red alternativos con todas las políticas de seguridad web habituales, esquemas internos privilegiados para mostrar componentes de la interfaz de usuario o información de depuración, esquemas sandboxed con restricciones adicionales, etc.

Para más información, consulte QWebEngineUrlScheme y QWebEngineUrlSchemeHandler.

Arrastrar y soltar

Qt WebEngine admite la función de arrastrar y soltar de HTML5.

Esta función puede probarse abriendo una demo de arrastrar y soltar HTML5, como Demos HTML5 - Arrastrar y soltar, Demos HTML5 - Arrastrar y soltar simple, o Demos HTML5 - Arrastrar y soltar, carga automática, en Simple Browser o Nano Browser.

Arrastrar archivos al navegador no forma parte de HTML5, pero es compatible. Se puede probar abriendo Demos HTML5 - File API.

Favicon

Qt WebEngine soporta el icono de la URL del sitio web, favicon. Cada icono se almacena en la base de datos interna para cada QWebEngineProfile y se puede acceder a él mediante una llamada a QWebEnginePage::icon() o una propiedad WebEngineView.icon para el contenido cargado actualmente.

Además, Qt WebEngine proporciona una API para acceder a los iconos ya almacenados en la base de datos interna del perfil.

Manejo de Favicon QML

Para acceder a los iconos se registra un QQuickImageProvider. Se puede acceder a este proveedor mediante una URL especial en la que el esquema es "image:" y el host es "favicon".

Image {
    source: "image://favicon/url"
}

url puede ser la URL del favicon:

Image {
    source: "image://favicon/https://www.qt.io/hubfs/2016_Qt_Logo/qt_logo_green_rgb_16x16.png"
}

El url también puede ser la URL de una página para acceder a su icono:

Image {
    source: "image://favicon/https://www.qt.io/"
}

Si hay más de un icono disponible, se puede especificar la propiedad Image::sourceSize para elegir el icono con el tamaño deseado. Si no se especifica Image::sourceSize o se especifica 0, se elegirá el icono más grande disponible.

El proveedor de imágenes busca el icono solicitado en las instancias WebEngineView existentes. En primer lugar, intenta que coincida con los iconos mostrados actualmente. Si no se encuentra ninguna coincidencia, solicita el icono a la base de datos. Cada perfil tiene su propia base de datos de iconos y se guarda en el almacenamiento persistente, por lo que también se puede acceder a los iconos guardados sin conexión a la red. El icono debe ser cargado previamente para ser almacenado en la base de datos.

Manejo de Favicon C

Un usuario puede solicitar un icono del contenido previamente cargado para cada QWebEngineProfile utilizando las llamadas QWebEngineProfile::requestIconForPageURL() o QWebEngineProfile::requestIconForIconURL(). Tenga en cuenta que la base de datos del perfil se almacena en el almacenamiento persistente y se puede acceder a ella sin conexión a la red.

Pantalla completa

Qt WebEngine permite ver contenidos web en modo de pantalla completa. Para más información, consulte WebEngineSettings.fullscreenSupportEnabled, WebEngineView.fullScreenRequested, QWebEngineSettings::FullScreenSupportEnabled, y QWebEnginePage::fullScreenRequested.

Esta función se puede probar reproduciendo un vídeo de YouTube en Video Player o Nano Browser, y haciendo clic en el icono de pantalla completa para pasar al modo de pantalla completa.

Aceleración por hardware

Qt WebEngine intenta utilizar la aceleración por hardware para renderizar el contenido web siempre que es posible. El renderizado real lo realiza Chromium, y la imagen final la produce el compositor de Chromium, que hace uso de APIs de GPU modernas como OpenGL, Vulkan, Metal o Direct3D, dependiendo de la plataforma y los controladores disponibles.

A continuación, Qt WebEngine importa esta imagen final en el canal de renderizado de Qt utilizando la interoperabilidad de GPU, lo que permite compartir eficazmente los recursos de la GPU sin copias innecesarias. La imagen importada se pasa a Qt Quick Scene Graph, que también realiza el renderizado acelerado por hardware a través de Qt Rendering Hardware Interface (RHI).

Aunque tanto Qt como Chromium dependen de la aceleración por GPU, no necesariamente utilizan la misma API gráfica. En la práctica, Qt WebEngine intenta alinear el backend de GPU de Chromium con el utilizado por Qt siempre que sea posible, utilizando por defecto la configuración de backend elegida por Qt para garantizar la compatibilidad y un rendimiento óptimo, aunque es posible anular manualmente estos valores por defecto si es necesario.

Cuando la aceleración por hardware no está disponible o falla, Qt WebEngine intenta automáticamente volver al renderizado por software.

Forzar el uso del renderizado por software

El cambio automático a la renderización por software no siempre es posible, y Qt WebEngine puede no mostrar correctamente el contenido web o salir con un mensaje de error. En estos casos, puede ser necesario desactivar explícitamente la aceleración por hardware y utilizar el renderizado por software en su lugar.

Hay varias formas de forzar el renderizado por software:

• Deshabilitar la aceleración por hardware en Chromium:

  export QTWEBENGINE_CHROMIUM_FLAGS=--disable-gpu

• Deshabilitar la aceleración por hardware en Qt Quick Scene Graph:

  export QT_QUICK_BACKEND=software

Cambiar el backend de la API gráfica en Qt

Hay dos maneras de elegir el backend de la API de gráficos:

• Establecer la variable de entorno QSG_RHI_BACKEND antes de lanzar la aplicación.
• Llamar a QQuickWindow::setGraphicsApi() en combinación con QSGRendererInterface::GraphicsApi antes de construir el primer QQuickWindow.

Para más detalles, ver Renderizado a través de la Interfaz de Hardware de Renderizado Qt.

Cambiar el backend de la API gráfica en Chromium

Generalmente no se recomienda cambiar el backend de la API gráfica de Chromium, ya que puede causar problemas de compatibilidad o comportamientos de renderizado inconsistentes. Siempre que sea posible, es preferible utilizar la variable de entorno QSG_RHI_BACKEND. Sin embargo, puede ser necesario en algunos casos para la depuración o como una solución temporal para problemas específicos del controlador.

Para anular el backend de Chromium, establezca la variable de entorno QTWEBENGINE_CHROMIUM_FLAGS para pasar las banderas de línea de comandos de Chromium correspondientes, como --use-gl= o --use-angle=.

En Qt WebEngine, Chromium utiliza actualmente el backend ANGLE por defecto en todas las plataformas que soportan aceleración por hardware. ANGLE es una capa de abstracción gráfica multiplataforma de Chromium que oculta el backend gráfico nativo subyacente.

La configuración por defecto que utiliza Qt WebEngine es la siguiente:

export QTWEBENGINE_CHROMIUM_FLAGS="--use-gl=angle --use-angle=default"

Si ANGLE falla bajo una configuración específica, se puede desactivar completamente mientras se sigue utilizando Vulkan para el renderizado acelerado por hardware:

export QTWEBENGINE_CHROMIUM_FLAGS="--use-gl=stub --enable-features=Vulkan --use-vulkan=native"

Alternativamente, la siguiente configuración utiliza Vulkan para el renderizado mientras mantiene ANGLE habilitado para el soporte de WebGL:

export QTWEBENGINE_CHROMIUM_FLAGS="--use-gl=angle --enable-features=Vulkan --use-vulkan=native"

Para más detalles sobre las banderas de línea de comandos de Chromium correspondientes, consulte el código fuente de Chromium: //ui/gl/gl_switches.cc

NVIDIA en Linux

En sistemas Linux con una GPU NVIDIA, Chromium se ve obligado a utilizar Vulkan para el renderizado.

Qt WebEngine utiliza objetos de búfer GBM para importar texturas desde Chromium al canal de gráficos de Qt. Sin embargo, los controladores NVIDIA no admiten actualmente la asignación de estos objetos de búfer. Como solución, Qt WebEngine fuerza a Chromium a renderizar con Vulkan e importa las texturas usando la interoperabilidad Vulkan.

Habilitar el registro y la resolución de problemas

Cuando se produce un problema de renderizado, es importante conocer la configuración que falla y el estado actual de la aceleración por hardware para poder investigar e informar del problema de forma efectiva.

La forma más sencilla de comprobar esta información es cargar la página interna chrome://gpu y analizar su contenido. Sin embargo, esta página puede no estar siempre legible o disponible durante un problema de renderizado.

Qt WebEngine proporciona categorías de registro que pueden activarse para volcar información gráfica detallada:

• qt.webenginecontext registra cómo se inicializó Qt WebEngine, la GPU detectada y la configuración gráfica.
• qt.webengine.compositor registra la configuración utilizada por Chromium y los pasos que sigue Qt WebEngine para importar texturas en el canal gráfico de Qt.

Para habilitar estos registros, configura la variable de entorno QT_LOGGING_RULES, por ejemplo:

export QT_LOGGING_RULES="qt.webenginecontext=true;qt.webengine.compositor=true"

Este es un ejemplo de registro de GPU de qt.webenginecontext:

Chromium GL Backend: angle
Chromium ANGLE Backend: default
Chromium Vulkan Backend: disabled

QSG RHI Backend: OpenGL
QSG RHI Backend Supported: yes
QSG RHI Device: AMD AMD Radeon Graphics (radeonsi, raphael_mendocino, LLVM 20.1.8, DRM 3.61, 6.12.41-gentoo-x86_64) 4.6 (Compatibility Profile) Mesa 25.1.9
QSG RHI GPU Vendor: AMD

El primer bloque presenta la configuración de Chromium:

• Chromium GL Backend muestra el valor de la configuración de --use-gl=.
• Chromium ANGLE Backend muestra el valor de la configuración de --use-angle=.
• Chromium Vulkan Backend muestra el valor de la configuración de --use-vulkan=.

El segundo bloque presenta la configuración de Qt:

• QSG RHI Backend muestra la API gráfica nativa subyacente.
• QSG RHI Backend Supported indica si esta API de gráficos está soportada por Qt WebEngine.
• QSG RHI Device muestra los metadatos del dispositivo gráfico utilizado por el RHI.
• QSG RHI Vendor muestra el proveedor del dispositivo gráfico utilizado por el RHI.

Este es un ejemplo de registro ANGLE de qt.webengine.compositor para la misma GPU:

qt.webengine.compositor: ANGLE_OPENGL display is initialized:
GL Renderer: ANGLE (AMD, AMD Radeon Graphics (radeonsi raphael_mendocino LLVM 20.1.8), OpenGL 4.6 (Core Profile) Mesa 25.1.9)
2 GPU(s) detected:
  Nvidia, device id: 0x1d01, driver: Mesa 25.1.9, system device id: 0x0, preference: None, active: no
  AMD, device id: 0x164e, driver: Mesa 25.1.9, system device id: 0x0, preference: None, active: yes
NVIDIA Optimus: disabled
AMD Switchable: disabled

Las entradas de registro anteriores indican:

• ANGLE_OPENGL display is initialized confirma que ANGLE se ha inicializado correctamente con el tipo de pantalla especificado.
• GL Renderer muestra los metadatos para el dispositivo gráfico usado por ANGLE (se espera que coincida con QSG RHI Device).
• 2 GPU(s) detected lista las GPUs detectadas por ANGLE.
• NVIDIA Optimus y AMD Switchable indican si ANGLE soporta el cambio de GPU en tiempo de ejecución (actualmente no soportado).

HTML5 DRM

Qt WebEngine permite visualizar vídeos protegidos por DRM si se ha instalado el plugin Widevine CDM. El plugin sólo viene en formato binario, por lo que puede ocultar detalles de la implementación del descifrado DRM. Puede obtenerlo de un tercero, o de una instalación de Google Chrome.

Al iniciarse, Qt WebEngine busca el complemento Widevine CDM en varias ubicaciones conocidas, como el directorio de instalación predeterminado de Google Chrome o rutas específicas de la distribución de Linux. También puede pasar la ubicación del complemento con QTWEBENGINE_CHROMIUM_FLAGS utilizando widevine-path.

En Windows:

set QTWEBENGINE_CHROMIUM_FLAGS=--widevine-path="C:/some path/widevinecdm.dll"

En Linux:

export QTWEBENGINE_CHROMIUM_FLAGS=--widevine-path="/some path/libwidevinecdm.so"

En macOS:

export QTWEBENGINE_CHROMIUM_FLAGS=--widevine-path="/some path/libwidevinecdm.dylib"

El formato de vídeo más utilizado por los servicios DRM, H.264, requiere códecs de audio y vídeo propietarios. Para más información sobre cómo activar los códecs, consulte Códecs de audio y vídeo.

Puede probar esta función reproduciendo un vídeo de castLabs o Bitmovin Player en los proyectos de ejemplo Simple Browser o Nano Browser.

Geolocalización HTML5

Qt WebEngine es compatible con la API de geolocalización de JavaScript con Qt Positioning como backend. La geolocalización HTML5 está desactivada por defecto. Para permitirla explícitamente, la aplicación necesita escuchar a QWebEnginePage::permissionRequested. Cuando se recibe una solicitud de permiso con un tipo de QWebEnginePermission::PermissionType::Geolocation, se puede llamar a QWebEnginePermission::grant() en el objeto recibido para conceder el permiso requerido.

Si Qt WebEngine fue construido con soporte Qt Positioning entonces esta característica puede ser probada usando Mapas y permitiéndole encontrar la posición actual del usuario.

Consulte Qt Positioning para una posible configuración de backend como el GPS o el posicionamiento basado en IP.

Permisos HTML5

Qt WebEngine tiene soporte para varios tipos de permisos de funciones web a través de la API QWebEnginePermission. Se pueden conceder (o denegar) permisos a un dominio web siempre que una página solicite información potencialmente sensible del usuario, como el acceso a la cámara o la geolocalización del usuario.

Los desarrolladores de aplicaciones pueden elegir entre pedir permiso al usuario final o tomar automáticamente la decisión por ellos. Además, pueden conceder o denegar de forma preventiva determinados permisos, en los casos en los que se espera que un dominio conocido los solicite.

El objeto QWebEngineProfile almacena todos los permisos que se han concedido o denegado a dominios individuales. A menos que el perfil actual esté fuera de registro, esos permisos se almacenan en el disco y se recuperan la próxima vez que se abre una aplicación. Sin embargo, este comportamiento puede modificarse, y los desarrolladores pueden optar por almacenar los permisos sólo hasta la salida de la aplicación, o incluso hacer que las peticiones de permisos se activen cada vez que un sitio web los solicite.

La lista completa de permisos web admitidos actualmente se encuentra en in the QWebEnginePermission documentation.

Marcos

Mediante la API QWebEngineFrame, los desarrolladores pueden inspeccionar e interactuar con elementos individuales de <iframe> dentro de una página web. Esto puede utilizarse para inyectar JavaScript o para imprimir sólo el contenido del marco, ignorando la página en la que está incrustado. También se puede acceder a los marcos de forma recursiva, en los casos en que existan marcos dentro de otros marcos.

WebSockets HTML5

Qt WebEngine admite la API WebSocket JavaScript para comunicarse con servidores WebSocket mediante los protocolos ws:// o wss://. Además, la integración con Qt WebChannel y Qt WebSockets permite la comunicación entre JavaScript y la parte nativa de la aplicación.

El módulo Qt WebChannel tiene un gran ejemplo para un servidor de chat y su cliente de chat basado en web. El cliente funciona en los navegadores de ejemplo de Qt WebEngine (como Simple Browser o Nano Browser).

Protocolo HTTP/2

Qt WebEngine soporta la implementación Chromium del protocolo HTTP/2.

Esta función puede probarse abriendo una demo de HTTP/2, como la Demo HTTP/2 de Akamai, en Simple Browser o Nano Browser.

Almacenamiento Local

Qt WebEngine permite guardar pares clave-valor en Local Storage sin fecha de caducidad. Esto forma parte de la API de Almacenamiento Web, donde un usuario puede acceder a un objeto Storage para los dominios dados utilizando la propiedad JavaScript Window.localStorage. Los datos almacenados persistirán incluso después de cerrar la página o la aplicación del navegador.

Tenga en cuenta que el Almacenamiento Local también puede desactivarse con un ajuste de QWebEngineSettings::LocalStorageEnabled. Además, la ruta de almacenamiento puede ajustarse con una llamada a QWebEngineProfile::setPersistentStoragePath.

QWebEngineProfile profile("MyProfile");
profile.settings()->setAttribute(QWebEngineSettings::LocalStorageEnabled, isEnabled);
profile.setPersistentStoragePath("/path/to/storage");

Qt WebEngine ofrece también una forma sencilla de investigar el contenido de Local Storage con Qt WebEngine Developer Tools visitando el panel Application y desplegando el menú Local Storage.

Diálogos nativos

Una página web puede solicitar diálogos para las siguientes funciones:

• Introducción de credenciales de usuario para autenticación HTTP y proxy
• Visualización de alertas, cuadros de diálogo de confirmación y avisos en JavaScript
• Selección de colores
• Selección de archivos
• Visualización de mensajes de validación de formularios

Qt WebEngine proporciona diálogos estándar para estas funciones. En las aplicaciones basadas en widgets, los cuadros de diálogo estándar se basan en QDialog, mientras que en las aplicaciones Qt Quick, pueden basarse en Qt Quick Controls 1 o Qt Quick Controls 2 . Estos últimos sólo se utilizan en plataformas eglfs.

Para forzar explícitamente diálogos basados en Qt Quick Controls 1 o Qt Quick Controls 2, establezca la variable de entorno QTWEBENGINE_DIALOG_SET en QtQuickControls1 o QtQuickControls2.

Qt WebEngine Los cuadros de diálogo de los widgets pueden personalizarse reimplementando las funciones QWebEnginePage::chooseFiles(), QWebEnginePage::javaScriptAlert(), QWebEnginePage::javaScriptConfirm() y QWebEnginePage::javaScriptPrompt().

Qt Quick Los diálogos pueden personalizarse conectándose a las señales WebEngineView::authenticationDialogRequested(), WebEngineView::javaScriptDialogRequested(), WebEngineView::colorDialogRequested(), WebEngineView::fileDialogRequested() y WebEngineView::formValidationMessageRequested().

Visualización de archivos PDF

Qt WebEngine permite visualizar documentos PDF navegando hasta ellos. Esta función utiliza la API de extensiones de Chromium y el complemento de visor de PDF para mostrar los documentos PDF. Puede probarse en Simple Browser o Nano Browser.

Esta función puede activarse (por defecto) o desactivarse mediante la configuración de QWebEngineSettings::PdfViewerEnabled o WebEngineSettings::pdfViewerEnabled.

API del ciclo de vida de la página

Qt WebEngine es compatible con la especificación Page Lifecycle API, una extensión en curso del estándar HTML que permite a los agentes de usuario reducir el consumo de recursos congelando o descartando páginas en segundo plano. Esta función está disponible tanto en la API de Widgets como en la de QML.

Para ver un ejemplo de uso de la API QML, consulte el ejemplo del ciclo de vida de WebEngine.

Visión general de los estados del ciclo de vida

Cada elemento de WebEngineView (u objeto de QWebEnginePage ) puede estar en uno de los tres estados del ciclo de vida: activo, congelado o descartado. Estos estados, al igual que los estados de suspensión de una CPU, controlan el uso de recursos de las vistas web.

El estado activo es el estado normal, sin restricciones, de una vista web. Todas las vistas web visibles están siempre en estado activo, al igual que todas las vistas web que aún no han terminado de cargarse. Sólo las vistas web invisibles e inactivas pueden pasar a otros estados del ciclo de vida.

El estado congelado es un estado de bajo uso de CPU. En este estado, la mayoría de las fuentes de tareas HTML se suspenden (congelan) y, como resultado, la mayoría del procesamiento de eventos DOM y la ejecución de JavaScript también se suspenderán. La vista web debe ser invisible para estar congelada, ya que la renderización no es posible en este estado.

El estado descartado es un estado extremo de ahorro de recursos. En este estado, el contexto de navegación de la vista web se descartará y el subproceso de renderizado correspondiente se cerrará. El uso de CPU y memoria en este estado se reduce prácticamente a cero. Al salir de este estado, la página web se recargará automáticamente. El proceso de entrar y salir del estado de descarte es similar a serializar el historial de navegación de la vista web y destruir la vista, para luego crear una nueva vista y restaurar su historial.

Véase también WebEngineView::LifecycleState. El equivalente en la API de Widgets es QWebEnginePage::LifecycleState.

Las propiedades lifecycleState y recommendedState

La propiedad lifecycleState del tipo WebEngineView es una propiedad de lectura-escritura que controla el estado actual del ciclo de vida de la vista web. Esta propiedad está diseñada para imponer el menor número posible de restricciones sobre los estados a los que se puede pasar. Por ejemplo, se permite congelar una vista web que esté reproduciendo música en segundo plano, deteniendo la música. Para implementar una estrategia de ahorro de recursos menos agresiva que evite interrumpir la actividad de fondo visible para el usuario, debe utilizarse la propiedad recommendedState.

La propiedad recommendedState del tipo WebEngineView es una propiedad de sólo lectura que calcula un límite seguro en la propiedad lifecycleState, teniendo en cuenta la actividad actual de la vista web. Así, en el ejemplo de una vista web reproduciendo música en segundo plano, el estado recomendado será Active ya que un estado más agresivo detendría la música. Si la aplicación quiere evitar interrumpir la actividad en segundo plano, entonces debería evitar poner la vista web en un estado de ciclo de vida más agresivo en el ahorro de recursos que el dado por recommendedState.

Véase también WebEngineView::lifecycleState y WebEngineView::recommendedState. Los equivalentes en la API de Widgets son QWebEnginePage::lifecycleState y QWebEnginePage::recommendedState.

Extensiones DOM

La propiedad lifecycleState está conectada a la especificación de la API Page Lifecycle, que especifica dos nuevos eventos DOM, freeze y resume, y añade una nueva propiedad booleana Document.wasDiscarded. Los eventos freeze y resume se disparan al pasar de Active a Frozen state, y viceversa. La propiedad Document.wasDiscarded se establece en true cuando se pasa del estado Discarded al estado Active.

Imprimir en PDF

Qt WebEngine permite imprimir una página web en un archivo PDF. Para obtener más información, consulte QWebEnginePage::printToPdf() y WebEngineView.printToPdf.

Esta función puede probarse utilizando Html2Pdf.

Notificaciones push

Qt WebEngine es compatible con la API Push de JavaScript para suscribirse y recibir notificaciones push. Para obtener más información, consulte QWebEngineProfile::setPushServiceEnabled() y WebEngineProfile.setPushServiceEnabled.

Esta función puede probarse con el ejemplo de notificaciones push de WebEngine.

Corrector ortográfico

Qt WebEngine permite integrar el corrector ortográfico en formularios HTML para que los usuarios puedan enviar mensajes con corrección ortográfica. Cuando el usuario hace clic en una palabra mal escrita subrayada, el menú contextual predeterminado muestra hasta cuatro sugerencias. Al seleccionar una, se sustituirá la palabra mal escrita.

Para poder comprobar la ortografía, el corrector ortográfico necesita diccionarios. Admite diccionarios del proyecto Hunspell, pero tienen que compilarse en un formato binario especial. Un diccionario Hunspell consta de dos archivos:

• Un archivo .dic que es un diccionario que contiene palabras para el idioma
• Un archivo .aff que define el significado de los indicadores especiales del diccionario.

Estos dos archivos pueden convertirse al formato bdic utilizando la herramienta qwebengine_convert_dict que se suministra junto con Qt. Cuando el corrector ortográfico Qt WebEngine se inicializa, intentará cargar los diccionarios bdict y comprobar su coherencia.

Para CMake, puede utilizar el comando qt_add_webengine_dictionary para convertir los archivos Hunspell .dic al formato binario .bdic. El comando crea un qtwebengine_dictionaries objetivo, que su proyecto puede utilizar una dependencia.

Por defecto, Qt WebEngine busca diccionarios dentro del directorio qtwebengine_dictionaries relativo al ejecutable si existe. Si no existe, buscará en QT_INSTALL_PREFIX/qtwebengine_dictionaries.

Alternativamente, se puede establecer una ruta de directorio de diccionarios como valor de la variable de entorno QTWEBENGINE_DICTIONARIES_PATH, o a través de la línea de comandos:

--webEngineArgs --webengine-dictionaries-path=<path>

Cuando se establece una anulación, la aplicación busca diccionarios sólo dentro del directorio proporcionado, y en ningún otro lugar.

En macOS, dependiendo de cómo esté configurado Qt WebEngine en el momento de la compilación, existen dos posibilidades para encontrar los datos de corrección ortográfica:

• Diccionarios Hunspell (por defecto) - se utilizan diccionarios .bdic, igual que en otras plataformas
• Diccionarios nativos: se utilizan las API de corrección ortográfica de macOS (lo que significa que los resultados dependerán de los diccionarios instalados en el sistema operativo).

Así, en el caso de macOS Hunspell, Qt WebEngine buscará en el subdirectorio qtwebengine_dictionaries situado dentro del directorio del paquete de aplicaciones Resources, y también en el directorio Resources situado dentro del paquete del framework Qt.

Para resumir, en caso de uso de Hunspell, se consideran las siguientes rutas:

• QTWEBENGINE_DICTIONARIES_PATH, si se establece
• QCoreApplication::applicationDirPath()/qtwebengine_dictionaries o QCoreApplication::applicationDirPath()/../Contents/Resources/qtwebengine_dictionaries (en macOS)
• [QLibraryInfo::DataPath]/qtwebengine_dictionaries o path/to/QtWebEngineCore.framework/Resources/qtwebengine_dictionaries (paquete Qt framework en macOS)

El corrector ortográfico está desactivado por defecto y puede activarse por perfil utilizando el método QWebEngineProfile::setSpellCheckEnabled() en aplicaciones basadas en widgets y la propiedad WebEngineProfile.spellCheckEnabled en aplicaciones Qt Quick.

El idioma actual utilizado para la corrección ortográfica se define por perfil, y puede establecerse utilizando el método QWebEngineProfile::setSpellCheckLanguages() o la propiedad WebEngineProfile.spellCheckLanguages.

Esta función puede probarse construyendo y ejecutando el ejemplo de corrector ortográfico.

Qt WebEngine puede compilarse también sin soporte para el corrector ortográfico con el uso de un modificador de configuración webengine-spellchecker.

qt-configure-module path\to\qtwebengine\sources -no-webengine-spellchecker

Para más información, vea Opciones de configuración de Qt.

Toque

Qt WebEngine soporta dispositivos táctiles para navegar e interactuar con páginas web.

El soporte de eventos táctiles en la API de JavaScript depende de la presencia de una pantalla táctil (lo que significa que ontouchstart y los manejadores relacionados estarán presentes en el objeto document.window si un dispositivo táctil capaz está conectado al sistema).

Algunos sitios web utilizan esta API para decidir si se ejecutan en un dispositivo móvil o en un ordenador de sobremesa y basan su diseño en ella. Esto puede provocar resultados no deseados en portátiles con pantalla táctil u otras configuraciones que emulen un dispositivo táctil falso.

Las aplicaciones pueden configurar esta función explícitamente con QWebEngineSettings::TouchEventsApiEnabled.

Tenga en cuenta que los eventos táctiles seguirán enviándose a las páginas web aunque la API esté desactivada. El envío de eventos táctiles a páginas web puede prohibirse instalando un objeto de filtro de eventos mediante QObject::installEventFilter en el objeto proxy de enfoque de vista WebEngine y filtrando todos los eventos táctiles.

Fuente de la vista

Qt WebEngine permite ver la fuente HTML de una página web.

Esta función puede utilizarse desde menús personalizados o asignarse a eventos personalizados. Para más información, consulte WebEngineView::WebAction, y QWebEnginePage::WebAction.

Esta función puede probarse abriendo una página web en Simple Browser o Nano Browser y seleccionando Page Source en el menú contextual. La entrada del menú contextual Page Source abre la vista de origen en una nueva pestaña.

Para abrir la vista fuente en la pestaña actual, también se admiten URL con el esquema URI vista-fuente. Por ejemplo, puede escribir la siguiente URL en la barra de URL para ver el código fuente HTML de la página web qt.io:

view-source:https://www.qt.io/

El autocompletado de URL incompletas con el esquema URI de visualización de origen hace que el uso de esta función sea más cómodo. Por ejemplo, la siguiente URL incompleta también carga la vista de origen de la página web qt.io:

view-source:qt.io

Notificaciones web

Qt WebEngine es compatible con la API de notificaciones web de JavaScript. La aplicación tiene que permitir explícitamente la función utilizando QWebEnginePage::Notifications o WebEngineView.Notifications.

WebEngineDriver

WebEngineDriver permite automatizar las pruebas de sitios web en distintos navegadores. WebEngineDriver se basa en ChromeDriver y puede utilizarse del mismo modo. Para obtener más información sobre ChromeDriver y su uso, visita el sitio del usuario de ChromeDriver.

WebEngineDriver tiene ligeras modificaciones en comparación con ChromeDriver para poder conectarse a navegadores basados en Qt WebEngine. Es compatible con los navegadores de ejemplo Qt WebEngine, como Simple Browser o Nano Browser.

La automatización del navegador se realiza a través de un cliente WebDriver como el Selenium WebDriver. Por ejemplo, WebEngineDriver se puede utilizar con el lenguaje Python de Selenium WebDriver:

from selenium import webdriver
from selenium.webdriver.chrome.service import Service

service = Service(executable_path='QTDIR/libexec/webenginedriver')
options = webdriver.ChromeOptions()
options.binary_location = 'path/to/browser_binary'

driver = webdriver.Chrome(service=service, options=options)
driver.get("http://www.google.com/")
driver.quit()

En este ejemplo,

• executable_path debe establecerse la ruta binaria de WebEngineDriver
• QTDIR es el directorio donde está instalado Qt
• options.binary_location es la ruta binaria del navegador

Antes de ejecutar el script, debe establecerse la variable de entorno QTWEBENGINE_REMOTE_DEBUGGING. Su valor es un número de puerto que utilizan el navegador y WebEngineDriver para comunicarse entre sí.

export QTWEBENGINE_REMOTE_DEBUGGING=12345

Al ejecutarse, el script abre el navegador web especificado y carga el sitio web de Google.

WebEngineDriver también puede adjuntarse a un navegador que ya se esté ejecutando si se inició con el puerto de depuración remota configurado. options.debugger_address debe configurarse con la dirección de depuración remota en la secuencia de comandos:

options.debugger_address = 'localhost:12345'

En este caso, options.binary_location no debe establecerse porque el navegador ya se está ejecutando. La variable de entorno QTWEBENGINE_REMOTE_DEBUGGING no es utilizada por WebEngineDriver si options.debugger_address está configurada.

WebGL

Qt WebEngine soporta WebGL para algunas configuraciones de stacks gráficos. Un usuario puede visitar la página chrome://gpu usando la aplicación QtWebEngine powered. La descripción general del estado de las características gráficas indica si WebGL es compatible con la configuración de la plataforma actual. El usuario también puede consultar el Informe WebGL.

La compatibilidad con WebGL está activada por defecto. Puedes desactivarlo con la configuración de QWebEngineSettings::WebGLEnabled.

WebRTC

WebRTC proporciona a los navegadores capacidades de comunicación en tiempo real (RTC) a través de sencillas API. Para obtener más información, consulte WebEngineView.Feature, y QWebEnginePage::Feature.

Esta función puede probarse configurando una cámara web o un micrófono y abriendo https://test.webrtc.org/ en Simple Browser o Nano Browser.