Vorschauruntime 156.0.4314.8 (12. Oktober 2026)

Versionshinweise für Microsoft Edge WebView2 Preview Runtime, Veröffentlichungsdatum: 12. Oktober 2026.

Dies ist eine Vorschau-Laufzeit für frühe Tests. Vorabversionstests von WebView2-SDKs verwenden einen Vorschaukanal von Microsoft Edge (Beta, Dev oder Canary), der die WebView2-Vorschauruntime enthält.

Diese Versionshinweise gelten für die WebView2 Preview Runtime, die dem Beta-Vorschaukanal von Microsoft Edge entspricht. Es wird empfohlen, Ihre App mit dem Beta-Vorschaukanal von Microsoft Edge zu testen, bevor diese Änderungen in "Stable" hochgestuft werden. Wenn Sie noch früher testen möchten, können Sie mit Edge Dev oder Edge Canary testen.

Weitere Informationen finden Sie unter Vorabversionstests mit Vorschaukanälen von Microsoft Edge.

Zusätzlich zu den folgenden WebView2-Runtimeverbesserungen können Sie auch die neuen Webplattformfeatures von Microsoft Edge 156 verwenden. siehe Anmerkungen zur Microsoft Edge 156-Webplattform (22. Oktober 2026).

Bevorstehende wichtige Änderung: Entfernen des msAbydosHandwritingAttr WebView2-Browserflags

Ab Version 159 entfernt WebView2 das veraltete msAbydosHandwritingAttr Browserflag. Nach dieser Änderung wird durch Durchlaufen msAbydosHandwritingAttrWEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTSvon registrierungsbasierten Browserargumenten oder CoreWebView2EnvironmentOptions.AdditionalBrowserArguments das erwartete Verhalten nicht mehr aktiviert.

Überprüfen Sie Ihre App- und Testkonfiguration und planen Sie entsprechend.

Was dies für Ihre App bedeutet

  • Apps, die nicht festgelegt msAbydosHandwritingAttrwerden:

    Es ist keine Aktion erforderlich.

  • Apps oder Testtools, die das msAbydosHandwritingAttr Kennzeichen setzen:

    Entfernen Sie das msAbydosHandwritingAttr Kennzeichen und validieren Sie handschriftliche Szenarien ohne es.

  • Enterprisebereitstellungen, die Browserargumente über Umgebungsvariablen oder Registrierungseinstellungen konfigurieren:

    Entfernen Sie das Flag aus der msAbydosHandwritingAttr verwalteten Konfiguration.

Weitere Informationen

Feedback teilen

Haben Sie eine Frage oder sind Sie auf eine Regression gestoßen? Melden Sie ein Problem im WebView2Feedback-Repository mit Ihrer Runtime-Version, Windows-Version, Konfiguration und Reproduktionsschritten.

Bevorstehende wichtige Änderung: Erforderliche ACL-Einrichtung für App-verwaltete WebView2 Runtimes mit Fixierter Version unter Windows

Ab Version 159 stärkt WebView2 die Renderer-Sandbox für App-verwaltete Bereitstellungen mit Fixierter Version. Anwendungen, die eine nicht gepackte Runtime mit Fixierter Version bereitstellen und verwalten, müssen die erforderlichen Windows Access Control List (ACL)-Einträge im Runtime-Ordner während der Installation, Laufzeitaktualisierungen und Reparatur konfigurieren und beibehalten.

Dieser Leitfaden gilt für von Apps verwaltete, nicht verpackte Bereitstellungen mit Fixierter Version unter Windows 10 und Windows 11. Für Evergreen-Bereitstellungen und Windows-verwaltete Paketordner ist diese Installationsaktion nicht erforderlich.

