Qt WebEngine Fonctionnalités

Qt WebEngine prend en charge les fonctionnalités suivantes :

• Codecs audio et vidéo
• Outils de développement Chromium
• Certificats clients
• Schémas personnalisés
• Glisser-déposer
• Favicon
• Plein écran
• Accélération matérielle
• HTML5 DRM
• Géolocalisation HTML5
• HTML5 WebSockets
• Protocole HTTP/2
• Stockage local
• Dialogues natifs
• Visualisation de fichiers PDF
• API de cycle de vie des pages
• Imprimer en PDF
• Notifications push
• Correcteur orthographique
• Toucher
• Voir la source
• Notifications Web
• WebEngineDriver
• WebGL
• WebRTC

Codecs audio et vidéo

Qt WebEngine Le format de fichier MPEG-4 Part 14 (MP4) n'est pris en charge par Qt que si les codecs audio et vidéo propriétaires requis, tels que H.264 et MPEG layer-3 (MP3), ont été activés. Les codecs propriétaires peuvent être activés en passant l'option suivante à l'outil configure lors de la configuration de Qt Tool :

-webengine-proprietary-codecs

Par exemple, l'option suivante peut être passée lors de la configuration de Qt pour le construire au niveau supérieur :

configure -webengine-proprietary-codecs

Pour plus d'informations, voir les options de configuration de Qt.

Lorsque l'on utilise cmake pour construire uniquement le module Qt WebEngine, la commande suivante peut être utilisée pour configurer et construire (dans cet exemple, le code source de Qt WebEngine est situé dans C:\qt\qtwebengine) :

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

FFmpeg est une solution multiplateforme pour enregistrer, convertir et diffuser de l'audio et de la vidéo. Il peut être configuré pour être utilisé avec plusieurs codecs, ce qui pose des problèmes de licence lors de la distribution avec les bibliothèques de codecs. Pour certains codecs, des implémentations open source, telles que OpenH264, sont disponibles.

Chromium DevTools

Les DevTools de Chromium permettent d'inspecter et de déboguer les problèmes de mise en page et de performance de n'importe quel contenu web.

Cette fonctionnalité peut être testée en lançant une application Qt WebEngine avec l'option de ligne de commande --remote-debugging-port=[your-port] ou en définissant la variable d'environnement QTWEBENGINE_REMOTE_DEBUGGING, puis en utilisant un navigateur basé sur Chromium (tel que Simple Browser ou Nano Browser) pour se connecter à http://localhost:[your-port].

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

Pour éviter les erreurs WebSocket lors du débogage à distance, ajoutez un argument de ligne de commande supplémentaire --remote-allow-origins=<origin>[,<origin>, ...], où <origin> fait référence à l'origine de la requête. Utilisez --remote-allow-origins=* pour autoriser les connexions de toutes les origines. Si rien n'est spécifié, Qt WebEngine ajoutera --remote-allow-origins=* aux arguments de la ligne de commande lorsque le débogage à distance est activé, autorisant ainsi les demandes de toutes les origines.

La page Chromium DevTools peut également être affichée dans l'application. Pour ce faire, vous pouvez appeler soit QWebEnginePage::setInspectedPage() vers la page à inspecter, ce qui charge implicitement les DevTools dans la page this, soit QWebEnginePage::setDevToolsPage() pour permettre à la page this d'être inspectée.

Les propriétés QML correspondantes sont WebEngineView.devToolsView et WebEngineView.inspectedView.

Pour plus d'informations, voir Qt WebEngine Debugging and Profiling.

Certificats des clients

Certains serveurs web, en particulier de nombreux sites intranet, exigent que le client s'authentifie à l'aide d'un certificat, appelé certificat client. Qt WebEngine lira les certificats clients installés dans les paramètres du système sous macOS et Windows, et sous Linux, ceux installés dans la base de données NSS. Les certificats peuvent être installés dans la base de données NSS à l'aide de l'outil pk12util.

Par défaut, Qt WebEngine ne propose aucun certificat client aux serveurs, car cela permet d'identifier l'utilisateur de manière unique et pourrait porter atteinte à la vie privée.

Pour activer la prise en charge des certificats clients, une application doit écouter les signaux QWebEnginePage::selectClientCertificate ou WebEngineView.selectClientCertificate et sélectionner l'un des certificats proposés. Pour les applications qui peuvent naviguer vers des sites web non fiables, il est recommandé de toujours laisser le choix à l'utilisateur avant de l'identifier de manière unique auprès d'un serveur distant.

