Qt WebEngine Funktionen

Qt WebEngine unterstützt die folgenden Funktionen:

• Audio- und Video-Codecs
• WebEngineDriver
• Chromium-Entwicklungstools
• Client-Zertifikate
• Benutzerdefinierte Schemata
• Ziehen und Ablegen
• Favicon
• Vollbild
• Hardware-Beschleunigung
• HTML5-DRM
• HTML5 Geolokalisierung
• HTML5 WebSockets
• HTTP/2-Protokoll
• Lokale Speicherung
• Native Dialoge
• Anzeige von PDF-Dateien
• Seiten-Lebenszyklus-API
• Drucken in PDF
• Prozess-Modelle
• Rechtschreibprüfung
• Berühren Sie
• Quelle anzeigen
• Web-Benachrichtigungen
• WebGL
• WebRTC

Audio- und Videocodecs

Qt WebEngine unterstützt das MPEG-4 Part 14 (MP4) Dateiformat nur, wenn die erforderlichen proprietären Audio- und Videocodecs, wie H.264 und MPEG Layer-3 (MP3), aktiviert wurden. Proprietäre Codecs können aktiviert werden, indem bei der Konfiguration von Qt die folgende Option an das Tool configure übergeben wird:

-webengine-proprietary-codecs

Zum Beispiel könnte die folgende Option bei der Konfiguration von Qt übergeben werden, um es auf der obersten Ebene zu bauen:

configure -webengine-proprietary-codecs

Weitere Informationen finden Sie unter Qt-Konfigurationsoptionen.

Wenn cmake verwendet wird, um nur das Modul Qt WebEngine zu bauen, kann der folgende Befehl zum Konfigurieren und Bauen verwendet werden (in diesem Beispiel befindet sich der Quellcode von Qt WebEngine in C:\qt\qtwebengine):

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

FFmpeg ist eine plattformübergreifende Lösung zum Aufnehmen, Konvertieren und Streamen von Audio und Video. Es kann für die Verwendung mit verschiedenen Codecs konfiguriert werden, wodurch sich bei der Verteilung mit den Codec-Bibliotheken Lizenzierungsprobleme ergeben. Für einige Codecs sind Open-Source-Implementierungen, wie OpenH264, verfügbar.

WebEngineDriver

Mit WebEngineDriver können Sie das Testen von Websites in verschiedenen Browsern automatisieren. WebEngineDriver basiert auf ChromeDriver und kann auf die gleiche Weise verwendet werden. Weitere Informationen über ChromeDriver und seine Verwendung finden Sie auf der ChromeDriver-Benutzerseite.

WebEngineDriver weist im Vergleich zu ChromeDriver leichte Änderungen auf, um eine Verbindung zu Qt WebEngine basierten Browsern herstellen zu können. Er ist kompatibel mit Qt WebEngine Beispielbrowsern, wie Simple Browser oder Nano Browser.

Die Browser-Automatisierung wird über einen WebDriver-Client wie den Selenium WebDriver gesteuert. Zum Beispiel kann WebEngineDriver mit den Python-Sprachbindungen von Selenium WebDriver verwendet werden:

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()

In diesem Beispiel,

• executable_path muss auf den Binärpfad des WebEngineDriver gesetzt werden
• QTDIR ist das Verzeichnis, in dem Qt installiert ist
• options.binary_location muss auf den Binärpfad des Browsers gesetzt werden

Bevor das Skript ausgeführt wird, muss die Umgebungsvariable QTWEBENGINE_REMOTE_DEBUGGING gesetzt werden. Ihr Wert ist eine Portnummer, die sowohl vom Browser als auch vom WebEngineDriver für die Kommunikation untereinander verwendet wird.

export QTWEBENGINE_REMOTE_DEBUGGING=12345

Wenn das Skript ausgeführt wird, öffnet es den angegebenen Webbrowser und lädt die Google-Website.

WebEngineDriver kann auch an einen bereits laufenden Browser angehängt werden, wenn dieser mit dem eingestellten Remote-Debugging-Port gestartet wurde. options.debugger_address muss im Skript auf die Remote-Debugging-Adresse gesetzt werden:

options.debugger_address = 'localhost:12345'

In diesem Fall sollte options.binary_location nicht gesetzt werden, da der Browser bereits läuft. Die Umgebungsvariable QTWEBENGINE_REMOTE_DEBUGGING wird vom WebEngineDriver nicht verwendet, wenn options.debugger_address gesetzt ist.

Chromium DevTools