Was dies für Ihre App bedeutet

  • Evergreen Runtime:

    Für von Microsoft verwaltete Laufzeitdateien ist keine ACL-Aktion erforderlich.

  • Speicherorte von gepackten Apps und von Windows verwalteten Paketen:

    Ändern Sie Paketordner-ACLs nicht manuell.

  • App-verwaltete, nicht gepackte Laufzeit mit Fixierter Version:

    Aktualisieren Sie Ihren Installations-, Updater- und Reparaturfluss, um die erforderlichen Berechtigungen zu konfigurieren und zu überprüfen.

Erforderliches Setup

Führen Sie die folgenden Befehle in einem Installationskontext mit geeigneten erhöhten Rechten aus, und ersetzen {Fixed Version path} Sie ihn durch den Laufzeitordner, der von Ihrer Anwendung bereitgestellt wird:

icacls "{Fixed Version path}" /grant *S-1-15-2-2:(OI)(CI)(RX)

icacls "{Fixed Version path}" /grant *S-1-15-2-1:(OI)(CI)(RX)

Diese Einträge gewähren vererbbaren Lese- und Ausführungszugriff auf ALLE EINGESCHRÄNKTEN ANWENDUNGSPAKETE und ALLE ANWENDUNGSPAKETE. Behalten Sie die vorhandenen Berechtigungen des Laufzeitordners bei.

Vorbereitungen

  1. Fügen Sie das ACL-Setup zu den Installations-, Laufzeitaktualisierungs- und Reparaturpfaden hinzu.

  2. Überprüfen Sie nach jedem Bereitstellungsvorgang, ob beide Identitäten über Lese- und Ausführungszugriff auf den Laufzeitordner und dessen Inhalt verfügen.

  3. Führen Sie die installierte App wie ein normaler Benutzer aus, und üben Sie alle WebView2-Features aus, von denen Ihre App abhängt. Das anfängliche Laden der Seite allein reicht nicht aus.

  4. Behandeln Sie WebView2 process-start oder access-denied Fehler mit einem umsetzbaren Reparaturpfad.

  5. Verwenden Sie no-sandbox weder einen anderen Sandbox-Deaktivierungsschalter als Problemumgehung.

Weitere Informationen

Feedback teilen

Haben Sie eine Frage oder sind Sie auf eine Regression bei der Bereitstellung gestoßen? Melden Sie ein Problem im WebView2Feedback-Repository mit Ihrem Bereitstellungsmodell, dem Laufzeitpfad, den Windows- und Laufzeitversionen, den resultierenden ACLs und den Reproduktionsschritten.

Bevorstehende Breaking Change: Strengere Verzeichnisprüfungen für den Dateisystemzugriff

Ab Version 159 wendet WebView2 strengere Überprüfungen auf eingeschränkte Ordner während des Dateisystemzugriffs-Verzeichnisdurchlaufs unter Windows an.

WebView2 unter Windows wird genauer an das Chromium-Sicherheitsverhalten angepasst, indem Überprüfungen vertraulicher Standorte angewendet werden, wenn Webinhalte auf Einträge unterhalb eines gewährten Verzeichnisses zugreifen oder diese aufzählen.

Diese Änderung kann sich auf Apps auswirken, die die Dateisystemzugriffs-API für Webinhalte verfügbar machen oder den Zugriff auf Ordner unter geschützten System- oder Profilspeicherorten delegieren. Überprüfen Sie Ihren Entwurf für den Dateizugriff, und planen Sie entsprechend.

Zeitleiste für die Veröffentlichung (mit Vorbehalt)

  • Oktober 2026 – Vorankündigung.

  • Migrationszeitfenster — Ungefähr 2 Monate nach der Ankündigung; Die endgültigen Termine stehen noch unter dem Vorbehalt der Bestätigung durch den Release-Besitzer.

  • [Bestätigung durch den Releasebesitzer erforderlich] — Strengere Prüfungen erreichen einen WebView2-Vorschaukanal.

  • [Bestätigung durch den Releasebesitzer erforderlich] – Die Erzwingung erreicht die Evergreen Stable Runtime und das entsprechende Release der Fixierten Version.