En plus du certificat client stocké dans les paramètres du système, Qt WebEngine propose également le stockage en mémoire. L'instance QWebEngineClientCertificateStore peut être obtenue avec la méthode QWebEngineProfile::clientCertificateStore(). Une application peut utiliser cette classe pour ajouter un nouveau certificat avec un appel QWebEngineClientCertificateStore::add(). Notez que lors des appels à selectClientCertificate, Qt WebEngine répertorie les certificats des clients stockés dans le système et en mémoire.

Voir également l'exemple de certificat client pour plus de détails sur la mise en œuvre.

Schémas personnalisés

Qt WebEngine permet à l'application de définir ses propres schémas d'URL personnalisés avec des politiques de sécurité et des mécanismes de transport spécialisés.

Les schémas personnalisés peuvent être utilisés pour mettre en œuvre des protocoles réseau alternatifs avec toutes les politiques de sécurité web habituelles, des schémas internes privilégiés pour afficher des composants d'interface utilisateur ou des informations de débogage, des schémas en bac à sable avec des restrictions supplémentaires, et ainsi de suite.

Pour plus d'informations, voir QWebEngineUrlScheme et QWebEngineUrlSchemeHandler.

Glisser-déposer

Qt WebEngine prend en charge le glisser-déposer HTML5.

Cette fonctionnalité peut être testée en ouvrant une démo HTML5 de glisser-déposer, telle que HTML5 Demos - Drag and Drop, HTML5 Demos - Simple Drag and Drop , ou HTML5 Demos - Drag and Drop, Automatic Upload, dans Simple Browser ou Nano Browser.

Le glissement de fichiers dans le navigateur ne fait pas partie du HTML5, mais il est pris en charge. Il peut être testé en ouvrant HTML5 Demos - File API.

Favicon

Qt WebEngine prend en charge l'icône de l'URL du site web, favicon. Chaque icône est stockée dans la base de données interne de chaque site QWebEngineProfile et peut être consultée à l'aide d'un appel QWebEnginePage::icon() ou d'une propriété WebEngineView.icon pour le contenu actuellement chargé.

En outre, Qt WebEngine fournit une API permettant d'accéder aux icônes déjà stockées dans la base de données interne du profil.

Gestion du Favicon QML

Pour accéder aux icônes, un site QQuickImageProvider est enregistré. Ce fournisseur est accessible par une URL spéciale où le schéma est "image :" et l'hôte "favicon".

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

L'adresse url peut être l'URL du favicon :

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

Le url peut également être l'URL d'une page pour accéder à son icône :

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

Si plusieurs icônes sont disponibles, la propriété Image::sourceSize peut être spécifiée pour choisir l'icône de la taille souhaitée. Si la propriété Image::sourceSize n'est pas spécifiée ou si elle est égale à 0, c'est la plus grande icône disponible qui sera choisie.

Le fournisseur d'images recherche l'icône demandée dans les instances WebEngineView existantes. Il tente d'abord de trouver une correspondance avec les icônes actuellement affichées. Si aucune correspondance n'est trouvée, il demande l'icône dans la base de données. Chaque profil possède sa propre base de données d'icônes, qui est stockée dans la mémoire permanente, de sorte que les icônes stockées sont également accessibles sans connexion réseau. L'icône doit avoir été chargée au préalable pour être stockée dans la base de données.

Gestion des icônes C++

Un utilisateur peut demander une icône à partir du contenu précédemment chargé pour chaque QWebEngineProfile en utilisant les appels QWebEngineProfile::requestIconForPageURL() ou QWebEngineProfile::requestIconForIconURL(). Notez que la base de données du profil est stockée dans la mémoire persistante et peut être consultée sans connexion réseau.

Plein écran

Qt WebEngine prend en charge l'affichage du contenu web en mode plein écran. Pour plus d'informations, voir WebEngineSettings.fullscreenSupportEnabled, WebEngineView.fullScreenRequested, QWebEngineSettings::FullScreenSupportEnabled, et QWebEnginePage::fullScreenRequested.

Cette fonctionnalité peut être testée en lisant une vidéo de YouTube dans Video Player ou Nano Browser, et en cliquant sur l'icône plein écran pour passer en mode plein écran.

Accélération matérielle

Qt WebEngine tente d'utiliser l'accélération matérielle pour le rendu du contenu web chaque fois que cela est possible. Le rendu proprement dit est effectué par Chromium, et l'image finale est produite par le compositeur de Chromium, qui utilise des API GPU modernes telles que OpenGL, Vulkan, Metal ou Direct3D, en fonction de la plateforme et des pilotes disponibles.

