Qt WebEngine Débogage et profilage

Journalisation de la console

JavaScript exécuté à l'intérieur de Qt WebEngine peut utiliser l'API de la console de Chrome pour enregistrer des informations dans une console. Les messages de journalisation sont transmis aux fonctions de journalisation de Qt XML à l'intérieur de js logging category . Cependant, par défaut, seuls les messages d'avertissement et les messages fatals sont imprimés. Pour changer cela, vous devez soit définir des règles personnalisées pour la catégorie js, soit fournir des gestionnaires de messages personnalisés en réimplémentant QWebEnginePage::javaScriptConsoleMessage(), ou en vous connectant à WebEngineView::javaScriptConsoleMessage().

Tous les messages sont également accessibles via les outils de développement Qt WebEngine.

Qt WebEngine Outils de développement

Le module Qt WebEngine fournit des outils de développement web qui facilitent l'inspection et le débogage des problèmes de mise en page et de performance de n'importe quel contenu web.

Les outils de développement sont accessibles sous la forme d'une page web locale à l'aide d'un navigateur basé sur Chromium ou Qt WebEngine, tel que le navigateur Chrome.

Pour activer les outils de développement, démarrez une application qui utilise Qt WebEngine avec l'argument de ligne de commande --remote-debugging-port=<portnumber>.

--webEngineArgs --remote-debugging-port=<portnumber>

Où <port_number> fait référence à un port de réseau local. Les outils de développement web sont accessibles en lançant un navigateur à l'adresse http://localhost:<port_number>.

Il est également possible de définir la variable d'environnement QTWEBENGINE_REMOTE_DEBUGGING. Elle peut être définie comme un simple port fonctionnant de manière similaire à --remote-debugging-port ou comme une adresse d'hôte et un port. Ce dernier peut être utilisé pour contrôler l'interface réseau sur laquelle exporter l'interface, afin que vous puissiez accéder aux outils de développement à partir d'un périphérique distant.

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 demande. 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.

Pour une explication détaillée des capacités des outils de développement, voir la page Chrome DevTools.

Utilisation des arguments de ligne de commande

Vous pouvez utiliser les arguments de ligne de commande suivants pendant le débogage afin de fournir des informations pour les rapports de bogue :

• --disable-gpu désactive l'accélération matérielle du GPU. Cette option est utile pour diagnostiquer les problèmes liés à OpenGL.
• --disable-logging désactive la journalisation de la console, ce qui peut être utile pour les constructions de débogage.
• --enable-logging --log-level=0 active la journalisation de la console et définit le niveau de journalisation à 0, ce qui signifie que les messages de gravité info et plus sont enregistrés dans le journal. C'est la valeur par défaut pour les versions de débogage. Les autres niveaux de journalisation possibles sont 1 pour les avertissements, 2 pour les erreurs et 3 pour les erreurs fatales.
• --v=1 Augmente le niveau de journalisation au-delà de ce que peut faire --log-level et permet de journaliser les messages de débogage jusqu'au niveau de verbosité 1. Un chiffre plus élevé augmente encore la verbosité, mais peut entraîner un grand nombre de messages enregistrés. La valeur par défaut est 0 (pas de messages de débogage).
• --no-sandbox désactive le bac à sable pour les processus de rendu et de plugin. Gardez à l'esprit que la désactivation du bac à sable peut présenter un risque pour la sécurité.
• --single-process exécute le moteur de rendu et les plugins dans le même processus que le navigateur. Ceci est utile pour obtenir des traces de pile en cas de plantage du moteur de rendu.
• --enable-features=NetworkServiceInProcess exécute le réseau dans le processus principal. Cela peut faciliter la gestion du pare-feu, puisque seul l'exécutable de l'application devra être inscrit sur la liste blanche et non QtWebEngineProcess. Cela signifie cependant que l'on perd la sécurité du sandboxing du service réseau.

Toutes les options de la ligne de commande WebEngine doivent être spécifiées après l'option --webEngineArgs, qui est utilisée pour séparer les options spécifiques à l'application de l'utilisateur de celles de WebEngine.

--webEngineArgs [WebEngine specific options]

Il est également possible de définir la variable d'environnement QTWEBENGINE_CHROMIUM_FLAGS. Par exemple, la valeur suivante peut être définie pour désactiver la journalisation lors du débogage d'une application appelée mybrowser:

QTWEBENGINE_CHROMIUM_FLAGS="--disable-logging" mybrowser

QTWEBENGINE_CHROMIUM_FLAGS peut également être défini à l'aide de qputenv depuis l'application si elle est appelée avant QtWebEngineQuick::initialize().

Vider les informations du WebEngineContext

Pour extraire les informations du WebEngineContext, vous pouvez définir la variable d'environnement QT_LOGGING_RULES à "qt.webenginecontext.debug=true".

La sortie contient des informations sur le backend graphique et sur la manière dont Qt WebEngine est initialisé pour l'application. Ceci est particulièrement utile pour reproduire les problèmes.