Was dies für Ihre App bedeutet

  • Apps, die die Dateisystemzugriffs-API nicht verwenden:

    Es ist keine Aktion erforderlich.

  • Apps, die vom Benutzer ausgewählte Verzeichnisse auflisten:

    Verknüpfte oder geschützte untergeordnete Einträge geben jetzt möglicherweise ein access-denied Ergebnis zurück.

  • Apps, die absichtlich auf Daten unterhalb von eingeschränkten Speicherorten zugreifen:

    Workflows für den direkten Dateisystemzugriff funktionieren möglicherweise nicht mehr und erfordern eine Änderung des Speichers oder der Hostintegration.

  • Hostdelegierte Workflows:

    Überprüfen Sie, ob der gewährte Standort, seine untergeordneten Elemente oder verknüpfte Ziele unter die Richtlinie für eingeschränkte Standorte fallen.

Vorbereitungen

  1. Verschieben Sie von Apps verwaltete Daten, die für Webinhalte benötigt werden, nach Möglichkeit an einen geeigneten, nicht eingeschränkten Speicherort.

  2. Wenn geschützte Daten vorhanden bleiben müssen, stellen Sie nur die minimal erforderlichen Vorgänge über eine validierte hostvermittelte Schnittstelle bereit, anstatt über einen breiten, direkten Dateisystemzugriff.

  3. Behandeln Sie Ergebnisse bei verweigertem Zugriff sorgfältig, und bieten Sie einen umsetzbaren Wiederherstellungspfad für Benutzer.

Informationen zu eingeschränkten Ordnern

Die Richtlinie für eingeschränkte Standorte ist sicherheitsrelevant und kann sich weiterentwickeln. Microsoft veröffentlicht oder garantiert keine vollständige Verzeichnisliste. Kodieren Sie eine Ordnerliste nicht hart, und gehen Sie nicht davon aus, dass ein Speicherort zulässig ist, weil er in der Dokumentation nicht genannt wird. Die öffentliche Anleitung von Chromium beschreibt ebenfalls eingeschränkte Ordner und Beispiele, ohne eine vollständige Sperrliste zu veröffentlichen.

Weitere Informationen

  • Eingeschränkte Ordner in der Dateisystemzugriffs-API: Vereinfachen des Zugriffs auf lokale Dateien in Chrome-Dokumenten.

Feedback teilen

Haben Sie eine Frage oder sind wir auf eine Regression gestoßen? Melden Sie ein Problem im WebView2Feedback-Repository mit der API-Sequenz, der ausgewählten Ordnerform, den Details zu verknüpften Pfaden, den Windows- und Runtime-Versionen sowie den Reproduktionsschritten.

Fehlerbehebungen

  • Die DACL-Mutationsoberfläche wurde eingeschränkt.
  • Ein fehlgeschlagener interaktiver Windows-Anmeldeversuch für den aktuellen lokalen Benutzer wurde behoben.
  • Es wurde ein Problem behoben, bei dem WebResourceRequested Ereignisse für Service Worker und Shared Worker nicht ordnungsgemäß auf das WebView2-Profil beschränkt waren.
  • Die Klickweitergabe von der Titelleiste Window Controls Overlay (WCO) auf Webinhalte wurde korrigiert.
  • Falsches Anzeigefenster im Minimalmodus behoben.
  • Die JAWS-Unterstützung im Minimalfenster wurde korrigiert.
  • Korrigierte Downloads, die für Antivirenscans unter der Identität der Host-App anstelle der Identität der freigegebenen Laufzeit übermittelt wurden.
  • Der Mark-of-the-Web-Prompt-Status wurde korrigiert, sodass er pro Host-App statt pro freigegebener WebView2-Runtime nachverfolgt wird.

Siehe auch

  • Zuletzt aktualisiert um