Cette image finale est ensuite importée par Qt WebEngine dans le pipeline de rendu Qt XML à l'aide de l'interopérabilité GPU, ce qui permet un partage efficace des ressources GPU sans copies inutiles. L'image importée est transmise à Qt Quick Scene Graphs, qui effectue également un rendu accéléré par le matériel grâce à l'interface matérielle de rendu Qt (RHI).

Bien que Qt et Chromium s'appuient tous deux sur l'accélération GPU, ils n'utilisent pas nécessairement la même API graphique. En pratique, Qt WebEngine tente d'aligner le backend GPU de Chromium avec celui utilisé par Qt lorsque cela est possible, en adoptant par défaut la configuration de backend choisie par Qt pour assurer la compatibilité et des performances optimales, bien qu'il soit possible d'outrepasser manuellement ces valeurs par défaut si nécessaire.

Lorsque l'accélération matérielle n'est pas disponible ou échoue, Qt WebEngine tente automatiquement de revenir au rendu logiciel.

Forcer l'utilisation du rendu logiciel

Le retour automatique au rendu logiciel n'est pas toujours possible, et Qt WebEngine peut ne pas afficher correctement le contenu web ou se terminer par un message d'erreur. Dans ce cas, il peut être nécessaire de désactiver explicitement l'accélération matérielle et d'utiliser le rendu logiciel à la place.

Il existe plusieurs façons de forcer le rendu logiciel :

• Désactiver l'accélération matérielle dans Chromium :

  export QTWEBENGINE_CHROMIUM_FLAGS=--disable-gpu

• Désactiver l'accélération matérielle dans Qt Quick Scene Graph:

  export QT_QUICK_BACKEND=software

Changer le backend de l'API graphique dans Qt

Il y a deux façons de choisir le backend de l'API graphique :

• Définir la variable d'environnement QSG_RHI_BACKEND avant de lancer l'application.
• Appeler QQuickWindow::setGraphicsApi() en combinaison avec QSGRendererInterface::GraphicsApi avant de construire le premier QQuickWindow.

Pour plus de détails, voir Rendu via l'interface matérielle de rendu Qt.

Modification du backend de l'API graphique dans Chromium

Il n'est généralement pas recommandé de modifier le backend de l'API graphique de Chromium, car cela peut entraîner des problèmes de compatibilité ou un comportement de rendu incohérent. Dans la mesure du possible, préférez utiliser la variable d'environnement QSG_RHI_BACKEND. Cependant, cela peut être nécessaire dans certains cas pour le débogage ou comme solution temporaire pour des problèmes spécifiques aux pilotes.

Pour remplacer le backend de Chromium, définissez la variable d'environnement QTWEBENGINE_CHROMIUM_FLAGS afin qu'elle transmette les drapeaux de ligne de commande Chromium correspondants, tels que --use-gl= ou --use-angle=.

Sur Qt WebEngine, Chromium utilise actuellement le backend ANGLE par défaut sur toutes les plateformes où l'accélération matérielle est prise en charge. ANGLE est une couche d'abstraction graphique multiplateforme dans Chromium qui cache le backend graphique natif sous-jacent.

La configuration par défaut utilisée par Qt WebEngine est la suivante :

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

Si ANGLE plante dans une configuration spécifique, il peut être complètement désactivé tout en continuant à utiliser Vulkan pour le rendu avec accélération matérielle :

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

Alternativement, la configuration suivante utilise Vulkan pour le rendu tout en gardant ANGLE activé pour la prise en charge de WebGL:

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

Pour plus de détails sur les drapeaux de ligne de commande correspondants de Chromium, voir le code source de Chromium : //ui/gl/gl_switches.cc

NVIDIA sous Linux

Sur les systèmes Linux équipés d'un GPU NVIDIA, Chromium est obligé d'utiliser Vulkan pour le rendu.

Qt WebEngine Vulkan utilise des objets tampons GBM pour importer les textures de Chromium dans le pipeline graphique de Qt. Cependant, les pilotes NVIDIA ne prennent actuellement pas en charge l'allocation de ces objets tampons. Comme solution de contournement, Qt WebEngine force Chromium à effectuer le rendu avec Vulkan et importe les textures en utilisant l'interopérabilité Vulkan.

Activer la journalisation et le dépannage

Lorsqu'un problème de rendu survient, il est important de connaître la configuration défaillante et l'état actuel de l'accélération matérielle afin d'enquêter et de signaler le problème de manière efficace.

Le moyen le plus simple de vérifier ces informations est de charger la page interne chrome://gpu et d'analyser son contenu. Cependant, cette page n'est pas toujours lisible ou disponible lors d'un problème de rendu.

Qt WebEngine fournit des catégories de journalisation qui peuvent être activées pour déverser des informations graphiques détaillées :