Die Chromium DevTools bieten die Möglichkeit, Layout- und Leistungsprobleme beliebiger Webinhalte zu untersuchen und zu beheben.

Diese Funktion kann getestet werden, indem eine Qt WebEngine Anwendung mit der Kommandozeilenoption --remote-debugging-port=[your-port] gestartet wird oder indem die Umgebungsvariable QTWEBENGINE_REMOTE_DEBUGGING gesetzt wird und dann ein Chromium-basierter Browser (wie Simple Browser oder Nano Browser) verwendet wird, um eine Verbindung zu http://localhost:[your-port] herzustellen.

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

Um WebSocket-Fehler beim Remote-Debugging zu vermeiden, fügen Sie ein zusätzliches Befehlszeilenargument --remote-allow-origins=<origin>[,<origin>, ...] hinzu, wobei <origin> auf den Ursprung der Anfrage verweist. Verwenden Sie --remote-allow-origins=*, um Verbindungen aus allen Herkunftsländern zuzulassen. Wenn nichts angegeben wird, fügt Qt WebEngine --remote-allow-origins=* zu den Befehlszeilenargumenten hinzu, wenn Remote-Debugging aktiviert ist, und erlaubt so Anfragen von allen Ursprüngen.

Die Chromium DevTools-Seite kann auch innerhalb der Anwendung angezeigt werden. Um dies einzurichten, kann man entweder QWebEnginePage::setInspectedPage() für die zu inspizierende Seite aufrufen, was implizit die DevTools in die this Seite lädt, oder QWebEnginePage::setDevToolsPage(), um die this Seite inspizieren zu lassen.

Die entsprechenden QML-Eigenschaften sind WebEngineView.devToolsView und WebEngineView.inspectedView.

Weitere Informationen finden Sie unter Qt WebEngine Debugging und Profiling.

Client-Zertifikate

Einige Webserver, insbesondere viele Intranetseiten, verlangen, dass sich der Client mit einem Zertifikat, einem so genannten Client-Zertifikat, authentifiziert. Qt WebEngine liest die Client-Zertifikate, die in den Systemeinstellungen von macOS und Windows installiert sind, und unter Linux diejenigen, die in der NSS-Datenbank installiert sind. Zertifikate können mit dem Tool pk12util in der NSS-Datenbank installiert werden.

Standardmäßig bietet Qt WebEngine den Servern keine Client-Zertifikate an, da dies den Benutzer eindeutig identifiziert und die Erwartungen an den Datenschutz verletzen könnte.

Um die Unterstützung für Client-Zertifikate zu aktivieren, muss eine Anwendung auf die Signale QWebEnginePage::selectClientCertificate oder WebEngineView.selectClientCertificate hören und eines der angebotenen Zertifikate auswählen. Für Anwendungen, die zu nicht vertrauenswürdigen Websites navigieren können, wird empfohlen, dem Benutzer immer die Wahl zu lassen, bevor er sich gegenüber einem Remote-Server eindeutig identifiziert.

Zusätzlich zum Client-Zertifikat, das in den Systemeinstellungen gespeichert ist, bietet Qt WebEngine auch den In-Memory-Speicher. Die Instanz QWebEngineClientCertificateStore kann mit der Methode QWebEngineProfile::clientCertificateStore() erhalten werden. Eine Anwendung kann diese Klasse verwenden, um ein neues Zertifikat mit einem QWebEngineClientCertificateStore::add()-Aufruf hinzuzufügen. Beachten Sie, dass während der selectClientCertificate -Aufrufe Qt WebEngine sowohl System- als auch In-Memory gespeicherte Client-Zertifikate auflistet.

Siehe auch Client-Zertifikat-Beispiel für weitere Implementierungsdetails.

Benutzerdefinierte Schemata

Qt WebEngine ermöglicht es der Anwendung, ihre eigenen benutzerdefinierten URL-Schemata mit speziellen Sicherheitsrichtlinien und Transportmechanismen zu definieren.

Benutzerdefinierte Schemata können verwendet werden, um alternative Netzwerkprotokolle mit allen üblichen Web-Sicherheitsrichtlinien, privilegierte interne Schemata für die Anzeige von Komponenten der Benutzeroberfläche oder Debugging-Informationen, Sandbox-Schemata mit zusätzlichen Einschränkungen usw. zu implementieren.

Weitere Informationen finden Sie unter QWebEngineUrlScheme und QWebEngineUrlSchemeHandler.

Ziehen und Ablegen

Qt WebEngine unterstützt HTML5 Drag and Drop.

