Runtime 150.0.4078.44 (7. Juli 2026)

Versionshinweise für Microsoft Edge WebView2 Runtime, Veröffentlichungsdatum: 7. Juli 2026.

Zusätzlich zu den folgenden Verbesserungen der WebView2-Runtime können Sie auch die neuen Webplattform-Features von Microsoft Edge 150 verwenden. Weitere Informationen finden Sie in den Versionshinweisen zur Microsoft Edge 150-Webplattform (2. Juli 2026).

WebView2 Runtime wechselt zu einem zweiwöchigen Veröffentlichungsrhythmus

Ab Version 152 (28. August 2026) wechselt die WebView2-Runtime zu einem zweiwöchigen Veröffentlichungsrhythmus. Dies ist auf Microsoft Edge ausgerichtet. WebView2 Runtime Version 151 ist die endgültige Version mit einem 4-wöchigen Versionsrhythmus.

Siehe [Ankündigung] WebView2 Runtime wechselt zu einem zweiwöchigen Veröffentlichungsrhythmus (ab v152).

Fehlerbehebungen

  • Die Ablaufinvarianz beim Löschen von Frames wurde korrigiert.

  • Der Objektwrapperzugriff für eine Benutzerautorisierungsdatei (User Authorization File, UAF) wurde korrigiert.

  • Stempeln Sie den browserautorisierenden Ursprung auf die Hostpipe, um eine WebMessageReceivedEventArgs.Source Spoofung zu verhindern.

  • Eingeschränkter Zugriff auf eine Singleton-Hostpipe in einem veralteten WebView2.

  • Der Parameter wurde aus Methoden entfernt origin , die auf ein natives Objekt zugreifen.

  • Verstärkte Durchsetzung von WebView2-Virtual-Host-Hosts kDeny gegen Renderer-Spoofing und NTFS-Junction-Escapes (New Technology File System).

  • Die Struktur von Fenster-zu-Visualisierung der Benutzeroberflächenautomatisierung (UIA) wurde korrigiert.

  • Eine Regression in der AddScriptToExecuteOnDocumentCreated API wurde behoben.

  • Gesamtanzahlhistogramme für WebView2-Umgebung und Controllererstellungsversuche hinzugefügt.

  • Zugeordnet TERMINATION_STATUS_LAUNCH_FAILED_OS_POLICY zu kLaunchFailed

  • Die Klassifizierung der Fehlerursache wurde für einen Prozess, der gekillt wurde, um Arbeitsspeicher freizugeben, auf OOMaktualisiert.

  • Es wurde eine Momentaufnahme des Systemspeichers zum Zeitpunkt der Erkennung von nicht genügend Arbeitsspeicher (OOM) für die Analyse hinzugefügt.

  • Das automatische Schließen eines Popups, wenn der Host erwartet, dass das Popup geöffnet bleibt, wurde behoben.

  • Überprüfung des vertrauenswürdigen Ursprungs während des Hostobjektzugriffs hinzugefügt.

  • Reduzierte redundante Kartensuche im WebView2 URL-Anforderungsmanager für verbesserte Leistung.

  • Unnötige Zeichenfolgenzuweisungen in der WebView2-Cookie-Ebene wurden eliminiert, um die Leistung zu verbessern.

Wichtige Änderung: Aktivieren der Windows-Shell-Handschriftunterstützung für WebView2 im WindowToVisual-Modus

WebView2 führt Unterstützung für Windows-Shellhandschrift (Stifthandschrift in Text) für Bearbeitungsfelder in WebView2-Instanzen ein, die unter Windows im Modus "Fenster zu Visual" (WindowToVisual) gehostet werden.

Diese Änderung betrifft nur WindowToVisual den Hostingmodus. WindowToWindow Der Hostingmodus unterstützt bereits Windows Shell-Handschrift, und VisualToVisual der Hostingmodus wird von dieser Änderung nicht unterstützt.

Vor dieser Änderung: WebView2 im WindowToVisual Modus registriert keinen ITfHandwritingSink TSF-Thread (Text Services Framework). Windows-Shell-Handschrift kann weiterhin funktionieren, aber die Handschriftzielbestimmung verwendet den auf der Betriebssystem-Benutzeroberflächenautomatisierung (UIA) basierenden Pfad.

Nach dieser Änderung: Wenn das msAbydosForWindowlessWV2 Featureflag deaktiviert ist, bleibt das Verhalten das gleiche wie vor dieser Änderung, einschließlich des UIA-basierten Handschriftziel-Bestimmungspfads.

Wenn das msAbydosForWindowlessWV2 Featureflag aktiviert ist, registriert WebView2 im WindowToVisual Modus eine Pro-instance ITfHandwritingSink im TSF-Thread. Dies aktiviert die Windows-Shell-Handschrift für Bearbeitungsfelder in WebView2 und ändert die Art und Weise, wie TSF-Handschriftereignisse auf den freigegebenen TSF-Thread weitergeleitet werden.

Wenn Ihre App bereits eine eigene ITfHandwritingSink App in ihrem TSF-Thread registriert, funktioniert die Stifthandschrift weiterhin für die nativen Bearbeitungsfelder Ihrer App, und die Stifthandschrift funktioniert auch in WebView2-Bearbeitungsfeldern.

Wenn Ihre App keine eigene ITfHandwritingSinkregistriert, funktioniert die Stifthandschrift möglicherweise nicht mehr für die nativen Bearbeitungsfelder Ihrer App, nachdem diese Änderung standardmäßig aktiviert wurde. Dies tritt auf, weil WebView2 für HWNDs zurückgibt E_NOTIMPL , die es nicht besitzt, und erwartet, dass TSF mit einer anderen registrierten Senke verkettet wird. Wenn keine Hostsenke registriert ist, greift TSF nicht auf die standardmäßige UIA-basierte Handschriftzielauflösung zurück.

Um die Unterstützung der Stifthandschrift für die nativen Bearbeitungsfelder Ihrer App beizubehalten, registrieren Sie Ihre eigene ITfHandwritingSink im TSF-Thread. Die Stifthandschrift in den WebView2-Bearbeitungsfeldern wird durch diese Änderung automatisch aktiviert.

Sie können das Verhalten Ihrer WebView2-App proaktiv überprüfen, indem Sie das folgende Featureflag aktivieren, bevor Sie Ihre App starten:

set WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS=--enable-features=msAbydosForWindowlessWV2

In den Versionen 149 und 150 ist das msAbydosForWindowlessWV2 Featureflag standardmäßig deaktiviert, sodass Apps Zeit zum proaktiven Testen haben. Ab Version 151 ist es geplant, das Feature standardmäßig zu aktivieren.

Indem Sie Ihre WebView2-App mit aktiviertem Featureflag testen, können Sie feststellen, ob native Handschrift-Workflows in Ihrem Arbeitsbereich von der Registrierung eines Hosts ITfHandwritingSinkabhängen.

Siehe auch:

Siehe auch

  • Last updated on