• qt.webenginecontext enregistre la façon dont Qt WebEngine a été initialisé, le GPU détecté et la configuration graphique.
• qt.webengine.compositor enregistre la configuration utilisée par Chromium et les étapes suivies par Qt WebEngine pour importer des textures dans le pipeline graphique de Qt.

Pour activer ces journaux, définissez la variable d'environnement QT_LOGGING_RULES, par exemple :

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

Voici un exemple de journal GPU provenant 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

Le premier bloc présente la configuration de Chromium :

• Chromium GL Backend indique la valeur du paramètre --use-gl=.
• Chromium ANGLE Backend indique la valeur du paramètre --use-angle=.
• Chromium Vulkan Backend indique la valeur du paramètre --use-vulkan=.

Le deuxième bloc présente la configuration Qt :

• QSG RHI Backend indique l'API graphique native sous-jacente.
• QSG RHI Backend Supported indique si cette API graphique est prise en charge par Qt WebEngine.
• QSG RHI Device indique les métadonnées du périphérique graphique utilisé par le RHI.
• QSG RHI Vendor indique le fournisseur du périphérique graphique utilisé par le RHI.

Voici un exemple de journal ANGLE provenant de qt.webengine.compositor pour le même 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

Les entrées de journal ci-dessus indiquent :

• ANGLE_OPENGL display is initialized confirme que ANGLE a été initialisé avec succès avec le type d'affichage spécifié.
• GL Renderer montre les métadonnées du périphérique graphique utilisé par ANGLE (qui devrait correspondre à QSG RHI Device).
• 2 GPU(s) detected liste les GPU détectés par ANGLE.
• NVIDIA Optimus et AMD Switchable indiquent si ANGLE prend en charge le changement de GPU au moment de l'exécution (actuellement non pris en charge).

HTML5 DRM

Qt WebEngine permet d'afficher des vidéos protégées par DRM si le plugin Widevine CDM a été installé. Le plugin n'est fourni que dans un format binaire, de sorte qu'il peut cacher les détails de l'implémentation du décryptage des DRM. Vous pouvez l'obtenir auprès d'un tiers ou d'une installation de Google Chrome.

Au démarrage, Qt WebEngine recherche le plugin Widevine CDM dans plusieurs emplacements bien connus, comme le répertoire d'installation par défaut de Google Chrome, ou des chemins spécifiques aux distributions Linux. Vous pouvez également transmettre l'emplacement du plugin avec QTWEBENGINE_CHROMIUM_FLAGS en utilisant widevine-path.

Sous Windows :

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

Sous Linux :

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

Sous macOS :

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

Le format vidéo le plus couramment utilisé par les services DRM, H.264, nécessite des codecs audio et vidéo propriétaires. Pour plus d'informations sur l'activation des codecs, voir Codecs audio et vidéo.

Vous pouvez tester cette fonctionnalité en lisant une vidéo à partir de castLabs ou de Bitmovin Player dans les projets d'exemple Simple Browser ou Nano Browser.

Géolocalisation HTML5

Qt WebEngine prend en charge l'API de géolocalisation JavaScript avec Qt Positioning comme backend. La géolocalisation HTML5 est désactivée par défaut. Pour l'autoriser explicitement, l'application doit écouter QWebEnginePage::permissionRequested. Lorsqu'une demande de permission de type QWebEnginePermission::PermissionType::Geolocation est reçue, vous pouvez appeler QWebEnginePermission::grant() sur l'objet reçu pour accorder la permission requise.

Si Qt WebEngine a été construit avec le support de Qt Positioning, cette fonctionnalité peut être testée en utilisant Maps et en lui permettant de trouver la position actuelle de l'utilisateur.

Voir Qt Positioning pour une configuration possible du backend comme le GPS ou le positionnement basé sur l'IP.

Permissions HTML5

Qt WebEngine HTML5 a pris en charge plusieurs types de permissions pour les fonctionnalités web via l'API QWebEnginePermission. Des permissions peuvent être accordées (ou refusées) à un domaine web chaque fois qu'une page demande des informations potentiellement sensibles sur l'utilisateur, comme l'accès à la caméra ou à la géolocalisation de l'utilisateur.

Les développeurs d'applications peuvent choisir de demander l'autorisation à l'utilisateur final ou de prendre automatiquement la décision à sa place. En outre, ils peuvent accorder ou refuser certaines autorisations de manière anticipée, dans les cas où un domaine connu est censé les demander.