Diese Funktion kann getestet werden, indem Sie eine HTML5-Drag-and-Drop-Demo öffnen, wie z. B. HTML5-Demos - Drag and Drop, HTML5-Demos - Simple Drag and Drop oder HTML5-Demos - Drag and Drop, Automatic Upload, in Simple Browser oder Nano Browser.

Das Ziehen von Dateien in den Browser ist eigentlich nicht Teil von HTML5, wird aber unterstützt. Sie können es testen, indem Sie HTML5 Demos - File API öffnen.

Unterstützung für diese Funktion wurde in Qt 5.7.0 hinzugefügt.

Favicon

Qt WebEngine unterstützt das URL-Symbol der Website, das Favicon. Jedes Icon wird in der internen Datenbank für jedes QWebEngineProfile gespeichert und kann über einen QWebEnginePage::icon()-Aufruf oder eine WebEngineView.icon -Eigenschaft für den aktuell geladenen Inhalt aufgerufen werden.

Darüber hinaus bietet Qt WebEngine eine API für den Zugriff auf bereits gespeicherte Icons in der internen Datenbank des Profils.

QML Favicon-Behandlung

Für den Zugriff auf Icons wird ein QQuickImageProvider registriert. Auf diesen Provider kann über eine spezielle URL zugegriffen werden, wobei das Schema "image:" und der Host "favicon" ist.

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

Die url kann die URL des Favicons sein:

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

Die url kann auch eine Seiten-URL sein, um auf das Symbol zuzugreifen:

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

Wenn mehr als ein Symbol verfügbar ist, kann die Eigenschaft Image::sourceSize angegeben werden, um das Symbol mit der gewünschten Größe auszuwählen. Wenn Image::sourceSize nicht angegeben wird oder 0 ist, wird das größte verfügbare Icon gewählt.

Der Bildanbieter sucht das angeforderte Symbol in den vorhandenen WebEngineView Instanzen. Zunächst versucht er, die aktuell angezeigten Symbole zu finden. Wenn keine Übereinstimmung gefunden wird, fordert er das Symbol aus der Datenbank an. Jedes Profil hat seine eigene Icon-Datenbank, die im persistenten Speicher abgelegt ist, so dass auf die gespeicherten Icons auch ohne Netzwerkverbindung zugegriffen werden kann. Das Icon muss zuvor geladen worden sein, um in der Datenbank gespeichert zu werden.

C++ Favicon-Behandlung

Ein Benutzer kann mit den Aufrufen QWebEngineProfile::requestIconForPageURL() oder QWebEngineProfile::requestIconForIconURL() ein Symbol aus dem zuvor geladenen Inhalt für jedes QWebEngineProfile anfordern. Beachten Sie, dass die Profildatenbank im permanenten Speicher abgelegt wird und ohne Netzwerkverbindung aufgerufen werden kann.

Vollbild

Qt WebEngine unterstützt die Anzeige von Webinhalten im Vollbildmodus. Weitere Informationen finden Sie unter WebEngineSettings.fullscreenSupportEnabled, WebEngineView.fullScreenRequested, QWebEngineSettings::FullScreenSupportEnabled, und QWebEnginePage::fullScreenRequested.

Sie können diese Funktion testen, indem Sie ein Video von YouTube im Video Player oder Nano Browser abspielen und auf das Vollbildsymbol klicken, um in den Vollbildmodus zu wechseln.

Die Unterstützung für diese Funktion wurde in Qt 5.6.0 hinzugefügt.

Hardware-Beschleunigung

QtWebEngine versucht, Hardware-Beschleunigung für das Rendern des Inhalts zu verwenden. Sie verwendet OpenGL oder OpenGLES APIs, um Rendering-Aufrufe auf der GPU auszuführen. Als Fallback wird Software-Rendering verwendet, wenn die Hardware nicht die erforderliche OpenGL-Funktionalität bietet. Der Benutzer kann den aktuellen Status der Hardware-Beschleunigung überprüfen, indem er die interne Seite chrome://gpu lädt. Außerdem kann die Beschleunigung mit QTWEBENGINE_CHROMIUM_FLAGS unter Verwendung des Schalters disable-gpu explizit deaktiviert werden. Zum Beispiel unter Linux:

export QTWEBENGINE_CHROMIUM_FLAGS=--disable-gpu

HTML5 DRM

Qt WebEngine unterstützt die Anzeige von DRM-geschützten Videos, wenn das Widevine CDM-Plugin installiert wurde. Das CDM-Plugin ist ein Ersatz für Flash-basierte Plugins zur Anzeige von DRM-geschützten Inhalten. Es liegt nur in einem Binärformat vor, so dass es die Details der DRM-Entschlüsselung verbergen kann. Es kann von einem Drittanbieter oder von einer Google Chrome-Installation bezogen werden.