L'objet QWebEngineProfile stocke toutes les autorisations qui ont été accordées ou refusées à des domaines individuels. À moins que le profil actuel ne soit pas enregistré, ces autorisations sont stockées sur le disque et rappelées lors de la prochaine ouverture d'une application. Toutefois, ce comportement peut être modifié et les développeurs peuvent choisir de ne stocker les autorisations que jusqu'à la sortie de l'application, ou même de déclencher des demandes d'autorisation à chaque fois qu'un site web en fait la demande.

La liste complète des autorisations Web actuellement prises en charge est disponible à l'adresse suivante : in the QWebEnginePermission documentation.

Cadres

À l'aide de l'API QWebEngineFrame, les développeurs peuvent inspecter et interagir avec des éléments <iframe> individuels au sein d'une page web. Cela peut être utilisé pour injecter du JavaScript ou pour imprimer uniquement le contenu du cadre, sans tenir compte de la page dans laquelle il est intégré. Il est également possible d'accéder aux cadres de manière récursive, dans les cas où des cadres existent à l'intérieur d'autres cadres.

HTML5 WebSockets

Qt WebEngine prend en charge l'API JavaScript WebSocket pour communiquer avec les serveurs WebSocket à l'aide des protocoles ws:// ou wss://. De plus, l'intégration avec Qt WebChannel et Qt WebSockets permet la communication entre JavaScript et le côté natif de l'application.

Le module Qt WebChannel présente un excellent exemple de serveur de chat et de son client de chat basé sur le web. Le client fonctionne d'emblée dans les exemples de navigateurs de Qt WebEngine (tels que Simple Browser ou Nano Browser).

Protocole HTTP/2

Qt WebEngine supporte l'implémentation Chromium du protocole HTTP/2.

Cette fonctionnalité peut être testée en ouvrant une démo HTTP/2, telle que la démo HTTP/2 d'Akamai, dans Simple Browser ou Nano Browser.

Stockage local

Qt WebEngine prend en charge l'enregistrement de paires clé-valeur dans un fichier Local Storage sans date d'expiration. Il s'agit d'une partie de l'API de stockage web, où un utilisateur peut accéder à un objet Storage pour les domaines donnés à l'aide de la propriété JavaScript Window.localStorage. Les données stockées persistent même après la fermeture de la page ou de l'application du navigateur.

Notez que le stockage Local peut également être désactivé à l'aide d'un paramètre QWebEngineSettings::LocalStorageEnabled. En outre, le chemin de stockage peut être modifié par un appel à QWebEngineProfile::setPersistentStoragePath.

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

Qt WebEngine Le siteQt WebEngine Developer Tools offre également un moyen facile d'examiner le contenu du site Local Storage en visitant le panneau Application et en développant le menu Local Storage.

Dialogues natifs

Une page web peut demander des boîtes de dialogue pour les fonctions suivantes :

• saisie des informations d'identification de l'utilisateur pour l'authentification HTTP et proxy
• Affichage d'alertes JavaScript, de boîtes de dialogue de confirmation et d'invites
• Choix des couleurs
• Sélection de fichiers
• Affichage des messages de validation des formulaires

Qt WebEngine fournit des boîtes de dialogue standard pour ces fonctions. Dans les applications basées sur des widgets, les boîtes de dialogue standard sont basées sur QDialog, tandis que dans les applications Qt Quick, elles peuvent être basées sur Qt Quick Controls 1 ou Qt Quick Controls 2. Ces derniers ne sont utilisés que sur les plates-formes eglfs.

Pour forcer explicitement les boîtes de dialogue basées sur Qt Quick Controls 1 ou Qt Quick Controls 2, définissez la variable d'environnement QTWEBENGINE_DIALOG_SET sur QtQuickControls1 ou QtQuickControls2.

Qt WebEngine Les boîtes de dialogue des widgets peuvent être personnalisées en réimplémentant les fonctions QWebEnginePage::chooseFiles(), QWebEnginePage::javaScriptAlert(), QWebEnginePage::javaScriptConfirm() et QWebEnginePage::javaScriptPrompt().

Qt Quick Les boîtes de dialogue peuvent être personnalisées en se connectant aux signaux WebEngineView::authenticationDialogRequested(), WebEngineView::javaScriptDialogRequested(), WebEngineView::colorDialogRequested(), WebEngineView::fileDialogRequested() et WebEngineView::formValidationMessageRequested().

Visualisation de fichiers PDF

Qt WebEngine permet de visualiser des documents PDF en naviguant jusqu'à eux. Cette fonctionnalité utilise l'API d'extensions de Chromium et le plugin de visualisation PDF pour afficher les documents PDF. Elle peut être testée dans Simple Browser ou Nano Browser.

Cette fonctionnalité peut être activée (par défaut) ou désactivée via les paramètres QWebEngineSettings::PdfViewerEnabled ou WebEngineSettings::pdfViewerEnabled.