Qt WebEngine Das Programm sucht beim Start nach dem Widevine CDM-Plugin in bekannten Verzeichnissen, wie dem Standard-Installationsverzeichnis von Google Chrome oder den spezifischen Pfaden von Linux-Distributionen. Der Speicherort des Plugins kann jedoch auch mit QTWEBENGINE_CHROMIUM_FLAGS unter Verwendung von widevine-path übergeben werden.

Unter Windows:

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

Unter Linux:

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

Unter macOS:

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

Das von DRM-Diensten am häufigsten verwendete Videoformat, H.264, erfordert proprietäre Audio- und Videocodecs. Weitere Informationen zur Aktivierung der Codecs finden Sie unter Audio- und Videocodecs.

Sie können diese Funktion testen, indem Sie ein Video in Simple Browser oder Nano Browser von castLabs, Swank Motion Pictures, Inc. oder Bitmovin Player abspielen.

Unterstützung für diese Funktion wurde in Qt 5.7.0 hinzugefügt.

HTML5-Geolokalisierung

Qt WebEngine unterstützt JavaScript Geolocation API mit Qt Positioning als Backend. Die HTML5-Geolokalisierung ist standardmäßig deaktiviert. Um es explizit zu erlauben, muss die Anwendung auf QWebEnginePage::permissionRequested hören. Wenn eine Berechtigungsanfrage mit dem Typ QWebEnginePermission::PermissionType::Geolocation empfangen wird, können Sie QWebEnginePermission::grant() auf dem empfangenen Objekt aufrufen, um die erforderliche Berechtigung zu erteilen.

Wenn Qt WebEngine mit der Unterstützung von Qt Positioning erstellt wurde, kann diese Funktion getestet werden, indem Maps verwendet wird, um die aktuelle Position des Benutzers zu ermitteln.

Siehe Qt Positioning für eine mögliche Backend-Einrichtung wie die GPS- oder IP-basierte Positionsbestimmung.

Unterstützung für diese Funktion wurde in Qt 5.5.0 hinzugefügt.

HTML5 WebSockets

Qt WebEngine unterstützt die WebSocket JavaScript API zur Kommunikation mit WebSocket-Servern unter Verwendung der Protokolle ws:// oder wss://. Darüber hinaus ermöglicht die Integration mit Qt WebChannel und Qt WebSockets die Kommunikation zwischen JavaScript und der nativen Seite der Anwendung.

Das Modul Qt WebChannel enthält ein hervorragendes Beispiel für einen Chat-Server und seinen webbasierten Chat-Client. Der Client funktioniert sofort in den Beispielbrowsern von Qt WebEngine (wie Simple Browser oder Nano Browser).

HTTP/2-Protokoll

Qt WebEngine unterstützt die Chromium-Implementierung des HTTP/2-Protokolls.

Diese Funktion kann getestet werden, indem eine HTTP/2-Demo, wie die Akamai HTTP/2-Demo, in Simple Browser oder Nano Browser geöffnet wird.

Lokale Speicherung

Qt WebEngine unterstützt das Speichern von Schlüssel-Wert-Paaren in einem Local Storage ohne Verfallsdatum. Dies ist Teil der Web Storage API, bei der ein Benutzer über die JavaScript-Eigenschaft Window.localStorage auf ein Storage -Objekt für die angegebenen Domains zugreifen kann. Die gespeicherten Daten bleiben auch dann erhalten, wenn die Seite oder die Browseranwendung geschlossen wird.

Beachten Sie, dass die Local Speicherung auch mit einer QWebEngineSettings::LocalStorageEnabled Einstellung deaktiviert werden kann. Außerdem kann der Speicherpfad mit einem QWebEngineProfile::setPersistentStoragePath -Aufruf angepasst werden.

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

Qt WebEngine bietet auch eine einfache Möglichkeit, den Inhalt des Local Storage mit Qt WebEngine Developer Tools zu untersuchen, indem Sie das Application Panel besuchen und das Local Storage Menü erweitern.

Native Dialoge

Eine Webseite kann Dialoge für die folgenden Funktionen anfordern:

• Eingabe von Benutzeranmeldeinformationen für die HTTP- und Proxy-Authentifizierung
• Anzeige von JavaScript-Warnungen, Bestätigungsdialogen und Aufforderungen
• Auswählen von Farben
• Auswählen von Dateien
• Anzeige von Formularvalidierungsmeldungen

Qt WebEngine bietet Standarddialoge für diese Funktionen. In Widget-basierten Anwendungen basieren die Standarddialoge auf QDialog, während sie in Qt Quick Anwendungen entweder auf Qt Quick Controls 1 oder Qt Quick Controls 2 (seit Qt 5.8) basieren können. Letztere werden nur auf eglfs Plattformen verwendet.

Um explizit Dialoge zu erzwingen, die entweder auf Qt Quick Controls 1 oder Qt Quick Controls 2 basieren, setzen Sie die Umgebungsvariable QTWEBENGINE_DIALOG_SET entweder auf QtQuickControls1 oder QtQuickControls2.

Qt WebEngine Widgets-Dialoge können durch Neuimplementierung der Funktionen QWebEnginePage::chooseFiles(), QWebEnginePage::javaScriptAlert(), QWebEnginePage::javaScriptConfirm() und QWebEnginePage::javaScriptPrompt() angepasst werden.

Seit Qt 5.8 können Qt Quick -Dialoge angepasst werden, indem man sich mit den Signalen WebEngineView::authenticationDialogRequested(), WebEngineView::javaScriptDialogRequested(), WebEngineView::colorDialogRequested(), WebEngineView::fileDialogRequested() und WebEngineView::formValidationMessageRequested() verbindet.

Anzeige von PDF-Dateien

Qt WebEngine unterstützt die Anzeige von PDF-Dokumenten durch Navigation zu ihnen. Diese Funktion verwendet die Chromium-Erweiterungs-API und das PDF-Viewer-Plugin, um die PDF-Dokumente anzuzeigen. Sie kann in Simple Browser oder Nano Browser getestet werden.

Das Laden von Plugins muss über QWebEngineSettings::PluginsEnabled oder WebEngineSettings::pluginsEnabled aktiviert werden, um diese Funktion nutzen zu können.

Diese Funktion kann über die Einstellungen QWebEngineSettings::PdfViewerEnabled oder WebEngineSettings::pdfViewerEnabled ein- (Standard) oder ausgeschaltet werden.

Unterstützung für diese Funktion wurde in Qt 5.13.0 hinzugefügt.

Seiten-Lebenszyklus-API

Qt WebEngine Qt 5.13.0 unterstützt die Page Lifecycle API-Spezifikation, eine in Arbeit befindliche Erweiterung des HTML-Standards, die es User Agents ermöglicht, ihren Ressourcenverbrauch durch Einfrieren oder Verwerfen von Hintergrundseiten zu reduzieren. Die Funktion wird sowohl in den Widgets- als auch in den QML-APIs bereitgestellt.

Ein Beispiel für die QML-API im Einsatz finden Sie im WebEngine Lifecycle-Beispiel.

Unterstützung für diese Funktion wurde in Qt 5.14.0 hinzugefügt.

Überblick über die Lebenszyklus-Zustände

Jedes WebEngineView Element (oder QWebEnginePage Objekt) kann sich in einem von drei Lebenszykluszuständen befinden: aktiv, eingefroren oder verworfen. Diese Zustände steuern, wie die Ruhezustände einer CPU, die Ressourcennutzung von Webansichten.

Der aktive Zustand ist der normale, nicht eingeschränkte Zustand einer Webansicht. Alle sichtbaren Webansichten befinden sich immer im aktiven Zustand, ebenso wie alle Webansichten, deren Ladevorgang noch nicht abgeschlossen ist. Nur unsichtbare, im Leerlauf befindliche Webansichten können in andere Lebenszykluszustände überführt werden.

Der eingefrorene Zustand ist ein Zustand mit geringer CPU-Auslastung. In diesem Zustand werden die meisten HTML-Task-Quellen ausgesetzt (eingefroren), was zur Folge hat, dass auch die meisten DOM-Ereignisverarbeitungen und JavaScript-Ausführungen ausgesetzt werden. Die Webansicht muss unsichtbar sein, um eingefroren werden zu können, da in diesem Zustand kein Rendering möglich ist.

Der verworfene Zustand ist ein extrem ressourcenschonender Zustand. In diesem Zustand wird der Browsing-Kontext der Webansicht verworfen und der entsprechende Renderer-Unterprozess beendet. Die CPU- und Speichernutzung ist in diesem Zustand praktisch auf Null reduziert. Beim Verlassen dieses Zustands wird die Webseite automatisch neu geladen. Der Prozess des Eintritts und des Verlassens des verworfenen Zustands ist vergleichbar mit der Serialisierung des Browserverlaufs der Webansicht und der Zerstörung der Ansicht, der anschließenden Erstellung einer neuen Ansicht und der Wiederherstellung ihres Verlaufs.