API de cycle de vie des pages

Qt WebEngine prend en charge la spécification Page Lifecycle API, une extension en cours de la norme HTML permettant aux agents utilisateurs de réduire leur consommation de ressources en gelant ou en supprimant les pages d'arrière-plan. Cette fonctionnalité est exposée à la fois dans les API Widgets et QML.

Pour un exemple d'utilisation de l'API QML, voir l'exemple de cycle de vie WebEngine.

Vue d'ensemble des états du cycle de vie

Chaque élément WebEngineView (ou objet QWebEnginePage ) peut se trouver dans l'un des trois états de cycle de vie suivants : actif, gelé ou supprimé. Ces états, comme les états de veille d'une unité centrale, contrôlent l'utilisation des ressources des vues Web.

L'état actif est l'état normal, sans restriction, d'une vue web. Toutes les vues Web visibles sont toujours dans l'état actif, de même que toutes les vues Web dont le chargement n'est pas encore terminé. Seules les vues Web invisibles et inactives peuvent passer à d'autres états du cycle de vie.

L'état gelé est un état de faible utilisation du processeur. Dans cet état, la plupart des sources de tâches HTML sont suspendues (gelées) et, par conséquent, la plupart des traitements d'événements DOM et l'exécution JavaScript sont également suspendus. La vue web doit être invisible pour être gelée, car le rendu n'est pas possible dans cet état.

L'état "jeté" est un état d'économie de ressources extrême. Dans cet état, le contexte de navigation de la vue web est supprimé et le sous-processus de rendu correspondant est arrêté. L'utilisation de l'unité centrale et de la mémoire dans cet état est pratiquement réduite à zéro. Lorsque l'on quitte cet état, la page web est automatiquement rechargée. Le processus d'entrée et de sortie de l'état d'abandon est similaire à la sérialisation de l'historique de navigation de la vue web et à la destruction de la vue, puis à la création d'une nouvelle vue et à la restauration de son historique.

Voir également WebEngineView::LifecycleState. L'équivalent dans l'API Widgets est QWebEnginePage::LifecycleState.

Propriétés lifecycleState et recommendedState

La propriété lifecycleState du type WebEngineView est une propriété en lecture-écriture qui contrôle l'état actuel du cycle de vie de la vue Web. Cette propriété est conçue pour imposer le moins de restrictions possible sur les états vers lesquels il est possible de passer. Par exemple, il est permis de geler une vue web qui joue actuellement de la musique en arrière-plan, en arrêtant la musique. Pour mettre en œuvre une stratégie d'économie de ressources moins agressive qui évite d'interrompre l'activité d'arrière-plan visible par l'utilisateur, la propriété recommendedState doit être utilisée.

La propriété recommendedState du type WebEngineView est une propriété en lecture seule qui calcule une limite sûre pour la propriété lifecycleState, en tenant compte de l'activité actuelle de la vue web. Ainsi, dans l'exemple d'une vue web jouant de la musique en arrière-plan, l'état recommandé sera Active car un état plus agressif arrêterait la musique. Si l'application veut éviter d'interrompre l'activité en arrière-plan, elle doit éviter de placer la vue web dans un état de cycle de vie d'économie de ressources plus agressif que celui donné par recommendedState.

Voir également WebEngineView::lifecycleState et WebEngineView::recommendedState. Les équivalents dans l'API Widgets sont QWebEnginePage::lifecycleState et QWebEnginePage::recommendedState.

Les extensions DOM

La propriété lifecycleState est liée à la spécification de l'API Page Lifecycle, qui spécifie deux nouveaux événements DOM, freeze et resume, et ajoute une nouvelle propriété booléenne Document.wasDiscarded. Les événements freeze et resume sont déclenchés lors de la transition de Active à Frozen state et vice-versa. La propriété Document.wasDiscarded est définie sur true lors de la transition de l'état Discarded à l'état Active.

Imprimer en PDF

Qt WebEngine permet d'imprimer une page web dans un fichier PDF. Pour plus d'informations, voir QWebEnginePage::printToPdf() et WebEngineView.printToPdf.

Cette fonctionnalité peut être testée à l'aide de Html2Pdf.

Notifications push

Qt WebEngine prend en charge l'API JavaScript Push pour s'abonner à des notifications push et en recevoir. Pour plus d'informations, voir QWebEngineProfile::setPushServiceEnabled() et WebEngineProfile.setPushServiceEnabled.

Cette fonctionnalité peut être testée avec l'exemple WebEngine Push Notifications.

Correcteur orthographique