Siehe auch WebEngineView::LifecycleState. Die Entsprechung in der Widgets-API ist QWebEnginePage::LifecycleState.

Die Eigenschaften lifecycleState und recommendedState

Die Eigenschaft lifecycleState des Typs WebEngineView ist eine Lese- und Schreibeigenschaft, die den aktuellen Lebenszykluszustand der Webansicht steuert. Diese Eigenschaft ist so konzipiert, dass sie so wenig Einschränkungen wie möglich in Bezug auf die Zustände enthält, in die übergegangen werden kann. So ist es zum Beispiel erlaubt, eine Webansicht, die gerade Musik im Hintergrund abspielt, einzufrieren und die Musik zu stoppen. Um eine weniger aggressive Strategie zur Ressourceneinsparung zu implementieren, die eine Unterbrechung der für den Benutzer sichtbaren Hintergrundaktivität vermeidet, muss die Eigenschaft recommendedState verwendet werden.

Die Eigenschaft recommendedState des Typs WebEngineView ist eine schreibgeschützte Eigenschaft, die unter Berücksichtigung der aktuellen Aktivität der Webansicht eine sichere Grenze für die Eigenschaft lifecycleState berechnet. In dem Beispiel einer Webansicht, die im Hintergrund Musik abspielt, ist der empfohlene Zustand Active, da ein aggressiverer Zustand die Musik anhalten würde. Wenn die Anwendung eine Unterbrechung der Hintergrundaktivität vermeiden will, sollte sie es vermeiden, die Webansicht in einen aggressiveren, ressourcenschonenden Lebenszykluszustand zu versetzen als den, der durch recommendedState vorgegeben ist.

Siehe auch WebEngineView::lifecycleState und WebEngineView::recommendedState. Die Entsprechungen in der Widgets-API sind QWebEnginePage::lifecycleState und QWebEnginePage::recommendedState.

Die DOM-Erweiterungen

Die Eigenschaft lifecycleState ist mit der Spezifikation der Page Lifecycle API verbunden, die zwei neue DOM-Ereignisse, freeze und resume, spezifiziert und eine neue boolesche Eigenschaft Document.wasDiscarded hinzufügt. Die Ereignisse freeze und resume werden beim Übergang von Active zu Frozen state ausgelöst und umgekehrt. Die Eigenschaft Document.wasDiscarded wird auf true gesetzt, wenn vom Zustand Discarded zum Zustand Active übergegangen wird.

Drucken in PDF

Qt WebEngine unterstützt das Drucken einer Webseite in eine PDF-Datei. Weitere Informationen finden Sie unter QWebEnginePage::printToPdf() und WebEngineView.printToPdf.

Diese Funktion kann mit Html2Pdf getestet werden.

Unterstützung für diese Funktion wurde in Qt 5.7.0 hinzugefügt.

Modelle verarbeiten

Qt WebEngine verwendet mehrere Betriebssystemprozesse, um Websites voneinander und von der Client-Anwendung zu isolieren und so die Sicherheit und Robustheit zu verbessern. Die folgenden Prozessmodelle bzw. Möglichkeiten zur Aufteilung von Websites zwischen Betriebssystemprozessen werden unterstützt:

• Prozess pro Site-Instanz
• Prozess pro Standort
• Einzelner Prozess

Prozess pro Standortinstanz

Dies ist das Standardmodell. Seiten von verschiedenen Websites werden in separaten Prozessen abgelegt und separate Besuche derselben Website werden ebenfalls isoliert.

Zwei Webseiten werden als zur selben Site gehörig betrachtet, wenn sie vom selben registrierten Domänennamen (z. B. wikipedia.org) und Schema (z. B. https) stammen. Dies ist vergleichbar mit der "same-origin"-Politik, aber Subdomains werden ignoriert. Zum Beispiel würden sowohl https://en.wikipedia.org/ als auch https://de.wikipedia.org/ zur selben Site gehören.

Eine Site-Instanz ist eine Sammlung von Webseiten, die zur selben Site gehören. Wenn die Anwendung eine URL explizit in Qt WebEngine lädt (z. B. über QWebEnginePage::setUrl), wird eine neue Site-Instanz für die Seite erstellt. Wenn der Benutzer jedoch auf der Seite auf Links zu derselben Site klickt, wird die bestehende Site-Instanz lediglich um weitere Seiten erweitert.