Qt WebEngine permet d'intégrer un correcteur orthographique dans les formulaires HTML afin de permettre aux utilisateurs de soumettre des messages dont l'orthographe a été vérifiée. Lorsque l'utilisateur clique sur un mot mal orthographié souligné, le menu contextuel par défaut affiche jusqu'à quatre suggestions. La sélection de l'une d'entre elles remplacera le mot mal orthographié.

Pour pouvoir vérifier l'orthographe, le correcteur orthographique a besoin de dictionnaires. Il prend en charge les dictionnaires du projet Hunspell, mais ils doivent être compilés dans un format binaire spécial. Un dictionnaire Hunspell se compose de deux fichiers :

• un fichier .dic qui est un dictionnaire contenant les mots de la langue
• Un fichier .aff qui définit la signification des drapeaux spéciaux dans le dictionnaire.

Ces deux fichiers peuvent être convertis au format bdic à l'aide de l'outil qwebengine_convert_dict fourni avec Qt XML. Lorsque le correcteur orthographique Qt WebEngine s'initialise, il essaie de charger les dictionnaires bdict et de vérifier leur cohérence.

Pour CMake, vous pouvez utiliser la commande qt_add_webengine_dictionary pour convertir les fichiers Hunspell .dic au format binaire .bdic. La commande crée une cible qtwebengine_dictionaries, dont votre projet peut utiliser une dépendance.

Par défaut, Qt WebEngine recherche les dictionnaires dans le répertoire qtwebengine_dictionaries relatif à l'exécutable s'il existe. S'il n'existe pas, il cherchera dans QT_INSTALL_PREFIX/qtwebengine_dictionaries.

Le chemin d'accès au répertoire des dictionnaires peut également être défini en tant que valeur de la variable d'environnement QTWEBENGINE_DICTIONARIES_PATH ou via la ligne de commande :

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

Lorsqu'une dérogation est définie, l'application ne recherche les dictionnaires que dans le répertoire fourni, et nulle part ailleurs.

Sur macOS, en fonction de la configuration de Qt WebEngine au moment de la compilation, il existe deux possibilités pour trouver les données de vérification orthographique :