Wenn ein Benutzer im Beispiel des einfachen Browsers zwei Registerkarten öffnet und explizit https://en.wikipedia.org/ in die URL-Leisten eingibt, haben beide Registerkarten ihre eigenen, separaten Betriebssystemprozesse (weil die explizite Eingabe einer URL eine neue Site-Instanz erzeugt). Wenn der Benutzer dann jedoch mit der mittleren Maustaste auf einige Links derselben Site klickt, um weitere Registerkarten zu öffnen, teilen sich diese neuen Registerkarten denselben Betriebssystemprozess (weil die Benutzerinteraktion die bestehende Site-Instanz erweitert).

Prozess pro Site

Seiten von separaten Sites werden in separaten Prozessen abgelegt. Im Gegensatz zu Prozess pro Site-Instanz teilen sich alle Besuche derselben Site einen Betriebssystemprozess.

Der Vorteil dieses Modells ist der geringere Speicherverbrauch, da sich mehr Webseiten einen Prozess teilen. Zu den Nachteilen gehören geringere Sicherheit, Robustheit und Reaktionsfähigkeit.

Um dieses Modell zu aktivieren, verwenden Sie das Befehlszeilenargument --process-per-site. Siehe Verwendung von Befehlszeilenargumenten.

Einzelner Prozess

Nur zu Debugging-Zwecken kann mit dem Befehlszeilenargument --single-process ein Einzelprozessmodus aktiviert werden. Siehe Verwendung von Befehlszeilenargumenten und Qt WebEngine Debugging und Profiling.

Rechtschreibprüfung

Qt WebEngine unterstützt die Integration der Rechtschreibprüfung in HTML-Formulare, damit die Benutzer rechtschreibgeprüfte Nachrichten übermitteln können. Wenn der Benutzer auf ein unterstrichenes, falsch geschriebenes Wort klickt, zeigt das Standard-Kontextmenü bis zu vier Vorschläge an. Wird einer davon ausgewählt, wird das falsch geschriebene Wort ersetzt.

Um die Rechtschreibung überprüfen zu können, benötigt die Rechtschreibprüfung Wörterbücher. Es werden Wörterbücher aus dem Hunspell-Projekt unterstützt, die jedoch in ein spezielles Binärformat kompiliert werden müssen. Ein Hunspell-Wörterbuch besteht aus zwei Dateien:

• Eine .dic Datei, die ein Wörterbuch mit Wörtern für die Sprache ist
• Eine .aff Datei, die die Bedeutung von speziellen Flags im Wörterbuch definiert

Diese beiden Dateien können mit dem qwebengine_convert_dict Tool, das zusammen mit Qt ausgeliefert wird, in das bdic Format konvertiert werden. Wenn die Qt WebEngine Rechtschreibprüfung initialisiert wird, versucht sie, die bdict Wörterbücher zu laden und sie auf Konsistenz zu prüfen.

Wenn QTWEBENGINE_DICTIONARIES_PATH gesetzt ist, verwendet die Rechtschreibprüfung die Wörterbücher im angegebenen Verzeichnis, ohne irgendwo anders zu suchen. Andernfalls verwendet sie das Verzeichnis qtwebengine_dictionaries relativ zur ausführbaren Datei, falls es existiert. Wenn es nicht existiert, wird in QT_INSTALL_PREFIX/qtwebengine_dictionaries gesucht.

Unter macOS gibt es, je nachdem wie Qt WebEngine zur Erstellungszeit konfiguriert ist, zwei Möglichkeiten, wie die Daten für die Rechtschreibprüfung gefunden werden:

• Hunspell-Wörterbücher (Standard) - .bdic-Wörterbücher werden verwendet, genau wie auf anderen Plattformen
• Native Wörterbücher - die macOS Rechtschreibprüfungs-APIs werden verwendet (was bedeutet, dass die Ergebnisse von den installierten OS-Wörterbüchern abhängen)

Im Fall von macOS Hunspell sucht Qt WebEngine also im Unterverzeichnis qtwebengine_dictionaries, das sich im Verzeichnis des Anwendungsbündels Resources befindet, und im Verzeichnis Resources, das sich im Qt-Framework-Bündel befindet.

Zusammenfassend lässt sich sagen, dass im Falle der Verwendung von Hunspell die folgenden Pfade berücksichtigt werden:

• QTWEBENGINE_DICTIONARIES_PATH, wenn gesetzt
• QCoreApplication::applicationDirPath()/qtwebengine_dictionaries oder QCoreApplication::applicationDirPath()/../Contents/Resources/qtwebengine_dictionaries (unter macOS)
• [QLibraryInfo::DataPath]/qtwebengine_dictionaries oder Pfad/zu/QtWebEngineCore.framework/Resources/qtwebengine_dictionaries (Qt-Framework-Bundle unter macOS)

Die Rechtschreibprüfung ist standardmäßig deaktiviert und kann pro Profil mit der Methode QWebEngineProfile::setSpellCheckEnabled() in Widget-basierten Anwendungen und der Eigenschaft WebEngineProfile.spellCheckEnabled in Qt Quick Anwendungen aktiviert werden.

Die aktuelle Sprache, die für die Rechtschreibprüfung verwendet wird, wird pro Profil definiert und kann mit der Methode QWebEngineProfile::setSpellCheckLanguages() oder der Eigenschaft WebEngineProfile.spellCheckLanguages eingestellt werden.

Diese Funktion kann durch Erstellen und Ausführen des Spellchecker-Beispiels getestet werden.

Qt WebEngine kann auch ohne Unterstützung der Rechtschreibprüfung kompiliert werden, wenn der Schalter webengine-spellchecker configure verwendet wird.

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

Für weitere Informationen, siehe Qt Configure Options.

Unterstützung für diese Funktion wurde in Qt 5.8.0 hinzugefügt.

Berühren

Qt WebEngine unterstützt Touch-Geräte zum Navigieren und Interagieren mit Web-Seiten.

Anwendungen können die Verwendung von Touch-Ereignissen auf folgende Weise unterbinden:

• Durch die Übergabe des Flags --touch-events=disabled auf der Befehlszeile wird die Unterstützung von Berührungsereignissen in der JavaScript-API deaktiviert (d. h. ontouchstart und zugehörige Handler sind im Objekt document.window nicht vorhanden). Berührungsereignisse werden weiterhin an Webseiten geliefert.
• Installieren eines Ereignisfilterobjekts mit QObject::installEventFilter auf dem WebEngine View Focus Proxy-Objekt und Herausfiltern aller Berührungsereignisse.

Ansicht Quelle

Qt WebEngine unterstützt die Anzeige des HTML-Quelltextes einer Webseite.

Diese Funktion kann über benutzerdefinierte Menüs verwendet oder benutzerdefinierten Ereignissen zugewiesen werden. Weitere Informationen finden Sie unter WebEngineView::WebAction, und QWebEnginePage::WebAction.

Sie können diese Funktion testen, indem Sie eine Webseite in Simple Browser oder Nano Browser öffnen und dann Page Source im Kontextmenü auswählen. Der Kontextmenüeintrag Page Source öffnet die Quellansicht in einer neuen Registerkarte.

Zum Öffnen der Quellansicht in der aktuellen Registerkarte werden auch URLs mit dem URI-Schema view-source unterstützt. Sie können zum Beispiel die folgende URL in die URL-Leiste eingeben, um den HTML-Quelltext der qt.io-Webseite anzuzeigen:

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

Die automatische Vervollständigung von unvollständigen URLs mit view-source URI Schema macht die Nutzung dieser Funktion komfortabler. Zum Beispiel lädt die folgende unvollständige URL auch die Quellansicht der qt.io-Webseite:

view-source:qt.io

Unterstützung für diese Funktion wurde in Qt 5.8.0 hinzugefügt.

Web-Benachrichtigungen

Qt WebEngine unterstützt die JavaScript Web Notifications API. Die Anwendung muss die Funktion explizit zulassen, indem sie QWebEnginePage::Notifications oder WebEngineView.Notifications verwendet.

Unterstützung für diese Funktion wurde in Qt 5.13.0 hinzugefügt.

WebGL

Qt WebEngine unterstützt WebGL für einige Grafikstapel-Setups. Ein Benutzer kann die Seite chrome://gpu mit der Anwendung QtWebEngine besuchen. Die Übersicht über den Status der Grafikfunktionen gibt an, ob WebGL für die aktuelle Plattformeinrichtung unterstützt wird. Ein Benutzer kann auch den WebGL-Bericht überprüfen.

Die WebGL-Unterstützung ist standardmäßig aktiviert. Sie können sie mit der Einstellung QWebEngineSettings::WebGLEnabled deaktivieren.

WebRTC

WebRTC bietet Browsern Echtzeit-Kommunikationsfunktionen (RTC) über einfache APIs. Weitere Informationen finden Sie unter WebEngineView.Feature, und QWebEnginePage::Feature.

Diese Funktion kann getestet werden, indem Sie eine Webcam oder ein Mikrofon einrichten und dann https://test.webrtc.org/ in Simple Browser oder Nano Browser öffnen.