• Dictionnaires Hunspell (par défaut) - les dictionnaires .bdic sont utilisés, comme sur les autres plateformes.
• Dictionnaires natifs - les API de vérification orthographique de macOS sont utilisées (ce qui signifie que les résultats dépendront des dictionnaires installés dans le système d'exploitation).

Ainsi, dans le cas de macOS Hunspell, Qt WebEngine cherchera dans le sous-répertoire qtwebengine_dictionaries situé dans le répertoire Resources du bundle d'applications, ainsi que dans le répertoire Resources situé dans le bundle du framework Qt.

En résumé, en cas d'utilisation de Hunspell, les chemins suivants sont pris en compte :

• QTWEBENGINE_DICTIONARIES_PATH, s'il est défini
• QCoreApplication::applicationDirPath()/qtwebengine_dictionaries ou QCoreApplication::applicationDirPath()/../Contents/Resources/qtwebengine_dictionaries (sur macOS)
• [QLibraryInfo::DataPath]/qtwebengine_dictionaries ou path/to/QtWebEngineCore.framework/Resources/qtwebengine_dictionaries (Qt framework bundle sur macOS)

La vérification orthographique est désactivée par défaut et peut être activée par profil en utilisant la méthode QWebEngineProfile::setSpellCheckEnabled() dans les applications basées sur des widgets et la propriété WebEngineProfile.spellCheckEnabled dans les applications Qt Quick.

La langue courante utilisée pour la vérification orthographique est définie par profil et peut être définie à l'aide de la méthode QWebEngineProfile::setSpellCheckLanguages() ou de la propriété WebEngineProfile.spellCheckLanguages.

Cette fonctionnalité peut être testée en construisant et en exécutant l'exemple de correcteur orthographique.

Qt WebEngine peut également être compilé sans la prise en charge du correcteur orthographique en utilisant le commutateur webengine-spellchecker configure.

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

Pour plus d'informations, voir Qt Configure Options.

Toucher

Qt WebEngine prend en charge les dispositifs tactiles pour la navigation et l'interaction avec les pages web.

La prise en charge des événements tactiles dans l'API JavaScript dépend de la présence d'un écran tactile (c'est-à-dire que ontouchstart et les gestionnaires correspondants seront présents dans l'objet document.window si un appareil tactile capable est connecté au système).

Certains sites web utilisent cette API pour décider s'ils fonctionnent sur un appareil mobile ou sur un ordinateur de bureau et basent leur conception sur cette décision. Cela peut entraîner des résultats indésirables sur les ordinateurs portables à écran tactile ou sur d'autres configurations qui émulent un faux périphérique tactile.

Les applications peuvent définir explicitement cette fonctionnalité à l'aide de QWebEngineSettings::TouchEventsApiEnabled.

Notez que les événements tactiles seront toujours transmis aux pages web même si l'API est désactivée. L'envoi d'événements tactiles aux pages web peut être interdit en installant un objet de filtrage d'événements à l'aide de QObject::installEventFilter sur l'objet proxy de focalisation de la vue WebEngine, et en filtrant tous les événements tactiles.

Voir la source

Qt WebEngine permet de visualiser la source HTML d'une page web.

Cette fonction peut être utilisée à partir de menus personnalisés ou assignée à des événements personnalisés. Pour plus d'informations, voir WebEngineView::WebAction, et QWebEnginePage::WebAction.

Cette fonctionnalité peut être testée en ouvrant une page web dans Simple Browser ou Nano Browser, puis en sélectionnant Page Source dans le menu contextuel. L'entrée du menu contextuel Page Source ouvre la vue de la source dans un nouvel onglet.

Pour ouvrir la vue source dans l'onglet actuel, les URL avec le schéma URI vue-source sont également pris en charge. Par exemple, vous pouvez taper l'URL suivante dans la barre d'URL pour afficher la source HTML de la page web qt.io :

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

L'auto-complétion des URLs incomplètes avec le schéma URI view-source rend l'utilisation de cette fonctionnalité plus confortable. Par exemple, l'URL incomplète suivante charge également la vue source de la page web qt.io :

view-source:qt.io

Notifications Web

Qt WebEngine prend en charge l'API JavaScript de notifications Web. L'application doit explicitement autoriser cette fonctionnalité en utilisant QWebEnginePage::Notifications ou WebEngineView.Notifications.

Pilote WebEngine

Avec WebEngineDriver, vous pouvez automatiser les tests de sites web sur l'ensemble des navigateurs. WebEngineDriver est basé sur ChromeDriver et peut être utilisé de la même manière. Pour plus d'informations sur ChromeDriver et son utilisation, visitez le site utilisateur de ChromeDriver.

WebEngineDriver a subi de légères modifications par rapport à ChromeDriver pour pouvoir se connecter aux navigateurs basés sur Qt WebEngine. Il est compatible avec les exemples de navigateurs Qt WebEngine, tels que Simple Browser ou Nano Browser.

L'automatisation du navigateur est scriptée par l'intermédiaire d'un client WebDriver tel que Selenium WebDriver. Par exemple, WebEngineDriver peut être utilisé avec le langage 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()

Dans cet exemple,

• executable_path doit être défini comme le chemin binaire de WebEngineDriver
• QTDIR est le répertoire dans lequel Qt est installé
• options.binary_location doit être défini comme le chemin binaire du navigateur

Avant d'exécuter le script, la variable d'environnement QTWEBENGINE_REMOTE_DEBUGGING doit être définie. Sa valeur est un numéro de port utilisé par le navigateur et le WebEngineDriver pour communiquer entre eux.

export QTWEBENGINE_REMOTE_DEBUGGING=12345

En s'exécutant, le script ouvre le navigateur web spécifié et charge le site web de Google.

WebEngineDriver peut également être attaché à un navigateur déjà en cours d'exécution s'il a été démarré avec le port de débogage à distance défini. options.debugger_address doit être défini à l'adresse de débogage à distance dans le script :

options.debugger_address = 'localhost:12345'

Dans ce cas, options.binary_location ne doit pas être défini car le navigateur est déjà en cours d'exécution. La variable d'environnement QTWEBENGINE_REMOTE_DEBUGGING n'est pas utilisée par le WebEngineDriver si options.debugger_address est défini.

WebGL

Qt WebEngine supporte WebGL pour certaines configurations de piles graphiques. Un utilisateur peut visiter la page chrome://gpu en utilisant l'application QtWebEngine. La vue d'ensemble de l'état des fonctionnalités graphiques indique si WebGL est pris en charge pour la configuration actuelle de la plateforme. L'utilisateur peut également consulter le rapport WebGL.

La prise en charge de WebGL est activée par défaut. Vous pouvez la désactiver à l'aide du paramètre QWebEngineSettings::WebGLEnabled.

WebRTC

WebRTC fournit aux navigateurs des capacités de communication en temps réel (RTC) via des API simples. Pour plus d'informations, voir WebEngineView.Feature, et QWebEnginePage::Feature.

Cette fonctionnalité peut être testée en installant une webcam ou un microphone, puis en ouvrant https://test.webrtc.org/ dans Simple Browser ou Nano Browser.